RPi4B: u-boot printenv shows: fdt_addr=4000 (input to u-boot) vs. fdt_addr_r=0x02600000 (output from u-boot): 4000 is used by FreeBSD?

Mark Millard marklmi at yahoo.com
Mon Oct 12 07:41:14 UTC 2020


The fdt_addr=4000 is from:

MESS:00:00:06.171732:0: dtb_file 'bcm2711-rpi-4-b.dtb'
MESS:00:00:06.173753:0: Trying Device Tree file 'bcm2711-rpi-4-b.dtb'
MESS:00:00:06.186642:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb

The fdt_addr_r=0x02600000 is from u-boot doing its own modifications
to a copy it makes.

But that is not what the debug output indicates is being used after
u-boot produces its "output" fdt:

MESS:00:00:09.631802:0: brfs: File read: /mfs/sd/armstub8-gic.bin
MESS:00:00:09.634830:0: Loading 'armstub8-gic.bin' to 0x0 size 0x1700
MESS:00:00:09.641023:0: brfs: File read: 5888 bytes
MESS:00:00:09.762872:0: brfs: File read: /mfs/sd/u-boot.bin
MESS:00:00:09.765376:0: Loading 'u-boot.bin' to 0x80000 size 0x8b9c0
MESS:00:00:09.771462:0: Device tree loaded to 0x4000 (size 0xbe0c)

The following points out that the reporting 0x4000 just above is
odd. Other contexts are reporting addresses closer to what
fdt_addr_r has above (0x02600000) after u-boot.bin load (and based
on the default 0x100 for the input to u-boot).


For operating systems contexts where device_tree_address is not forced
(and no armstub8*.bin is in use), I've noted that the debug messages
track this sort of staging and use the u-boot output:

MESS:00:00:08.861956:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
MESS:00:00:08.865197:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x100 size 0xb99c
. . .
MESS:00:00:10.443307:0: Loading 'rpi4-u-boot.bin' to 0x80000 size 0x8bb60
MESS:00:00:10.449832:0: Device tree loaded to 0x2eff4000 (size 0xbf18)

That example is from the Fedora 33 branch, recently enough to be
using u-boot 2020.10 .

RaspiOS64 (debian variant) does the same sort of thing:

MESS:00:00:06.029224:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
MESS:00:00:06.032473:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x100 size 0xb99c
. . .
MESS:00:00:08.552427:0: brfs: File read: /mfs/sd/kernel8.img
MESS:00:00:08.554979:0: Loading 'kernel8.img' to 0x80000 size 0xee6200
MESS:00:00:08.561240:0: Device tree loaded to 0x2eff4100 (size 0xbea2)

(Note the lack of an explicit u-boot. This might be a u-boot
"Falcon-Mode" context for all I know.)

Ubuntu 2020.04.1 LTS is older and uses an older u-boot and older
firmware but also reports an address similar to the prior two
examples:

## Flattened Device Tree blob at 02600000
   Booting using the fdt blob at 0x2600000
   Using Device Tree in place at 0000000002600000, end 000000000260ea4f

(The older firmware does not have the same debug output.)


FreeBSD seems to be the odd one out for what fdt address it is likely
given.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)



More information about the freebsd-arm mailing list