Date: Mon, 12 Oct 2020 01:05:16 -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: Re: 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: <7052E5C0-0228-4838-A072-AF689C377337@yahoo.com> In-Reply-To: <09E20B0B-3D90-409B-9994-02A56F86FF5E@yahoo.com> References: <09E20B0B-3D90-409B-9994-02A56F86FF5E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Oct-12, at 00:41, Mark Millard <marklmi@yahoo.com> wrote: > 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. Well, I decided was going to fdt print / for fdt_addr vs. fdt_addr_r but got the following from the fdt addr commands: U-Boot> fdt addr 0x02600000 libfdt fdt_check_header(): FDT_ERR_BADMAGIC U-Boot> fdt addr 4000 U-Boot> where the earlier printenv showed: fdt_addr=4000 fdt_addr_r=0x02600000 So, may be it is the 0x02600000 figure itself that is what is wrong and the content for 4000 has the u-boot output? (I'm unsure.) === 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?7052E5C0-0228-4838-A072-AF689C377337>