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?

On 2020-Oct-12, at 00:41, Mark Millard <[email protected]> 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)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"