[U-Boot] ARMv7 EFI loader broken?

[U-Boot] ARMv7 EFI loader broken?

[Michal Suchanek]

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

[U-Boot] ARMv7 EFI loader broken?

[Michal Suchanek]

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

[U-Boot] ARMv7 EFI loader broken?

[Misha Komarovskiy]

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?_escaped_fragment_=#!

> 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Best Regards,
Misha Komarovskiy
zombahatgmaildotcom

[U-Boot] ARMv7 EFI loader broken?

[Michal Suchanek]

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]
>
> - [1] http://www.de7ec7ed.com/2013/05/application-processor-ap-uart-samsung.html?_escaped_fragment_=#!

Thanks for the link. This looks useful.

Michal