From owner-freebsd-arm@freebsd.org Sat Oct 10 06:54:04 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E845C43E09F for ; Sat, 10 Oct 2020 06:54:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C7bJW0n02z4Jf0 for ; Sat, 10 Oct 2020 06:54:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: qdEPk9cVM1kykQY5ySzKmkIEThqDQ8sxmUjCl8Zrn3YOhqX8eX7SIvPoClh.0IM H_6qkxZ4lD78VEBuAHlXYZtO_6h1GmRgDlGmodvqr0vLXEAJ8wFAmx3I8sP_dmCAuKD0cFtDEYqH uRpmYzMccYMLjLswUFrEWTq3oZyjplACo6oSEfBa9tBRoTZIt7Mu38gkVF1ENcGW_Lv6AmxLWtEE .FSpXLe0cCJDIb14QHuYmDkIubEwZfwjxZbIZlNeWg0XFafAgI5KiIxk11EAB.pDsvYo3pEgzvNv KEJl4KeOiZ71POVZ24ayU4YLOxTODvW0.HZpvFeX91Er0mNeiv.bUnB5R.9fYd8JnKAHlukZRDr1 B3XOe2R6KDZn9am6.M9066DpBmP.3SKJ4FHqPU8f9a0VVGBUI0zF3sZMMxcBoeGxMhkutmkn1Nz8 L2_hO9R1s91ZBuvEQOiqCK7Ob2jHiP9C7mITkJQsOt1Z2peotojiTtorpD965MgTC3Ls64CNycFT 9.SLF_HP7xq9O6YOs4cp_gtvSdnACusnTsOPIaUPzmMR8re4vWvYH91esMsFHswgUJEa0zrcUwjd ocAciMMJlza6BUmMR0ubadt3USXAGpg3XzlVf9izoH1hTB7ksATj8kfYdFQ7s5dGl58lFYV9aaxS ujUsU.3ugehKH2wvM4sg_MKrjm7vv6DLAQEwyILF9fMnoLntOT9YEebJNr9xQvPs3T0EE2H_6Ib1 lJtP7LX1E7lGRPNfiUxJ9P5bfung8kdn2O5RBw5o.Z53fXghaanab2fXC2ZJ6qWABY3P7MX9I5LH 7zfoijfhtOSwiHUTJcS6H9A.lbSYfI0WQbPz641MGOYdTWi.4AFBy9urG9gwlTnzbARpkYm4xH2W EJIEUzUfi2CmRINR7rxwDnfz_kUaGPQQ9ZidWo_xHeDI8Gav8YwTLO4rlqvDKhKBfx3qCZDvb6po oQGJwRcbYM3jE1mD.q.eBpxt2OUnCV5ODhnY_kWNMZne_c7Bl3dhULiNF_MhbAgHXGWL0JWOvo6z tfq2TBxfcaPjhBe9jPfNhgMAEC4ZbXO70MZcxmR3fnHk.8Xhp4xEEUDQx0IH5PBqeBAMPyIDVHa4 ulKECRyyzlo59cbzK8M8CYHRkGKvga2wevyXroTZ3N3WpB3k6B5xwhPm8IFXtYOq_1OOWcmT5xUK YDygH9ncm1fXwAczGPLzJXg7bpNqnrKM4KeM9M_b1sY1OdbD45lJ0fiiS2pOzK7mL79juRQhNlvs AWEMhjq0x8ehaxTuKT1wa.l_g4ZJ0Amr.hl56gu4CfnXep6eyi_D9VmsZMRnl2DAMDENsch_oSU2 zKwVPc1SCr.VmyxSspNBVqxh6U55QpXw2remB8UKKfF1HcTpM5YWUVldayVCX_OpUzgraNKCSKlI qrbm0yFXXqq2lfq8tcIAn_9X07Qqvbhi5yYWNXhZPmyw3227YZkXIi_JcLY2wIfdA5YpTCdIgZt0 JP46mTa3SS6KYaibfZiwbaMIfgNt0PyfBpd5ml9yFvHGehgFqnIxfrPOt2D7DoAf9oSCt4MvBBEP yFD5upb4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 10 Oct 2020 06:53:59 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a045bffddea084c78025ffee60d04c9e; Sat, 10 Oct 2020 06:53:58 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) 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> Date: Fri, 9 Oct 2020 23:53:57 -0700 To: Kyle Evans , freebsd-arm X-Mailer: Apple Mail (2.3608.120.23.2.1) References: <2B1B21CB-1A63-42CE-8917-98870C88CACE.ref@yahoo.com> X-Rspamd-Queue-Id: 4C7bJW0n02z4Jf0 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.68 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.21)[-1.213]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.99)[-0.990]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; FREEMAIL_CC(0.00)[googlemail.com,protonmail.com]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 06:54:05 -0000 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)