* [U-Boot] 64-bit x86 U-Boot? @ 2016-02-01 2:20 Simon Glass 2016-02-01 7:14 ` Albert ARIBAUD 0 siblings, 1 reply; 10+ messages in thread From: Simon Glass @ 2016-02-01 2:20 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] 64-bit x86 U-Boot? 2016-02-01 2:20 [U-Boot] 64-bit x86 U-Boot? Simon Glass @ 2016-02-01 7:14 ` Albert ARIBAUD 2016-02-02 3:58 ` Simon Glass 0 siblings, 1 reply; 10+ messages in thread From: Albert ARIBAUD @ 2016-02-01 7:14 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] 64-bit x86 U-Boot? 2016-02-01 7:14 ` Albert ARIBAUD @ 2016-02-02 3:58 ` Simon Glass 2016-02-02 7:25 ` Bin Meng 0 siblings, 1 reply; 10+ messages in thread From: Simon Glass @ 2016-02-02 3:58 UTC (permalink / raw) To: u-boot +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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] 64-bit x86 U-Boot? 2016-02-02 3:58 ` Simon Glass @ 2016-02-02 7:25 ` Bin Meng 2016-02-02 9:53 ` Albert ARIBAUD 0 siblings, 1 reply; 10+ messages in thread From: Bin Meng @ 2016-02-02 7:25 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] 64-bit x86 U-Boot? 2016-02-02 7:25 ` Bin Meng @ 2016-02-02 9:53 ` Albert ARIBAUD 2016-02-02 15:02 ` Bin Meng 0 siblings, 1 reply; 10+ messages in thread From: Albert ARIBAUD @ 2016-02-02 9:53 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] 64-bit x86 U-Boot? 2016-02-02 9:53 ` Albert ARIBAUD @ 2016-02-02 15:02 ` Bin Meng 2016-02-03 4:31 ` Simon Glass 0 siblings, 1 reply; 10+ messages in thread From: Bin Meng @ 2016-02-02 15:02 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] 64-bit x86 U-Boot? 2016-02-02 15:02 ` Bin Meng @ 2016-02-03 4:31 ` Simon Glass 2016-02-03 4:42 ` Bin Meng 0 siblings, 1 reply; 10+ messages in thread From: Simon Glass @ 2016-02-03 4:31 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] 64-bit x86 U-Boot? 2016-02-03 4:31 ` Simon Glass @ 2016-02-03 4:42 ` Bin Meng 2016-02-04 17:41 ` Tom Rini 0 siblings, 1 reply; 10+ messages in thread From: Bin Meng @ 2016-02-03 4:42 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] 64-bit x86 U-Boot? 2016-02-03 4:42 ` Bin Meng @ 2016-02-04 17:41 ` Tom Rini 2016-02-05 5:41 ` Bin Meng 0 siblings, 1 reply; 10+ messages in thread From: Tom Rini @ 2016-02-04 17:41 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] 64-bit x86 U-Boot? 2016-02-04 17:41 ` Tom Rini @ 2016-02-05 5:41 ` Bin Meng 0 siblings, 0 replies; 10+ messages in thread From: Bin Meng @ 2016-02-05 5:41 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-02-05 5:41 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-02-01 2:20 [U-Boot] 64-bit x86 U-Boot? Simon Glass 2016-02-01 7:14 ` Albert ARIBAUD 2016-02-02 3:58 ` Simon Glass 2016-02-02 7:25 ` Bin Meng 2016-02-02 9:53 ` Albert ARIBAUD 2016-02-02 15:02 ` Bin Meng 2016-02-03 4:31 ` Simon Glass 2016-02-03 4:42 ` Bin Meng 2016-02-04 17:41 ` Tom Rini 2016-02-05 5:41 ` Bin Meng
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox