Date: Sat, 10 Oct 2020 23:31:38 -0700 From: Mark Millard <marklmi@yahoo.com> To: Kyle Evans <kevans@FreeBSD.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]? Message-ID: <F8DBF042-FD57-4AE3-8F98-0E36945469A9@yahoo.com> In-Reply-To: <2B1B21CB-1A63-42CE-8917-98870C88CACE@yahoo.com> References: <2B1B21CB-1A63-42CE-8917-98870C88CACE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Oct-9, at 23:53, Mark Millard <marklmi@yahoo.com> wrote: > My evidence that suggests the possibility or likelyhood is . . . >=20 > 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: >=20 > 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' >=20 > 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. >=20 > Somewhat later: >=20 > 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) >=20 > (I did not show re-reading config.txt, some HDMI notices, > loading of overlays, or the attempted open of the > non-existent cmdline.txt .) >=20 > So: >=20 > 0x4000 up to 0xF99c (which contains 0xcfd2, 0xd88c, and 0xe149) > (Even before armstub8-gic.bin is loaded.) >=20 > 0x4000 up to 0xFE0C (which contains 0xcfd2, 0xd88c, and 0xe149) > (After armstub8-gic.bin and u-boot.bin have been loaded.) >=20 > Only a few more lines are output before things are hung up: >=20 > 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 >=20 > (Note: Even a working boot for a microsd-card-only context > using older firmware gets the above set of 4 messages --but > keeps going.) >=20 > (The re-reads of config.txt may mean that the initial/only > hnd listed for it no longer matters.) >=20 >=20 >=20 > I see the same sort of hangup with modern firmware when a USB3 > SSD is in use instead of a microsd card: >=20 > 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' >=20 > vs. >=20 > 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) >=20 > Again the "hnd" point inside the area that later holds the Device = Tree. >=20 > Again: >=20 > 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 >=20 > (Yep: looks basically the same as before.) >=20 >=20 >=20 > 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. >=20 > 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' >=20 > 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) >=20 > There is no overlap between the later Device Tree area and the > hnd values. >=20 > 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. >=20 > 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. >=20 > The messages continue in this case: >=20 > 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) > . . . . >=20 >=20 > My memory is that armstub8-gic.bin currently requires the > 0x4000 for the start of the device tree. >=20 >=20 > 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. >=20 I've seen: Read config.txt bytes 285 hnd 0x00000007 hash '901b7026086ee8cf' which suggests that my guess about "hnd" is false. Looking for overlaps with address ranges may well not be appropriate. I've seen other odd numbered values as well. What I learned from the Fedora 33 branch's material . . . A) I did manage to do a u-boot 2020.10 USB3-SSD-only boot with modern firmware on a 4 GiByte RPi4B. But it was a Fedora 33 branch context, not FreeBSD, not rpi3-psci-monitor. A different u-boot 2020.10 build than for FreeBSD as well. B) Attempting the same boot on a 8 GiByte RPi4B via the same media has the same problem seen via FreeBSD experiments for u-boot 2020.10 and 8 GiByte: starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found So (B) would seem to be a u-boot 2020.10 issue, having nothing specifically to do with FreeBSD or with rpi3-psci-monitor use. =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?F8DBF042-FD57-4AE3-8F98-0E36945469A9>