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

[Albert ARIBAUD]

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.

> > 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
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.

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).

> Regards,
> Bin

Amicalement,
-- 
Albert.