[U-Boot] 64-bit x86 U-Boot?
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
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,
+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
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
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,
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
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
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
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?
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
participants (4)
-
Albert ARIBAUD -
Bin Meng -
Simon Glass -
Tom Rini