On Fri, Feb 5, 2016 at 1:41 AM, Tom Rini <[email protected]> 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 <[email protected]> wrote: >> > Hi Bin, >> > >> > On 2 February 2016 at 08:02, Bin Meng <[email protected]> wrote: >> >> Hi Albert, >> >> >> >> On Tue, Feb 2, 2016 at 5:53 PM, Albert ARIBAUD >> >> <[email protected]> wrote: >> >>> Hello Bin and Simon, >> >>> >> >>> On Tue, 2 Feb 2016 15:25:48 +0800, Bin Meng <[email protected]> wrote: >> >>>> Hi Simon, >> >>>> >> >>>> On Tue, Feb 2, 2016 at 11:58 AM, Simon Glass <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
