[U-Boot] ARMv7 EFI loader broken?

[Michal Suchanek]

On 17 February 2017 at 11:26, Misha Komarovskiy <zombah at gmail.com> wrote:
> Hello Michal,
>
> On Fri, Feb 17, 2017 at 1:38 AM, Michal Suchanek <hramrach at gmail.com> wrote:
>> On 14 February 2017 at 15:50, Michal Suchanek <hramrach at 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