+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