Hi,
I verified that RPI4 can boot Ubuntu and LEDGE RP with UEFI + U-Boot. Two flows have been checked: direct (kernel+initrd in BootXXX variable leveraging LOAD_FILE2 mechanism) and through grub.
Note: Grub (current head) behaves properly but does not display anything on serial console because lack of U-Boot (2021.07-rc2) support for:
GRUB_EFI_SERIAL_IO_GUID \
{ 0xbb25cf6f, 0xf1d4, 0x11d2, \
{ 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0xfd } \
}
/* details: grub-core/term/efi/serial.c, grub_efiserial_init() -> grub_efi_locate_handle (GRUB_EFI_BY_PROTOCOL, &serial_io_guid,...) returns NULL */
So I think we need to add this protocol and some others to make the UEFI text environment fully supported for grub.
Cheers
FF
PS: It would be nice to have an efidebug command to actually trace all boot services calls to "get_protocol" and either trace all requests or just failed requests.
WRT RPI and Uboot.
Ubuntu 20.04 used U-boot on RPI. Ubuntu 20.10 eliminates it to rely directly on the RPI firmware model so USB and ENET boot work.
This is not a good tread direction for our story. (I have not checked 21.04.)
Bill
On 5/24/21 1:42 PM, François Ozog wrote:
Hi,
I verified that RPI4 can boot Ubuntu and LEDGE RP with UEFI + U-Boot. Two flows have been checked: direct (kernel+initrd in BootXXX variable leveraging LOAD_FILE2 mechanism) and through grub.
Note: Grub (current head) behaves properly but does not display anything on serial console because lack of U-Boot (2021.07-rc2) support for:
GRUB_EFI_SERIAL_IO_GUID \
{ 0xbb25cf6f, 0xf1d4, 0x11d2, \
{ 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0xfd } \}
/* details: grub-core/term/efi/serial.c, grub_efiserial_init() -> grub_efi_locate_handle (GRUB_EFI_BY_PROTOCOL, &serial_io_guid,...) returns NULL */
So I think we need to add this protocol and some others to make the UEFI text environment fully supported for grub.
Cheers
FF
PS: It would be nice to have an efidebug command to actually trace all boot services calls to "get_protocol" and either trace all requests or just failed requests.
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 5/24/21 1:42 PM, François Ozog wrote:
PS: It would be nice to have an efidebug command to actually trace all boot services calls to "get_protocol" and either trace all requests or just failed requests.
Yes that does sound like a good thing to have.
Bill
On Tue, May 25, 2021 at 08:00:16PM -0400, Bill Mills wrote:
On 5/24/21 1:42 PM, François Ozog wrote:
PS: It would be nice to have an efidebug command to actually trace all boot services calls to "get_protocol" and either trace all requests or just failed requests.
Yes that does sound like a good thing to have.
Alternatively, you can do the tracing by adding "#define DEBUG" in efi_boottime.c. (no way to selectively trace calls, though.)
-Takahiro Akashi
Bill
-- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Le mer. 26 mai 2021 à 02:50, AKASHI Takahiro takahiro.akashi@linaro.org a écrit :
On Tue, May 25, 2021 at 08:00:16PM -0400, Bill Mills wrote:
On 5/24/21 1:42 PM, François Ozog wrote:
PS: It would be nice to have an efidebug command to actually trace all
boot
services calls to "get_protocol" and either trace all requests or just failed requests.
Yes that does sound like a good thing to have.
Alternatively, you can do the tracing by adding "#define DEBUG" in efi_boottime.c. (no way to selectively trace calls, though.)
that sounds just perfect.
-Takahiro Akashi
Bill
-- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 24/05/2021 18:42, François Ozog wrote:
Hi,
I verified that RPI4 can boot Ubuntu and LEDGE RP with UEFI + U-Boot. Two flows have been checked: direct (kernel+initrd in BootXXX variable leveraging LOAD_FILE2 mechanism) and through grub.
Note: Grub (current head) behaves properly but does not display anything on serial console because lack of U-Boot (2021.07-rc2) support for:
GRUB_EFI_SERIAL_IO_GUID \
{ 0xbb25cf6f, 0xf1d4, 0x11d2, \
{ 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0xfd } \}
/* details: grub-core/term/efi/serial.c, grub_efiserial_init() -> grub_efi_locate_handle (GRUB_EFI_BY_PROTOCOL, &serial_io_guid,...) returns NULL */
This doesn't look right to me. U-Boot provides the SimpleTextProtocol which Grub can use to display the menu over either UART or framebuffer. The SERIAL_IO protocol is not required. If you aren't getting output on the serial console then it is more likely a U-Boot configuration problem rather than missing functionality.
g.
So I think we need to add this protocol and some others to make the UEFI text environment fully supported for grub.
Cheers
FF
PS: It would be nice to have an efidebug command to actually trace all boot services calls to "get_protocol" and either trace all requests or just failed requests.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Le jeu. 27 mai 2021 à 18:24, Grant Likely grant.likely@arm.com a écrit :
On 24/05/2021 18:42, François Ozog wrote:
Hi,
I verified that RPI4 can boot Ubuntu and LEDGE RP with UEFI + U-Boot. Two flows have been checked: direct (kernel+initrd in BootXXX variable leveraging LOAD_FILE2 mechanism) and through grub.
Note: Grub (current head) behaves properly but does not display anything
on
serial console because lack of U-Boot (2021.07-rc2) support for:
GRUB_EFI_SERIAL_IO_GUID \
{ 0xbb25cf6f, 0xf1d4, 0x11d2, \
{ 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0xfd } \}
/* details: grub-core/term/efi/serial.c, grub_efiserial_init() -> grub_efi_locate_handle (GRUB_EFI_BY_PROTOCOL, &serial_io_guid,...) returns NULL */
This doesn't look right to me. U-Boot provides the SimpleTextProtocol which Grub can use to display the menu over either UART or framebuffer. The SERIAL_IO protocol is not required. If you aren't getting output on the serial console then it is more likely a U-Boot configuration problem rather than missing functionality.
the rescue mode works nicely. The menu display does not. Is it because I am using Grub head ?
g.
So I think we need to add this protocol and some others to make the UEFI text environment fully supported for grub.
Cheers
FF
PS: It would be nice to have an efidebug command to actually trace all
boot
services calls to "get_protocol" and either trace all requests or just failed requests.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 5/27/21 6:29 PM, François Ozog wrote:
Le jeu. 27 mai 2021 à 18:24, Grant Likely grant.likely@arm.com a écrit :
On 24/05/2021 18:42, François Ozog wrote:
Hi,
I verified that RPI4 can boot Ubuntu and LEDGE RP with UEFI + U-Boot. Two flows have been checked: direct (kernel+initrd in BootXXX variable leveraging LOAD_FILE2 mechanism) and through grub.
Note: Grub (current head) behaves properly but does not display anything
on
serial console because lack of U-Boot (2021.07-rc2) support for:
GRUB_EFI_SERIAL_IO_GUID \ { 0xbb25cf6f, 0xf1d4, 0x11d2, \ { 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0xfd } \ }/* details: grub-core/term/efi/serial.c, grub_efiserial_init() -> grub_efi_locate_handle (GRUB_EFI_BY_PROTOCOL, &serial_io_guid,...) returns NULL */
This doesn't look right to me. U-Boot provides the SimpleTextProtocol which Grub can use to display the menu over either UART or framebuffer. The SERIAL_IO protocol is not required. If you aren't getting output on the serial console then it is more likely a U-Boot configuration problem rather than missing functionality.
the rescue mode works nicely. The menu display does not. Is it because I am using Grub head ?
Hello Grant,
by default GRUB uses video output if you have a graphical output protocol. You have to set GRUB_TERMINAL=console if you want to use the simple text protocol on systems with graphical output protocol.
On Debian/Ubuntu you can make the setting in /etc/default/grub and the run update-grub.
Best regards
Heinrich
g.
So I think we need to add this protocol and some others to make the UEFI text environment fully supported for grub.
Cheers
FF
PS: It would be nice to have an efidebug command to actually trace all
boot
services calls to "get_protocol" and either trace all requests or just failed requests.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
boot-architecture@lists.linaro.org
-
AKASHI Takahiro -
Bill Mills -
François Ozog -
Grant Likely -
Heinrich Schuchardt