[U-Boot] [BUG] Wandboard fails to boot via U-Boot bootefi, GRUB

[Heinrich Schuchardt]

On 7/1/19 9:56 PM, Leif Lindholm wrote:
> Hi,
>
> On Mon, Jul 01, 2019 at 07:19:10PM +0200, Heinrich Schuchardt wrote:
>>> According to this, we have an allocation of somewhat below 8MB, I
>>> assume this matches the size of the initrd?
>>
>> Thanks a lot for taking a look at this.
>>
>> 31516827 bytes actually.
>> 74715648 bytes after unzipping.
>
> Yeah, so probably grub unzips it.
>
>>>
>>>> 00000007, 17f0c000, 17f0c000,            162e5,                8
>>>> 00000004, 17f00000, 17f00000,                c,                8
>>>> 00000002, 17d00000, 17d00000,              200,                8
>>>> 00000007, 1240b000, 1240b000,             58f5,                8
>>>> 00000002, 12000000, 12000000,              40b,                8
>>>> 00000004, 10000000, 10000000,             2000,                8
>>>>
>>>> The initial ramdisk is loaded at 2e1f1000.
>>>>
>>>> The problem occurs in drivers/of/fdt.c where some memory areas including
>>>> the one containig the initial ramdisk are excluded. I have added some
>>>> extra debug lines to early_init_dt_add_memory_arch().
>>>
>>> Do you have a pointer to the device tree sources?
>>> If the DT is explicitly excluding regions not marked such in the UEFI
>>> memory map ... that would cause problems.
>>
>> Please, find appended the device tree passed to U-Boot (dtb) and the
>> printout of the devicetree upon entering SetVirtualAddressMap.
>
> Thank you.
>
> Hmm. Well, my main concern is that we *should* be ignoring whatever is
> in the DT when booting through UEFI (see Linux commit 500899c2cc3e3).
>
> Could you try deleting the "memory" and "memory at 10000000" nodes from
> the DT and see if that changes behaviour? (You probably want to delete
> one of them regardless, since they describe the same region :)

setenv bootargs console=$console earlyprintk
load mmc 2:2 $fdt_addr_r dtb
fdt addr $fdt_addr_r
fdt rm /memory
fdt rm /memory at 10000000
load mmc 2:1 $kernel_addr_r EFI/debian/grubarm.efi
bootefi $kernel_addr_r $fdt_addr_r

leads to the same result.

>
> If that doesn't change anything, how far back would we be able to
> bisect and still be able to boot on this platform?

I do not know if it ever worked for this board. U-Boot v2019.01 fails too.

I have not seen the problem on 32bit Amlogic (OrangePi PC).

>
> Is this a distro kernel? Is the behaviour the same on upstream?

I have used 4.19.55 upstream together with the Debian config file but
with earlyprintk enabled.

Best regards

Heinrich

>
> Regards,
>
> Leif
>