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]

On 2020-Oct-12, at 01:05, Mark Millard <marklmi at yahoo.com> wrote:

> On 2020-Oct-12, at 00:41, Mark Millard <marklmi at 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.)


Even more "which one" complications: typing boot resulted in:

. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x7ef1000.

So, yet a 3rd address. Rebooting and stopping in u-boot again,
0x4000 and 0x7ef1000 have good magic number status, unlike
0x02600000.

Turns out the differences in the fdt print / output are
not man . . .

0x7ef1000 had a few more lines:

        framebuffer at 3e3cf000 {
                format = "a8r8g8b8";
                stride = <0x00001e00>;
                height = <0x00000438>;
                width = <0x00000780>;
                reg = <0x00000000 0x3e3cf000 0x007e9000>;
                compatible = "simple-framebuffer";
                status = "okay";
        };

0x7ef1000 vs. 0x4000 had:

                kaslr-seed = <0x1d98ffaa 0xdd0919a9>;
vs.
                kaslr-seed = <0x076f7ceb 0x10310a1f>;

The rest was a match.



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