[U-Boot] [PATCH 00/82] x86: Add initial support for 64-bit U-Boot

[Simon Glass]

Hi Bin,

On 17 October 2016 at 19:25, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Tue, Oct 18, 2016 at 6:17 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 10 October 2016 at 23:36, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Mon, Sep 26, 2016 at 11:33 AM, Simon Glass <sjg at chromium.org> wrote:
>>>> At present U-Boot runs entirely in 32-bit mode on x86, except for the
>>>> initial switch from 16-bit mode. On 64-bit machines it is possible to run
>>>> in 64-bit mode. This series starts the process of adding this support.
>>>>
>>>> The main benefit of 64-bit mode for a boot loader is direct access to all
>>>> available memory. There are also more registers, but this makes very little
>>>> difference.
>>>>
>>>> This feature is implemented by putting all of the 32-bit code in an SPL
>>>> build. SPL then runs through all the init that has to be done in 32-bit
>>>> mode, changes to 64-bit mode and then jumps to U-Boot proper.
>>>>
>>>> Typically the total code size increases slightly. For example, on link in
>>>> 32-bit mode, U-Boot has around 480KB of code (admittedly with a large
>>>> number of features enabled). In 64-bit mode, U-Boot falls to around 460KB,
>>>> but SPL adds another 60KB, for a net increase of 40KB. Partly this is due
>>>> to code duplication and partly it is due to the worse code density of
>>>> 64-bit code on x86.
>>>>
>>>> Many major features are not implemented yet, for example:
>>>> - SDRAM sizing
>>>> - Booting linux
>>>> - FSP support
>>>> - EFI support
>>>> - SCSI device init
>>>> - Running video ROMs
>>>>
>>>> Still, this is a big step forward towards full 64-bit support. To enable it,
>>>> select CONFIG_X86_RUN_64BIT.
>>>>
>>>> This series is available at u-boot-x86/64-working
>>>>
>>>
>>> Looks it requires a 64-bit toolchain to compile 64-bit U-Boot. For
>>> example, I used kernel.org i386 toolchain to compile 64-bit U-Boot, I
>>> got:
>>>
>>> include/asm-generic/bitops/__fls.h: In function '__fls':
>>> include/asm-generic/bitops/__fls.h:17:2: warning: left shift count >=
>>> width of type
>>>   if (!(word & (~0ul << 32))) {
>>>   ^
>>> include/asm-generic/bitops/__fls.h:19:3: warning: left shift count >=
>>> width of type
>>>    word <<= 32;
>>>    ^
>>> include/asm-generic/bitops/__fls.h:22:2: warning: left shift count >=
>>> width of type
>>>   if (!(word & (~0ul << (BITS_PER_LONG-16)))) {
>>>   ^
>>> include/asm-generic/bitops/__fls.h:26:2: warning: left shift count >=
>>> width of type
>>>   if (!(word & (~0ul << (BITS_PER_LONG-8)))) {
>>>   ^
>>> include/asm-generic/bitops/__fls.h:30:2: warning: left shift count >=
>>> width of type
>>>   if (!(word & (~0ul << (BITS_PER_LONG-4)))) {
>>>   ^
>>> include/asm-generic/bitops/__fls.h:34:2: warning: left shift count >=
>>> width of type
>>>   if (!(word & (~0ul << (BITS_PER_LONG-2)))) {
>>>   ^
>>> include/asm-generic/bitops/__fls.h:38:2: warning: left shift count >=
>>> width of type
>>>   if (!(word & (~0ul << (BITS_PER_LONG-1))))
>>>   ^
>>> arch/x86/cpu/intel_common/microcode.c: In function 'microcode_read_rev':
>>> arch/x86/cpu/intel_common/microcode.c:79:2: error: PIC register
>>> clobbered by 'ebx' in 'asm'
>>>   asm volatile (
>>>   ^
>>> make[2]: *** [arch/x86/cpu/intel_common/microcode.o] Error 1
>>
>> Yes, that is expected.
>
> Can we make the i386 toolchain work? Linux 64-bit kernel build does
> not require the toolchain to be 64-bit.

I can fix the header file warnings, but things like pushq do not seem
to be supported on the i386 toolchain. Perhaps this is something to
look at later.

>
>>>
>>> After I switched to 64-bit toolchain from kernel.org (x86_64-linux),
>>> there was no such warnings/errors, but I still got build failure at
>>> last.
>>>
>>>   ./tools/binman/binman -d u-boot.dtb -O . -I . -I
>>> ./board/google/chromebook_link u-boot-x86-16bit.bin
>>> Traceback (most recent call last):
>>>   File "./tools/binman/binman", line 31, in <module>
>>>     import control
>>>   File "./tools/binman/control.py", line 17, in <module>
>>>     from image import Image
>>>   File "./tools/binman/image.py", line 12, in <module>
>>>     import entry
>>>   File "./tools/binman/etype/entry.py", line 8, in <module>
>>>     import importlib
>>> ImportError: No module named importlib
>>> make: *** [u-boot.rom] Error 1
>>
>> What version of python do you use?
>
> $ python -V
> Python 2.7.12

I thought importlib was implemented in 2.7 (I am using 2.7.6 which is
older). But I'll add a work-around for this as it seems I was wrong.

Regards,
Simon