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

[Leif Lindholm]

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 :)

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

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

Regards,

Leif