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?
* If not, what are the needed steps in order to enable it?
Thanks, Haim ________________________________ Haim Boot, Marvell Israel - SW Engineer 6 Hamada Street Mordot HaCarmel Industrial Park Yokneam, 20692, Israel Email: hayim@marvell.commailto:hayim@marvell.com Office: +972.4.9091520 - OnNet: 704.1520 Fax: +972.4.9091501 Web site: http://www.marvell.comhttp://www.marvell.com/
This message may contain confidential, proprietary or legally privileged information. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone or by e-mail and delete the message from your computer. ________________________________
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.
· 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/hea...
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.
-----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
· 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 ?
Best Regards
Yehuda
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,
Hi Ard
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Sunday, May 08, 2016 20:24 To: Yehuda Yitschak Cc: Haim Boot; linaro-uefi@lists.linaro.org; Leif Lindholm; Marcin Wojtas (mw@semihalf.com) Subject: Re: BE Support in Linux Kernel
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.
Actually, I meant "x86 system which use UEFI as a simple bootloader", not necessarily booting BE kernels. I guess the BE requirement came from shifting to an ARM SOC.
· 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
Thanks for the clarification. That's good news :)
Best Regards
Yehuda
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,
-
Ard Biesheuvel -
Haim Boot -
Yehuda Yitschak