From owner-freebsd-arm@freebsd.org Sun Oct 11 06:31:43 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 BB1D44396CD for ; Sun, 11 Oct 2020 06:31:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4C8BmG4Ngbz3WYQ for ; Sun, 11 Oct 2020 06:31:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GpJPz8AVM1kFLQSL3inmQdsZfvSnQyI0g0pUcOWL0Ua8xIfDnmmy0F70M2.sMlN mVHO5JFNIg7Jf4b0ECezFxzE2.FApwTzSpgTMrnCWtvO__DRCfZ3ii.Ug04cx1Yp5fVRQQ9RVbdq uhvjDHNiiigWfl4m3uH_rJJw340Q04oIV5xg4hKgF5UCGYyXKZyf2W1rtHjNie2BxruHrVUHs6G2 8lJ_vD5W9k3PN3t88Bry8_nvAoO_J0S1GVJ_PpZIqql2gF5TB3Z4RjNsBcVaIOjB6zSl1FkG6oC2 Tdx3tRfSSnWDTW7J_ERHH2XOfKaQeBmOfL2YVdLDRWL4nKMzVpjUxpTpJbUYd1ndtsUP9F90Kzsv .1KRiE3rFJYXX5lasDx4Xs2rcxxSfExeLa0FFEqtOsdV5kyqVhw7rRhGDL1qCSNADv4vNe3EmvYU Lt_RA1pKzPynR0VU.ON8CcsRUTZKyW55U0y0.HpvWRM5x.MaLXvfL5K28IWuOD7zAnINcGFmV10J ewPHLBv67ERe100zhISrByw25xSuBs1hwIQwyybRqgA6KQWD_ShG8qZAxjLDfd_5_Pb_AXYgz6PH pb9qfgi4OTEvivxuE4ilCHyfPyAt_osw.PEthrzPWcVgB6Eoa0aOwK4PArMjpdsNNT.QnBM5UWg. 6CcsgVqkPx6ZjE6y_iFFEgrKAnI36e5KIJa_q50N.Ep5Cwacdnfi4Fu8n0TXXKRG4qwgvoIyM0og dn0_ipySYswP5DJDy_bchsiI0pPqbNlJWujXx2ppo1WBW2yLrdEGmQ3tR1tWPXnK33TtQq48.4s6 ihFhZV0ibhJURneRnHHniKhSot.P3_cvBo8OkN2oJWzzPQIh0pGY27WcMrMRQo2PtyR3O4f5lvTu pbY39udJ1WqJ9l9ImJOrVKhAjGabCXFmd8FBFK_hmARjreGsEaZf3SNgMBXV2F4JThuJ637OYlIA 3.3MCyRghvrZw6ZI_yl.3IdFIPwfHY3Cx_aOrjywp8V7FRFdBJVLo_SlOV_EgPlzbr3l0aZixTok H5YQWA.D0H6rKP.LUbeQpFZS79tbY1MR9d28MnG0icsc_hC0H6ayZ14iKRiriQwnz2oXzUyIjJHI lOlYJ_kc7K__4ShGgzWr_7EcA7FT86DLRHUho1qfuBZgHWSpOUVM91yO9HoqsmBOEaN9lMlm7PQo vlW.inhKyFM8Rr4_T1bOwf1BDhz3XcSGHZl13AFJjPVDH9HRs8eJX7Vd3lkD0dwEcvh5J6EwPA28 YTz4rnMg3Mjl8SB73WpZVmizCBPIUsFATjNRcvVvuqr_XDiEKcAM_lLL576TUw2no5_GvCtfWxgQ DZzDhawHaM4w2.4jNDVFX3phkRlNaKWpRc9c9MuqLHKnC4QPJzEqs_Abeb8ALfk6farZDLrCXzQi AkeATc6WdrZbCaKEC1yBXWB9xgDIjjtLsiZSDkFWedbN7PZI4QOM2026e5KyQ19Hbns30mkKndEc 5wlNoWOVAPZrwliZAM1NCWOuqwQomj.J2e3P_S7lftUHJ_0XNeirBUi8LYSqEX0Kvx.9dnG4RlCK w7MW9lxhQ Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 11 Oct 2020 06:31:39 +0000 Received: by smtp403.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9eabea541256bce65738466ef60d857f; Sun, 11 Oct 2020 06:31:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]? From: Mark Millard In-Reply-To: <2B1B21CB-1A63-42CE-8917-98870C88CACE@yahoo.com> Date: Sat, 10 Oct 2020 23:31:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B1B21CB-1A63-42CE-8917-98870C88CACE@yahoo.com> To: Kyle Evans , freebsd-arm X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C8BmG4Ngbz3WYQ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.04 / 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(-0.57)[-0.574]; 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.981]; 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.989]; 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.65.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.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: Sun, 11 Oct 2020 06:31:43 -0000 On 2020-Oct-9, at 23:53, Mark Millard 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)