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