Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed

[Karsten Merker <merker@debian.org>]

Control: found -1 2023.01+dfsg-1
X-Debbugs-CC: debian-riscv@lists.debian.org

On Tue, Jan 10, 2023 at 09:23:04AM -0800 Vagrant Cascadian wrote:
> On 2023-01-10, Cheng Li wrote:
[...]
> > Moving Image from 0x84000000 to 0x80200000, end=815d8000
> > ## Flattened Device Tree blob at ff733ef0
> >     Booting using the fdt blob at 0xff733ef0
> > Working FDT set to ff733ef0
> >     Using Device Tree in place at 00000000ff733ef0, end 00000000ff738dd2
> > Working FDT set to ff733ef0
> > ERROR: fdt fixup event failed: -22
> >   - must RESET the board to recover.
> >
> > FDT creation failed! hanging...### ERROR ### Please RESET the board ###
> 
> I wonder if this is relevent?
> 
>   docs/firmware: Update FW_JUMP documentation
>   https://github.com/riscv-software-src/opensbi/commit/7105c189f67028ef73720d7e9816c800ab53dda5
> 
> Basically changing the address offsets to avoid clobbering one another...

Hello,

some clobbering could indeed be the source of the problem, though
I currently fail to see why that would happen.  When running the
objdump dance on the working u-boot 2022.10, this gives me the
following address blocks:

0x802001a4
0x80200e60
0x80259bbc
0x80275a38
0x802769d1
0x802770c8
0x802778b8
0x80283d60
0x80283e70
0x80284628
0x80287f88
0x80288138
0x8029c2b0
0x8029d9a8
0x802a8008

On the non-working u-boot 2023.01 that is in unstable since today
this gives me

0x802001a4
0x80200e70
0x8025a604
0x802762f4
0x802772e8
0x802779ec
0x802781f4
0x802847a8
0x802848b8
0x80285098
0x80288a08
0x80288bb8
0x8029cf40
0x8029e6b0
0x802a8d08

i.e. the used area is a little bit larger in the non-working case, but still
way below one MB.  On the other hand OpenSBI's ./platform/generic/config.mk
contains

  FW_JUMP_FDT_ADDR=$(shell printf "0x%X" $$(($(FW_TEXT_START) + 0x2200000)))

i.e. AIUI it reserves an area of 0x2200000 bytes (34MB) for it's payload, so
there should be plenty of space and no clobbering should occur.


I've also taken a look at the u-boot changelogs and there have
been quite a few changes concerning u-boot's handling of
device-trees between the working and the non-working versions. 
Unfortunately I'm not familiar enough with the inner workings of
u-boot to understand the implications of several of these
changes.

Regards,
Karsten
-- 
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.