[U-Boot] ARMv7 EFI loader broken?
Hello,
I tired to build u-boot master for Snow board, install grub, chainload grub.
In short, it fails.
First, u-boot searches for EFI loader in ${distro_bootpart} which defaults to unset and is interpreted as 1. grub wants the partition it installs to to have the EFI System GUID. So to boot you need to set the first partition to EFI System GUID and install grub there. Further, grub installs as EFI/debian/grubarm.efi while u-boot searches for /efi/boot/bootarm.efi. This is not even a variable - it's hardcoded in several places in the default efi boot script. Given that saving environment does not work on Snow changing the environment requires rebuild either way. Or change what is on the disk.
Finally, when grub loads I get this:
snow # setenv distro_bootpart 4 snow # boot switch to partitions #0, OK mmc1 is current device Scanning mmc 1:4... Found EFI removebla media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 88576 bytes read in 42 ms (2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 42000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks ←[?25h←[?25l←[?25l
And that is all.
No reaction to keypresses.
Any idea what is wrong in this case? It seems like grub starts and then fails to do whatever it is supposed to do. Is there some special support in grub needed? I would expect that would be against the point of having an EFI emulation, right?
Thanks
Michal
On 14 February 2017 at 15:50, Michal Suchanek hramrach@gmail.com wrote:
Hello,
I tired to build u-boot master for Snow board, install grub, chainload grub.
In short, it fails.
First, u-boot searches for EFI loader in ${distro_bootpart} which defaults to unset and is interpreted as 1. grub wants the partition it installs to to have the EFI System GUID. So to boot you need to set the first partition to EFI System GUID and install grub there. Further, grub installs as EFI/debian/grubarm.efi while u-boot searches for /efi/boot/bootarm.efi. This is not even a variable - it's hardcoded in several places in the default efi boot script. Given that saving environment does not work on Snow changing the environment requires rebuild either way. Or change what is on the disk.
Finally, when grub loads I get this:
snow # setenv distro_bootpart 4 snow # boot switch to partitions #0, OK mmc1 is current device Scanning mmc 1:4... Found EFI removebla media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 88576 bytes read in 42 ms (2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 42000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks ←[?25h←[?25l←[?25l
And that is all.
No reaction to keypresses.
Any idea what is wrong in this case? It seems like grub starts and then fails to do whatever it is supposed to do. Is there some special support in grub needed? I would expect that would be against the point of having an EFI emulation, right?
OK, so I tried to use EFI/opensuse/grubarm.efi instead of EFI/debian/grubarm.efi and now I see that garbage as well as grub welcome header. So I guess the Debian grub uses defaults even less compatible with the u-boot EFI emulation than openSUSE.
Since the Snow board does not have a known serial port and the EFI terminal emulation on efifb is not working with grub I will try to stick to the known working syslinux emulation on Snow.
Best regards
Michal
Hello Michal,
On Fri, Feb 17, 2017 at 1:38 AM, Michal Suchanek hramrach@gmail.com wrote:
On 14 February 2017 at 15:50, Michal Suchanek hramrach@gmail.com wrote:
Hello,
I tired to build u-boot master for Snow board, install grub, chainload grub.
In short, it fails.
First, u-boot searches for EFI loader in ${distro_bootpart} which defaults to unset and is interpreted as 1. grub wants the partition it installs to to have the EFI System GUID. So to boot you need to set the first partition to EFI System GUID and install grub there. Further, grub installs as EFI/debian/grubarm.efi while u-boot searches for /efi/boot/bootarm.efi. This is not even a variable - it's hardcoded in several places in the default efi boot script. Given that saving environment does not work on Snow changing the environment requires rebuild either way. Or change what is on the disk.
Finally, when grub loads I get this:
snow # setenv distro_bootpart 4 snow # boot switch to partitions #0, OK mmc1 is current device Scanning mmc 1:4... Found EFI removebla media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 88576 bytes read in 42 ms (2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 42000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks ←[?25h←[?25l←[?25l
And that is all.
No reaction to keypresses.
Any idea what is wrong in this case? It seems like grub starts and then fails to do whatever it is supposed to do. Is there some special support in grub needed? I would expect that would be against the point of having an EFI emulation, right?
OK, so I tried to use EFI/opensuse/grubarm.efi instead of EFI/debian/grubarm.efi and now I see that garbage as well as grub welcome header. So I guess the Debian grub uses defaults even less compatible with the u-boot EFI emulation than openSUSE.
Since the Snow board does not have a known serial port and the EFI
If you are talking about Chromebook Snow, then it's serial is known but require soldering, described here [1]
- [1] http://www.de7ec7ed.com/2013/05/application-processor-ap-uart-samsung.html?_...
terminal emulation on efifb is not working with grub I will try to stick to the known working syslinux emulation on Snow.
Best regards
Michal _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 17 February 2017 at 11:26, Misha Komarovskiy zombah@gmail.com wrote:
Hello Michal,
On Fri, Feb 17, 2017 at 1:38 AM, Michal Suchanek hramrach@gmail.com wrote:
On 14 February 2017 at 15:50, Michal Suchanek hramrach@gmail.com wrote:
Hello,
I tired to build u-boot master for Snow board, install grub, chainload grub.
In short, it fails.
First, u-boot searches for EFI loader in ${distro_bootpart} which defaults to unset and is interpreted as 1. grub wants the partition it installs to to have the EFI System GUID. So to boot you need to set the first partition to EFI System GUID and install grub there. Further, grub installs as EFI/debian/grubarm.efi while u-boot searches for /efi/boot/bootarm.efi. This is not even a variable - it's hardcoded in several places in the default efi boot script. Given that saving environment does not work on Snow changing the environment requires rebuild either way. Or change what is on the disk.
Finally, when grub loads I get this:
snow # setenv distro_bootpart 4 snow # boot switch to partitions #0, OK mmc1 is current device Scanning mmc 1:4... Found EFI removebla media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 88576 bytes read in 42 ms (2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 42000000 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks ←[?25h←[?25l←[?25l
And that is all.
No reaction to keypresses.
Any idea what is wrong in this case? It seems like grub starts and then fails to do whatever it is supposed to do. Is there some special support in grub needed? I would expect that would be against the point of having an EFI emulation, right?
OK, so I tried to use EFI/opensuse/grubarm.efi instead of EFI/debian/grubarm.efi and now I see that garbage as well as grub welcome header. So I guess the Debian grub uses defaults even less compatible with the u-boot EFI emulation than openSUSE.
And it turns out the difference is Debian creates a grub config file for you automagically while on SUSE you have to create it by hand. Once created the grub config file loads a bunch of graphics modules which breaks video output for grub. Not loading them makes grub somewhat work (with garbage among text) but breaks video for Linux. It just says "Video support broken" and blanks the screen, eventually rebooting.
There is also some problem loading the DT given the message FDT_ERR_BADMAGIC.
Or maybe there is not. It does not really say what it's doing. I guess I will try adding some debug prints in the distro bootcmd.
If you are talking about Chromebook Snow, then it's serial is known but require soldering, described here [1]
Thanks for the link. This looks useful.
Michal
participants (2)
-
Michal Suchanek -
Misha Komarovskiy