On 8 May 2016 at 16:23, Yehuda Yitschak yehuday@marvell.com wrote:
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Sunday, May 08, 2016 14:23 To: Haim Boot Cc: linaro-uefi@lists.linaro.org; Leif Lindholm; Yehuda Yitschak; Marcin Wojtas (mw@semihalf.com) Subject: Re: BE Support in Linux Kernel
On 8 May 2016 at 10:55, Haim Boot hayim@marvell.com wrote:
Hi
I’m trying to book BE image from UEFI. I got the following error message:
“Command Error Status: Unsupported”
We’ve noticed that the EFI header is wrong (no 0x5A4D signature and the rest of the stuff).
This is cause since when EFI config is not enabled when CPU_BIG_ENDIAN is configured.
· Is there a pending patch which enables EFI when Big endian is configured? Are there any plans for that?
There have been some discussions, but no concrete plans to support this. UEFI is little endian by specification, and the UEFI runtime services remain available to the OS after boot. This means we need to switch endianness in EL1, which is non-trivial (since all the runtime services arguments in memory need to be endian-swapped) and fragile (since the exception vector table is not set up to deal with foreign endianness)
This means that UEFI will be merely a bootloader rather than a full firmware interface when running under BE, and so the use of UEFI does not necessarily make a lot of sense.
I agree it doesn’t makes since, but still there are some x86 based systems out there which use UEFI solely as a bootloader. So to allow them to move to ARM easily, we would like to support BE Linux boot as well
I suppose you meant something other than x86, since x86 is LE only. But running a BE OS on hardware that supports it is not unreasonable, and it is unfortunate that UEFI is standing in your way here.
· If not, what are the needed steps in order to enable it?
I did some preliminary work in the past to enable this https://git.linaro.org/people/ard.biesheuvel/linux- arm.git/shortlog/refs/heads/arm64-efi-be
This is unlikely to make it upstream, since it also requires part of the kernel (the UEFI stub) to be built in LE mode, while the rest of the kernel is in BE mode, so the refactoring of the makefiles and the reshuffling of the code is fairly complicated as well.
The best approach would be to rewrite the stub as a separate EFI application, which implements the same handover protocol as the UEFI stub in the kernel does (i.e., pass the memory map and system table addresses in the DT /chosen node). We would still need some code changes in the core kernel to deal with firmware tables that are little endian, but that would be something we could upstream.
Assuming you have a dedicated bootloader running on top of EDK2, would it be possible to do these stuff there ?
Yes, that is basically what I meant. Instead of booting the kernel directly from UEFI or via GRUB, you would boot it via a special loader that can boot BE kernels. This is actually on my list, but I haven't gotten around to that. Let's call it 'sastub' (for standalone stub), and your command line in UEFI could simply be something like
sastub Image console=xxxx root=yyy
and the sastub UEFI app would hand over to the core kernel in the same way as the builtin stub does i.e., loading the memory map and populating the /chosen node in the DT table. The core kernel would still require EFI support, but not EFI stub support. Hence the need to update some UEFI code in the kernel to deal with firmware tables in the wrong byte order. But the entire kernel would be the same endianness, no reason to combine LE and BE objects (which the linker really does not like)
Ideally, we would simply reuse the in-kernel source to generate this stub, and build it against GNU-EFI. As I said, this is on my list, but not anywhere near the top.
Thanks, Ard,