[U-Boot] 64-bit x86 U-Boot?

[Bin Meng]

Hi Simon,

On Wed, Feb 3, 2016 at 12:31 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 2 February 2016 at 08:02, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Albert,
>>
>> On Tue, Feb 2, 2016 at 5:53 PM, Albert ARIBAUD
>> <albert.u.boot at aribaud.net> wrote:
>>> Hello Bin and Simon,
>>>
>>> On Tue, 2 Feb 2016 15:25:48 +0800, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Tue, Feb 2, 2016 at 11:58 AM, Simon Glass <sjg at chromium.org> wrote:
>>>> > +Bin (sorry, meant to copy you before)
>>>
>>>> >>> For non-FSP devices we don't init the RAM until much later -
>>>> >>> dram_init(). That means that a significant portion of the init
>>>> >>> sequence would be 32-bit code. I'm not sure that will work.
>>>> >>>
>>>>
>>>> I believe we can do dram_init() in 64-bit mode as well if MRC is
>>>> written in pure C.
>>>
>>> Bin: not sure what you mean by "if MRC is written in pure C" -- there
>>> is no C construct that can even approach the mrc instruction, which can
>>> only be emitted through an asm statement.
>>
>> You are exposed as an ARM guy :-) I was talking about an Intel term
>> Memory Reference Code which are a amount of magic codes to initialize
>> system RAM.
>>
>>>
>>>> > I wonder whether we might need to resort to SPL for the 32-bit
>>>> > portion, and jump to a 64-bit U-Boot from there? Tegra does something
>>>> > similar to that.
>>>
>>> Simon: seems like a sensible approach, as it does not mix 32 and 64
>>> bits in one "build artefact", plus it seems logical in that SPL's
>>> role is to get the platform ready for U-Boot; switching from
>>> power-on32-bit mode to 64-bit mode belongs quite "naturally" in SPL.
>>>
>>>> What's the benefit of doing a 64-bit bootloader? Intel's UEFI BIOS has
>>>> a 32-bit and 64-bit version, and has caused some troubles for the next
>>>> stage loader (bootia32.efi vs. bootx64.efi). I know for PowerPC, a
>>>> 64-bit U-Boot does not exist as 32-bit U-Boot can load 32-bit and
>>>> 64-bit kernel, just like what we have for x86. 64-bit U-Boot was only
>>>> seen on ARMv8, but that's the architecture limitation I believe, and
>>>> we have to do that.
>>>
>>> Some U-Boot users who might want to get rid of x86 32-bit code in
>>> x86 64-bit platforms just like in the past some people must have wanted
>>> to get rid of real-mode 16-bit x86 code in order to run pure 32-bit; the
>>
>> Yep, but unfortunately we still cannot get rid of real-mode 16-bit x86
>> code even today :(
>>
>>> idea is that if you can do with as well as without a feature, then that
>>> feature is potential dead code, and is candidate for removal, all the
>>> more when that feature partly collides with another feature, as here
>>> where 32-bit and 64-bit support sort of overlap partially.
>>>
>>
>> I wonder if some day these processors (arm, x86, whatever else?) will
>> come out of reset in the 64-bit mode directly. No more any legacy
>> modes. At that time, 64-bit mode bootloader is definitely a must.
>
> ARM does. Not sure if Intel will, but they should IMO!
>

Agreed. But guess Intel won't do that due to whatever backward
compatible reasons..

>>
>>> Now, we can wait until x86 32-bit is really dead (as in "not used
>>> except in a few legacy projects whose engineers' children are about to
>>> retire") and then scrape dead code parts which no one really understands
>>> any more, or we can try and anticipate and replace code while we still
>>> have a grasp of what it does. I personally like the idea of anticipating
>>> better.
>>>
>>> Just in case, note that I do not mean x86 32-bit support should be
>>> removed from U-Boot now or later. I mean that if we can make x86 64-bit
>>> support in U-Boot less and less dependent on x86 32-bit support, then I
>>> think we should, so that the day we completely drop x86 32-bit support,
>>> x86 64-bit support will be (as) unaffected (as possible).
>>>
>>
>> I agree with the philosophy here. But I sense this might be too
>> anticipating as there are some other tasks to do for U-Boot 32-bit
>> like ACPI and SMM. 32-bit is enough for now, unless we want to access
>>>4GB memory in U-Boot shell?
>
> Yes, I suppose there are more important things. The 32/64-bit split
> bothers me. For example with the EFI loader series, U-Boot runs in
> 32-bit mode so can only run a 32-bit EFI application (e.g. grub). That
> seems like an annoying limitation. We don't have that limitation when
> booting a kernel.

Isn't the limitation coming from UEFI itself? My understanding is that
we cannot boot a 64-bit EFI application from a 32-bit UEFI BIOS as
well.

>
> But I'm not sure it is very important - just something I was thinking about.
>

Yep, thanks for bringing this for discussion. It's very helpful. We
can put the 64-bit port as a TODO list.

Regards,
Bin