Date: Fri, 9 Oct 2020 23:53:57 -0700 From: Mark Millard <marklmi@yahoo.com> To: Kyle Evans <kevans@FreeBSD.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]? Message-ID: <2B1B21CB-1A63-42CE-8917-98870C88CACE@yahoo.com> References: <2B1B21CB-1A63-42CE-8917-98870C88CACE.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
My evidence that suggests the possibility or likelyhood is . . . In a dies-rather-early modern-firmware boot context (even without USB involved!) I see the following sorts of notices in the debug output during very early RPi firmware activity: Read config.txt bytes 258 hnd 0x0000cfd2 hash '4f21032d556a3fd9' recover4.elf not found (6) recovery.elf not found (6) Read start4.elf bytes 2283936 hnd 0x0000d88c hash 'ddddf81164f250ad' Read fixup4.dat bytes 5422 hnd 0x0000e149 hash 'fdfbb390f4a2c93c' Note the "hnd" values. I presume those are memory locations identifying memory that is then holding some value(s) (that look to be of fairly long term utility). But I do not know for sure. Somewhat later: MESS:00:00:06.001798:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb MESS:00:00:06.005041:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x4000 size = 0xb99c . . . MESS:00:00:07.226859:0: brfs: File read: /mfs/sd/armstub8-gic.bin MESS:00:00:07.229885:0: Loading 'armstub8-gic.bin' to 0x0 size 0x1700 MESS:00:00:07.236077:0: brfs: File read: 5888 bytes MESS:00:00:07.354201:0: brfs: File read: /mfs/sd/u-boot.bin MESS:00:00:07.356719:0: Loading 'u-boot.bin' to 0x80000 size 0x8b9c0 MESS:00:00:07.362807:0: Device tree loaded to 0x4000 (size 0xbe0c) (I did not show re-reading config.txt, some HDMI notices, loading of overlays, or the attempted open of the non-existent cmdline.txt .) So: 0x4000 up to 0xF99c (which contains 0xcfd2, 0xd88c, and 0xe149) (Even before armstub8-gic.bin is loaded.) 0x4000 up to 0xFE0C (which contains 0xcfd2, 0xd88c, and 0xe149) (After armstub8-gic.bin and u-boot.bin have been loaded.) Only a few more lines are output before things are hung up: MESS:00:00:07.368908:0: uart: Set PL011 baud rate to 103448.300000 Hz MESS:00:00:07.377816:0: uart: Baud rate change done... MESS:00:00:07.379870:0: uart: Baud rate change done... MESS:00:00:07.385266:0: gpioman: gpioman_get_pin_num: pin = SDCARD_CONTROL_POWER not defined (Note: Even a working boot for a microsd-card-only context using older firmware gets the above set of 4 messages --but keeps going.) (The re-reads of config.txt may mean that the initial/only hnd listed for it no longer matters.) I see the same sort of hangup with modern firmware when a USB3 SSD is in use instead of a microsd card: Read config.txt bytes 258 hnd 0x000080ec hash '241c057b26cdfc4e' recover4.elf not found (6) recovery.elf not found (6) Read start4.elf bytes 2277248 hnd 0x00003df5 hash '8e98b15f075142da' Read fixup4.dat bytes 5409 hnd 0x00003519 hash 'bdc1f053a4ad68f8' vs. MESS:00:00:06.184750:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x4000 size = 0xb99c . . . MESS:00:00:09.317648:0: Device tree loaded to 0x4000 (size 0xbe0c) Again the "hnd" point inside the area that later holds the Device Tree. Again: MESS:00:00:09.323596:0: uart: Set PL011 baud rate to 103448.300000 Hz MESS:00:00:09.332661:0: uart: Baud rate change done... MESS:00:00:09.334714:0: uart: Baud rate change done... MESS:00:00:09.340188:0: gpioman: gpioman_get_pin_num: pin = SDCARD_CONTROL_POWER not defined (Yep: looks basically the same as before.) In a working modern-firmware-in-use context (uefi/ACPI via USB3 SSD example), I see the following in the debug output during a boot with modern firmware. Again note the "hnd" values vs. the Device Tree memory. Read config.txt bytes 257 hnd 0x00000014 hash '149443376548b81e' recover4.elf not found (6) recovery.elf not found (6) Read start4.elf bytes 2283936 hnd 0x000007e2 hash 'ddddf81164f250ad' Read fixup4.dat bytes 5422 hnd 0x000008fa hash 'fdfbb390f4a2c93c' MESS:00:00:07.259636:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x1f0000 size = 0xb99c . . . MESS:00:00:08.268417:0: brfs: File read: /mfs/sd/RPI_EFI.fd MESS:00:00:08.270883:0: Loading 'RPI_EFI.fd' to 0x0 size 0x1f0000 MESS:00:00:08.276708:0: No compatible kernel found MESS:00:00:08.281210:0: Device tree loaded to 0x1f0000 (size 0xbd90) There is no overlap between the later Device Tree area and the hnd values. There is an overlap between where RPI_EFI.fd is loaded and the hnd values, but just at this later time frame, where the overlaps might be less likely to matter. So far, I've not observed problems for this. It might suggest that my hnd hypothesis is wrong. Or that it is late enough that the overlaps do not matter any more. The messages continue in this case: MESS:00:00:08.287327:0: uart: Set PL011 baud rate to 103448.300000 Hz MESS:00:00:08.296362:0: uart: Baud rate change done... MESS:00:00:08.298385:0: uart: Baud rate change done... MESS:00:00:08.303463:0: bfs_xhci_stop MESS:00:00:08.306631:0: XHCI-STOP MESS:00:00:08.311953:0: xHC ver: 256 HCS: 05000420 fc000031 00e70004 = HCC: 002841eb NOTICE: BL31: v2.3():v2.3 NOTICE: BL31: Built : 10:40:51, Apr 21 2020 UEFI firmware (version UEFI Firmware v1.20 built at 14:10:14 on Sep 1 = 2020) . . . . My memory is that armstub8-gic.bin currently requires the 0x4000 for the start of the device tree. If the above turns out to be right, then it is likely that older firmware also got overlaps with the hnd values but happened to not fail for some not-always-guaranteed reason. This is probably the strongest point against my hypothesis. =3D=3D=3D 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?2B1B21CB-1A63-42CE-8917-98870C88CACE>