Date: Mon, 12 Oct 2020 01:30:24 -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: <AFBB184A-2378-42F9-9A02-0C721F921AE5@yahoo.com> In-Reply-To: <7052E5C0-0228-4838-A072-AF689C377337@yahoo.com> References: <09E20B0B-3D90-409B-9994-02A56F86FF5E@yahoo.com> <7052E5C0-0228-4838-A072-AF689C377337@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AFBB184A-2378-42F9-9A02-0C721F921AE5>