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

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

[Simon Glass]

Hi Bin,

At present U-Boot supports booting a 64-bit kernel directly. It can
also be loaded as a 64-bit payload from EFI. But it cannot be built as
a 64-bit boot loader.

I took a bit of a look at this. It looks like we need to stay in
32-bit mode until the FSP is loaded. Also, to get to 64-bit mode I'm
pretty sure we need page tables, which means we need somewhere to put
them!

Looking at the board_f init sequence, it seems that arch_cpu_init() is
the earlist we could switch to 64-bit. We'd need to grab some memory
from somewhere to do this - I wonder if this can be CAR? There is no
SRAM on x86 chips I think.

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 suppose one option is to only go to 64-bit mode when relocating. But
then we end up with lots of code that needs to run in 32-bit and
64-bit.

Do you have any ideas on this?

Regards,
Simon

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

[Albert ARIBAUD]

Hello Simon,

On Sun, 31 Jan 2016 19:20:31 -0700, Simon Glass <sjg@chromium.org>
wrote:
> Hi Bin,
> 
> At present U-Boot supports booting a 64-bit kernel directly. It can
> also be loaded as a 64-bit payload from EFI. But it cannot be built as
> a 64-bit boot loader.
> 
> I took a bit of a look at this. It looks like we need to stay in
> 32-bit mode until the FSP is loaded. Also, to get to 64-bit mode I'm
> pretty sure we need page tables, which means we need somewhere to put
> them!
> 
> Looking at the board_f init sequence, it seems that arch_cpu_init() is
> the earlist we could switch to 64-bit. We'd need to grab some memory
> from somewhere to do this - I wonder if this can be CAR? There is no
> SRAM on x86 chips I think.
> 
> 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 suppose one option is to only go to 64-bit mode when relocating. But
> then we end up with lots of code that needs to run in 32-bit and
> 64-bit.
> 
> Do you have any ideas on this?

How about starting with implementing the last option, i.e. switch to 64
bits when DDR is available, mainline that, then progressively work your
way toward an earlier switch?

> Regards,
> Simon

Amicalement,
-- 
Albert.

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

[Simon Glass]

+Bin (sorry, meant to copy you before)

Hi Albert,

On 1 February 2016 at 00:14, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> Hello Simon,
>
> On Sun, 31 Jan 2016 19:20:31 -0700, Simon Glass <sjg@chromium.org>
> wrote:
>> Hi Bin,
>>
>> At present U-Boot supports booting a 64-bit kernel directly. It can
>> also be loaded as a 64-bit payload from EFI. But it cannot be built as
>> a 64-bit boot loader.
>>
>> I took a bit of a look at this. It looks like we need to stay in
>> 32-bit mode until the FSP is loaded. Also, to get to 64-bit mode I'm
>> pretty sure we need page tables, which means we need somewhere to put
>> them!
>>
>> Looking at the board_f init sequence, it seems that arch_cpu_init() is
>> the earlist we could switch to 64-bit. We'd need to grab some memory
>> from somewhere to do this - I wonder if this can be CAR? There is no
>> SRAM on x86 chips I think.
>>
>> 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 suppose one option is to only go to 64-bit mode when relocating. But
>> then we end up with lots of code that needs to run in 32-bit and
>> 64-bit.
>>
>> Do you have any ideas on this?
>
> How about starting with implementing the last option, i.e. switch to 64
> bits when DDR is available, mainline that, then progressively work your
> way toward an earlier switch?

The tricky thing is that I'm not sure we can run 32-bit code in 64-bit
mode or vice-versa. The instruction set is similar but there are data
size settings that probably make it incompatible.

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.

Regards,
Simon

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

[Bin Meng]

Hi Simon,

On Tue, Feb 2, 2016 at 11:58 AM, Simon Glass <sjg@chromium.org> wrote:
> +Bin (sorry, meant to copy you before)
>
> Hi Albert,
>
> On 1 February 2016 at 00:14, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
>> Hello Simon,
>>
>> On Sun, 31 Jan 2016 19:20:31 -0700, Simon Glass <sjg@chromium.org>
>> wrote:
>>> Hi Bin,
>>>
>>> At present U-Boot supports booting a 64-bit kernel directly. It can
>>> also be loaded as a 64-bit payload from EFI. But it cannot be built as
>>> a 64-bit boot loader.
>>>
>>> I took a bit of a look at this. It looks like we need to stay in
>>> 32-bit mode until the FSP is loaded. Also, to get to 64-bit mode I'm
>>> pretty sure we need page tables, which means we need somewhere to put
>>> them!
>>>

Yes unfortunately that is the FSP limitation.

>>> Looking at the board_f init sequence, it seems that arch_cpu_init() is
>>> the earlist we could switch to 64-bit. We'd need to grab some memory
>>> from somewhere to do this - I wonder if this can be CAR? There is no
>>> SRAM on x86 chips I think.
>>>
>>> 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.

>>> I suppose one option is to only go to 64-bit mode when relocating. But
>>> then we end up with lots of code that needs to run in 32-bit and
>>> 64-bit.
>>>
>>> Do you have any ideas on this?
>>
>> How about starting with implementing the last option, i.e. switch to 64
>> bits when DDR is available, mainline that, then progressively work your
>> way toward an earlier switch?
>
> The tricky thing is that I'm not sure we can run 32-bit code in 64-bit
> mode or vice-versa. The instruction set is similar but there are data
> size settings that probably make it incompatible.
>

No, it's not 100% compatible. We have to switch back and forth unfortunately.

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

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.

Regards,
Bin

[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@gmail.com> wrote:
> Hi Simon,
> 
> On Tue, Feb 2, 2016 at 11:58 AM, Simon Glass <sjg@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.

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

[Bin Meng]

Hi Albert,

On Tue, Feb 2, 2016 at 5:53 PM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Hello Bin and Simon,
>
> On Tue, 2 Feb 2016 15:25:48 +0800, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Tue, Feb 2, 2016 at 11:58 AM, Simon Glass <sjg@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.

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

Regards,
Bin

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

[Simon Glass]

Hi Bin,

On 2 February 2016 at 08:02, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Albert,
>
> On Tue, Feb 2, 2016 at 5:53 PM, Albert ARIBAUD
> <albert.u.boot@aribaud.net> wrote:
>> Hello Bin and Simon,
>>
>> On Tue, 2 Feb 2016 15:25:48 +0800, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Tue, Feb 2, 2016 at 11:58 AM, Simon Glass <sjg@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!

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

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

Regards,
Simon

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

[Bin Meng]

Hi Simon,

On Wed, Feb 3, 2016 at 12:31 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 2 February 2016 at 08:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Albert,
>>
>> On Tue, Feb 2, 2016 at 5:53 PM, Albert ARIBAUD
>> <albert.u.boot@aribaud.net> wrote:
>>> Hello Bin and Simon,
>>>
>>> On Tue, 2 Feb 2016 15:25:48 +0800, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Tue, Feb 2, 2016 at 11:58 AM, Simon Glass <sjg@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

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

[Tom Rini]

On Wed, Feb 03, 2016 at 12:42:44PM +0800, Bin Meng wrote:
> Hi Simon,
> 
> On Wed, Feb 3, 2016 at 12:31 PM, Simon Glass <sjg@chromium.org> wrote:
> > Hi Bin,
> >
> > On 2 February 2016 at 08:02, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> Hi Albert,
> >>
> >> On Tue, Feb 2, 2016 at 5:53 PM, Albert ARIBAUD
> >> <albert.u.boot@aribaud.net> wrote:
> >>> Hello Bin and Simon,
> >>>
> >>> On Tue, 2 Feb 2016 15:25:48 +0800, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>> Hi Simon,
> >>>>
> >>>> On Tue, Feb 2, 2016 at 11:58 AM, Simon Glass <sjg@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.

Well, how much are distros going to dislike having to provide 32bit EFI
grub, for the x86 case here?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160204/5161114d/attachment.sig>

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

[Bin Meng]

On Fri, Feb 5, 2016 at 1:41 AM, Tom Rini <trini@konsulko.com> wrote:
> On Wed, Feb 03, 2016 at 12:42:44PM +0800, Bin Meng wrote:
>> Hi Simon,
>>
>> On Wed, Feb 3, 2016 at 12:31 PM, Simon Glass <sjg@chromium.org> wrote:
>> > Hi Bin,
>> >
>> > On 2 February 2016 at 08:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >> Hi Albert,
>> >>
>> >> On Tue, Feb 2, 2016 at 5:53 PM, Albert ARIBAUD
>> >> <albert.u.boot@aribaud.net> wrote:
>> >>> Hello Bin and Simon,
>> >>>
>> >>> On Tue, 2 Feb 2016 15:25:48 +0800, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>>> Hi Simon,
>> >>>>
>> >>>> On Tue, Feb 2, 2016 at 11:58 AM, Simon Glass <sjg@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.
>
> Well, how much are distros going to dislike having to provide 32bit EFI
> grub, for the x86 case here?
>

See a blog post "Don't ship 32-bit UEFI firmware on x86" here:
https://mjg59.dreamwidth.org/26734.html

Regards,
Bin