RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?

Sun Oct 11 09:39:19 UTC 2020

> My memory is that armstub8-gic.bin currently requires the
> 0x4000 for the start of the device tree.

In our patched version of armstub8-gic, we attempt to modify the device tree at runtime to add PSCI nodes (see https://github.com/gonzoua/rpi3-psci-monitor/blob/master/fdtpatch.c#L133). That C function is called from assembly. The only reference I can see to 0x4000 is that we use it for the top of the stack when we execute that C function (https://github.com/gonzoua/rpi3-psci-monitor/blob/master/pscimon.S#L172). In this case, the value is arbitrary, it just needs to be unused memory.

We also pass 0x4000 as the second argument to the bootloader, but I do not know what it does with it.

— RHC.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 10 October 2020 07:53, Mark Millard <marklmi at yahoo.com> wrote:

> My evidence that suggests the possibility or likelyhood is . . .
>
> In a dies-rather-early modern-firmware boot context (even without
> USB involved!) I see the following sorts of notices in the debug
> output during very early RPi firmware activity:
>
> Read config.txt bytes 258 hnd 0x0000cfd2 hash '4f21032d556a3fd9'
> recover4.elf not found (6)
> recovery.elf not found (6)
> Read start4.elf bytes 2283936 hnd 0x0000d88c hash 'ddddf81164f250ad'
> Read fixup4.dat bytes 5422 hnd 0x0000e149 hash 'fdfbb390f4a2c93c'
>
> Note the "hnd" values. I presume those are memory locations
> identifying memory that is then holding some value(s) (that
> look to be of fairly long term utility). But I do not know
> for sure.
>
> Somewhat later:
>
> MESS:00:00:06.001798:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
> MESS:00:00:06.005041:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x4000 size 0xb99c
> . . .
> MESS:00:00:07.226859:0: brfs: File read: /mfs/sd/armstub8-gic.bin
> MESS:00:00:07.229885:0: Loading 'armstub8-gic.bin' to 0x0 size 0x1700
> MESS:00:00:07.236077:0: brfs: File read: 5888 bytes
> MESS:00:00:07.354201:0: brfs: File read: /mfs/sd/u-boot.bin
> MESS:00:00:07.356719:0: Loading 'u-boot.bin' to 0x80000 size 0x8b9c0
> MESS:00:00:07.362807:0: Device tree loaded to 0x4000 (size 0xbe0c)
>
> (I did not show re-reading config.txt, some HDMI notices,
> loading of overlays, or the attempted open of the
> non-existent cmdline.txt .)
>
> So:
>
> 0x4000 up to 0xF99c (which contains 0xcfd2, 0xd88c, and 0xe149)
> (Even before armstub8-gic.bin is loaded.)
>
> 0x4000 up to 0xFE0C (which contains 0xcfd2, 0xd88c, and 0xe149)
> (After armstub8-gic.bin and u-boot.bin have been loaded.)
>
> Only a few more lines are output before things are hung up:
>
> MESS:00:00:07.368908:0: uart: Set PL011 baud rate to 103448.300000 Hz
> MESS:00:00:07.377816:0: uart: Baud rate change done...
> MESS:00:00:07.379870:0: uart: Baud rate change done...
> MESS:00:00:07.385266:0: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
>
> (Note: Even a working boot for a microsd-card-only context
> using older firmware gets the above set of 4 messages --but
> keeps going.)
>
> (The re-reads of config.txt may mean that the initial/only
> hnd listed for it no longer matters.)
>
> I see the same sort of hangup with modern firmware when a USB3
> SSD is in use instead of a microsd card:
>
> Read config.txt bytes 258 hnd 0x000080ec hash '241c057b26cdfc4e'
> recover4.elf not found (6)
> recovery.elf not found (6)
> Read start4.elf bytes 2277248 hnd 0x00003df5 hash '8e98b15f075142da'
> Read fixup4.dat bytes 5409 hnd 0x00003519 hash 'bdc1f053a4ad68f8'
>
> vs.
>
> MESS:00:00:06.184750:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x4000 size 0xb99c
> . . .
> MESS:00:00:09.317648:0: Device tree loaded to 0x4000 (size 0xbe0c)
>
> Again the "hnd" point inside the area that later holds the Device Tree.
>
> Again:
>
> MESS:00:00:09.323596:0: uart: Set PL011 baud rate to 103448.300000 Hz
> MESS:00:00:09.332661:0: uart: Baud rate change done...
> MESS:00:00:09.334714:0: uart: Baud rate change done...
> MESS:00:00:09.340188:0: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
>
> (Yep: looks basically the same as before.)
>
> In a working modern-firmware-in-use context (uefi/ACPI via USB3
> SSD example), I see the following in the debug output during a
> boot with modern firmware. Again note the "hnd" values vs. the
> Device Tree memory.
>
> Read config.txt bytes 257 hnd 0x00000014 hash '149443376548b81e'
> recover4.elf not found (6)
> recovery.elf not found (6)
> Read start4.elf bytes 2283936 hnd 0x000007e2 hash 'ddddf81164f250ad'
> Read fixup4.dat bytes 5422 hnd 0x000008fa hash 'fdfbb390f4a2c93c'
>
> MESS:00:00:07.259636:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x1f0000 size 0xb99c
> . . .
> MESS:00:00:08.268417:0: brfs: File read: /mfs/sd/RPI_EFI.fd
> MESS:00:00:08.270883:0: Loading 'RPI_EFI.fd' to 0x0 size 0x1f0000
> MESS:00:00:08.276708:0: No compatible kernel found
> MESS:00:00:08.281210:0: Device tree loaded to 0x1f0000 (size 0xbd90)
>
> There is no overlap between the later Device Tree area and the
> hnd values.
>
> There is an overlap between where RPI_EFI.fd is loaded and the
> hnd values, but just at this later time frame, where the
> overlaps might be less likely to matter.
>
> So far, I've not observed problems for this. It might suggest that
> my hnd hypothesis is wrong. Or that it is late enough that the
> overlaps do not matter any more.
>
> The messages continue in this case:
>
> MESS:00:00:08.287327:0: uart: Set PL011 baud rate to 103448.300000 Hz
> MESS:00:00:08.296362:0: uart: Baud rate change done...
> MESS:00:00:08.298385:0: uart: Baud rate change done...
> MESS:00:00:08.303463:0: bfs_xhci_stop
> MESS:00:00:08.306631:0: XHCI-STOP
> MESS:00:00:08.311953:0: xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
> NOTICE: BL31: v2.3():v2.3
> NOTICE: BL31: Built : 10:40:51, Apr 21 2020
> UEFI firmware (version UEFI Firmware v1.20 built at 14:10:14 on Sep 1 2020)
> . . . .
>
> My memory is that armstub8-gic.bin currently requires the
> 0x4000 for the start of the device tree.
>
> If the above turns out to be right, then it is likely
> that older firmware also got overlaps with the hnd values
> but happened to not fail for some not-always-guaranteed
> reason. This is probably the strongest point against my
> hypothesis.
>
>
> ========================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
>
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)