Date: Mon, 12 Oct 2020 00:41:04 -0700 From: Mark Millard <marklmi@yahoo.com> To: Robert Crowston <crowston@protonmail.com>, Oleksandr Tymoshenko <gonzo@freebsd.org>, Kyle Evans <kevans@FreeBSD.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: 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? Message-ID: <09E20B0B-3D90-409B-9994-02A56F86FF5E@yahoo.com> References: <09E20B0B-3D90-409B-9994-02A56F86FF5E.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?09E20B0B-3D90-409B-9994-02A56F86FF5E>