From owner-freebsd-arm@freebsd.org Sun Oct 4 01:27:36 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 71FF63F5C1F for ; Sun, 4 Oct 2020 01:27:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (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 4C3mLZ4GwKz437d for ; Sun, 4 Oct 2020 01:27:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: RdT_LmMVM1kLqEZR0CwKh4usUcNVvLt.8T9EV2CQENtjt7acY0gyoyd6t1rw3je AC9PuWYSWbrtYTV88UXpFrY3snosuF43D10QVux6LVz_xeJ8WDxe1GFtjn3GMCYVI3TpPWkoa_1o _ee.eZsJqmN1NWfevZRhNw9VQUk4Hl42Ia7vj3hko2fImtmKgXC0nKtpXyRLZjFO3dgN.kapNrKp tTL7MAo1q4waCNbUxyoqoi8haOJLWI71ca8ZN1f0p1_yueX4L_vpynLH0M.pUWNHaQaQIestmEMo kBneG9NCatjO7DfTqEnVqt4OTBH1Xcc5Sg55EEJfC3qz7OZlMNCfb5gkVRZuFNdVWYJahF6yaxu2 Hb.MHMTxM6w3TOI6BIWijJN.EQlG8Xw9mwGzKK_eCOy5i_wDMr.N_wXf61AGKELmss..7kG4rOi2 WoDATn89gci9rAax5Trjc1vtNUehi5NScQUO58nLN6qQw1Eq7BYbdpT1oruAAu.n.Iy6nX2.nTa_ TSUZ_jtTbSfyhacvfea.1zhmmmxPSzxfxy1YulYqU3zzp7qI3bXYgDOQv9Tzn9sqk7k.ImZyithC dWLoOAd6gZC2plSOX_6puvgNu3ovEkYtkrGvHfPHNc0IkCrSWOvWwSGUOf.CT8O0s2j2NLNXbuo1 Rod4.8NHZUL4bscIQ6j8AmwmaHVSO0pyB9OkfdkWndT6WqTUl9W8Fk0SN2Sq4CkPxwm_i3Y6.jN5 EfTogikFLCg6H3wGiNbtftWoVuA.3zmHQyd2tM5Vs_2A91NHqcwS3IPnnYJXeDG0eK5bveWIiveV UFqiA3CTH6n9lZGwuibzYILNKPY5Qq7FIUgtxVhNhJ4eBmTEWRNhA3CWJQ2KDYjW78Rq_Dlsu0rP 6i1woPCvEIqfK.3NVSwmIPkwq43dnpJ45auvCM87mqshXTeGc7ic2hfj.25NaZJT._TiBW7SYvus d2he4BGJT6NngB9RvswGKWkhX0MSka2BfhZ29jwDJqx2JCElrnF8a64UDa8Ssw6mCTRBCragNhY9 cqk5VADxOxJhYep8VhFjR_UFOwBvhV7bHqjSOziS92U4urahL09whc.9szjOm2nHeqUoiFlhgEd6 8Ev4qtkA7TDB4iafnkB6h85NfiTuMKc_3U14Jk64fyUMDMuxt9mlYockHBiAtHGJ18tXnQhO3ksi IyXQOyvwiHt4vdcpRDzw0zO1SpvZf.2iTkT4O8XJkRJkhgST.FjQ4TuAY9TikXeeaEG316nHV1yc x4RNncHHiV2bHlaG71S3BvCzBSjltbWXQ78TPK4LOXAUMnQOPJyo0uBwsDqsCDUfQ4.ocrMn16ib 7o023OrpfBX.3.uhf8czMyt9iIQPrnLN_HY345fSK6duLe99gk.NqPk4.CcCA8dinNW8PMXVivNO J0ib4zbToTm.isjP6ygxBIfGnQtcZz1HjBKtudNfYzGq1b3P60O5dI7JJYM.3mOApH8pOwSNQE83 gom.K1.as5SU1Y.63UR2S3bDuV2A1sFfkSZG0.IuDYV3EpPSwwxuSMN6ZjAIpHdMwr29ZbbKpqsx ben53gNVLsbpWUHu7LvqiX1PQK_AnZ7UMbaRQ Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 4 Oct 2020 01:27:32 +0000 Received: by smtp412.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5698e1a329d02f9547a6e199169c9b0b; Sun, 04 Oct 2020 01:27:28 +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: Re: lspci XHCI "Memory at" for RPi4 (u-boot based context): FreeBSD vs. ubuntu vs. "Memory behind bridge" addresses Date: Sat, 3 Oct 2020 18:27:27 -0700 References: <8D837FD4-FC25-4D17-B008-141DC6A3D0FC@yahoo.com> To: Robert Crowston , freebsd-arm In-Reply-To: <8D837FD4-FC25-4D17-B008-141DC6A3D0FC@yahoo.com> Message-Id: <9D47356E-4CC4-410C-B258-330B943988D4@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C3mLZ4GwKz437d X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.07 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.49)[-0.489]; FREEMAIL_TO(0.00)[protonmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.04)[-1.045]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.040]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; 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, 04 Oct 2020 01:27:36 -0000 On 2020-Oct-3, at 13:01, Mark Millard wrote: > [Be warned that I'm reporting differences that I do not > understand. I may end up being told "nothing of interest > in these differences".] >=20 > In the later lspci -v output diff, there is the following for > the XHCI (-: FreeBSD, +: ubuntu): >=20 > - Memory at f8000000 (64-bit, non-prefetchable) > . . . > + Memory at 600000000 (64-bit, non-prefetchable) [size=3D4K] Looks like this is the two lspci's disagreeing about what to show for "Memory at": ubuntu "fdt print /" output: pcie@7d500000 { . . . #address-cells =3D <0x00000003>; . . . #size-cells =3D <0x00000002>; . . . ranges =3D <0x02000000 0x00000000 0xf8000000 = 0x00000006 0x00000000 0x00000000 0x04000000>; Note that both the figures are in ranges: 0x00000000 0xf8000000 and: 0x00000006 0x00000000 . As for FreeBSD, the same is true: pcie@7d500000 { #address-cells =3D <0x3>; . . . #size-cells =3D <0x2>; . . . ranges =3D <0x2000000 0x0 0xf8000000 0x6 0x0 0x0 = 0x4000000>; . . . So: 0x0 0xf8000000 and: 0x6 0x0 > Odder(?) is comparison of the FreeBSD address with what is > listed by both OS's for "Memory behind bridge": >=20 > Memory behind bridge: f8000000-f80fffff [size=3D1M] > . . . > - Memory at f8000000 (64-bit, non-prefetchable) >=20 > ubuntu gets a distinct address (600000000) and FreeBSD gets > an exact match to the start of the "Memory behind bridge". > (There may be a possible 32-bit address vs. 64-bit address > distinction?) Looks like this part is not odd. > [There are also IRQ differences (81/82 for FreeBSD; 41/42 for > ubuntu) and ubuntu lists the kernel drivers used.] >=20 > For reference: >=20 > # diff -u ~/rpi4-lspci_v-*.txt | more > --- /root/rpi4-lspci_v-fbsd.txt 2020-10-03 12:19:57.162261000 -0700 > +++ /root/rpi4-lspci_v-ubuntu.txt 2020-10-03 12:21:01.448646000 = -0700 > @@ -1,5 +1,5 @@ > -00:00.0 PCI bridge: Broadcom Inc. and subsidiaries Device 2711 = (prog-if 00 [Normal decode]) > - Flags: bus master, fast devsel, latency 0, IRQ 81 > +00:00.0 PCI bridge: Broadcom Inc. and subsidiaries Device 2711 (rev = 10) (prog-if 00 [Normal decode]) > + Flags: bus master, fast devsel, latency 0, IRQ 41 > Bus: primary=3D00, secondary=3D01, subordinate=3D01, = sec-latency=3D0 > I/O behind bridge: 00000000-00000fff [size=3D4K] > Memory behind bridge: f8000000-f80fffff [size=3D1M] > @@ -9,13 +9,15 @@ > Capabilities: [100] Advanced Error Reporting > Capabilities: [180] Vendor Specific Information: ID=3D0000 = Rev=3D0 Len=3D028 > Capabilities: [240] L1 PM Substates > + Kernel driver in use: pcieport >=20 > 01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host = Controller (rev 01) (prog-if 30 [XHCI]) > Subsystem: VIA Technologies, Inc. VL805 USB 3.0 Host Controller > - Flags: bus master, fast devsel, latency 0, IRQ 82 > - Memory at f8000000 (64-bit, non-prefetchable) > + Flags: bus master, fast devsel, latency 0, IRQ 42 > + Memory at 600000000 (64-bit, non-prefetchable) [size=3D4K] > Capabilities: [80] Power Management version 3 > Capabilities: [90] MSI: Enable+ Count=3D1/4 Maskable- 64bit+ > Capabilities: [c4] Express Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > + Kernel driver in use: xhci_hcd >=20 >=20 >=20 > Is this odd? Expected/reasonable? f8000000 vs. 600000000 Looks to be an odd lspci -v variation, with FreeBSD apparently showing the figure as if -b had been supplied on the command line ("Bus-centric view"): ubuntu shows f8000000 when the -b is supplied. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Oct 4 03:15:34 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 01A0A3F871F for ; Sun, 4 Oct 2020 03:15:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 4C3pl813nDz47fT for ; Sun, 4 Oct 2020 03:15:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Zn2A36gVM1mpzWOFst0.zRY7UlQI0BcG0B8Tb2NL.VxwbH3v37sr7YKj2tobR0R QCQXI7eEEDQa2GtDAGqb6Ft.02M3KDENMe7jfL.1lq5Lf4xVjuou4AY8lhmfyiHLcKxd8tFAKXxu X6Fg67Dll9TaRZ349XUXmyC8Z935qgwDqGzO97dngNh_WLzpV13AuGfXtfLvGBC7MSP.5z1Hhr_l cpEOoAEUrWFeGIpq.dytlP1aEuMNkmc906rDzQH71ceEwiBeiEgTUUqtEKm9z1GuQc2q61ZB_5J. 17QeUIQGxl6SOPUzh_VxJZXKnRJtP4GWLwZai0KP2P3fOENSP4sSxvl3qu9XuOq.bGsLNHN8WJn4 Vtb7g8FTxbxbprebvK50orplMC1lEUQFLR99gDTsT_Xx6hqkl20iPMKWH09lOrLXeMzHjcGu9Eud EaCosyDjeBKD28m.UUcl3Yw7trJ7fwwJZfMRRbb_yqPJLPLA0w2ztuGaKFwjS5R1e3Yth1duo8IJ PqTJM5cCy9FnsV_IEKxGqXmydn66ai2jL3n1cKBJ9y19ehF4OlnMX4VFfRupe70vInKb.UvASO_w qHCnO5JwbVm.6ZGLnjs.x_LwZ0ishmY861C1jIBnRsV_Iu6IGqRyb9fJYX23LbYCPMj.lXBIpcri .4xv.KMTOo4A8R4juVp6sYWt8OuJQdbJx7F5QNw8YGKAD5t.UyRozc5GDUG3n25CU2cEncTmGy3u 3jhaN3ZbNFAbgIuMucnwaAdPIbHPbz0BjdDgyIt8.DyLIe0exkKIt5aw9wrFzqXRBKrUHPB4YIEY mBOJFIOj4r412SG7ny_xn3FjimNHQdAd7wTd6pntNH5fHoTfK3pYyMaMMT87lfxTld9uqJTr.fyW TSgTi4lDW9hzt2yj2YdX8fpNCyBpTtoSJ.sFbiguQPCVKiqYY7CtSj6K.8iRpIoQE.inoGDu7fQl 06KreygGOSlEgKF_JzUZpbucMdXjDXeUK5WNN7eUcJegrmU0tU5RwfgCpMiWMPE6HRKQRyX1WXlG LW6pAnynVdq6e1dnQv.EAdNg1rChoFPcItWuedEHruTFqHWB1kufVPNhMDzVcjpOOfgcO9zTVPb_ 2H7.5koOkGRRgVBeSOlPOHAX0XrKqE3osDjPReZ6JtTOo1LKVlVAZT7EKWevUqomXc7y8sLEBvEB R_I.mwTuJTGuqzdZPrpb0_32Z0vJhvkCbNpfIgxmP4P4G_QWWo1FURlf5nATJOdNGxo2LR_bTkzy jlvrsaVPKueWV1TpTlrsn4tnFKwsFfHkfIbW2xibr446K_0gGmvQDEAID976eYZeLYO6UpiN7Tqn Rtg7Ctc.dYpD44JIy3CNu4St7EkzO.mVgmB.7DATFIlTwdxX.NSVXs3NpTaMTSnRh5_o8gwPWqBp _u75NAoui1JUJGLmmCmUArAiNk5Lukx9by3UztXu1_3Mr8sS4YkXEG38ToZgjjN.UwUlI4_N5odK CeNsj5vzJYn996rbDACudLDHGBDBTa6MpdCTn81fYFnAE1UpWMvUidO93Hz_J6DHui2gl.nmoyPe PiHgfUuOq5bzhYFUVCCO3oSVpJtkNlzkQnLw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 4 Oct 2020 03:15:30 +0000 Received: by smtp425.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fac0d4ac29f24895e185c4ff717c8b88; Sun, 04 Oct 2020 03:15:28 +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: Re: rpi4 FreeBSD vs. ubuntu u-boot fdt print / memereserve difference (lack of reserve in FreeBSD context), 0x3b400000 vs. DMA_HIGH_LIMIT being 0x3c000000 Date: Sat, 3 Oct 2020 20:15:26 -0700 References: <1A13F7B5-F8C3-4022-939C-2992E53D1DF1@yahoo.com> To: Robert Crowston , freebsd-arm In-Reply-To: Message-Id: <01C14FE4-C2A6-4459-A5EE-AE33045FAF42@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C3pl813nDz47fT X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.63 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.04)[-1.042]; FREEMAIL_TO(0.00)[protonmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.04)[-1.044]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email]; NEURAL_HAM_LONG(-1.04)[-1.039]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[0.0.0.0:email]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; 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, 04 Oct 2020 03:15:34 -0000 On 2020-Oct-3, at 16:10, Mark Millard wrote: > On 2020-Oct-3, at 15:20, Mark Millard wrote: >=20 >> Another FreeBSD vs. ubuntu context difference, this time in the >> fdt print / output . . . >>=20 >> The ubuntu u-boot has (fdt print / output): >>=20 >> memreserve =3D <0x3b400000 0x04c00000>; >> . . . (Note: 0x3b400000+0x04c00000 =3D=3D 0x40000000) . . . >>=20 >> #address-cells =3D <0x00000002>; >> #size-cells =3D <0x00000001>; >> . . . >> axi { >> vc_mem { >> reg =3D <0x3ec00000 0x40000000 0xc0000000>; >> }; >> Note: "vc_mem is solely used as a mechanism for passing a = couple >> of parameters through from the firmware to vcdbg" >> End note >> }; >>=20 >> . . . ( boot args has: vc_mem.mem_base=3D0x3ec00000 = vc_mem.mem_size=3D0x40000000 ) . . . >>=20 >> reserved-memory { >> #address-cells =3D <0x00000002>; >> #size-cells =3D <0x00000001>; >> ranges; >> phandle =3D <0x0000003d>; >> linux,cma { >> compatible =3D "shared-dma-pool"; >> size =3D <0x04000000>; >> reusable; >> linux,cma-default; >> alloc-ranges =3D <0x00000000 0x00000000 = 0x30000000>; >> phandle =3D <0x0000003e>; >> }; >> }; >> . . . (I split the reg into lines below) . . . >> memory@0 { >> device_type =3D "memory"; >> reg =3D <0x00000000 0x00000000 0x3b400000 >> 0x00000000 0x40000000 0xbc000000 >> 0x00000001 0x00000000 0x80000000 >> 0x00000001 0x80000000 0x80000000>; >> }; >> . . . (Note: 0x40000000+0xbc000000 =3D=3D 0xFC000000) . . . >>=20 >> (I've ignored gpiomem above and below.) >>=20 >> It appears to be that the memreserve may be important >> to have. The above may also suggest that FreeBSD's: >>=20 >> #define DMA_HIGH_LIMIT 0x3c000000 >>=20 >> may be a little too large (< or <=3D 0x3b400000 ?). >>=20 >> FreeBSD u-boot reports just: >>=20 >> /memreserve/ 0x0 0x1000; >> . . . >> memory@0 { >>=20 >> device_type =3D "memory"; >> reg =3D <0x0 0x0 0x0>; >> }; >>=20 >> And so does not indicate anything special for either of >> (showing begin/end points): >>=20 >> 0x3b400000..0x3FFFFFFF (in use by the vc?) >> 0xFC000000..0xFFFFFFFF (I/O peripheral area and such?) >>=20 >> The context is an 8 GiByte RPi4 in both examples. Various >> details would vary on 1 GiByte and 2 GiByte RPi4Bs and >> some in memory@0 on the 4 GiBYTe RPi4B. >=20 > Turns out that rpi_DATA_2711_1p0.pdf 's "Figure 1. BCM2711 > Address Maps" shows this "SDRAM (for the VC)" area in the > two 35-bit Address Maps, showing 0x0_4000_0000 as the > next address after the area in both diagrams --and notes > for area for each diagram: >=20 > QUOTE > Size of VC SDRAM > determined by > config.txt > END QUOTE >=20 > But ubuntu uses includes and such so overall there > are the following .txt files ( cmdline.txt being for > a different purpose ): >=20 > # ls -ld /boot/firmware/*.txt > -rwxr-xr-x 1 root root 141 Jul 31 16:48 /boot/firmware/cmdline.txt > -rwxr-xr-x 1 root root 1117 Jul 31 16:48 /boot/firmware/config.txt > -rwxr-xr-x 1 root root 327 Jul 31 16:48 /boot/firmware/syscfg.txt > -rwxr-xr-x 1 root root 251 Sep 26 22:14 /boot/firmware/usercfg.txt >=20 > config.txt includes syscfg.txt and usercfg.txt . >=20 > config.txt uses the [pi4], [pi2], [pi3], and [all] section > notation as well. >=20 > Looks like one of u-boot's jobs is to figure out the figures > that go in (base then size): >=20 > memreserve =3D <0x???????? 0x????????>; >=20 > (such that the total is 0x40000000 for the RPi4B) in order > to protect the VC SDRAM area. >=20 >=20 > The diagrams also indicate that 0xFC000000..0xFFFFFFFF is > for when "low Perioheral" mode is in use, listing ("up > to H" not including H): >=20 > ARM Local peripherals from 0x0_FF80_0000 up to 0x1_0000_0000 > and: > Main peripherals from 0x0_FC00_0000 up to 0x0_FF80_0000 >=20 > Otherwise they are listed at: >=20 > ARM Local peripherals from 0x4_C000_0000 up to 0x5_0000_0000 > and: > Main peripherals from 0x4_7C00_0000 up to 0x4_8000_0000 >=20 > I gather the ubuntu "fdt print /" result implies that ubuntu > is using "Low Peripheral" mode (or at least allowing for it). >=20 > There are some other "Reserved" areas and the special areas > that are "two L2 cache aliases (one allocating, one > non-allocating) which cache (only) the first 1GB of SDRAM". > if these are all counted then 0x4_0000_0000 up to > 0x6_0000_0000 is all some form of special-use area in > both diagrams and 0x6_0000_0000 through 0x7_FFFF_FFFF is the > PCIe area in both diagams. Looks like in ubuntu land the following from the dtb/fdt work together(?) to cover avoiding memory that is inappropriate for use for low-RAM DMA activity: U-Boot> fdt print / / { memreserve =3D <0x3b400000 0x04c00000>; . . . (Note: 0x3b400000+0x04c00000 =3D=3D 0x40000000) . . . reserved-memory { #address-cells =3D <0x00000002>; #size-cells =3D <0x00000001>; ranges; phandle =3D <0x0000003d>; linux,cma { compatible =3D "shared-dma-pool"; size =3D <0x04000000>; reusable; linux,cma-default; alloc-ranges =3D <0x00000000 0x00000000 = 0x30000000>; phandle =3D <0x0000003e>; }; }; . . . where: alloc-ranges =3D <0x00000000 0x00000000 0x30000000> indicates a low memory range to use for "shared-dma-pool" DMA activity. memreserve =3D <0x3b400000 0x04c00000> indicates the actual area in use for gnu_mem=3D/gnu_mem_1024=3D material and so indicates an area that must be avoided. It appears that this adjusts based on what config.txt has for (either of) gnu_mem=3D/gnu_mem_1024=3D . It appears that the alloc-ranges=3D... above allows for the maximum recommended gpu_mem/gnu_mem_1024 figure for the RPi4B and so, if that limit is honored, avoids overlapping the memreserve. This may suggest that your code should change to: #define DMA_HIGH_LIMIT 0x30000000 XHCI and the type-DMA4 engine use need to explicitly avoid the memreserve area. The old normal/LITE DMA could be redirected to use a different 1 GiByte range (shifted above the memreserve when there is enough RAM to do so). The more modern dtb/fdt's that I use in some contexts have the reserved-memory linux,cma alloc-ranges. (I'm not claiming such information is translated to uefi/ACPI.) But the old dtb/fdt's used with FreeBSD u-boot do not indicate those alloc-ranges. The u-boot for FreeBSD that I'm using (from ports) does not generate the memreserve material so neither the old or new fdt's end up with such material. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Oct 4 07:59:24 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 0ED943FE1B5 for ; Sun, 4 Oct 2020 07:59:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.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 4C3x2b6K7Tz4NGH for ; Sun, 4 Oct 2020 07:59:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ESmq5Z4VM1lKTkJLIRV8XjPu_7GaBSaXekABFfActiBe7.zXGUS0zkH4Wa8QlZv h1miY5TBbFzIcfyxbr9qaMmzVX6Rbi083NkmRn0KQPUejWJzOqsL08QIU20LONEPCYN5C2QAhVhw _VjCNEEYU2e93A68RBX283qonkx8k0Jou3bP.furvr36htDnCkH6mjcHxxe2xAK.Ume8ubM9deRI c7qvnF6odTr99sxFsy3tVXuZQDBAeFNa_P8yFwP2.Y.iEkhcXGF9.MepgdT42OZbRrfeJ9NdamFZ mbm1rx8qQ__ntHtghZccLeqLV_1cZa0j15vI3FzSd_M8fAFIyxI84QihqyUyPS5QVWLz4a0eBUgi HhwiMBdjuzdfn8Uoj.RTrhkTGoyxCRm5d3md7Mjf5TdEiZyd0hxKVL2Rrrt17f_ofckO5ogUU6r_ lh0Vft78CgLDiKokYGcrddclGZW7d30itlWo0quAr8CD7JdrS_mmQ9wKQVu9wbGDfYNl3vLrXIFX fjnb1Gs5h_1n8N.aBjctviyyNRCoB39iH3aDKPIaMM0fwWFcSef8jZrQxXfKZUOXiQFGjsLYZN5j i7qsUwZfYg3HOarOSezf_fAEIgRNz3oMFa3tFTsldVoqoONP74GW74nZydu8WXyQCauKL0HpZbdL uryPdJvCMWhmHhA5l60L0OlX9Mdz6adBBpV78nDM8YayubQSLZvMzqvnVjP8pFbh6z2Os6LKSlnz kqb5vbcd88tGKKaIMsC8triy5oOQViRXNJuZPXNaxqHfAjVeXPKzp3P47MidibpzL2dlzIpjZ53Z ARPvKwhWvMoy0JttUOwugFFhsQd7GLqwmyoteKbOQ5fe4iebpv0Yo41JHPiFKmhr5r55wuaEAAKx R.ZEZ3EoWBejRVCXAR9CMrmP1TTVv2xMAPDpiPatNLlQXPpj82LcrElpP_qMhoPKPTRDlBzcuUys B6PZhr0YLU7SMi5z0bwWI3_LYeV_M_EOHgBbmdXcJCGrk5BLfyXeVWZlZsAfeJLE9tZ8xorD33th OvaR5mn83exjgbdLDUbVQ3jFwHbjpEFDpZP6E9SvIeGMKtsqe3udYMZJyHNGikRoXl88VmWgLWsK Hs4irAnosDbOwGSKfPkWigXs86zXnd5HozUCNtqXb2EXWsF1mmQaUK.wNuD3ewxaLiydYdf7Nmyu S5X0JGvGB7I7YU8t8Vm.xcnPBrV6yB0lliazfNokRZKCqLkErBulUqPBolKhRGKzgjs87QrkHsoC Thq72SyGMwpCDD2oMSrtvPVLWg4DFUyiX2hdMe.gMBRM1V2mYjQWlpYVEilBlNcwcLoendsGLhb3 R33nKfoY8Hp3g3p1mQqfDaey_zb7tnTxhkVk51h1yZ_K5GYgWbb9ERJ8toPoCjra.jn4z8kv7WSn X5gLw1Jr1_euSYxuGSlvfsUs4e4i_IR6TIG18.SLrhfs3RDlpHISLFOZpt7490lFkaYyQ9gT0It7 UE2FNziApjlfu95hb90nTaDJmiNLeCTtELkIHd0SB3ZmGsAfO4c6UgpMffbmxryZPw09lxiJo0kS FKTxTZcuh2VBEtqWJv3zISkIP6krqq40- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 4 Oct 2020 07:59:18 +0000 Received: by smtp401.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cf8786afa088dd751f0063790f45b057; Sun, 04 Oct 2020 07:59:16 +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 u-boot based booting and hw.cpufreq.voltage_core and dev.cpu.0.freq use: able to use 2000 MHz From: Mark Millard In-Reply-To: <19D27F91-F038-4393-90BF-7A439F8BF4B1@yahoo.com> Date: Sun, 4 Oct 2020 00:59:15 -0700 Cc: freebsd-arm , Robert Clausecker Content-Transfer-Encoding: quoted-printable Message-Id: <5681B635-18E8-465E-9BC1-8E398BC6A306@yahoo.com> References: <0578EC2B-D21C-46AA-AD3E-CD13985B18FA.ref@yahoo.com> <0578EC2B-D21C-46AA-AD3E-CD13985B18FA@yahoo.com> <20200926133934.GD54660@bastion.zyxst.net> <64B39936-7689-4240-A5F9-4DF5EAE4DE42@yahoo.com> <19D27F91-F038-4393-90BF-7A439F8BF4B1@yahoo.com> To: tech-lists X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C3x2b6K7Tz4NGH X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.16 / 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.62)[-0.619]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.05)[-1.045]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; 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, 04 Oct 2020 07:59:24 -0000 On 2020-Sep-26, at 19:01, Mark Millard wrote: > On 2020-Sep-26, at 13:20, Mark Millard wrote: >=20 >> On 2020-Sep-26, at 06:39, tech-lists wrote: >>=20 >>> . . . >>> Exellent! On the basis of your post I went ahead and removed from = config.txt >>> three lines, then added two and rebooted. >>>=20 >>> It's now this: >>>=20 >>> arm_control=3D0x200 >>> arm_64bit=3D1 >>> dtoverlay=3Ddisable-bt >>> dtoverlay=3Dmmc >>> device_tree_address=3D0x4000 >>> kernel=3Du-boot.bin >>> armstub=3Darmstub8-gic.bin >>> over_voltage=3D6 >>> arm_freq=3D2000 >>>=20 >>> before, when it didn't work, it had this: >>> [same as above], apart from >>> gpu_mem=3D16 >>> over_voltage=3D6 >>> arm_freq=3D2100 >>>=20 >=20 Turns out that gpu_mem=3D32 works for the 8 GiByte RPi4B. (Note: I do have a display connected but no X11m just a console login prompt.) But gpu_mem=3D16 prevents further I/O to the microsd card during the early RPi stages of things, before FreeBSD is involved: . . . rsc 32 fat-sectors 635 c-count 81269 c-size 2 r-dir 2 r-sec 0 Read config.txt bytes 177 hnd 0x00006938 hash '9be9ccf1915ff016' recover4.elf not found (6) recovery.elf not found (6) start4cd.elf not found (6) start_cd.elf not found (6) Firmware not found ERROR: 00000004 . . .=20 In my context it then tried booting from the USB3 SSD and that worked. (Only the microsd card had gpu_mem=3D16 but I'm not sure if the config.txt from the USB3 SSD was read or not. The USB3 SSD booting is set up for uefi/ACPI booting experiments. The microsd card was set up for u-boot booting experiments [when it gets that far].) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Oct 4 08:15:58 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 289543FE8EB for ; Sun, 4 Oct 2020 08:15:58 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C3xPm0z2Vz4PB3 for ; Sun, 4 Oct 2020 08:15:55 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sun, 04 Oct 2020 08:15:46 +0000 To: Mark Millard From: Robert Crowston Cc: freebsd-arm Reply-To: Robert Crowston Subject: Re: RPi4B 3 GiByte pcie limitation: The following change survived my huge-file duplicate-and-diff tests so far Message-ID: In-Reply-To: <447B28E3-3964-4498-A91D-528EA5923793@yahoo.com> References: <7506FD70-D814-4F64-BFAF-CCCE9A0D71A3@yahoo.com> <447B28E3-3964-4498-A91D-528EA5923793@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4C3xPm0z2Vz4PB3 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.16 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-0.20)[-0.203]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.933]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.027]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.70.40.133:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.133:from]; 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, 04 Oct 2020 08:15:58 -0000 I have experimented with the segment size. I cannot have tested every scena= rio, but I did not find it made any difference, even if I went down to segm= ents of only a page. I understand the original Linux driver used a bounce buffer where each DMA = transaction was limited to a few MB. However that design was dropped when t= he driver was merged into the mainline kernel. =E2=80=94 RHC. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Saturday, 3 October 2020 03:35, Mark Millard wrote: > [Operator error note and another note.] > > On 2020-Oct-2, at 13:56, Mark Millard wrote: > > > It appears to me that 3 GiByte works for lowaddr and > > maxsize but that the maxsegsz needs to be limited to > > 1 GiByte [or so, maybe (1 Gi - 1) Bytes]. > > I did the following based on all those notes that I > > sent out, that included the ?_TXFR_LEN being limited > > 30 bits for (normal) DMA engines (0-6) and the DMA4 > > engines (11-14) [but not DMA LITE (7-10)]: > > Ignore: I had the wrong kernel build installed. > In fact the below fails when the intended kernel > is tested. > > > svnlite diff /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c /usr/src/s= ys/arm/broadcom/bcm2835/bcm2838_xhci.c > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (revision 365932) > > +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (working copy) > > @@ -105,7 +105,8 @@ > > * > > > > - Whatever the true maximum address, 960 MiB works. > > */ > > -#define DMA_HIGH_LIMIT 0x3c000000 > > +#define DMA_SEG_HIGH_LIMIT 0x3c000000 > > +#define DMA_TOTAL_HIGH_LIMIT 0xc0000000 > > #define MAX_MEMORY_LOG2 0x21 > > #define REG_VALUE_DMA_WINDOW_LOW (MAX_MEMORY_LOG2 - 0xf) > > #define REG_VALUE_DMA_WINDOW_HIGH 0x0 > > @@ -642,12 +643,12 @@ > > / > > error =3D bus_dma_tag_create(bus_get_dma_tag(dev), / parent / > > 1, 0, / alignment, bounds */ > > > > - DMA_HIGH_LIMIT,=09=09=09/* lowaddr */ > > > > > > > > - DMA_TOTAL_HIGH_LIMIT,=09=09/* lowaddr */ > > BUS_SPACE_MAXADDR,=09=09=09/* highaddr */ > > NULL, NULL,=09=09=09=09/* filter, filterarg */ > > > > > > > > - DMA_HIGH_LIMIT,=09=09=09/* maxsize */ > > > > > > > > - DMA_TOTAL_HIGH_LIMIT,=09=09/* maxsize */ > > BUS_SPACE_UNRESTRICTED,=09=09/* nsegments */ > > > > > > > > - DMA_HIGH_LIMIT,=09=09=09/* maxsegsize */ > > > > > > > > - DMA_SEG_HIGH_LIMIT,=09=09=09/* maxsegsize */ > > 0, =09=09=09=09=09/* flags */ > > NULL, NULL,=09=09=09=09/* lockfunc, lockarg */ > > &sc->dmat); > > > > > > > > Then, with such a kernel installed, I used: > > -rw-r--r-- 1 root wheel 11570948096 Jul 18 18:32:37 2020 clang-armv7-on= -aarch64.tar > > (so much larger than the 8 GiByte RAM) and did the following with > > the file: > > > > cp -aRx clang-armv7-on-aarch64.tar clang-armv7-on-aarch64.alt_tar > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > diff clang-armv7-on-aarch64.tar clang-armv7-on-aarch64.alt_tar > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =3D=3D > > > > Such tests have been passing. > > I do not know what your test procedures were. But if the above > > is suggestive, you might want to try testing something like the > > above via your test procedures. > > Going in a different direction for potential maxsegsz figures > (and the like): xhci instead of bcm2711 material . . . > > extensible-host-controler-interface-usb-xhci.pdf reports that > normal TRB Transfer Length fields have bits 16:0 and "Valid > values are 0 to 64K". (Transfer Event TRB Transfer Lengths > have 23:0 but above 0x10000 as a value is only for Event Data > flag being 1 or for condition code is stopped - short packet.) > > I've not experimented with this. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Oct 4 08:24:00 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 82FD33FEE3C for ; Sun, 4 Oct 2020 08:24:00 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C3xb32Pctz4PMb for ; Sun, 4 Oct 2020 08:23:58 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sun, 04 Oct 2020 08:23:52 +0000 To: Mark Millard From: Robert Crowston Cc: freebsd-arm Reply-To: Robert Crowston Subject: Re: lspci XHCI "Memory at" for RPi4 (u-boot based context): FreeBSD vs. ubuntu vs. "Memory behind bridge" addresses Message-ID: <_1uj5jck3lB6Ae6MFtajO1T-MFo3k9fO1wVm7cSjo3cwf6KPUSqrWg30DHmKrwr_NBHOK93sVXm6Evf_a-6WiMyO-mvtk8ZdvyTtgHYoP78=@protonmail.com> In-Reply-To: <9D47356E-4CC4-410C-B258-330B943988D4@yahoo.com> References: <8D837FD4-FC25-4D17-B008-141DC6A3D0FC@yahoo.com> <9D47356E-4CC4-410C-B258-330B943988D4@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4C3xb32Pctz4PMb X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.16 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24:c]; FREEMAIL_FROM(0.00)[protonmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-0.20)[-0.203]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.934]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.027]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.70.40.22:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.22:from]; 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, 04 Oct 2020 08:24:00 -0000 Yes, the 0xf8000000 is the PCI start address and the 0x600000000 is the CPU= start address. It was (and perhaps is) a source of much confusion to me as= well, especially as (AFAIK) FreeBSD did have any other examples of PCI dri= vers using distinct addressing schemes for upstream vs downstream DMA acces= s. Therefore we only supported it "theoretically": in the sense that, as fa= r as I know, that no one ever had to think about it before. It may be that the tooling or diagnostics could be cleaned up to give the C= PU view. =E2=80=94 RHC. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, 4 October 2020 02:27, Mark Millard wrote: > > > On 2020-Oct-3, at 13:01, Mark Millard wrote: > > > [Be warned that I'm reporting differences that I do not > > understand. I may end up being told "nothing of interest > > in these differences".] > > In the later lspci -v output diff, there is the following for > > the XHCI (-: FreeBSD, +: ubuntu): > > > > - Memory at f8000000 (64-bit, non-prefetchable) > > > > > > > > . . . > > > > - Memory at 600000000 (64-bit, non-prefetchable) [size=3D4K] > > > > > > Looks like this is the two lspci's disagreeing about what > to show for "Memory at": > > ubuntu "fdt print /" output: > > pcie@7d500000 { > . . . > #address-cells =3D <0x00000003>; > . . . > #size-cells =3D <0x00000002>; > . . . > ranges =3D <0x02000000 0x00000000 0xf8000000 0x00000006 0x00000000 0x0000= 0000 0x04000000>; > > Note that both the figures are in ranges: > > 0x00000000 0xf8000000 > and: > 0x00000006 0x00000000 > > . As for FreeBSD, the same is true: > > pcie@7d500000 { > #address-cells =3D <0x3>; > . . . > #size-cells =3D <0x2>; > . . . > ranges =3D <0x2000000 0x0 0xf8000000 0x6 0x0 0x0 0x4000000>; > . . . > > So: > > 0x0 0xf8000000 > and: > 0x6 0x0 > > > Odder(?) is comparison of the FreeBSD address with what is > > listed by both OS's for "Memory behind bridge": > > > > Memory behind bridge: f8000000-f80fffff [size=3D1M] > > > > > > . . . > > > > - Memory at f8000000 (64-bit, non-prefetchable) > > > > > > > > ubuntu gets a distinct address (600000000) and FreeBSD gets > > an exact match to the start of the "Memory behind bridge". > > (There may be a possible 32-bit address vs. 64-bit address > > distinction?) > > Looks like this part is not odd. > > > [There are also IRQ differences (81/82 for FreeBSD; 41/42 for > > ubuntu) and ubuntu lists the kernel drivers used.] > > For reference: > > > > diff -u ~/rpi4-lspci_v-*.txt | more > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > --- /root/rpi4-lspci_v-fbsd.txt 2020-10-03 12:19:57.162261000 -0700 > > +++ /root/rpi4-lspci_v-ubuntu.txt 2020-10-03 12:21:01.448646000 -0700 > > @@ -1,5 +1,5 @@ > > -00:00.0 PCI bridge: Broadcom Inc. and subsidiaries Device 2711 (prog-i= f 00 [Normal decode]) > > > > - Flags: bus master, fast devsel, latency 0, IRQ 81 > > > > > > > > +00:00.0 PCI bridge: Broadcom Inc. and subsidiaries Device 2711 (rev 10= ) (prog-if 00 [Normal decode]) > > > > - Flags: bus master, fast devsel, latency 0, IRQ 41 > > Bus: primary=3D00, secondary=3D01, subordinate=3D01, sec-laten= cy=3D0 > > I/O behind bridge: 00000000-00000fff [size=3D4K] > > Memory behind bridge: f8000000-f80fffff [size=3D1M] > > > > > > > > @@ -9,13 +9,15 @@ > > Capabilities: [100] Advanced Error Reporting > > Capabilities: [180] Vendor Specific Information: ID=3D0000 Rev=3D0 Len= =3D028 > > Capabilities: [240] L1 PM Substates > > > > - Kernel driver in use: pcieport > > > > > > > > 01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Contr= oller (rev 01) (prog-if 30 [XHCI]) > > Subsystem: VIA Technologies, Inc. VL805 USB 3.0 Host Controller > > > > - Flags: bus master, fast devsel, latency 0, IRQ 82 > > > > > > - Memory at f8000000 (64-bit, non-prefetchable) > > > > > > > > - Flags: bus master, fast devsel, latency 0, IRQ 42 > > > > > > - Memory at 600000000 (64-bit, non-prefetchable) [size=3D4K] > > Capabilities: [80] Power Management version 3 > > Capabilities: [90] MSI: Enable+ Count=3D1/4 Maskable- 64bit+ > > Capabilities: [c4] Express Endpoint, MSI 00 > > Capabilities: [100] Advanced Error Reporting > > > > > > - Kernel driver in use: xhci_hcd > > > > > > > > Is this odd? Expected/reasonable? > > f8000000 vs. 600000000 Looks to be an odd lspci -v variation, > with FreeBSD apparently showing the figure as if -b had been > supplied on the command line ("Bus-centric view"): ubuntu > shows f8000000 when the -b is supplied. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Oct 4 08:42:05 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 1EB573FF3BA for ; Sun, 4 Oct 2020 08:42:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (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 4C3xzv42Chz4QKN for ; Sun, 4 Oct 2020 08:42:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 1MVdSeUVM1lC6pKLeQAanv65rqp8IXqjE4_lBjVyYsJ1rM_ThQFs0oOo90qofln Txt7WvmxX8NzK_G_sHPrA.rBMaNvVgpb56DExGlGMPpuTqHuIOJXtIdy0kiudwUY9T8OeRjU.Atu 4dhw8vLErYPxb1MI5.f0QgtDSdJQEhF7Lkk0wWzmYfh8tCyj_jdmgJnzAFt6D2z7UX4yxkPAdXYW C61c.26XKfpjAYJQYfpvRudWcgi3gPAOOpLku233tkFFQTNHbgaQPuq9BaZ6RwYmEyzoHAXTZyOl L89semETYTsOeysHm67Nl_BBRR7JEtCyOHCSpFCr1iNxjHNF_2yOI8MjWXqyCHBXdZjtOw7FYEt9 P875S6IVRlMCrfy3cDgLhPbVZdB5u0wB4foH5f28o_nzosIzVnBpp.Cp1tImUhIByxRFcaGDgQYi zVOt3439Tvw2Fc2ViFSkRUKzEjPC0mg11QGwy6e5HjMYSrAOuNy1lzcrAb_24UQai1hY6nvkymOa Pm0lM6JU3gDJzeC2AqB2.yIVCyqVNlc2uXVr0vD0Kil4TUhHysC6fqcZKkVPbmEHhLseSdT2wcwY uUTA60uea1tdRJRyiPrXjLRg5uPh664sRvr5C.cRig51eaxnrPO..ISA9H4wMzuh7mU3oK5I2IP. Thoc1aIME6XCr3_yXBPYvtqsm17imNkY0LSxy4zJDb.167rnBuw25vdqk5eWoLdQZCY3UDxw3plH CvUrb4oV1z7OBHygRHgvMFq.NuR7TLTjy6bPApmAHVtvt4CuT6D8Nwq1bupdxokXH3ZNwoLGUX6Y OBQ93ebFYr87dGnxdg8kWR0YfS1N2cHsnQhFHX63QmFaYozRDNQhjDvFgMF8fuON1TALCqe9XrZ0 4Lkx7qpwNfa5Cc1mrd0T_xfMebIfgt_tJUrB4U6o7h9ST2j5mGrhBScW05opznPXmCAV7D9278GA VBfWqa3sBcfmEMOTEOr4iVXQTp6XRNk05eyQhUDfhSy.oBlepXdItVp3Ugjux9JWS9yT3c5H0LPd zI0clksp24eg7C0A9CAoBzkCwwamdxqplC8liwWSvDUr7AJNuUbJ4qcGAXqshJqz_..CI..n.xQz 8Mqydvcq1BsA3hVEdhoUjJzoTWGDIgEUj_RsPpK_6Tlp2pkLkihXLw4APE_0RG3wOAxJ8BzvxmYO fnB1AgA6xPZ8lRfoibJNCWXinKNR4WCJN3KrEHydXVbn5DaEkyqlOTNR1mleqQGlQP2ivEXFcEDU 4CWShqcUAS2FbtF3nQnfQKYNSOiRV1AnCIzvnlzkl4D3Jwu5mh1yXO3fZfbTw._TJ1wTA4AgLt8m RAGk6NBxzwYkQ.pc0N2n_T8oV0hwerOg1XBZHVEfro6K6478CDsvDTts7dAFIXLFCsKHeZ.qdVgW RE5ZLtwT5unEGHrAfcMtTewkH1ZTTJHQMwvHJit7.37f_UOBj6AvwgSMW30wsZRpXAcapUcCeXja DX1NFouZEq.deplNnrEI95648FWHI8yJpr8WYAG4ZzmIQ4zK33Ke1ZOOKUqrDYdO1_3rUTcZSA8v B Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 4 Oct 2020 08:42:00 +0000 Received: by smtp410.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b879e65c925ff4d0ac09f99e954ce8bd; Sun, 04 Oct 2020 08:41:55 +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: Re: rpi4 FreeBSD vs. ubuntu u-boot fdt print / memereserve difference (lack of reserve in FreeBSD context), 0x3b400000 vs. DMA_HIGH_LIMIT being 0x3c000000 Date: Sun, 4 Oct 2020 01:41:54 -0700 References: <1A13F7B5-F8C3-4022-939C-2992E53D1DF1@yahoo.com> <01C14FE4-C2A6-4459-A5EE-AE33045FAF42@yahoo.com> To: Robert Crowston , freebsd-arm In-Reply-To: <01C14FE4-C2A6-4459-A5EE-AE33045FAF42@yahoo.com> Message-Id: <4D5162C2-592D-439C-9660-33A94DA5C807@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C3xzv42Chz4QKN X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.07 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.53)[-0.535]; FREEMAIL_TO(0.00)[protonmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email]; NEURAL_HAM_LONG(-1.04)[-1.039]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[0.0.0.0:email]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; 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, 04 Oct 2020 08:42:05 -0000 On 2020-Oct-3, at 20:15, Mark Millard wrote: > On 2020-Oct-3, at 16:10, Mark Millard wrote: >=20 >> On 2020-Oct-3, at 15:20, Mark Millard wrote: >>=20 >>> Another FreeBSD vs. ubuntu context difference, this time in the >>> fdt print / output . . . >>>=20 >>> The ubuntu u-boot has (fdt print / output): >>>=20 >>> memreserve =3D <0x3b400000 0x04c00000>; >>> . . . (Note: 0x3b400000+0x04c00000 =3D=3D 0x40000000) . . . >>>=20 >>> #address-cells =3D <0x00000002>; >>> #size-cells =3D <0x00000001>; >>> . . . >>> axi { >>> vc_mem { >>> reg =3D <0x3ec00000 0x40000000 0xc0000000>; >>> }; >>> Note: "vc_mem is solely used as a mechanism for passing a = couple >>> of parameters through from the firmware to vcdbg" >>> End note >>> }; >>>=20 >>> . . . ( boot args has: vc_mem.mem_base=3D0x3ec00000 = vc_mem.mem_size=3D0x40000000 ) . . . >>>=20 >>> reserved-memory { >>> #address-cells =3D <0x00000002>; >>> #size-cells =3D <0x00000001>; >>> ranges; >>> phandle =3D <0x0000003d>; >>> linux,cma { >>> compatible =3D "shared-dma-pool"; >>> size =3D <0x04000000>; >>> reusable; >>> linux,cma-default; >>> alloc-ranges =3D <0x00000000 0x00000000 = 0x30000000>; >>> phandle =3D <0x0000003e>; >>> }; >>> }; >>> . . . (I split the reg into lines below) . . . >>> memory@0 { >>> device_type =3D "memory"; >>> reg =3D <0x00000000 0x00000000 0x3b400000 >>> 0x00000000 0x40000000 0xbc000000 >>> 0x00000001 0x00000000 0x80000000 >>> 0x00000001 0x80000000 0x80000000>; >>> }; >>> . . . (Note: 0x40000000+0xbc000000 =3D=3D 0xFC000000) . . . >>>=20 >>> (I've ignored gpiomem above and below.) >>>=20 >>> It appears to be that the memreserve may be important >>> to have. The above may also suggest that FreeBSD's: >>>=20 >>> #define DMA_HIGH_LIMIT 0x3c000000 >>>=20 >>> may be a little too large (< or <=3D 0x3b400000 ?). >>>=20 >>> FreeBSD u-boot reports just: >>>=20 >>> /memreserve/ 0x0 0x1000; >>> . . . >>> memory@0 { >>>=20 >>> device_type =3D "memory"; >>> reg =3D <0x0 0x0 0x0>; >>> }; >>>=20 >>> And so does not indicate anything special for either of >>> (showing begin/end points): >>>=20 >>> 0x3b400000..0x3FFFFFFF (in use by the vc?) >>> 0xFC000000..0xFFFFFFFF (I/O peripheral area and such?) >>>=20 >>> The context is an 8 GiByte RPi4 in both examples. Various >>> details would vary on 1 GiByte and 2 GiByte RPi4Bs and >>> some in memory@0 on the 4 GiBYTe RPi4B. >>=20 >> Turns out that rpi_DATA_2711_1p0.pdf 's "Figure 1. BCM2711 >> Address Maps" shows this "SDRAM (for the VC)" area in the >> two 35-bit Address Maps, showing 0x0_4000_0000 as the >> next address after the area in both diagrams --and notes >> for area for each diagram: >>=20 >> QUOTE >> Size of VC SDRAM >> determined by >> config.txt >> END QUOTE >>=20 >> But ubuntu uses includes and such so overall there >> are the following .txt files ( cmdline.txt being for >> a different purpose ): >>=20 >> # ls -ld /boot/firmware/*.txt >> -rwxr-xr-x 1 root root 141 Jul 31 16:48 /boot/firmware/cmdline.txt >> -rwxr-xr-x 1 root root 1117 Jul 31 16:48 /boot/firmware/config.txt >> -rwxr-xr-x 1 root root 327 Jul 31 16:48 /boot/firmware/syscfg.txt >> -rwxr-xr-x 1 root root 251 Sep 26 22:14 /boot/firmware/usercfg.txt >>=20 >> config.txt includes syscfg.txt and usercfg.txt . >>=20 >> config.txt uses the [pi4], [pi2], [pi3], and [all] section >> notation as well. >>=20 >> Looks like one of u-boot's jobs is to figure out the figures >> that go in (base then size): >>=20 >> memreserve =3D <0x???????? 0x????????>; >>=20 >> (such that the total is 0x40000000 for the RPi4B) in order >> to protect the VC SDRAM area. >>=20 >>=20 >> The diagrams also indicate that 0xFC000000..0xFFFFFFFF is >> for when "low Perioheral" mode is in use, listing ("up >> to H" not including H): >>=20 >> ARM Local peripherals from 0x0_FF80_0000 up to 0x1_0000_0000 >> and: >> Main peripherals from 0x0_FC00_0000 up to 0x0_FF80_0000 >>=20 >> Otherwise they are listed at: >>=20 >> ARM Local peripherals from 0x4_C000_0000 up to 0x5_0000_0000 >> and: >> Main peripherals from 0x4_7C00_0000 up to 0x4_8000_0000 >>=20 >> I gather the ubuntu "fdt print /" result implies that ubuntu >> is using "Low Peripheral" mode (or at least allowing for it). >>=20 >> There are some other "Reserved" areas and the special areas >> that are "two L2 cache aliases (one allocating, one >> non-allocating) which cache (only) the first 1GB of SDRAM". >> if these are all counted then 0x4_0000_0000 up to >> 0x6_0000_0000 is all some form of special-use area in >> both diagrams and 0x6_0000_0000 through 0x7_FFFF_FFFF is the >> PCIe area in both diagams. >=20 >=20 > Looks like in ubuntu land the following from the dtb/fdt > work together(?) to cover avoiding memory that is > inappropriate for use for low-RAM DMA activity: >=20 > U-Boot> fdt print / > / { > memreserve =3D <0x3b400000 0x04c00000>; > . . . (Note: 0x3b400000+0x04c00000 =3D=3D 0x40000000) . . . > reserved-memory { > #address-cells =3D <0x00000002>; > #size-cells =3D <0x00000001>; > ranges; > phandle =3D <0x0000003d>; > linux,cma { > compatible =3D "shared-dma-pool"; > size =3D <0x04000000>; > reusable; > linux,cma-default; > alloc-ranges =3D <0x00000000 0x00000000 = 0x30000000>; > phandle =3D <0x0000003e>; > }; > }; > . . . >=20 > where: >=20 > alloc-ranges =3D <0x00000000 0x00000000 0x30000000> indicates a low > memory range to use for "shared-dma-pool" DMA activity. >=20 > memreserve =3D <0x3b400000 0x04c00000> indicates the actual > area in use for gnu_mem=3D/gnu_mem_1024=3D material and so indicates > an area that must be avoided. It appears that this adjusts based > on what config.txt has for (either of) gnu_mem=3D/gnu_mem_1024=3D . >=20 > It appears that the alloc-ranges=3D... above allows for the maximum > recommended gpu_mem/gnu_mem_1024 figure for the RPi4B and so, > if that limit is honored, avoids overlapping the memreserve. This > may suggest that your code should change to: >=20 > #define DMA_HIGH_LIMIT 0x30000000 >=20 >=20 > XHCI and the type-DMA4 engine use need to explicitly avoid the > memreserve area. The old normal/LITE DMA could be redirected to > use a different 1 GiByte range (shifted above the memreserve > when there is enough RAM to do so). >=20 >=20 > The more modern dtb/fdt's that I use in some contexts have the > reserved-memory linux,cma alloc-ranges. (I'm not claiming such > information is translated to uefi/ACPI.) But the old dtb/fdt's > used with FreeBSD u-boot do not indicate those alloc-ranges. >=20 > The u-boot for FreeBSD that I'm using (from ports) does not > generate the memreserve material so neither the old or new > fdt's end up with such material. Looking at the FreeBSD boot-time memory map on the 8 GiByte RPi4B via a u-boot based boot shows that the address ranges 0x3b400000..0x3e512fff and 0x3ebec000..0x3fffffff are not referenced below (I inserted some notes): Type Physical Virtual #Pages Attr Reserved 000000000000 0 00000002 WB=20 ConventionalMemory 000000002000 2000 00007eef WB=20 ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB=20 ConventionalMemory 000007f0f000 7f0f000 00029f71 WB=20 BootServicesData 000031e80000 31e80000 00000001 WB=20 LoaderData 000031e81000 31e81000 00008001 WB=20 LoaderCode 000039e82000 39e82000 000000ad WB=20 Reserved 000039f2f000 39f2f000 00000007 WB=20 BootServicesData 000039f36000 39f36000 00000001 WB=20 RuntimeServicesData 000039f37000 39f37000 00000001 WB RUNTIME BootServicesData 000039f38000 39f38000 00000002 WB=20 Reserved 000039f3a000 39f3a000 00000001 WB=20 BootServicesData 000039f3b000 39f3b000 00000002 WB=20 RuntimeServicesData 000039f3d000 39f3d000 00000002 WB RUNTIME Reserved 000039f3f000 39f3f000 00000001 WB=20 BootServicesData 000039f40000 39f40000 00000001 WB=20 Reserved 000039f41000 39f41000 00000001 WB=20 BootServicesData 000039f42000 39f42000 00000002 WB=20 Reserved 000039f44000 39f44000 00000001 WB=20 LoaderData 000039f45000 39f45000 0000140b WB=20 RuntimeServicesCode 00003b350000 3b350000 00000010 WB RUNTIME LoaderData 00003b360000 3b360000 000000a0 WB=20 NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all (even = later) NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even = later) BootServicesData 000040000000 40000000 000bc000 WB=20 MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME BootServicesData 000100000000 100000000 00100000 WB=20 Physical memory chunk(s): 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages) 0x07f0f000 - 0x39f2efff, 800 MB ( 204832 pages) 0x39f36000 - 0x39f39fff, 0 MB ( 4 pages) 0x39f3b000 - 0x39f3efff, 0 MB ( 4 pages) 0x39f40000 - 0x39f40fff, 0 MB ( 1 pages) 0x39f42000 - 0x39f43fff, 0 MB ( 2 pages) 0x39f45000 - 0x3b34ffff, 20 MB ( 5131 pages) 0x3b360000 - 0x3b3fffff, 0 MB ( 160 pages) NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all (even = later) NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even = later) 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages) Excluded memory regions: 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc=20 0x32000000 - 0x33451fff, 20 MB ( 5202 pages) NoAlloc=20 0x39f2f000 - 0x39f35fff, 0 MB ( 7 pages) NoAlloc=20 0x39f37000 - 0x39f37fff, 0 MB ( 1 pages) NoAlloc=20 0x39f3a000 - 0x39f3afff, 0 MB ( 1 pages) NoAlloc=20 0x39f3d000 - 0x39f3ffff, 0 MB ( 3 pages) NoAlloc=20 0x39f41000 - 0x39f41fff, 0 MB ( 1 pages) NoAlloc=20 0x39f44000 - 0x39f44fff, 0 MB ( 1 pages) NoAlloc=20 0x3b350000 - 0x3b35ffff, 0 MB ( 16 pages) NoAlloc=20 NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all (even = above) 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20 NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even = above) 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 Physical memory chunk(s): 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) 0x00000007f0f000 - 0x00000031ffffff, 705630208 bytes (172273 pages) 0x00000033452000 - 0x00000039f2efff, 112054272 bytes (27357 pages) 0x00000039f36000 - 0x00000039f36fff, 4096 bytes (1 pages) 0x00000039f38000 - 0x00000039f39fff, 8192 bytes (2 pages) 0x00000039f3b000 - 0x00000039f3cfff, 8192 bytes (2 pages) 0x00000039f40000 - 0x00000039f40fff, 4096 bytes (1 pages) 0x00000039f42000 - 0x00000039f43fff, 8192 bytes (2 pages) 0x00000039f45000 - 0x0000003b34ffff, 21016576 bytes (5131 pages) 0x0000003b360000 - 0x0000003b3fffff, 655360 bytes (160 pages) NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all (even = above) NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even = above) 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) 0x00000100000000 - 0x000001f3840fff, 4085518336 bytes (997441 pages) So: #define DMA_HIGH_LIMIT 0x3c000000 leads to the range for potential DMA use seeming to overlap 0x3b400000..0x3bffffff (which is not mentioned above). Should the missing ranges have a classification above? Is the lack of mention supposed to prevent the range of memory's use for DMA activity? I'll note that there are a bunch of explicitly "Excluded memory regions" that overlap with the range for potential DMA use as well. Note: Use of gpu_mem_1024=3D256 in config.txt instead produces (notes added again): Type Physical Virtual #Pages Attr Reserved 000000000000 0 00000002 WB=20 ConventionalMemory 000000002000 2000 00007eef WB=20 ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB=20 ConventionalMemory 000007f0f000 7f0f000 0001eb71 WB=20 BootServicesData 000026a80000 26a80000 00000001 WB=20 LoaderData 000026a81000 26a81000 00008001 WB=20 LoaderCode 00002ea82000 2ea82000 000000ad WB=20 Reserved 00002eb2f000 2eb2f000 00000007 WB=20 BootServicesData 00002eb36000 2eb36000 00000001 WB=20 RuntimeServicesData 00002eb37000 2eb37000 00000001 WB RUNTIME BootServicesData 00002eb38000 2eb38000 00000002 WB=20 Reserved 00002eb3a000 2eb3a000 00000001 WB=20 BootServicesData 00002eb3b000 2eb3b000 00000002 WB=20 RuntimeServicesData 00002eb3d000 2eb3d000 00000002 WB RUNTIME Reserved 00002eb3f000 2eb3f000 00000001 WB=20 BootServicesData 00002eb40000 2eb40000 00000001 WB=20 Reserved 00002eb41000 2eb41000 00000001 WB=20 BootServicesData 00002eb42000 2eb42000 00000002 WB=20 Reserved 00002eb44000 2eb44000 00000001 WB=20 LoaderData 00002eb45000 2eb45000 0000140b WB=20 RuntimeServicesCode 00002ff50000 2ff50000 00000010 WB RUNTIME LoaderData 00002ff60000 2ff60000 000000a0 WB=20 NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all (even = below) NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even = below) BootServicesData 000040000000 40000000 000bc000 WB=20 MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME BootServicesData 000100000000 100000000 00100000 WB=20 Physical memory chunk(s): 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages) 0x07f0f000 - 0x2eb2efff, 620 MB ( 158752 pages) 0x2eb36000 - 0x2eb39fff, 0 MB ( 4 pages) 0x2eb3b000 - 0x2eb3efff, 0 MB ( 4 pages) 0x2eb40000 - 0x2eb40fff, 0 MB ( 1 pages) 0x2eb42000 - 0x2eb43fff, 0 MB ( 2 pages) 0x2eb45000 - 0x2ff4ffff, 20 MB ( 5131 pages) 0x2ff60000 - 0x2fffffff, 0 MB ( 160 pages) NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all (even = below) NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even = below) 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages) Excluded memory regions: 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc=20 0x26c00000 - 0x28051fff, 20 MB ( 5202 pages) NoAlloc=20 0x2eb2f000 - 0x2eb35fff, 0 MB ( 7 pages) NoAlloc=20 0x2eb37000 - 0x2eb37fff, 0 MB ( 1 pages) NoAlloc=20 0x2eb3a000 - 0x2eb3afff, 0 MB ( 1 pages) NoAlloc=20 0x2eb3d000 - 0x2eb3ffff, 0 MB ( 3 pages) NoAlloc=20 0x2eb41000 - 0x2eb41fff, 0 MB ( 1 pages) NoAlloc=20 0x2eb44000 - 0x2eb44fff, 0 MB ( 1 pages) NoAlloc=20 0x2ff50000 - 0x2ff5ffff, 0 MB ( 16 pages) NoAlloc=20 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20 NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all (even = above) NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even = above) 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 Physical memory chunk(s): 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) 0x00000007f0f000 - 0x00000026bfffff, 516886528 bytes (126193 pages) 0x00000028052000 - 0x0000002eb2efff, 112054272 bytes (27357 pages) 0x0000002eb36000 - 0x0000002eb36fff, 4096 bytes (1 pages) 0x0000002eb38000 - 0x0000002eb39fff, 8192 bytes (2 pages) 0x0000002eb3b000 - 0x0000002eb3cfff, 8192 bytes (2 pages) 0x0000002eb40000 - 0x0000002eb40fff, 4096 bytes (1 pages) 0x0000002eb42000 - 0x0000002eb43fff, 8192 bytes (2 pages) 0x0000002eb45000 - 0x0000002ff4ffff, 21016576 bytes (5131 pages) 0x0000002ff60000 - 0x0000002fffffff, 655360 bytes (160 pages) NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all (even = above) NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even = above) 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) 0x00000100000000 - 0x000001f3cb5fff, 4090191872 bytes (998582 pages) (Note: gpu_mem_1024=3D16 leads to the rpi firmware messing up and being unable to read the microsd card for later rpi firmware files that it needs. It actually ended up doing a USB3 SSD based boot, in my context a uefi/ACPI boot.) gpu_mem_1024=3D32 produced (no notes this time): Type Physical Virtual #Pages Attr Reserved 000000000000 0 00000002 WB=20 ConventionalMemory 000000002000 2000 00007eef WB=20 ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB=20 ConventionalMemory 000007f0f000 7f0f000 0002cb71 WB=20 BootServicesData 000034a80000 34a80000 00000001 WB=20 LoaderData 000034a81000 34a81000 00008001 WB=20 LoaderCode 00003ca82000 3ca82000 000000ad WB=20 Reserved 00003cb2f000 3cb2f000 00000007 WB=20 BootServicesData 00003cb36000 3cb36000 00000001 WB=20 RuntimeServicesData 00003cb37000 3cb37000 00000001 WB RUNTIME BootServicesData 00003cb38000 3cb38000 00000002 WB=20 Reserved 00003cb3a000 3cb3a000 00000001 WB=20 BootServicesData 00003cb3b000 3cb3b000 00000002 WB=20 RuntimeServicesData 00003cb3d000 3cb3d000 00000002 WB RUNTIME Reserved 00003cb3f000 3cb3f000 00000001 WB=20 BootServicesData 00003cb40000 3cb40000 00000001 WB=20 Reserved 00003cb41000 3cb41000 00000001 WB=20 BootServicesData 00003cb42000 3cb42000 00000002 WB=20 Reserved 00003cb44000 3cb44000 00000001 WB=20 LoaderData 00003cb45000 3cb45000 0000140b WB=20 RuntimeServicesCode 00003df50000 3df50000 00000010 WB RUNTIME LoaderData 00003df60000 3df60000 000000a0 WB=20 BootServicesData 000040000000 40000000 000bc000 WB=20 MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME BootServicesData 000100000000 100000000 00100000 WB=20 Physical memory chunk(s): 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages) 0x07f0f000 - 0x3cb2efff, 844 MB ( 216096 pages) 0x3cb36000 - 0x3cb39fff, 0 MB ( 4 pages) 0x3cb3b000 - 0x3cb3efff, 0 MB ( 4 pages) 0x3cb40000 - 0x3cb40fff, 0 MB ( 1 pages) 0x3cb42000 - 0x3cb43fff, 0 MB ( 2 pages) 0x3cb45000 - 0x3df4ffff, 20 MB ( 5131 pages) 0x3df60000 - 0x3dffffff, 0 MB ( 160 pages) 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages) Excluded memory regions: 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc=20 0x34c00000 - 0x36051fff, 20 MB ( 5202 pages) NoAlloc=20 0x3cb2f000 - 0x3cb35fff, 0 MB ( 7 pages) NoAlloc=20 0x3cb37000 - 0x3cb37fff, 0 MB ( 1 pages) NoAlloc=20 0x3cb3a000 - 0x3cb3afff, 0 MB ( 1 pages) NoAlloc=20 0x3cb3d000 - 0x3cb3ffff, 0 MB ( 3 pages) NoAlloc=20 0x3cb41000 - 0x3cb41fff, 0 MB ( 1 pages) NoAlloc=20 0x3cb44000 - 0x3cb44fff, 0 MB ( 1 pages) NoAlloc=20 0x3df50000 - 0x3df5ffff, 0 MB ( 16 pages) NoAlloc=20 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 Physical memory chunk(s): 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) 0x00000007f0f000 - 0x00000034bfffff, 751767552 bytes (183537 pages) 0x00000036052000 - 0x0000003cb2efff, 112054272 bytes (27357 pages) 0x0000003cb36000 - 0x0000003cb36fff, 4096 bytes (1 pages) 0x0000003cb38000 - 0x0000003cb39fff, 8192 bytes (2 pages) 0x0000003cb3b000 - 0x0000003cb3cfff, 8192 bytes (2 pages) 0x0000003cb40000 - 0x0000003cb40fff, 4096 bytes (1 pages) 0x0000003cb42000 - 0x0000003cb43fff, 8192 bytes (2 pages) 0x0000003cb45000 - 0x0000003df4ffff, 21016576 bytes (5131 pages) 0x0000003df60000 - 0x0000003dffffff, 655360 bytes (160 pages) 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) 0x00000100000000 - 0x000001f372afff, 4084379648 bytes (997163 pages) I wonder if such could be contributing to why DMA_HIGH_LIMIT had to be set smaller than the 3 GiByte limit: to under a 1 GiByte limit. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Oct 5 05:53:18 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 121DC3F8B67 for ; Mon, 5 Oct 2020 05:53:18 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C4VBj21fcz4j9p for ; Mon, 5 Oct 2020 05:53:17 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-lf1-x12a.google.com with SMTP id b12so9347090lfp.9 for ; Sun, 04 Oct 2020 22:53:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=pM3j1oy4971dx01ZOwKXhucoQo4bHnDSDt7OWg8491c=; b=cao8eogNPX2FIEMmC45VqxizZJ6iqi3WkXQ/nSUDWMUAIK45zOXSYQi0hvwoDoJhKn C7ah9vci13oAUAAU7LjQ2XP5N5DxZRohy2mfVnuty1280dhGnNx+hoUjXksFLp2tK072 7oIOGNDE3XDrbCb5Yf0CVJ2XsQ3bExYami4BD0KZreI0gPErLl2zetfLNLnciG0NVlQ0 LhuCl/+gG4JuOJMyqXXwzLnQNMHmtp4AySy9SUW1SR5yguz+X8SjJcjpUYt8BGmtGYJh fdSWeq2YEWLwesYC0WNfFsiS8S5KvyEEuZ4f8twL8/4CQFMKyJV8WbYW7xW4DmKcvGoq 7xQQ== X-Gm-Message-State: AOAM530WBbRB3WwdFcjmez/E40khJQUZkHA3UpCTA48gOgOOP6E8jOD2 R48Qb8KbPyjB8v/Yo4BoFM0wKWYxjKI+ng== X-Google-Smtp-Source: ABdhPJzZtSO6wanA5nSB32HtF+vG/FpZF/kAa3X7SpunfvQyWV4OM4aLiud6qQPoitaWHb3x3vPjSw== X-Received: by 2002:a5d:5602:: with SMTP id l2mr9983645wrv.410.1601876732117; Sun, 04 Oct 2020 22:45:32 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-109-085.46.114.pool.telefonica.de. [46.114.109.85]) by smtp.googlemail.com with ESMTPSA id w81sm11573176wmg.47.2020.10.04.22.45.31 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Oct 2020 22:45:31 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: RPI4 U-Boot 2020.10-rc5 please test xhci feature Message-Id: <81140AD2-2AAF-4378-ABB2-8F5B608DE7F7@googlemail.com> Date: Mon, 5 Oct 2020 07:45:29 +0200 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C4VBj21fcz4j9p X-Spamd-Bar: ++++++++++++ X-Spamd-Result: default: False [12.33 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,body]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(0.00)[googlemail.com,quarantine]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[46.114.109.85:received]; R_DKIM_ALLOW(0.00)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.109.85:received]; FROM_HAS_DN(0.00)[]; SH_AUTHBL_RECEIVED(4.00)[46.114.109.85:received]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.81)[0.807]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.04)[1.038]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; NEURAL_SPAM_LONG(0.99)[0.989]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-Spam: Yes 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: Mon, 05 Oct 2020 05:53:18 -0000 ( https://wiki.freebsd.org/arm/Raspberry%20Pi#RPI4 ) new compiled U-Boot version U-Boot 2020.10-rc5 =E2=80=94- 1st try with default settings/files/configuratios ext. = USB-SSD/ no SD-card present:=E2=80=94 =E2=80=A6=E2=80=A6=E2=80=A6..U-Boot 2020.10-rc5 (Oct 05 2020 - 03:08:23 = +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03114) MMC: mmc@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found=E2=80=A6=E2=80=A6=E2=80=A6. =E2=80=94 2020.10-rc5 boots fine from SD-card happy testing=20 thanks Regards Klaus From owner-freebsd-arm@freebsd.org Mon Oct 5 08:47:55 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 B3E2F3FC5A1 for ; Mon, 5 Oct 2020 08:47:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4Z4C3pfQz4rWg for ; Mon, 5 Oct 2020 08:47:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 80B173FC3C6; Mon, 5 Oct 2020 08:47:55 +0000 (UTC) Delivered-To: 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 7F4653FC719 for ; Mon, 5 Oct 2020 08:47:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C4Z4B1Kgqz4rCH for ; Mon, 5 Oct 2020 08:47:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From; bh=oBjf4KEgKSFxj/O5jRa7bAqA3/fZRWuddt1Mf2U4d3w=; b=N+YJzd6tsX2NGo4VWln257BuWrGpoxX/uW57h/BWGDm9C9W39Wy6FTdD8Z8O9NUNgaCRnLL9qHzNKBJux17dWpjqJgjogXGFaWDGzjibRe0zGbeyjb7PuFyRUJKaS01YqX1F0K7HYFtCFFYgF0M/fIlPQSUSbelWiyDtLXQ2mFd4DHjvg+VTMkrWIkCyoKUqK8Y0EPl7xhoIBjGxYIeuRibYqewODvY7j86d2FPaK25bTcmUZ7s2O9jWfRt4OuQXksKwBmO1CjawJ9a2l3sGumXrGmDU5ajdruTGkyRaG9QW/cXJlMSCdc8uTv4n6lBbMq2JNpURnu6SaspWGI0PbQ==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1kPM9o-000DU7-BC for arm@freebsd.org; Mon, 05 Oct 2020 11:47:44 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: nanopi/allwinner i2c not working. Message-Id: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> Date: Mon, 5 Oct 2020 11:47:43 +0300 To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4C4Z4B1Kgqz4rCH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=N+YJzd6t; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.55 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.99)[-0.995]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.01)[-1.005]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-0.25)[-0.245]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[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: Mon, 05 Oct 2020 08:47:55 -0000 Hi, latest 12.2-stable r366421, when nothing is connected, i2c -s just hangs and reboot is required. if anything is connected, it just goes into a loop: # i2c -s Hardware may not support START/STOP scanning; trinterrupt storm detected = on "gic0,s6:"; throttling interrupt source ying less-reliable read method. interrupt storm detected on "gic0,s6:"; throttling interrupt source interrupt storm detected on "gic0,s6:"; throttling interrupt source =E2=80=A6 im willing to help debug this, but need help. cheers, danny From owner-freebsd-arm@freebsd.org Mon Oct 5 12:10:00 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 A17714228C0 for ; Mon, 5 Oct 2020 12:10:00 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C4fYM46L6z3YpJ for ; Mon, 5 Oct 2020 12:09:59 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-qt1-x843.google.com with SMTP id j22so9276452qtj.8 for ; Mon, 05 Oct 2020 05:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=c8kuBvlMVT+T7JfFM0Ol6P7d6Axt5dd2wlpFI2NGrGo=; b=hdpao0is9bdMtxOEM4/vX6aJTau1C4NFiXqxmcaYfDg2xAjEQmXhklnRAPlq8KV/TE Wi76Gser5wFnEGJZ8tK5LPwxHe3jd4MdpFP2/WVBkYhR/EeVG5WQU3lGKl/trYS4sPAm n/FNQjwbev88kTBWHhK3K2x5V2TwPf7NJitRTucW+0GR2k/lGPJw+qptL3RKugb+d8hW IuloisE6A7MH4XTNmaWbsoONoUXQDPpjD/EH+izRR7Mn4X37h4tTGzpCyYWxm7ggwa4w t0tstyVisxGsm7bEQwYqE0r6DbjjLRh6Le2BaN4J8o/ZzVKRVLLH3tpv+eAzXv3WgCSL rFUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=c8kuBvlMVT+T7JfFM0Ol6P7d6Axt5dd2wlpFI2NGrGo=; b=kZJWme+an1I3899cas3KeOv4jZaVBMEzHsay/p5B3muqklIeJG4AzMDo3gAisdqoRx JEewRFTd2sCSHRJqNwIUiWFzz8N2tGukCVj0gJVRd0mW9mSZc04bcngNmDTFlQgWpfor 3P+mx2eV0Fu5DJYcUJp/iJYiqQumkNndUcT0iYZcGYZU6XV0o9OmmYllKj64uXnOCIIJ W/jEWeL6Xf3RTIksSq1Bi+TDYrMQTbAbK6esADYXb0F2bT5Q+9CBv/d9jkvStG6GqlFN RTq1/KSuDn9AgOXCY3vkDx/bb14q4NZdS+Q7Qm6BlqmfCJIVTNEQgyforPPokorytowq nUMg== X-Gm-Message-State: AOAM531/dAbPFf1hSXEki2lLu1qHSQL1opbWrD23R3eEozibRO4P5CFu 7X+pTBcDv9w1yZQbJAzwo2DB7jnWul9rRufBsk3QlOI9R9+Kcg== X-Google-Smtp-Source: ABdhPJxMQZt0JB5zC0ZqKTZtBnNpgPAy2ZL1URu97DW1nHvyEand82xXpuxwkk4ntlSIJNp+EooPyX3hUSqbsB41iF8= X-Received: by 2002:ac8:4e8c:: with SMTP id 12mr12210514qtp.91.1601899798433; Mon, 05 Oct 2020 05:09:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marcin Wojtas Date: Mon, 5 Oct 2020 14:09:47 +0200 Message-ID: Subject: Re: HEADS UP: NXP LS1046A SoC support in the tree To: Dan Kotowski Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4C4fYM46L6z3YpJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20150623.gappssmtp.com header.s=20150623 header.b=hdpao0is; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2607:f8b0:4864:20::843) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [-2.55 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[semihalf-com.20150623.gappssmtp.com:s=20150623]; FREEFALL_USER(0.00)[mw]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_LONG(-1.01)[-1.006]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::843:from]; NEURAL_HAM_SHORT(-0.25)[-0.251]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; 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: Mon, 05 Oct 2020 12:10:00 -0000 =C5=9Br., 30 wrz 2020 o 13:16 Dan Kotowski napisa=C5=82(a): > > > Hello all, > > > > On behalf of the Semihalf team I'd like to announce that starting from > > r365054 FreeBSD is ready to run NXP LS1046A system-on-a-chip with most > > of the interfaces supported. > > > > LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with > > integrated packet processing acceleration and high speed peripherals > > including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide > > range of networking, storage, security and industrial applications. It > > is confirmed that at least some parts of the kernel support (such as > > SDHCI) was successfully used on the Solid-Run LX2K Honeycomb > > development platform. > > > > Below is the port status together with the features, which were > > originally developed on top of the release/11.2.0 that have made their > > way to FreeBSD-HEAD: > > > > - LS1046A core support (Quad-CA72 SMP, timers, IRQS, UART) > > - already working in vanilla FreeBSD-HEAD before > > - DWC3 USB3.0 host controller driver (FreeBSD-HEAD > > version developed by manu@) > > > > - VF610 I2C controller (adjusted to work with the LS1046A) > > - TI LM75 temperature sensor (adjusted to work with the LS1046A) > > - QorIQ platform clockgen > > - LS1046A CPU clockgen > > - LS1046A GPIO > > - RX8803 I2C RTC > > - TCA6416 I2C GPIO expander > > - LS1046A AHCI > > - LS1046A SDHCI > > > > The major out-of-tree components are that albeit working on top of > > release/11.2.0, still require significant effort to adopt to > > FreeBSD-HEAD: > > > > - DPAA network controller support > > - QSPI controller support > > > > This was a joined effort of Semihalf and Alstom Group (main > > development sponsor), in particular: > > Laurent Muller > > David Fontaine > > Yannis Planus > > Artur Rojek > > Dawid G=C3=B3recki > > Kornel Dul=C4=99ba > > Kamil Koczurek > > Micha=C5=82 Stanek > > Jacek Klimkowicz > > > > Best regards, > > Marcin > > Excellent work, all! > > Do you expect to port up the DPAA controller support or will you be leavi= ng that for others? As of now unfortunately we do not have spare cycles to perform the upgrade (that may change, but I prefer not to commit to any timeframe whatsoever). Between 11.2 and HEAD there was a big contrib (sys/contrib/ncsw/) part update and our changes, using the latest common code from NXP are conflicting to a great extent. > > And have you looked into what it would take to add DPAA2 support as well? > Yes, briefly - the DPAA2 is more complex than its predecessor and it should be added from scratch, so it seems much more work to introduce the support for the NIC from the LX2K SoCs. Best regards, Marcin From owner-freebsd-arm@freebsd.org Mon Oct 5 13:53:21 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 F07E34256FD for ; Mon, 5 Oct 2020 13:53:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C4hrc2zhyz3gQm for ; Mon, 5 Oct 2020 13:53:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f196.google.com with SMTP id u9so7837544ilj.7 for ; Mon, 05 Oct 2020 06:53:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KxUhrMgt2pzloHS1wzxOMUImoGjYauAw+v3BXYnjkqQ=; b=cZPw6q5JRoVx/SlHPYLlSTVSLHWst5P+QzAtTXZia1u/Gk9iAM4ZhMLFvObWGKDcWk S7C0WdUQ9mc74V36iuz0xckXixC+E7AoHdaUReTd9AYN6b4z00trSG675c8GLz88FWHV HQCYhbwjFx/hIGrRQ5iV5EEjVBNfpL+y77lAzaCVpuGChfCqwu3w9NOVhemenKBik1r7 zq5OXZwyKOfICuqdIO/QbOSdg2NaigtsA9VmRKJ53U3cdgBSoa/smtwTBbW68qHaeP9A XcVFng1hYwrgzXj7SWusY8pynVSXvntNZ3OVMxTPs658dKsYfb9T2ctMKRpw/a65AP9/ WtoA== X-Gm-Message-State: AOAM531DJRJpdiIVyb7hYyYno2GyClRDwIsSwBg1AfIpFFj3M5RYD51m 51NnHvE5o0BCoanbmWmLWZpCA6gPfOGLCSAFCBwvzLklVN0= X-Google-Smtp-Source: ABdhPJxDhTZc2ur9Mtm8j2llinpreIC9Cxq5dP+kunrvzl0GB1qPqEtiR7cPjRKNvEVq/q6oHWYtCf6B4+9sJkPbH70= X-Received: by 2002:a92:ba1c:: with SMTP id o28mr7681112ili.182.1601905998163; Mon, 05 Oct 2020 06:53:18 -0700 (PDT) MIME-Version: 1.0 From: Ed Maste Date: Mon, 5 Oct 2020 09:53:06 -0400 Message-ID: Subject: BBB boot failure between r366365 and r366386 To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4C4hrc2zhyz3gQm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.196 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.77 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.973]; TO_DOM_EQ_FROM_DOM(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.87)[-0.867]; TO_DN_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.196:from]; NEURAL_SPAM_SHORT(0.07)[0.068]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.196:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; 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: Mon, 05 Oct 2020 13:53:22 -0000 Sometime after r366365 and up to r366365 BBB stopped booting in the HW test environment. Last successful build: https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-beaglebone-test/6663/ First failing build: https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-beaglebone-test/6664/ The kernel starts up but ends up in U-Boot again: ... ARM Debug Architecture not supported KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #288 r366440: Mon Oct 5 13:23:01 UTC 2020 root@FreeBSD-head-armv7-build_devtest.jail:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git llvmorg-11.0.0-rc5-0-g60a25202a7d) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. No PSCI/SMCCC call function found CPU: ARM Cortex-A8 r3p2 (ECO: 0x00000000) CPU Features: Thumb2, Security, VMSAv7 Optional instructions: UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 536055808 (511 MB) avail memory = 506232832 (482 MB) Texas Instruments AM335x Processor, Revision ES2.1 random: unblocking device. U-Boot SPL 2020.07 (Sep 24 2020 - 04:58:48 +0000) Trying to boot from MMC2 U-Boot 2020.07 (Sep 24 2020 - 04:58:48 +0000) CPU : AM335X-GP rev 2.1 Model: TI AM335x BeagleBone Black DRAM: 512 MiB ... From owner-freebsd-arm@freebsd.org Mon Oct 5 14:19:50 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 7575342600B for ; Mon, 5 Oct 2020 14:19:50 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4jRB1n0Rz3yd3 for ; Mon, 5 Oct 2020 14:19:50 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 3AE81425EB4; Mon, 5 Oct 2020 14:19:50 +0000 (UTC) Delivered-To: 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 3AAB8425CA6 for ; Mon, 5 Oct 2020 14:19:50 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C4jR93F87z3yV8 for ; Mon, 5 Oct 2020 14:19:49 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f41.google.com with SMTP id r127so6544111lff.12 for ; Mon, 05 Oct 2020 07:19:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=fxW+NUt2JraQPj/FenfGZiXXcRz10dBTGDfbNI+gUOo=; b=EoCI7bff5cNAz8VxwOYjfjHeTzNtpBv9aXF/i0lbZgfCOzFC9t4Bl9nmRT5A7V9g4j XcLm4uK+qvV8XOpfwLYrPPGT0sDd0MYFTbEip9XPzoScfNVdsvGPiE2Z5sI/cBWRZOtF FEzJrh+uH33HBlty8e3UxQIsKLW6pD2tfkfcV32OhlWyUS9t1PsMWFuq5ayyPm3tlCkQ CJd7Y1Gq+4uKHmFVgl6tZJXFmWGCoGCWd/b/tibXRv0kOMk2oR6+p+dAVLObtwPkp8Lo MICgX6Qn8wbm5rmm4XuSJmYLtftA0KaZrZaOaggWb7OZZOCT0mPuOaL9LzkOB7bg/rmq 5fPg== X-Gm-Message-State: AOAM530r9u3rFDc/H8FZ+9t/qJQ76ZXIVGNp2ZiaZuFBBkF8ek0D8ht3 QUR2U+I2jLg0zXhkqeKbLx2zFCgxPnKZgg== X-Google-Smtp-Source: ABdhPJzy31wIDyaCCnxhcby0s21BL5wN/8YYW58wuYUUXdBgsyS2uVaj+YLULP2apbHHX3qV8dZ5hA== X-Received: by 2002:ac2:4d0c:: with SMTP id r12mr2494487lfi.74.1601907587202; Mon, 05 Oct 2020 07:19:47 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id c131sm1994733lfg.48.2020.10.05.07.19.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2020 07:19:44 -0700 (PDT) Subject: Re: nanopi/allwinner i2c not working. To: Daniel Braniss , "freebsd-arm@freebsd.org" References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: Date: Mon, 5 Oct 2020 17:19:43 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4C4jR93F87z3yV8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-2.42 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.38)[-0.384]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.017]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.018]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.41:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.41:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[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: Mon, 05 Oct 2020 14:19:50 -0000 On 05/10/2020 11:47, Daniel Braniss wrote: > Hi, > latest 12.2-stable r366421, > > when nothing is connected, > i2c -s > just hangs > and reboot is required. > > > if anything is connected, it just goes into a loop: > # i2c -s > Hardware may not support START/STOP scanning; trinterrupt storm detected on "gic0,s6:"; throttling interrupt source > ying less-reliable read method. > interrupt storm detected on "gic0,s6:"; throttling interrupt source > interrupt storm detected on "gic0,s6:"; throttling interrupt source > … > > im willing to help debug this, but need help. What NanoPi model is this? Can you try to merge r365397 and check if it helps? If it does not, can you additionally try https://reviews.freebsd.org/D26049 ? If the problem persists, can you try setting hw.i2c.twsi_debug=1 and collect some logs? Thanks! -- Andriy Gapon From owner-freebsd-arm@freebsd.org Mon Oct 5 14:54:39 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 3DADD4267C5 for ; Mon, 5 Oct 2020 14:54:39 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4kCL5Qxnz41V7 for ; Mon, 5 Oct 2020 14:54:38 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id BA635426A1E; Mon, 5 Oct 2020 14:54:38 +0000 (UTC) Delivered-To: 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 BA3104267C4 for ; Mon, 5 Oct 2020 14:54:38 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C4kCL2NZlz41V6; Mon, 5 Oct 2020 14:54:38 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=Rsqb1ucdSbbdzsiuceuKWjw42kTGqRv15HiymABXUyc=; b=sK8d20UanOyrS+JgtxOpQUR7JARpi0W4Hbj3dKDWYgQAJk3jEoxSOfWc3iKTq5Jm1H5+p/QdX95XAA2gKefBVB9NYbPcXzpGQemTtEnaF/g2WvgKzI1Ex+l+10rTxG5KMEQkJ5IsKZkw9RBSLjqHwDmUY1oxN2U5/C9ClyUkTVykLUHw8MZXMoVqYrrI+OA3hNVE3bDH4OEJYduSQfZygdOSy+xdSt1vm+ilcIgOQ/zgHA84kg8qT7DAY4Lk38FRqc5VLhw8Xg1+kVNNH1PyIUpFA9Mhokl0kbZwXKKPII71LztJy9wcKx/Y7ueg8A1o6c+wEVR5w3RZhT1IwHk4Ng==; Received: from mbpro2.bk.cs.huji.ac.il ([132.65.179.20] helo=localhost.localdomain) by kabab.cs.huji.ac.il with esmtp id 1kPRsn-0000vg-MP; Mon, 05 Oct 2020 17:54:33 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.33\)) Subject: Re: nanopi/allwinner i2c not working. From: Daniel Braniss In-Reply-To: Date: Mon, 5 Oct 2020 17:54:32 +0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> To: Andriy Gapon X-Mailer: Apple Mail (2.3654.0.3.2.33) X-Rspamd-Queue-Id: 4C4kCL2NZlz41V6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL] 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: Mon, 05 Oct 2020 14:54:39 -0000 > On 5 Oct 2020, at 17:19, Andriy Gapon wrote: >=20 > On 05/10/2020 11:47, Daniel Braniss wrote: >> Hi, >> latest 12.2-stable r366421, >>=20 >> when nothing is connected, >> i2c -s >> just hangs >> and reboot is required. >>=20 >>=20 >> if anything is connected, it just goes into a loop: >> # i2c -s >> Hardware may not support START/STOP scanning; trinterrupt storm = detected on "gic0,s6:"; throttling interrupt source >> ying less-reliable read method. >> interrupt storm detected on "gic0,s6:"; throttling interrupt source >> interrupt storm detected on "gic0,s6:"; throttling interrupt source >> =E2=80=A6 >>=20 >> im willing to help debug this, but need help. >=20 > What NanoPi model is this? nanopi neo v1.3 and v1.4 >=20 > Can you try to merge r365397 and check if it helps? > If it does not, can you additionally try = https://reviews.freebsd.org/D26049 ? i think i tested this a while back, with the same results. >=20 > If the problem persists, can you try setting hw.i2c.twsi_debug=3D1 and = collect > some logs? last time i tested, debug was on, and it worked, but when turned off it = hung. I have to compile twsi with debug, and will report back ASAP. thanks, danny >=20 > Thanks! >=20 > --=20 > Andriy Gapon From owner-freebsd-arm@freebsd.org Mon Oct 5 19:56:47 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 CBEAE42E5DB for ; Mon, 5 Oct 2020 19:56:47 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C4rvy5t33z4R78 for ; Mon, 5 Oct 2020 19:56:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f47.google.com with SMTP id y20so10463928iod.5 for ; Mon, 05 Oct 2020 12:56:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=chQGcUPFrVq7oZsgKggDt4R7nj/clUeJMz3rGYE2Q3g=; b=hNQ3pVxv9uA+nQyLRXDvDbjqQnBoweAlx10DzmVbNOnxTqDH98eRbBec6dgEVMk80Z CaH+5XKA3Rgdywg2LMNFrS6f/GcS32oCUaFZ7yrKRdypG6SFL65nT1YKK1m+Ayyz8IIW ZgEgEPrBU2J0pdFtn/eNt2P0cFfGwHktvWp1/1LlhLKZ+7CNEJjKkQGc350NCV1zJrFv iuomx8o/AMlhRWqOi2HW7eQt6xqmFBnt33JHXQ8Bav/GOwvg24VhL/aaKB9B0BGss+Pj InlwsvI4bKRitqt5799MMYQeOdAn9shaKimAi8Da9DC5RkEdioc727ZYg9drMJv/uLUF VY5w== X-Gm-Message-State: AOAM532zXJKHsdAHyykYpsRSFD3QLEJy13uscob1+gZ0F/qQM9UD+vbv Ieh0lbaRiV60BbQNFJibFXd/XxG94RetzntC1Wq54BPDOyA= X-Google-Smtp-Source: ABdhPJzVZvbsfiKoENN0jQ7GZy9YuiJticW/UmygkIpg5qAXMdhfW8MjtpkxS3Mlhp0YXSvbEDpPrGJ8zaBPmp2KZFY= X-Received: by 2002:a05:6602:1d0:: with SMTP id w16mr1268513iot.102.1601927805414; Mon, 05 Oct 2020 12:56:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Mon, 5 Oct 2020 15:56:33 -0400 Message-ID: Subject: Re: BBB boot failure between r366365 and r366386 To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4C4rvy5t33z4R78 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.56 / 15.00]; TO_DOM_EQ_FROM_DOM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.91)[-0.907]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.47:from]; NEURAL_SPAM_SHORT(0.34)[0.340]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.47:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] 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: Mon, 05 Oct 2020 19:56:47 -0000 On Mon, 5 Oct 2020 at 09:53, Ed Maste wrote: > > Sometime after r366365 and up to r366365 BBB stopped booting in the HW > test environment. That should of course be after r366365 and up to (and including) r366386. Commits in this range include: r366366 flash: Add support for SPI flash s25fl512s r366367 Simplify the check for non-dumpable VM object types r366368 Implement sparse core dumps r366369 Add backlight subsystem r366371 Add pwm_backlight r366372 linuxkpi: Add backlight support r366373 linuxkpi: Add dmi_* function r366374 fixup modules/crypto: add dependency workaround r366376 Fix the INVARIANTS build for 32-bit platforms r366377 uma: Remove newlines from panic messages r366378 uma: Use LIFO for non-SMR bucket caches r366379 uma: Use the bucket cache for cross-domain allocations r366380 vm_pageout: Avoid rounding down the inactive scan target r366381 pwm_backlight: Restrict module to armv7 and aarch64 r366382 Fix LINT: Add backlight to NOTES r366384 cxgbe(4): set up the firmware flowc for the tid before send_abort_rpl r366386 pwm_backlight: Fix 32 bits build From owner-freebsd-arm@freebsd.org Tue Oct 6 02:10:27 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 450F84374FD; Tue, 6 Oct 2020 02:10:27 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C51C44ybkz3Y4Q; Tue, 6 Oct 2020 02:10:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 0962AUt1013302 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 5 Oct 2020 19:10:30 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 0962AUJG013301; Mon, 5 Oct 2020 19:10:30 -0700 (PDT) (envelope-from fbsd) Date: Mon, 5 Oct 2020 19:10:29 -0700 From: bob prohaska To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 Message-ID: <20201006021029.GA13260@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4C51C44ybkz3Y4Q X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [3.22 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.18)[0.184]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.44)[0.442]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.69)[0.693]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-arm]; MID_RHS_WWW(0.50)[] 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: Tue, 06 Oct 2020 02:10:27 -0000 Still seeing non-current pmap panics on the Pi3, this time a B+ running 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master) during a -j4 buildworld. The backtrace reports panic: non-current pmap 0xffffa00020eab8f0 cpuid = 0 time = 1601947137 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x30 pc = 0xffff00000072999c lr = 0xffff00000019ec8c sp = 0xffff00005d96c230 fp = 0xffff00005d96c430 db_trace_self_wrapper() at kdb_backtrace+0x38 pc = 0xffff00000019ec8c lr = 0xffff0000004b4984 sp = 0xffff00005d96c440 fp = 0xffff00005d96c500 kdb_backtrace() at vpanic+0x19c pc = 0xffff0000004b4984 lr = 0xffff0000004734c0 sp = 0xffff00005d96c510 fp = 0xffff00005d96c560 vpanic() at panic+0x44 pc = 0xffff0000004734c0 lr = 0xffff0000004730dc sp = 0xffff00005d96c570 fp = 0xffff00005d96c620 panic() at pmap_remove_pages+0x5d8 pc = 0xffff0000004730dc lr = 0xffff00000073fe58 sp = 0xffff00005d96c630 fp = 0xffff00005d96c690 pmap_remove_pages() at vmspace_exit+0xb0 pc = 0xffff00000073fe58 lr = 0xffff0000006c77a0 sp = 0xffff00005d96c6a0 fp = 0xffff00005d96c700 vmspace_exit() at exit1+0x470 pc = 0xffff0000006c77a0 lr = 0xffff00000042e5bc sp = 0xffff00005d96c710 fp = 0xffff00005d96c760 exit1() at sys_sys_exit+0x10 pc = 0xffff00000042e5bc lr = 0xffff00000042e148 sp = 0xffff00005d96c770 fp = 0xffff00005d96c7c0 sys_sys_exit() at syscallenter+0x104 pc = 0xffff00000042e148 lr = 0xffff0000007463dc sp = 0xffff00005d96c7d0 fp = 0xffff00005d96c7d0 syscallenter() at svc_handler+0x4c pc = 0xffff0000007463dc lr = 0xffff000000745df8 sp = 0xffff00005d96c7e0 fp = 0xffff00005d96c810 svc_handler() at do_el0_sync+0xf0 pc = 0xffff000000745df8 lr = 0xffff000000745c08 sp = 0xffff00005d96c820 fp = 0xffff00005d96c830 do_el0_sync() at handle_el0_sync+0x90 pc = 0xffff000000745c08 lr = 0xffff00000072c224 sp = 0xffff00005d96c840 fp = 0xffff00005d96c980 handle_el0_sync() at 0x40421150 pc = 0xffff00000072c224 lr = 0x0000000040421150 sp = 0xffff00005d96c990 fp = 0x0000ffffffffd830 KDB: enter: panic [ thread pid 2429 tid 100951 ] Stopped at 0x403fa408 db> Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Tue Oct 6 07:32:09 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 7E1CB42B4F4 for ; Tue, 6 Oct 2020 07:32:09 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C58LK253kz45g3 for ; Tue, 6 Oct 2020 07:32:09 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 475A542B333; Tue, 6 Oct 2020 07:32:09 +0000 (UTC) Delivered-To: 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 471CD42B4F3 for ; Tue, 6 Oct 2020 07:32:09 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C58LH3Nghz45S7; Tue, 6 Oct 2020 07:32:06 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=OyY5gFlelFJvFI6KLwKS0evJ4Cn04Kax5kqkrEVfnS0=; b=KR1nVaaC0ypdthiH7iIe05AFEZ4f8XQkOQ5fqwjRZ5p+JJ/b3k8jE/jBh8c8McAnjVLVwFpBLPGxupIi1NDph51KE8MMzg+2jMHDTbWZI24d20Dr4gzxwtXmrBce90R02lRHNyBQfah8zuGeJ7mON8H0Mdnte78Vfabb29qkgEe0CYloidOjkvB6iJZriA8qo1MTitTzgfr2GuooXwt0Ds1m/cCn1u1wxSXJlivpwS7MBNJ/fFq3s4aFwTQzu3N532qCv472MlVWYgIsQ+LmBfznH0sWIWmrNjrybguUEFM89dXL2FeG2ig4EgnaLi2AZnpBhQSzgpxoCiewtJisCg==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1kPhS6-0003BD-Ep; Tue, 06 Oct 2020 10:32:02 +0300 From: Daniel Braniss Message-Id: <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: nanopi/allwinner i2c not working. Date: Tue, 6 Oct 2020 10:32:02 +0300 In-Reply-To: Cc: "freebsd-arm@freebsd.org" To: Andriy Gapon References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4C58LH3Nghz45S7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=KR1nVaaC; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.04 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.02)[-1.018]; NEURAL_HAM_MEDIUM(-1.01)[-1.014]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-0.71)[-0.707]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[arm] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Tue, 06 Oct 2020 07:32:09 -0000 > On 5 Oct 2020, at 17:54, Daniel Braniss wrote: >=20 >=20 >=20 >> On 5 Oct 2020, at 17:19, Andriy Gapon wrote: >>=20 >> On 05/10/2020 11:47, Daniel Braniss wrote: >>> Hi, >>> latest 12.2-stable r366421, >>>=20 >>> when nothing is connected, >>> i2c -s >>> just hangs >>> and reboot is required. >>>=20 >>>=20 >>> if anything is connected, it just goes into a loop: >>> # i2c -s >>> Hardware may not support START/STOP scanning; trinterrupt storm = detected on "gic0,s6:"; throttling interrupt source >>> ying less-reliable read method. >>> interrupt storm detected on "gic0,s6:"; throttling interrupt source >>> interrupt storm detected on "gic0,s6:"; throttling interrupt source >>> =E2=80=A6 >>>=20 >>> im willing to help debug this, but need help. >>=20 >> What NanoPi model is this? > nanopi neo v1.3 and v1.4 >=20 >>=20 >> Can you try to merge r365397 and check if it helps? >> If it does not, can you additionally try = https://reviews.freebsd.org/D26049 = ? > i think i tested this a while back, with the same results. >>=20 >> If the problem persists, can you try setting hw.i2c.twsi_debug=3D1 = and collect >> some logs? >=20 > last time i tested, debug was on, and it worked, but when turned off = it hung. >=20 > I have to compile twsi with debug, and will report back ASAP. >=20 this is what happens with debug on, =E2=80=A6 iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 8 from 10 iichb0: twsi_intr: initial status=3D8 iichb0: twsi_intr: Send the address iichb0: TWSI_WRITE: Writing 48 to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 8 from 10 iichb0: twsi_intr: initial status=3D8 iichb0: twsi_intr: Send the address iichb0: TWSI_WRITE: Writing 48 to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Done with interrupts ... > thanks, > danny >=20 >=20 >>=20 >> Thanks! >>=20 >> --=20 >> Andriy Gapon >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Tue Oct 6 08:34:31 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 E712642C90C for ; Tue, 6 Oct 2020 08:34:31 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C59kH53qBz49X2 for ; Tue, 6 Oct 2020 08:34:31 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id AD42742C372; Tue, 6 Oct 2020 08:34:31 +0000 (UTC) Delivered-To: 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 AD03042C993 for ; Tue, 6 Oct 2020 08:34:31 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C59kG3bzMz49Cf for ; Tue, 6 Oct 2020 08:34:30 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f178.google.com with SMTP id n25so10116532ljj.4 for ; Tue, 06 Oct 2020 01:34:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=aE/9AciGnl4x0XLTI7rege1gI9wVWXDIinq6BpgaiLg=; b=VFluAh3xa20Q1dchcz3y9jnj+RUzzMBx33DxmVvL2LWK1GKauP2T04qhwLu2Cdb13L DzJnUPsLjN+aIaSmEJiDxe/IsaKAeQI7CmPsWIK/fnLWVRXPXQhL5Y2CgSZrcejuYXwv 5ukR2fF9cXWczhKpMUdYkpbGIhZZVfsPCvhJu7V5IyGWleLCrGeYt5xUgFTLYC8uZh33 DcdLTUstZM3NFou3ldXewgc/ciPLo6BA3+E4ciYcBhT06/t2jhflqxzJ5OG7y6Jxb4N6 pYoq5z6nqvOKH7Y7sC3ItR7O5c3Gpa2wamsbyNVUBt5n0yX9yGyPVsTUApDumguA974P IDCw== X-Gm-Message-State: AOAM533CNhmAdUWjEkbrAEqRH1oGuPYyagUjDSnpHvdo74sT7GRiN/Aw jUYQUk94HivK9iu3fLONtqiULYfN+44Vtg== X-Google-Smtp-Source: ABdhPJydAST1mDxJ+0Q37ZGecL/GPgLdiPhhZX8XYa+o72mnpeYRqNyF55UJI7I//+S58y9tjZmFqQ== X-Received: by 2002:a2e:9e8b:: with SMTP id f11mr1239747ljk.297.1601973268208; Tue, 06 Oct 2020 01:34:28 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id n6sm591931ljg.106.2020.10.06.01.34.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 01:34:27 -0700 (PDT) Subject: Re: nanopi/allwinner i2c not working. To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: Date: Tue, 6 Oct 2020 11:34:26 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4C59kG3bzMz49Cf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-2.59 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.54)[-0.540]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.012]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.042]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.178:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.178:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[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: Tue, 06 Oct 2020 08:34:32 -0000 On 06/10/2020 10:32, Daniel Braniss wrote: > this is what happens with debug on, > > … > iichb0: twsi_intr: Got interrupt Current msg=0 > iichb0: TWSI_READ: read 8 from 10 > iichb0: twsi_intr: initial status=8 > iichb0: twsi_intr: Send the address > iichb0: TWSI_WRITE: Writing 48 to 8 > iichb0: TWSI_WRITE: Writing c4 to c > iichb0: twsi_intr: Done with interrupts > > iichb0: twsi_intr: Got interrupt Current msg=0 > iichb0: TWSI_READ: read 8 from 10 > iichb0: twsi_intr: initial status=8 > iichb0: twsi_intr: Send the address > iichb0: TWSI_WRITE: Writing 48 to 8 > iichb0: TWSI_WRITE: Writing c4 to c > iichb0: twsi_intr: Done with interrupts > > ... Sorry, if I missed it, is this with any of the patches I suggested earlier? Additionally, it looks like manu still hasn't merged r363021 ? That could be the root cause of the problem that you see. -- Andriy Gapon From owner-freebsd-arm@freebsd.org Tue Oct 6 08:41:30 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 4121542CA46 for ; Tue, 6 Oct 2020 08:41:30 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C59tK4zTtz49bB for ; Tue, 6 Oct 2020 08:41:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.nyi.freebsd.org (Postfix) id AAD5542CA45; Tue, 6 Oct 2020 08:41:29 +0000 (UTC) Delivered-To: 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 AAA1042CA44 for ; Tue, 6 Oct 2020 08:41:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C59tJ6tjrz49h3; Tue, 6 Oct 2020 08:41:28 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1601973680; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ULz2rJfPfu97YV3wVC9RDoikgNQxCqclqGeKk1bdd84=; b=FBoPJVuwFxbjjg1VeFc91jDd+hGCb6+A+UpJbC5SN1IMMztGc13Tpj986cUVZuXaFmiYAd yB7lGfAc2XK0u6s0c7xQxeY2VBUBihITt3nSGntQuZFoCUFRFxkeTSp7heAUi6AGb7A/50 6BtUAKZUtISNthuvh9QQRG22k1Fv+FM= Received: from skull.home.blih.net (lfbn-idf2-1-288-247.w82-123.abo.wanadoo.fr [82.123.126.247]) by mx.blih.net (OpenSMTPD) with ESMTPSA id d59e4a2d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 6 Oct 2020 08:41:20 +0000 (UTC) Date: Tue, 6 Oct 2020 10:41:19 +0200 From: Emmanuel Vadot To: Andriy Gapon Cc: Daniel Braniss , "freebsd-arm@freebsd.org" Subject: Re: nanopi/allwinner i2c not working. Message-Id: <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> In-Reply-To: References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4C59tJ6tjrz49h3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; REPLY(-4.00)[] 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: Tue, 06 Oct 2020 08:41:30 -0000 On Tue, 6 Oct 2020 11:34:26 +0300 Andriy Gapon wrote: > On 06/10/2020 10:32, Daniel Braniss wrote: > > this is what happens with debug on, > >=20 > > ? > > iichb0: twsi_intr: Got interrupt Current msg=3D0 > > iichb0: TWSI_READ: read 8 from 10 > > iichb0: twsi_intr: initial status=3D8 > > iichb0: twsi_intr: Send the address > > iichb0: TWSI_WRITE: Writing 48 to 8 > > iichb0: TWSI_WRITE: Writing c4 to c > > iichb0: twsi_intr: Done with interrupts > >=20 > > iichb0: twsi_intr: Got interrupt Current msg=3D0 > > iichb0: TWSI_READ: read 8 from 10 > > iichb0: twsi_intr: initial status=3D8 > > iichb0: twsi_intr: Send the address > > iichb0: TWSI_WRITE: Writing 48 to 8 > > iichb0: TWSI_WRITE: Writing c4 to c > > iichb0: twsi_intr: Done with interrupts > >=20 > > ... >=20 >=20 > Sorry, if I missed it, is this with any of the patches I suggested earlie= r? > Additionally, it looks like manu still hasn't merged r363021 ? > That could be the root cause of the problem that you see. >=20 > --=20 > Andriy Gapon Mhm yes it seems that I've might miss a few commits to mfc. I'll try to have a look today. Daniel, could you test 13-CURRENT just to confirm that it's fixed in head ? Thanks, --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Oct 6 09:11:01 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 BFD1842D409 for ; Tue, 6 Oct 2020 09:11:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5BXP46W5z4CYf for ; Tue, 6 Oct 2020 09:11:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 8D2C442CDE9; Tue, 6 Oct 2020 09:11:01 +0000 (UTC) Delivered-To: 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 8CF7142D22A for ; Tue, 6 Oct 2020 09:11:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5BXN4ZRDz4CWl; Tue, 6 Oct 2020 09:11:00 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=ROtH6TerZKO2KP1JD0hKlorpmubzkFrOzRgECTb+x8o=; b=A2CEaJds+lMinRF/R0+jyIO4e6ErPSulpwQA3+KpHYhbDuHiecGMytdgiXivX8FexqAuR51EZlzemAZCrmfGzZyW32HyNRGy5HreWur48O9Ou2J8OBGstZ1npTorWHufd2Zvhx+P6eK6Fm+myA++MWaFVrE7N3pSDqIZKGnN5aJEqAgscssgnGiT9C+J7wkup+wMC2neSrJUEwRbyty3F73YBORo1xY9ATv2Td1fpOWUzu6/SmJPeIvn3hB+2xFLWL81Rei2x6TXRqusN6psXa4QveedrHF3VAB/xVq/JBdSeEzfMTxyl1Zp2QebcKaI6+rh7aC519Ij5dVZXcjxMQ==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1kPizj-0007XA-4r; Tue, 06 Oct 2020 12:10:51 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: nanopi/allwinner i2c not working. From: Daniel Braniss In-Reply-To: <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> Date: Tue, 6 Oct 2020 12:10:50 +0300 Cc: Andriy Gapon , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4C5BXN4ZRDz4CWl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=A2CEaJds; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.82 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.04)[-1.035]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.01)[-1.010]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-0.47)[-0.472]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[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: Tue, 06 Oct 2020 09:11:01 -0000 > On 6 Oct 2020, at 11:41, Emmanuel Vadot wrote: >=20 > On Tue, 6 Oct 2020 11:34:26 +0300 > Andriy Gapon wrote: >=20 >> On 06/10/2020 10:32, Daniel Braniss wrote: >>> this is what happens with debug on, >>>=20 >>> ? >>> iichb0: twsi_intr: Got interrupt Current msg=3D0 >>> iichb0: TWSI_READ: read 8 from 10 >>> iichb0: twsi_intr: initial status=3D8 >>> iichb0: twsi_intr: Send the address >>> iichb0: TWSI_WRITE: Writing 48 to 8 >>> iichb0: TWSI_WRITE: Writing c4 to c >>> iichb0: twsi_intr: Done with interrupts >>>=20 >>> iichb0: twsi_intr: Got interrupt Current msg=3D0 >>> iichb0: TWSI_READ: read 8 from 10 >>> iichb0: twsi_intr: initial status=3D8 >>> iichb0: twsi_intr: Send the address >>> iichb0: TWSI_WRITE: Writing 48 to 8 >>> iichb0: TWSI_WRITE: Writing c4 to c >>> iichb0: twsi_intr: Done with interrupts >>>=20 >>> ... >>=20 >>=20 >> Sorry, if I missed it, is this with any of the patches I suggested = earlier? >> Additionally, it looks like manu still hasn't merged r363021 ? >> That could be the root cause of the problem that you see. >>=20 >> --=20 >> Andriy Gapon >=20 > Mhm yes it seems that I've might miss a few commits to mfc. > I'll try to have a look today. > Daniel, could you test 13-CURRENT just to confirm that it's fixed in > head ? > Thanks, well, that will take some time, but starting now. btw, is there bootable image somewhere? >=20 > --=20 > Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Oct 6 12:47:50 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 4B0C8432706 for ; Tue, 6 Oct 2020 12:47:50 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5HLY6pzjz4Rst for ; Tue, 6 Oct 2020 12:47:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id E9EE5432472; Tue, 6 Oct 2020 12:47:49 +0000 (UTC) Delivered-To: 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 E9B6F432794 for ; Tue, 6 Oct 2020 12:47:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5HLW3CwYz4RLC; Tue, 6 Oct 2020 12:47:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=tGdyS2Wq4JnzVrM6gc/vjaa39b9tO0aXcH1fbfUoiGQ=; b=ifK0sA3QqJSVd+/BamOeryG83NWmOFTfx4ONnGfwkQdDThqpzM0wedhVpOGeaWD1oX+dz6tzhzxK12MXBt1eb0zQxOJ5kzykJEDn7tzubiBtHzXW70TTCoHrHlEnCKpdVctLGX5YIJabl7+MlN4dKcjrSVoQKC6/w3nUpSS9ec/NzGi03yNtEunnyYUUYm3z0wzjiDJh8Ue1rmu9Y9zyz7DAI35dyzeyU2Dxa4UWueBQdI+pjq10jr+h0l7kslhmBflOg3D140tmxp6Ir6ryCQdnIrLXwHeLokMPU3J0bIpa4NzKzJc5+DhocXqVFKzLI198PfvtMqaVfeX0d9jNpg==; Received: from mbpro2.bk.cs.huji.ac.il ([132.65.179.20] helo=localhost.localdomain) by kabab.cs.huji.ac.il with esmtp id 1kPmNX-000GEU-R9; Tue, 06 Oct 2020 15:47:39 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.33\)) Subject: Re: nanopi/allwinner i2c not working. From: Daniel Braniss In-Reply-To: <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> Date: Tue, 6 Oct 2020 15:47:39 +0300 Cc: Andriy Gapon , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3654.0.3.2.33) X-Rspamd-Queue-Id: 4C5HLW3CwYz4RLC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=ifK0sA3Q; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.73 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.04)[-1.036]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.97)[-0.972]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-0.42)[-0.420]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[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: Tue, 06 Oct 2020 12:47:50 -0000 > On 6 Oct 2020, at 12:10, Daniel Braniss wrote: >=20 >=20 >=20 >> On 6 Oct 2020, at 11:41, Emmanuel Vadot = wrote: >>=20 >> On Tue, 6 Oct 2020 11:34:26 +0300 >> Andriy Gapon wrote: >>=20 >>> On 06/10/2020 10:32, Daniel Braniss wrote: >>>> this is what happens with debug on, >>>>=20 >>>> ? >>>> iichb0: twsi_intr: Got interrupt Current msg=3D0 >>>> iichb0: TWSI_READ: read 8 from 10 >>>> iichb0: twsi_intr: initial status=3D8 >>>> iichb0: twsi_intr: Send the address >>>> iichb0: TWSI_WRITE: Writing 48 to 8 >>>> iichb0: TWSI_WRITE: Writing c4 to c >>>> iichb0: twsi_intr: Done with interrupts >>>>=20 >>>> iichb0: twsi_intr: Got interrupt Current msg=3D0 >>>> iichb0: TWSI_READ: read 8 from 10 >>>> iichb0: twsi_intr: initial status=3D8 >>>> iichb0: twsi_intr: Send the address >>>> iichb0: TWSI_WRITE: Writing 48 to 8 >>>> iichb0: TWSI_WRITE: Writing c4 to c >>>> iichb0: twsi_intr: Done with interrupts >>>>=20 >>>> ... >>>=20 >>>=20 >>> Sorry, if I missed it, is this with any of the patches I suggested = earlier? >>> Additionally, it looks like manu still hasn't merged r363021 ? >>> That could be the root cause of the problem that you see. >>>=20 >>> --=20 >>> Andriy Gapon >>=20 >> Mhm yes it seems that I've might miss a few commits to mfc. >> I'll try to have a look today. >> Daniel, could you test 13-CURRENT just to confirm that it's fixed in >> head ? >> Thanks, >=20 > well, that will take some time, but starting now. i2c -s works - finds the devices but can=E2=80=99t do much else, can=E2=80=99t talk to the device (pn532) trying to write i get I2CRWR: errno 1: Operation not permitted=E2=80=99 > btw, is there bootable image somewhere? >=20 >>=20 >> --=20 >> Emmanuel Vadot >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Oct 6 12:53:52 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 778764328AE for ; Tue, 6 Oct 2020 12:53:52 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5HTX1nd2z4Rmk for ; Tue, 6 Oct 2020 12:53:52 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 3D56C43299A; Tue, 6 Oct 2020 12:53:52 +0000 (UTC) Delivered-To: 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 3D17D4327B8 for ; Tue, 6 Oct 2020 12:53:52 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5HTW15dMz4S0w for ; Tue, 6 Oct 2020 12:53:50 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f172.google.com with SMTP id w3so10807132ljo.5 for ; Tue, 06 Oct 2020 05:53:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2B5tUGk7FWNPg7p9UJyrdnpQbwBsH4jxeUmDiiIOMjE=; b=KLf8/j2jLXCCM7nXav+x/Pv+lQk/r2Sja7VGleCCFPrRLuU1OlRXsGa31caRfTPvny k30jINoDb94wnSIgoqAWx6/RG+x28OgI2PgXPy/khK1b+ozNq0MTGmNneqNFgSbJajyr K8O7GptHqhVro3XZL+gu+lY/YLzZHmkgE3todbIKljf82SCZKrymsR1ZWS1Gl7a2SMl6 P4KXLP9ZDmI85jCUssgQP8AXoNIwp83YE0rr/3EZIiB54SH1aBdtjFfkT+BL7wVq4QU7 FwXRzm2tIvKtv0cwG+55G+0LvUWIYYA3JibBxdPHlujNxS6anJVGBI98Ni8kqHKd0tYb ZNEA== X-Gm-Message-State: AOAM531Xsqs9zTUIOA1L1UX5FpgIz9B3rQ/16APpxtbLKwGperrFiKSJ 3TJLVlAXBtiLlUi/Yb+eI3loE9jaLOu70g== X-Google-Smtp-Source: ABdhPJxr8hAewTu635L9KlqrGQ1Lm2sjAryaXJNxsIWQzrshFgmw6Q1dWrM18RZCHZhfpD5GmuIjfw== X-Received: by 2002:a2e:b8d4:: with SMTP id s20mr1613190ljp.232.1601988828090; Tue, 06 Oct 2020 05:53:48 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id e14sm683772ljp.15.2020.10.06.05.53.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 05:53:47 -0700 (PDT) Subject: Re: nanopi/allwinner i2c not working. To: Daniel Braniss , Emmanuel Vadot Cc: "freebsd-arm@freebsd.org" References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> Date: Tue, 6 Oct 2020 15:53:46 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4C5HTW15dMz4S0w X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-1.73 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.924]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.24)[0.239]; NEURAL_HAM_LONG(-1.04)[-1.042]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.172:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.172:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[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: Tue, 06 Oct 2020 12:53:52 -0000 On 06/10/2020 15:47, Daniel Braniss wrote: > i2c -s works - finds the devices > > but can’t do much else, can’t talk to the device (pn532) > trying to write i get > I2CRWR: errno 1: Operation not permitted’ You have to use -m tr with twsi. -- Andriy Gapon From owner-freebsd-arm@freebsd.org Tue Oct 6 13:23:10 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 38618432F7F for ; Tue, 6 Oct 2020 13:23:10 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5J7L04dDz4V1D for ; Tue, 6 Oct 2020 13:23:10 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 02ABB432F7E; Tue, 6 Oct 2020 13:23:10 +0000 (UTC) Delivered-To: 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 0276E43303E for ; Tue, 6 Oct 2020 13:23:10 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5J7G5H1gz4TtV; Tue, 6 Oct 2020 13:23:06 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=gZFabIpNPUYcSlbCgIVOW88z1/FkeKfP3YLDcJTFdRI=; b=tWlTtxG+QLlH3p4Q4QSSzSZCLSWEGEzzyZEEQxxBP9texUwzqMq0s5p/UsKFUwhEvxv2LYK4IQ7Tbnxh9p2Ce8JLZxV1bsgwdRQAp1D0ii0DZSOy/sAEQZm22xrTrWFztWBgafHBFoe1Wdm3RftkFCUw4obmhfVP5uZaeZX8c1pxZSvm6ziFJcYq234Yyi8hUKPb/1oIvoiOenDXJpOk7cgooR09lQMdM1OwIqI22miY2d1zPYHIdFTtHDApI/T48AEL351VPC5rpeb89Zps3kXNJ8UHN75q9iqKFlZ/pRdqRq4X4XxQJsxQ649knllo/MGo1Irs4KaoP5pjR9y8Lw==; Received: from mbpro2.bk.cs.huji.ac.il ([132.65.179.20] helo=localhost.localdomain) by kabab.cs.huji.ac.il with esmtp id 1kPmvo-000HzM-Ek; Tue, 06 Oct 2020 16:23:04 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.33\)) Subject: Re: nanopi/allwinner i2c not working. From: Daniel Braniss In-Reply-To: <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> Date: Tue, 6 Oct 2020 16:23:04 +0300 Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3654.0.3.2.33) X-Rspamd-Queue-Id: 4C5J7G5H1gz4TtV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; REPLY(-4.00)[] 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: Tue, 06 Oct 2020 13:23:10 -0000 > On 6 Oct 2020, at 15:53, Andriy Gapon wrote: >=20 > On 06/10/2020 15:47, Daniel Braniss wrote: >> i2c -s works - finds the devices >>=20 >> but can=E2=80=99t do much else, can=E2=80=99t talk to the device = (pn532) >> trying to write i get >> I2CRWR: errno 1: Operation not permitted=E2=80=99 >=20 > You have to use -m tr with twsi. please translate :-) >=20 > --=20 > Andriy Gapon From owner-freebsd-arm@freebsd.org Tue Oct 6 13:26:16 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 E65A743349D for ; Tue, 6 Oct 2020 13:26:16 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5JBw4xshz4TmT for ; Tue, 6 Oct 2020 13:26:16 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id A78A443349C; Tue, 6 Oct 2020 13:26:16 +0000 (UTC) Delivered-To: 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 A74CD43341E for ; Tue, 6 Oct 2020 13:26:16 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5JBt56bKz4TwJ for ; Tue, 6 Oct 2020 13:26:14 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f174.google.com with SMTP id a5so5395313ljj.11 for ; Tue, 06 Oct 2020 06:26:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=MwCLC2Vp4VBrswulzp27SPt1dJCm2ODS6ypOncdOsOs=; b=Icp1Qw7+dTlxqaT3eWe1LG/iuVnQS3qro/ydyDoaPrbwK6lGDt7F5j2R/DFvqB4HIH OdH8ZXb/KrfN+ovN3FslNPOLwIsI6RDFcp4dxOaRffuUkveREjfzhHnLUi5812QxgnA7 uyjW9fl20snKNrIMffgZegjNbQRJ81kHgxIg01KuIVXMAqfWSlHcy+tIze/EBgelyTSU 276IAH7cEhA/qXxgz9+o4sTCr1zqd5OCFtoI5QJCV8tqp6Yrmi+opHaPvusDS7c8KiTv R5HDSWjE8N2ze0Tz9RU+dX8vufpFuaS8il47hawDRzkAxK1b3j/q2N5HFUkY97m995m1 XnXA== X-Gm-Message-State: AOAM532hdf0xTGs9yq9wkz+NnHDezV6vUTmIhef+FBSVp+I15V31qchD sx51wGhExPpd/wr1G8ZSXw+MR++PmKYdwQ== X-Google-Smtp-Source: ABdhPJxj+Wh/oxrGeTmbQ0ZizFrXKQoONdW2ikQ1QNzTSD3S299Q5Dkuzq453G+USY3TvKRuMQVL1A== X-Received: by 2002:a2e:8e30:: with SMTP id r16mr1914043ljk.304.1601990772624; Tue, 06 Oct 2020 06:26:12 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id q3sm710692lji.27.2020.10.06.06.26.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 06:26:11 -0700 (PDT) Subject: Re: nanopi/allwinner i2c not working. To: Daniel Braniss Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: Date: Tue, 6 Oct 2020 16:26:09 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4C5JBt56bKz4TwJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.174 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-1.73 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.946]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.26)[0.256]; NEURAL_HAM_LONG(-1.04)[-1.037]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.174:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.174:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[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: Tue, 06 Oct 2020 13:26:17 -0000 On 06/10/2020 16:23, Daniel Braniss wrote: > > >> On 6 Oct 2020, at 15:53, Andriy Gapon wrote: >> >> On 06/10/2020 15:47, Daniel Braniss wrote: >>> i2c -s works - finds the devices >>> >>> but can’t do much else, can’t talk to the device (pn532) >>> trying to write i get >>> I2CRWR: errno 1: Operation not permitted’ >> >> You have to use -m tr with twsi. > > please translate :-) Okay, please show the command line :) -- Andriy Gapon From owner-freebsd-arm@freebsd.org Tue Oct 6 13:30:22 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 94DB4433442 for ; Tue, 6 Oct 2020 13:30:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5JHf2wfnz4Tmr for ; Tue, 6 Oct 2020 13:30:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 626B2433441; Tue, 6 Oct 2020 13:30:22 +0000 (UTC) Delivered-To: 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 611154331BD for ; Tue, 6 Oct 2020 13:30:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5JHf15gsz4V1s; Tue, 6 Oct 2020 13:30:21 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=W3DNp38mCS0QgVdDggfU1vngvoyoMTwrRA2MGlORpYU=; b=FfZ2RdQhQzvY/90DZQlE3F0swQftSO3i9hwVq+nPd3BmQAxs2Xf1LkRu84OTQCQIZBc5F/klnzhv7Vw+nnBOioUS6R7J27l2RSj/C3QUovETPKVsPh6pGFXZmZea2f6eX1yR3/J5XEFwsh9KhWJbtbkj/vSg+lLHAxbInuqoRfUl+LxfN/tgacZ7lbMlPMSNLBzW3SBDOTtieeRhythBs2d45w0x9coofuVrM1EHY0thbyq9V34Feb3xO5HYgEIw1pl9k8Q4SiwcyY3A1/FfRQepfrD2+FEUz6RzKH/QqkxNRAEfeVY3jdLbJAYKRwsjZdRsDpPp2rc8ov5vIc+7uQ==; Received: from mbpro2.bk.cs.huji.ac.il ([132.65.179.20] helo=localhost.localdomain) by kabab.cs.huji.ac.il with esmtp id 1kPn2p-000I9m-RK; Tue, 06 Oct 2020 16:30:19 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.33\)) Subject: Re: nanopi/allwinner i2c not working. From: Daniel Braniss In-Reply-To: Date: Tue, 6 Oct 2020 16:30:19 +0300 Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> To: Andriy Gapon X-Mailer: Apple Mail (2.3654.0.3.2.33) X-Rspamd-Queue-Id: 4C5JHf15gsz4V1s X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL] 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: Tue, 06 Oct 2020 13:30:22 -0000 > On 6 Oct 2020, at 16:26, Andriy Gapon wrote: >=20 > On 06/10/2020 16:23, Daniel Braniss wrote: >>=20 >>=20 >>> On 6 Oct 2020, at 15:53, Andriy Gapon wrote: >>>=20 >>> On 06/10/2020 15:47, Daniel Braniss wrote: >>>> i2c -s works - finds the devices >>>>=20 >>>> but can=E2=80=99t do much else, can=E2=80=99t talk to the device = (pn532) >>>> trying to write i get >>>> I2CRWR: errno 1: Operation not permitted=E2=80=99 >>>=20 >>> You have to use -m tr with twsi. >>=20 >> please translate :-) >=20 > Okay, please show the command line :) ah, got it, but i use ioctl(fd, I2CRDWR, data). i=E2=80=99ll recompile and see if it=E2=80=99s still not working. >=20 >=20 > --=20 > Andriy Gapon From owner-freebsd-arm@freebsd.org Tue Oct 6 13:37:50 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 E7C09433643; Tue, 6 Oct 2020 13:37:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5JSG03lKz4VbM; Tue, 6 Oct 2020 13:37:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82c.google.com with SMTP id s47so4301715qth.4; Tue, 06 Oct 2020 06:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BXTMiiP0ETsEtIkLqxngtJv9K8OCm2bx2i2BOsde/LE=; b=g6yrWm8DSe2T35eZRRiNSE4JySuePGx39X1B1GnzCtrmw1K2SuDNtVX+gE+RVbyZ/X cshT8hPOxiXpV0VO1YeUNmIiRVyAQER4ffJyxuV4x6XXkwFN7g5FuBbOU8CkO0y3CrGi k2oNb0iJg0eSVvrN/Vbw755H+i7uLwWoBeM1OdfEnPwau3ifWOcJ+2dcZ+t57op4qM/l IOcw+IdfXJ7OmLnsxXTPHj6IfyZRfhqgk0Dp/YJ3oiAFVEaVrw4VVJLogdVtPAKhKLbD Fgto/KRncoZ1WATOYd+bCjfGJkdcakPhRl4zkM66pLTnxQ0xlmc0Yiuevw0H9Gjo13Wa +Bnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=BXTMiiP0ETsEtIkLqxngtJv9K8OCm2bx2i2BOsde/LE=; b=lwO19Lq2wY05Bat0+qbGvORLFD6jdCFWUp0xcnjMY3opc4fFqcf9RmzYx9tbm0qGJn 4mmGLrarMi5P34RkkKnjR8NujOcc3s3fZfGgwY7iS+64no06GuBZl/tsj92O79c2XKyu dQJ6bE9AgptcoRLwIUU73vCeEWgSO16p3OODV4dFQE3wVROMcf4y9DsqaXkphUZcmnJA s52QcuWfwf08ryQULo5fKiEs+KBkA96IQW+U7xv1ErEbAvnMrUmxTKmQwsQMC3yxLKQ+ KC81XHCODqfbVnPHPVWFJXHu5aGHOk+CdbZ/cdeKUeQIsKNyxSkrBHFD5BhLnVHg9Iag D58Q== X-Gm-Message-State: AOAM533osdiNfd3RTEuPxcFm2z8iVfbxB5mIKwRdCiSAKi4j/E9Wbyid cGEBwEo7j484XMlOXQXwoB+ge435xwf81w== X-Google-Smtp-Source: ABdhPJwGINjALUZUj089+qeHfs6DQkspgs3OOfwneyHqeIhq9rHeVKdCnz6U9pzQlmR8LrVLh6rbtg== X-Received: by 2002:ac8:3984:: with SMTP id v4mr5220627qte.240.1601991468946; Tue, 06 Oct 2020 06:37:48 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-77-103.dsl.bell.ca. [174.88.77.103]) by smtp.gmail.com with ESMTPSA id e39sm2374695qtk.32.2020.10.06.06.37.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2020 06:37:47 -0700 (PDT) Sender: Mark Johnston Date: Tue, 6 Oct 2020 09:37:43 -0400 From: Mark Johnston To: bob prohaska Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 Message-ID: <20201006133743.GA96285@raichu> References: <20201006021029.GA13260@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201006021029.GA13260@www.zefox.net> X-Rspamd-Queue-Id: 4C5JSG03lKz4VbM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=g6yrWm8D; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::82c as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.17 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.03)[-1.030]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.49)[-0.494]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82c:from]; NEURAL_HAM_MEDIUM(-0.95)[-0.946]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; MAILMAN_DEST(0.00)[freebsd-current,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: Tue, 06 Oct 2020 13:37:51 -0000 On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote: > Still seeing non-current pmap panics on the Pi3, this time a B+ running > 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master) > during a -j4 buildworld. The backtrace reports > > panic: non-current pmap 0xffffa00020eab8f0 Could you show the output of "show procvm" from the debugger? From owner-freebsd-arm@freebsd.org Tue Oct 6 13:47:34 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 2E8BE433A9F for ; Tue, 6 Oct 2020 13:47:34 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5JgT6cp5z4Vmw for ; Tue, 6 Oct 2020 13:47:33 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id E0F804337F9; Tue, 6 Oct 2020 13:47:33 +0000 (UTC) Delivered-To: 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 DFB314338C0 for ; Tue, 6 Oct 2020 13:47:33 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5JgS68gdz4W0h for ; Tue, 6 Oct 2020 13:47:32 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f180.google.com with SMTP id l13so7969595ljg.10 for ; Tue, 06 Oct 2020 06:47:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oZNVv5Xrt2aBmTA/92wtnZVC9NA9lGodUAdvI4Rd31k=; b=fiBUabte9leErzTKE6yBzl2+K8B0SmNvIoZjKO/YECwyWUfNd4QY0UkAI6nEQZp/c3 ondGuS2T8Ur3HqwOKMw6NZSQRZa1MipJFPblD4LkHBext7wFHqIkIHDOLH/dJpgXJpke y9TNr9ISZJIh/um/Hct+Ly/XRluHj7Yz/ozwd7i8ULQNStHx4Qm/QoEBC7DuiJQnQkF6 1kyacXrvzavxsPIoW7b5FsIgb5dxbDR79zemHigVJsUzQ9ZdR3hvb+qYO9wxFkMB0U/p HprWlYf408xfjQeKZj+WE8SrZyrQN3iHDAprfmivIrG984pluYje/s3iZIA2s1xt/EYz XaLw== X-Gm-Message-State: AOAM5307meL/OSNX6EQ5+GCiVG381vhJ2/f1AVi1XmfSlRZGeP8kwa1T THBvdqSsLWZhVauistDJR8qDSUuou+ARLw== X-Google-Smtp-Source: ABdhPJxIIWcZAfz8UfHwHPo8hHLOsN8Uk0XVKLgrIhvK3fLG26aHth3IhYMOMgA4eXu8PDAcFkbSJA== X-Received: by 2002:a2e:9a4d:: with SMTP id k13mr1720412ljj.138.1601992049310; Tue, 06 Oct 2020 06:47:29 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id y9sm600677lfg.293.2020.10.06.06.47.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 06:47:28 -0700 (PDT) Subject: Re: nanopi/allwinner i2c not working. To: Daniel Braniss Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> Date: Tue, 6 Oct 2020 16:47:27 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4C5JgS68gdz4W0h X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-2.35 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.37)[-0.367]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.944]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.04)[-1.037]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.180:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.180:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[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: Tue, 06 Oct 2020 13:47:34 -0000 On 06/10/2020 16:30, Daniel Braniss wrote: > > >> On 6 Oct 2020, at 16:26, Andriy Gapon wrote: >> >> On 06/10/2020 16:23, Daniel Braniss wrote: >>> >>> >>>> On 6 Oct 2020, at 15:53, Andriy Gapon wrote: >>>> >>>> On 06/10/2020 15:47, Daniel Braniss wrote: >>>>> i2c -s works - finds the devices >>>>> >>>>> but can’t do much else, can’t talk to the device (pn532) >>>>> trying to write i get >>>>> I2CRWR: errno 1: Operation not permitted’ >>>> >>>> You have to use -m tr with twsi. >>> >>> please translate :-) >> >> Okay, please show the command line :) > > ah, got it, but i use ioctl(fd, I2CRDWR, data). > > i’ll recompile and see if it’s still not working. I2CRDWR should work actually, it uses iicbus_transfer. Can you share / show your code? -- Andriy Gapon From owner-freebsd-arm@freebsd.org Tue Oct 6 14:00:57 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 C93E6433EBF for ; Tue, 6 Oct 2020 14:00:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5Jyx3X0Cz4WkZ for ; Tue, 6 Oct 2020 14:00:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 7905E433EBE; Tue, 6 Oct 2020 14:00:57 +0000 (UTC) Delivered-To: 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 78CCC433E5A for ; Tue, 6 Oct 2020 14:00:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5Jyx1p4pz4Wh5; Tue, 6 Oct 2020 14:00:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=aytvvgj+0SSt61z9xTbhfJy6pkwSVe1+fbOKeZXrljY=; b=0664bme3jL+SM2dJBUtAXvEFtqLdvY++GnrFU6m5R0cW/j1DP7QraDuz1zHf1TDCw9nbm9/b4xbHPSrdxGdrEhQTy/VCMMEIpQLYfYdZKfNqtFqH3rv027GGYGWrUY6KRWLKuz8078nAxCHbG+VSpA8evOAObiD6r84EOEYYSnikQxf2UU9Qz1QejTWpBAPY+yhk5RUiey6oKZy9U5mUgId6LH5jbP9VVPSPMSAIQr0lKdIsLQjGm21emejlSYPH5VwHCOeKhfwgmn3Xn+aeWVGsmDCnFYS+uHUzbmgVPL/hno71WM9nizfdP7BvzJZ4d7KMC7f7dIzSPy+jgchlEg==; Received: from mbpro2.bk.cs.huji.ac.il ([132.65.179.20] helo=localhost.localdomain) by kabab.cs.huji.ac.il with esmtp id 1kPnWP-000JOs-1B; Tue, 06 Oct 2020 17:00:53 +0300 From: Daniel Braniss Message-Id: <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.33\)) Subject: Re: nanopi/allwinner i2c not working. Date: Tue, 6 Oct 2020 17:00:52 +0300 In-Reply-To: <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" To: Andriy Gapon References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> X-Mailer: Apple Mail (2.3654.0.3.2.33) X-Rspamd-Queue-Id: 4C5Jyx1p4pz4Wh5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; REPLY(-4.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Tue, 06 Oct 2020 14:00:57 -0000 > On 6 Oct 2020, at 16:47, Andriy Gapon wrote: >=20 > On 06/10/2020 16:30, Daniel Braniss wrote: >>=20 >>=20 >>> On 6 Oct 2020, at 16:26, Andriy Gapon wrote: >>>=20 >>> On 06/10/2020 16:23, Daniel Braniss wrote: >>>>=20 >>>>=20 >>>>> On 6 Oct 2020, at 15:53, Andriy Gapon wrote: >>>>>=20 >>>>> On 06/10/2020 15:47, Daniel Braniss wrote: >>>>>> i2c -s works - finds the devices >>>>>>=20 >>>>>> but can=E2=80=99t do much else, can=E2=80=99t talk to the device = (pn532) >>>>>> trying to write i get >>>>>> I2CRWR: errno 1: Operation not permitted=E2=80=99 >>>>>=20 >>>>> You have to use -m tr with twsi. >>>>=20 >>>> please translate :-) >>>=20 >>> Okay, please show the command line :) >>=20 >> ah, got it, but i use ioctl(fd, I2CRDWR, data). >>=20 >> i=E2=80=99ll recompile and see if it=E2=80=99s still not working. >=20 > I2CRDWR should work actually, it uses iicbus_transfer. > Can you share / show your code? not too proud of it, but i=E2=80=99ll make it available. it=E2=80=99s in https://www.cs.huji.ac.il/~danny/elockc.tar.bz = look in i2c.c in any case it works fine in 12.1. >=20 >=20 > --=20 > Andriy Gapon From owner-freebsd-arm@freebsd.org Tue Oct 6 14:22:31 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 CF3F243436B for ; Tue, 6 Oct 2020 14:22:31 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5KRq4G4Dz4Xdx for ; Tue, 6 Oct 2020 14:22:31 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 8FEB4434369; Tue, 6 Oct 2020 14:22:31 +0000 (UTC) Delivered-To: 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 8E9BC4347E7 for ; Tue, 6 Oct 2020 14:22:31 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5KRp5t6Vz4Y1K for ; Tue, 6 Oct 2020 14:22:30 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f181.google.com with SMTP id a4so6593510lji.12 for ; Tue, 06 Oct 2020 07:22:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oXrwVzNxj3RknBQEKLQDz5jSQI0vNI+K0xGkOu6hjZE=; b=uiLvJGN1n5tlkYUXlk0L+XkL1f/M//kmwTjgayZo32XjQlwJL50jmiXLmfJ4kphvcb TEnYQa9ay8stWtphZgfmVfUOUrO9/i21HNHz9onkQdzcn1Yt2MPDUOWt+awwiJFi9Jkk 8a1OblIRY3r5ingAgUDONkBQGWnlUGpYhs07vMKp4p+71SGtXP5AIZH3g90c0J2nz/80 9elNH+z8jKKKsBvFOQUhZhHpJyqKAAS/HC0Mn+70mY7tJxQWuyD3lVIkdLb3dAz6B8Ri JVZUvNOohvPEVKlvm/Ae+suCPaMyhXYT8VxRZH0+/KuP8IvEUckotNC9KHpcvly2gn0X OYwg== X-Gm-Message-State: AOAM532S8slUoBHPO8VS7NDX2w9u1jBAodmaxIflIf02V2CtjcIY9vTx upZjUkLlFMyW5Q69lDCpR+AYsHfK1HjIaw== X-Google-Smtp-Source: ABdhPJwMG017lgmvRQPdfaKWlXOCYINdapR3Wn021S4TyrUG2uDwsMiTBylOLKl9WtKrwh0jAcxvyQ== X-Received: by 2002:a05:651c:1031:: with SMTP id w17mr1775747ljm.227.1601994148993; Tue, 06 Oct 2020 07:22:28 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id o15sm610114lfg.226.2020.10.06.07.22.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 07:22:27 -0700 (PDT) Subject: Re: nanopi/allwinner i2c not working. To: Daniel Braniss Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: Date: Tue, 6 Oct 2020 17:22:26 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4C5KRp5t6Vz4Y1K X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.181 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-2.18 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.19)[-0.194]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.944]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.04)[-1.037]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.181:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.181:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[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: Tue, 06 Oct 2020 14:22:31 -0000 On 06/10/2020 17:00, Daniel Braniss wrote: > not too proud of it, but i’ll make it available. > it’s in https://www.cs.huji.ac.il/~danny/elockc.tar.bz > look in i2c.c > > in any case it works fine in 12.1. And it looks good to me as well. Could you please collect twsi debug output again? In head you do not need to recompile, you can just set hw.i2c.twsi_debug. -- Andriy Gapon From owner-freebsd-arm@freebsd.org Tue Oct 6 17:03:48 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 9CDCC437410 for ; Tue, 6 Oct 2020 17:03:48 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5P1v43WVz3Rcm for ; Tue, 6 Oct 2020 17:03:47 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: by mail-il1-x129.google.com with SMTP id u9so1942591ilj.7 for ; Tue, 06 Oct 2020 10:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=TxCm3WhgA/n2Iv/aVwTxNmv2h/ayHTItN3MM4VwlyEA=; b=vZzaurVj+/EHIILlkO19/6FpCm0PXIkaiMksHwPOFkODo7IMLdMUNSKRwmAUatN42X DQAAaWjIQoqFKgsdRn1DH+3yjqOo8kGT1E5T3dEL2nz0k4V+OtXr8NvkaQoT4AsdA2QG ab79KWMwwAQSOrHSqZcdTXD7Gd/hBhM9XKLTGuTpM53BP4KLQNE3WIf/kGeSC5hllGtM 0HjHAuXoj9XagA1tLPU+J1vHZyy11lro3OwfduLEeCuZnrHhWQrWvRmPR8kN9s3U8RsO BUzP53DkHUvdbHfJtB7/fibhPDoifZognuNW8kfm82w9UIIhHNnyLb5/n8KXKJUfSDrb +dXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=TxCm3WhgA/n2Iv/aVwTxNmv2h/ayHTItN3MM4VwlyEA=; b=DvKzH1uLylLqct/jQOuYntFlXOSsg6XsKLCvqJXtduE2uHTqzB1OeswbCQ8UL0bd09 0IiX6Oojdoyg6WnHGCJKOuzIOaorgx9oEALRG9/cVc1OO7dJx1dStTqftjsirw4w5XZg 8AcIH5iv4nWvRPcRHuHB49Zk2SAjk6Aq+GdY5URZe2n4Me9oaCbeV2i1yH3rIHUnMlKu Aui7+Ci0qlcd8Bvj5bkYBysI13/NXmriC3+97emb59Ri271eE5VmdwQ0JQkV3jTmBUdq GzVPMLEsswsxEG+6wlkgmeo2PTo/vLWeC+xlZa0XlyUsZqU0rsMM0Rbm/td//cW7I8ma TH7A== X-Gm-Message-State: AOAM533G/pivx0iAQWSV7acOV4nMvGvbg6VeREvIRwlOdcpH7dQki0yt ISZ804KJR1t7d8drUwi9YGjUbyqPUSQB9QaphG0MoFfdUlFd X-Google-Smtp-Source: ABdhPJwZq3BKlr7GnnzRqxWYXyRd0tU9xb7knF0bV1AnPC6x0Hjn5c6aRzeCYXppHKf2iUNkzJPDVj7EgeoeVS722xs= X-Received: by 2002:a92:c7a7:: with SMTP id f7mr4565125ilk.268.1602003826142; Tue, 06 Oct 2020 10:03:46 -0700 (PDT) MIME-Version: 1.0 Reply-To: kamalp@acm.org From: "Kamal R. Prasad" Date: Tue, 6 Oct 2020 22:33:35 +0530 Message-ID: Subject: generic q on freebsd To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 4C5P1v43WVz3Rcm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=vZzaurVj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kamalpr@gmail.com designates 2607:f8b0:4864:20::129 as permitted sender) smtp.mailfrom=kamalpr@gmail.com X-Spamd-Result: default: False [-2.53 / 15.00]; HAS_REPLYTO(0.00)[kamalp@acm.org]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.78)[-0.779]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.035]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.28)[0.282]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::129:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Tue, 06 Oct 2020 17:03:48 -0000 hello, i am curious if it is possible to compile c++ code inside the freebsd kernel. thanks -kamal From owner-freebsd-arm@freebsd.org Tue Oct 6 17:23:14 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 5CD0B437AF6 for ; Tue, 6 Oct 2020 17:23:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5PSK2h0jz3Scx for ; Tue, 6 Oct 2020 17:23:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x841.google.com with SMTP id j22so13672391qtj.8 for ; Tue, 06 Oct 2020 10:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2McW5trDQWcml6CsUqBgmg1pBQ4CigFOL7YkC6HHgro=; b=Okzyj8pR0J0z2FTDN9LoH/Qxs9lckBboedbxloZ+uHR4iclxNHEumRIBoen1Kfhhqr NUlHFZIAzE05V4x3iXVoEyAhymXA+ghys5VdQMcb5Viie0fvjCu1xyFiBw11ThuOhK4O tD6fCjjI4lU1sTvDIQoyn6ly/Sm+iVwT4Z5cH7/RnctEo1mgZAJ+p0qzoxZbLQK8qwUn jTHJPHpL4njy3Y7Aor5l3Yr52rSPdsbXARtTNgRdyMuCJzdA2V115S6ZsZaI1TGI6GTt PtcBl5aIMP2gsseV3jio/rMnBKNmvSUb4Buuu8e3UA5h4dzwyEQYWfvffT9XClxVFnVw UiVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2McW5trDQWcml6CsUqBgmg1pBQ4CigFOL7YkC6HHgro=; b=o4BIQ+XOvYI2DlJhJ50lruxJJNNVhrs0kxcsAiBY5Ym4+tzU5lF+c4AX+DYqzoSYR2 NUgM+yb93Byp12NLMPt/cuDCGGtLJAkWbmUu4QCi6usbtP09tt9snEuU2C1D/vv4i/1S ltESzWlWKtACOxFjyfvXjSD7QjLq4eJwDEMZttnmrhpsNyUjZ7uK4tZ9NEG6nuPiMHXY XlDaYpsUJAYYhUcsagmazc/xtzz8yoBG4+HOfi9EHVCusWqpN++4O3Asahr9NsjLNEkH aM/grsxoktWySQVBmwmjtmKLsWAWUIs6QViUOToRjHB8P1nq+3eB22CzQNEWXO1MwlNO EvJg== X-Gm-Message-State: AOAM530QHKIPVPnD9/nhMEPeuvs1sJseH3qLPyCurGQceTvzNJQSxShR Y9hPjfhdA9szPNCMpInvdTXrHvAj0iszC6xfq3QGgrMMRXw07GnT X-Google-Smtp-Source: ABdhPJzzWgvy1m+avUof3qW9Xr0111eGWO44m4h2ck11Ak+aTFuzVbuHLuVe3ImXFh5tFmKCilX2SvGzghzoCBrM9vk= X-Received: by 2002:ac8:327d:: with SMTP id y58mr6262364qta.291.1602004992264; Tue, 06 Oct 2020 10:23:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 6 Oct 2020 11:23:01 -0600 Message-ID: Subject: Re: generic q on freebsd To: kamalp@acm.org Cc: "freebsd-arm@freebsd.org" X-Rspamd-Queue-Id: 4C5PSK2h0jz3Scx X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Okzyj8pR; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::841) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.93 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.871]; NEURAL_HAM_LONG(-1.04)[-1.035]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::841:from]; NEURAL_HAM_SHORT(-0.03)[-0.027]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Tue, 06 Oct 2020 17:23:14 -0000 On Tue, Oct 6, 2020, 11:03 AM Kamal R. Prasad wrote: > hello, > > i am curious if it is possible to compile c++ code inside the freebsd > kernel. > Possible? Yes, with restrictions. Easy? No. There are a number of restrictions on doing this. There is no C++ runtime support provided in stock FreeBSD. You have to write your own, or find someone else that has published theirs. And the code is likely to be compiler dependent. People have done it and talked or blogged about it. Generally, if you don't use exceptions, templates, RTTI, expressions that result in the automatic allocation of objects, have large objects (> 1k) on the stack, etc, it may be possible. I tried it in the 90s and had to write just a few routines to make simple classes work, but there's a lot of dragons here and very little C++ code is written these days w/o reference to the standard libraries, which aren't present in the kernel. Some googling turns up: https://github.com/adamlsd/libcpp.ko from 6 years ago https://lists.freebsd.org/pipermail/freebsd-arch/2018-June/019069.html has some details from 2 years ago about command line args you might need. Many have tried. Few have succeeded. Those that have write all their code to conform to a subset of the language. Few have had success moving C++ code for other purposes into the kernel, though if it was written using the proposed (but never ratified) eC++ (embedded subset), then chances are greater. Good luck Warner From owner-freebsd-arm@freebsd.org Tue Oct 6 18:59:42 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 C797B4392F4 for ; Tue, 6 Oct 2020 18:59:42 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5Rbd65Xyz3Y88 for ; Tue, 6 Oct 2020 18:59:41 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f52.google.com with SMTP id d197so14203588iof.0 for ; Tue, 06 Oct 2020 11:59:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fnSLL8amWNQS2yDrGCwtgyQoSasVbPOtrOjK7q2uPyY=; b=TP/+4AW9Q1e+feUhhCPQMQwwJUMWpnZAQaJ6ppgm2wyNaRDbTCbTEwF+TRUel2NjJF mKiWn5xDk4S3RDioMB1+9YKMp/TYq8t4/y6boK+MEgyzqTp00GBfcPu1mVJHDV1/xvN0 KP7GQ6uxPOrTGRf9v9uh9hSpU0vY3zVk+TY4FcN9S29YG9ZGQgoGDevryTuvdfmI/Xlz XQqBOqhAVGKhpEfN9Rru/462tsziYio1kGI69D2bqJqvSanhcRjfmRRA0LrFlHeE/4/j 9e0twvS5aoJdXirtubbldNK/OYFJGArn+yb0m/FLgb2VYF28B70YiaIk9a/H4BIOg3AU sf+A== X-Gm-Message-State: AOAM5313hkRcie6BDUtp3pPxj4rjd/+1e+W3q+d9G0bgAbSE+TrzwDPn YboNa8yjZaVtfdZ3K0S8ChBFQaMH6OAoF+dTC7cJZt4mM2I= X-Google-Smtp-Source: ABdhPJxpuFyhm8i74PLvuMKOYeRLbPdIutzXKUzMn+ec+fSv5VcO3KKoIUd623YVbzxywFcBHW9MR7kOhK2Xc3BuAb0= X-Received: by 2002:a6b:d80d:: with SMTP id y13mr2387144iob.15.1602010778984; Tue, 06 Oct 2020 11:59:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Tue, 6 Oct 2020 14:59:26 -0400 Message-ID: Subject: Re: BBB boot failure between r366365 and r366386 To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4C5Rbd65Xyz3Y88 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.56 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.02)[-1.015]; NEURAL_HAM_MEDIUM(-0.94)[-0.943]; TO_DN_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.52:from]; NEURAL_SPAM_SHORT(0.39)[0.393]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.52:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MAILMAN_DEST(0.00)[freebsd-arm]; TO_DOM_EQ_FROM_DOM(0.00)[] 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: Tue, 06 Oct 2020 18:59:42 -0000 On Mon, 5 Oct 2020 at 15:56, Ed Maste wrote: > > On Mon, 5 Oct 2020 at 09:53, Ed Maste wrote: > > > > Sometime after r366365 and up to r366365 BBB stopped booting in the HW > > test environment. > > That should of course be after r366365 and up to (and including) > r366386. Discussed on IRC; the second U-Boot banner comes out ~60s after the first, which might suggest a watchdog timeout. We seem to get stuck after > random: unblocking device. From owner-freebsd-arm@freebsd.org Tue Oct 6 20:29:33 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 DCDFC43AFCE for ; Tue, 6 Oct 2020 20:29:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5TbK42fFz3dg0 for ; Tue, 6 Oct 2020 20:29:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 88A1B43B38F; Tue, 6 Oct 2020 20:29:33 +0000 (UTC) Delivered-To: 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 872A243B38E for ; Tue, 6 Oct 2020 20:29:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5TbJ3MxYz3dlV; Tue, 6 Oct 2020 20:29:32 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=ByaUBi9Z0WZdA5l1V8VadPeJuSfT8U8kU9ZOoLR+sgg=; b=GdXjRR3itX/Bgw/MYk6fk3YhgTw6iXWlsjDESAIjEtPQ0mFhami5DVWSA8m8iIn8ClycInntDF68zS1Kgkk+n4Ph7RuCwtO0ZkFlkUEoYr7Zp+DW/vysb3NK7qUdIDXjlZ3M70VfthHgS3L4cwmTY67qvRGtMK3vmpOgvn7oy7O0UvJNHEip3pApBLMQXqhpXrOMEIR510bqRBfDTUz2TkkBaH9DMVdtxcoVWXQsMVCZ4WVm6YpjDT4v6WimA2kp+7qcRKig/lOfe0AAWh4+OB3jLEl1rMPTbskbiktL6RQ29uL44Vw+/sfGC5x4g62TypHmJfyU0oYonePRFCqhNg==; Received: from mbpro2.bk.cs.huji.ac.il ([132.65.179.20] helo=localhost.localdomain) by kabab.cs.huji.ac.il with esmtp id 1kPtaR-0005NO-5H; Tue, 06 Oct 2020 23:29:27 +0300 From: Daniel Braniss Message-Id: <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.33\)) Subject: Re: nanopi/allwinner i2c not working. Date: Tue, 6 Oct 2020 23:29:26 +0300 In-Reply-To: Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" To: Andriy Gapon References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> X-Mailer: Apple Mail (2.3654.0.3.2.33) X-Rspamd-Queue-Id: 4C5TbJ3MxYz3dlV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Tue, 06 Oct 2020 20:29:34 -0000 > On 6 Oct 2020, at 17:22, Andriy Gapon wrote: >=20 > On 06/10/2020 17:00, Daniel Braniss wrote: >> not too proud of it, but i=E2=80=99ll make it available. >> it=E2=80=99s in https://www.cs.huji.ac.il/~danny/elockc.tar.bz >> look in i2c.c >>=20 >> in any case it works fine in 12.1. >=20 > And it looks good to me as well. > Could you please collect twsi debug output again? > In head you do not need to recompile, you can just set = hw.i2c.twsi_debug. i did have to recompile iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 iichb0: twsi_reset: Using clock param=3D59 iichb0: TWSI_WRITE: Writing 0 to 18 iichb0: TWSI_WRITE: Writing 59 to 14 iichb0: TWSI_WRITE: Writing 40 to c iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 iichb0: twsi_reset: Using clock param=3D59 iichb0: TWSI_WRITE: Writing 0 to 18 iichb0: TWSI_WRITE: Writing 59 to 14 iichb0: TWSI_WRITE: Writing 40 to c iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_transfer: transmitting 2 messages iichb0: TWSI_READ: read f8 from 10 iichb0: twsi_transfer: status=3Df8 iichb0: twsi_transfer: msg 0 is 9 bytes long iichb0: twsi_transfer: msg 1 is 7 bytes long iichb0: TWSI_WRITE: Writing e4 to c iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 8 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: Send the address (48)iichb0: TWSI_WRITE: Writing 48 = to 8 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_intr: Refresh reg_control iichb0: TWSI_WRITE: Writing cc to c iichb0: twsi_intr: Done with interrupts iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 20 from 10 iichb0: TWSI_READ: read cc from c iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_intr: No ack received after transmitting the address iichb0: twsi_intr: Refresh reg_control iichb0: twsi_transfer: pause finish iichb0: TWSI_WRITE: Writing 8 to c iichb0: twsi_transfer: Error, aborting (2) iichb0: twsi_intr: Done with interrupts iichb0: TWSI_WRITE: Writing 0 to c iichb0: TWSI_READ: read 30 from 10 iichb0: twsi_transfer: status=3D30 iichb0: TWSI_WRITE: Writing 0 to c iichb0: TWSI_READ: read 30 from 10 iichb0: twsi_transfer: status=3D30 iichb0: TWSI_WRITE: Writing c4 to c iichb0: twsi_transfer: transmitting 2 messages iichb0: twsi_intr: Got interrupt Current msg=3D0 iichb0: TWSI_READ: read 30 from 10 iichb0: TWSI_READ: read 30 from 10 iichb0: twsi_transfer: status=3D30 iichb0: TWSI_READ: read cc from c iichb0: twsi_transfer: msg 0 is 9 bytes long iichb0: twsi_intr: reg control=3Dcc iichb0: twsi_transfer: msg 1 is 7 bytes long iichb0: twsi_intr: status=3D30 hot handled iichb0: TWSI_WRITE: Writing e4 to c iichb0: twsi_intr: Refresh reg_control iichb0: twsi_transfer: pause finish iichb0: TWSI_WRITE: Writing 8 to c iichb0: twsi_transfer: Error, aborting (1) iichb0: twsi_intr: Done with interrupts iichb0: TWSI_WRITE: Writing 0 to c iichb0: TWSI_READ: read 10 from 10 iichb0: twsi_transfer: status=3D10 iichb0: TWSI_WRITE: Writing 0 to c iichb0: TWSI_READ: read 10 from 10 iichb0: twsi_transfer: status=3D10 >=20 > --=20 > Andriy Gapon From owner-freebsd-arm@freebsd.org Tue Oct 6 21:26:32 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 DE91B43C0CA for ; Tue, 6 Oct 2020 21:26:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 4C5Vs34gw0z3gtw for ; Tue, 6 Oct 2020 21:26:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 6YNWuCwVM1n7IIfeCFhJ.jdDPxcCra6QCa1mnqC6Snr9IBPnlqP3ZiS.0jWHgFY .AtcUbdysZ8RJGSroPTScu3WOJDsv3fZ2CsZjT8ijwb07gARW3RDcHV9b25xyLKmD8QEK8AJDs94 9v0e8nj5eZAHVw1EY2Lc3r5suwGKAEvQSfYjC1AHmClcx0IvSkpI9mmLXCyY6DibpRD9frBZ80i2 j_epo.J9XVzTG0EDAj0VTKQ8dShuw802.5WSiTOmap.hBAcWuG1HidJRTfGDLrq0c2WZzsOvSUcJ wIxrWBLQC6Z_FA2kQZd6uU_CdlcbkTGbBfR1a2sWR_t3H4v0Y73PasrKW_qENBcqQbvlEN9FRDIp 6mL0XrfqG45v5c.Md1ZvPXIwmXs6ImC_I_oJB0lPJJ9f.2SnO4VRelVMMulKlbD.SLbTqYOinxSp a6AoZKTiDTFh551S69pa9Fz4IDnLNxUQ9SBSwt57JZbVvFcb.Qg9sPSqx8udNhhydDZUqhCpcMMS zc9pPpfn8fBCvOOcXVKvmCm0lQ4IG32SxRPwlFF8kUCzxxvZAJObul_K1pjRDNvZ5M84BUNXxDT9 Xrge3.ydd7eoBo2Ohw5yTBxCZyAnNa90xfndyy6VBIr8OkjBe6TUJTwpxZRBhTtdddKKTYOdIbHI TMVS_0Vc30Iuh1eM2DlXdx2KBVm9yQuKTQ5RwdSAZ4anfyjsOxpppOnbzRfNN_SnN_WHHFDBrPJ3 hxBvcJSEokHhYZApoukGlSf2KTrx3miHUu0P0FnLeemMZ1wFGGT3BKmSI0thuafyH2OohJkQyRGw CZ7xlo2NjfN.yezk5lRSARDygClzshignjMhYYPGfuEn1v1aU58Wj73wELNydhAXM3d_9mbTHJsi gTNaLSHT9.JOtJPxDS2md1a9K19bdgBUx38eL.THoxBZJkdhwmfDGrXG936seOnpEJZVQTRB3UCb n9ZYf7vltQPSBRMEQjjduPUbF1MomIJleckTI56RGy.9MB3sfe5v6J4w3yQV44OEQ3pqpmjYwr1V Sx_bB3sc5cOLfu1TGvh1dXO7uOBNw0BmdRSLzzJ6bnd66CWf3Ld1b9bM1DaXbZgGxdTj9rfKbjXM UG8XMCWGlLkWEo1f2z7.FU51_NsJGNwy2O2KpjookeV.UAxT6A0j_wbC1fPhZtzxiklamzHuhd6h TiyuR_06hJ0TmQdBT_rcHo2KJjPrN4nb2PVM40wPw2QkGReTR95ggH.DKz0fdd_SL9b.qGjcqEii I8OtHRdmpu_j0g__jqk_5mMRFqOL3ep7jDk1qeqF4X3RWZ7.NBYf.RW59mBGjwiz8UNrZongiDIT p.gwk_0Wd9MK.anTDMfc1rdY4asNFMODcptPaRfuTk1PgLI3JP3iOAnSCTVl1AQVDF1lwSICtCgU R65mjBQuQGCpfKsKFv8yuGr3fBV_VPLNexAJnnRO04nkMOTXgUSCoB2h9iLWH91m7VCk05dfWhHV Ud9LfXrWt0UW91MsCn44fkH3qCl3O6eKqKWhmIv6QzJficmBMbJcBpfhxjpezHwjXsW.qCbqTc_E jlhjr0JafxYm.xSn.Dqio0gL4ywM5jyvblac- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 Oct 2020 21:26:28 +0000 Received: by smtp422.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 534db2c7acdaa9f351ae946f578637b9; Tue, 06 Oct 2020 21:26:25 +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: Re: rpi4 FreeBSD vs. ubuntu u-boot fdt print / memereserve difference (lack of reserve in FreeBSD context), 0x3b400000 vs. DMA_HIGH_LIMIT being 0x3c000000 Date: Tue, 6 Oct 2020 14:26:24 -0700 References: <1A13F7B5-F8C3-4022-939C-2992E53D1DF1@yahoo.com> <01C14FE4-C2A6-4459-A5EE-AE33045FAF42@yahoo.com> <4D5162C2-592D-439C-9660-33A94DA5C807@yahoo.com> To: Robert Crowston , freebsd-arm In-Reply-To: <4D5162C2-592D-439C-9660-33A94DA5C807@yahoo.com> Message-Id: <14D4D816-3CF3-4911-91FB-2AA50A4D1C22@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C5Vs34gw0z3gtw X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.25 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.75)[-0.745]; FREEMAIL_TO(0.00)[protonmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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.983]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.017]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; 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: Tue, 06 Oct 2020 21:26:32 -0000 On 2020-Oct-4, at 01:41, Mark Millard wrote: >=20 > On 2020-Oct-3, at 20:15, Mark Millard wrote: >=20 >> . . . >=20 > Looking at the FreeBSD boot-time memory map > on the 8 GiByte RPi4B via a u-boot based boot > shows that the address ranges > 0x3b400000..0x3e512fff and > 0x3ebec000..0x3fffffff are not referenced > below (I inserted some notes): >=20 > Type Physical Virtual #Pages Attr > Reserved 000000000000 0 00000002 WB=20 > ConventionalMemory 000000002000 2000 00007eef WB=20 > ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB=20 > ConventionalMemory 000007f0f000 7f0f000 00029f71 WB=20 > BootServicesData 000031e80000 31e80000 00000001 WB=20 > LoaderData 000031e81000 31e81000 00008001 WB=20 > LoaderCode 000039e82000 39e82000 000000ad WB=20 > Reserved 000039f2f000 39f2f000 00000007 WB=20 > BootServicesData 000039f36000 39f36000 00000001 WB=20 > RuntimeServicesData 000039f37000 39f37000 00000001 WB RUNTIME > BootServicesData 000039f38000 39f38000 00000002 WB=20 > Reserved 000039f3a000 39f3a000 00000001 WB=20 > BootServicesData 000039f3b000 39f3b000 00000002 WB=20 > RuntimeServicesData 000039f3d000 39f3d000 00000002 WB RUNTIME > Reserved 000039f3f000 39f3f000 00000001 WB=20 > BootServicesData 000039f40000 39f40000 00000001 WB=20 > Reserved 000039f41000 39f41000 00000001 WB=20 > BootServicesData 000039f42000 39f42000 00000002 WB=20 > Reserved 000039f44000 39f44000 00000001 WB=20 > LoaderData 000039f45000 39f45000 0000140b WB=20 > RuntimeServicesCode 00003b350000 3b350000 00000010 WB RUNTIME > LoaderData 00003b360000 3b360000 000000a0 WB=20 > NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all = (even later) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even later) > BootServicesData 000040000000 40000000 000bc000 WB=20 > MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME > BootServicesData 000100000000 100000000 00100000 WB=20 > Physical memory chunk(s): > 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages) > 0x07f0f000 - 0x39f2efff, 800 MB ( 204832 pages) > 0x39f36000 - 0x39f39fff, 0 MB ( 4 pages) > 0x39f3b000 - 0x39f3efff, 0 MB ( 4 pages) > 0x39f40000 - 0x39f40fff, 0 MB ( 1 pages) > 0x39f42000 - 0x39f43fff, 0 MB ( 2 pages) > 0x39f45000 - 0x3b34ffff, 20 MB ( 5131 pages) > 0x3b360000 - 0x3b3fffff, 0 MB ( 160 pages) > NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all = (even later) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even later) > 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) > 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages) > Excluded memory regions: > 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 > 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc=20 > 0x32000000 - 0x33451fff, 20 MB ( 5202 pages) NoAlloc=20 > 0x39f2f000 - 0x39f35fff, 0 MB ( 7 pages) NoAlloc=20 > 0x39f37000 - 0x39f37fff, 0 MB ( 1 pages) NoAlloc=20 > 0x39f3a000 - 0x39f3afff, 0 MB ( 1 pages) NoAlloc=20 > 0x39f3d000 - 0x39f3ffff, 0 MB ( 3 pages) NoAlloc=20 > 0x39f41000 - 0x39f41fff, 0 MB ( 1 pages) NoAlloc=20 > 0x39f44000 - 0x39f44fff, 0 MB ( 1 pages) NoAlloc=20 > 0x3b350000 - 0x3b35ffff, 0 MB ( 16 pages) NoAlloc=20 > NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all = (even above) > 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20 Looks like the above "NoAlloc" line is from: /* Exclude the EFI framebuffer from our view of physical memory. = */ efifb =3D (struct efi_fb *)preload_search_info(kmdp, MODINFO_METADATA | MODINFOMD_EFI_FB); if (efifb !=3D NULL) physmem_exclude_region(efifb->fb_addr, efifb->fb_size, EXFLAG_NOALLOC); However, for the RPi4B, it looks like the EFI FrameBuffer is in a subrange of the more general "gpu_mem" area that can be sized by doing gpu_mem=3D or gpu_mem_1024=3D via config.txt . The size varies by changing the smaller memory address and runs to the end of the=20 1 GiByte area on RPi4B's. At least this gives a reason for the one NoAlloc range that did show up that is in the gpu_mem=3D/gpu_mem_1024=3D area (but without a containing "Physical memory chunk"). In the end, I do not expect that this contributes to the issue at hand: phys_avail and the like seem to omit the whole gpu_mem=3D area and so it looks like the gpu_mem=3D memory is avoided for allocation. > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even above) > 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 >=20 > Physical memory chunk(s): > 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) > 0x00000007f0f000 - 0x00000031ffffff, 705630208 bytes (172273 pages) > 0x00000033452000 - 0x00000039f2efff, 112054272 bytes (27357 pages) > 0x00000039f36000 - 0x00000039f36fff, 4096 bytes (1 pages) > 0x00000039f38000 - 0x00000039f39fff, 8192 bytes (2 pages) > 0x00000039f3b000 - 0x00000039f3cfff, 8192 bytes (2 pages) > 0x00000039f40000 - 0x00000039f40fff, 4096 bytes (1 pages) > 0x00000039f42000 - 0x00000039f43fff, 8192 bytes (2 pages) > 0x00000039f45000 - 0x0000003b34ffff, 21016576 bytes (5131 pages) > 0x0000003b360000 - 0x0000003b3fffff, 655360 bytes (160 pages) > NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all = (even above) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even above) > 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) > 0x00000100000000 - 0x000001f3840fff, 4085518336 bytes (997441 pages) >=20 > So: >=20 > #define DMA_HIGH_LIMIT 0x3c000000 >=20 > leads to the range for potential DMA use seeming to > overlap 0x3b400000..0x3bffffff (which is not mentioned > above). >=20 > Should the missing ranges have a classification above? > Is the lack of mention supposed to prevent the range > of memory's use for DMA activity? >=20 > I'll note that there are a bunch of explicitly "Excluded > memory regions" that overlap with the range for potential > DMA use as well. >=20 > Note: Use of gpu_mem_1024=3D256 in config.txt instead > produces (notes added again): >=20 > Type Physical Virtual #Pages Attr > Reserved 000000000000 0 00000002 WB=20 > ConventionalMemory 000000002000 2000 00007eef WB=20 > ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB=20 > ConventionalMemory 000007f0f000 7f0f000 0001eb71 WB=20 > BootServicesData 000026a80000 26a80000 00000001 WB=20 > LoaderData 000026a81000 26a81000 00008001 WB=20 > LoaderCode 00002ea82000 2ea82000 000000ad WB=20 > Reserved 00002eb2f000 2eb2f000 00000007 WB=20 > BootServicesData 00002eb36000 2eb36000 00000001 WB=20 > RuntimeServicesData 00002eb37000 2eb37000 00000001 WB RUNTIME > BootServicesData 00002eb38000 2eb38000 00000002 WB=20 > Reserved 00002eb3a000 2eb3a000 00000001 WB=20 > BootServicesData 00002eb3b000 2eb3b000 00000002 WB=20 > RuntimeServicesData 00002eb3d000 2eb3d000 00000002 WB RUNTIME > Reserved 00002eb3f000 2eb3f000 00000001 WB=20 > BootServicesData 00002eb40000 2eb40000 00000001 WB=20 > Reserved 00002eb41000 2eb41000 00000001 WB=20 > BootServicesData 00002eb42000 2eb42000 00000002 WB=20 > Reserved 00002eb44000 2eb44000 00000001 WB=20 > LoaderData 00002eb45000 2eb45000 0000140b WB=20 > RuntimeServicesCode 00002ff50000 2ff50000 00000010 WB RUNTIME > LoaderData 00002ff60000 2ff60000 000000a0 WB=20 > NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all = (even below) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even below) > BootServicesData 000040000000 40000000 000bc000 WB=20 > MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME > BootServicesData 000100000000 100000000 00100000 WB=20 > Physical memory chunk(s): > 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages) > 0x07f0f000 - 0x2eb2efff, 620 MB ( 158752 pages) > 0x2eb36000 - 0x2eb39fff, 0 MB ( 4 pages) > 0x2eb3b000 - 0x2eb3efff, 0 MB ( 4 pages) > 0x2eb40000 - 0x2eb40fff, 0 MB ( 1 pages) > 0x2eb42000 - 0x2eb43fff, 0 MB ( 2 pages) > 0x2eb45000 - 0x2ff4ffff, 20 MB ( 5131 pages) > 0x2ff60000 - 0x2fffffff, 0 MB ( 160 pages) > NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all = (even below) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even below) > 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) > 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages) > Excluded memory regions: > 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 > 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc=20 > 0x26c00000 - 0x28051fff, 20 MB ( 5202 pages) NoAlloc=20 > 0x2eb2f000 - 0x2eb35fff, 0 MB ( 7 pages) NoAlloc=20 > 0x2eb37000 - 0x2eb37fff, 0 MB ( 1 pages) NoAlloc=20 > 0x2eb3a000 - 0x2eb3afff, 0 MB ( 1 pages) NoAlloc=20 > 0x2eb3d000 - 0x2eb3ffff, 0 MB ( 3 pages) NoAlloc=20 > 0x2eb41000 - 0x2eb41fff, 0 MB ( 1 pages) NoAlloc=20 > 0x2eb44000 - 0x2eb44fff, 0 MB ( 1 pages) NoAlloc=20 > 0x2ff50000 - 0x2ff5ffff, 0 MB ( 16 pages) NoAlloc=20 (Line that was here moved down to track address-range ordering.) > NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all = (even above) 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20 (Again the EFI framebuffer.) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even above) > 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 >=20 > Physical memory chunk(s): > 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) > 0x00000007f0f000 - 0x00000026bfffff, 516886528 bytes (126193 pages) > 0x00000028052000 - 0x0000002eb2efff, 112054272 bytes (27357 pages) > 0x0000002eb36000 - 0x0000002eb36fff, 4096 bytes (1 pages) > 0x0000002eb38000 - 0x0000002eb39fff, 8192 bytes (2 pages) > 0x0000002eb3b000 - 0x0000002eb3cfff, 8192 bytes (2 pages) > 0x0000002eb40000 - 0x0000002eb40fff, 4096 bytes (1 pages) > 0x0000002eb42000 - 0x0000002eb43fff, 8192 bytes (2 pages) > 0x0000002eb45000 - 0x0000002ff4ffff, 21016576 bytes (5131 pages) > 0x0000002ff60000 - 0x0000002fffffff, 655360 bytes (160 pages) > NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all = (even above) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even above) > 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) > 0x00000100000000 - 0x000001f3cb5fff, 4090191872 bytes (998582 pages) >=20 >=20 > (Note: gpu_mem_1024=3D16 leads to the rpi firmware > messing up and being unable to read the microsd card > for later rpi firmware files that it needs. It > actually ended up doing a USB3 SSD based boot, in > my context a uefi/ACPI boot.) >=20 >=20 > gpu_mem_1024=3D32 produced (no notes this time): >=20 > Type Physical Virtual #Pages Attr > Reserved 000000000000 0 00000002 WB=20 > ConventionalMemory 000000002000 2000 00007eef WB=20 > ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB=20 > ConventionalMemory 000007f0f000 7f0f000 0002cb71 WB=20 > BootServicesData 000034a80000 34a80000 00000001 WB=20 > LoaderData 000034a81000 34a81000 00008001 WB=20 > LoaderCode 00003ca82000 3ca82000 000000ad WB=20 > Reserved 00003cb2f000 3cb2f000 00000007 WB=20 > BootServicesData 00003cb36000 3cb36000 00000001 WB=20 > RuntimeServicesData 00003cb37000 3cb37000 00000001 WB RUNTIME > BootServicesData 00003cb38000 3cb38000 00000002 WB=20 > Reserved 00003cb3a000 3cb3a000 00000001 WB=20 > BootServicesData 00003cb3b000 3cb3b000 00000002 WB=20 > RuntimeServicesData 00003cb3d000 3cb3d000 00000002 WB RUNTIME > Reserved 00003cb3f000 3cb3f000 00000001 WB=20 > BootServicesData 00003cb40000 3cb40000 00000001 WB=20 > Reserved 00003cb41000 3cb41000 00000001 WB=20 > BootServicesData 00003cb42000 3cb42000 00000002 WB=20 > Reserved 00003cb44000 3cb44000 00000001 WB=20 > LoaderData 00003cb45000 3cb45000 0000140b WB=20 > RuntimeServicesCode 00003df50000 3df50000 00000010 WB RUNTIME > LoaderData 00003df60000 3df60000 000000a0 WB=20 > BootServicesData 000040000000 40000000 000bc000 WB=20 > MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME > BootServicesData 000100000000 100000000 00100000 WB=20 > Physical memory chunk(s): > 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages) > 0x07f0f000 - 0x3cb2efff, 844 MB ( 216096 pages) > 0x3cb36000 - 0x3cb39fff, 0 MB ( 4 pages) > 0x3cb3b000 - 0x3cb3efff, 0 MB ( 4 pages) > 0x3cb40000 - 0x3cb40fff, 0 MB ( 1 pages) > 0x3cb42000 - 0x3cb43fff, 0 MB ( 2 pages) > 0x3cb45000 - 0x3df4ffff, 20 MB ( 5131 pages) > 0x3df60000 - 0x3dffffff, 0 MB ( 160 pages) > 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) > 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages) > Excluded memory regions: > 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 > 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc=20 > 0x34c00000 - 0x36051fff, 20 MB ( 5202 pages) NoAlloc=20 > 0x3cb2f000 - 0x3cb35fff, 0 MB ( 7 pages) NoAlloc=20 > 0x3cb37000 - 0x3cb37fff, 0 MB ( 1 pages) NoAlloc=20 > 0x3cb3a000 - 0x3cb3afff, 0 MB ( 1 pages) NoAlloc=20 > 0x3cb3d000 - 0x3cb3ffff, 0 MB ( 3 pages) NoAlloc=20 > 0x3cb41000 - 0x3cb41fff, 0 MB ( 1 pages) NoAlloc=20 > 0x3cb44000 - 0x3cb44fff, 0 MB ( 1 pages) NoAlloc=20 > 0x3df50000 - 0x3df5ffff, 0 MB ( 16 pages) NoAlloc=20 > 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20 (Above: again the EFI framebuffer inside the bigger gpu_mem area.) > 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 >=20 > Physical memory chunk(s): > 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) > 0x00000007f0f000 - 0x00000034bfffff, 751767552 bytes (183537 pages) > 0x00000036052000 - 0x0000003cb2efff, 112054272 bytes (27357 pages) > 0x0000003cb36000 - 0x0000003cb36fff, 4096 bytes (1 pages) > 0x0000003cb38000 - 0x0000003cb39fff, 8192 bytes (2 pages) > 0x0000003cb3b000 - 0x0000003cb3cfff, 8192 bytes (2 pages) > 0x0000003cb40000 - 0x0000003cb40fff, 4096 bytes (1 pages) > 0x0000003cb42000 - 0x0000003cb43fff, 8192 bytes (2 pages) > 0x0000003cb45000 - 0x0000003df4ffff, 21016576 bytes (5131 pages) > 0x0000003df60000 - 0x0000003dffffff, 655360 bytes (160 pages) > 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) > 0x00000100000000 - 0x000001f372afff, 4084379648 bytes (997163 pages) >=20 >=20 > I wonder if such could be contributing to why > DMA_HIGH_LIMIT had to be set smaller than the > 3 GiByte limit: to under a 1 GiByte limit. It looks like my ACPI boots are getting the EFI framebuffer being more like (default gpu_mem example, as I remember): 0x3e2fe000 - 0x3eae6fff, 7 MB ( 2025 pages) NoAlloc=20 again not having a containing "Physical memory chunk" (and, again in the gpu_mem=3D/gpu_mem_1024=3D area). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Oct 7 01:11:48 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 7426B43F9FD for ; Wed, 7 Oct 2020 01:11:48 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5brz37h7z49dS for ; Wed, 7 Oct 2020 01:11:47 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f193.google.com with SMTP id o18so810589ill.2 for ; Tue, 06 Oct 2020 18:11:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/IrZasmyRwg8zxbati5NkluzXbKs4ICZMw+O6OZVIqY=; b=rOXpdc0LUw3UpUGQIFoq7bkOQZKmkGMiOqJBMj7taJgwZr3yw9xQtNa3dkzROh3cjB 2GngrpK803BgsTMnVZ7YFGiXuj2lBapK7lfpzAspfWDdgFWA1hznDKb+uigAT80F4Md7 Kvd0W1LaXjBJu2zQjZODoCY4zLy/nyqXNf2snQaulffzbiJEkvTPfnRyS6TXOHa+ohEt ApqchjUNDC+zw7UtTl7i5Ax63SjwodafGKSac7QU8+fxVACoqg3/LLWezKpJJrNQ84NG KH9MIaeqsnzRi5IIC7oQSG06vHiuXFsOyh4GzCjdztVkymdjGdPMzVyJ/YPnCT4pjmvM IS/g== X-Gm-Message-State: AOAM531G7I5z+y7UjyuCJ9tQQnjDZZiRjunMDM6C34h/eINoKpZQ7oP3 5yqCYZYqd1AkobceoA1H16Raxt0geoGF33kybo2zAaNiRXk= X-Google-Smtp-Source: ABdhPJwAZE2wsORxz8FSGordruZuyZA1+KS930/wpCOwBTNbNHN+Jso5NhjY5r1isLIqZk3rByBVZRaqBOX0JjcwLss= X-Received: by 2002:a92:998d:: with SMTP id t13mr769804ilk.256.1602033103476; Tue, 06 Oct 2020 18:11:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Tue, 6 Oct 2020 21:11:31 -0400 Message-ID: Subject: Re: BBB boot failure between r366365 and r366386 To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4C5brz37h7z49dS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.193 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.10 / 15.00]; TO_DOM_EQ_FROM_DOM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; NEURAL_HAM_MEDIUM(-0.75)[-0.751]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.02)[-1.015]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.33)[-0.329]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.193:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.193:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] 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: Wed, 07 Oct 2020 01:11:48 -0000 On Tue, 6 Oct 2020 at 14:59, Ed Maste wrote: > > On Mon, 5 Oct 2020 at 15:56, Ed Maste wrote: > > > > On Mon, 5 Oct 2020 at 09:53, Ed Maste wrote: > > > > > > Sometime after r366365 and up to r366365 BBB stopped booting in the HW > > > test environment. > > > > That should of course be after r366365 and up to (and including) > > r366386. > > Discussed on IRC; the second U-Boot banner comes out ~60s after the > first, which might suggest a watchdog timeout. > > We seem to get stuck after > > random: unblocking device. kevans points out that std.armv7 includes VERBOSE_SYSINIT=0, so verbose sysinits are available with a loader tunable. We get this far: subsystem 2140000 init_hwpmc(0)... done. init_dtrace(0)... done. pmc_soft_ev_register(&pmc___lock_failed)... done. pmc_soft_ev_register(&pmc___clock_prof)... done. pmc_soft_ev_register(&pmc___clock_hard)... done. pmc_soft_ev_register(&pmc___clock_stat)... done. subsystem 2160000 random_fortuna_init_alg(0)... done. random_harvestq_init(0)... done. random_harvestq_prime(0)... done. __stack_chk_init(0)... random: unblocking device. done. subsystem 2180000 mac_init(0)... done. subsystem 21d0000 mac_late_init(0)... done. subsystem 21e0000 vnet0_init(0)... done. subsystem 2200000 proc0_init(0)... done. shutdown_conf(0)... done. subsystem 2300000 vm_stats_init(0)... done. uma_startup3(0)... done. vm_page_init_cache_zones(0)... done. subsystem 2380000 db_capture_sysinit(0)... done. subsystem 2400000 sched_setup(0)... done. subsystem 2480000 ktrace_init(0)... From owner-freebsd-arm@freebsd.org Wed Oct 7 03:58:24 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 4B62E3F98B9 for ; Wed, 7 Oct 2020 03:58:24 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5gYC2kS4z4HZy for ; Wed, 7 Oct 2020 03:58:23 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x343.google.com with SMTP id z22so3543715wmi.0 for ; Tue, 06 Oct 2020 20:58:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=ggT2B42Re5sb/TZ6PLSuM1tCY3ec5Ezvp4Ws/O71SRY=; b=VF6HQEx0klni/fGs1O5PevIamPlj3mV/KIAgDOM1Ha7w8Z9rtxeVlTm36XDDq213ZM qsRY/vVZyH1CWwasCagqOZn3rzfxepXquHX0hyNyaWNkHsDTARcVSslsYN3buzQWwuay 88rCLhg9+y+qaGN8/Bx1ysVsdtz5l5GVnKEWB60BZTJpTaoxkQoLLfQC/wMWNPGjzZIi l2xUzMXYtJVlxOaeDyhEOz1u3XkwTwMDFUCdQsXMGvhvd+FESzC9DeQg6lZMqo0fvb3b ZUF8jgDeXTFyyNdDlHdnicatTZc95n6j4F6k7OMtdKyTan9+ErP+ezz95cWFcvoZhy6K s29A== X-Gm-Message-State: AOAM532SWXYLZkKpU+AaZrYcHpOzOmHnht9l0fkKd452ZqHSF2RO6KsC gK3D5ou4oTjD69GuSss+xcw8bNpWT1I= X-Google-Smtp-Source: ABdhPJywa/jI0RUFl6oDI4QYUGSx5oa4ern0XpwM8x+237yyCW6W+v60Oti4Z7ZUIWlCueTVHIT2TA== X-Received: by 2002:a1c:9d90:: with SMTP id g138mr946775wme.5.1602042695448; Tue, 06 Oct 2020 20:51:35 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-105-155.46.114.pool.telefonica.de. [46.114.105.155]) by smtp.googlemail.com with ESMTPSA id o129sm805580wmb.25.2020.10.06.20.51.34 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 20:51:34 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPI4 U-Boot 2020.10-rc5 please test xhci feature Date: Wed, 7 Oct 2020 05:51:32 +0200 References: <81140AD2-2AAF-4378-ABB2-8F5B608DE7F7@googlemail.com> To: freebsd-arm@freebsd.org In-Reply-To: <81140AD2-2AAF-4378-ABB2-8F5B608DE7F7@googlemail.com> Message-Id: X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C5gYC2kS4z4HZy X-Spamd-Bar: +++++++ X-Spamd-Result: default: False [7.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,body]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(0.00)[googlemail.com,quarantine]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.105.155:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[46.114.105.155:received]; R_DKIM_ALLOW(0.00)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.05)[0.052]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(0.96)[0.956]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; NEURAL_SPAM_LONG(1.03)[1.030]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::343:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-Spam: Yes 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: Wed, 07 Oct 2020 03:58:24 -0000 > Am 05.10.2020 um 07:45 schrieb Klaus Cucinauomo = : >=20 > ( https://wiki.freebsd.org/arm/Raspberry%20Pi#RPI4 ) >=20 > new compiled U-Boot version U-Boot 2020.10-rc5 >=20 > =E2=80=94- 1st try with default settings/files/configuratios ext. = USB-SSD/ no SD-card present:=E2=80=94 >=20 > =E2=80=A6=E2=80=A6=E2=80=A6..U-Boot 2020.10-rc5 (Oct 05 2020 - = 03:08:23 +0000) >=20 > DRAM: 7.9 GiB > RPI 4 Model B (0xd03114) > MMC: mmc@7e300000: 1, emmc2@7e340000: 0 > Loading Environment from FAT... In: serial > Out: vidconsole > Err: vidconsole > Net: eth0: ethernet@7d580000 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus xhci_pci: probe failed, error -110 > No working controllers found=E2=80=A6=E2=80=A6=E2=80=A6. > =E2=80=94 > 2020.10-rc5 boots fine from SD-card >=20 > happy testing=20 >=20 > thanks > Regards > Klaus >=20 >=20 The 4GB-model scans xhci correctly (although not detecting kernel/filesystem for now in early testing) (Same disk as on 8GB-test,no SD-card present, `ve changed some files in = msdos-partition (start4.elf, config.txt,/overlays etc.)) while the=20 8GB model needs further patches because the VL805 - firmware=20 is no more loaded by an own eeprom , so has to be loaded explicitly by = the=20 SoC's VideoCore. U-Boot 2020.10-rc5 (Oct 05 2020 - 03:08:23 +0000) DRAM: 3.1 GiB RPI 4 Model B (0xc03111) MMC: mmc@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: serial Err: serial Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0=20 Card did not respond to voltage select! Device 0: Vendor: JMicron Rev: 3202 Prod: Tech =20 Type: Hard Disk Capacity: 114473.4 MB =3D 111.7 GB (234441648 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@7e300000.blk... Disk mmc@7e300000.blk not ready Card did not respond to voltage select! Scanning disk emmc2@7e340000.blk... Disk emmc2@7e340000.blk not ready Scanning disk usb_mass_storage.lun0... ** Unrecognized filesystem type ** Found 3 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image 688192 bytes read in 5 ms (131.3 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi Consoles: EFI console =20 Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: failed to allocate staging area: 9 failed to allocate staging area ## Application failed, r =3D 5 EFI LOAD FAILED: continuing... BOOTP broadcast 1 BOOTP broadcast 2 = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Klaus From owner-freebsd-arm@freebsd.org Wed Oct 7 04:43:51 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 E65F83FB052 for ; Wed, 7 Oct 2020 04:43:51 +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 4C5hYf2yRhz4KLn for ; Wed, 7 Oct 2020 04:43:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Ee0Fs1MVM1mnxiYnwuTov1.bWKKYbWDvAGazIffSJkl0ePtPvz8Ueej8lsZA.Bd vZVK6tyBFqwEKXCLaZPRHum991pLULcUJazD1Xh7F4LdisBl1cax5AxPcvdY16_4LxIPeLWTAkkw ewhgtSuDCxS7lxystnimEyfUVHxBXbcQ.SmKTvU06n.9c0ymuDPM6aqDDk_S7R8wOI64b1JjJJu7 n2s_VJG.z4U0Fld47Jnf_trm3K909RIsolnKHyZD3aWpQhzT0rapHtuCnlTE2VqKKz1uvYsehXCP enzQBdtgJ1WBCC7nidmpQUouYCYpSIHcS93Pm3pRjmmTM_q.l80srZVUqXrW.vNJrcsEBpVBSIOE L5v46LBTbcdDC_wz_jni7uEPARIuvupgnHH4.xHxqZSF_sx0BCCQlGvNw86GJYifpO8QxVl3bQdu NLg2mcWK21dGrtyPdkeAZdDXRdsk6RpoF9UepuNYJV6ksGHncufSQKRbCU5z240izIDvLHc5wi8Q GhDIQGhzWI7eLgJv.CEFlYd.zlhtSwvbv.5Dla4mPSjP0.eolcISttkv._n0ixrSgL6g3bC2BjY1 DvBvmvlpFFKfjsiI.52TNMnKknLKlgiqHb..V4TN3fdLECAyk816pMUtcqCWLHOaqF52X36Xs706 A52KWWHpQgU.QE9YeVxnt3YGUDR5Y.nW2wH.r8l2__X1NGCf9xYO1bhWul3f.otbZ7VfcT6uuM2N h5AiV8sL1E59wvCbIaMQEw7rqocD54MmGkgRQX1vKXMZ_gXbsLJEz454NxzGyzFF2TVoM9Cjwxyu 0s7iyKqOmaBy.d.Br81cUyLQyYb_6SPzH0EZLn98JAqITJZzu3anyVAmy27sD38VZZ26uI96aEUG CD9Kgin8CleFxO1ai8kkJ7tjTU7DR.mj5mC2hxz99f8Ohx0_o.5AkSbGbtePl5mgop3ajpum5PjK eCDj5K6Pd1qW5JoTS9A3uvnZ429exB6ccj6mSTURbsiciLhtHSKBKd2uR7c40eeuHy6M9tHbN3.s XD5o1Rc1XseOPCfn7.mV76qqcmNmP1MQvSG9ap6zc3y2OMSIjAvsR17bcSIjdQ0WWmwhVa3jJJr3 .P.XGARMflV8GIyqVZDizxnNCxGsQ_rF4hL1kDsoDg5KpN7cDRgBgqVEKGY7GNPE6o6rncvDlEXi 7hLTccfsU5AO9rAawTbuDXy0HM318wal0kOwoEj9oAeeeEjOA9aLP_k1IbxEM3IQKqoJ.sYASzQW dJVIZRle35Q4dDu5hrwi72.2t_Tt7YeG8AE8IM0_1B9yGDjukTiSVIo4AKXw1I.YT410.tMWaEgc Y0BUVWHJ9CHC1uuEp5N9.Gopbs33eEhNSLakFpAgB1HChS49x1Xoq_XjEil.g0DYz4CVRPk3HGTs FT2R32R63CWkJGrQ40hLFgZd0lGETdVblksmiWyEqQnq_M1q1bJwisQ3viimwWJQBRbzXksu62ek 9Z8QuFk.osstuG3zOGfenoX0K.atYJDOCLDQtIgl_uWAFZWn4zpC3v9KcYNkj9juXjotZ.BU2KA- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Oct 2020 04:43:47 +0000 Received: by smtp409.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 80db86b1a6b320d6c43a129ec1bbfaec; Wed, 07 Oct 2020 04:43:43 +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: A basis for a possible update to the pcie based xhci support? It survived huge-file duplicate-then-diff testing so far. Message-Id: <31C1F4F8-6727-4EBE-9D20-39F5B2DA89A5@yahoo.com> Date: Tue, 6 Oct 2020 21:43:42 -0700 To: Robert Crowston , freebsd-arm X-Mailer: Apple Mail (2.3608.120.23.2.1) References: <31C1F4F8-6727-4EBE-9D20-39F5B2DA89A5.ref@yahoo.com> X-Rspamd-Queue-Id: 4C5hYf2yRhz4KLn X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.73 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.19)[-1.194]; FREEMAIL_TO(0.00)[protonmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.02)[-1.022]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.018]; MIME_GOOD(-0.10)[text/plain]; 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]; 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: Wed, 07 Oct 2020 04:43:52 -0000 Note: based on a head -r363932 context, not more recent. First off, a note about lowaddr values. What sysctl showed me were the likes of (prior to the changes that this note is about): . . . hw.busdma.zone2.lowaddr: 0x3c000fff . . . hw.busdma.zone1.lowaddr: 0x3fffffff . . . hw.busdma.zone0.lowaddr: 0xffffffff . . . So I've guessed that lowaddr should identify the end page of the possibly-use-it region, not the first do-not-use-it page. If wrong, at most it should avoid bouncing one page that it could avoid. But, if correct, it might bounce a page that it should instead of not doing so. Otherwise what I've done is put back some of your old bcm2838_pci.c code and removed the sc->sc_bus.dma_bits adjustment from the bcm2838_xhci.c code. Be warned that I copied the likes of REG_VALUE_4GB_WINDOW and REG_VALUE_4GB_CONFIG without understanding the values or encoding. (I'm not pcie knowledgable.) # svnlite diff /usr/src/sys/arm/broadcom/ Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (revision = 365932) +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (working copy) @@ -91,27 +91,22 @@ #define REG_EP_CONFIG_CHOICE 0x9000 #define REG_EP_CONFIG_DATA 0x8000 =20 +#define REG_VALUE_4GB_WINDOW 0x11 +#define REG_VALUE_4GB_CONFIG 0x88003000 + /* * The system memory controller can address up to 16 GiB of physical = memory * (although at time of writing the largest memory size available for = purchase - * is 8 GiB). However, the system DMA controller is capable of = accessing only a - * limited portion of the address space. Worse, the PCI-e controller = has further - * constraints for DMA, and those limitations are not wholly clear to = the - * author. NetBSD and Linux allow DMA on the lower 3 GiB of the = physical memory, - * but experimentation shows DMA performed above 960 MiB results in = data - * corruption with this driver. The limit of 960 MiB is taken from = OpenBSD, but + * is 8 GiB). However, the system DMA controller in early enough boards = is + * capable of accessing only a limited portion of the address space (3 = GiByte). + * Worse, the PCI-e controller has further constraints for DMA, and = those + * limitations are not wholly clear to the author. NetBSD and Linux = allow + * DMA on the lower 3 GiB of the physical memory. OpenBSD used 960 = MiByte but * apparently that value was chosen for satisfying a constraint of an = unrelated * peripheral. - * - * Whatever the true maximum address, 960 MiB works. */ -#define DMA_HIGH_LIMIT 0x3c000000 -#define MAX_MEMORY_LOG2 0x21 -#define REG_VALUE_DMA_WINDOW_LOW (MAX_MEMORY_LOG2 - 0xf) +#define DMA_HIGH_LIMIT ((bus_addr_t)0xc0000000u-1) #define REG_VALUE_DMA_WINDOW_HIGH 0x0 -#define DMA_WINDOW_ENABLE 0x3000 -#define REG_VALUE_DMA_WINDOW_CONFIG \ - (((MAX_MEMORY_LOG2 - 0xf) << 0x1b) | DMA_WINDOW_ENABLE) =20 #define REG_VALUE_MSI_CONFIG 0xffe06540 =20 @@ -645,9 +640,9 @@ DMA_HIGH_LIMIT, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ - DMA_HIGH_LIMIT, /* maxsize */ + BUS_SPACE_MAXSIZE, /* maxsize */ BUS_SPACE_UNRESTRICTED, /* nsegments */ - DMA_HIGH_LIMIT, /* maxsegsize */ + BUS_SPACE_MAXSIZE, /* maxsegsize */ 0, /* flags */ NULL, NULL, /* lockfunc, lockarg */ &sc->dmat); @@ -674,9 +669,9 @@ * Set PCI->CPU memory window. This encodes the inbound window = showing * the system memory to the controller. */ - bcm_pcib_set_reg(sc, REG_DMA_WINDOW_LOW, = REG_VALUE_DMA_WINDOW_LOW); + bcm_pcib_set_reg(sc, REG_DMA_WINDOW_LOW, REG_VALUE_4GB_WINDOW); bcm_pcib_set_reg(sc, REG_DMA_WINDOW_HIGH, = REG_VALUE_DMA_WINDOW_HIGH); - bcm_pcib_set_reg(sc, REG_DMA_CONFIG, = REG_VALUE_DMA_WINDOW_CONFIG); + bcm_pcib_set_reg(sc, REG_DMA_CONFIG, REG_VALUE_4GB_CONFIG); =20 bcm_pcib_set_reg(sc, REG_BRIDGE_GISB_WINDOW, 0); bcm_pcib_set_reg(sc, REG_DMA_WINDOW_1, 0); Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c (revision = 365932) +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c (working copy) @@ -189,15 +189,7 @@ bcm_xhci_install_xhci_firmware(dev); =20 error =3D xhci_pci_attach(dev); - if (error) - return (error); - - /* 32 bit DMA is a limitation of the PCI-e controller, not the = VL805. */ - sc->sc_bus.dma_bits =3D 32; - if (bootverbose) - device_printf(dev, "note: switched to 32-bit DMA.\n"); - - return (0); + return (error); } =20 /* I've concluded from what I've seen in the code that lowaddr should be based on the pcie properties and should not worry about the maxsize and maxseg size figures being possibly smaller: that is a dma engine use worry, not a pci one. (Not that I could get that from the documentation that I quoted in the review.) Thus I put back the 2 BUS_SPACE_MAXSIZE uses. After the first huge-file duplicate-then-diff test sysctl reported lots of bounced transfers: # sysctl hw.busdma hw.busdma.zone1.alignment: 4096 hw.busdma.zone1.lowaddr: 0x3fffffff hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.total_bounced: 755770 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.free_bpages: 838 hw.busdma.zone1.total_bpages: 838 hw.busdma.zone0.alignment: 4096 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.active_bpages: 256 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.free_bpages: 257 hw.busdma.zone0.total_bpages: 513 hw.busdma.total_bpages: 1351 For the non-power-of-2 boundary (0xc0000000-1), it appears to use the next smaller power of 2 for the boundary (0x40000000-1), without having to explicitly code both types of values specially for the RPi4B. (Of course, it also avoids using 2 GiBytes to potentially avoid more bouncing.) I'll note that, prior to the change, there was after an example first test: hw.busdma.zone2.total_bounced: 1091942 and 174 in zone 1. So the bounce count has decreased. I'll note that "total_bounced" need not be the a page count: it is incremented by 1 after the loop for a bounce, not inside the loop. Lots of pages of data were bounced. For reference (the test as of a gpu_mem_1024=3D32 context): Physical memory chunk(s): 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) 0x00000007f0f000 - 0x00000034bfffff, 751767552 bytes (183537 pages) 0x00000036052000 - 0x0000003cb2efff, 112054272 bytes (27357 pages) 0x0000003cb36000 - 0x0000003cb36fff, 4096 bytes (1 pages) 0x0000003cb38000 - 0x0000003cb39fff, 8192 bytes (2 pages) 0x0000003cb3b000 - 0x0000003cb3cfff, 8192 bytes (2 pages) 0x0000003cb40000 - 0x0000003cb40fff, 4096 bytes (1 pages) 0x0000003cb42000 - 0x0000003cb43fff, 8192 bytes (2 pages) 0x0000003cb45000 - 0x0000003df4ffff, 21016576 bytes (5131 pages) 0x0000003df60000 - 0x0000003dffffff, 655360 bytes (160 pages) 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) 0x00000100000000 - 0x000001f372afff, 4084379648 bytes (997163 pages) FYI, before the huge-file duplicate-and-diff test: # sysctl hw.busdma hw.busdma.zone1.alignment: 4096 hw.busdma.zone1.lowaddr: 0x3fffffff hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.total_bounced: 866 hw.busdma.zone1.active_bpages: 2 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.free_bpages: 836 hw.busdma.zone1.total_bpages: 838 hw.busdma.zone0.alignment: 4096 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.active_bpages: 256 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.free_bpages: 257 hw.busdma.zone0.total_bpages: 513 hw.busdma.total_bpages: 1351 After the duplicate but before the diff: # sysctl hw.busdma hw.busdma.zone1.alignment: 4096 hw.busdma.zone1.lowaddr: 0x3fffffff hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.total_bounced: 513604 hw.busdma.zone1.active_bpages: 8 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.free_bpages: 830 hw.busdma.zone1.total_bpages: 838 hw.busdma.zone0.alignment: 4096 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.active_bpages: 256 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.free_bpages: 257 hw.busdma.zone0.total_bpages: 513 hw.busdma.total_bpages: 1351 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Oct 7 04:50:46 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 1F45D3FADD2 for ; Wed, 7 Oct 2020 04:50:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4C5hjd1bT7z4KGS for ; Wed, 7 Oct 2020 04:50:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: p8a2FC0VM1nf_iIm7nn56a6WyjODa6a7J1isb4Vt7cYost4n0uCyucL9OF1pKAz FhChw17huD2oFzUEu0y1XPvcbfoWP.4t1dTFtc7o56TbD8uazzRUCmvyFvRn3x8nXyI2tvBazoFw P0GHw0rlF.Fn1i9Uq2ORGQ47lvreHuN2pKU_wnZo4y8Jpzu.4a0e.Zwh5VkpVWEQC24ZttL_JfIe 6Jlev.kFGvNRnLgmVnFtz5eFR4hgw.sWBEh5WGu8uF0LwlmqKXSHlJG0Ik8WLy79EgGM_s6IzPBW DD.PjCooPce8BLO7uBxXJf3A6hmF9UiqkPvyh9Xfxsp6abg8jE0tbUNnG9LaFLu5plY4IbWZJUYe EgR0NfGnPi7ZGtefrFrKG1cSMXv7VEADnHl22y1Ua.VMFnaSGb6ZyV2G2yvqua73bD0Mb2Jj1X4w AW3cXrryz5TLTtdvUIvDdm0.e_2LdAxYTK8BFPirCpM2uwlmFDbg3ruLPcrrQCMoJ0oLFk.cEdBt Vey.JedjJbSEoFohkyPgsbL83lNdTgRfjGgdsWGewBSmWguzZkEnoYDZMJuLm4Jbe1UBfG4acsWG Xo.jH2.1UWOVDv1rujSsSEl4wuWWrQB6KkojZAl1cNtA_qUzOhaNhWTt847zbQhnuPlmMv_hQ1wa Ikp6XpdXR0qCRnhP6rKCNJrfROZpukmYDJJV0BN4RHKET.N3XTjbmTnReZMxlsfYGxjL4oMPiw95 Jywl0LA0YPUU4hvgBpAcdz.tO5TdzSB1tEkmrtdgCn_D6jzL_bmvGgn4XbV64YFlTG5mBNSzv9Sd JiX_SnH5msQeFsS..VBbmOp6VBWXisUkYymCCnsafTTOO4OIWk_cw_yrSYXdpEklO9Any3saXRT9 3bU5unhjMmuPybeNrBt2TfP3bqYfC0p3QS8BdrQywGO9GGZbyFTzaCqEHYoGYlk649Dk6c6CbqIn ZClq9jIYtsAfZJ2.K0rQPfUTCz56QB7LqBsiLu0_FcrYUs16AX3OlXr0mURfNSSPtiFXxgIvsGv0 QBH8vxRca.GwLDeLH6jaxglmaqYQdm659.dKSbVNaStr1IX4C11WRdGZ7WklAe_bx4IgP.7HTwHR nXYOlu4_5GFRiZoXi3QsyXd7ufo5vPMGNln1oF0_sBid6AUfbyipI5stGeuWBz.mVosRc7BIdiFF T4aaReDdHW4uyjKxFf56UN70Sfl9rhFJ8E4yBxaR7MtaO2Qmvem_9MlCRE2sys2b6uWhNYkvK0G0 FwAYqUIEsAk2yewmG.Ou2Gwehc_ZzwN8CP1q_PnfrBtJoT9lOhKDQFkRMeMHvjlDRgMW6JkauhxO R_ZAw6uLD4keAOum5V0MrfpfUsb3Pv8MUSr4oTgP_InzGKjH.h2rVJHPyXYJam3GLE82RbXos5m. dVLsIB0.YDw7NGb52h0R2AEK98.eY62rwnVPS.DGxLjXTTyhmGo99r6yMbP0pcIcGWaI9Yf6g96M uui5uJ5F2L2zbtFER3kBNuWz.Bzu4QYmhwLxhXg30afoMpsXV8nJdCR6v1PHAMHSFuvjtAkKjo5N ql2n_S_IWPig8nKSkEOfbRKvgR_BVXV_zkMA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Oct 2020 04:50:42 +0000 Received: by smtp418.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2ae6e81db8dd70c0fe6ae8b3696829a6; Wed, 07 Oct 2020 04:50:38 +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: Re: A basis for a possible update to the pcie based xhci support? It survived huge-file duplicate-then-diff testing so far. Date: Tue, 6 Oct 2020 21:50:36 -0700 References: <31C1F4F8-6727-4EBE-9D20-39F5B2DA89A5@yahoo.com> To: Robert Crowston , freebsd-arm In-Reply-To: <31C1F4F8-6727-4EBE-9D20-39F5B2DA89A5@yahoo.com> Message-Id: <0A440C23-7D21-4515-B872-1C64FF80A873@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C5hjd1bT7z4KGS X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.73 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.19)[-1.191]; FREEMAIL_TO(0.00)[protonmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.02)[-1.022]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.019]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; 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: Wed, 07 Oct 2020 04:50:46 -0000 On 2020-Oct-6, at 21:43, Mark Millard wrote: > Note: based on a head -r363932 context, not more recent. >=20 > First off, a note about lowaddr values. What sysctl showed > me were the likes of (prior to the changes that this note > is about): >=20 > . . . > hw.busdma.zone2.lowaddr: 0x3c000fff > . . . > hw.busdma.zone1.lowaddr: 0x3fffffff > . . . > hw.busdma.zone0.lowaddr: 0xffffffff > . . . >=20 > So I've guessed that lowaddr should identify the > end page of the possibly-use-it region, not the > first do-not-use-it page. > If wrong, at most it > should avoid bouncing one page that it could > avoid. That was a wonderfully messed up sentence. Trying again: "If wrong, at most it would bounce one page that it could avoid bouncing." > But, if correct, it might bounce a page > that it should instead of not doing so. >=20 > Otherwise what I've done is put back some of your old > bcm2838_pci.c code and removed the sc->sc_bus.dma_bits > adjustment from the bcm2838_xhci.c code. Be warned > that I copied the likes of REG_VALUE_4GB_WINDOW and > REG_VALUE_4GB_CONFIG without understanding the values > or encoding. (I'm not pcie knowledgable.) >=20 > # svnlite diff /usr/src/sys/arm/broadcom/ > Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (revision = 365932) > +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (working copy) > @@ -91,27 +91,22 @@ > #define REG_EP_CONFIG_CHOICE 0x9000 > #define REG_EP_CONFIG_DATA 0x8000 >=20 > +#define REG_VALUE_4GB_WINDOW 0x11 > +#define REG_VALUE_4GB_CONFIG 0x88003000 > + > /* > * The system memory controller can address up to 16 GiB of physical = memory > * (although at time of writing the largest memory size available for = purchase > - * is 8 GiB). However, the system DMA controller is capable of = accessing only a > - * limited portion of the address space. Worse, the PCI-e controller = has further > - * constraints for DMA, and those limitations are not wholly clear to = the > - * author. NetBSD and Linux allow DMA on the lower 3 GiB of the = physical memory, > - * but experimentation shows DMA performed above 960 MiB results in = data > - * corruption with this driver. The limit of 960 MiB is taken from = OpenBSD, but > + * is 8 GiB). However, the system DMA controller in early enough = boards is > + * capable of accessing only a limited portion of the address space = (3 GiByte). > + * Worse, the PCI-e controller has further constraints for DMA, and = those > + * limitations are not wholly clear to the author. NetBSD and Linux = allow > + * DMA on the lower 3 GiB of the physical memory. OpenBSD used 960 = MiByte but > * apparently that value was chosen for satisfying a constraint of an = unrelated > * peripheral. > - * > - * Whatever the true maximum address, 960 MiB works. > */ > -#define DMA_HIGH_LIMIT 0x3c000000 > -#define MAX_MEMORY_LOG2 0x21 > -#define REG_VALUE_DMA_WINDOW_LOW (MAX_MEMORY_LOG2 - 0xf) > +#define DMA_HIGH_LIMIT = ((bus_addr_t)0xc0000000u-1) > #define REG_VALUE_DMA_WINDOW_HIGH 0x0 > -#define DMA_WINDOW_ENABLE 0x3000 > -#define REG_VALUE_DMA_WINDOW_CONFIG \ > - (((MAX_MEMORY_LOG2 - 0xf) << 0x1b) | DMA_WINDOW_ENABLE) >=20 > #define REG_VALUE_MSI_CONFIG 0xffe06540 >=20 > @@ -645,9 +640,9 @@ > DMA_HIGH_LIMIT, /* lowaddr */ > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ > - DMA_HIGH_LIMIT, /* maxsize */ > + BUS_SPACE_MAXSIZE, /* maxsize */ > BUS_SPACE_UNRESTRICTED, /* nsegments */ > - DMA_HIGH_LIMIT, /* maxsegsize */ > + BUS_SPACE_MAXSIZE, /* maxsegsize */ > 0, /* flags */ > NULL, NULL, /* lockfunc, lockarg */ > &sc->dmat); > @@ -674,9 +669,9 @@ > * Set PCI->CPU memory window. This encodes the inbound window = showing > * the system memory to the controller. > */ > - bcm_pcib_set_reg(sc, REG_DMA_WINDOW_LOW, = REG_VALUE_DMA_WINDOW_LOW); > + bcm_pcib_set_reg(sc, REG_DMA_WINDOW_LOW, REG_VALUE_4GB_WINDOW); > bcm_pcib_set_reg(sc, REG_DMA_WINDOW_HIGH, = REG_VALUE_DMA_WINDOW_HIGH); > - bcm_pcib_set_reg(sc, REG_DMA_CONFIG, = REG_VALUE_DMA_WINDOW_CONFIG); > + bcm_pcib_set_reg(sc, REG_DMA_CONFIG, REG_VALUE_4GB_CONFIG); >=20 > bcm_pcib_set_reg(sc, REG_BRIDGE_GISB_WINDOW, 0); > bcm_pcib_set_reg(sc, REG_DMA_WINDOW_1, 0); > Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c (revision = 365932) > +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c (working copy) > @@ -189,15 +189,7 @@ > bcm_xhci_install_xhci_firmware(dev); >=20 > error =3D xhci_pci_attach(dev); > - if (error) > - return (error); > - > - /* 32 bit DMA is a limitation of the PCI-e controller, not the = VL805. */ > - sc->sc_bus.dma_bits =3D 32; > - if (bootverbose) > - device_printf(dev, "note: switched to 32-bit DMA.\n"); > - > - return (0); > + return (error); > } >=20 > /* >=20 > I've concluded from what I've seen in the code that lowaddr > should be based on the pcie properties and should not worry > about the maxsize and maxseg size figures being possibly > smaller: that is a dma engine use worry, not a pci one. (Not > that I could get that from the documentation that I quoted in > the review.) Thus I put back the 2 BUS_SPACE_MAXSIZE uses. >=20 > After the first huge-file duplicate-then-diff test sysctl > reported lots of bounced transfers: >=20 > # sysctl hw.busdma > hw.busdma.zone1.alignment: 4096 > hw.busdma.zone1.lowaddr: 0x3fffffff > hw.busdma.zone1.total_deferred: 0 > hw.busdma.zone1.total_bounced: 755770 > hw.busdma.zone1.active_bpages: 0 > hw.busdma.zone1.reserved_bpages: 0 > hw.busdma.zone1.free_bpages: 838 > hw.busdma.zone1.total_bpages: 838 > hw.busdma.zone0.alignment: 4096 > hw.busdma.zone0.lowaddr: 0xffffffff > hw.busdma.zone0.total_deferred: 0 > hw.busdma.zone0.total_bounced: 0 > hw.busdma.zone0.active_bpages: 256 > hw.busdma.zone0.reserved_bpages: 0 > hw.busdma.zone0.free_bpages: 257 > hw.busdma.zone0.total_bpages: 513 > hw.busdma.total_bpages: 1351 >=20 > For the non-power-of-2 boundary (0xc0000000-1), it > appears to use the next smaller power of 2 for the > boundary (0x40000000-1), without having to explicitly > code both types of values specially for the RPi4B. > (Of course, it also avoids using 2 GiBytes to > potentially avoid more bouncing.) >=20 > I'll note that, prior to the change, there > was after an example first test: >=20 > hw.busdma.zone2.total_bounced: 1091942 >=20 > and 174 in zone 1. So the bounce count has > decreased. >=20 > I'll note that "total_bounced" need not be the > a page count: it is incremented by 1 after > the loop for a bounce, not inside the loop. > Lots of pages of data were bounced. >=20 > For reference (the test as of a gpu_mem_1024=3D32 > context): >=20 > Physical memory chunk(s): > 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) > 0x00000007f0f000 - 0x00000034bfffff, 751767552 bytes (183537 pages) > 0x00000036052000 - 0x0000003cb2efff, 112054272 bytes (27357 pages) > 0x0000003cb36000 - 0x0000003cb36fff, 4096 bytes (1 pages) > 0x0000003cb38000 - 0x0000003cb39fff, 8192 bytes (2 pages) > 0x0000003cb3b000 - 0x0000003cb3cfff, 8192 bytes (2 pages) > 0x0000003cb40000 - 0x0000003cb40fff, 4096 bytes (1 pages) > 0x0000003cb42000 - 0x0000003cb43fff, 8192 bytes (2 pages) > 0x0000003cb45000 - 0x0000003df4ffff, 21016576 bytes (5131 pages) > 0x0000003df60000 - 0x0000003dffffff, 655360 bytes (160 pages) > 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) > 0x00000100000000 - 0x000001f372afff, 4084379648 bytes (997163 pages) >=20 >=20 > FYI, before the huge-file duplicate-and-diff test: >=20 > # sysctl hw.busdma > hw.busdma.zone1.alignment: 4096 > hw.busdma.zone1.lowaddr: 0x3fffffff > hw.busdma.zone1.total_deferred: 0 > hw.busdma.zone1.total_bounced: 866 > hw.busdma.zone1.active_bpages: 2 > hw.busdma.zone1.reserved_bpages: 0 > hw.busdma.zone1.free_bpages: 836 > hw.busdma.zone1.total_bpages: 838 > hw.busdma.zone0.alignment: 4096 > hw.busdma.zone0.lowaddr: 0xffffffff > hw.busdma.zone0.total_deferred: 0 > hw.busdma.zone0.total_bounced: 0 > hw.busdma.zone0.active_bpages: 256 > hw.busdma.zone0.reserved_bpages: 0 > hw.busdma.zone0.free_bpages: 257 > hw.busdma.zone0.total_bpages: 513 > hw.busdma.total_bpages: 1351 >=20 > After the duplicate but before the diff: >=20 > # sysctl hw.busdma > hw.busdma.zone1.alignment: 4096 > hw.busdma.zone1.lowaddr: 0x3fffffff > hw.busdma.zone1.total_deferred: 0 > hw.busdma.zone1.total_bounced: 513604 > hw.busdma.zone1.active_bpages: 8 > hw.busdma.zone1.reserved_bpages: 0 > hw.busdma.zone1.free_bpages: 830 > hw.busdma.zone1.total_bpages: 838 > hw.busdma.zone0.alignment: 4096 > hw.busdma.zone0.lowaddr: 0xffffffff > hw.busdma.zone0.total_deferred: 0 > hw.busdma.zone0.total_bounced: 0 > hw.busdma.zone0.active_bpages: 256 > hw.busdma.zone0.reserved_bpages: 0 > hw.busdma.zone0.free_bpages: 257 > hw.busdma.zone0.total_bpages: 513 > hw.busdma.total_bpages: 1351 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Oct 7 06:32:11 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 B0EBF3FD349 for ; Wed, 7 Oct 2020 06:32:11 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5kyg3K5Jz4Q2s for ; Wed, 7 Oct 2020 06:32:11 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 71BEE3FD610; Wed, 7 Oct 2020 06:32:11 +0000 (UTC) Delivered-To: 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 716513FCE7C for ; Wed, 7 Oct 2020 06:32:11 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5kyf1vVTz4Q7Y for ; Wed, 7 Oct 2020 06:32:10 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f53.google.com with SMTP id r127so955821lff.12 for ; Tue, 06 Oct 2020 23:32:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ukUuW6YqIdPRmpbh+a6xMhZRGx1j5Z2G1m/PwVNT0F4=; b=lXVG6uWDzo/HOcLEn0GB6a/Fw1qtsYYdqf2HCzxoY0mFl+IHAcwjU59ZitGSsf8ASU 9zhWHIqwIHqhsAARp3O0s6iY6V0EXyK3MVwYo4YdjTQLphVgenlFW8a2LZ0DDK8bzYaX ey/sQPbSkWwObLLNvTHoO7wlVgxcd9PqxIaF24RsFQbZGL7PsGlPXEnaVjHKG3RrnZ+e /nIaIvrd5iQ0+kCyPZf2QctLhkCNpeMM1MpIseCA3CPBvA0waibKoC1LL2ibpzN4CLIz 1Ayiuqj1/fTvkbZJWFSmjjNKjoMXmxK6qpDPGGByVY5+yKdElaUmGRBLqcfRHgnE2OHR qOzw== X-Gm-Message-State: AOAM531sOVfoYgUYIcvYhnu0Ran9QIaP7f04Jjk/n611hOENw7/w/4BT zV4EHPbN2Rfg+TmIroUTIOvLAE8aq/VIeA== X-Google-Smtp-Source: ABdhPJw19xI1/ljkCNR9BqFM/qcKh6xXp/VWu7rAN1eRgTqs7l1usuV7Soxddiumgqyqlzam0Guk4Q== X-Received: by 2002:a05:6512:214c:: with SMTP id s12mr484019lfr.578.1602052327893; Tue, 06 Oct 2020 23:32:07 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id l3sm186593lfc.34.2020.10.06.23.32.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 23:32:06 -0700 (PDT) Subject: Re: nanopi/allwinner i2c not working. To: Daniel Braniss Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: Date: Wed, 7 Oct 2020 09:32:05 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4C5kyf1vVTz4Q7Y X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-2.56 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.57)[-0.571]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.948]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.04)[-1.039]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.53:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.53:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[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: Wed, 07 Oct 2020 06:32:11 -0000 On 06/10/2020 23:29, Daniel Braniss wrote: > > >> On 6 Oct 2020, at 17:22, Andriy Gapon > > wrote: >> >> On 06/10/2020 17:00, Daniel Braniss wrote: >>> not too proud of it, but i’ll make it available. >>> it’s in https://www.cs.huji.ac.il/~danny/elockc.tar.bz >>> look in i2c.c >>> >>> in any case it works fine in 12.1. >> >> And it looks good to me as well. >> Could you please collect twsi debug output again? >> In head you do not need to recompile, you can just set hw.i2c.twsi_debug. > i did have to recompile Oh, I thought I committed that change, but now I see that I have not. It is a part of D26049. > iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 > iichb0: twsi_reset: Using clock param=59 > iichb0: TWSI_WRITE: Writing 0 to 18 > iichb0: TWSI_WRITE: Writing 59 to 14 > iichb0: TWSI_WRITE: Writing 40 to c > iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 > iichb0: twsi_reset: Using clock param=59 > iichb0: TWSI_WRITE: Writing 0 to 18 > iichb0: TWSI_WRITE: Writing 59 to 14 > iichb0: TWSI_WRITE: Writing 40 to c > iichb0: TWSI_WRITE: Writing c4 to c > iichb0: twsi_transfer: transmitting 2 messages > iichb0: TWSI_READ: read f8 from 10 > iichb0: twsi_transfer: status=f8 > iichb0: twsi_transfer: msg 0 is 9 bytes long > iichb0: twsi_transfer: msg 1 is 7 bytes long > iichb0: TWSI_WRITE: Writing e4 to c > iichb0: twsi_intr: Got interrupt Current msg=0 > iichb0: TWSI_READ: read 8 from 10 > iichb0: TWSI_READ: read cc from c > iichb0: twsi_intr: reg control=cc > iichb0: twsi_intr: Send the address (48)iichb0: TWSI_WRITE: Writing 48 to 8 Does that address (0x24 / 0x48 in 7-/8-bit representations) look correct? > iichb0: TWSI_WRITE: Writing c4 to c > iichb0: twsi_intr: Refresh reg_control > iichb0: TWSI_WRITE: Writing cc to c > iichb0: twsi_intr: Done with interrupts > > iichb0: twsi_intr: Got interrupt Current msg=0 > iichb0: TWSI_READ: read 20 from 10 > iichb0: TWSI_READ: read cc from c > iichb0: twsi_intr: reg control=cc > iichb0: twsi_intr: No ack received after transmitting the address The controller says that the device did not acknowledge its address. In other words, no device responded to the slave address. > iichb0: twsi_intr: Refresh reg_control > iichb0: twsi_transfer: pause finish > iichb0: TWSI_WRITE: Writing 8 to c > iichb0: twsi_transfer: Error, aborting (2) > iichb0: twsi_intr: Done with interrupts > > iichb0: TWSI_WRITE: Writing 0 to c > iichb0: TWSI_READ: read 30 from 10 > iichb0: twsi_transfer: status=30 > iichb0: TWSI_WRITE: Writing 0 to c > iichb0: TWSI_READ: read 30 from 10 > iichb0: twsi_transfer: status=30 > iichb0: TWSI_WRITE: Writing c4 to c > iichb0: twsi_transfer: transmitting 2 messages > iichb0: twsi_intr: Got interrupt Current msg=0 > iichb0: TWSI_READ: read 30 from 10 > iichb0: TWSI_READ: read 30 from 10 > iichb0: twsi_transfer: status=30 > iichb0: TWSI_READ: read cc from c > iichb0: twsi_transfer: msg 0 is 9 bytes long > iichb0: twsi_intr: reg control=cc > iichb0: twsi_transfer: msg 1 is 7 bytes long > > iichb0: twsi_intr: status=30 hot handled > iichb0: TWSI_WRITE: Writing e4 to c > iichb0: twsi_intr: Refresh reg_control > iichb0: twsi_transfer: pause finish > iichb0: TWSI_WRITE: Writing 8 to c > iichb0: twsi_transfer: Error, aborting (1) > iichb0: twsi_intr: Done with interrupts > > iichb0: TWSI_WRITE: Writing 0 to c > iichb0: TWSI_READ: read 10 from 10 > iichb0: twsi_transfer: status=10 > iichb0: TWSI_WRITE: Writing 0 to c > iichb0: TWSI_READ: read 10 from 10 > iichb0: twsi_transfer: status=10 The rest reads like gibberish because the driver did not stop the controller after the NACK (also, possibly some log messages were omitted from your email). I'd recommend once again to give https://reviews.freebsd.org/D26049 a try. I've just rebased it on the latest head, so it should apply cleanly. But as I said earlier, from the debug log it seems that the problem is either with the slave address or with the hardware (wiring, etc). It's also possible that that was a transient condition. -- Andriy Gapon From owner-freebsd-arm@freebsd.org Wed Oct 7 06:57:24 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 28A993FDBC6 for ; Wed, 7 Oct 2020 06:57:24 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5lWl1zprz4R7w for ; Wed, 7 Oct 2020 06:57:22 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: by mail-qt1-x844.google.com with SMTP id g3so778077qtq.10 for ; Tue, 06 Oct 2020 23:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sv9HN4vKWGD1ZfyRjsoBbbaBQL2xBTWbIjqYngT3SJw=; b=Lawj1Koggb8N9aSl0+yz/2QLJxMBiYj38cEzDYZV6OH9SRzn3h7cB1msAycELzxz0E o762HjL3nQVgggiq2/7v07KBnjDR8661zIF/CIP+idNZxH7hLOHn4KyTs4xtC3y/Vfbe XI2JQ0JWGNNUTVHd0tTRBja9uug/ZNcIoGww4SmtPmeEs41CQCWhlULK2dYnLqoJyynN FxBsRNHqrXuTMZZ8pk+P8jmn0ReB3sUiTAlr9evaSZ0owBfY3iSMMwpqIhui7OeAhNgi sw2IuSg+C1/Ic2r8exY45ZqpKhe8tlTxskVTQV01Xz1LJm4rLVIifMsuDt2KDR2khIKo ENNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sv9HN4vKWGD1ZfyRjsoBbbaBQL2xBTWbIjqYngT3SJw=; b=YaHbeChkEEMEvbq2ictAyttt57SNCYlWEOpe2g57Png26DR60opbBjz7BrGW9vvna2 1B4dnIcTe2ygPtr8bXjicrzU3f3IuFKdyCRmsKspsagCWXAwi8QiING28lne4bFbZzWb fFwtrzYsILVXv29eQGXBk4IblhCvOAgnImBPM9fTMvgTNU3H9ay5laR2nB9ah7hAcvVO b1Ot2cenPC+1Q/SfwG7rUJ2ybRRFfhReaPg1RmXA368Hskk74FtbMgTJHUT5179a84pA AA8JZMm92vsbyXkrktLgP6a9olQNRGnwBEc4jdp2fsAVIAaiNMVVMroLhqdjp7k/Qukg sBNg== X-Gm-Message-State: AOAM530zZmslGOnB+bKI10E+55G5jU+AMlWJWMOiaPNR07ED2SrlG25N XjpL43GU4o/ygNWrChBJwEpUT/f4Rd9sTsY= X-Google-Smtp-Source: ABdhPJw1TFfHj1/aFdgQZPBS9YyGHh68dHmeMD5Hj83mSz/F4SKDPFsAxgmpjpacftrWARuP1ZTjgg== X-Received: by 2002:ac8:1910:: with SMTP id t16mr1693352qtj.351.1602053842168; Tue, 06 Oct 2020 23:57:22 -0700 (PDT) Received: from [192.168.1.3] ([122.179.31.199]) by smtp.gmail.com with ESMTPSA id h199sm755079qke.112.2020.10.06.23.57.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 23:57:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: generic q on freebsd From: Kamal Prasad In-Reply-To: Date: Wed, 7 Oct 2020 12:40:19 +0530 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3273) X-Rspamd-Queue-Id: 4C5lWl1zprz4R7w X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Lawj1Kog; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kamalpr@gmail.com designates 2607:f8b0:4864:20::844 as permitted sender) smtp.mailfrom=kamalpr@gmail.com X-Spamd-Result: default: False [-3.57 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.001]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.030]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[122.179.31.199:received]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.037]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::844:from]; RCVD_TLS_ALL(0.00)[]; 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: Wed, 07 Oct 2020 06:57:24 -0000 Thanks. Why is it difficult to port the C++ runtime to the kernel? I = mean what is the technological hurdle? thanks -kamal On Oct 6, 2020, at 10:53 PM, Warner Losh wrote: >=20 > On Tue, Oct 6, 2020, 11:03 AM Kamal R. Prasad = wrote: >=20 >> hello, >>=20 >> i am curious if it is possible to compile c++ code inside the freebsd >> kernel. >>=20 >=20 >=20 > Possible? Yes, with restrictions. Easy? No. >=20 > There are a number of restrictions on doing this. There is no C++ = runtime > support provided in stock FreeBSD. You have to write your own, or find > someone else that has published theirs. And the code is likely to be > compiler dependent. People have done it and talked or blogged about = it. >=20 > Generally, if you don't use exceptions, templates, RTTI, expressions = that > result in the automatic allocation of objects, have large objects (> = 1k) on > the stack, etc, it may be possible. I tried it in the 90s and had to = write > just a few routines to make simple classes work, but there's a lot of > dragons here and very little C++ code is written these days w/o = reference > to the standard libraries, which aren't present in the kernel. >=20 > Some googling turns up: > https://github.com/adamlsd/libcpp.ko from 6 years ago > https://lists.freebsd.org/pipermail/freebsd-arch/2018-June/019069.html = has > some details from 2 years ago about command line args you might need. >=20 > Many have tried. Few have succeeded. Those that have write all their = code > to conform to a subset of the language. Few have had success moving = C++ > code for other purposes into the kernel, though if it was written = using the > proposed (but never ratified) eC++ (embedded subset), then chances are > greater. >=20 > Good luck >=20 > Warner > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Oct 7 07:08:03 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 A30CF3FDF54 for ; Wed, 7 Oct 2020 07:08:03 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5lm26tmPz4RFC for ; Wed, 7 Oct 2020 07:08:02 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: by mail-qv1-xf44.google.com with SMTP id cv1so538185qvb.2 for ; Wed, 07 Oct 2020 00:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MDGs1K6Erpnp1w59MCc0rSG38mjf7qBZn7IvVkUGAqY=; b=iHcVICaIr+CiI7ututlgYhfmOBGyu6T1zPmV9xY0ef72oBYeM17M1fV+A8t6u5wSFo sAZ6sX61ViJipGSsOR2hLX92xMSu5Q7luRUtZKfHYXT2qSBfqJLu5ykfVXgpYIuLNk3n WXH+aUjVQQ/JdQXRtCPlQC2uDMhjA0VfcyGBN/QBIPllNlpvoBfZ296Yue2beAJ8Wa2E N2yhBxeG8oRsT9LL6hsIDgPZgXxXGgPiueOLSbv9fnmcGL8ZPu0YCX1cSofpgTW+nf9j UOt9RCFaZNk2GJwj1l9mS3xiJNslczEq1ZLqOsK2c2up+XXdajYGAtBjGDx6vMPUhC61 4rnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MDGs1K6Erpnp1w59MCc0rSG38mjf7qBZn7IvVkUGAqY=; b=bYLB+uC1Xz8ijPfogRRYqpJr1qa+4TVnwaMuBztSlKbxVsQMRLy2zcbZCxpDaQZ6QI N7qhxmrg/nBBadS9QX81oVNh/62wgHuqf0gNnTjbP6vdtuZhbTwWdDbL7iuEtXzDJrOo O+NmTUF7fz/iiHu5xux0EyWzdebIyao4Dnl/Ehno+WVhnwppatHq/D7kKTyYjB6GjlaJ /YcgSy/lZtpmVDZvsw6u4dFYoXm/xn8dJ+Y88UUBy+VwzGA6rAH5Ho1Lh7OUFKDBCNa/ KtQv8ukFOmiSmhrlMfJSWvTcO3Cfm/vqSZD70+puv858ynOpUmFDgD9/SMBViJWg2L2l WzLQ== X-Gm-Message-State: AOAM533kFeKqOm6lDIR695BQ8ufb4/P0grjWSFvn9/tIdoOcZTjGsXIx rNeKOgAl8N7p+YzsBknCZL/jFUDp/Eauv58= X-Google-Smtp-Source: ABdhPJwqlzTzCbF3ToEPlTYYTg69o9tkj6klopFg1mQR8nFnxGUdiaZCvCyyUz4W7cAa04PuEmrImw== X-Received: by 2002:a05:6214:146e:: with SMTP id c14mr1867997qvy.22.1602054482000; Wed, 07 Oct 2020 00:08:02 -0700 (PDT) Received: from [192.168.1.3] ([122.179.31.199]) by smtp.gmail.com with ESMTPSA id l19sm759169qkk.99.2020.10.07.00.07.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2020 00:08:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: generic q on freebsd From: Kamal Prasad In-Reply-To: Date: Wed, 7 Oct 2020 12:50:59 +0530 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3273) X-Rspamd-Queue-Id: 4C5lm26tmPz4RFC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=iHcVICaI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kamalpr@gmail.com designates 2607:f8b0:4864:20::f44 as permitted sender) smtp.mailfrom=kamalpr@gmail.com X-Spamd-Result: default: False [-3.57 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.030]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[122.179.31.199:received]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.037]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f44:from]; RCVD_TLS_ALL(0.00)[]; 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: Wed, 07 Oct 2020 07:08:03 -0000 Android has a libc++. I think that can be ported into the kernel. https://developer.android.com/ndk/guides/cpp-support=20 thanks -kamal > On Oct 7, 2020, at 12:40 PM, Kamal Prasad wrote: >=20 > Thanks. Why is it difficult to port the C++ runtime to the kernel? I = mean what is the technological hurdle? >=20 > thanks > -kamal >=20 >=20 >=20 >=20 >=20 >=20 > On Oct 6, 2020, at 10:53 PM, Warner Losh wrote: >>=20 >> On Tue, Oct 6, 2020, 11:03 AM Kamal R. Prasad = wrote: >>=20 >>> hello, >>>=20 >>> i am curious if it is possible to compile c++ code inside the = freebsd >>> kernel. >>>=20 >>=20 >>=20 >> Possible? Yes, with restrictions. Easy? No. >>=20 >> There are a number of restrictions on doing this. There is no C++ = runtime >> support provided in stock FreeBSD. You have to write your own, or = find >> someone else that has published theirs. And the code is likely to be >> compiler dependent. People have done it and talked or blogged about = it. >>=20 >> Generally, if you don't use exceptions, templates, RTTI, expressions = that >> result in the automatic allocation of objects, have large objects (> = 1k) on >> the stack, etc, it may be possible. I tried it in the 90s and had to = write >> just a few routines to make simple classes work, but there's a lot of >> dragons here and very little C++ code is written these days w/o = reference >> to the standard libraries, which aren't present in the kernel. >>=20 >> Some googling turns up: >> https://github.com/adamlsd/libcpp.ko from 6 years ago >> = https://lists.freebsd.org/pipermail/freebsd-arch/2018-June/019069.html = has >> some details from 2 years ago about command line args you might need. >>=20 >> Many have tried. Few have succeeded. Those that have write all their = code >> to conform to a subset of the language. Few have had success moving = C++ >> code for other purposes into the kernel, though if it was written = using the >> proposed (but never ratified) eC++ (embedded subset), then chances = are >> greater. >>=20 >> Good luck >>=20 >> Warner >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@freebsd.org Wed Oct 7 07:21:51 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 ED35E3FE04D for ; Wed, 7 Oct 2020 07:21:51 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5m3z4bDWz4RmV for ; Wed, 7 Oct 2020 07:21:51 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 9BC293FE339; Wed, 7 Oct 2020 07:21:51 +0000 (UTC) Delivered-To: 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 9A6DD3FE338 for ; Wed, 7 Oct 2020 07:21:51 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5m3z164nz4S6G; Wed, 7 Oct 2020 07:21:50 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=s56IJmsBxvrhFHkb01EwviG7bAf1Hx4vkUJkCXnXJss=; b=KzgKEsU4y6i1jM2uOi/hZa2xKTQgqoTsZ2KT2jpnDWC4udjv7db+qojOooRJ7apZQWP1pnTx+eJ2zktYhxnnhCi814DgCWCYJf+kWYVamCEfa9DG6nWMj7sJi/JrU0J05s/vUa48VMF1kHmdXrqtl8AdfkNzAYLZX1z6xjnTEQr7CYFTmuNEM8H2asfYsi8Ebb/o3O6ZKlLq0JnCir0wLFedmxap78TIQoxyedId1bt207R1wZYzLw0q9IrRq4wP3YFekhBRnB+stf4PAo6etjL7Tv9Y4T8akdtjAQ3wd01V2XE/2m0Oi7b48O4Nk+sfnjz50pZHE/OuCDw8JM3+Vg==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1kQ3li-000M9p-Qs; Wed, 07 Oct 2020 10:21:46 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: nanopi/allwinner i2c not working. From: Daniel Braniss In-Reply-To: Date: Wed, 7 Oct 2020 10:21:46 +0300 Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il> References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> To: Andriy Gapon X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4C5m3z164nz4S6G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; REPLY(-4.00)[] 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: Wed, 07 Oct 2020 07:21:52 -0000 > On 7 Oct 2020, at 09:32, Andriy Gapon wrote: >=20 > On 06/10/2020 23:29, Daniel Braniss wrote: >>=20 >>=20 >>> On 6 Oct 2020, at 17:22, Andriy Gapon >> > wrote: >>>=20 >>> On 06/10/2020 17:00, Daniel Braniss wrote: >>>> not too proud of it, but i=E2=80=99ll make it available. >>>> it=E2=80=99s in https://www.cs.huji.ac.il/~danny/elockc.tar.bz >>>> look in i2c.c >>>>=20 >>>> in any case it works fine in 12.1. >>>=20 >>> And it looks good to me as well. >>> Could you please collect twsi debug output again? >>> In head you do not need to recompile, you can just set = hw.i2c.twsi_debug. >> i did have to recompile >=20 > Oh, I thought I committed that change, but now I see that I have not. > It is a part of D26049. >=20 >> iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 >> iichb0: twsi_reset: Using clock param=3D59 >> iichb0: TWSI_WRITE: Writing 0 to 18 >> iichb0: TWSI_WRITE: Writing 59 to 14 >> iichb0: TWSI_WRITE: Writing 40 to c >> iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 >> iichb0: twsi_reset: Using clock param=3D59 >> iichb0: TWSI_WRITE: Writing 0 to 18 >> iichb0: TWSI_WRITE: Writing 59 to 14 >> iichb0: TWSI_WRITE: Writing 40 to c >> iichb0: TWSI_WRITE: Writing c4 to c >> iichb0: twsi_transfer: transmitting 2 messages >> iichb0: TWSI_READ: read f8 from 10 >> iichb0: twsi_transfer: status=3Df8 >> iichb0: twsi_transfer: msg 0 is 9 bytes long >> iichb0: twsi_transfer: msg 1 is 7 bytes long >> iichb0: TWSI_WRITE: Writing e4 to c >> iichb0: twsi_intr: Got interrupt Current msg=3D0 >> iichb0: TWSI_READ: read 8 from 10 >> iichb0: TWSI_READ: read cc from c >> iichb0: twsi_intr: reg control=3Dcc >> iichb0: twsi_intr: Send the address (48)iichb0: TWSI_WRITE: Writing = 48 to 8 >=20 > Does that address (0x24 / 0x48 in 7-/8-bit representations) look = correct? 100% correct >=20 >> iichb0: TWSI_WRITE: Writing c4 to c >> iichb0: twsi_intr: Refresh reg_control >> iichb0: TWSI_WRITE: Writing cc to c >> iichb0: twsi_intr: Done with interrupts >>=20 >> iichb0: twsi_intr: Got interrupt Current msg=3D0 >> iichb0: TWSI_READ: read 20 from 10 >> iichb0: TWSI_READ: read cc from c >> iichb0: twsi_intr: reg control=3Dcc >> iichb0: twsi_intr: No ack received after transmitting the address >=20 > The controller says that the device did not acknowledge its address. > In other words, no device responded to the slave address. but i2c -s=20 >=20 >> iichb0: twsi_intr: Refresh reg_control >> iichb0: twsi_transfer: pause finish >> iichb0: TWSI_WRITE: Writing 8 to c >> iichb0: twsi_transfer: Error, aborting (2) >> iichb0: twsi_intr: Done with interrupts >>=20 >> iichb0: TWSI_WRITE: Writing 0 to c >> iichb0: TWSI_READ: read 30 from 10 >> iichb0: twsi_transfer: status=3D30 >> iichb0: TWSI_WRITE: Writing 0 to c >> iichb0: TWSI_READ: read 30 from 10 >> iichb0: twsi_transfer: status=3D30 >> iichb0: TWSI_WRITE: Writing c4 to c >> iichb0: twsi_transfer: transmitting 2 messages >> iichb0: twsi_intr: Got interrupt Current msg=3D0 >> iichb0: TWSI_READ: read 30 from 10 >> iichb0: TWSI_READ: read 30 from 10 >> iichb0: twsi_transfer: status=3D30 >> iichb0: TWSI_READ: read cc from c >> iichb0: twsi_transfer: msg 0 is 9 bytes long >> iichb0: twsi_intr: reg control=3Dcc >> iichb0: twsi_transfer: msg 1 is 7 bytes long >>=20 >> iichb0: twsi_intr: status=3D30 hot handled >> iichb0: TWSI_WRITE: Writing e4 to c >> iichb0: twsi_intr: Refresh reg_control >> iichb0: twsi_transfer: pause finish >> iichb0: TWSI_WRITE: Writing 8 to c >> iichb0: twsi_transfer: Error, aborting (1) >> iichb0: twsi_intr: Done with interrupts >>=20 >> iichb0: TWSI_WRITE: Writing 0 to c >> iichb0: TWSI_READ: read 10 from 10 >> iichb0: twsi_transfer: status=3D10 >> iichb0: TWSI_WRITE: Writing 0 to c >> iichb0: TWSI_READ: read 10 from 10 >> iichb0: twsi_transfer: status=3D10 >=20 > The rest reads like gibberish because the driver did not stop the = controller > after the NACK (also, possibly some log messages were omitted from = your email). >=20 > I'd recommend once again to give https://reviews.freebsd.org/D26049 a = try. > I've just rebased it on the latest head, so it should apply cleanly. i just downloaded it and will try - the sysctl for hw. is there. (i did a git to get the latest current, i=E2=80=99ll try doing an svn = update later -its bloody slow) >=20 > But as I said earlier, from the debug log it seems that the problem is = either > with the slave address or with the hardware (wiring, etc). the hardware is fine, running 12.1 on it works ok. and also i2c -s finds it. > It's also possible that that was a transient condition. not really, it seems to me some timming issue. after a power cycle, and with debug on, all is working. turning off debug only i2c -s works. in any case will try the D26049 now. >=20 > --=20 > Andriy Gapon From owner-freebsd-arm@freebsd.org Wed Oct 7 07:26:14 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 7E8593FE61B for ; Wed, 7 Oct 2020 07:26:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30]) (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 4C5m914wdDz4SK9 for ; Wed, 7 Oct 2020 07:26:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 84qnzRcVM1kkYVlcNYHhG5xgIdcCeOyyPtyxtrw5nsd_KbA.HU9IKEtr2TiUKs5 7TpGdxZbu5CITE4OoGjjo9XaDRqGe1_kjX0ZHsKGTBR6hA1vzZKmXJ55nTxrtOGNBaG2pkFGA38c Ti7XvmVdmRGnv8jl35Xdzge1CFG7z8uwS5WLdPMkUZixpVnh_6fLTdQ_mY8iUg60Am631oaMKQG. wesjN58sLV4jys.V9Ui4E.YZq9d_39j3PigtfVToe_aQoDwSZgIyL6lE.LU6LIIOzurs4Y87HSxi 9QR714UgH.7LWkKV9E_VVsbCGh8kI94nfgION4kTCyKwWPjw18igFuYGwtu0WNQBH49apKUx6BeQ 3DpUx3Xj_9Auim6NdVoddnoajqE14bgzI9MytZGEmASIRz5slMoCPQDneFSag4pSJxWYKMZYrMGN xf1YdyZyuinlyIBdm2wtGPRlsmouhGUQ7Z7el5ZBfhmeA06_Shtn2aDugA0mLwT4DaCgry3R2LwN kGsiWLFnmaTL5n97Kqk9xbDOp8OgFdpb2BW7G6dFAsRX31NFGaU_r_UaSYearOQNOcRR9Qluv3TD UeB.5ZMwwUnEBcyawE41mXgDJoatmn03q.eBgle6dYuB_13EVt.X9ir62wdBuHh2Z3A9XsWVHwpS ILvnCXgUsbqCpGCSlljm4E3ebpmBAmJgZqDkCc0RD2kHxh7cFD5.debX4RmsXWRlRA_ygYbNTM.w 9VedG3Eg3JwpnUuI6fkt1unykcx4LPlc7SQLdmRfGjX_cKQObinOtEeA0YKq1t_a1MIe1UOnETYj mwvC_1CGHyJGZUfk4ERviMmeCIwvemORKaJVh.4gQJ18HoUuYQuVlnEa6CIMEdkEKbDDUoHdoAod AEtf9BJ9sRzOImQOYNBsU7oTRB96ASTEX9tQYClQ4Tjk24GvWSN3oLY0qFc_TS1LKbAKC1sa4tFe w8QjWDAdkvDu1ZH58tbRPNd3ZsOWpA5uSVsqGO6vc0MBdcqsKQV_.T_VNho2jeVh_jM3V5olCOYO Kh6NexXIYPmxsQLK8QqipQ0RA9otSEmoyYJ3JV1zwDpbF58qjDsI3vnmKXXB5qNBzH.nFuSTpCsx PAFFvgSIrmDVTa9701uToPpEU4xnPGM2I2LPxtVWgNM4MmMUtcUP0UoDvFrXNi5ytAxKzpkl9iH7 gpTNKT7l8SRb7GkZqvEDOP6yinmYNVjgbFDV.p1CD7QG0b9afpTFUPUPh3MY1VYP99r9z62..dkD 0LOwWMUH7lCEPLoZdsY0fMf2OUAzbd4rviEYiTzrGsoXWfxOV3.ZxYzx1bGx5WtsPco_PFtDChEK 4zBUGuNG8_6vhZPS2KvgzMz0mmsgbFvQKsxNIGNs_0DUBIYHh2NuMWntfz918Xq6_Fv.Jo49WYsi WZ740VP06zGk5HnYK9R_Dh4fydx6UzAdrcZmtX_OYYADq056hJoOy0PdBBv3MzoVH1nAljDb7OgG acKI1zux0FyHPCq6R3cZH2U5OIrtfTcMKGzzO3YSFxJFUKdPyqv9J34wQVMu2i7gFucFlSJcxBqy hoKtvZI_xaFWIV9J2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Oct 2020 07:26:11 +0000 Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cc193a47c79c6a67763d9a8974302217; Wed, 07 Oct 2020 07:26:07 +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: Adding a "-1" into https://reviews.freebsd.org/D25219 's code looks to make uefi/ACPI handle USB3 SSD reliably Message-Id: <5F1CF0D1-9FA2-48B9-984B-6A2B98CB87E9@yahoo.com> Date: Wed, 7 Oct 2020 00:26:05 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3608.120.23.2.1) References: <5F1CF0D1-9FA2-48B9-984B-6A2B98CB87E9.ref@yahoo.com> X-Rspamd-Queue-Id: 4C5m914wdDz4SK9 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.19 / 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.67)[-0.668]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.01)[-1.012]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; URL_IN_SUBJECT(1.00)[reviews.freebsd.org]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.010]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.30:from]; 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: Wed, 07 Oct 2020 07:26:14 -0000 https://reviews.freebsd.org/D25219 has (in part) > + if (bus_dma_tag_create(NULL, 1, 0, > + limits.lowaddr, BUS_SPACE_MAXADDR, NULL, NULL, Based on sysctl hw.busdma output and testing a change for the = u-boot/DTB/fdt code context that worked in testing so far, I've tried = using limits.lowaddr-1 in the above ACPI handling code instead. It has worked so far. So both existing implementations have the same basic problem as far as I can tell: limits.lowaddr too large by one, so identifying the wrong page. What sysctl showed me was the likes of (before changes that lead to lack of zone2 for u-boot/dtb/fdt): . . . hw.busdma.zone2.lowaddr: 0x3c000fff . . . hw.busdma.zone1.lowaddr: 0x3fffffff . . . hw.busdma.zone0.lowaddr: 0xffffffff . . . So I've guessed that lowaddr should identify the end page of the possibly-use-it-directly region, not the first do-not-use-it-directly page. If I've guessed wrong, at most it would bounce one page that it could avoid bouncing. But, if I guessed correct, it might bounce a page that it should instead of not doing so. Thus the "-1" addition. For reference, after the first duplicate-and-diff test for uefi/ACPI: # sysctl hw.busdma hw.busdma.zone0.alignment: 4096 hw.busdma.zone0.lowaddr: 0xbfffffff hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.total_bounced: 762568 hw.busdma.zone0.active_bpages: 12 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.free_bpages: 824 hw.busdma.zone0.total_bpages: 836 hw.busdma.total_bpages: 836 I'll note that "total_bounced" need not be the a page count: it is incremented by 1 after the loop for a bounce, not inside the loop. Lots of pages of data were bounced. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Oct 7 07:48:44 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 B38033FF3A7 for ; Wed, 7 Oct 2020 07:48:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4C5mfz5BC0z4V3S for ; Wed, 7 Oct 2020 07:48:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: swQIhNkVM1mKxEaZhBr8T8MG8IEJHLW8D4JtYZ2tizT1OpHsB1bC3Sb6esT8qSm 5Mys7xdoGeTVmiNmzYDVjwWVyIFXt3j3mVVEJ_JfOsQGUoOPWu710pSgQB.ab_ajZAncYPQHgsY. PP7mRLgRAXGqCipguNyl19xMf9W0UVPZ5rKB5cXZV1ZKlcj__Us4__5UeGw3B2xAMuRB0eboJl4G XATD52Z4yW9kmPxaTGxURD6Z_c6qHGkWpoQrn6_xkKSC6Gwb67AJ_4DY3jgsJUNfNUsVArjx9tL8 gjDn.D.xJo7SZHLQCT.zoKK2wvsyROdyxoPIlPef8PSWvUWqBOg_mGeOoJrJm_MlNc8vRNza3ZsM JVvTRSQ9d..TcUzupbgC130hyYdq04HuarkqLxlQgRX9vg8xSFpQjuJUj7Uww1QJkGNt7qsD3oWZ 1Rhz3AyQFoZtb3Rk9qqfFZuVUw89h5seSqR8XDoPIMGLIoDwlZiDk4.2APGaCWqs_KwpAFzwwhMy 4uKbVM20ttOyxWT2ND6z_mH0FYPXnb93fcESMNlQGqwqpiaomkWR2YQo5vUNvgXn48mZthiXL7eI e_o.S2VlLI_0cO.zPJoLpe.T2Tsoe21ZRm5SC6C.N2p9.45zib_He9ras4noRVDi2Vvzo8i.2uYz deVm9URlju3aF3WIr6juBsIAWdlZi2qRdslB80RJdkbHBTzQwKWRbNmOqne1vCnWx6U_fWRtWH22 rggcFxVi5fAt8zesxZD6bWPVFZ7kyeVAht7LkZT3hZZ5hpA.QqslcIu53tsY0utx96U04hBCyol3 .CsXcy0UjVTfbW3wDGIh6fEHPutWdJFpZDxw92iCehnF2D13_VU3OHrt8xjALDtQW1BDA9ZI.Z4E uy5gK7XvQDR69l7yfZa1Nz4zFSCAATCIN405CuPtx.UYLbN2WewLewSLxD3mbbxKaa5_DXQzyu4p 3D189w5jf_9IfRELJIMjsVxTW5Rurzqc64R8cbDhKv4NjxMQSEETWnUumU7ZzGxe3kUcPR68DdxM szH2mBi3Pw21xgo0i4Ir1xgWlyLVftdb3YDesEItYHYr7qw7f3QiFocBieBRE9v5McPgxV9KmuW7 AqxsQ8ZHGoeE7NXPFZUgi5d3j0JeXjxGVLOWSsSpR1ylnHMEzrxQpTiW4TM9lHK7Qe4psaSUJaF7 EYYun74noYbDB9lBslKe.Lk2YD3ZRcMSU.P8algL8_SqvZRlir7pduj9BEvJwXOarEf5uMKTwrYf 499KX90g5kFYn_esbl4UoUKeOSgGMa7MhWOLr2fi7ZSprl0y073frBHAx7kLjtHIJV0gT0UoHit7 C4Yj_XY.014PF_RoDy1_hjWuezVSpaqbXGdkxhWIK51kVgy0Ayt4echmH97SbSHsymj6E47oCTSE GXNUZoUewuQTUEmBjRdQhkSnkjphVx8a0U2ZUPWI7SmokSVlf2mP0YTBauO6Co.E8itVoW4mhxNy wKg.DEKMIeyerVavmM2OAm6RD4DWPKoGtWmQJTq3QVFKoUPxJDC3afNRL7neDOrACysoBvAat_j6 LFT0kxiKfigS7o79YHuFriuDW11K5q3uz.g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Oct 2020 07:48:42 +0000 Received: by smtp410.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7725db3d258e50cec608a5baeff70f2a; Wed, 07 Oct 2020 07:48:39 +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: generic q on freebsd From: Mark Millard In-Reply-To: Date: Wed, 7 Oct 2020 00:48:37 -0700 Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kamal Prasad X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C5mfz5BC0z4V3S X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.63 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.09)[-1.094]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.015]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.02)[-1.017]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; 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: Wed, 07 Oct 2020 07:48:44 -0000 On 2020-Oct-7, at 00:20, Kamal Prasad wrote: > Android has a libc++. I think that can be ported into the kernel. > https://developer.android.com/ndk/guides/cpp-support=20 So far as I know, Android has libc++ but not in its kernel. FreeBSD has libc++, but not in its kernel. In both contexts, libc++ is from LLVM. In both contexts, userspace programs do not need libc++ to be in the kernel. In both contexts, the C++ involved is a "hosted implementation" instead of being limited to a "Freestanding implemenation". See https://en.cppreference.com/w/cpp/freestanding about freestanding vs. hosted. In part: QUOTE In a freestanding implementation execution may happen without an = operating system END QUOTE > thanks > -kamal >=20 >> On Oct 7, 2020, at 12:40 PM, Kamal Prasad wrote: >>=20 >> Thanks. Why is it difficult to port the C++ runtime to the kernel? I = mean what is the technological hurdle? >>=20 >> thanks >> -kamal >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Oct 6, 2020, at 10:53 PM, Warner Losh wrote: >>>=20 >>> On Tue, Oct 6, 2020, 11:03 AM Kamal R. Prasad = wrote: >>>=20 >>>> hello, >>>>=20 >>>> i am curious if it is possible to compile c++ code inside the = freebsd >>>> kernel. >>>>=20 >>>=20 >>>=20 >>> Possible? Yes, with restrictions. Easy? No. >>>=20 >>> There are a number of restrictions on doing this. There is no C++ = runtime >>> support provided in stock FreeBSD. You have to write your own, or = find >>> someone else that has published theirs. And the code is likely to be >>> compiler dependent. People have done it and talked or blogged about = it. >>>=20 >>> Generally, if you don't use exceptions, templates, RTTI, expressions = that >>> result in the automatic allocation of objects, have large objects (> = 1k) on >>> the stack, etc, it may be possible. I tried it in the 90s and had to = write >>> just a few routines to make simple classes work, but there's a lot = of >>> dragons here and very little C++ code is written these days w/o = reference >>> to the standard libraries, which aren't present in the kernel. >>>=20 >>> Some googling turns up: >>> https://github.com/adamlsd/libcpp.ko from 6 years ago >>> = https://lists.freebsd.org/pipermail/freebsd-arch/2018-June/019069.html = has >>> some details from 2 years ago about command line args you might = need. >>>=20 >>> Many have tried. Few have succeeded. Those that have write all their = code >>> to conform to a subset of the language. Few have had success moving = C++ >>> code for other purposes into the kernel, though if it was written = using the >>> proposed (but never ratified) eC++ (embedded subset), then chances = are >>> greater. >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Oct 7 07:52:00 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 9CB2F3FF275 for ; Wed, 7 Oct 2020 07:52:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf42.google.com (mail-qv1-xf42.google.com [IPv6:2607:f8b0:4864:20::f42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5mkl5hykz4VHB for ; Wed, 7 Oct 2020 07:51:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf42.google.com with SMTP id bl9so594133qvb.10 for ; Wed, 07 Oct 2020 00:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uGg7TQpL6/G6vPzkyt6ayGgqneyW8oAPMoIaFwHyeOk=; b=X4/YM01R7Gtiw/N39Rt/wkJegZG8XHE/kwk922n3hOblrRSFkPM20jteAFliObpKN9 R6YSvGbiLanXVVvUhqUzWUocTJZDoGDU/RbOFZaqOUaqCE/KE0mif4NeW3SyogISQO4I OS0CX2C2W5kGbjwAC0/Eh/QupE2QD04DcGLrAOrl3IoFF+4O96jmfYELkj19RgZ7Hwlw cDRMuKln1tKLyMO2iVYTkZ5CenYn0UdV2GuoJl24kY5m2R2uidtrSTxoIammRUNx1NuM PQW+DZEOi9Xp7pM20ORf5RFCTK2ADVNwQV9FHnGiGIl+D/4HBS8Rn0XOKTRrfXOVtool g89g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uGg7TQpL6/G6vPzkyt6ayGgqneyW8oAPMoIaFwHyeOk=; b=R1Zkc92aGmfOyJDmPB6RGcCehBAs+Wm1xg8wSoqZgo/YUIMcD6ZQwwa3F3sxKg5q6m WJLxw4rKAmqUhaLmEgsggYa/s9cofaKdZH6w0g1yh14lzUkQWBbzV0Iw5S2j0M3lcZFI er6TexLw3G8IG5Ust/Db9XPnFZhAyLXv4X/aacNqjwC3shvy+/VvhQN1S03fBWN1KKRU ofRzWAJVwKHlDnU5oZsnlsYowf+isIsrGOxzM++r6P44VFNcDFzbLsaJ5ai8C+IsgvYa uP2n0nx/sVwv9BdQFRWRLE3Vc9O7vUaTACevpX8vsiKmc9oF61IsBdEk0ZOSlUiWztNU gyCQ== X-Gm-Message-State: AOAM530ciSi7VeYCnvdCuXAwzFgXyzCOtdIqAKjWlMfDRnefYKksnzoi kb62Xe4PDqqMkxPkSdVRwGin/zeTisxL6+iJIQmcyw== X-Google-Smtp-Source: ABdhPJzjW36C6sx9Dl3ceJymbajueaOlMlD0DVXrRmmp3AVUnXiPfi9rAfPtoW/hz6AdEO46TerOuGgCxHc4A0LzGxE= X-Received: by 2002:a0c:a482:: with SMTP id x2mr1976426qvx.56.1602057118735; Wed, 07 Oct 2020 00:51:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 7 Oct 2020 01:51:46 -0600 Message-ID: Subject: Re: generic q on freebsd To: Kamal Prasad Cc: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 4C5mkl5hykz4VHB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=X4/YM01R; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f42) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.39 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.92)[-0.916]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f42:from]; NEURAL_HAM_SHORT(-0.47)[-0.472]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Wed, 07 Oct 2020 07:52:00 -0000 On Wed, Oct 7, 2020, 12:57 AM Kamal Prasad wrote: > Thanks. Why is it difficult to port the C++ runtime to the kernel? I mean > what is the technological hurdle? > Generally they make use of STL or other standard classes which has no kernel safe implementation at the moment. It's not super hard, irc, just really tedious to implement them in a safe way. Warner thanks > -kamal > > > > > > > On Oct 6, 2020, at 10:53 PM, Warner Losh wrote: > > > > On Tue, Oct 6, 2020, 11:03 AM Kamal R. Prasad wrote: > > > >> hello, > >> > >> i am curious if it is possible to compile c++ code inside the freebsd > >> kernel. > >> > > > > > > Possible? Yes, with restrictions. Easy? No. > > > > There are a number of restrictions on doing this. There is no C++ runtime > > support provided in stock FreeBSD. You have to write your own, or find > > someone else that has published theirs. And the code is likely to be > > compiler dependent. People have done it and talked or blogged about it. > > > > Generally, if you don't use exceptions, templates, RTTI, expressions that > > result in the automatic allocation of objects, have large objects (> 1k) > on > > the stack, etc, it may be possible. I tried it in the 90s and had to > write > > just a few routines to make simple classes work, but there's a lot of > > dragons here and very little C++ code is written these days w/o reference > > to the standard libraries, which aren't present in the kernel. > > > > Some googling turns up: > > https://github.com/adamlsd/libcpp.ko from 6 years ago > > https://lists.freebsd.org/pipermail/freebsd-arch/2018-June/019069.html > has > > some details from 2 years ago about command line args you might need. > > > > Many have tried. Few have succeeded. Those that have write all their code > > to conform to a subset of the language. Few have had success moving C++ > > code for other purposes into the kernel, though if it was written using > the > > proposed (but never ratified) eC++ (embedded subset), then chances are > > greater. > > > > Good luck > > > > Warner > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@freebsd.org Wed Oct 7 07:54:59 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 D13833FF61E for ; Wed, 7 Oct 2020 07:54:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5mpC4WvNz4Vgx for ; Wed, 7 Oct 2020 07:54:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 9B1F83FF7A3; Wed, 7 Oct 2020 07:54:59 +0000 (UTC) Delivered-To: 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 9ADE93FF61D for ; Wed, 7 Oct 2020 07:54:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5mpB2JTvz4VHr; Wed, 7 Oct 2020 07:54:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=dkYfRqUAm/VR2FEks7+vDobAXjPint/1szo1/3jM8Mk=; b=fnQtEm0pW/5XvBZfXlzSDcnKXnP3vGzfklP+nEtAmWPGoW76BsXKDKjCP4na5o4kl2xXVfUbCj3at0yCZ3IUlRXyrG4rrr+mimnaiLDWPrBVG8A6hYNRYZRph4NZZnm7EqK21raZjKWPYRcEpRYci743H3FL3obuIvOtbHxw4LjfA5yDPN/afPx8B5J4sGdt5bq2Xj8ADaWBG3oPIOYW0oXeydPeC2eVqoPh5jQbE/Gyzqhcs/dcpPELJlSR9Xr4TXd4w4W61jwde6O5P6LaVKt4Fmq96quqv5vXlKrILjaXfWq0H2XG2IJ7ukREQFvZfznI5iSdEe0FVHT2tChT9g==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1kQ4Hn-000N0c-8F; Wed, 07 Oct 2020 10:54:55 +0300 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: nanopi/allwinner i2c not working. Date: Wed, 7 Oct 2020 10:54:54 +0300 In-Reply-To: <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il> Cc: "freebsd-arm@freebsd.org" To: Andriy Gapon References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il> X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4C5mpB2JTvz4VHr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=fnQtEm0p; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.12 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.02)[-1.018]; NEURAL_HAM_MEDIUM(-0.99)[-0.995]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-0.81)[-0.806]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[arm] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Wed, 07 Oct 2020 07:54:59 -0000 > On 7 Oct 2020, at 10:21, Daniel Braniss wrote: >=20 >=20 >=20 >> On 7 Oct 2020, at 09:32, Andriy Gapon wrote: >>=20 >> On 06/10/2020 23:29, Daniel Braniss wrote: >>>=20 >>>=20 >>>> On 6 Oct 2020, at 17:22, Andriy Gapon >>> > wrote: >>>>=20 >>>> On 06/10/2020 17:00, Daniel Braniss wrote: >>>>> not too proud of it, but i=E2=80=99ll make it available. >>>>> it=E2=80=99s in https://www.cs.huji.ac.il/~danny/elockc.tar.bz >>>>> look in i2c.c >>>>>=20 >>>>> in any case it works fine in 12.1. >>>>=20 >>>> And it looks good to me as well. >>>> Could you please collect twsi debug output again? >>>> In head you do not need to recompile, you can just set = hw.i2c.twsi_debug. >>> i did have to recompile >>=20 >> Oh, I thought I committed that change, but now I see that I have not. >> It is a part of D26049. >>=20 >>> iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 >>> iichb0: twsi_reset: Using clock param=3D59 >>> iichb0: TWSI_WRITE: Writing 0 to 18 >>> iichb0: TWSI_WRITE: Writing 59 to 14 >>> iichb0: TWSI_WRITE: Writing 40 to c >>> iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 >>> iichb0: twsi_reset: Using clock param=3D59 >>> iichb0: TWSI_WRITE: Writing 0 to 18 >>> iichb0: TWSI_WRITE: Writing 59 to 14 >>> iichb0: TWSI_WRITE: Writing 40 to c >>> iichb0: TWSI_WRITE: Writing c4 to c >>> iichb0: twsi_transfer: transmitting 2 messages >>> iichb0: TWSI_READ: read f8 from 10 >>> iichb0: twsi_transfer: status=3Df8 >>> iichb0: twsi_transfer: msg 0 is 9 bytes long >>> iichb0: twsi_transfer: msg 1 is 7 bytes long >>> iichb0: TWSI_WRITE: Writing e4 to c >>> iichb0: twsi_intr: Got interrupt Current msg=3D0 >>> iichb0: TWSI_READ: read 8 from 10 >>> iichb0: TWSI_READ: read cc from c >>> iichb0: twsi_intr: reg control=3Dcc >>> iichb0: twsi_intr: Send the address (48)iichb0: TWSI_WRITE: Writing = 48 to 8 >>=20 >> Does that address (0x24 / 0x48 in 7-/8-bit representations) look = correct? >=20 > 100% correct >=20 >>=20 >>> iichb0: TWSI_WRITE: Writing c4 to c >>> iichb0: twsi_intr: Refresh reg_control >>> iichb0: TWSI_WRITE: Writing cc to c >>> iichb0: twsi_intr: Done with interrupts >>>=20 >>> iichb0: twsi_intr: Got interrupt Current msg=3D0 >>> iichb0: TWSI_READ: read 20 from 10 >>> iichb0: TWSI_READ: read cc from c >>> iichb0: twsi_intr: reg control=3Dcc >>> iichb0: twsi_intr: No ack received after transmitting the address >>=20 >> The controller says that the device did not acknowledge its address. >> In other words, no device responded to the slave address. >=20 > but i2c -s=20 >>=20 >>> iichb0: twsi_intr: Refresh reg_control >>> iichb0: twsi_transfer: pause finish >>> iichb0: TWSI_WRITE: Writing 8 to c >>> iichb0: twsi_transfer: Error, aborting (2) >>> iichb0: twsi_intr: Done with interrupts >>>=20 >>> iichb0: TWSI_WRITE: Writing 0 to c >>> iichb0: TWSI_READ: read 30 from 10 >>> iichb0: twsi_transfer: status=3D30 >>> iichb0: TWSI_WRITE: Writing 0 to c >>> iichb0: TWSI_READ: read 30 from 10 >>> iichb0: twsi_transfer: status=3D30 >>> iichb0: TWSI_WRITE: Writing c4 to c >>> iichb0: twsi_transfer: transmitting 2 messages >>> iichb0: twsi_intr: Got interrupt Current msg=3D0 >>> iichb0: TWSI_READ: read 30 from 10 >>> iichb0: TWSI_READ: read 30 from 10 >>> iichb0: twsi_transfer: status=3D30 >>> iichb0: TWSI_READ: read cc from c >>> iichb0: twsi_transfer: msg 0 is 9 bytes long >>> iichb0: twsi_intr: reg control=3Dcc >>> iichb0: twsi_transfer: msg 1 is 7 bytes long >>>=20 >>> iichb0: twsi_intr: status=3D30 hot handled >>> iichb0: TWSI_WRITE: Writing e4 to c >>> iichb0: twsi_intr: Refresh reg_control >>> iichb0: twsi_transfer: pause finish >>> iichb0: TWSI_WRITE: Writing 8 to c >>> iichb0: twsi_transfer: Error, aborting (1) >>> iichb0: twsi_intr: Done with interrupts >>>=20 >>> iichb0: TWSI_WRITE: Writing 0 to c >>> iichb0: TWSI_READ: read 10 from 10 >>> iichb0: twsi_transfer: status=3D10 >>> iichb0: TWSI_WRITE: Writing 0 to c >>> iichb0: TWSI_READ: read 10 from 10 >>> iichb0: twsi_transfer: status=3D10 >>=20 >> The rest reads like gibberish because the driver did not stop the = controller >> after the NACK (also, possibly some log messages were omitted from = your email). >>=20 >> I'd recommend once again to give https://reviews.freebsd.org/D26049 a = try. >> I've just rebased it on the latest head, so it should apply cleanly. >=20 > i just downloaded it and will try - the sysctl for hw. is there. >=20 > (i did a git to get the latest current, i=E2=80=99ll try doing an svn = update later -its bloody slow) >>=20 >> But as I said earlier, from the debug log it seems that the problem = is either >> with the slave address or with the hardware (wiring, etc). >=20 > the hardware is fine, running 12.1 on it works ok. > and also i2c -s finds it. >=20 >=20 >> It's also possible that that was a transient condition. >=20 > not really, it seems to me some timming issue. >=20 > after a power cycle, and with debug on, all is working. > turning off debug only i2c -s works. >=20 > in any case will try the D26049 now. >=20 with D26049: i2s -s works with and without debug my test runs ok with debug on, but failed with debug off. timing issue? thanks, danny From owner-freebsd-arm@freebsd.org Wed Oct 7 08:33:50 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 D145A428789 for ; Wed, 7 Oct 2020 08:33:50 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5ng24JkTz4Xcp for ; Wed, 7 Oct 2020 08:33:50 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 93E9C3FFFF6; Wed, 7 Oct 2020 08:33:50 +0000 (UTC) Delivered-To: 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 93B0B4286B7 for ; Wed, 7 Oct 2020 08:33:50 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5ng13lyDz4XWg for ; Wed, 7 Oct 2020 08:33:49 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f48.google.com with SMTP id r127so1294606lff.12 for ; Wed, 07 Oct 2020 01:33:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Ukp7lk1nDzcuBFcE6/BvLSA0bHyFPlKDr2r+eWS6JFI=; b=LTZep+j8Z0twGm+rgwxcH3XpRGiBvsjfiI/w/+8V4t95pHq0q1AqyApT93/IV1Xufv xrrd/8dFyv0TjCnrfw5l1URS1VApMf5EdEQPrQVMITANLLRU9Jkm4xbFafA/ifUoMe7P 5d1XLyu1fx1oHLpe4F54kprwobyNgjgpusT0Mn6/RHOJ8pIj1PviIdW3XhvVE+BIoSth ah0ovFADDvODkks+zyMo1BdgXNDQclxT1+d3CELzjUjWZfX1Q7RQsxdmZQPY5fi4UXNJ A+0Dd45N71Y5dWdh7UYxSEargkagBRg8Q4/lf/pWQOj33eY3oZUWb7SI3LgIb9qah//f SUOA== X-Gm-Message-State: AOAM5300tqqTxUHeRvBYrxZJEiuXhA76rfI3TBctwOKccSRBgs+kHLSR 7cbqLclIPBZ01H1D1HHhZrJ3Lt2/R+Opjg== X-Google-Smtp-Source: ABdhPJzkQshOHEYCWPMLmbTx6XLW0GhlAEGljdu2+Xf1PxRQ5oec9sjWICHdpaJwm/nbXhACjnhoNg== X-Received: by 2002:a19:5619:: with SMTP id k25mr563539lfb.324.1602059627303; Wed, 07 Oct 2020 01:33:47 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id 28sm222414lfp.295.2020.10.07.01.33.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2020 01:33:32 -0700 (PDT) Subject: Re: nanopi/allwinner i2c not working. To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: <82ac00f2-0463-3861-dd39-9c079978be27@FreeBSD.org> Date: Wed, 7 Oct 2020 11:33:16 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4C5ng13lyDz4XWg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-2.92 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.912]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.965]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.040]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.48:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.48:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[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: Wed, 07 Oct 2020 08:33:50 -0000 On 07/10/2020 10:54, Daniel Braniss wrote: > with D26049: > i2s -s works with and without debug > > my test runs ok with debug on, but failed with debug off. > timing issue? That's interesting. I also have an H3-based system and did not see anything like that with any of I2C devices that I have. The latest driver is completely interrupt driven and there are no fixed delays. The controller datasheet does not seem to mandate any delays as well. Perhaps the problem is on the device's side? Also, it could be that the older driver (in 12.1) was slower, so more forgiving of any wiring / connector problems. Not sure how to proceed when debug mode works fine and non-debug fails. Perhaps DTrace would be less overhead than the debug printf-s. Ah, another thought, with debugging enabled, could you please do a bus reset and see what mode and clock param get printed? -- Andriy Gapon From owner-freebsd-arm@freebsd.org Wed Oct 7 08:56:20 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 662514290F5 for ; Wed, 7 Oct 2020 08:56:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5p901Mllz4ZBF for ; Wed, 7 Oct 2020 08:56:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 2C2BF42934F; Wed, 7 Oct 2020 08:56:20 +0000 (UTC) Delivered-To: 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 2BEF842942B for ; Wed, 7 Oct 2020 08:56:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5p8z6gXYz4Yxl; Wed, 7 Oct 2020 08:56:19 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=4GcKZKw/AcTvzx35o5BGialwqGA6jnavhaWj4is1/tM=; b=xfmVRaT3V/d9augdTFeMRoVetsPriyyvJ0Ue3z4XS/m6frQqJr22RBF6OjCBTQvyUHuzxK3hB8RUcrNOTqxw7aW/ZcP30AHsTfLDmaXpSbmNOKi6by6GQ7g5djCy2GAiQz3cxDNITEl7gY6zsduBXgNIS6SW2J0RsLfmeryFdgM8TUdu9zGHhHumyJgOWgBwIvpgCy1dO7d9G6eJkkyU1CA6Wdwr/WWh3wQ3FlvJ/FhPRe76pVKRNYwkC4V4nVGyBjZ0ZgXeZhOdv5+Tkv2KDuM20GG2HG7YJO8HUricXBTeJeFBOBcf2GxePGyPTXJAcDVcqj+aHYw2MfpGyKgbqw==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1kQ5FB-000Osz-OA; Wed, 07 Oct 2020 11:56:17 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: nanopi/allwinner i2c not working. From: Daniel Braniss In-Reply-To: <82ac00f2-0463-3861-dd39-9c079978be27@FreeBSD.org> Date: Wed, 7 Oct 2020 11:56:17 +0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3B6E9040-3498-4FEF-829D-0FAF9E63B1E0@cs.huji.ac.il> References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il> <82ac00f2-0463-3861-dd39-9c079978be27@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4C5p8z6gXYz4Yxl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL] 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: Wed, 07 Oct 2020 08:56:20 -0000 > On 7 Oct 2020, at 11:33, Andriy Gapon wrote: >=20 > On 07/10/2020 10:54, Daniel Braniss wrote: >> with D26049: >> i2s -s works with and without debug >>=20 >> my test runs ok with debug on, but failed with debug off. >> timing issue? >=20 > That's interesting. > I also have an H3-based system and did not see anything like that with = any of > I2C devices that I have. > The latest driver is completely interrupt driven and there are no = fixed delays. > The controller datasheet does not seem to mandate any delays as well. > Perhaps the problem is on the device's side? > Also, it could be that the older driver (in 12.1) was slower, so more = forgiving > of any wiring / connector problems. >=20 > Not sure how to proceed when debug mode works fine and non-debug = fails. > Perhaps DTrace would be less overhead than the debug printf-s. >=20 > Ah, another thought, with debugging enabled, could you please do a bus = reset and > see what mode and clock param get printed? iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 iichb0: twsi_reset: Using clock param=3D59 >=20 > --=20 > Andriy Gapon From owner-freebsd-arm@freebsd.org Wed Oct 7 08:59:14 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 85EEC429669 for ; Wed, 7 Oct 2020 08:59:14 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5pDL26yJz4Z6f for ; Wed, 7 Oct 2020 08:59:14 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 47076429668; Wed, 7 Oct 2020 08:59:14 +0000 (UTC) Delivered-To: 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 46D18429445 for ; Wed, 7 Oct 2020 08:59:14 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5pDK34fjz4YqW for ; Wed, 7 Oct 2020 08:59:13 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f182.google.com with SMTP id y16so33459ljk.1 for ; Wed, 07 Oct 2020 01:59:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6bnp3PVR6BrcAEJYmKR4N3I1MjaofVK8tm7usFZOLnE=; b=APIMZjxhutHODD06zzo3p78b9EdWjzQyN1npPEM+WaIhHZG4fV22KGmUNclfMgBFG3 aU1cdw/Zh1nTp3kMdS0pnUc1W1YWhgviDSCEWTBIuu0YOun1MKmwPn/gstbCnnyVDldb jXSKY5z7SnKM4vLOJQFvbDnlBxIhlK7x8JLSyF/k0o1vO3qd01yQJ8bNX71AK4m7swqT pXgXaGeT8WT14JgayxpWBr1BANVJBW7/lrhW6c08gdgNHlL6/+MWjXxLaOgxYN19MAe7 ra9w4SwKDRWCblswkXE76xFbvCvwZ2r78oxLM343bSDjx7qjE5jKYlB8/caK9Ah4pDWz 8zTQ== X-Gm-Message-State: AOAM531o0jNM1I7FFRjQ3WaQRwfQkQCgGYsXZCQx+k+l94pZTYJ+1KKi d/h5qfwPWKN+oLqDdinOZvwlK8OojHiAiA== X-Google-Smtp-Source: ABdhPJzbprMa4j9dIuVgZ0pkUCXys0z7lpwwZRq7ijCaP7S3f1EqcC9FT4VvC556tWcdH7vVczlOMg== X-Received: by 2002:a2e:89c1:: with SMTP id c1mr875077ljk.385.1602061150571; Wed, 07 Oct 2020 01:59:10 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id b18sm258504ljj.5.2020.10.07.01.59.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2020 01:59:09 -0700 (PDT) Subject: Re: nanopi/allwinner i2c not working. From: Andriy Gapon To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il> <82ac00f2-0463-3861-dd39-9c079978be27@FreeBSD.org> Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: <3eeb74a3-47f1-bf23-bd4a-eae9b5f46daf@FreeBSD.org> Date: Wed, 7 Oct 2020 11:59:08 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <82ac00f2-0463-3861-dd39-9c079978be27@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4C5pDK34fjz4YqW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-2.97 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.958]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.037]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.182:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.182:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[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: Wed, 07 Oct 2020 08:59:14 -0000 On 07/10/2020 11:33, Andriy Gapon wrote: > Perhaps the problem is on the device's side? >From here https://www.nxp.com/docs/en/user-guide/141520.pdf § 6.2.4 However, it may happen that the PN532 does not acknowledge its own address immediately after having finished a previous exchange. So, perhaps an application level delay is needed? I am not really familiar with the device and its communication protocol details, so maybe I am talking nonsense. -- Andriy Gapon From owner-freebsd-arm@freebsd.org Wed Oct 7 09:04:47 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 89CC9429B0D for ; Wed, 7 Oct 2020 09:04:47 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5pLl2D5Qz4ZGH for ; Wed, 7 Oct 2020 09:04:47 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 4C31D42994F; Wed, 7 Oct 2020 09:04:47 +0000 (UTC) Delivered-To: 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 4BF64429869 for ; Wed, 7 Oct 2020 09:04:47 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5pLk3wNCz4ZB7 for ; Wed, 7 Oct 2020 09:04:46 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f174.google.com with SMTP id p15so1190297ljj.8 for ; Wed, 07 Oct 2020 02:04:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=g27mHmTOVsDOEzC1tSaXXWUas5Zhup53Oq3c/mexEO8=; b=mq1l/LAGAwsV3aPYqdchCO8nzxqGtwCWeP4fSJJjM66r15fyXgyElbNBP29ORmsVAJ KZ4DBT35GMp+AU8LjC5NlvaO/YKZlXeNuTOmRQmx5VbZEKX/lwQZjjjBRkvXheJhC7DV XlZ2tDjo4lms8ZUEcmgGqRJDIB3JImjDQ5SY7BBp97qfJ1bG5ChkqBFBacfgcNadBiNE qINWvvrbF/gNDaR9QZRjAVa703J6MJbaFImFdylpb7RnZK2f7HjU9WqL9xjRXQEr4VxX JH1vNRq2EPrRd0kgRQ4MPcqOpgo4EkMykQ/G/wZziNpPKMxmJQlpdUhQuD7ix+iVNz2K P5oQ== X-Gm-Message-State: AOAM530M2IZyCWSSUj1S0v44dHy2m9f3cM9Pel0NbL4tWiT4ef6dOsZl bxFVGVSaNsPdtrtQbJO3PZSzBo1gT010gg== X-Google-Smtp-Source: ABdhPJwqUBt840ogFSE2I0k8NsEBiKNqEtnh+9QQap3wAsGTwgkBVe/OL7O9s7zuKimMK/uFEcC1Eg== X-Received: by 2002:a2e:8e63:: with SMTP id t3mr757455ljk.132.1602061484643; Wed, 07 Oct 2020 02:04:44 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id 21sm236719lfd.272.2020.10.07.02.04.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2020 02:04:44 -0700 (PDT) Subject: Re: nanopi/allwinner i2c not working. To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il> <82ac00f2-0463-3861-dd39-9c079978be27@FreeBSD.org> <3B6E9040-3498-4FEF-829D-0FAF9E63B1E0@cs.huji.ac.il> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: Date: Wed, 7 Oct 2020 12:04:43 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <3B6E9040-3498-4FEF-829D-0FAF9E63B1E0@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4C5pLk3wNCz4ZB7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.174 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-2.97 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.950]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.038]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.174:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.174:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[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: Wed, 07 Oct 2020 09:04:47 -0000 On 07/10/2020 11:56, Daniel Braniss wrote: > > >> On 7 Oct 2020, at 11:33, Andriy Gapon wrote: >> Ah, another thought, with debugging enabled, could you please do a bus reset and >> see what mode and clock param get printed? > > iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 > iichb0: twsi_reset: Using clock param=59 This is good. Means 24MHz -> 100kHz. -- Andriy Gapon From owner-freebsd-arm@freebsd.org Wed Oct 7 09:06:32 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 0327A429C07 for ; Wed, 7 Oct 2020 09:06:32 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5pNl3y3qz4ZLw for ; Wed, 7 Oct 2020 09:06:31 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 85EC5429C06; Wed, 7 Oct 2020 09:06:31 +0000 (UTC) Delivered-To: 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 85B204296A8 for ; Wed, 7 Oct 2020 09:06:31 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5pNl2DDsz4ZPN; Wed, 7 Oct 2020 09:06:30 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=QRmqbG+rsTbJCcroJabuahaue/MYcrfEUh+NeJ/hwVc=; b=FDkKQahi4tn2i0kDyf/Kf0im709r2vtijsENyo1bvuk9pgbGFsPmrooidi1ApxWLTB1e//4RhKSYi7f1X/6vxlMihSFtRFhdt9mYVckJC9uaG7R2ch5QVw0XZtA+ofJgVs6fHPk5MopXCWoB8aAkNw7B7o5P1/1+AhmFLnVsaKKvINimcw6YJHcJS+ItMCMPNUG4xEOzUTB8v0VoBm5NjvwCQnHnqBkoP6a+oAQCYok5aYtwolcn2dv4q/90ncp3XFs4n7S/lhV8xACzfMuCcO841lvfI0mWIkWfBGPRhX3md3lP6wqJnaObYDXs8IAbYfAGGd0AqgRJoTdQ/EyO3w==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1kQ5P2-000POq-NJ; Wed, 07 Oct 2020 12:06:28 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: nanopi/allwinner i2c not working. From: Daniel Braniss In-Reply-To: <3eeb74a3-47f1-bf23-bd4a-eae9b5f46daf@FreeBSD.org> Date: Wed, 7 Oct 2020 12:06:28 +0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il> <82ac00f2-0463-3861-dd39-9c079978be27@FreeBSD.org> <3eeb74a3-47f1-bf23-bd4a-eae9b5f46daf@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4C5pNl2DDsz4ZPN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL] 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: Wed, 07 Oct 2020 09:06:32 -0000 > On 7 Oct 2020, at 11:59, Andriy Gapon wrote: >=20 > On 07/10/2020 11:33, Andriy Gapon wrote: >> Perhaps the problem is on the device's side? >=20 >> =46rom here https://www.nxp.com/docs/en/user-guide/141520.pdf > =C2=A7 6.2.4 > However, it may happen that the PN532 does not acknowledge its own = address > immediately after having finished a previous exchange. >=20 > So, perhaps an application level delay is needed? > I am not really familiar with the device and its communication = protocol details, > so maybe I am talking nonsense. there is some black magic involved here :-) i=E2=80=99ll try putting someday, and some other stuff. btw, I have a dtsoto enable the 2nd. 2c but now Isee that the = =E2=80=98official=E2=80=99 one is different, can you priced me with a correct one? and is there a way to lower the i2c speed? thanks, and it=E2=80=99s back to the drawing board for me. danny >=20 > --=20 > Andriy Gapon From owner-freebsd-arm@freebsd.org Wed Oct 7 09:08:34 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 E6D4A429CA6 for ; Wed, 7 Oct 2020 09:08:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5pR65B3Vz4ZMd for ; Wed, 7 Oct 2020 09:08:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id B1B85429CA4; Wed, 7 Oct 2020 09:08:34 +0000 (UTC) Delivered-To: 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 B178C429C2A for ; Wed, 7 Oct 2020 09:08:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5pR5553lz4Zjn; Wed, 7 Oct 2020 09:08:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=12M81iLN0FrI4dXW/ChloFwWqJkDeCqk+ICZS2pTUaw=; b=PCZAsmF6rl30B28KNmgBISGbu4qKMxA7c7cX1PClicxRpWpQ8xWckWTLOuC0jHpYGKl2SB0aIZ76beFazn4TmZj4YnftdaTyf4not8tc98tNJtFdii08y7XdvD9lBUCHzRTCRrXO27zCEdHxJDx6hz6RfeFoJfdLt+1ooakIVH/SwMidiHpH8XEpxyMyNiKFyhUqLJbleQtSHO7K9U15xSeuyxkq8ffsjvUDgyUSvWdHqGYV79XuXHkgAJNEDmBeHYftMAPhLu4DtcOCgE4IV+Q7mcOiPDHSNAQbdTMJQY/n6WMek5eQJbsjtD2+Mn7ahUsYckiKE5PZWqzTQ6ZUNQ==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1kQ5R1-000PQu-Sa; Wed, 07 Oct 2020 12:08:31 +0300 From: Daniel Braniss Message-Id: <297C8B96-E70D-4126-BCE8-C95E19D344B1@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: nanopi/allwinner i2c not working. Date: Wed, 7 Oct 2020 12:08:31 +0300 In-Reply-To: Cc: "freebsd-arm@freebsd.org" To: Andriy Gapon References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il> <82ac00f2-0463-3861-dd39-9c079978be27@FreeBSD.org> <3eeb74a3-47f1-bf23-bd4a-eae9b5f46daf@FreeBSD.org> X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4C5pR5553lz4Zjn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=PCZAsmF6; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.12 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.02)[-1.018]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-0.81)[-0.805]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[arm] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Wed, 07 Oct 2020 09:08:35 -0000 grr I hate spell checkers > On 7 Oct 2020, at 12:06, Daniel Braniss wrote: >=20 >=20 >=20 >> On 7 Oct 2020, at 11:59, Andriy Gapon wrote: >>=20 >> On 07/10/2020 11:33, Andriy Gapon wrote: >>> Perhaps the problem is on the device's side? >>=20 >>> =46rom here https://www.nxp.com/docs/en/user-guide/141520.pdf >> =C2=A7 6.2.4 >> However, it may happen that the PN532 does not acknowledge its own = address >> immediately after having finished a previous exchange. >>=20 >> So, perhaps an application level delay is needed? >> I am not really familiar with the device and its communication = protocol details, >> so maybe I am talking nonsense. > there is some black magic involved here :-) > i=E2=80=99ll try putting someday, and some other stuff. s/someday/some delay/ > btw, I have a dtsoto enable the 2nd. 2c but now Isee that the = =E2=80=98official=E2=80=99 one is different, > can you priced me with a correct one? > and is there a way to lower the i2c speed? >=20 > thanks, > and it=E2=80=99s back to the drawing board for me. >=20 > danny >=20 >>=20 >> --=20 >> Andriy Gapon >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Wed Oct 7 11:30:23 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 88A5942C561 for ; Wed, 7 Oct 2020 11:30:23 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5sZj4Bhmz4jcB for ; Wed, 7 Oct 2020 11:30:20 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [36.52.212.1]) by kx.truefc.org (8.15.2/8.15.2) with ESMTP id 097BUA5b008538; Wed, 7 Oct 2020 20:30:10 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <202010071130.097BUA5b008538@kx.truefc.org> Date: Wed, 07 Oct 2020 20:30:10 +0900 From: KIRIYAMA Kazuhiko To: freebsd-arm Cc: kiri@truefc.org Subject: Where is the rk3399-pinebook-pro.dtb ? User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP X-Rspamd-Queue-Id: 4C5sZj4Bhmz4jcB X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of kiri@truefc.org has no SPF policy when checking 36.52.212.1) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [1.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.36)[-0.364]; FREEFALL_USER(0.00)[kiri]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[truefc.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.63)[-0.634]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.39)[0.394]; RCVD_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10013, ipnet:36.52.208.0/21, country:JP]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; ONCE_RECEIVED(0.10)[] 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: Wed, 07 Oct 2020 11:30:23 -0000 Hi, all I want to make bootable installer image of PINEBOOK Pro, so I installed sysutils/u-boot-pinebookpro and worked as follows: # truncate -s 1g FreeBSD-13.0-CURRENT-arm64-aarch64-PINEBOOKPRO-20201001-e18fc94e525-memstick.img # mdconfig -d -u md0 # mdconfig -a -t vnode -f FreeBSD-13.0-CURRENT-arm64-aarch64-PINEBOOKPRO-20201001-e18fc94e525-memstick.img md0 # gpart create -s mbr md0 md0 created # gpart add -b 32768 -t fat32lba -s 54m md0 md0s1 added # mdconfig -a -t vnode -f FreeBSD-13.0-CURRENT-arm64-aarch64-PINEBOOK-20201001-e18fc94e525.img md1 # gpart show md1 => 63 6291393 md1 MBR (3.0G) 63 2016 - free - (1.0M) 2079 110502 1 fat32lba [active] (54M) 112581 6178851 2 freebsd (2.9G) 6291432 24 - free - (12K) # gpart show md0 => 63 2097089 md0 MBR (1.0G) 63 32705 - free - (16M) 32768 110592 1 fat32lba (54M) 143360 1953792 - free - (954M) # dd if=/dev/md1s1 of=/dev/md0s1 bs=10240 conv=sync 5526+0 records in 5526+0 records out 56586240 bytes transferred in 50.280273 secs (1125416 bytes/sec) # mdconfig -d -u md1 # mdconfig -a -t vnode -f FreeBSD-13.0-CURRENT-arm64-aarch64-20201001-e18fc94e525-memstick.img md1 # gpart show md1 => 3 1655448 md1 GPT (808M) 3 66584 1 efi (33M) 66587 1588864 2 freebsd (776M) # gpart add -t freebsd md0 md0s2 added # dd if=/dev/md1s2 of=/dev/md0s2 bs=10240 conv=sync 79444+0 records in 79444+0 records out 813506560 bytes transferred in 736.789089 secs (1104124 bytes/sec) # dd if=/usr/local/share/u-boot/u-boot-pinebookpro/idbloader.img of=/dev/md0 seek=64 bs=512 conv=sync 322+0 records in 322+0 records out 164864 bytes transferred in 1.578397 secs (104450 bytes/sec) # dd if=/usr/local/share/u-boot/u-boot-pinebookpro/u-boot.itb of=/dev/md0 seek=16384 bs=512 conv=sync 1800+0 records in 1800+0 records out 921600 bytes transferred in 11.001794 secs (83768 bytes/sec) # # gpart show md0 => 63 2097089 md0 MBR (1.0G) 63 32705 - free - (16M) 32768 110592 1 fat32lba (54M) 143360 1953792 2 freebsd (954M) # gpart set -a active -i 1 md0 active set on md0s1 # gpart show md0 => 63 2097089 md0 MBR (1.0G) 63 32705 - free - (16M) 32768 110592 1 fat32lba [active] (54M) 143360 1953792 2 freebsd (954M) # mount -t msdos /dev/md0s1 /mnt # ll /mnt/ total 8 drwxr-xr-x 1 root wheel 4096 10$B7n(B 1 19:40 dtb/ drwxr-xr-x 1 root wheel 4096 10$B7n(B 1 19:40 EFI/ # ll /mnt/dtb/rockchip/ total 432 -rwxr-xr-x 1 root wheel 50515 10$B7n(B 1 19:40 rk3328-rock64.dtb* -rwxr-xr-x 1 root wheel 75766 10$B7n(B 1 19:40 rk3399-firefly.dtb* -rwxr-xr-x 1 root wheel 75037 10$B7n(B 1 19:40 rk3399-khadas-edge-captain.dtb* -rwxr-xr-x 1 root wheel 75029 10$B7n(B 1 19:40 rk3399-khadas-edge-v.dtb* -rwxr-xr-x 1 root wheel 74974 10$B7n(B 1 19:40 rk3399-khadas-edge.dtb* -rwxr-xr-x 1 root wheel 75967 10$B7n(B 1 19:40 rk3399-rockpro64.dtb* # I found that there is not rk3399-pinebook-pro.dtb. I searched rk3399-pinebook-pro.dts [1] but it's binary could not found. Where is the rk3399-pinebook-pro.dtb? Regards. [1] http://sbexr.rabexc.org/latest/sources/16/9e72f1727556c6.html --- Kazuhiko Kiriyama From owner-freebsd-arm@freebsd.org Wed Oct 7 15:54:00 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 67F5543275B for ; Wed, 7 Oct 2020 15:54:00 +0000 (UTC) (envelope-from oskar.holmlund@yahoo.com) Received: from sonic307-54.consmr.mail.ir2.yahoo.com (sonic307-54.consmr.mail.ir2.yahoo.com [87.248.110.31]) (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 4C5zQt6YgVz3V2B for ; Wed, 7 Oct 2020 15:53:58 +0000 (UTC) (envelope-from oskar.holmlund@yahoo.com) X-YMail-OSG: lJvbDV8VM1mUQzbV9Zevvsoa8E2POjdMI_vAF8hAFuad1bINijhnudmFurqAySK aHa0hZBSRQEbEcmDcK6AP7jkCPxz8EQYlk_edEaVAIfAsPptBPrBr7taf6zuC7nt_IrLxryON2zw AIDze7diwIqMhRLtaAkMKdBX0cn6t6VXJ34Bk1MwfZMEQ0amT9R0JB7vaqGfE8o1ietl21Huh3FB Z16BdLrI3gEpJxSSMsFUhqKDujssBSMTpE9tTvtmrfz36U7Yvf3hhkTKigf9q_Rl5bek7oO1_L6x Ys6JgVMIBLYTPJh3s7sjKH0bx3cibkKpNrz.XRDuFcd6NES5zVkW43V_KsEFA6dld1mJub_zelCP M7tsn524kDIoTvUIXidhnHF1qzu.lPNEJbIpCmjwjuLh2AulwGX25Uqxq0Bxzy4ZY7n35wFVJnq6 1RFKj.0KJ5bdQyJ3MN22_W4SRGNXXUnUkFZuW_yOjkAIsu3ofUlwTKQQI1glvWsJiZVWWh0rt0rm pf_yjP7eFSTj.nOd.AtzrpKlIJ31sa4lzlltafJC3D.ClF8CAxUX7R1sNUE6IS83h2TgUZhNGap1 ylvIb1f6o6FcAByMcnxxW_cnoaQ2E_EUnBXyu6bwzb6G6Z5Z6iGd5iwMo0nize593C4SfGt8pPp9 R1St23jO.3PH6VM1brWZJLIxRqZb5lnM2KEsQzroLc7P68T3.D4wE4jfhPnIuYfv_QNeKlbRbqxC halBjhgA_Kf77UTSboDKRPbQHZuGUpfxjO23VsGfi16rTck3AdYNJsXFJ._8kVw4hCEpcZxI3ML8 pvMW2OXtkpvV8IVgnUB.rArd1wAQJgCg2fFOoyLNCC3YjoDEQEs9VrTnEt0AXpzYI.U1EP.rw05Q JMyb_Ga6MlHyNCHWVoXdk7apqRd3LYYrK0CLG8pJI5ZjosFcAxZHwh9RA4EXg6Ki2j_CkmUSm1je nPNXvTkN76bOpnYcE_4KOpQcvRb0Ab4NilzP.4DQENWZqgTYSlTxUb8ao71fABtl3ipX5coVJB9w mAA1rfF8BrSV9ug3VANQnkwprKMkdzXAnib1x3KBpC6lYByOXyXKP0DsKvnTWb4JzqneGgj8OHZI G7KTBeb_38FG75az9LH5DJzt0GSUgbETrPjWX9en_cxG8wagGlTbQQNzSZQOmBWdGXGTVbkZMHWi WJzVUTnG07Z8an2_fjM45airAbzR2SwxtZpmj1FE3ZHPujY2.eztzKSvfVXHlswCRHG8WEYFzoMe tliBokxGFUR1GdG7Q0p27OxUADK5usZ_JJnx1hCoCotcZM7PopVHBOy_zYez9G6ztjdVaCj7iqzX lQvPyWfKMFNr_iYYPJY1e85nPhSK1lZpCx3EBI886UAvteYD0yobXQwzityh9vgrIO31BUqdU.8p wCF3uHHAtfN0cirpQ2zpHfllIgp7dqg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ir2.yahoo.com with HTTP; Wed, 7 Oct 2020 15:53:55 +0000 Date: Wed, 7 Oct 2020 15:53:51 +0000 (UTC) From: Oskar Holmlund To: freebsd-arm , Ed Maste Message-ID: <472221209.496244.1602086031265@mail.yahoo.com> In-Reply-To: References: Subject: Re: BBB boot failure between r366365 and r366386 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.16795 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0 X-Rspamd-Queue-Id: 4C5zQt6YgVz3V2B X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.95 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[87.248.110.31:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.02)[-1.021]; NEURAL_HAM_MEDIUM(-1.03)[-1.034]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[87.248.110.31:from]; NEURAL_HAM_SHORT(-0.89)[-0.895]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:34010, ipnet:87.248.110.0/24, country:GB]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] 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: Wed, 07 Oct 2020 15:54:00 -0000 Hello Ed, > Den onsdag 7 oktober 2020 03:11:55 CEST, Ed Maste sk= rev:=20 > On Tue, 6 Oct 2020 at 14:59, Ed Maste wrote: > > > > On Mon, 5 Oct 2020 at 15:56, Ed Maste wrote: > > > > > >=C2=A0 On Mon, 5 Oct 2020 at 09:53, Ed Maste wrot= e: > > > > > > > > Sometime after r366365 and up to r366365 BBB stopped booting in the= HW > > > > test environment. > > > > > > That should of course be after r366365 and up to (and including) > > > r366386. > > > > Discussed on IRC; the second U-Boot banner comes out ~60s after the > > first, which might suggest a watchdog timeout. > > > > We seem to get stuck after > > > random: unblocking device. > > kevans points out that std.armv7 includes VERBOSE_SYSINIT=3D0, so > verbose sysinits are available with a loader tunable. We get this far: >=20 > subsystem 2140000 >=C2=A0 init_hwpmc(0)... done. >=C2=A0 init_dtrace(0)... done. >=C2=A0 pmc_soft_ev_register(&pmc___lock_failed)... done. >=C2=A0 pmc_soft_ev_register(&pmc___clock_prof)... done. >=C2=A0 pmc_soft_ev_register(&pmc___clock_hard)... done. >=C2=A0 pmc_soft_ev_register(&pmc___clock_stat)... done. > subsystem 2160000 > =C2=A0 random_fortuna_init_alg(0)... done. > =C2=A0 random_harvestq_init(0)... done. > =C2=A0 random_harvestq_prime(0)... done. > =C2=A0 __stack_chk_init(0)... random: unblocking device. > done. > subsystem 2180000 > =C2=A0 mac_init(0)... done. > subsystem 21d0000 > =C2=A0 mac_late_init(0)... done. > subsystem 21e0000 > =C2=A0 vnet0_init(0)... done. > subsystem 2200000 > =C2=A0 proc0_init(0)... done. > =C2=A0 shutdown_conf(0)... done. > subsystem 2300000 > =C2=A0 vm_stats_init(0)... done. > =C2=A0 uma_startup3(0)... done. > =C2=A0 vm_page_init_cache_zones(0)... done. > subsystem 2380000 > =C2=A0 db_capture_sysinit(0)... done. > subsystem 2400000 > =C2=A0 sched_setup(0)... done. > subsystem 2480000 > =C2=A0 ktrace_init(0)... > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" I can not reproduce the problem - I have tested r366366 - r366386 and as of= today r366515 and all works fine. U-boot is same as yours 2020.07. But i h= ave not tested to netboot the BBB, i have only tested from SD card and from= eMMC. I can try the kernel and base from the CI builds later. //Oskar From owner-freebsd-arm@freebsd.org Wed Oct 7 15:57:49 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 205C9432B19 for ; Wed, 7 Oct 2020 15:57:49 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5zWH6kz9z3VKG; Wed, 7 Oct 2020 15:57:47 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1602086259; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/M4ufbbn5X7bTKvPmwTD1RZL58iq0s/s5j3xvc+iVic=; b=OgibvyAdfYfky54QgY2ThQLT7RHHNLSfa2XZIfMmbIeszOnLPjimZqFk5eoS/OU6MM024G bVCJB7IOnVN++e6DbwdJhpaZZjsMehAwkGSpGIBIb78BIPM9C+NSCP//PLbPsLSvOWDBcH mA+Pe9oI5JbTdemXllkki23TErnqaGo= Received: from skull.home.blih.net (lfbn-idf2-1-288-247.w82-123.abo.wanadoo.fr [82.123.126.247]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 3d9caf1c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 7 Oct 2020 15:57:39 +0000 (UTC) Date: Wed, 7 Oct 2020 17:57:39 +0200 From: Emmanuel Vadot To: Oskar Holmlund Cc: Oskar Holmlund via freebsd-arm , Ed Maste , markj@freebsd.org Subject: Re: BBB boot failure between r366365 and r366386 Message-Id: <20201007175739.d2899b22406eaf86893f1357@bidouilliste.com> In-Reply-To: <472221209.496244.1602086031265@mail.yahoo.com> References: <472221209.496244.1602086031265@mail.yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4C5zWH6kz9z3VKG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=OgibvyAd; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.67 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.035]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.11)[-1.110]; NEURAL_HAM_MEDIUM(-1.02)[-1.024]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; 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: Wed, 07 Oct 2020 15:57:49 -0000 On Wed, 7 Oct 2020 15:53:51 +0000 (UTC) Oskar Holmlund via freebsd-arm wrote: > Hello Ed, >=20 > > Den onsdag 7 oktober 2020 03:11:55 CEST, Ed Maste = skrev:=20 > > On Tue, 6 Oct 2020 at 14:59, Ed Maste wrote: > > > > > > On Mon, 5 Oct 2020 at 15:56, Ed Maste wrote: > > > > > > > >=A0 On Mon, 5 Oct 2020 at 09:53, Ed Maste wrote: > > > > > > > > > > Sometime after r366365 and up to r366365 BBB stopped booting in t= he HW > > > > > test environment. > > > > > > > > That should of course be after r366365 and up to (and including) > > > > r366386. > > > > > > Discussed on IRC; the second U-Boot banner comes out ~60s after the > > > first, which might suggest a watchdog timeout. > > > > > > We seem to get stuck after > > > > random: unblocking device. > > > > kevans points out that std.armv7 includes VERBOSE_SYSINIT=3D0, so > > verbose sysinits are available with a loader tunable. We get this far: > >=20 > > subsystem 2140000 > >=A0 init_hwpmc(0)... done. > >=A0 init_dtrace(0)... done. > >=A0 pmc_soft_ev_register(&pmc___lock_failed)... done. > >=A0 pmc_soft_ev_register(&pmc___clock_prof)... done. > >=A0 pmc_soft_ev_register(&pmc___clock_hard)... done. > >=A0 pmc_soft_ev_register(&pmc___clock_stat)... done. > > subsystem 2160000 > > =A0 random_fortuna_init_alg(0)... done. > > =A0 random_harvestq_init(0)... done. > > =A0 random_harvestq_prime(0)... done. > > =A0 __stack_chk_init(0)... random: unblocking device. > > done. > > subsystem 2180000 > > =A0 mac_init(0)... done. > > subsystem 21d0000 > > =A0 mac_late_init(0)... done. > > subsystem 21e0000 > > =A0 vnet0_init(0)... done. > > subsystem 2200000 > > =A0 proc0_init(0)... done. > > =A0 shutdown_conf(0)... done. > > subsystem 2300000 > > =A0 vm_stats_init(0)... done. > > =A0 uma_startup3(0)... done. > > =A0 vm_page_init_cache_zones(0)... done. > > subsystem 2380000 > > =A0 db_capture_sysinit(0)... done. > > subsystem 2400000 > > =A0 sched_setup(0)... done. > > subsystem 2480000 > > =A0 ktrace_init(0)... > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 > I can not reproduce the problem - I have tested r366366 - r366386 and as = of today r366515 and all works fine. U-boot is same as yours 2020.07. But i= have not tested to netboot the BBB, i have only tested from SD card and fr= om eMMC. > I can try the kernel and base from the CI builds later. >=20 > //Oskar I manage to find the problem with a lot of help from markj@. This is due to r364819 (and maybe the -O2 recent switch). =20 This patch fixes it : diff --git a/sys/kern/subr_vmem.c b/sys/kern/subr_vmem.c index b99b895233a4..b48ff7f29b63 100644 --- a/sys/kern/subr_vmem.c +++ b/sys/kern/subr_vmem.c @@ -697,7 +697,7 @@ vmem_startup(void) * arena, which may involve importing a range from the kernel arena, * so we need to keep at least 2 * BT_MAXALLOC tags reserved. */ - uma_zone_reserve(vmem_bt_zone, 2 * BT_MAXALLOC * mp_ncpus); + uma_zone_reserve(vmem_bt_zone, 64); uma_zone_set_allocf(vmem_bt_zone, vmem_bt_alloc); #endif } Mark is now aware of the issue and I'm sure he will find a correct patch soon :) Cheers, --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Oct 8 09:01:37 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 6E51A3FB22C for ; Thu, 8 Oct 2020 09:01:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4C6QDZ5rxSz3XG8 for ; Thu, 8 Oct 2020 09:01:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: _NdKAAsVM1npyJsnBay8RtmuWy3xZo3dbW2heCDEBFMKw0ddeJAGAA8uV9YiZen zx8_GbNDcLAom7by0l3T9a0UZ25IBmgEgucL.YQSt.M6sWddeHEvUwtbgFKKBOzr4QH6cQc0yWGS CpulyWm1FnWQ2uOblLtwsg.DL_Pm.iJ1rx7l5gykQlmghjbHTSoQvmRzp0KvzLK_yQ0YTzzkRC30 LcCYXndHghM_XQhJv408RZBIGe0UpmKMpl5s2ypzeGRQQ3vBn6PkncSRaFLPL7RzTVs.rkcZEz7D tD1hE8w1BjW7Y.cMnU.vMni2nryIi5jgkDwaKD7FEJrA1vxmsI7wN0EIOWqbAHpusIU2avu1yM7E nCK3FVm1Z3LhM03ptPRZU_TAks8q.zIv2Ja52Bf_DW67Xoz8GmQsHNrDfxBeyUVnzOvMbBlhXx2O 81olhWbHgwdP3c1Q.rLRyDVPdeP90bcvS8BhKIUX9Wger5IO_cqPX03kpXFj7Vas_ETftGwKrcsg dgOywLPY2TicBvHK_YOH.7p1IG053rd9jkCPAdrHzjQLyu.d1grWjyiKasx.k_B1gVNgQ0bXKVvt KKFLbvEzRu8GS46sLfb1xCl9iI.vvlpI_ke4GHEyidlyRnaKRk8Sly2i8_GeOQE19X3ijTK0aV2C Fv9JMeLkt4gqLndUBwcZCCFnbYtM8MET5r34YqO3jDop0Qkq46sMPOs_XVEm2bOtWXMDe4B0SSNQ totJE5y.oGxy5TyDnTOQ6KlwOIMAXOmLAzLB7Hq7r7mxfqHFKJXNbYUhA6m5j9KVpSIAjkUdcDT7 7Mok1U9QdqWLFBrMiKSOqdQJKJQGV6Dn1POAz1zEcd_Dr0v3sMkIAlyqOMtWk_MhZz6B1BxUqBFb gvDfk.1KgSvbrgPpcP.6T0gd9GgVboN2PsJNua_f2GRRx2Ysl_NkqKuTi86cHUyDCle8I0WWILvu HoZZB5yP1zUw4y2BLxzVz6y_Xqp5ntSpakgCZk6AtG.U0TBOCegK3L3drjRSAUL1NZ29dOkywk95 4hEtfwidbKvEwi9bkkzgXOsT_xd2AEbhhqm3HbFIJTn4k22oUHiRw.hwO0nDiXP9xIWCEhFslW9j finbo5FPlqO1mkfE0qbdGoKVAHGkZ_wkWhybfH6rYSR9kZ4eoPeDYTqY6ZVEqm0nfKY2AwTo8BRk zJAO0OIxij6X036tA.qATmEzQH.jEsZ_cOm8iPAfKSOgyTkpsW.kOB4oIsGeKfmRrBgjzOpQoRCb 1ZvzghFW0CHWusmtfPeEyvl7zmFME9rDYIJi8KivojWAn.VEs8inJN45JDENi3J19prD.AqoKLLc HyGeLjBjDjMaEeV1UcmyvoO3_GmON3u8VtsEEopold07FOtOHSD8jkabLbC8g77GIURq6TeHq5mx dctcZ60jz3PcKchVhYBxiPMSwYkt1bMXLiLkUIW2PpxtkQTzr8d8WA23dkdpCUaLmiKSviMnbwr_ CQKGApTMpJ1T91TIYbM6cc2KrHByiaBHp2zLie3JfaoTs8Xxx8IMjffKd8Kqk1A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Oct 2020 09:01:32 +0000 Received: by smtp406.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bb6102d3dcfe5689569546e125e11302; Thu, 08 Oct 2020 09:01:31 +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: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Message-Id: Date: Thu, 8 Oct 2020 02:01:29 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3608.120.23.2.1) References: X-Rspamd-Queue-Id: 4C6QDZ5rxSz3XG8 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.93 / 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.42)[-0.420]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.00)[-1.002]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.012]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; 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: Thu, 08 Oct 2020 09:01:37 -0000 sys/gnu/dts/arm/bcm2711.dtsi reports: /* * emmc2 has different DMA constraints based on SoC revisions. = It was * moved into its own bus, so as for RPi4's firmware to update = them. * The firmware will find whether the emmc2bus alias is defined, = and if * so, it'll edit the dma-ranges property below accordingly. */ emmc2bus: emmc2bus { compatible =3D "simple-bus"; #address-cells =3D <2>; #size-cells =3D <1>; =20 ranges =3D <0x0 0x7e000000 0x0 0xfe000000 0x01800000>; dma-ranges =3D <0x0 0xc0000000 0x0 0x00000000 = 0x40000000>; =20 emmc2: emmc2@7e340000 { compatible =3D "brcm,bcm2711-emmc2"; reg =3D <0x0 0x7e340000 0x100>; interrupts =3D ; clocks =3D <&clocks BCM2711_CLOCK_EMMC2>; status =3D "disabled"; }; }; The old u-boot/DTB combination in use does not have emmc2bus. And, even if it did, FreeBSD would not use the dma-ranges content, expecting it to not vary within the RPi4B family. Relative to "lowaddr", for example, there is: #define BCM2838_PERIPH_MAXADDR 0x3fffffff (the emmc2bus dma-ranges' size_cell_value-1 for the text above). sys/arm/broadcom/bcm2835/bcm2835_sdhci.c does list brcm,bcm2711-emmc2 in its compat_data: static struct ofw_compat_data compat_data[] =3D { {"broadcom,bcm2835-sdhci", (uintptr_t)&bcm2835_sdhci_conf}, {"brcm,bcm2835-sdhci", (uintptr_t)&bcm2835_sdhci_conf}, {"brcm,bcm2835-mmc", (uintptr_t)&bcm2835_sdhci_conf}, {"brcm,bcm2711-emmc2", (uintptr_t)&bcm2838_emmc2_conf}, {"brcm,bcm2838-emmc2", (uintptr_t)&bcm2838_emmc2_conf}, {NULL, 0} }; where BCM2838_PERIPH_MAXADDR is picked out based on: (from sys/arm/broadcom/bcm2835/bcm2835_vcbus.c) static struct bcm283x_memory_soc_cfg { struct bcm283x_memory_mapping *memmap; const char *soc_compat; bus_addr_t busdma_lowaddr; } bcm283x_memory_configs[] =3D { . . . { .memmap =3D bcm2838_memmap, .soc_compat =3D "brcm,bcm2711", .busdma_lowaddr =3D BCM2838_PERIPH_MAXADDR, }, { .memmap =3D bcm2838_memmap, .soc_compat =3D "brcm,bcm2838", .busdma_lowaddr =3D BCM2838_PERIPH_MAXADDR, }, }; (I've not found tracking of SoC revisions. But I also do not know what varies across which SoC revisions. So far as I know, the few I have access to have a uniform structure.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Oct 8 11:16:02 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 6D1D63FD279 for ; Thu, 8 Oct 2020 11:16:02 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6TCj6GCfz3f1C for ; Thu, 8 Oct 2020 11:16:01 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-pf1-x441.google.com with SMTP id y14so3697012pfp.13 for ; Thu, 08 Oct 2020 04:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=PFgENX4xjdr7fRpyefZIEzARn8Xw0o0eCcw0TFTkjQc=; b=klOafaRVu/JM9djgJTbDi3l86GPormfVdiSY0g9H0uuNhdtq4hptxeqvaOquZ9dNJj jbvNbuO7MsyrgNUBBQ43N/Odp9csWJZXaN7yHi35OdV9g7zRlSp93pSflTtUDXZJPkmj VOa0EEn00zlIaJPKk/96hQ2+UY2H/pD22K06VfyRlnrRSG2tsN/f8kqvEBHoQke3Smag Hlec7EebN+3xZKp4bKA6Fwq4bt0eUg99Hm/84V/8HSfKWkLNHZADC2F001vn7BEfxTQj DeeKge7WBJLExdpD83bP0lGtPXjnCE1gUaI/B9d6X2/iU1XmFd8pBjKwGb8MRwGZGXwc vb9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PFgENX4xjdr7fRpyefZIEzARn8Xw0o0eCcw0TFTkjQc=; b=WYhXjpvF2DyWFUACZmKEsnrVo+CNcDoArGA+Z3sYreubVxGhKIF6QnI7gQV722N3J6 lTp3930ZmpAuj8Vky3681BDZ9sudib1Csmj+p5Y43wOA6skEvuBOjVytQLjz+e3bO8Ax U/OfjDJDKn4dr4elsh+LQqNzXee/jHdUzQJ7naO2Yc4SM7ylTU2wgW3UGfcHwPbm/eq0 teKUefItioWQu8lxqTmFsJ+8OLxfoAE9cwWalMpiyBFXWpGeeWcOaU3LH59dsGE3ExG5 ARKrbKKbGRxYJQr98V5QcBxkyWyZrE42IMhPaVATOGbJhp0aPxWYZ1PsdbrptJMxcQTe os8g== X-Gm-Message-State: AOAM530PqiqP+ypS0SaGMZOue0pgf9pMfkuyrITOuWXILeCtNgnX4oxG pzi2hfMKTlY6bF/2RT0v9GHK1mgI8AUexwKQ2HiJt1PHwCo= X-Google-Smtp-Source: ABdhPJyW5m/MMEyoqVCI48m2GbvC64ansl3lnbwtcC311SDqGsut+KAWYD+FH/KHhordtScnBCBkxeuCN/AFdyUK6RM= X-Received: by 2002:a63:1219:: with SMTP id h25mr6788939pgl.72.1602155759983; Thu, 08 Oct 2020 04:15:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sleep Walker Date: Thu, 8 Oct 2020 14:15:42 +0300 Message-ID: Subject: Re: FreeBSD-13.0-CURRENT on Helios64 Kobol NAS To: Free BSD X-Rspamd-Queue-Id: 4C6TCj6GCfz3f1C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=klOafaRV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of s199pwa1k9r@gmail.com designates 2607:f8b0:4864:20::441 as permitted sender) smtp.mailfrom=s199pwa1k9r@gmail.com X-Spamd-Result: default: False [-3.35 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.01)[-1.007]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::441:from]; NEURAL_HAM_SHORT(-0.35)[-0.348]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Thu, 08 Oct 2020 11:16:02 -0000 Hello FreeBSD ARM community! I have successfully installed FreeBSD-13.0-CURRENT on Kobol Helios64 (RK3399). https://wiki.kobol.io/helios64/intro/ U-boot and DTS file kindly provided by Kobol TEAM :-). dmesg and dmesg verbose can be viewed here. dmesg - https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D5695 dmesg verbose - https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D5694 I have not yet had time to conduct a thorough test, but at first glance, all 6 SATA dicks work perfectly, even with 6 kernels enabled with OpenZFS support. Of course, the speed of dwc (4) - 53MB / sec and the incomprehensible behavior of the 2.5GbE port built on the Realtek RTL8156 chip via VL815 USB 3.0 Hub - is disappointing. --- ue0: flags =3D 8843 metric 0 m= tu 1500 ether 64: 62: 66: d0: 01: 3d inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options =3D 29 ---- root @ tsy: ~ # iperf3 -c 192.168.1.1 Connecting to host 192.168.1.1, port 5201 [5] local 192.168.1.182 port 60358 connected to 192.168.1.1 port 5201 [ID] Interval Transfer Bitrate Retr Cwnd [5] 0.00-1.00 sec 10.4 MBytes 87.2 Mbits / sec 90 42.6 KBytes [5] 1.00-2.00 sec 10.8 MBytes 91.0 Mbits / sec 106 1.41 KBytes [5] 2.00-3.00 sec 10.8 MBytes 91.0 Mbits / sec 109 24.1 KBytes [5] 3.00-4.00 sec 10.8 MBytes 90.7 Mbits / sec 101 1.41 KBytes [5] 4.00-5.00 sec 10.8 MBytes 90.9 Mbits / sec 105 1.41 KBytes [5] 5.00-6.00 sec 10.9 MBytes 91.1 Mbits / sec 104 42.6 KBytes [5] 6.00-7.00 sec 10.8 MBytes 90.7 Mbits / sec 105 41.2 KBytes [5] 7.00-8.00 sec 10.8 MBytes 91.0 Mbits / sec 105 42.6 KBytes [5] 8.00-9.00 sec 10.8 MBytes 91.0 Mbits / sec 110 22.6 KBytes [5] 9.00-10.00 sec 10.9 MBytes 91.0 Mbits / sec 105 29.8 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - - [ID] Interval Transfer Bitrate Retr [5] 0.00-10.00 sec 108 MBytes 90.6 Mbits / sec 1040 sender [5] 0.00-10.00 sec 107 MBytes 90.0 Mbits / sec receiver iperf Done. root @ tsy: ~ # iperf3 -R -c 192.168.1.1 Connecting to host 192.168.1.1, port 5201 Reverse mode, remote host 192.168.1.1 is sending [5] local 192.168.1.182 port 55719 connected to 192.168.1.1 port 5201 [ID] Interval Transfer Bitrate [5] 0.00-1.00 sec 20.7 MBytes 174 Mbits / sec [5] 1.00-2.00 sec 21.7 MBytes 182 Mbits / sec [5] 2.00-3.00 sec 21.7 MBytes 182 Mbits / sec [5] 3.00-4.00 sec 21.7 MBytes 182 Mbits / sec [5] 4.00-5.00 sec 21.7 MBytes 182 Mbits / sec [5] 5.00-6.00 sec 21.7 MBytes 182 Mbits / sec [5] 6.00-7.00 sec 21.7 MBytes 182 Mbits / sec [5] 7.00-8.00 sec 21.7 MBytes 182 Mbits / sec [5] 8.00-9.00 sec 21.7 MBytes 182 Mbits / sec [5] 9.00-10.00 sec 21.7 MBytes 182 Mbits / sec - - - - - - - - - - - - - - - - - - - - - - - - - - [ID] Interval Transfer Bitrate Retr [5] 0.00-10.03 sec 217 MBytes 181 Mbits / sec 1 sender [5] 0.00-10.00 sec 216 MBytes 181 Mbits / sec receiver In general, the speed of the network is terribly annoying. Before that, I last tested the 22 Jun system and then eMMC worked fine. --- FreeBSD 13.0-CURRENT # 0 r361113M 0fb6ad5-c996 (nanopi): Mon Jun 22 12:18:06 MSK 2020 root@dev.kubsu.ru: /usr/crochet/work/obj/usr/crochet/src-13.0/arm64.aarch64/sys/FREENAS arm64 FreeBSD clang version 10.0.0 (git@github.com: llvm / llvm-project.git llvmorg-10.0.0-0-gd32170dbd5b) Now eMMC is not detected. As a result, there is a replenishment in the ranks of ARM hardware ;-). --- Sergey Tyuryukanov. =D1=87=D1=82, 8 =D0=BE=D0=BA=D1=82. 2020 =D0=B3. =D0=B2 12:01, Mark Millard= via freebsd-arm < freebsd-arm@freebsd.org>: > sys/gnu/dts/arm/bcm2711.dtsi reports: > > /* > * emmc2 has different DMA constraints based on SoC revisions. It > was > * moved into its own bus, so as for RPi4's firmware to update > them. > * The firmware will find whether the emmc2bus alias is defined, > and if > * so, it'll edit the dma-ranges property below accordingly. > */ > emmc2bus: emmc2bus { > compatible =3D "simple-bus"; > #address-cells =3D <2>; > #size-cells =3D <1>; > > ranges =3D <0x0 0x7e000000 0x0 0xfe000000 0x01800000>; > dma-ranges =3D <0x0 0xc0000000 0x0 0x00000000 0x4000000= 0>; > > emmc2: emmc2@7e340000 { > compatible =3D "brcm,bcm2711-emmc2"; > reg =3D <0x0 0x7e340000 0x100>; > interrupts =3D ; > clocks =3D <&clocks BCM2711_CLOCK_EMMC2>; > status =3D "disabled"; > }; > }; > > > The old u-boot/DTB combination in use does not have emmc2bus. > And, even if it did, FreeBSD would not use the dma-ranges > content, expecting it to not vary within the RPi4B family. > Relative to "lowaddr", for example, there is: > > #define BCM2838_PERIPH_MAXADDR 0x3fffffff > > (the emmc2bus dma-ranges' size_cell_value-1 for the text > above). > > sys/arm/broadcom/bcm2835/bcm2835_sdhci.c does list brcm,bcm2711-emmc2 in > its compat_data: > > static struct ofw_compat_data compat_data[] =3D { > {"broadcom,bcm2835-sdhci", (uintptr_t)&bcm2835_sdhci_conf}, > {"brcm,bcm2835-sdhci", (uintptr_t)&bcm2835_sdhci_conf}, > {"brcm,bcm2835-mmc", (uintptr_t)&bcm2835_sdhci_conf}, > {"brcm,bcm2711-emmc2", (uintptr_t)&bcm2838_emmc2_conf}, > {"brcm,bcm2838-emmc2", (uintptr_t)&bcm2838_emmc2_conf}, > {NULL, 0} > }; > > where BCM2838_PERIPH_MAXADDR is picked out based on: > (from sys/arm/broadcom/bcm2835/bcm2835_vcbus.c) > > static struct bcm283x_memory_soc_cfg { > struct bcm283x_memory_mapping *memmap; > const char *soc_compat; > bus_addr_t busdma_lowaddr; > } bcm283x_memory_configs[] =3D { > . . . > { > .memmap =3D bcm2838_memmap, > .soc_compat =3D "brcm,bcm2711", > .busdma_lowaddr =3D BCM2838_PERIPH_MAXADDR, > }, > { > .memmap =3D bcm2838_memmap, > .soc_compat =3D "brcm,bcm2838", > .busdma_lowaddr =3D BCM2838_PERIPH_MAXADDR, > }, > }; > > (I've not found tracking of SoC revisions. But I also do > not know what varies across which SoC revisions. So far > as I know, the few I have access to have a uniform > structure.) > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Oct 8 13:36:16 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 D5DC5428B1D for ; Thu, 8 Oct 2020 13:36:16 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6XKW6syBz43CB for ; Thu, 8 Oct 2020 13:36:15 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x32b.google.com with SMTP id 13so6507555wmf.0 for ; Thu, 08 Oct 2020 06:36:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=1c8rBlwQhZfIbMY6JPBPImTj5NiU7/q6AcmjSRgUBUI=; b=lXytGTIaL94DyrCxJ2FvMWrrXaVpJZYGY0yXrKhH5cfNUzkUtR2S40nvj8CrV5vtjo m3JfwntabslguokuumdxrmlDwfIQuIOYYb1CoG4rosuB/8VB37/CYbdGgtdibtIFqzsZ uU13G9vACtcYCgGG29xHGfxOKHo4DRb9UYwk/WGvZRX5pBnjNB8fbn9S8IC8t6vDP6n0 cQByrJ4t5INtiz4jdtxtCTC2YWlU8P450h8wtmKWOK2VJxe+jK6pxhmJZxk55g2G8Esz Bnydxhovh3zoAM60gWCSFM7/LT2NBtKnniHSjrty84swxPa0f/PnlgEDGsRPpfO+gWSj 6cgw== X-Gm-Message-State: AOAM5326bYcI/nAMV0GOIn3TnkithV4VHN8rxDFVGSL0QgG8fmuSddmP Fo5ic3OfwXOY1umU+wXmIXyFpUb8P4Q= X-Google-Smtp-Source: ABdhPJxunCW5972Bjuk79nXBaVefxa15K//uQgrBvPB02fOdj4UZ5V/FDZAd48W0jYDLwgcK2LBnjQ== X-Received: by 2002:a7b:c18d:: with SMTP id y13mr1424119wmi.120.1602163672203; Thu, 08 Oct 2020 06:27:52 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-104-010.46.114.pool.telefonica.de. [46.114.104.10]) by smtp.googlemail.com with ESMTPSA id o14sm7108652wmc.36.2020.10.08.06.27.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Oct 2020 06:27:51 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Date: Thu, 8 Oct 2020 15:27:49 +0200 References: To: Mark Millard , freebsd-arm@freebsd.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C6XKW6syBz43CB X-Spamd-Bar: +++++++ X-Spamd-Result: default: False [7.94 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,body]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(0.00)[googlemail.com,quarantine]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[46.114.104.10:received]; R_DKIM_ALLOW(0.00)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.104.10:received]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.57)[0.569]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(0.85)[0.848]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.02)[1.020]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32b:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-Spam: Yes 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: Thu, 08 Oct 2020 13:36:16 -0000 > Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm = : >=20 >=20 > The old u-boot/DTB combination in use does not have emmc2bus. > And, even if it did, FreeBSD would not use =E2=80=A6=E2=80=A6=E2=80=A6. =E2=80=A6 and the new 2020.10- combinations will even be more = annoying=E2=80=A6 While I meanwhile e.g. could boot the 4GB off of xhci, it hangs in = DeviceTree, Depending on GUESSED ;-) combinations and DeviceTree-patches in src . There have to be necessary adjustments which are even not yet = upstreamed in u-boot=20 (depending on hw-revisions)=E2=80=A6and so on ... I doubt that anyone really will take explicitly time consuming care of = all that annoying RPI4-crap. I don't see any other way than targeting minimum 1 developer(better = more) ONLY to the RPI-platform=20 for a time period=E2=80=A6 other than leaving it crappy as is and to be = happy that it nevertheless=20 is a working fbsd-gadget :-) From owner-freebsd-arm@freebsd.org Thu Oct 8 16:33:59 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 21A8F42B7D5 for ; Thu, 8 Oct 2020 16:33:59 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6cGb07kZz4DRY for ; Thu, 8 Oct 2020 16:33:59 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id D788121B31 for ; Thu, 8 Oct 2020 16:33:58 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f170.google.com with SMTP id 188so7591470qkk.12 for ; Thu, 08 Oct 2020 09:33:58 -0700 (PDT) X-Gm-Message-State: AOAM531B4ukglw5xIZp/ldCS26lpo3GpBheG4eoSefMLCM+JaJR+JC4e kt190XIaLKVFRaFJhnnZEMbIyQ0zfjG5AwPEzRQ= X-Google-Smtp-Source: ABdhPJzm0dDqvk9lkuxPlpnjkpihHSo518xRINAJnMfbQBLAGLs/aB+kTQoysjYti7mgwLf3JTj+OT1ycopx1CYmx8g= X-Received: by 2002:a05:620a:136e:: with SMTP id d14mr8964930qkl.430.1602174838449; Thu, 08 Oct 2020 09:33:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Thu, 8 Oct 2020 11:33:45 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) To: Mark Millard Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" 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: Thu, 08 Oct 2020 16:33:59 -0000 On Thu, Oct 8, 2020 at 4:01 AM Mark Millard via freebsd-arm wrote: > > sys/gnu/dts/arm/bcm2711.dtsi reports: > > /* > * emmc2 has different DMA constraints based on SoC revisions. It was > * moved into its own bus, so as for RPi4's firmware to update them. > * The firmware will find whether the emmc2bus alias is defined, and if > * so, it'll edit the dma-ranges property below accordingly. > */ > [... snip ...] I have no words for how annoying this is. Thanks, Kyle Evans From owner-freebsd-arm@freebsd.org Thu Oct 8 17:38:29 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 8AFFE42CCCA for ; Thu, 8 Oct 2020 17:38:29 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6dj12pt1z4H3c for ; Thu, 8 Oct 2020 17:38:29 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 3FB8D222D2 for ; Thu, 8 Oct 2020 17:38:29 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f46.google.com with SMTP id j3so3461455qvi.7 for ; Thu, 08 Oct 2020 10:38:29 -0700 (PDT) X-Gm-Message-State: AOAM5301Du2t6k0a88F2ZjHXVHlAtvxl6t02vNgmgPtlY7hvzAE+qcd2 vAf92kSdcNvSqt+81JtB3rshkyxSDfeYfOwAexE= X-Received: by 2002:ad4:41c4:: with SMTP id a4mt9080744qvq.60.1602178708787; Thu, 08 Oct 2020 10:38:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Thu, 8 Oct 2020 12:38:15 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Cc: Mark Millard , freebsd-arm Content-Type: text/plain; charset="UTF-8" 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: Thu, 08 Oct 2020 17:38:29 -0000 On Thu, Oct 8, 2020 at 11:33 AM Kyle Evans wrote: > > On Thu, Oct 8, 2020 at 4:01 AM Mark Millard via freebsd-arm > wrote: > > > > sys/gnu/dts/arm/bcm2711.dtsi reports: > > > > /* > > * emmc2 has different DMA constraints based on SoC revisions. It was > > * moved into its own bus, so as for RPi4's firmware to update them. > > * The firmware will find whether the emmc2bus alias is defined, and if > > * so, it'll edit the dma-ranges property below accordingly. > > */ > > [... snip ...] > > I have no words for how annoying this is. > For a slightly more helpful response: We can fix this, and it ends up being much cleaner than my current hack. Basically, in bcm2835_vcbus.c, we should eradicate the busdma_lowaddr from bcm283x_memory_soc_cfg. bcm283x_dmabus_peripheral_lowaddr should instead take a device_t and grab the bus's dma-ranges. It /looks/ to be valid on all the DTS I see for the RPi boards we support, so we can just unconditionally use that and things will just work for the newer RPi4 models. >From my discussion (with an assist Ian on address interpretation) on IRC, so I don't forget: dma-ranges is three-value: We'll see 4 and 5 value variants of this because 64-bit addresses are described with pairs of 32-bit values. 4-value variant: dma_addr will be 32-bit, cpu_addr will be 64-bit 5-value variant: both are 64-bit Note that bcm283x_dmabus_peripheral_lowaddr() will be returning cpu_addr + (max_len - 1) This won't match perfectly with what we currently return, but it will be more accurate. Thanks, Kyle Evans From owner-freebsd-arm@freebsd.org Thu Oct 8 17:49:17 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 1E7EB42CA57 for ; Thu, 8 Oct 2020 17:49:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (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 4C6dxR4TSLz4Hjn for ; Thu, 8 Oct 2020 17:49:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: aMQY7IgVM1nDxfD_.2yX7917lsGoOR1X4VaGkJg4r0cs4hV8kP4G04p8yUo4nVx AZ.5vQRtN4hfLMXa478lfxkVfxd9zb_7PEWBQTb.Lzlnfb04pXiVheJeR38A5kL0xOlrCWYPYkR. sHP8iLW6y1yHeuha2WU1oJPs8PLLBQ8.uDXVDUtEeVm27f05GTRnnaWvv1juxeEzXZxWHhsYpEkg F4thB21BJD2vbBa4AUqwkag93DlkdwQgjePLSjIMVSXQgtTMFLpGARfe29ucQZoJu3XwaoQvkDwx L77iUgpOoAKot0Ygvii0.oApDzgcPOYOP4yepV5FcjbzHOjqeQSC.zL91ohELqgoohx7xYag0ZHJ YFrYLhNLr4Z5KOGNLDINOjNFphzq9AU8u2WxaE497LTL1d4hep_8p_i9EmBDn2kl.Irh_KvO91qH KIiZOgcgqIPh58sS3wC3tWCSPhQZQ_FDixMeKiHhh51hi3dzAwcnMhKkVfhGwjCzDtCXPQcjeBvm va9OeqA5AwL.q2ClbTB.d0kSZxlGNF40TyDkp3vdztZ5TCMCScmdxs5wWLFZGE1EiKzF6x4oQI8n TcpgSt_0czuD0BiE91hTp9ugMeYfmCx1bXgLFgi7Pym8eNZrpzU0qBVJMzKJ8TesHN82RK85Lnd0 .rlxMv_gOIbZ3P5P7uZrRSTthOwTCq7BzefVtyKQrDUHtjcTM_8eDRQ_wHr_SFispdZ1NwMwfx5W YmkuVnZx0DoeL3iSoYOt3iyKKOo5_GZfle7HPmbF65c7lL.OF8TdXbaEF8Mpiw1UEW.5xmvM_oFR 9U6GqxxcaEo2rCBRYsw9mBfcvoRkWe7nI4T0O22qMnc0Y.tSvsR8CfeCt8mQ8P0jiTpz8mwDuKgj CKLSGfP2MIEQpDVWYTLYmrSzp1es2clbQAEdx8H1fGkhDu7pvnaxavWbzSN9RncT.8lKkaihbo9x bo5vvHRdaC80IifSCf3dpfT5ah6rKgXbUA9UxzG6b2vFjtnc143K3dfUKy4qQAcFtHpB331dCzZr m9iT3Vi3rKHpK3dobdN212tRhphsHjjjRKqVP0CGC6eNPG5et4hmRZKuzqNl3GmMa_KEfDsoyzsy dFyHqHx6BE_fVUgY9H.E8t0r6CMqkIFcJbFMzNvTPgbYLGnIqylyyPED7Z3V3Rcm7QbIyqDxKCPw _7G.es3oo997CIfTH2.g9Q2t6lbf6sBjPGe.h6yeb_WQ6OuAd9WRlm20PNeQgqpAVfVtR7MfRz14 CDC._Ua7WP_5G1nyeo4u5SvOG6o.hlySuMeHYNu38_oPTiSo6AVZS8mXAvc8JC0.KKxWPR3dTLW_ 78LiacDZTRo5ILzlLP.y2l0Wf8ERb2ma9dO86pNkZfXFqWQgA5qwSE4XnaF4.CX60qBfj0EMZDTL OVTq28.zJ.Sinx2DltTq9DDWvw.RyEMvMlMpdYeUHBdL0T3v3vJXxkThmFDVIm76BRuY28ihAd1q 9gbYnkFnnjZu5o7JJ9PJtn3MbRLjTRCVy.WJ_6X7W5Xn1XKsqi.upEacD3.vOv82ALYUd9x2QsVW naA22rGRY94nhGTXGXRzWZzys.LOyEnA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Oct 2020 17:49:13 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f4bf89125f1cf769690216262f4b4278; Thu, 08 Oct 2020 17:49:12 +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: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: Date: Thu, 8 Oct 2020 10:49:11 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kyle Evans X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C6dxR4TSLz4Hjn X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.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:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.53)[-0.533]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.02)[-1.015]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.995]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; 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: Thu, 08 Oct 2020 17:49:17 -0000 On 2020-Oct-8, at 09:33, Kyle Evans wrote: > On Thu, Oct 8, 2020 at 4:01 AM Mark Millard via freebsd-arm > wrote: >>=20 >> sys/gnu/dts/arm/bcm2711.dtsi reports: >>=20 >> /* >> * emmc2 has different DMA constraints based on SoC revisions. = It was >> * moved into its own bus, so as for RPi4's firmware to update = them. >> * The firmware will find whether the emmc2bus alias is = defined, and if >> * so, it'll edit the dma-ranges property below accordingly. >> */ >> [... snip ...] >=20 > I have no words for how annoying this is. The linux kernel drivers/pci/controller/pcie-brcmstb.c has a comment mentioning another dynamic edit of dma-ranges for the RPi4, suggesting that there is or will be revisions that do not have the 3 GiByte PCIe oddity. The following is a code-comment from:=20 = https://elixir.bootlin.com/linux/v5.8.14/source/drivers/pci/controller/pci= e-brcmstb.c#L646 * We validate the inbound memory view even though we should = trust * whatever the device-tree provides. This is because of an HW = issue on * early Raspberry Pi 4's revisions (bcm2711). It turns out its * firmware has to dynamically edit dma-ranges due to a bug on = the * PCIe controller integration, which prohibits any access above = the * lower 3GB of memory. Given this, we decided to keep the = dma-ranges * in check, avoiding hard to debug device-tree related issues = in the * future: * * The PCIe host controller by design must set the inbound = viewport to * be a contiguous arrangement of all of the system's memory. = In * addition, its size mut be a power of two. To further = complicate * matters, the viewport must start on a pcie-address that is = aligned * on a multiple of its size. If a portion of the viewport does = not * represent system memory -- e.g. 3GB of memory requires a 4GB * viewport -- we can map the outbound memory in or after 3GB = and even * though the viewport will overlap the outbound memory the = controller * will know to send outbound memory downstream and everything = else * upstream. * * For example: * * - The best-case scenario, memory up to 3GB, is to place the = inbound * region in the first 4GB of pcie-space, as some legacy = devices can * only address 32bits. We would also like to put the MSI = under 4GB * as well, since some devices require a 32bit MSI target = address. * * - If the system memory is 4GB or larger we cannot start the = inbound * region at location 0 (since we have to allow some space for * outbound memory @ 3GB). So instead it will start at the 1x * multiple of its size =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Oct 8 18:34:26 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 1F5D042E973 for ; Thu, 8 Oct 2020 18:34:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6fxZ01Fkz4Mv5 for ; Thu, 8 Oct 2020 18:34:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id D41DF23487 for ; Thu, 8 Oct 2020 18:34:25 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-vk1-f181.google.com with SMTP id r78so1528872vke.11 for ; Thu, 08 Oct 2020 11:34:25 -0700 (PDT) X-Gm-Message-State: AOAM532NiA5CxpWwWV1wnjjTCX0uWn92ZLz+VJgG3ymvo/Uf/Vj1r0uv gQGTozosM5YBCRd+Hj+vcLLlPMQOPV5BzlblMLg= X-Received: by 2002:a1f:9381:: with SMTP id v123mt5786081vkd.20.1602182065425; Thu, 08 Oct 2020 11:34:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Thu, 8 Oct 2020 13:34:12 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Cc: Mark Millard , freebsd-arm Content-Type: text/plain; charset="UTF-8" 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: Thu, 08 Oct 2020 18:34:26 -0000 On Thu, Oct 8, 2020 at 12:38 PM Kyle Evans wrote: > > On Thu, Oct 8, 2020 at 11:33 AM Kyle Evans wrote: > > > > On Thu, Oct 8, 2020 at 4:01 AM Mark Millard via freebsd-arm > > wrote: > > > > > > sys/gnu/dts/arm/bcm2711.dtsi reports: > > > > > > /* > > > * emmc2 has different DMA constraints based on SoC revisions. It was > > > * moved into its own bus, so as for RPi4's firmware to update them. > > > * The firmware will find whether the emmc2bus alias is defined, and if > > > * so, it'll edit the dma-ranges property below accordingly. > > > */ > > > [... snip ...] > > > > I have no words for how annoying this is. > > > > For a slightly more helpful response: > > We can fix this, and it ends up being much cleaner than my current > hack. Basically, in bcm2835_vcbus.c, we should eradicate the > busdma_lowaddr from bcm283x_memory_soc_cfg. > > bcm283x_dmabus_peripheral_lowaddr should instead take a device_t and > grab the bus's dma-ranges. It /looks/ to be valid on all the DTS I see > for the RPi boards we support, so we can just unconditionally use that > and things will just work for the newer RPi4 models. > > From my discussion (with an assist Ian on address interpretation) on > IRC, so I don't forget: > > dma-ranges is three-value: > > We'll see 4 and 5 value variants of this because 64-bit addresses are > described with pairs of 32-bit values. > > 4-value variant: dma_addr will be 32-bit, cpu_addr will be 64-bit > 5-value variant: both are 64-bit > > Note that bcm283x_dmabus_peripheral_lowaddr() will be returning > cpu_addr + (max_len - 1) > > This won't match perfectly with what we currently return, but it will > be more accurate. Here's a patch that I hacked out and can't test for quite a while yet, feel free to give it a shot: https://people.freebsd.org/~kevans/bcm2835_vcbus.diff -- the best guarantee I can give you is that it builds. We'll need to test it on both RPi4 models with the separate bus and the original RPi4s, as well as an RPi3 and RPi2/0w. Thanks, Kyle Evans From owner-freebsd-arm@freebsd.org Thu Oct 8 19:06:28 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 7F5EB42F2B4 for ; Thu, 8 Oct 2020 19:06:28 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6gfX266Lz4NsG for ; Thu, 8 Oct 2020 19:06:28 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.nyi.freebsd.org (Postfix) id 4845142F1F4; Thu, 8 Oct 2020 19:06:28 +0000 (UTC) Delivered-To: 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 47FC942EFEE; Thu, 8 Oct 2020 19:06:28 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6gfV62fGz4NsF; Thu, 8 Oct 2020 19:06:26 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 098J6LH0031449 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Oct 2020 12:06:21 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 098J6LuJ031447; Thu, 8 Oct 2020 12:06:21 -0700 (PDT) (envelope-from jmg) Date: Thu, 8 Oct 2020 12:06:21 -0700 From: John-Mark Gurney To: current@FreeBSD.org, arm@FreeBSD.org Subject: RFC: allow first boot config from msdos partition Message-ID: <20201008190621.GW4213@funkthat.com> Mail-Followup-To: current@FreeBSD.org, arm@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 08 Oct 2020 12:06:21 -0700 (PDT) X-Rspamd-Queue-Id: 4C6gfV62fGz4NsF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [0.96 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.37)[0.367]; NEURAL_HAM_LONG(-0.42)[-0.422]; NEURAL_HAM_MEDIUM(-0.19)[-0.187]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[current,arm]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 08 Oct 2020 19:06:28 -0000 Hello, I've had the idea that it'd be nice to allow more first boot configuration of our ARM images from the FAT partition. The machine I normally use is a MacOSX box, so when writing images, it isn't easy to put an rc.conf on the image. This change imports configinit from cperciva's ec2-scripts (one minor tweak to make it better), and creates an fs_configinit script that reads the config.init file from /boot/msdos and passes it through configinit. This will allow first boot config, like setting a static IP, installing packages at first boot making it easier to get a system functional. It also means that if you have a simple appliance, if you package your config as a config.init script, it's easier to upgrade and test FreeBSD snapshots and releases than it was previous. I've written the man pages. If there is anything that isn't clear or missing, please let me know. The changes are in here: https://reviews.freebsd.org/D26713 Thanks! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Thu Oct 8 19:28:30 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 267D242FF12 for ; Thu, 8 Oct 2020 19:28:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4C6h7x1vMVz4Q3D for ; Thu, 8 Oct 2020 19:28:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: k3QzSmUVM1kOy9MHBa.xyak_GpBopaC82cTFMGWYGX6O3vLXh3Qx0FozAkj0mn7 840Y5yucg9QW0EFhxriWNUt_qTWFhHzrGFgnTxrE6UvgWjyRdxWa80XU.84d1fO1UUnI69FIibKn NXmBTnRMuoFcxo9JJ.GPSPqWdcmCwqlrY09Qvc25Bb9rRKhIKQwxqs1CDigEk2xH1OP4eU75GPBP mhzjpCFX1GfHBT8WiJxAI_hdtjJfY.KHkl2r3_Ph1eA6kUYzdIeA2dVji4LeRbx7ZBps37.XO4JI _cyRsVTTuqt91GH5PSNWcX29WZsiZigjIddT5dRZCFBYlXApDD1ingK.ynL3aQJjBWLf85VFNT6Q PO4GAWgjpvh.LUPwxPzpWVOjHX5b_8eCNhPZrAq0inqDyzNIWXy6fOAql1blRZaRDQg.L3RqY5Jr PkatB4k0i9ji_8zhqLqSWDWBkvgjMmb3q3IY4jN5kg.e4EjUmn68ax1h3hyf.SshIPXkt2k4xkuh 4Qc7kFIuxKb5WhY29AVju2hI6kpZMw3cqVrHMcylN7mtyuhoWiE_6.xI1P1D8iUvtcL_6JPBUO7E KTqqrq6t6y4OL3XzlTiSMvu98GZRlZNgYQJqI7iLkYQ4VVvoYV1Iv7SdXL3VuMHd.MwYLbgb5pTt AyGGQv9nQ1a0HHM1osMQRI1I793T7CT66XHOptQdzY0Zr1Z2O097iuYOWt.ZuBux4yRHz7s.96.E 7fOTR6IoYl9qJdhIZ39iIksZpR10WYbUdSxSvfTiMicvdLkPa05nl16u1LOWcVE377fRycCrYV5z 0ZJzUADAdt.BQtbAUlEZ4DLr8SkM43QbXj2IRrth0Hacc2Qoe_ul55VXaofiRWDZwpKhFohOHEdd xgv4vGi7IWithRyYopjsx6ChOX8ikFTohSN8Gtq_xGWNLapsa6BeQM9K2A7C.lQgzp78R3S6v0D6 5q8u.ezcd.nTu8lKmSF1e_C9Xi88m058ayhVwIXFt5K.XHhp.yIXYDwbktzhhqSKLCLBSML1pZR6 Jh6iNxCQeS.FvV7enz_nTYPDNpVDXOHt3mNqzoG7tpUL59YvV5IqzEgIFo.Bh.MdMm6cVZH.Rdvt Bqii17sqwSC6l_1FN3u5NIdqXbLxQs2uZVT2oxmE66GUMxs_6E2W2SMA.BzXiSm5fSR6Tp1f1PbM k9QiZEG1QiJqj5.fIbf8tT.uWl7BH3xQFtrAERm4Ly5MapHKBtch9s72MzsUHlo852rgRBhK6Q2R yWUkEE_jmqLUy3ZsInDi0LMeTFkJ_MDa37jCeTD5JzUHuRQzdKzeSQJ.bFecWItCje7h8p44.F3q cclVGeWS59.nN3TdocMvGRK1t6jSzR9AlYxnhNuInGkrZRF4Oex7HruYCt3BA8_ZzwnoQpf8alJg B1ODNxHgQZzWjEf54hA0a8YUXYfZc9.aM3tIuYdCo9apWbtFCBaJ6_RpRirndZS0U1RiRBC6pOIz 9dccojyz9Og4umB5H7ZzFWLFIZEM5KGhK_qjbFNxagqj1dd1CMXga9hi.WgPGxcItlPljcMvR3RU - Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Oct 2020 19:28:26 +0000 Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8e9dce392d602179e56e43acb544c061; Thu, 08 Oct 2020 19:28:23 +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: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: Date: Thu, 8 Oct 2020 12:28:21 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <32A8A046-56DF-4998-9C3D-8630ACCE4951@yahoo.com> References: To: Kyle Evans X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C6h7x1vMVz4Q3D X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.81 / 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:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.30)[-1.299]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.02)[-1.015]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; 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: Thu, 08 Oct 2020 19:28:30 -0000 On 2020-Oct-8, at 11:34, Kyle Evans wrote: > On Thu, Oct 8, 2020 at 12:38 PM Kyle Evans wrote: >>=20 >> On Thu, Oct 8, 2020 at 11:33 AM Kyle Evans = wrote: >>>=20 >>> On Thu, Oct 8, 2020 at 4:01 AM Mark Millard via freebsd-arm >>> wrote: >>>>=20 >>>> sys/gnu/dts/arm/bcm2711.dtsi reports: >>>>=20 >>>> /* >>>> * emmc2 has different DMA constraints based on SoC = revisions. It was >>>> * moved into its own bus, so as for RPi4's firmware to = update them. >>>> * The firmware will find whether the emmc2bus alias is = defined, and if >>>> * so, it'll edit the dma-ranges property below accordingly. >>>> */ >>>> [... snip ...] >>>=20 >>> I have no words for how annoying this is. >>>=20 >>=20 >> For a slightly more helpful response: >>=20 >> We can fix this, and it ends up being much cleaner than my current >> hack. Basically, in bcm2835_vcbus.c, we should eradicate the >> busdma_lowaddr from bcm283x_memory_soc_cfg. >>=20 >> bcm283x_dmabus_peripheral_lowaddr should instead take a device_t and >> grab the bus's dma-ranges. It /looks/ to be valid on all the DTS I = see >> for the RPi boards we support, so we can just unconditionally use = that >> and things will just work for the newer RPi4 models. >>=20 >> =46rom my discussion (with an assist Ian on address interpretation) = on >> IRC, so I don't forget: >>=20 >> dma-ranges is three-value: Note: For the below I looked at 3 separate RPi4B examples, using u-boot print fdt / when I could or translating the dtb to a dts otherwise. One of the examples is from one of ubuntu 2020.04.1's RPi4B specific builds. The others I use with FreeBSD, one for u-boot and one for uefi/ACPI. ( cpu_addr is sized via the global: / { #address-cells =3D <0x2>; and the dma_addr and max_len by more local definitions, such as in: #address-cells =3D <0x1>; #size-cells =3D <0x1>; compatible =3D "simple-bus"; dma-ranges =3D <0xc0000000 0x0 0x0 0x40000000>; and: #address-cells =3D <0x2>; #size-cells =3D <0x2>; compatible =3D "simple-bus"; dma-ranges =3D <0x0 0x0 0x0 0x0 0x4 0x0>; Note that the above has #size-cells varying when: 4 <=3D number of cells in dma-range . There will be worse cases later, below. and: #address-cells =3D <0x3>; #interrupt-cells =3D <0x1>; #size-cells =3D <0x2>; . . . dma-ranges =3D <0x2000000 0x0 0x0 0x0 0x0 0x0 = 0xc0000000>; (The #address-cells being 3 indicates a bit mask as the first of the 3, the bit mask indicating extra information about the context.) and: #address-cells =3D <0x2>; #size-cells =3D <0x1>; compatible =3D "simple-bus"; dma-ranges =3D <0x0 0xc0000000 0x0 0x0 0x40000000>; and: #address-cells =3D <0x1>; #size-cells =3D <0x2>; compatible =3D "simple-bus"; dma-ranges =3D <0x0 0x0 0x0 0x4 0x0>; Note that for the last 2 examples above the number of cells in the dma-range (5) is not sufficient to indicate the value for #size-cells or #(dma-addr-cells) without presuming some other context to disambiguate. There is also an example of just: dma-ranges; (in firmware { . . . }). >> We'll see 4 and 5 value variants of this because 64-bit addresses are >> described with pairs of 32-bit values. >>=20 >> 4-value variant: dma_addr will be 32-bit, cpu_addr will be 64-bit >> 5-value variant: both are 64-bit There is an example shown above with 5-value having #size_cells being 1 (32-bit) [and dma-addr being 64 bit (cells 2)] instead of #size_cells being 2 (64-bit) [and dma_addr being 32-bit (cells 1)]. >> Note that bcm283x_dmabus_peripheral_lowaddr() will be returning >> cpu_addr + (max_len - 1) >>=20 >> This won't match perfectly with what we currently return, but it will >> be more accurate. >=20 > Here's a patch that I hacked out and can't test for quite a while yet, > feel free to give it a shot: > https://people.freebsd.org/~kevans/bcm2835_vcbus.diff -- the best > guarantee I can give you is that it builds. We'll need to test it on > both RPi4 models with the separate bus and the original RPi4s, as well > as an RPi3 and RPi2/0w. See above about trying to use the number of cells in a dma-ranges to figure out the sizes of #size-cells or #(dma-addr-cells). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Oct 8 19:32:23 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 DA60F42FEE0 for ; Thu, 8 Oct 2020 19:32:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6hDR5Rr0z4QjZ for ; Thu, 8 Oct 2020 19:32:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 9EC1422ACD for ; Thu, 8 Oct 2020 19:32:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f42.google.com with SMTP id de3so3653196qvb.5 for ; Thu, 08 Oct 2020 12:32:23 -0700 (PDT) X-Gm-Message-State: AOAM530jPNZtFnrRCh6IseBXvPsJOvX5tfYo9ieG2oRegSEGiAcfRST2 pnVviQJxnZ/2hsH+6au7SnXIjHmkfQlBAtCsDAE= X-Google-Smtp-Source: ABdhPJw3xcwvIjrh890VMXEmS5u63butq6qUz/d/gGykMp47qVra/dgeu+QjRgDePyvHsqO/kET0B4eKj69Eh0BKfiM= X-Received: by 2002:a0c:c709:: with SMTP id w9mr9378437qvi.26.1602185543058; Thu, 08 Oct 2020 12:32:23 -0700 (PDT) MIME-Version: 1.0 References: <32A8A046-56DF-4998-9C3D-8630ACCE4951@yahoo.com> In-Reply-To: <32A8A046-56DF-4998-9C3D-8630ACCE4951@yahoo.com> From: Kyle Evans Date: Thu, 8 Oct 2020 14:32:09 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) To: Mark Millard Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" 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: Thu, 08 Oct 2020 19:32:23 -0000 On Thu, Oct 8, 2020 at 2:28 PM Mark Millard wrote: > > > > On 2020-Oct-8, at 11:34, Kyle Evans wrote: > > > On Thu, Oct 8, 2020 at 12:38 PM Kyle Evans wrote: > >> > >> On Thu, Oct 8, 2020 at 11:33 AM Kyle Evans wrote: > >>> > >>> On Thu, Oct 8, 2020 at 4:01 AM Mark Millard via freebsd-arm > >>> wrote: > >>>> > >>>> sys/gnu/dts/arm/bcm2711.dtsi reports: > >>>> > >>>> /* > >>>> * emmc2 has different DMA constraints based on SoC revisions. It was > >>>> * moved into its own bus, so as for RPi4's firmware to update them. > >>>> * The firmware will find whether the emmc2bus alias is defined, and if > >>>> * so, it'll edit the dma-ranges property below accordingly. > >>>> */ > >>>> [... snip ...] > >>> > >>> I have no words for how annoying this is. > >>> > >> > >> For a slightly more helpful response: > >> > >> We can fix this, and it ends up being much cleaner than my current > >> hack. Basically, in bcm2835_vcbus.c, we should eradicate the > >> busdma_lowaddr from bcm283x_memory_soc_cfg. > >> > >> bcm283x_dmabus_peripheral_lowaddr should instead take a device_t and > >> grab the bus's dma-ranges. It /looks/ to be valid on all the DTS I see > >> for the RPi boards we support, so we can just unconditionally use that > >> and things will just work for the newer RPi4 models. > >> > >> From my discussion (with an assist Ian on address interpretation) on > >> IRC, so I don't forget: > >> > >> dma-ranges is three-value: > > Note: For the below I looked at 3 separate RPi4B > examples, using u-boot print fdt / when I could > or translating the dtb to a dts otherwise. One > of the examples is from one of ubuntu 2020.04.1's > RPi4B specific builds. The others I use with FreeBSD, > one for u-boot and one for uefi/ACPI. > > ( > > cpu_addr is sized via the global: > > / { > > #address-cells = <0x2>; > > and the dma_addr and max_len by more local definitions, > such as in: > > #address-cells = <0x1>; > #size-cells = <0x1>; > compatible = "simple-bus"; > dma-ranges = <0xc0000000 0x0 0x0 0x40000000>; > > and: > > #address-cells = <0x2>; > #size-cells = <0x2>; > compatible = "simple-bus"; > dma-ranges = <0x0 0x0 0x0 0x0 0x4 0x0>; > > Note that the above has #size-cells varying when: > 4 <= number of cells in dma-range . There will be > worse cases later, below. > > and: > > #address-cells = <0x3>; > #interrupt-cells = <0x1>; > #size-cells = <0x2>; > . . . > dma-ranges = <0x2000000 0x0 0x0 0x0 0x0 0x0 0xc0000000>; > > (The #address-cells being 3 indicates a bit mask as the first of the 3, > the bit mask indicating extra information about the context.) > > and: > > #address-cells = <0x2>; > #size-cells = <0x1>; > compatible = "simple-bus"; > dma-ranges = <0x0 0xc0000000 0x0 0x0 0x40000000>; > > and: > > #address-cells = <0x1>; > #size-cells = <0x2>; > compatible = "simple-bus"; > dma-ranges = <0x0 0x0 0x0 0x4 0x0>; > > Note that for the last 2 examples above the number of cells > in the dma-range (5) is not sufficient to indicate the value > for #size-cells or #(dma-addr-cells) without presuming some > other context to disambiguate. > > > There is also an example of just: > > dma-ranges; > > (in firmware { . . . }). > > >> We'll see 4 and 5 value variants of this because 64-bit addresses are > >> described with pairs of 32-bit values. > >> > >> 4-value variant: dma_addr will be 32-bit, cpu_addr will be 64-bit > >> 5-value variant: both are 64-bit > > There is an example shown above with 5-value having #size_cells > being 1 (32-bit) [and dma-addr being 64 bit (cells 2)] instead of > #size_cells being 2 (64-bit) [and dma_addr being 32-bit (cells 1)]. > > >> Note that bcm283x_dmabus_peripheral_lowaddr() will be returning > >> cpu_addr + (max_len - 1) > >> > >> This won't match perfectly with what we currently return, but it will > >> be more accurate. > > > > Here's a patch that I hacked out and can't test for quite a while yet, > > feel free to give it a shot: > > https://people.freebsd.org/~kevans/bcm2835_vcbus.diff -- the best > > guarantee I can give you is that it builds. We'll need to test it on > > both RPi4 models with the separate bus and the original RPi4s, as well > > as an RPi3 and RPi2/0w. > > See above about trying to use the number of cells in a dma-ranges > to figure out the sizes of #size-cells or #(dma-addr-cells). > Yeah, Ian pointed out just a little bit ago the way this should be done correctly. The hacky patch should at least get it correct enough for now, then I can write a more generic version of dma-ranges parsing that does it correctly. From owner-freebsd-arm@freebsd.org Thu Oct 8 20:15:58 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 C1E1743065E for ; Thu, 8 Oct 2020 20:15:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4C6jBk0C8Lz4S3v for ; Thu, 8 Oct 2020 20:15:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: EdkR.P4VM1nUD1iCyRX0ymaYGs4A9hEpPG4ALegNhqceXDtdbaib2wMBV6KIehV 3xZlE47HUVuc5HPBG585nB59IHmnHfREdTi6Qd6IjeWoBHvDYwnnTMkr2lGT314IHpqxDNAVMZCk MPChRyVM916xD9a7JPSydv_X9lPgWXFOqmkia7kL3o5HXUZ3agwN8R1u9nPs.GkXI52RIrHEm4HM 8TbnfYlrvsOWm9ITAZP3Bvd6uTfwencSDBI5Y1A0gp.pUuGVJUayxZif8Gbwp5DobmzLIpk5WdII QWwCkE9_Xs4bOm6ipFpsDzIbUbxzFxlGaj1GF0zYSF.K2gQrXYCtH5_qAzVK.lR5uMi_907xf8q6 IPCXBaNi3YibfmFbsuVakq2Ams2bGPy6U7o0LldPuootWwiICVMxEkAT09Ap4b13VIukLBeUzRBu b63w7WFpA4Kv7K.ii.28cikhqWqCPmezMExTCIpMWAvnM8UhgVjv3s.T0Tuz3PHelrcqMmEopnf0 xpFIrX6ajuM.2uJ23B2HYYOsgkoBbfuetBuSgr.EEmdgf4VB36KCCdW_SnSnceqC7btFcK0MbQJx nWw1eDx_pEFo7MSNN71IbanQhktwiurudS.A.dGx_l15NLTmjU4DRQr5MapGlKKKpu_1I91Ia4od 1IAYfxZH.x0pH8c_S4I6KjtEqw1v.9kYiSF4Q1rPOXdEq5S5Up78Zi8pFE8FhxkoUvzGzqHQrmBo 3eMuWiiV.LOBO6zvhaWQrAiZRoi78kJk8xiiqOGQojMs2ITqKQkc1eVT0.lfFpFMMw_lJk0eZbDF 0A1KDO41sYvmFFVDDPf.Yg_ky5lDnT5sox9uQHgjDcmaFz__yfi1v.YtW2w0Vh2hG1TUTe93Bzc8 TigsHsdcW94E_2KksiUohfV8tbHaPgSI0ZnsmNTzy3WighDn9GrMMrgJ3xi0T9p0dDPoT7XwTJ_5 1FhrzL25cgD3h5523XR1SXZy2wwxoSPudQgRJjvQNAjTzY3R1JwMcEF_lhCP87OIfJz70loIDIF1 ykqklODpcEIKV3BhGUJDU5GDPZsoU7dYneWjxbRF1K5g5a62NH.5erVpN9b1iMhMgZH4692yrBLA xtssSGPAk5RbA4OUtLw6xpxEXD.AuI.Q1uH5nrQ_OjT6UZnyDt_W9JMkVUqTyH4hItwpirXCIPQE AFJ99nYng8g0URW1kG3sg1LXkkQu3LDlSXJkg1734SWJzVGs3K6zyz4tRbsgk867c0bvT3OlP_Qt mFUL3_gPn6uxb3zPAmDkvkQqJ2UWDUawj8IOskutnh3xicRpzyDdeBKw61YWT_QdxB6ZXYC_zjeT qbHMRjSKucem_yReNKeaYFthp04JeKVzV95PKMMjgDdQufnFuFUhzVb1k5_UKYBGsgydcR1QiJxq U2XK1zGqLkvicaNqruzy_fMVpwwtR3lwWWUn9lCsGJdTo6UkTiDNj1rFHvxiVSt.s0vfDttl9._p EqReMeL8yJoOYWTZVfhdJlPNhOZ_1V8svSkurEygNZDLMFHZTEhbejvGJMx8o99cN_JZMiFOLiaf BqdsKrPYuyLGsSlOlneH.Z652BmTpz8FZpQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Oct 2020 20:15:55 +0000 Received: by smtp421.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d8cf9c361f163162fab13e90b38bce66; Thu, 08 Oct 2020 20:15:50 +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: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: Date: Thu, 8 Oct 2020 13:15:49 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <68AC0E4E-0469-46AE-BD68-058DCB6B078F@yahoo.com> References: <32A8A046-56DF-4998-9C3D-8630ACCE4951@yahoo.com> To: Kyle Evans X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C6jBk0C8Lz4S3v X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.67 / 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:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.16)[-1.161]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.02)[-1.015]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; 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: Thu, 08 Oct 2020 20:15:58 -0000 On 2020-Oct-8, at 12:32, Kyle Evans wrote: > On Thu, Oct 8, 2020 at 2:28 PM Mark Millard = wrote: >>=20 >>=20 >>=20 >> On 2020-Oct-8, at 11:34, Kyle Evans wrote: >>=20 >>> On Thu, Oct 8, 2020 at 12:38 PM Kyle Evans = wrote: >>>>=20 >>>> On Thu, Oct 8, 2020 at 11:33 AM Kyle Evans = wrote: >>>>>=20 >>>>> On Thu, Oct 8, 2020 at 4:01 AM Mark Millard via freebsd-arm >>>>> wrote: >>>>>>=20 >>>>>> sys/gnu/dts/arm/bcm2711.dtsi reports: >>>>>>=20 >>>>>> /* >>>>>> * emmc2 has different DMA constraints based on SoC = revisions. It was >>>>>> * moved into its own bus, so as for RPi4's firmware to = update them. >>>>>> * The firmware will find whether the emmc2bus alias is = defined, and if >>>>>> * so, it'll edit the dma-ranges property below = accordingly. >>>>>> */ >>>>>> [... snip ...] >>>>>=20 >>>>> I have no words for how annoying this is. >>>>>=20 >>>>=20 >>>> For a slightly more helpful response: >>>>=20 >>>> We can fix this, and it ends up being much cleaner than my current >>>> hack. Basically, in bcm2835_vcbus.c, we should eradicate the >>>> busdma_lowaddr from bcm283x_memory_soc_cfg. >>>>=20 >>>> bcm283x_dmabus_peripheral_lowaddr should instead take a device_t = and >>>> grab the bus's dma-ranges. It /looks/ to be valid on all the DTS I = see >>>> for the RPi boards we support, so we can just unconditionally use = that >>>> and things will just work for the newer RPi4 models. >>>>=20 >>>> =46rom my discussion (with an assist Ian on address interpretation) = on >>>> IRC, so I don't forget: >>>>=20 >>>> dma-ranges is three-value: >>=20 >> Note: For the below I looked at 3 separate RPi4B >> examples, using u-boot print fdt / when I could >> or translating the dtb to a dts otherwise. One >> of the examples is from one of ubuntu 2020.04.1's >> RPi4B specific builds. The others I use with FreeBSD, >> one for u-boot and one for uefi/ACPI. >>=20 >> ( >>=20 >> cpu_addr is sized via the global: >>=20 >> / { >>=20 >> #address-cells =3D <0x2>; >>=20 >> and the dma_addr and max_len by more local definitions, >> such as in: >>=20 >> #address-cells =3D <0x1>; >> #size-cells =3D <0x1>; >> compatible =3D "simple-bus"; >> dma-ranges =3D <0xc0000000 0x0 0x0 0x40000000>; >>=20 >> and: >>=20 >> #address-cells =3D <0x2>; >> #size-cells =3D <0x2>; >> compatible =3D "simple-bus"; >> dma-ranges =3D <0x0 0x0 0x0 0x0 0x4 0x0>; >>=20 >> Note that the above has #size-cells varying when: >> 4 <=3D number of cells in dma-range . There will be >> worse cases later, below. >>=20 >> and: >>=20 >> #address-cells =3D <0x3>; >> #interrupt-cells =3D <0x1>; >> #size-cells =3D <0x2>; >> . . . >> dma-ranges =3D <0x2000000 0x0 0x0 0x0 0x0 0x0 = 0xc0000000>; >>=20 >> (The #address-cells being 3 indicates a bit mask as the first of the = 3, >> the bit mask indicating extra information about the context.) >>=20 >> and: >>=20 >> #address-cells =3D <0x2>; >> #size-cells =3D <0x1>; >> compatible =3D "simple-bus"; >> dma-ranges =3D <0x0 0xc0000000 0x0 0x0 0x40000000>; >>=20 >> and: >>=20 >> #address-cells =3D <0x1>; >> #size-cells =3D <0x2>; >> compatible =3D "simple-bus"; >> dma-ranges =3D <0x0 0x0 0x0 0x4 0x0>; >>=20 >> Note that for the last 2 examples above the number of cells >> in the dma-range (5) is not sufficient to indicate the value >> for #size-cells or #(dma-addr-cells) without presuming some >> other context to disambiguate. >>=20 >>=20 >> There is also an example of just: >>=20 >> dma-ranges; >>=20 >> (in firmware { . . . }). >>=20 >>>> We'll see 4 and 5 value variants of this because 64-bit addresses = are >>>> described with pairs of 32-bit values. >>>>=20 >>>> 4-value variant: dma_addr will be 32-bit, cpu_addr will be 64-bit >>>> 5-value variant: both are 64-bit >>=20 >> There is an example shown above with 5-value having #size_cells >> being 1 (32-bit) [and dma-addr being 64 bit (cells 2)] instead of >> #size_cells being 2 (64-bit) [and dma_addr being 32-bit (cells 1)]. >>=20 >>>> Note that bcm283x_dmabus_peripheral_lowaddr() will be returning >>>> cpu_addr + (max_len - 1) >>>>=20 >>>> This won't match perfectly with what we currently return, but it = will >>>> be more accurate. >>>=20 >>> Here's a patch that I hacked out and can't test for quite a while = yet, >>> feel free to give it a shot: >>> https://people.freebsd.org/~kevans/bcm2835_vcbus.diff -- the best >>> guarantee I can give you is that it builds. We'll need to test it on >>> both RPi4 models with the separate bus and the original RPi4s, as = well >>> as an RPi3 and RPi2/0w. >>=20 >> See above about trying to use the number of cells in a dma-ranges >> to figure out the sizes of #size-cells or #(dma-addr-cells). >>=20 >=20 > Yeah, Ian pointed out just a little bit ago the way this should be > done correctly. The hacky patch should at least get it correct enough > for now, then I can write a more generic version of dma-ranges parsing > that does it correctly. Okay. Another type of overall issue (that may not apply to the specific context here) is dtb content like: scb { compatible =3D "simple-bus"; #address-cells =3D <0x00000002>; #size-cells =3D <0x00000002>; ranges =3D * 0x0000000007ef8a18 [0x00000060]; dma-ranges =3D <0x00000000 0x00000000 0x00000000 = 0x00000000 0x00000000 0xfc000000 0x00000001 0x00000000 0x00000001 = 0x00000000 0x00000001 0x00000000>; phandle =3D <0x000000d0>; pcie@7d500000 { compatible =3D "brcm,bcm2711-pcie"; . . . #address-cells =3D <0x00000003>; #interrupt-cells =3D <0x00000001>; #size-cells =3D <0x00000002>; . . . dma-ranges =3D <0x02000000 0x00000000 0x00000000 = 0x00000000 0x00000000 0x00000000 0xc0000000>; . . . }; . . . where the inner most dma-ranges is not from the just-surrounding context (parent) but is strictly local (despite the parent potentially also having dma-ranges). I think that only pcie@... is that way so far for the RPi4 --but notationally it seems to be generally allowed. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Oct 8 23:57:38 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 B5DDF434251 for ; Thu, 8 Oct 2020 23:57:38 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6p6T4pKpz4dLl for ; Thu, 8 Oct 2020 23:57:37 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-qt1-x82f.google.com with SMTP id g3so6639727qtq.10 for ; Thu, 08 Oct 2020 16:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0pJ4bSsVL9QLhFHIg1T5tMFdcE740KCMdaGv50oht20=; b=LKYqmy1yc3Fubo6ywV+bRN/l8J5vNFBztNCe77eiHqKwOSiZiqjZ9FDePNvvDr3VWE nu/0YgZUIZamxdNn+afoc+fcu76bo1BDYChc2daJmhOlFBKgGTVaUApiYUJSHtVVTKTl MoSNcU1ZFiEYFPVLYvHONAIJAfLVVRtFV8QSfEw8vnXp14sPGFVIoLNrfzXpQIS+C76u pe2Pv+uc+4MBp5MhGKW+1PEbfE4dMTSZrqNHNhhrT0i6NUIwVi2mOsmpN9qY+Ipq0vZB KaL3CA72RHkZSoraGcLoEYctICSKxQ0rFYZYvQKIr7o7ZZu93lW27F1KuqGN6JQRZkiv 8j/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0pJ4bSsVL9QLhFHIg1T5tMFdcE740KCMdaGv50oht20=; b=FfP5HhQzn9W0zopdGyFkzswIbkBFT7YiwdWsAyrg1QkLeKZd3jt4OlC1N87IrvZIve hvxJOJIoDMnGm+C4LJMGwFeYOaDzUqhmowm/z25RxeQcK5M/lr7THa/C8P8vw3KZVmni ium228njUKgrbdg7KKuSUBCtHMxPkUAvfAf+ZQWiMDXGkE5AH2fPzl9viZCE3c1HOqaP C8kQkoc5q2YpKFUeaJiGz3IQ+ugC1DbWjxRQrY2eRBiwFr5cOhz8u3TjDNcn/aFbto1u /1eGGNaZcIkDTB2C9PERxm4Zb2lgaSt3CpZk9lh0cEPcXk5EfLAm16BOfm3MVxbTouop U4SQ== X-Gm-Message-State: AOAM531iakG4O86er7i9+fBt28rCMj4VAQLYJ8OWUsiuglsD0zLiGJxG sRbIVgGcX403rn+75mgycT5RCYqWtWPaC8KxEzREL2j5WolY/A== X-Google-Smtp-Source: ABdhPJz42wMzb1z8BFDNgdUswFuiQyo+u6nA3JhI0hlDOx7HmiAYM73MO3hfCyz2ba/2ywGOm/beM4KMTNboW7AbRuo= X-Received: by 2002:aed:3f16:: with SMTP id p22mr11425481qtf.181.1602201456067; Thu, 08 Oct 2020 16:57:36 -0700 (PDT) MIME-Version: 1.0 From: Marcin Wojtas Date: Fri, 9 Oct 2020 01:57:22 +0200 Message-ID: Subject: ARMv7 without VFP To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4C6p6T4pKpz4dLl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20150623.gappssmtp.com header.s=20150623 header.b=LKYqmy1y; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2607:f8b0:4864:20::82f) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [-2.36 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[semihalf-com.20150623.gappssmtp.com:s=20150623]; FREEFALL_USER(0.00)[mw]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.991]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.76)[-0.764]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.30)[-0.302]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82f:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; 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: Thu, 08 Oct 2020 23:57:38 -0000 Hi, We have a CA9-based SoC that for some reason does not support the VFP and would like to run the OS on stable/12. Disabling the VFP in the kernel options (or adding the detection of the feature in runtime) seems to work fine, but it turned out the biggest obstacle is trying to force the userspace to use the softfloat libc callbacks (in theory soft-/hard- float usage should be resolved dynamically by linking the proper functions in libc - so far we found no way to compile it successfully though with the standard toolchain). Other approaches to hardcode the softfloat userspace have failed so far. Details can be found below. Is there any known way to compile the userspace that may work with the soft-float on armv7? Details: When booting without VFP there is a problem with almost every process receiving SIGILL signals. Core dumps and disassembly proved that the illegal instructions are associated with hardware FPU. The kernel seems to run fine otherwise. 1. When building world with option CPUTYPE=soft, libc cannot be linked properly due to lack of _aeabi* --- all_subdir_sbin --- ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_f2iz_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fadd_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmpeq_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmpge_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmpgt_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmple_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmplt_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmpun_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fdiv_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fmul_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fsub_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_i2f_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_d2f_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_d2iz_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_dadd_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_dcmpeq_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_dcmpge_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_dcmpgt_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_dcmple_vfp 2. According to imp@, the softfloat system can still be built, however it is not officially supported anymore (https://lists.freebsd.org/pipermail/freebsd-arch/2017-September/018329.html). It is assumed that armv6/armv7 CPUs always have VFP unit. 3. FreeBSD stable/12 world with CPUTYPE=soft is built automatically with -mfloat-abi=softfp, which emulates the soft float ABI, however still uses hard float instructions. 4. When trying to pass -mfloat-abi=soft, everything is built with three flags: -mfloat-abi=soft -mfloat-abi=softfp -mfloat-abi=softfp. 5. Additional problem encountered when trying to use additional flag -mfloat-abi=soft: --- clang.full --- /home/mindal/obj/arm.armv6/usr/home/mindal/git/freebsd-src/lib/clang/libclang/libclang.a: could not read symbols: File format not recognized c++: error: linker command failed with exit code 1 (use -v to see invocation) 6. Problems above seen on both stable/11 and stable/12. In case of stable/12 it is visible with both TARGET_ARCH=armv6 and TARGET_ARCH=armv7 I'd appreciate any feedback. Best regards, Marcin (mw@) From owner-freebsd-arm@freebsd.org Fri Oct 9 02:18:51 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 6609F436A36 for ; Fri, 9 Oct 2020 02:18:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6sFQ6Zfmz3WK7; Fri, 9 Oct 2020 02:18:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 0992It3t025070 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 8 Oct 2020 19:18:55 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 0992ItIv025069; Thu, 8 Oct 2020 19:18:55 -0700 (PDT) (envelope-from fbsd) Date: Thu, 8 Oct 2020 19:18:55 -0700 From: bob prohaska To: Kyle Evans Cc: freebsd-arm , bob prohaska Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Message-ID: <20201009021855.GA24977@www.zefox.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4C6sFQ6Zfmz3WK7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] 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: Fri, 09 Oct 2020 02:18:51 -0000 On Thu, Oct 08, 2020 at 01:34:12PM -0500, Kyle Evans wrote: > > Here's a patch that I hacked out and can't test for quite a while yet, > feel free to give it a shot: > https://people.freebsd.org/~kevans/bcm2835_vcbus.diff -- the best > guarantee I can give you is that it builds. We'll need to test it on > both RPi4 models with the separate bus and the original RPi4s, as well > as an RPi3 and RPi2/0w. > FWIW, a Pi3B running FreeBSD www.zefox.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r366466M: Thu Oct 8 17:18:55 PDT 2020 bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 seems to build, boot and run without immediate problems. A Pi2 running FreeBSD www.zefox.com 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692: Thu Oct 8 16:57:50 PDT 2020 bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM arm also built, booted and ran. Uptime so far is only a few minutes, but so far, so good. If the MMCCAM mismatch is significant let me know and I'll fix it. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Fri Oct 9 02:27:34 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 11CE6437225 for ; Fri, 9 Oct 2020 02:27:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6sRT6Wl1z3WTM for ; Fri, 9 Oct 2020 02:27:33 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id BD2EE26D00 for ; Fri, 9 Oct 2020 02:27:33 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f170.google.com with SMTP id 140so7461717qko.2 for ; Thu, 08 Oct 2020 19:27:33 -0700 (PDT) X-Gm-Message-State: AOAM530B7H8N8l3bhhJroOR+6jLKnqujmF+XTJcxjKk6ZiiLjqEREyuw ZzLQOrPoTEDUyUTb57p/qKqA2fAf1iL8eViTP2w= X-Google-Smtp-Source: ABdhPJxRznWJGQ+nYJTNaOPAzucKrF0zfy2eIW3CY+zdT+obPGhorIWzoFHaGgbBFpVcEiFW8qoPN+3+SJBevOBg28s= X-Received: by 2002:a05:620a:4fb:: with SMTP id b27mr11689948qkh.120.1602210453400; Thu, 08 Oct 2020 19:27:33 -0700 (PDT) MIME-Version: 1.0 References: <20201009021855.GA24977@www.zefox.net> In-Reply-To: <20201009021855.GA24977@www.zefox.net> From: Kyle Evans Date: Thu, 8 Oct 2020 21:27:22 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) To: bob prohaska Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" 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: Fri, 09 Oct 2020 02:27:34 -0000 On Thu, Oct 8, 2020 at 9:18 PM bob prohaska wrote: > > On Thu, Oct 08, 2020 at 01:34:12PM -0500, Kyle Evans wrote: > > > > Here's a patch that I hacked out and can't test for quite a while yet, > > feel free to give it a shot: > > https://people.freebsd.org/~kevans/bcm2835_vcbus.diff -- the best > > guarantee I can give you is that it builds. We'll need to test it on > > both RPi4 models with the separate bus and the original RPi4s, as well > > as an RPi3 and RPi2/0w. > > > > FWIW, a Pi3B running > FreeBSD www.zefox.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r366466M: Thu Oct 8 17:18:55 PDT 2020 bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 > > seems to build, boot and run without immediate problems. > > A Pi2 running > FreeBSD www.zefox.com 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692: Thu Oct 8 16:57:50 PDT 2020 bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM arm > > also built, booted and ran. > > Uptime so far is only a few minutes, but so far, so good. If the MMCCAM > mismatch is significant let me know and I'll fix it. > Thanks for testing! Can you also confirm the output of `dmesg | grep 'WARNING:'`, please? In particular, I'd like to know if you hit either of: WARNING: Improper peripheral attachment ... WARNING: bus for '...' missing dma-ranges MMCAM is fine; by the time you've gone multi-user it's definitely exercised the appropriate bits. Thanks, Kyle Evans From owner-freebsd-arm@freebsd.org Fri Oct 9 02:49:13 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 206494370FE for ; Fri, 9 Oct 2020 02:49:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6swS5H2Qz3X47; Fri, 9 Oct 2020 02:49:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 0992nOSj025133 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 8 Oct 2020 19:49:25 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 0992nOVq025132; Thu, 8 Oct 2020 19:49:24 -0700 (PDT) (envelope-from fbsd) Date: Thu, 8 Oct 2020 19:49:24 -0700 From: bob prohaska To: Kyle Evans Cc: freebsd-arm , bob prohaska Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Message-ID: <20201009024924.GB24977@www.zefox.net> References: <20201009021855.GA24977@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4C6swS5H2Qz3X47 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] 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: Fri, 09 Oct 2020 02:49:13 -0000 On Thu, Oct 08, 2020 at 09:27:22PM -0500, Kyle Evans wrote: > On Thu, Oct 8, 2020 at 9:18 PM bob prohaska wrote: > > > > On Thu, Oct 08, 2020 at 01:34:12PM -0500, Kyle Evans wrote: > > > > > > Here's a patch that I hacked out and can't test for quite a while yet, > > > feel free to give it a shot: > > > https://people.freebsd.org/~kevans/bcm2835_vcbus.diff -- the best > > > guarantee I can give you is that it builds. We'll need to test it on > > > both RPi4 models with the separate bus and the original RPi4s, as well > > > as an RPi3 and RPi2/0w. > > > > > > > FWIW, a Pi3B running > > FreeBSD www.zefox.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r366466M: Thu Oct 8 17:18:55 PDT 2020 bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 > > > > seems to build, boot and run without immediate problems. > > > > A Pi2 running > > FreeBSD www.zefox.com 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692: Thu Oct 8 16:57:50 PDT 2020 bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM arm > > > > also built, booted and ran. > > > > Uptime so far is only a few minutes, but so far, so good. If the MMCCAM > > mismatch is significant let me know and I'll fix it. > > > > Thanks for testing! > > Can you also confirm the output of `dmesg | grep 'WARNING:'`, please? > In particular, I'd like to know if you hit either of: > > WARNING: Improper peripheral attachment ... > WARNING: bus for '...' missing dma-ranges > On the Pi2 I see: bob@www:~ % dmesg | grep 'WARNING:' WARNING: WITNESS option enabled, expect reduced performance. WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD 13.0. WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0. WARNING: WITNESS option enabled, expect reduced performance. On the Pi3 I see: bob@www:~ % dmesg | grep 'WARNING:' WARNING: WITNESS option enabled, expect reduced performance. WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD 13.0. WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0. WARNING: WITNESS option enabled, expect reduced performance. so the answer seems to be "no". HTH, let me know if I can try anthing else. Both installs are expendable. bob prohaska From owner-freebsd-arm@freebsd.org Fri Oct 9 03:06:14 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 530CB437569 for ; Fri, 9 Oct 2020 03:06:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4C6tJ4533mz3Y54 for ; Fri, 9 Oct 2020 03:06:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GHITNSsVM1kV7K65b8m1yMKNZXWtvYz8OmvSejNHgE5xsJt2QFEliRMKVeMqeCf 8g5o9sYtYIKn5D_kEvG4ExeJv_.jY1HWjwG9lXjLOGPt38Mbv5udBJ3ygR7rSUC0QHKvIMQB9BD5 oZkRP86ymIF0EQ4o_TP4h0JbWLnK3mQxVB91HhLZHCufpySmGYQzNLDD1IvSafo9aFWjniGJLe3Z G1kNDMWuqIfYmAgmhgM.CzUYZXrPfoKkN4AVK.F3DzoA2_8BqnGoq8kn0_ZvL2jCugjgY1WjhCUF rfrYoj3gUhdXnhmtUO1p8p6Pj3uP1JGOgqy21mgC98MIb_o_.Rj03tNKagCCl.4DDnf7cRQ9c_kE lEq7QLI3gAmLFkZwIiEYlatrd.rPUoVOif1.lwbxN3F6R6OV4cBhmGYhJb1SvRp1c11kcvZn1AvL 8t6uHQPufRZwG8e8isVaua5ejx.JhiRQoFT2V51QYnHN0B.aZv4lBnl3oV5mOIBrv5ghuliXRJN5 b0z3E1coOTkeA9ONmbo_cDd9ET7JYcLxY2ob99Yu2DrUlp6FAhbMFtKMhIBNhtJR7x7wIt8l.kx5 Kx6zLnFVJWRCgYZYZlzQifu4DvPXpub0w6j5l34.SUpU2_QsiSp8e35rWVg5Qm74vp7z52l3lzC4 LTNm87dvCZfgRyU14EWhjReohfENdQJwAgl8_2Hz2cnJ8WePdNqKBSw_rDVMJg4u_lT2GjUD0ZP8 O8u9kJJJPM4rVVwrb8Z_9_hW8qEgpP4u.PbidTx_KriZbSF2HYP8y115gzEh6RavTF4cNkm3_blD hmEO70paFAJWOGm_mjTX2Qs7NuPExKK6OWyJU_mbXnuDHUEusaJT15wG5nFeO3rIqGDZ68rpfLXY VcZyElGFJHpPtVDI3GGGxHCjm3yLLgCiF7vaDGAh.4TaAArV6yJsuM4KhJVJsrpvH8aDCvW2T5Q_ lcEkRiElYy2JgB9mkO4WCEbNRVi0QSPmDgBAh2ZzXf0oGGgVRJrRb9ji7G2fTxdKKycHgF4xaCPN nc5blyL1OiREUpNzj3o9LRHLGjXvXmRUXl5vdSw8OABsa0G4KFk1qSTpEhF3f5SrrYOVn2v2MuZI cnDHMB0g_TSpDEwW2pMEpLPX3NGg_iTab6dgi1UT8tcL1OTpyWeRjjVAw2DSHyyXjNNhN7buG0Ws xpb4L8iouOhTqDy0LTm7tKjUIYS45aKJwMJQNVNGXg_cGzQtueLUjh8X9l5veU26O51.Lc36dgaK hUf1ePZ1z.jTMWONrgdJoMbz04h5r53Mtgcdc83zPFO7W185BixCp4Q2s316Wy.GYUnptAUNmG1w lxvzeS5KqzixcrYlpY6Can0ZXScLE5aut4QECVzk8_Jo_0uWzbL511CL7pTnr7aWrrGt8u4tYUpY hjGWMe9ycL44ZTdDV49sVlXDH0t9CUsV6PSTMh276Ca9na2WctOqXV8qBqNGbTq67bBtZglvvUOy OfIuc1vzYRqBi1ZooyWbT_nfVfxv82GBZeRu7ZL4hcx92SjUGsRWiTc2zgglXlZe8rtSOnHynlqa cNJFCdygdZDAU.4yHTaf6mdJ2FYa5QEOY Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 03:06:10 +0000 Received: by smtp402.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4c5e1221013ea399f20f915eb005f95a; Fri, 09 Oct 2020 03:06:07 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: Date: Thu, 8 Oct 2020 20:06:05 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> References: To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C6tJ4533mz3Y54 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.19 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.69)[-0.687]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.01)[-1.013]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.995]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; 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: Fri, 09 Oct 2020 03:06:14 -0000 On 2020-Oct-8, at 06:27, Klaus Cucinauomo = wrote: >> Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm = : >>=20 >>=20 >> The old u-boot/DTB combination in use does not have emmc2bus. >> And, even if it did, FreeBSD would not use =E2=80=A6=E2=80=A6=E2=80=A6.= >=20 > =E2=80=A6 and the new 2020.10- combinations will even be more = annoying=E2=80=A6 > While I meanwhile e.g. could boot the 4GB off of xhci, it hangs in = DeviceTree, > Depending on GUESSED ;-) combinations and DeviceTree-patches in src . > There have to be necessary adjustments which are even not yet = upstreamed in u-boot=20 > (depending on hw-revisions)=E2=80=A6and so on ... > I doubt that anyone really will take explicitly time consuming care of = all that annoying RPI4-crap. > I don't see any other way than targeting minimum 1 developer(better = more) ONLY to the RPI-platform=20 > for a time period=E2=80=A6 other than leaving it crappy as is and to = be happy that it nevertheless=20 > is a working fbsd-gadget :-) Summary of probable-cause finding: u-boot 2020.10 is expecting: compatible =3D "brcm,generic-xhci" instead of what seems to be in files that are in use by FreeBSD: compatible =3D "generic-xhci" (I've no clue what all the other differences in the .dtb file contents might be.) The details of what I learned that reached that status . . . I updated my ports environment on a RPi4 to build the final 2020.10 = u-boot for the RPi4. I then built it and replaced the u-boot.bin on the microsd card that I boot with via the FreeBSD kernel being from that microsd = card but later stages being from the USB3 SSD. I did not update anything = else. So: still an older .dtb file. That 8 GiByte RPi4B context booted just fine. I then rebooted and had it stop in u-boot and looked around just a = little bit. U-Boot 2020.10 (Oct 09 2020 - 00:51:29 +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03114) MMC: mmc@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found Hit any key to stop autoboot: 0=20 So it reproted the problem above. Yet . . . U-Boot> pci 0 Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x14e4 0x2711 Bridge device 0x04 U-Boot> pci 1 =20 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 01.00.00 0x1106 0x3483 Serial bus controller 0x03 So it does see the xHCI on the pci bus despite the "Bus xhci_pci: probe failed, error -110". -110 looks to be -ETIMEDOUT . Looking at the v2020.10/drivers/usb/host/xhci-pci.c source code shows that the xhci_pci driver has: . . . static const struct udevice_id xhci_pci_ids[] =3D { { .compatible =3D "xhci-pci" }, { } }; U_BOOT_DRIVER(xhci_pci) =3D { .name =3D "xhci_pci", .id =3D UCLASS_USB, .probe =3D xhci_pci_probe, .remove =3D xhci_deregister, .of_match =3D xhci_pci_ids, .ops =3D &xhci_usb_ops, .platdata_auto_alloc_size =3D sizeof(struct usb_platdata), .priv_auto_alloc_size =3D sizeof(struct xhci_ctrl), .flags =3D DM_FLAG_ALLOC_PRIV_DMA, }; static struct pci_device_id xhci_pci_supported[] =3D { { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_XHCI, ~0) }, {}, }; U_BOOT_PCI_DEVICE(xhci_pci, xhci_pci_supported); (It looks like the above driver is used as the default driver if no explicit match is found. It has been around for years.) But, in the past when I showed the likes of fdt print / or translation to a .dts file, it did not have "xhci-pci" in compatible but had "generic-xhci" instead, such as: xhci@7e9c0000 { compatible =3D "generic-xhci"; status =3D "disabled"; reg =3D <0x00000000 0x7e9c0000 0x00000000 = 0x00100000>; interrupts =3D <0x00000000 0x000000b0 = 0x00000004>; phandle =3D <0x000000d3>; }; For reference, for FreeBSD there is: # grep -ri "xhci-pci" /usr/src/sys/ | more # grep -ri "generic-xhci" /usr/src/sys/ | more /usr/src/sys/dev/usb/controller/generic_xhci_fdt.c: {"generic-xhci", = true}, /usr/src/sys/gnu/dts/arm/bcm-nsp.dtsi: compatible =3D = "generic-xhci"; /usr/src/sys/gnu/dts/arm/bcm5301x.dtsi: = compatible =3D "generic-xhci"; /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: = compatible =3D "generic-xhci"; /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: = compatible =3D "generic-xhci"; /usr/src/sys/gnu/dts/arm64/marvell/armada-37xx.dtsi: = "generic-xhci"; /usr/src/sys/gnu/dts/arm64/marvell/armada-cp11x.dtsi: = "generic-xhci"; /usr/src/sys/gnu/dts/arm64/marvell/armada-cp11x.dtsi: = "generic-xhci"; That FreeBSD generic_xhci_fdt.c match is from: static struct ofw_compat_data compat_data[] =3D { {"marvell,armada-380-xhci", true}, {"marvell,armada3700-xhci", true}, {"marvell,armada-8k-xhci", true}, {"generic-xhci", true}, {NULL, false} }; (End for-reference.) There is another driver in u-boot 2020.10, one that does mention "generic-" for xhci in drivers/usb/host/xhci-brcm.c : static const struct udevice_id xhci_brcm_ids[] =3D { { .compatible =3D "brcm,generic-xhci" }, { } }; U_BOOT_DRIVER(usb_xhci) =3D { .name =3D "xhci_brcm", .id =3D UCLASS_USB, .probe =3D xhci_brcm_probe, .remove =3D xhci_brcm_deregister, .ops =3D &xhci_usb_ops, .of_match =3D xhci_brcm_ids, .platdata_auto_alloc_size =3D sizeof(struct = brcm_xhci_platdata), .priv_auto_alloc_size =3D sizeof(struct xhci_ctrl), .flags =3D DM_FLAG_ALLOC_PRIV_DMA, }; It is a new driver as of around 6 months ago and so is likely the one created for the RPi4B context. (Note the usb_xhci vs. xhci_brcm distinct namings of the driver.) The .dtb files that I use for uefi/ACPI booting of FreeBSD and for u-boot based booting of ubuntu 2010.04.1 also use "generic-xhci", no "brcm," invovled. It seems that .dtb files that the u-boot folks expect for the RPi4B are vintages/variations that have compatible listing: "brcm,generic-xhci" . If one finds a .dtb with such, it might be close to what they were testing. With such a file, finding other differences with the .dtb files currently in use with FreeBSD could be done. I hope that the above helps. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Oct 9 03:26:09 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 BBEB24377FF for ; Fri, 9 Oct 2020 03:26:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 4C6tl34qqgz3Ycr for ; Fri, 9 Oct 2020 03:26:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 07gGDmAVM1lI9FSRbTxArZPtZ1BIIE7EVc.DnSL3ZUE1HJEn7VEjl8BnW3FWhHk GdfexCZRbzH76LURPZzZWE7DWmKRtMmC2wZuoLnbsFb0GcWoJ1zOPQS1JfI8pmqXZ9LmmB5js0fN Ml6s8.16yVBsl1bfgyO1PEqSaTNm8mOQjimCH1CJpLsTV3asjXE8TvzhbHVKTurAYsTIKywN_jQ0 vVFHv5mvgjl1ljhlQCcNpJYQZbL.V6u8OO43PWvfv8BaWmmNCKZ_TEQdBj.Y3z1K18Bgpm_zJiRs 1ygYMq3TrYE1B63.pjOAvVDH3djJvUOk.u237fSnaxKX_Tw9NiA5Jm.9KmtUw.UMwQ_5WMqeNTKb DEq.fVi9olo1n4kaLGZDuGjctTNPsMe3JBtNH3tVaBMRSvxAu1RLkBqwwYXOaqFIaDi4tCXUmv2O qX2OiZA_Os9_cWS90Uwp5kS2bD_43HHVbhj6bIdgMP_jxxOyt2X5qf.pJQbyF.J4fZjXRBi7F28H 65tHOBFnTPTLFhq9acOVshyHk3uKbs98mJewOccLEtHK9e9QJDBQN.xRD88WFEV2bWMW5xpFZWAm TigQgnhGS8l9m0XLdCBSlbl3LLMytp.LzIKibZoa.HgMC1.50TlITCKy9BQ_KrEd3GO_W_zE68MQ Lk6dWcQFdsi4AMcjGKmq2Le2j4QuntqvMIHOvbnGDE0PN5pxh68.o9CWV6RtaNsri8bGLva4FOSC dct6kvVq7N2sT6cAGgcFRlkiiFkct1HcMazhcSEDuQQ83BKWDwnnN8pjtva9CGnCMD6CssB335fy EG..Madru5s9NhzQO.usq.b5QLrk8hqIlNcUWpJLVXiG3_zsm96a0q6ZOXh5rffhx4ixtf77sX8R yJOtW9c6GmdwvDGBw0QDGGsZepNVIUJTkIo00j.Bzpc1fSTx1634Zs6YaQmdjc084bHW42qvAPBL hEZtHqfn07gGrxhNH5QyZJ_i5mxTEl3OtF2b1JRBDaDtnQ1wJl6kTJmGJUMmQJx8DoksVZ2OO_tQ w_NHH6j03z9gjxASI7ViMDQN9XArwUj8hWOr4gJh7IvWqQ7qmpinCmGb2jL9WQ3b.1k_vXjpWw7I speB504a_qqpuKS8n9fibT7MDRD3gQ3Z1jsOEkwzP7O.W60XgZRlFqXTwJpwmait8gvxijOER5Jh 2A8G6_Dr4UddpwSPB9W7EWPeZ01rSIPELAFm0952kMOgu6Do_zJW9uxWI1gqgWmVTt6vzPzuY5g7 YP1eoyNCG1i3e9jJvBlZihaeICad7tsoMz9NXjiE4jRrUGlyA6NwcrzxnkQ2EVUFazn72SzjCR9h q3SrIdk1ElLJavk.2PaGKLKihHGUzCCKiiHAC66nOB0o0FX2xck.1nBBeQMePYHcWVwKa4hvKbcm 9FdxWnIzpOmYmbfMwquyyN_FG0d36ABrCYmMTUYUsVizlsRVWSbYWMX9gqK8NrlKYvvMKicvNq71 5.Yxw4ZEahEje6GDBFJ.XicxG7dgosTQNZjpo.kvrB9yvS0qR5nMz6Dxt6y_.EUHzkJjeK5mI1V4 KU0.6q01XuRf1tupDXQRZgKC9nVXku7E- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 03:26:05 +0000 Received: by smtp418.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2c6c5acd6fe418bc7e248ea6a6b7eee8; Fri, 09 Oct 2020 03:26:03 +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: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <20201009024924.GB24977@www.zefox.net> Date: Thu, 8 Oct 2020 20:26:01 -0700 Cc: Kyle Evans , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201009021855.GA24977@www.zefox.net> <20201009024924.GB24977@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C6tl34qqgz3Ycr X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.33 / 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.82)[-0.820]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.02)[-1.023]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.99)[-0.988]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; 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: Fri, 09 Oct 2020 03:26:09 -0000 On 2020-Oct-8, at 19:49, bob prohaska wrote: > On Thu, Oct 08, 2020 at 09:27:22PM -0500, Kyle Evans wrote: >> On Thu, Oct 8, 2020 at 9:18 PM bob prohaska = wrote: >>>=20 >>> On Thu, Oct 08, 2020 at 01:34:12PM -0500, Kyle Evans wrote: >>>>=20 >>>> Here's a patch that I hacked out and can't test for quite a while = yet, >>>> feel free to give it a shot: >>>> https://people.freebsd.org/~kevans/bcm2835_vcbus.diff -- the best >>>> guarantee I can give you is that it builds. We'll need to test it = on >>>> both RPi4 models with the separate bus and the original RPi4s, as = well >>>> as an RPi3 and RPi2/0w. >>>>=20 >>>=20 >>> FWIW, a Pi3B running >>> FreeBSD www.zefox.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r366466M: = Thu Oct 8 17:18:55 PDT 2020 = bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 >>>=20 >>> seems to build, boot and run without immediate problems. >>>=20 >>> A Pi2 running >>> FreeBSD www.zefox.com 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692: = Thu Oct 8 16:57:50 PDT 2020 = bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM arm RPi2 <=3D v1.1? (32-bit only, bcm2709-rpi-2-b.dtb from = https://github.com/Hexxeh/rpi-firmware/ ) RPi2 >=3D v1.2? (64-bit and 32-bit capable, bcm2710-rpi-2-b.dtb ) I've not looked at the differences in the .dtb files. >>> also built, booted and ran. >>>=20 >>> Uptime so far is only a few minutes, but so far, so good. If the = MMCCAM >>> mismatch is significant let me know and I'll fix it. >>>=20 >>=20 >> Thanks for testing! >>=20 >> Can you also confirm the output of `dmesg | grep 'WARNING:'`, please? >> In particular, I'd like to know if you hit either of: >>=20 >> WARNING: Improper peripheral attachment ... >> WARNING: bus for '...' missing dma-ranges >>=20 >=20 > On the Pi2 I see: > bob@www:~ % dmesg | grep 'WARNING:' > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: Device "openfirm" is Giant locked and may be deleted before = FreeBSD 13.0. > WARNING: Device "kbd" is Giant locked and may be deleted before = FreeBSD 13.0. > WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD = 13.0. > WARNING: WITNESS option enabled, expect reduced performance. >=20 > On the Pi3 I see: > bob@www:~ % dmesg | grep 'WARNING:' > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: Device "kbd" is Giant locked and may be deleted before = FreeBSD 13.0. > WARNING: Device "openfirm" is Giant locked and may be deleted before = FreeBSD 13.0. > WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD = 13.0. > WARNING: WITNESS option enabled, expect reduced performance. >=20 > so the answer seems to be "no". >=20 > HTH, let me know if I can try anthing else. Both installs are = expendable. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Oct 9 04:19:34 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 E8D02438A9B for ; Fri, 9 Oct 2020 04:19:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6vwj6rlBz3bWS for ; Fri, 9 Oct 2020 04:19:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x729.google.com with SMTP id c2so9336337qkf.10 for ; Thu, 08 Oct 2020 21:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0a92OruEQ/lXfXqiwsyisesXbiHgcWGZOuaJRWWLUoo=; b=wVIMxNZ8EunnGhYYKUqk61tN3coHT/VC0PrsV3YzoVIco3WFO5weG1BwhtGFsnvGOZ 5heQSd5lv5b0KPAYOrQeibAltqHjD/whUXqS85gF1HjLUYiEgUI0f/btCsfMz/sv0mfA QGNnojMtdrHv1bHHdDr1R/uI0mVpfadVddurt1QPWK9hVvfS1vLf7KI9Gm06yETaiI9N VDIf5/NYmt6CtCLeUq1RfZNnNgfKOhocJeZZ/h/EBH2YkvLQdHicWuuAYubR6iG17+wa CrM3tD0Zu2WR57HVStXHcgIaIteaY8y2diJlCjvZpxr64wXel2RqR+wRwE+aXlVqVmXQ Xs5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0a92OruEQ/lXfXqiwsyisesXbiHgcWGZOuaJRWWLUoo=; b=S8Lf/+R06XE6Avskm/DwQ1FqfMQyI3U4rl9n1dVORKpzk5bMC5oc63HFdBpPUiWvUP D7E3neZM2//Zy/71LlJ32PbAdHckRhwQlnOhaB/Hbx2HihXIggZV0+x1j7zCff2iUpqs DAU/lmeHkJp85jdWutPWFU2rde2x3IMxvzi+fJK6RvRWlO5U0GyUrgs+K0RgOQ4eimfe 6lj8jmCdPmo0nv9BSOrUyI+2vyW1SDH02OucQMDLha2GeY8I7xYP5VQv/+KC1yB85W6Q EQCgb14X/WttTo9aPj8o1IgijOspBrUcBL9x5fNoVDtkcH+XQhiyUErcoyqz5ddbtsfc fXrw== X-Gm-Message-State: AOAM530jDPy8+DKsfQRIlIw6c5U+uFLv9KWWJyu9rmUwNIHY9n/5G8Ja S1DJqa7qvftuN3/Am0OurMwH9zPFzR444W2nOnVfCkYy2conmg== X-Google-Smtp-Source: ABdhPJyipRirUYoCyfieMZ1Hkkqp9blQAdPzYUDOpNXcxuTucwNM0XeIAcYEjp4RtKD3K3jKcuci7UPhO4cBziTJmUs= X-Received: by 2002:ae9:eb97:: with SMTP id b145mr4289234qkg.60.1602217172727; Thu, 08 Oct 2020 21:19:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 8 Oct 2020 22:19:21 -0600 Message-ID: Subject: Re: ARMv7 without VFP To: Marcin Wojtas Cc: freebsd-arm X-Rspamd-Queue-Id: 4C6vwj6rlBz3bWS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=wVIMxNZ8; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::729) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.03 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.020]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::729:from]; NEURAL_HAM_SHORT(-0.03)[-0.026]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Fri, 09 Oct 2020 04:19:35 -0000 On Thu, Oct 8, 2020 at 5:57 PM Marcin Wojtas wrote: > Hi, > > We have a CA9-based SoC that for some reason does not support the VFP > and would like to run the OS on stable/12. Disabling the VFP in the > kernel options (or adding the detection of the feature in runtime) > seems to work fine, but it turned out the biggest obstacle is trying > to force the userspace to use the softfloat libc callbacks (in theory > soft-/hard- float usage should be resolved dynamically by linking the > proper functions in libc - so far we found no way to compile it > successfully though with the standard toolchain). Other approaches to > hardcode the softfloat userspace have failed so far. Details can be > found below. > > Is there any known way to compile the userspace that may work with the > soft-float on armv7? > > Details: > When booting without VFP there is a problem with almost every process > receiving SIGILL signals. Core dumps and disassembly proved that the > illegal > instructions are associated with hardware FPU. The kernel seems to run > fine otherwise. > > 1. When building world with option CPUTYPE=soft, libc cannot be linked > properly > due to lack of _aeabi* > > --- all_subdir_sbin --- > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_f2iz_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_fadd_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_fcmpeq_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_fcmpge_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_fcmpgt_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_fcmple_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_fcmplt_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_fcmpun_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_fdiv_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_fmul_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_fsub_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_i2f_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_d2f_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_d2iz_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_dadd_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_dcmpeq_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_dcmpge_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_dcmpgt_vfp > ld: error: > /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: > undefined reference to __aeabi_dcmple_vfp > > 2. According to imp@, the softfloat system can still be built, however it > is not > officially supported anymore > ( > https://lists.freebsd.org/pipermail/freebsd-arch/2017-September/018329.html > ). > It is assumed that armv6/armv7 CPUs always have VFP unit. > > 3. FreeBSD stable/12 world with CPUTYPE=soft is built automatically with > -mfloat-abi=softfp, which emulates the soft float ABI, however still > uses hard float instructions. > > 4. When trying to pass -mfloat-abi=soft, everything is built with > three flags: -mfloat-abi=soft -mfloat-abi=softfp -mfloat-abi=softfp. > > 5. Additional problem encountered when trying to use additional flag > -mfloat-abi=soft: > > --- clang.full --- > > /home/mindal/obj/arm.armv6/usr/home/mindal/git/freebsd-src/lib/clang/libclang/libclang.a: > could not read symbols: File format not recognized > c++: error: linker command failed with exit code 1 (use -v to see > invocation) > > 6. Problems above seen on both stable/11 and stable/12. In case of > stable/12 > it is visible with both TARGET_ARCH=armv6 and TARGET_ARCH=armv7 > > I'd appreciate any feedback. > I last built this several clang generations ago. I fear that you'll need to chase down what might be a bug in clang. I'd give it a shot with an external toolchain based on gcc. There's been talk from time to time of adding a armv7sf target. If you make progress on the underlying problem, I'd be open to that. Warner > Best regards, > Marcin (mw@) > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Oct 9 04:29:32 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 46B48438BA9 for ; Fri, 9 Oct 2020 04:29:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 4C6w8B6ZZxz3blV for ; Fri, 9 Oct 2020 04:29:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 9otuHgcVM1lRwmEPdlLgQKl3K.AycbLQkmy_CnLG3ZmYj2h4.Re1_Z4w1NreWir eCQd0yzOO96H4VTdXtHeGLnLHXcRrO3iU6Htl60x6SYdJUacEQrvr0oD5AcdfGLR4gymFmAl2CJo mVohcJYSQXGNj7hmoCoGwmcrNjLs7SC1fRfi124ew6le7rBLyscsgOLRI.t6UfzJoZ_6AmcF809i uJ65lxOYaQ_u6vvlGLNE6wPsC3xdVjyoPrY3JcshCZWa7pOg3bgErdKCd0aLgjzm52vSIfznOTdv GnZzuWkeFv_21rCI.cmVyejNz5XFwhwuyVjb_aTksWNDrvxYd1kc4EM.NEa3AgMtpp34e7ELsZ4P 6jLO5..hdHECe_WH6ADqh1UtjgpV2LiJ1k_WaiNtcMtVajfLtRatr7R8RTrOVQGdH1AHMtydrfCg 7JKFgd0aDisc9ZCJg587ZHEtS39nwHn4c6Si2u0e.mJ_bc.tQiEf4uua4.xSDiv1jYddrlYpFCy. apyvIMsaJpIqNuV0nDZwJAi83uJoeiwpoYGpGMbHRII9HIXuepz6mI5yIfZRs87O_GruWRRGqn0H ts1rHeNCkz5HEly0j9M4h4VZTeRyjdGmYlBwuOnUR2.0eqFL_G9rxlfhZZH1V2TE.E_LEy.VNzOJ rxIjobT_25WqgGwE1l1_K2NTuxakZ4eFgpvNFiFS78902GZxUtVV5w47kn7rTEQGsSRClp4ACr6G wtSQ1CDgbmUne8XnZLsLYqXynvROmrUZMagAFEcVh9IMo0sU7Uo_P1vUyuj4Lv4e1Mm.tr9jpW7x aMgKvfgZ_Cb3Jl8zkMh.Ht77vibPjTlsaAT5zt52gbFc.Kirk.zrP0QW0OKIVmOlMXoQowmIS0QP u4yxBXBADrQAUp7cgWYrCBGHSZI4TgjwYg8KJ9EzbqG5q6rIcSb4w1I0_1HaHWGINZJpcZIdeITV 9qslfl5OnGHZsB3M9Q2T4B8hoM2WJfJj5W_DyyTXUcX3ZAyG3Gp.pxxkn2R7n8zLep_9UHefin7M 3qK.883NEnzOYw_lV7WtaSRrM_cgK1GZopGZC1w6JNMOLik_5HxktMxf5mChkAuajqDQdVUj5UnR BH1sN9wDSzOaYQvxaNLaS_KETJdgFXnlDtwdmnbDJPmGVE6EU4gs.su0z9nvglV0oWEZVO2KbFA3 jeT2gaJOoPglxltCt0P08i1x6cJAYxvFGJ3KxRukiBxIg9XWBr_KvxlNbq.gtk1qZFYC3ndY3xGl _FKjiBgfJKqtq_3e.FZd6FmEyWEzRPZTUTR6yENTOXB0HIMmBDhodXF73c9T_6fH2Qk.n1YpglUH Kx13O2l0zPSuV8uAw40u0ITB7VdwO8bxpB.ry.5tbkb96lSPq1QFg9JEsFZ_E64obAP8e_gYB1J1 eSIM.CJ_egeTJXDCjMgNneZ7OujE9ez8MBP.lQHtyVOM4DC_CPeAdn8Mun2cj5axCT35huhYOgy1 ZY4aB5Dal2yzTXql7qjg5vTzvS2KEvi54J2IKsLraOcpZ533LuAC1YhkvQSNBKG_L2Fc7wXg.r0C eYUQ55IjzuEMxmnZHnupvL9qKEofiYhaq6tqjrig- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 04:29:28 +0000 Received: by smtp424.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fcdbce08aba8ab373603123557b653fb; Fri, 09 Oct 2020 04:29:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> Date: Thu, 8 Oct 2020 21:29:25 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C6w8B6ZZxz3blV X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.42 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.91)[-0.912]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.01)[-1.010]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; 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: Fri, 09 Oct 2020 04:29:32 -0000 On 2020-Oct-8, at 20:06, Mark Millard wrote: > On 2020-Oct-8, at 06:27, Klaus Cucinauomo wrote: >=20 >>> Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm = : >>>=20 >>>=20 >>> The old u-boot/DTB combination in use does not have emmc2bus. >>> And, even if it did, FreeBSD would not use =E2=80=A6=E2=80=A6=E2=80=A6= . >>=20 >> =E2=80=A6 and the new 2020.10- combinations will even be more = annoying=E2=80=A6 >> While I meanwhile e.g. could boot the 4GB off of xhci, it hangs in = DeviceTree, >> Depending on GUESSED ;-) combinations and DeviceTree-patches in src . >> There have to be necessary adjustments which are even not yet = upstreamed in u-boot=20 >> (depending on hw-revisions)=E2=80=A6and so on ... >> I doubt that anyone really will take explicitly time consuming care = of all that annoying RPI4-crap. >> I don't see any other way than targeting minimum 1 developer(better = more) ONLY to the RPI-platform=20 >> for a time period=E2=80=A6 other than leaving it crappy as is and to = be happy that it nevertheless=20 >> is a working fbsd-gadget :-) >=20 >=20 > Summary of probable-cause finding: u-boot 2020.10 is > expecting: >=20 > compatible =3D "brcm,generic-xhci" >=20 > instead of what seems to be in files that are in use > by FreeBSD: >=20 > compatible =3D "generic-xhci" >=20 > (I've no clue what all the other differences in the .dtb > file contents might be.) >=20 >=20 >=20 > The details of what I learned that reached that status . . . >=20 > I updated my ports environment on a RPi4 to build the final 2020.10 = u-boot > for the RPi4. I then built it and replaced the u-boot.bin on the = microsd > card that I boot with via the FreeBSD kernel being from that microsd = card > but later stages being from the USB3 SSD. I did not update anything = else. > So: still an older .dtb file. >=20 > That 8 GiByte RPi4B context booted just fine. >=20 > I then rebooted and had it stop in u-boot and looked around just a = little > bit. >=20 > U-Boot 2020.10 (Oct 09 2020 - 00:51:29 +0000) >=20 > DRAM: 7.9 GiB > RPI 4 Model B (0xd03114) > MMC: mmc@7e300000: 1, emmc2@7e340000: 0 > Loading Environment from FAT... In: serial > Out: vidconsole > Err: vidconsole > Net: eth0: ethernet@7d580000 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus xhci_pci: probe failed, error -110 > No working controllers found > Hit any key to stop autoboot: 0=20 >=20 > So it reproted the problem above. Yet . . . >=20 > U-Boot> pci 0 > Scanning PCI devices on bus 0 > BusDevFun VendorId DeviceId Device Class Sub-Class > _____________________________________________________________ > 00.00.00 0x14e4 0x2711 Bridge device 0x04 >=20 > U-Boot> pci 1 =20 > Scanning PCI devices on bus 1 > BusDevFun VendorId DeviceId Device Class Sub-Class > _____________________________________________________________ > 01.00.00 0x1106 0x3483 Serial bus controller 0x03 >=20 > So it does see the xHCI on the pci bus despite the > "Bus xhci_pci: probe failed, error -110". -110 looks > to be -ETIMEDOUT . >=20 > Looking at the v2020.10/drivers/usb/host/xhci-pci.c source > code shows that the xhci_pci driver has: >=20 > . . . > static const struct udevice_id xhci_pci_ids[] =3D { > { .compatible =3D "xhci-pci" }, > { } > }; >=20 > U_BOOT_DRIVER(xhci_pci) =3D { > .name =3D "xhci_pci", > .id =3D UCLASS_USB, > .probe =3D xhci_pci_probe, > .remove =3D xhci_deregister, > .of_match =3D xhci_pci_ids, > .ops =3D &xhci_usb_ops, > .platdata_auto_alloc_size =3D sizeof(struct usb_platdata), > .priv_auto_alloc_size =3D sizeof(struct xhci_ctrl), > .flags =3D DM_FLAG_ALLOC_PRIV_DMA, > }; >=20 > static struct pci_device_id xhci_pci_supported[] =3D { > { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_XHCI, ~0) }, > {}, > }; >=20 > U_BOOT_PCI_DEVICE(xhci_pci, xhci_pci_supported); >=20 > (It looks like the above driver is used as the default > driver if no explicit match is found. It has been around > for years.) >=20 >=20 > But, in the past when I showed the likes of fdt print / > or translation to a .dts file, it did not have "xhci-pci" > in compatible but had "generic-xhci" instead, such as: >=20 > xhci@7e9c0000 { > compatible =3D "generic-xhci"; > status =3D "disabled"; > reg =3D <0x00000000 0x7e9c0000 0x00000000 = 0x00100000>; > interrupts =3D <0x00000000 0x000000b0 = 0x00000004>; > phandle =3D <0x000000d3>; > }; >=20 > For reference, for FreeBSD there is: >=20 > # grep -ri "xhci-pci" /usr/src/sys/ | more > # grep -ri "generic-xhci" /usr/src/sys/ | more > /usr/src/sys/dev/usb/controller/generic_xhci_fdt.c: = {"generic-xhci", true}, > /usr/src/sys/gnu/dts/arm/bcm-nsp.dtsi: compatible =3D = "generic-xhci"; > /usr/src/sys/gnu/dts/arm/bcm5301x.dtsi: = compatible =3D "generic-xhci"; > /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: = compatible =3D "generic-xhci"; > /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: = compatible =3D "generic-xhci"; > /usr/src/sys/gnu/dts/arm64/marvell/armada-37xx.dtsi: = "generic-xhci"; > /usr/src/sys/gnu/dts/arm64/marvell/armada-cp11x.dtsi: = "generic-xhci"; > /usr/src/sys/gnu/dts/arm64/marvell/armada-cp11x.dtsi: = "generic-xhci"; >=20 > That FreeBSD generic_xhci_fdt.c match is from: >=20 > static struct ofw_compat_data compat_data[] =3D { > {"marvell,armada-380-xhci", true}, > {"marvell,armada3700-xhci", true}, > {"marvell,armada-8k-xhci", true}, > {"generic-xhci", true}, > {NULL, false} > }; >=20 > (End for-reference.) >=20 > There is another driver in u-boot 2020.10, one that > does mention "generic-" for xhci in > drivers/usb/host/xhci-brcm.c : >=20 > static const struct udevice_id xhci_brcm_ids[] =3D { > { .compatible =3D "brcm,generic-xhci" }, > { } > }; >=20 > U_BOOT_DRIVER(usb_xhci) =3D { > .name =3D "xhci_brcm", > .id =3D UCLASS_USB, > .probe =3D xhci_brcm_probe, > .remove =3D xhci_brcm_deregister, > .ops =3D &xhci_usb_ops, > .of_match =3D xhci_brcm_ids, > .platdata_auto_alloc_size =3D sizeof(struct = brcm_xhci_platdata), > .priv_auto_alloc_size =3D sizeof(struct xhci_ctrl), > .flags =3D DM_FLAG_ALLOC_PRIV_DMA, > }; >=20 > It is a new driver as of around 6 months ago and so is likely > the one created for the RPi4B context. >=20 > (Note the usb_xhci vs. xhci_brcm distinct namings of > the driver.) >=20 >=20 > The .dtb files that I use for uefi/ACPI booting of FreeBSD > and for u-boot based booting of ubuntu 2010.04.1 also use > "generic-xhci", no "brcm," invovled. >=20 > It seems that .dtb files that the u-boot folks expect for > the RPi4B are vintages/variations that have compatible > listing: "brcm,generic-xhci" . >=20 > If one finds a .dtb with such, it might be close to what > they were testing. With such a file, finding other > differences with the .dtb files currently in use with > FreeBSD could be done. >=20 > I hope that the above helps. Looks like the u-boot.bin built includes "xhci-pci" but excludes "brcm,generic-xhci": not in the output of hd /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin after the port is installed. My initial guess would be that something more needs to be specified to cause drivers/usb/host/xhci-brcm.c (and possibly more) to be built and included. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Oct 9 06:01:45 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 1DCCB43A203 for ; Fri, 9 Oct 2020 06:01:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4C6yBb4pbkz3gJH for ; Fri, 9 Oct 2020 06:01:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 8LiR12IVM1kuoztqIzbTyVmNxzDfOi1Y938N.a2lVqk6XZu7PM3xhDbD_Fz263y oFfwVkqVulHtR5Vo8rSYZLrdZEn7..tPI7.O1gggUr30a0Dboa4sSyyHmAxn_OXA254Ei4PQQMYh 8tefz3ESMewo2QjFWcKuK7Po0cUSRaZdNXS8FygVAa4dHpacs_hcNnepcNP_3opEF8rgJzqn60z_ mvoX8CYzKXnxZf8dfkPBz_6rJA74c87GjWBTj09XwcO6dseX_xsjeGMc.PdnxxZF3dMUZdv_XA8p xp4zBDYFogg_U_omNA.IPYGjNc2X4G2r6l2M84MJyIsLa29PGu2153rSAuKyG6Nj4yf2ywuq1LKK DH1yTurr.s9el3xFQEBf_xVCO9ShiVgjKEhUW259zbwCsurAPOtQeMf9EhrELL.K8v1wDKeqsyJM lyq4vb2Isurgf7sp0ooql5dYMmhrFzjZfF0Cb.ykrpuCYOU3KWV6jTbEcPOxrRPQvo_31Yg6S8wI G5ZrnV38dBsZVeuMWEgs1ztQ1003NjDbBD5RyoLyJXZ4jL.DcShwKKSXyNqMK2tTuWF9acVaQ86n duk0GUvLFpgfIn3eZnBb_ZqN6_YOuaVk7QEWxbFvah0lzTNvMV4tNyNZ6ICrN6jd2vExQUJoOLoM k3iY6AA3tZFXKZCQNMIa6t4J1Ykr2qUXXLTy5j1kOlfvTuvm.VBrllPXzAyRUg2OoBiL4GkM0hFG cSdjBVa6ooHzrbfDQX6Jz0K153ubRd8hnqGqe65LT_kz_9IUX1XQVhQBdQOSlocj0bARa8ftcgnj 8eRIhAVH3bRGQBMuiupJEHIEnSKiYIyzbKovRuoParg3aAIK0Pmq5XkpVN_dex.1NBSm0OB86d0I 7SrosEj3R_VLxsjidZLXjouk25svtNKCXWUrS90OL5XqsBJHSsR7M9z2K_Up2Tc4c3xyiHJd0HNP sA9n.XZ.L2gxA4._6DrltCRBdY1UJUBbtbaUSrEHLaJuPX19gY3uA3YXtQwC3HTIKGHjXPBK6EAF EXY3fI_mq.y33DE0s4gXtbE.eCLhzx7U3UintIA3SqzQBSR89mqp0DJIisTCgmjkrBnQ0egRd1cn BkpeI4.a4aAKRBUtDrokIO7hRxwJEyuMfuWyTsPYP9e2PrP0i9ZAxi2eeA3LOWBJ_HbUsc1Khr37 2Fa4_9003Vl7S.VTI8EmUTwAjDT6FY9cGoeFrj6C1jwSFjp_njD.kOZAIzeEj9xruIhvuJaSYhrA 2K1aPgfi.0XoK_xdxGSTcKmaIDXLkHX97OquN1EHMPcH9gzmJjeSm7QSoeO6hq0XvUOUJ2mVvOuW u9TA6BrF2ufkxvWAWj5saXVFVQqiDraaIMTN0kDzpuc7zfl2PcbToshj0KuVRbW1hc9ocHTMVrph EZE97kdJb7H192oCnbyH5VkY1lUfVVuNbj5JMrFeMZFvjgJAtSFroUQ7QylvDieP67g_KSloTz63 pyXGkiz1V6NANScZnqpGCVtsUAl5DneIOjt2DgzoE9Cs3qIBQg96AjKnoaSwYQNKAD_6CcHkpycN LQbciEvFFG0J0Ue.4ckTHVuWVFJyhuLPbTA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 06:01:42 +0000 Received: by smtp419.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 65e8efc1d0c5aa858b52fe3635ef160c; Fri, 09 Oct 2020 06:01:34 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> Date: Thu, 8 Oct 2020 23:01:33 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C6yBb4pbkz3gJH X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.56 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.05)[-1.054]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.01)[-1.010]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; 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: Fri, 09 Oct 2020 06:01:45 -0000 On 2020-Oct-8, at 21:29, Mark Millard wrote: > On 2020-Oct-8, at 20:06, Mark Millard wrote: >=20 >> On 2020-Oct-8, at 06:27, Klaus Cucinauomo wrote: >>=20 >>>> Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm = : >>>>=20 >>>>=20 >>>> The old u-boot/DTB combination in use does not have emmc2bus. >>>> And, even if it did, FreeBSD would not use =E2=80=A6=E2=80=A6=E2=80=A6= . >>>=20 >>> =E2=80=A6 and the new 2020.10- combinations will even be more = annoying=E2=80=A6 >>> While I meanwhile e.g. could boot the 4GB off of xhci, it hangs in = DeviceTree, >>> Depending on GUESSED ;-) combinations and DeviceTree-patches in src = . >>> There have to be necessary adjustments which are even not yet = upstreamed in u-boot=20 >>> (depending on hw-revisions)=E2=80=A6and so on ... >>> I doubt that anyone really will take explicitly time consuming care = of all that annoying RPI4-crap. >>> I don't see any other way than targeting minimum 1 developer(better = more) ONLY to the RPI-platform=20 >>> for a time period=E2=80=A6 other than leaving it crappy as is and = to be happy that it nevertheless=20 >>> is a working fbsd-gadget :-) >>=20 >>=20 >> Summary of probable-cause finding: u-boot 2020.10 is >> expecting: >>=20 >> compatible =3D "brcm,generic-xhci" >>=20 >> instead of what seems to be in files that are in use >> by FreeBSD: >>=20 >> compatible =3D "generic-xhci" >>=20 >> (I've no clue what all the other differences in the .dtb >> file contents might be.) >>=20 >>=20 >>=20 >> The details of what I learned that reached that status . . . >>=20 >> I updated my ports environment on a RPi4 to build the final 2020.10 = u-boot >> for the RPi4. I then built it and replaced the u-boot.bin on the = microsd >> card that I boot with via the FreeBSD kernel being from that microsd = card >> but later stages being from the USB3 SSD. I did not update anything = else. >> So: still an older .dtb file. >>=20 >> That 8 GiByte RPi4B context booted just fine. >>=20 >> I then rebooted and had it stop in u-boot and looked around just a = little >> bit. >>=20 >> U-Boot 2020.10 (Oct 09 2020 - 00:51:29 +0000) >>=20 >> DRAM: 7.9 GiB >> RPI 4 Model B (0xd03114) >> MMC: mmc@7e300000: 1, emmc2@7e340000: 0 >> Loading Environment from FAT... In: serial >> Out: vidconsole >> Err: vidconsole >> Net: eth0: ethernet@7d580000 >> PCIe BRCM: link up, 5.0 Gbps x1 (SSC) >> starting USB... >> Bus xhci_pci: probe failed, error -110 >> No working controllers found >> Hit any key to stop autoboot: 0=20 >>=20 >> So it reproted the problem above. Yet . . . >>=20 >> U-Boot> pci 0 >> Scanning PCI devices on bus 0 >> BusDevFun VendorId DeviceId Device Class Sub-Class >> _____________________________________________________________ >> 00.00.00 0x14e4 0x2711 Bridge device 0x04 >>=20 >> U-Boot> pci 1 =20 >> Scanning PCI devices on bus 1 >> BusDevFun VendorId DeviceId Device Class Sub-Class >> _____________________________________________________________ >> 01.00.00 0x1106 0x3483 Serial bus controller 0x03 >>=20 >> So it does see the xHCI on the pci bus despite the >> "Bus xhci_pci: probe failed, error -110". -110 looks >> to be -ETIMEDOUT . >>=20 >> Looking at the v2020.10/drivers/usb/host/xhci-pci.c source >> code shows that the xhci_pci driver has: >>=20 >> . . . >> static const struct udevice_id xhci_pci_ids[] =3D { >> { .compatible =3D "xhci-pci" }, >> { } >> }; >>=20 >> U_BOOT_DRIVER(xhci_pci) =3D { >> .name =3D "xhci_pci", >> .id =3D UCLASS_USB, >> .probe =3D xhci_pci_probe, >> .remove =3D xhci_deregister, >> .of_match =3D xhci_pci_ids, >> .ops =3D &xhci_usb_ops, >> .platdata_auto_alloc_size =3D sizeof(struct usb_platdata), >> .priv_auto_alloc_size =3D sizeof(struct xhci_ctrl), >> .flags =3D DM_FLAG_ALLOC_PRIV_DMA, >> }; >>=20 >> static struct pci_device_id xhci_pci_supported[] =3D { >> { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_XHCI, ~0) }, >> {}, >> }; >>=20 >> U_BOOT_PCI_DEVICE(xhci_pci, xhci_pci_supported); >>=20 >> (It looks like the above driver is used as the default >> driver if no explicit match is found. It has been around >> for years.) >>=20 >>=20 >> But, in the past when I showed the likes of fdt print / >> or translation to a .dts file, it did not have "xhci-pci" >> in compatible but had "generic-xhci" instead, such as: >>=20 >> xhci@7e9c0000 { >> compatible =3D "generic-xhci"; >> status =3D "disabled"; >> reg =3D <0x00000000 0x7e9c0000 0x00000000 = 0x00100000>; >> interrupts =3D <0x00000000 0x000000b0 = 0x00000004>; >> phandle =3D <0x000000d3>; >> }; >>=20 >> For reference, for FreeBSD there is: >>=20 >> # grep -ri "xhci-pci" /usr/src/sys/ | more >> # grep -ri "generic-xhci" /usr/src/sys/ | more >> /usr/src/sys/dev/usb/controller/generic_xhci_fdt.c: = {"generic-xhci", true}, >> /usr/src/sys/gnu/dts/arm/bcm-nsp.dtsi: compatible =3D = "generic-xhci"; >> /usr/src/sys/gnu/dts/arm/bcm5301x.dtsi: = compatible =3D "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: = compatible =3D "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: = compatible =3D "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/marvell/armada-37xx.dtsi: = "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/marvell/armada-cp11x.dtsi: = "generic-xhci"; >> /usr/src/sys/gnu/dts/arm64/marvell/armada-cp11x.dtsi: = "generic-xhci"; >>=20 >> That FreeBSD generic_xhci_fdt.c match is from: >>=20 >> static struct ofw_compat_data compat_data[] =3D { >> {"marvell,armada-380-xhci", true}, >> {"marvell,armada3700-xhci", true}, >> {"marvell,armada-8k-xhci", true}, >> {"generic-xhci", true}, >> {NULL, false} >> }; >>=20 >> (End for-reference.) >>=20 >> There is another driver in u-boot 2020.10, one that >> does mention "generic-" for xhci in >> drivers/usb/host/xhci-brcm.c : >>=20 >> static const struct udevice_id xhci_brcm_ids[] =3D { >> { .compatible =3D "brcm,generic-xhci" }, >> { } >> }; >>=20 >> U_BOOT_DRIVER(usb_xhci) =3D { >> .name =3D "xhci_brcm", >> .id =3D UCLASS_USB, >> .probe =3D xhci_brcm_probe, >> .remove =3D xhci_brcm_deregister, >> .ops =3D &xhci_usb_ops, >> .of_match =3D xhci_brcm_ids, >> .platdata_auto_alloc_size =3D sizeof(struct = brcm_xhci_platdata), >> .priv_auto_alloc_size =3D sizeof(struct xhci_ctrl), >> .flags =3D DM_FLAG_ALLOC_PRIV_DMA, >> }; >>=20 >> It is a new driver as of around 6 months ago and so is likely >> the one created for the RPi4B context. >>=20 >> (Note the usb_xhci vs. xhci_brcm distinct namings of >> the driver.) >>=20 >>=20 >> The .dtb files that I use for uefi/ACPI booting of FreeBSD >> and for u-boot based booting of ubuntu 2010.04.1 also use >> "generic-xhci", no "brcm," invovled. >>=20 >> It seems that .dtb files that the u-boot folks expect for >> the RPi4B are vintages/variations that have compatible >> listing: "brcm,generic-xhci" . >>=20 >> If one finds a .dtb with such, it might be close to what >> they were testing. With such a file, finding other >> differences with the .dtb files currently in use with >> FreeBSD could be done. >>=20 >> I hope that the above helps. >=20 > Looks like the u-boot.bin built includes "xhci-pci" > but excludes "brcm,generic-xhci": not in the output > of hd /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin > after the port is installed. >=20 > My initial guess would be that something more needs > to be specified to cause drivers/usb/host/xhci-brcm.c > (and possibly more) to be built and included. Looks like that was a bad guess, it still gets: No working controllers found based on instead having the "brcm,generic-xhci" driver (with a "generic-xhci" added to the compatibility list). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Oct 9 06:48:55 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 3516743A3E4 for ; Fri, 9 Oct 2020 06:48:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6zDz6LD8z3ysj; Fri, 9 Oct 2020 06:48:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 0996n3PL025536 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 8 Oct 2020 23:49:03 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 0996n3CU025535; Thu, 8 Oct 2020 23:49:03 -0700 (PDT) (envelope-from fbsd) Date: Thu, 8 Oct 2020 23:49:01 -0700 From: bob prohaska To: Mark Millard Cc: Kyle Evans , freebsd-arm , bob prohaska Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Message-ID: <20201009064901.GC24977@www.zefox.net> References: <20201009021855.GA24977@www.zefox.net> <20201009024924.GB24977@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4C6zDz6LD8z3ysj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.71 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-0.52)[-0.516]; NEURAL_HAM_LONG(-0.14)[-0.138]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.54)[-0.538]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] 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: Fri, 09 Oct 2020 06:48:55 -0000 On Thu, Oct 08, 2020 at 08:26:01PM -0700, Mark Millard wrote: > > > On 2020-Oct-8, at 19:49, bob prohaska wrote: > > > RPi2 <= v1.1? (32-bit only, bcm2709-rpi-2-b.dtb from https://github.com/Hexxeh/rpi-firmware/ ) > RPi2 >= v1.2? (64-bit and 32-bit capable, bcm2710-rpi-2-b.dtb ) > > I've not looked at the differences in the .dtb files. > It's the early Pi2, so v1.1. HTH, bob prohaska From owner-freebsd-arm@freebsd.org Fri Oct 9 10:02:15 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 D1F1F43E407 for ; Fri, 9 Oct 2020 10:02:15 +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 4C73X64DGgz48tX for ; Fri, 9 Oct 2020 10:02:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: V3A0FjcVM1lNCuK5d13m1Ny26WZu1j4B1TFwz9AUbwr41I943T9FXFNJMU7tfMD J87pbglq5feJI84u1Rpm3ZPXFq2ISMz2AmaaBWJenf6jWPmtB9Fr7pvECxtee.CbjRMD7aBgjyf5 HFsGFA5_J42l5hhBr8XSPC8k_4Ea53pbIVYbXJRiYNvuMYF5HDRkmzYOsrBm3Tjjj.ny7HTjL8HN MwjCj05lsKf9vRYltHv745rQtAvFVS.9ION2LKYeeD08y5qFU8dY1OqH8I4Wn17KWT4JeO8fbG8L 0PfgWnvuF1Isjh3UzLJTw6mnT.Ka_iTLjbmH4RgBWxYMUn61dru37i3s8Ds3CTg7z5jxgmimXFfq bGeSmN8sRWrKuBEnwm3TQSPtneC0aCBU7eHN4CISI7wYyvhp5.Jk8PrxPUJnGwJUxb8qzMcv54YP hhg9he1bbcF2eK6zdWoQNTuXmOlWKCzph2X2yz3v2qqzWc7S2s1Pz98hy2ifgHUyJTMbhNBig7oo 4tseAkwl9FNfMA98GfwcZpEi3ks0i1YnLgsjnFtRrbxDoiba8M0nwi3gnaW7XDK5av1uXGpB62cP US29g0tT3Rh_93zKG0HZZKzgKf99wTGfzaKd7RIgyGg5hKluBNrmq6pk8F5yJzMXDenx.9aJo400 m7xkspCyoIWHyPzMWqPGCgPYXzvYJhkw1ro5WTSg41RAWZDgWGZCU8U6OF0CSz28fkDzJvDmbJxH iaSo3nnetrG8HH4NNPNLAXP0OaqXA.67_Beh7Xf2JCY.RhhP9jdMx5ztnT_rzs3kkESqk8ZF2aPO ixRupY_3X3uN1BaCRkQcGGd7Kn26QDFRMINBPh7fHw3A5LMC4f9VD43wplXzyULGEIMvXD5LWHU0 wt7hEQfzKHZuFB7r_WepazWfZRxGyBORI1HlqsLLNC0Rzfk.HxxIC7QcH8xBoX36RROcFeDhvhQ5 a.AFUKoC3e4_dASQ315ZVOelO0h561K6HNppn7AxeiHFbKOqlfamiwZcMu9haK4xXFgleA9OMosb 5L_pD9lpF2QZtJ_RS.mar.tRzHYUpsqx30PzxGGR_scPkGlzvVLOUzmK6O9UYYe1jlwFhh35v978 oD20n9.Hs5pEQdcr8pYBVO6ddU1jeEaoDv1c6DAnTqhTJrBWH2TH.zWsR4UT4AWxCh4XKMZ9Fg__ IaJa1zQGSaN0_KTTy5ECsow39rQ.TS5RQ_UTcss5d.m6Rpg4Sb65v5qav1woiLPoG3bL1KUGzzwL W.zIJ6O7kj8Tet.gFn5zh9RoOh0emeb8CjqEdN62YLWRrt9WdoItibQDUyYIq.cDh6a6fAT.AcQt qU7Hb3cuhsfVN6_2XvZesUvxiIOS1OoEcDfsY8N4Cly1t1g1mpnNTg8GRWDae09Wt0oMBHxY3FR. 6N2M6v_vFi0.p2d0rKHQejyv9eQ0vBtq4k_qpAvDV0UIp_XRDaa7FHD0LqI8qdTeKYmZdZhtIYpJ Ha4em.A0oDHG5aXlrVqmH.f1_demme.RsWc39i.s0P1gdRFupQkYxgk7IfQ0Hq.VBkysoa5Ht3K. BmBD5CqNeBKPJRFqQQs2lvVezmu_R0PfJ1rmMKWk- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 10:02:10 +0000 Received: by smtp423.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 98c16acc2b02c264e7bc5cd030a2d329; Fri, 09 Oct 2020 10:02:06 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> Date: Fri, 9 Oct 2020 03:02:06 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C73X64DGgz48tX X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.31 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.78)[-0.780]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.04)[-1.036]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; 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]; 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: Fri, 09 Oct 2020 10:02:15 -0000 On 2020-Oct-8, at 23:01, Mark Millard wrote: > On 2020-Oct-8, at 21:29, Mark Millard wrote: >=20 >> On 2020-Oct-8, at 20:06, Mark Millard wrote: >>=20 >>> On 2020-Oct-8, at 06:27, Klaus Cucinauomo wrote: >>>=20 >>>>> Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm = : >>>>>=20 >>>>>=20 >>>>> The old u-boot/DTB combination in use does not have emmc2bus. >>>>> And, even if it did, FreeBSD would not use =E2=80=A6=E2=80=A6=E2=80=A6= . >>>>=20 >>>> =E2=80=A6 and the new 2020.10- combinations will even be more = annoying=E2=80=A6 >>>> While I meanwhile e.g. could boot the 4GB off of xhci, it hangs in = DeviceTree, >>>> Depending on GUESSED ;-) combinations and DeviceTree-patches in src = . >>>> There have to be necessary adjustments which are even not yet = upstreamed in u-boot=20 >>>> (depending on hw-revisions)=E2=80=A6and so on ... >>>> I doubt that anyone really will take explicitly time consuming care = of all that annoying RPI4-crap. >>>> I don't see any other way than targeting minimum 1 developer(better = more) ONLY to the RPI-platform=20 >>>> for a time period=E2=80=A6 other than leaving it crappy as is and = to be happy that it nevertheless=20 >>>> is a working fbsd-gadget :-) >>>=20 >>>=20 >>> Summary of probable-cause finding: u-boot 2020.10 is >>> expecting: >>>=20 >>> compatible =3D "brcm,generic-xhci" >>>=20 >>> instead of what seems to be in files that are in use >>> by FreeBSD: >>>=20 >>> compatible =3D "generic-xhci" >>>=20 >>> (I've no clue what all the other differences in the .dtb >>> file contents might be.) >>>=20 >>>=20 >>>=20 >>> The details of what I learned that reached that status . . . >>>=20 >>> I updated my ports environment on a RPi4 to build the final 2020.10 = u-boot >>> for the RPi4. I then built it and replaced the u-boot.bin on the = microsd >>> card that I boot with via the FreeBSD kernel being from that microsd = card >>> but later stages being from the USB3 SSD. I did not update anything = else. >>> So: still an older .dtb file. >>>=20 >>> That 8 GiByte RPi4B context booted just fine. >>>=20 >>> I then rebooted and had it stop in u-boot and looked around just a = little >>> bit. >>>=20 >>> U-Boot 2020.10 (Oct 09 2020 - 00:51:29 +0000) >>>=20 >>> DRAM: 7.9 GiB >>> RPI 4 Model B (0xd03114) >>> MMC: mmc@7e300000: 1, emmc2@7e340000: 0 >>> Loading Environment from FAT... In: serial >>> Out: vidconsole >>> Err: vidconsole >>> Net: eth0: ethernet@7d580000 >>> PCIe BRCM: link up, 5.0 Gbps x1 (SSC) >>> starting USB... >>> Bus xhci_pci: probe failed, error -110 >>> No working controllers found >>> Hit any key to stop autoboot: 0=20 >>>=20 >>> So it reproted the problem above. Yet . . . >>>=20 >>> U-Boot> pci 0 >>> Scanning PCI devices on bus 0 >>> BusDevFun VendorId DeviceId Device Class Sub-Class >>> _____________________________________________________________ >>> 00.00.00 0x14e4 0x2711 Bridge device 0x04 >>>=20 >>> U-Boot> pci 1 =20 >>> Scanning PCI devices on bus 1 >>> BusDevFun VendorId DeviceId Device Class Sub-Class >>> _____________________________________________________________ >>> 01.00.00 0x1106 0x3483 Serial bus controller 0x03 >>>=20 >>> So it does see the xHCI on the pci bus despite the >>> "Bus xhci_pci: probe failed, error -110". -110 looks >>> to be -ETIMEDOUT . >>>=20 >>> Looking at the v2020.10/drivers/usb/host/xhci-pci.c source >>> code shows that the xhci_pci driver has: >>>=20 >>> . . . >>> static const struct udevice_id xhci_pci_ids[] =3D { >>> { .compatible =3D "xhci-pci" }, >>> { } >>> }; >>>=20 >>> U_BOOT_DRIVER(xhci_pci) =3D { >>> .name =3D "xhci_pci", >>> .id =3D UCLASS_USB, >>> .probe =3D xhci_pci_probe, >>> .remove =3D xhci_deregister, >>> .of_match =3D xhci_pci_ids, >>> .ops =3D &xhci_usb_ops, >>> .platdata_auto_alloc_size =3D sizeof(struct usb_platdata), >>> .priv_auto_alloc_size =3D sizeof(struct xhci_ctrl), >>> .flags =3D DM_FLAG_ALLOC_PRIV_DMA, >>> }; >>>=20 >>> static struct pci_device_id xhci_pci_supported[] =3D { >>> { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_XHCI, ~0) }, >>> {}, >>> }; >>>=20 >>> U_BOOT_PCI_DEVICE(xhci_pci, xhci_pci_supported); >>>=20 >>> (It looks like the above driver is used as the default >>> driver if no explicit match is found. It has been around >>> for years.) >>>=20 >>>=20 >>> But, in the past when I showed the likes of fdt print / >>> or translation to a .dts file, it did not have "xhci-pci" >>> in compatible but had "generic-xhci" instead, such as: >>>=20 >>> xhci@7e9c0000 { >>> compatible =3D "generic-xhci"; >>> status =3D "disabled"; >>> reg =3D <0x00000000 0x7e9c0000 0x00000000 = 0x00100000>; >>> interrupts =3D <0x00000000 0x000000b0 = 0x00000004>; >>> phandle =3D <0x000000d3>; >>> }; >>>=20 >>> For reference, for FreeBSD there is: >>>=20 >>> # grep -ri "xhci-pci" /usr/src/sys/ | more >>> # grep -ri "generic-xhci" /usr/src/sys/ | more >>> /usr/src/sys/dev/usb/controller/generic_xhci_fdt.c: = {"generic-xhci", true}, >>> /usr/src/sys/gnu/dts/arm/bcm-nsp.dtsi: compatible =3D= "generic-xhci"; >>> /usr/src/sys/gnu/dts/arm/bcm5301x.dtsi: = compatible =3D "generic-xhci"; >>> /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: = compatible =3D "generic-xhci"; >>> /usr/src/sys/gnu/dts/arm64/broadcom/stingray/stingray-usb.dtsi: = compatible =3D "generic-xhci"; >>> /usr/src/sys/gnu/dts/arm64/marvell/armada-37xx.dtsi: = "generic-xhci"; >>> /usr/src/sys/gnu/dts/arm64/marvell/armada-cp11x.dtsi: = "generic-xhci"; >>> /usr/src/sys/gnu/dts/arm64/marvell/armada-cp11x.dtsi: = "generic-xhci"; >>>=20 >>> That FreeBSD generic_xhci_fdt.c match is from: >>>=20 >>> static struct ofw_compat_data compat_data[] =3D { >>> {"marvell,armada-380-xhci", true}, >>> {"marvell,armada3700-xhci", true}, >>> {"marvell,armada-8k-xhci", true}, >>> {"generic-xhci", true}, >>> {NULL, false} >>> }; >>>=20 >>> (End for-reference.) >>>=20 >>> There is another driver in u-boot 2020.10, one that >>> does mention "generic-" for xhci in >>> drivers/usb/host/xhci-brcm.c : >>>=20 >>> static const struct udevice_id xhci_brcm_ids[] =3D { >>> { .compatible =3D "brcm,generic-xhci" }, >>> { } >>> }; >>>=20 >>> U_BOOT_DRIVER(usb_xhci) =3D { >>> .name =3D "xhci_brcm", >>> .id =3D UCLASS_USB, >>> .probe =3D xhci_brcm_probe, >>> .remove =3D xhci_brcm_deregister, >>> .ops =3D &xhci_usb_ops, >>> .of_match =3D xhci_brcm_ids, >>> .platdata_auto_alloc_size =3D sizeof(struct = brcm_xhci_platdata), >>> .priv_auto_alloc_size =3D sizeof(struct xhci_ctrl), >>> .flags =3D DM_FLAG_ALLOC_PRIV_DMA, >>> }; >>>=20 >>> It is a new driver as of around 6 months ago and so is likely >>> the one created for the RPi4B context. >>>=20 >>> (Note the usb_xhci vs. xhci_brcm distinct namings of >>> the driver.) >>>=20 >>>=20 >>> The .dtb files that I use for uefi/ACPI booting of FreeBSD >>> and for u-boot based booting of ubuntu 2010.04.1 also use >>> "generic-xhci", no "brcm," invovled. >>>=20 >>> It seems that .dtb files that the u-boot folks expect for >>> the RPi4B are vintages/variations that have compatible >>> listing: "brcm,generic-xhci" . >>>=20 >>> If one finds a .dtb with such, it might be close to what >>> they were testing. With such a file, finding other >>> differences with the .dtb files currently in use with >>> FreeBSD could be done. >>>=20 >>> I hope that the above helps. >>=20 >> Looks like the u-boot.bin built includes "xhci-pci" >> but excludes "brcm,generic-xhci": not in the output >> of hd /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin >> after the port is installed. >>=20 >> My initial guess would be that something more needs >> to be specified to cause drivers/usb/host/xhci-brcm.c >> (and possibly more) to be built and included. >=20 > Looks like that was a bad guess, it still gets: >=20 > No working controllers found >=20 > based on instead having the "brcm,generic-xhci" > driver (with a "generic-xhci" added to the > compatibility list). Having reverted back to u-boot 2020.10 without compatibility list adjustments and with xhci-pci in place again, trying a 4 GiByte RPi4 without a microsd card boots as far as the rainbow square on the monitor but hangs there, never displaying even the: U-Boot 2020.10 (Oct 09 2020 - 06:50:04 +0000) notice. By contrast, booted via the microsd card I can stop it in u-boot 2020.10 and see things like: U-Boot> usb tree USB device tree: 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller=20 | +-2 Hub (480 Mb/s, 100mA) | USB2.0 Hub=20 | =20 +-3 Vendor specific (5 Gb/s, 72mA) | Realtek USB 10/100/1000 LAN 000000 | =20 +-4 Mass Storage (5 Gb/s, 0mA) OWC Envoy Pro mini So it gets farther with the 4 GiByte than with the 8 GiByte. But, for the "microsd card through kernel load" style of boot, I've discovered that I can use the more modern bcm2711-rpi-4-b.dtb that I use with uefi/ACPI booting for u-boot based booting as well. (This might have been true with the prior 2020.07 u-boot too. I did not go back and try it.) The implication is that the older versions of start4.elf and fixup4.dat are important for u-boot 2020.10 for some reason: having newer ones is what is different for failed microsd card based boots. The start4.elf and fixup4.dat that work with u-boot 2020.10 are too old for USB3 only based booting. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Oct 9 12:55:16 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 D63AF3F9C5B for ; Fri, 9 Oct 2020 12:55:16 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C77Mm5KStz4MD0 for ; Fri, 9 Oct 2020 12:55:16 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 956672B804 for ; Fri, 9 Oct 2020 12:55:16 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f182.google.com with SMTP id r8so7760079qtp.13 for ; Fri, 09 Oct 2020 05:55:16 -0700 (PDT) X-Gm-Message-State: AOAM531HUbeuFy3UcHtGJruAFSj2JAKnhXIxoK+36TKrVr8GYWSBtJdM Q/4wc9R32p46ysvUcby14CO4WV/B7F+rHMYkp7k= X-Google-Smtp-Source: ABdhPJx/MCJpi0rdrxms8SUB2jCRDxghNSKeew7qzJjbsuM2j/sOhUNeTk0uudCSCpxeAarYpy7qDA9SbODr/l3Vhwk= X-Received: by 2002:ac8:a0e:: with SMTP id b14mr13734012qti.242.1602248116137; Fri, 09 Oct 2020 05:55:16 -0700 (PDT) MIME-Version: 1.0 References: <32A8A046-56DF-4998-9C3D-8630ACCE4951@yahoo.com> <68AC0E4E-0469-46AE-BD68-058DCB6B078F@yahoo.com> In-Reply-To: <68AC0E4E-0469-46AE-BD68-058DCB6B078F@yahoo.com> From: Kyle Evans Date: Fri, 9 Oct 2020 07:55:03 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) To: Mark Millard Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" 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: Fri, 09 Oct 2020 12:55:16 -0000 On Thu, Oct 8, 2020 at 3:16 PM Mark Millard wrote: > > > > On 2020-Oct-8, at 12:32, Kyle Evans wrote: > > > On Thu, Oct 8, 2020 at 2:28 PM Mark Millard wrote: > >> > >> > >> > >> On 2020-Oct-8, at 11:34, Kyle Evans wrote: > >> > >> Note: For the below I looked at 3 separate RPi4B > >> examples, using u-boot print fdt / when I could > >> or translating the dtb to a dts otherwise. One > >> of the examples is from one of ubuntu 2020.04.1's > >> RPi4B specific builds. The others I use with FreeBSD, > >> one for u-boot and one for uefi/ACPI. > >> > >> ( > >> > >> cpu_addr is sized via the global: > >> > >> / { > >> > >> #address-cells = <0x2>; > >> > >> and the dma_addr and max_len by more local definitions, > >> such as in: > >> > >> #address-cells = <0x1>; > >> #size-cells = <0x1>; > >> compatible = "simple-bus"; > >> dma-ranges = <0xc0000000 0x0 0x0 0x40000000>; > >> > >> and: > >> > >> #address-cells = <0x2>; > >> #size-cells = <0x2>; > >> compatible = "simple-bus"; > >> dma-ranges = <0x0 0x0 0x0 0x0 0x4 0x0>; > >> > >> Note that the above has #size-cells varying when: > >> 4 <= number of cells in dma-range . There will be > >> worse cases later, below. > >> > >> and: > >> > >> #address-cells = <0x3>; > >> #interrupt-cells = <0x1>; > >> #size-cells = <0x2>; > >> . . . > >> dma-ranges = <0x2000000 0x0 0x0 0x0 0x0 0x0 0xc0000000>; > >> > >> (The #address-cells being 3 indicates a bit mask as the first of the 3, > >> the bit mask indicating extra information about the context.) > >> > >> and: > >> > >> #address-cells = <0x2>; > >> #size-cells = <0x1>; > >> compatible = "simple-bus"; > >> dma-ranges = <0x0 0xc0000000 0x0 0x0 0x40000000>; > >> > >> and: > >> > >> #address-cells = <0x1>; > >> #size-cells = <0x2>; > >> compatible = "simple-bus"; > >> dma-ranges = <0x0 0x0 0x0 0x4 0x0>; > >> > >> Note that for the last 2 examples above the number of cells > >> in the dma-range (5) is not sufficient to indicate the value > >> for #size-cells or #(dma-addr-cells) without presuming some > >> other context to disambiguate. > >> > >> > >> There is also an example of just: > >> > >> dma-ranges; > >> > >> (in firmware { . . . }). > >> > >>>> We'll see 4 and 5 value variants of this because 64-bit addresses are > >>>> described with pairs of 32-bit values. > >>>> > >>>> 4-value variant: dma_addr will be 32-bit, cpu_addr will be 64-bit > >>>> 5-value variant: both are 64-bit > >> > >> There is an example shown above with 5-value having #size_cells > >> being 1 (32-bit) [and dma-addr being 64 bit (cells 2)] instead of > >> #size_cells being 2 (64-bit) [and dma_addr being 32-bit (cells 1)]. > >> > >>>> Note that bcm283x_dmabus_peripheral_lowaddr() will be returning > >>>> cpu_addr + (max_len - 1) > >>>> > >>>> This won't match perfectly with what we currently return, but it will > >>>> be more accurate. > >>> > >>> Here's a patch that I hacked out and can't test for quite a while yet, > >>> feel free to give it a shot: > >>> https://people.freebsd.org/~kevans/bcm2835_vcbus.diff -- the best > >>> guarantee I can give you is that it builds. We'll need to test it on > >>> both RPi4 models with the separate bus and the original RPi4s, as well > >>> as an RPi3 and RPi2/0w. > >> > >> See above about trying to use the number of cells in a dma-ranges > >> to figure out the sizes of #size-cells or #(dma-addr-cells). > >> > > > > Yeah, Ian pointed out just a little bit ago the way this should be > > done correctly. The hacky patch should at least get it correct enough > > for now, then I can write a more generic version of dma-ranges parsing > > that does it correctly. > > Okay. > > Another type of overall issue (that may not apply to > the specific context here) is dtb content like: > > scb { > compatible = "simple-bus"; > #address-cells = <0x00000002>; > #size-cells = <0x00000002>; > ranges = * 0x0000000007ef8a18 [0x00000060]; > dma-ranges = <0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0xfc000000 0x00000001 0x00000000 0x00000001 0x00000000 0x00000001 0x00000000>; > phandle = <0x000000d0>; > pcie@7d500000 { > compatible = "brcm,bcm2711-pcie"; > . . . > #address-cells = <0x00000003>; > #interrupt-cells = <0x00000001>; > #size-cells = <0x00000002>; > . . . > dma-ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0xc0000000>; > . . . > }; > . . . > > where the inner most dma-ranges is not from the just-surrounding > context (parent) but is strictly local (despite the parent > potentially also having dma-ranges). I think that only pcie@... > is that way so far for the RPi4 --but notationally it seems to > be generally allowed. > This is irrelevant for the time being as the PCI driver doesn't cross paths with the snippet the patch touches. Thanks, Kyle Evans From owner-freebsd-arm@freebsd.org Fri Oct 9 12:55:35 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 0791B3F9F9B for ; Fri, 9 Oct 2020 12:55:35 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C77N63wmFz4MMF; Fri, 9 Oct 2020 12:55:34 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-ed1-x541.google.com with SMTP id x1so9237554eds.1; Fri, 09 Oct 2020 05:55:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=K+s0jwHd6pxf9sQ/v8cRhYb8ZXcidvYNBMGewhhL+H4=; b=nU4xAo86SRRi0cW0d/KLfcdpNZ/GrSwG0ohlyZI+p5BH1qhGNZRhSs6rx5QKgoVCWI iRE+KO2Rafvycg+X7jlNsn3mlu+CWNCtEe9KG/+ZIdr9dFP75cXK8VXfgqIk31wOCds9 yJIYnmv8GzeA//MnAGg/lHijYjXnX6E2EQ2zPJ70l/xLIy59zAfeBHQ5lgiEYLZEPCDb Wj41BifNqkVHiin5lUinxr4HdOa3wSU/vNLlNQkVZXU5ZXo4TFNX5A4Ij6aRE3Isb/jL jXxmHXW/hn7K1j2G1lFNh2vAmoSnDV/GJSmEAbpiTRm3e05mtttpcirwRmoZ1ruzx4jk 7bUw== X-Gm-Message-State: AOAM5312UsMV3BlX4GwlEXzD9TwWjj5BP5X4f24ozGfuu9soJOqIQF4d Nv/Kqdr9lgkiN80/vweYnpkXSIqwF+w= X-Google-Smtp-Source: ABdhPJxWzaVhVxBqgYSYX9yI3VtmPrrXqRgK46B8gYnIyZKq6kZus/YSZQMMvKr9MKEYQVfpEF+IaQ== X-Received: by 2002:a5d:468f:: with SMTP id u15mr830043wrq.154.1602247821758; Fri, 09 Oct 2020 05:50:21 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-106-131.46.114.pool.telefonica.de. [46.114.106.131]) by smtp.googlemail.com with ESMTPSA id w11sm12035814wrn.27.2020.10.09.05.50.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 05:50:20 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Date: Fri, 9 Oct 2020 14:50:16 +0200 References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> To: Mark Millard , freebsd-arm@freebsd.org, Kyle Evans In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C77N63wmFz4MMF X-Spamd-Bar: +++++++ X-Spamd-Result: default: False [7.25 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,body]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(0.00)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.27)[-0.268]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[46.114.106.131:received]; R_DKIM_ALLOW(0.00)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.106.131:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.99)[0.995]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[0.0.0.0:email]; NEURAL_SPAM_LONG(1.02)[1.024]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::541:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-Spam: Yes 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: Fri, 09 Oct 2020 12:55:35 -0000 > Am 09.10.2020 um 12:02 schrieb Mark Millard : >=20 >=20 >=20 > On 2020-Oct-8, at 23:01, Mark Millard wrote: >=20 >> On 2020-Oct-8, at 21:29, Mark Millard wrote: >>=20 >>> On 2020-Oct-8, at 20:06, Mark Millard wrote: >>>=20 >>>> On 2020-Oct-8, at 06:27, Klaus Cucinauomo wrote: >>>>=20 >>>>>> Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm = : >>>>>>=20 >=20 > Having reverted back to u-boot 2020.10 without > compatibility list adjustments and with xhci-pci > in place again, trying a 4 GiByte RPi4 without a > microsd card boots as far as the rainbow square > on the monitor but hangs there, never displaying > even the: >=20 > U-Boot 2020.10 (Oct 09 2020 - 06:50:04 +0000) >=20 >=20 >=20 the following `dmesg` of the 4GB is with the copied-over whole = msdos-partition of the Original RPI-ubuntu-distribution /ubuntu DOESN`T use the latest fw-files from rpi-github(which also fail = with me to the hdmi-rainbow-screen), Copying over =E2=80=9Eour=E2=80=9C old bcm2711-rpi-4-b.dtb, booted a bit = more (until gpio or so afaik)=E2=80=A6.it`s all about DeviceTree=20 and I guess Kyle Evans & friends unfortunately will have more = adjustment-work in the brcm285..dtsi=E2=80=A6 for 2020.10 I unfortunately totally fail in my time-management but will tell more = about the 8GB - VL805-videoCore-firmware-thing when finding time..=20 I didn=E2=80=99t yet apply kevans-patches, will test them it later.. Directly from SSD(no SD-card inserted): =E2=80=94-config.txt : =E2=80=94 arm_control=3D0x200 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don enable_uart=3D1 uart_2ndstage=3D1 dtoverlay=3Dminiuart-bt dtoverlay=3Dmmc dtoverlay=3Dpwm device_tree_address=3D0x4000 kernel=3Du-boot.bin =E2=80=94-------------------------------------------------- recover4.elf not found (6) recovery.elf not found (6) HUB [03:01] 2.00 000003:01 init port 1 speed 3 DEV [05:03] 2.00 000013:01 class 9 VID 045b PID 0209 HUB init [05:03] 2.00 000013:01 Read start4.elf bytes 2272992 hnd 0x000002e7 hash '319662b44a4c80d5' Read fixup4.dat bytes 5405 hnd 0x000001bf hash '0c1a6c6f96114a3f' 0x00c03111 0x00000000 0x0000001f MEM GPU: 76 ARM: 947 TOTAL: 1023 Starting start4.elf @ 0xfeb00200 partition 0 U-Boot 2020.10-rc5 (Oct 05 2020 - 03:08:23 +0000) DRAM: 3.9 GiB RPI 4 Model B (0xc03111) MMC: mmc@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 8 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0=20 Card did not respond to voltage select! Device 0: Vendor: JMicron Rev: 3202 Prod: Tech =20 Type: Hard Disk Capacity: 114473.4 MB =3D 111.7 GB (234441648 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@7e300000.blk... Disk mmc@7e300000.blk not ready Card did not respond to voltage select! Scanning disk emmc2@7e340000.blk... Disk emmc2@7e340000.blk not ready Scanning disk usb_mass_storage.lun0... ** Unrecognized filesystem type ** Found 3 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image 688192 bytes read in 6 ms (109.4 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi Consoles: EFI console =20 Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Jun 11 07:40:35 UTC 2020 root@releng1.nyi.freebsd.org) Command line arguments: loader.efi Image base: 0x39d83000 EFI version: 2.80 EFI Firmware: Das U-Boot (rev 8224.4096) Console: comconsole (0) Load Path: /efi\boot\bootaa64.efi Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)= /UsbClass(0x152d,0x578,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)= /UsbClass(0x152d,0x578,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) Setting currdev to disk0p1: Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)= /UsbClass(0x152d,0x578,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x76da839) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local Loading kernel... /boot/kernel/kernel text=3D0x2a8 text=3D0x7a7060 text=3D0x1b0d9c = data=3D0x194600 data=3D0x0+0x302da6 syms=3D[0x8+0x178ba8+0x8+0x156776] Loading configured modules... /boot/kernel/umodem.ko text=3D0x1be0 text=3D0xfb0 data=3D0x618+0x8 = syms=3D[0x8+0xe40+0x8+0xa8c] /etc/hostid size=3D0x25 /boot/entropy size=3D0x1000 Hit [Enter] to boot immediately, or any other key for command prompt. Type '?' for a list of commands, 'help' for more detailed help. OK boot Using DTB provided by EFI at 0x7ef1000. EFI framebuffer information: addr, size 0x3e3dc000, 0x6d8c00 dimensions 1824 x 984 stride 1824 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 ---<>--- KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #39 a1d832e8c08-c271678(master): Fri Jul 17 = 04:56:52 UTC 2020 root@generic:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG = arm64 FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.0-rc2-0-g414f32a9e86) VT(efifb): resolution 1824x984 module firmware already present! KLD file umodem.ko is missing dependencies real memory =3D 4146876416 (3954 MB) avail memory =3D 4023062528 (3836 MB) Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface MAP 39e34000 mode 2 pages 1 MAP 39e38000 mode 2 pages 3 MAP 39e3c000 mode 2 pages 4 MAP 3b250000 mode 2 pages 16 MAP fe100000 mode 0 pages 1 WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD = 13.0. kbd0 at kbdmux0 WARNING: Device "openfirm" is Giant locked and may be deleted before = FreeBSD 13.0. ofwbus0: simplebus0: on ofwbus0 ofw_clkbus0: on ofwbus0 clk_fixed0: on ofw_clkbus0 clk_fixed1: on ofw_clkbus0 clk_fixed2: on ofwbus0 simplebus1: on ofwbus0 regfix0: on ofwbus0 regfix1: on ofwbus0 simplebus2: on ofwbus0 simplebus3: on ofwbus0 regfix2: on ofwbus0 simple_mfd0: mem = 0x7d5d2000-0x7d5d2eff on simplebus0 psci0: on ofwbus0 gic0: mem = 0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460= 00-0x40047fff irq 31 on simplebus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256 gpio0: mem 0x7e200000-0x7e2000b3 irq = 15,16 on simplebus0 gpiobus0: on gpio0 mbox0: mem 0x7e00b880-0x7e00b8bf irq 14 on = simplebus0 bcm2835_firmware0: on simplebus0 gpio1: on bcm2835_firmware0 gpiobus1: on gpio1 gpioregulator0: on ofwbus0 generic_timer0: irq 4,5,6,7 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000 usb_nop_xceiv0: on ofwbus0 gpioc0: on gpio0 uart0: mem 0x7e201000-0x7e2011ff irq 17 on = simplebus0 uart0: console (115200,n,8,1) spi0: mem 0x7e204000-0x7e2041ff irq 19 on = simplebus0 spibus0: on spi0 spibus0: at cs 0 mode 0 spibus0: at cs 1 mode 0 uart1: mem 0x7e215040-0x7e21507f irq 22 on = simplebus0 iichb0: mem 0x7e804000-0x7e804fff irq 27 = on simplebus0 bcm_dma0: mem 0x7e007000-0x7e007aff irq = 32,33,34,35,36,37,38,39,40,41,42 on simplebus0 bcmwd0: mem = 0x7e100000-0x7e100113,0x7e00a000-0x7e00a023,0x7ec11000-0x7ec1101f on = simplebus0 gpioc1: on gpio1 sdhci_bcm0: mem 0x7e300000-0x7e3000ff = irq 63 on simplebus0 mmc0: on sdhci_bcm0 fb0: on simplebus0 fb0: keeping existing fb bpp of 32 fbd0 on fb0 WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD = 13.0. VT: Replacing driver "efifb" with new "fb". fb0: 1824x984(1824x984@0,0) 32bpp fb0: fbswap: 1, pitch 7296, base 0x3e3dc000, screen_size 7237632 pmu0: irq 0,1,2,3 on ofwbus0 cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 pcib0: mem = 0x7d500000-0x7d50930f irq 69,70 on simplebus1 pcib0: hardware identifies as revision 0x304. pci0: on pcib0 pcib1: irq 81 at device 0.0 on pci0 pci1: on pcib1 bcm_xhci0: irq 82 at = device 0.0 on pci1 bcm_xhci0: 32 bytes context size, 64-bit DMA usbus0 on bcm_xhci0 genet0: mem 0x7d580000-0x7d58ffff irq 71,72 on = simplebus1 genet0: GENET version 5.0 phy 0x0000 miibus0: on genet0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto genet0: Ethernet address: dc:a6:32:21:e9:57 gpioled0: on ofwbus0 sdhci_bcm1: mem 0x7e340000-0x7e3400ff = irq 80 on simplebus3 mmc1: on sdhci_bcm1 =E2=80=94- hanging here=E2=80=94 just GUESSING ;-) (absolutely NO proof:-): It comes to boot problems short before xhci will be initialized from the = DeviceTree From owner-freebsd-arm@freebsd.org Fri Oct 9 13:21:53 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 2BDD53FAB0F for ; Fri, 9 Oct 2020 13:21:53 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C77yT09cTz4Nn7; Fri, 9 Oct 2020 13:21:52 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x344.google.com with SMTP id d3so9840609wma.4; Fri, 09 Oct 2020 06:21:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=14rYlWnHFaSl1vieqKoCJgfxDEureQaYneHqh7eGbj0=; b=Ls1Y0htq18ANrBl7V79UHQ79mcoIeffPEDbBCzBSRaTXc0Lv4GXpBD2vurbxGPFqnU wFQSs/WZ/4unzZmtZbR+P9h/0RgPJqbGLN06GhosVNfjAhjJg/CNdTITDkrBdmPQ6oG8 7Sgq5weKaIJ/PkwVGcLBcscVb6bCCAEMZNHGtgfVI5jL8nuKbPc1Ddnl3PyfB/JAG/dc 7PpAntaq6zezuXQEAzI2h9ntSVQJMEXyWPIrXAFjhKnne+696oPkBwVaF1BmbzNQZiyv 2P0Xg80TqnazAKCWJa0r0WoVDb1lVclOg57ErzEahXE+HZ+kDVMqulo0x4jeCONwlhy3 U0gQ== X-Gm-Message-State: AOAM530DtUk+d0U6JXq/fr+qgfHVPArNhWyoUUrIqS0IkmVYW6YylHoq ipIb1jabKe+Oqv1HyuOBoT4mGB192zQ= X-Google-Smtp-Source: ABdhPJwMHftD+Rj+AhF4hXCRL2q699jBz8bfkHSTo8SDF75hQI+DU3dsvRp0JHbJuxqzQDwYWJwGag== X-Received: by 2002:a1c:f20f:: with SMTP id s15mr14324110wmc.69.1602249711399; Fri, 09 Oct 2020 06:21:51 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-106-131.46.114.pool.telefonica.de. [46.114.106.131]) by smtp.googlemail.com with ESMTPSA id n2sm11663368wma.29.2020.10.09.06.21.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 06:21:50 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Date: Fri, 9 Oct 2020 15:21:48 +0200 References: <32A8A046-56DF-4998-9C3D-8630ACCE4951@yahoo.com> <68AC0E4E-0469-46AE-BD68-058DCB6B078F@yahoo.com> To: Kyle Evans , freebsd-arm@freebsd.org, Mark Millard In-Reply-To: Message-Id: <9D391B40-894C-4D18-B0BD-F5A03734290A@googlemail.com> X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C77yT09cTz4Nn7 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; REPLY(-4.00)[] 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: Fri, 09 Oct 2020 13:21:53 -0000 > Am 09.10.2020 um 14:55 schrieb Kyle Evans : >>>>=20 >>=20 >> Another type of overall issue (that may not apply to >> the specific context here) is dtb content like: >>=20 >> scb { >> compatible =3D "simple-bus"; >> #address-cells =3D <0x00000002>; >> #size-cells =3D <0x00000002>; >> ranges =3D * 0x0000000007ef8a18 [0x00000060]; >> dma-ranges =3D <0x00000000 0x00000000 0x00000000 = 0x00000000 0x00000000 0xfc000000 0x00000001 0x00000000 0x00000001 = 0x00000000 0x00000001 0x00000000>; >> phandle =3D <0x000000d0>; >> pcie@7d500000 { >> compatible =3D "brcm,bcm2711-pcie"; >> . . . >> #address-cells =3D <0x00000003>; >> #interrupt-cells =3D <0x00000001>; >> #size-cells =3D <0x00000002>; >> . . . >> dma-ranges =3D <0x02000000 0x00000000 = 0x00000000 0x00000000 0x00000000 0x00000000 0xc0000000>; >> . . . >> }; >> . . . >>=20 >> where the inner most dma-ranges is not from the just-surrounding >> context (parent) but is strictly local (despite the parent >> potentially also having dma-ranges). I think that only pcie@... >> is that way so far for the RPi4 --but notationally it seems to >> be generally allowed. >>=20 >=20 > This is irrelevant for the time being as the PCI driver doesn't cross > paths with the snippet the patch touches. >=20 > Thanks, >=20 > Kyle Evans >=20 Yes, dma is another topic=E2=80=A6 thanks for working on RPI again !, external links to the xhci-initializiation - issue for the 8GB-model in = u-boot 2020.10 : = http://u-boot.10912.n7.nabble.com/PATCH-v6-0-4-usb-xhci-Load-Raspberry-Pi-= 4-VL805-s-firmware-td418114.html = https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2205783.html = https://patchwork.ozlabs.org/project/linux-pci/patch/20200629161845.6021-4= -nsaenzjulienne@suse.de/ = https://patchwork.ozlabs.org/project/linux-pci/patch/20200629161845.6021-5= -nsaenzjulienne@suse.de/ `guess there will be some other DeviceTree-adjustments needed to boot = directly off of an SSD until reaching the root-login. Regards K.= From owner-freebsd-arm@freebsd.org Fri Oct 9 19:25:36 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 62894429D80 for ; Fri, 9 Oct 2020 19:25:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4C7J2715QGz4lYK for ; Fri, 9 Oct 2020 19:25:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: m3JAV1YVM1kRUiNoycENSvZbUNEVOU2d3MKo9JGZholJx.tZh0ddhrFUHeROmq5 g9yz14zCIKhpX07xtEUxnXDnUYFNovkNx9kw9itN1SB6iqLeliorySPnvopqdkhF2DY7zejysgWc 0JRL9VrUQi2HfwCXouwwd_Css3KVfahTVprgMt1WqdPWyaQZxFDgSv3IDHvOfAOj1yxtNUdEorIX VrDtH6joUUJgufrpOFDgqImbsvjpmyRiyx4tjhtb_AaBQk0qK6ANBhYKcuiwoOsQyjc1lHphWXxW TEUGmwM8VlaSKq.tlH2W9C5JwiTVqVAawTWdPCMr.Abr9FRATOiXYfz_Gv4eSYUhQiBfVkiteByy _d5izp80ueC0USmD7LuV5DY6PsfZq.4YlIjzem04NCe98v2jkr69Wl8E8a4NVzyPscng1slvrdDg V4VtzYKjyDHDj1_fssLhZjVd4odjgQR1J1Z1eBGeDFYH6Fa9PDGyMTxTKRdXsC168s_ZO.TUaP8p xDQ5yWCY4QIv4NZWYVZydhbCgyGIKR2WKktgiFprSVxIP1Wa62SrB7lnt4DwhC2sr96zpl9P8Ew1 kqmdcG7xMC7GJG5hIJAQksYyU0gcvb5KxsHjZRzuOw9imCWxpL5FFDgtyQFj9riQq4POuMJDWWJ2 WXKuQP5wtOydIXC9xa6B6FruCtKbW1F1cAMURoWBVyiJvgiMxiHIP_3nd7PMnA7Hy6I.TIlcX2BO 0KUSjfIraFC6Xa5J0dPJEQrDybhLNFClg8vFYOQIclBY7GmUBEKuPVkN6_8ufnfiWip76EQ7ssAl KpVET2fo1ErWQSbFr5kFmrXDFTUSveaZyG5P5wN1ndICcRsQ3H3q73brYr3OjWekOccJrc4kV5E8 MuUdflVEuuVxSodkJi8qyWDTgh4Tw4MaWMp4NNig6iWrkYCDmIuJnuYp8m._QysQ.3i3.KUJMK42 3J4A2UZ0tgd76emiROQooRfBEx9.Gdtu.efAtkEXd0JZv.xkTSUxolrPuCP17fNioCyfC18HJubq RDXJ.Nbr8edAuPFNGLU49m0RS7_vJHa6blMU.hh84gBwcgm66YoOpn1X0plKQxjTRMXoRrNPtY7v hjOimR0i5edZ6J8F61pbwIR_kyvJHW56aYtIJJDLiOAx3oXCx0TtlFKM_dhX8200Uu4at1gtOiVS UtwNQVY2jcKBnqBmbj7WaZVzRLG0LGMp2KfC9lBCImG0PVtYm3oDsIGqnYIYdn7wg9VlhVH_FlfZ q4AKj0nwazrtLZ4rHX78YJkbQ.bFIO1rkoWNnyPlF8FpFSPYnWRxfDkbe1WW71QlOivUYcXWWrRj bKzbouL.U1D69g9V3LomCueNp.tvxbvM6S62caXnz.vQrVYxhyOiiNY0PIHGitSahPGbDUevGUdl 6ZfQypK_BMKleyHppfcyiLc6_5dqbqx810a6QygYsTJKh1L.lHvcB9r.N2GFf8VPrl6wsrypOhDj Q8Q9R7T._RR7A7g0P5GAElkPTWJBzwV_fQbqibfU_h5XYDZfhvaSRDAOvkFJ32aN3HN5XZGodAB9 DZtaT Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 19:25:31 +0000 Received: by smtp409.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7c37f04c39031a88eb55b18939c9dd7b; Fri, 09 Oct 2020 19:25:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: Date: Fri, 9 Oct 2020 12:25:25 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C7J2715QGz4lYK X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.55 / 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:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.03)[-1.027]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.04)[-1.035]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.991]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; 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: Fri, 09 Oct 2020 19:25:36 -0000 On 2020-Oct-9, at 05:50, Klaus Cucinauomo = wrote: >> Am 09.10.2020 um 12:02 schrieb Mark Millard : >>=20 >>=20 >>=20 >> On 2020-Oct-8, at 23:01, Mark Millard wrote: >>=20 >>> On 2020-Oct-8, at 21:29, Mark Millard wrote: >>>=20 >>>> On 2020-Oct-8, at 20:06, Mark Millard wrote: >>>>=20 >>>>> On 2020-Oct-8, at 06:27, Klaus Cucinauomo wrote: >>>>>=20 >>>>>>> Am 08.10.2020 um 11:01 schrieb Mark Millard via freebsd-arm = : >>>>>>>=20 >>=20 >> Having reverted back to u-boot 2020.10 without >> compatibility list adjustments and with xhci-pci >> in place again, trying a 4 GiByte RPi4 without a >> microsd card boots as far as the rainbow square >> on the monitor but hangs there, never displaying >> even the: >>=20 >> U-Boot 2020.10 (Oct 09 2020 - 06:50:04 +0000) >>=20 >>=20 >>=20 >=20 >=20 >=20 > the following `dmesg` of the 4GB is with the copied-over whole = msdos-partition of the Original RPI-ubuntu-distribution > /ubuntu DOESN`T use the latest fw-files from rpi-github(which also = fail with me to the hdmi-rainbow-screen) Linux has its own dts/dtsi/... sources instead of using the .dtb files from the RPi folks, not directly based on any vintage of the RPi .dtb files if I understand right. As I understand, ubuntu is based on the linux materials for producing .dtb files and so is likely not a full match to older rpi .dtb files either. They continue to update the .dtb's that they distribute, without also updating the start*.elf or fixup*.dat files. So far as I know, FreeBSD has been targeting support of some vintage of the RPi materials, including .dtb files. That is what sysutils/rpi-firmware is about. So the status relative to linux .dtb files is likely normally-unknown. I've not set up a USB3 SSD ubuntu 2020.04.1 (yet?), just a microsd card one. I use apt to update the ubuntu microsd card once and a while. It's /boot/firmware/ from a recent update currently looks like: # ls -lat /boot/firmware/ total 59854 drwxr-xr-x 4 root root 4096 Oct 8 22:46 .. drwxr-xr-x 2 root root 35328 Oct 8 22:46 overlays -rwxr-xr-x 1 root root 26516 Oct 8 22:46 bcm2710-rpi-2-b.dtb -rwxr-xr-x 1 root root 28176 Oct 8 22:46 bcm2710-rpi-3-b-plus.dtb -rwxr-xr-x 1 root root 27557 Oct 8 22:46 bcm2710-rpi-3-b.dtb -rwxr-xr-x 1 root root 26371 Oct 8 22:46 bcm2710-rpi-cm3.dtb -rwxr-xr-x 1 root root 46612 Oct 8 22:46 bcm2711-rpi-4-b.dtb -rwxr-xr-x 1 root root 19924 Oct 8 22:46 bcm2837-rpi-3-a-plus.dtb -rwxr-xr-x 1 root root 20793 Oct 8 22:46 bcm2837-rpi-3-b-plus.dtb -rwxr-xr-x 1 root root 20373 Oct 8 22:46 bcm2837-rpi-3-b.dtb -rwxr-xr-x 1 root root 19700 Oct 8 22:46 bcm2837-rpi-cm3-io3.dtb -rwxr-xr-x 1 root root 2603 Oct 8 22:46 boot.scr -rwxr-xr-x 1 root root 29276839 Oct 8 22:46 initrd.img -rwxr-xr-x 1 root root 1371 Oct 8 22:46 overlay_map.dtb -rwxr-xr-x 1 root root 8306930 Oct 8 22:46 vmlinuz -rwxr-xr-x 1 root root 251 Sep 26 22:14 usercfg.txt -rwxr-xr-x 1 root root 1514 Jul 31 16:48 README -rwxr-xr-x 1 root root 52480 Jul 31 16:48 bootcode.bin -rwxr-xr-x 1 root root 141 Jul 31 16:48 cmdline.txt -rwxr-xr-x 1 root root 1117 Jul 31 16:48 config.txt -rwxr-xr-x 1 root root 7276 Jul 31 16:48 fixup.dat -rwxr-xr-x 1 root root 5405 Jul 31 16:48 fixup4.dat -rwxr-xr-x 1 root root 3146 Jul 31 16:48 fixup4cd.dat -rwxr-xr-x 1 root root 8417 Jul 31 16:48 fixup4db.dat -rwxr-xr-x 1 root root 8419 Jul 31 16:48 fixup4x.dat -rwxr-xr-x 1 root root 3146 Jul 31 16:48 fixup_cd.dat -rwxr-xr-x 1 root root 10265 Jul 31 16:48 fixup_db.dat -rwxr-xr-x 1 root root 10265 Jul 31 16:48 fixup_x.dat -rwxr-xr-x 1 root root 240 Jul 31 16:48 meta-data -rwxr-xr-x 1 root root 770 Jul 31 16:48 network-config -rwxr-xr-x 1 root root 2997088 Jul 31 16:48 start.elf -rwxr-xr-x 1 root root 2272992 Jul 31 16:48 start4.elf -rwxr-xr-x 1 root root 816124 Jul 31 16:48 start4cd.elf -rwxr-xr-x 1 root root 3774532 Jul 31 16:48 start4db.elf -rwxr-xr-x 1 root root 3031652 Jul 31 16:48 start4x.elf -rwxr-xr-x 1 root root 816124 Jul 31 16:48 start_cd.elf -rwxr-xr-x 1 root root 4846308 Jul 31 16:48 start_db.elf -rwxr-xr-x 1 root root 3755236 Jul 31 16:48 start_x.elf -rwxr-xr-x 1 root root 327 Jul 31 16:48 syscfg.txt -rwxr-xr-x 1 root root 493528 Jul 31 16:48 uboot_rpi_3.bin -rwxr-xr-x 1 root root 492824 Jul 31 16:48 uboot_rpi_4.bin -rwxr-xr-x 1 root root 2114 Jul 31 16:48 user-data drwxr-xr-x 3 root root 4096 Jan 1 1970 . (I try to remember to do things in a way that preserves the original file dates. But, whatever update procedures do, I do not override.) One thing of note is the use of an "overlay_map.dtb". Without that things would likely be broken. Notably the start*.elf and fixup*.dat files all predate 2020-Aug-20 by a fair amount. ("USB MSD boot also requires the firmware from Raspberry Pi OS 2020-08-20 or newer.") But ubuntu need not have used a tagged release at all so it is not obvious just what vintage the start* and fixup* files are from. So, for now, ubuntu likely does not claim support of the critical release (general release) of the USB MSD ability for the RPI4 (even given modern enough eeprom contents are present). So far, I've never tried to have FreeBSD use any of these materials --or any materials from ubuntu. > , > Copying over =E2=80=9Eour=E2=80=9C old bcm2711-rpi-4-b.dtb, My FreeBSD head -r365932 "USB3 SSD only boot" context looks like (set up for uefi/ACPI booting): # ls -ldTt /usb_efi/* -rwxr-xr-x 1 root wheel 274 Oct 9 02:00:34 2020 = /usb_efi/config.txt -rwxr-xr-x 1 root wheel 182 Oct 9 00:26:10 2020 = /usb_efi/config.txt.ub -rwxr-xr-x 1 root wheel 571840 Oct 8 23:55:06 2020 = /usb_efi/u-boot.bin -rwxr-xr-x 1 root wheel 257 Sep 26 12:08:22 2020 = /usb_efi/config.txt.uefi_m_m drwxr-xr-x 1 root wheel 8192 Sep 7 22:48:50 2020 = /usb_efi/OVERLAYS -rwxr-xr-x 1 root wheel 47516 Sep 1 14:04:10 2020 = /usb_efi/bcm2711-rpi-4-b.dtb -rwxr-xr-x 1 root wheel 2283936 Sep 1 14:04:08 2020 = /usb_efi/start4.elf -rwxr-xr-x 1 root wheel 2283936 Sep 1 14:04:08 2020 = /usb_efi/start4.elf.new -rwxr-xr-x 1 root wheel 5422 Sep 1 14:04:04 2020 = /usb_efi/fixup4.dat -rwxr-xr-x 1 root wheel 5422 Sep 1 14:04:04 2020 = /usb_efi/fixup4.dat.new -rwxr-xr-x 1 root wheel 5252 Sep 1 13:59:48 2020 = /usb_efi/Readme.md -rwxr-xr-x 1 root wheel 5252 Sep 1 13:59:48 2020 = /usb_efi/Readme.md.new -rwxr-xr-x 1 root wheel 206 Sep 1 13:59:48 2020 = /usb_efi/config.txt.uefi_orig -rwxr-xr-x 1 root wheel 2581149 Sep 1 07:14:20 2020 = /usb_efi/RPi4_UEFI_Firmware_v1.20.zip -rwxr-xr-x 1 root wheel 2031616 Sep 1 07:08:52 2020 = /usb_efi/RPI_EFI.fd -rwxr-xr-x 1 root wheel 2277248 Jul 14 16:01:00 2020 = /usb_efi/start4.elf.old -rwxr-xr-x 1 root wheel 5409 Jul 14 16:00:58 2020 = /usb_efi/fixup4.dat.old -rwxr-xr-x 1 root wheel 4592 Jul 14 15:57:48 2020 = /usb_efi/Readme.md.old -rwxr-xr-x 1 root wheel 205 May 24 14:46:42 2020 = /usb_efi/config.txt.nobt -rwxr-xr-x 1 root wheel 5888 Jan 30 13:26:30 2020 = /usb_efi/armstub8-gic.bin -rwxr-xr-x 1 root wheel 18693 Nov 22 09:06:44 2019 = /usb_efi/COPYING.linux -rwxr-xr-x 1 root wheel 1594 Nov 22 09:06:44 2019 = /usb_efi/LICENCE.broadcom drwxr-xr-x 1 root wheel 8192 Sep 27 21:05:00 2018 /usb_efi/EFI My FreeBSD head -r365932 "microsd card first stages" context looks like (set up for u-boot 2020.10 booting): # ls -ldTt /microsd_efi/* -rwxr-xr-x 1 root wheel 258 Oct 9 02:02:00 2020 = /microsd_efi/config.txt -rwxr-xr-x 1 root wheel 571840 Oct 8 23:55:06 2020 = /microsd_efi/u-boot.bin -rwxr-xr-x 1 root wheel 182 Oct 4 14:18:00 2020 = /microsd_efi/config.txt.ub -rwxr-xr-x 1 root wheel 257 Sep 26 12:08:22 2020 = /microsd_efi/config.txt.uefi_m_m -rwxr-xr-x 1 root wheel 47516 Sep 1 14:04:10 2020 = /microsd_efi/bcm2711-rpi-4-b.dtb -rwxr-xr-x 1 root wheel 2283936 Sep 1 14:04:08 2020 = /microsd_efi/start4.elf.new -rwxr-xr-x 1 root wheel 5422 Sep 1 14:04:04 2020 = /microsd_efi/fixup4.dat.new -rwxr-xr-x 1 root wheel 5252 Sep 1 13:59:48 2020 = /microsd_efi/Readme.md.new -rwxr-xr-x 1 root wheel 2581149 Sep 1 07:14:20 2020 = /microsd_efi/RPi4_UEFI_Firmware_v1.20.zip -rwxr-xr-x 1 root wheel 2031616 Sep 1 07:08:52 2020 = /microsd_efi/RPI_EFI.fd drwxr-xr-x 1 root wheel 1024 Jul 14 18:43:24 2020 = /microsd_efi/OVERLAYS -rwxr-xr-x 1 root wheel 2277248 Jul 14 16:01:00 2020 = /microsd_efi/start4.elf -rwxr-xr-x 1 root wheel 2277248 Jul 14 16:01:00 2020 = /microsd_efi/start4.elf.old -rwxr-xr-x 1 root wheel 5409 Jul 14 16:00:58 2020 = /microsd_efi/fixup4.dat -rwxr-xr-x 1 root wheel 5409 Jul 14 16:00:58 2020 = /microsd_efi/fixup4.dat.old -rwxr-xr-x 1 root wheel 4592 Jul 14 15:57:48 2020 = /microsd_efi/Readme.md -rwxr-xr-x 1 root wheel 4592 Jul 14 15:57:48 2020 = /microsd_efi/Readme.md.old -rwxr-xr-x 1 root wheel 206 Jul 14 15:57:48 2020 = /microsd_efi/config.txt.uefi_orig -rwxr-xr-x 1 root wheel 205 May 24 14:46:42 2020 = /microsd_efi/config.txt.nobt -rwxr-xr-x 1 root wheel 5888 Jan 30 13:26:30 2020 = /microsd_efi/armstub8-gic.bin -rwxr-xr-x 1 root wheel 18693 Nov 22 09:06:44 2019 = /microsd_efi/COPYING.linux -rwxr-xr-x 1 root wheel 1594 Nov 22 09:06:44 2019 = /microsd_efi/LICENCE.broadcom drwxr-xr-x 1 root wheel 1024 Sep 27 21:05:00 2018 /microsd_efi/EFI # diff -rq /microsd_efi/ /usb_efi/ Only in /usb_efi/EFI/BOOT: BOOTAA64.EFI Only in /microsd_efi/EFI/BOOT: bootaa64.efi Files /microsd_efi/Readme.md and /usb_efi/Readme.md differ Files /microsd_efi/config.txt and /usb_efi/config.txt differ Files /microsd_efi/fixup4.dat and /usb_efi/fixup4.dat differ Files /microsd_efi/start4.elf and /usb_efi/start4.elf differ The content of BOOTAA64.EFI and bootaa64.efi are identical, it is just a capitalization difference in the naming. > booted a bit more (until gpio or so afaik)=E2=80=A6.it`s all about = DeviceTree=20 > and I guess Kyle Evans & friends unfortunately will have more = adjustment-work in the brcm285..dtsi=E2=80=A6 for 2020.10 > I unfortunately totally fail in my time-management but will tell more = about the 8GB - VL805-videoCore-firmware-thing when finding time..=20 > I didn=E2=80=99t yet apply kevans-patches, will test them it later.. I've not tried them either. > Directly from SSD(no SD-card inserted): > =E2=80=94-config.txt : =E2=80=94 > arm_control=3D0x200 > dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don > enable_uart=3D1 > uart_2ndstage=3D1 > dtoverlay=3Dminiuart-bt > dtoverlay=3Dmmc > dtoverlay=3Dpwm > device_tree_address=3D0x4000 > kernel=3Du-boot.bin > =E2=80=94-------------------------------------------------- >=20 > recover4.elf not found (6) > recovery.elf not found (6) > HUB [03:01] 2.00 000003:01 init port 1 speed 3 > DEV [05:03] 2.00 000013:01 class 9 VID 045b PID 0209 > HUB init [05:03] 2.00 000013:01 > Read start4.elf bytes 2272992 hnd 0x000002e7 hash '319662b44a4c80d5' > Read fixup4.dat bytes 5405 hnd 0x000001bf hash '0c1a6c6f96114a3f' > 0x00c03111 0x00000000 0x0000001f > MEM GPU: 76 ARM: 947 TOTAL: 1023 > Starting start4.elf @ 0xfeb00200 partition 0 >=20 >=20 > U-Boot 2020.10-rc5 (Oct 05 2020 - 03:08:23 +0000) >=20 > . . . > FreeBSD 13.0-CURRENT #39 a1d832e8c08-c271678(master): Fri Jul 17 = 04:56:52 UTC 2020 This identifies head -r365919 from 2020-Sep-20. I'm using head -r365932 = . > . . . > gpioled0: on ofwbus0 > sdhci_bcm1: mem 0x7e340000-0x7e3400ff = irq 80 on simplebus3 > mmc1: on sdhci_bcm1 > =E2=80=94- hanging here=E2=80=94 >=20 > just GUESSING ;-) (absolutely NO proof:-): > It comes to boot problems short before xhci will be initialized from = the DeviceTree >=20 I've not yet tried a combination that uses a u-boot from the USB3 SSD (no microsd card) and gets anywhere near that far along on any RPi4B (4 GiByte or 8 GiByte). I've only gotten u-boot to boot RPi4B FreeBSD completely when u-boot and the FreeBSD kernel were both from the microsd card. (With the FreeBSD kernel in place, I can then have the later stages use the USB3 SSD instead --and that is what I normally do.) But for this to work I've had to use older start* and fixup* files. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Oct 9 20:28:49 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 6351842C40B for ; Fri, 9 Oct 2020 20:28:49 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C7KR43vhDz4qkv; Fri, 9 Oct 2020 20:28:48 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x434.google.com with SMTP id x7so2970650wrl.3; Fri, 09 Oct 2020 13:28:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=x0WIGfvZciYolw74BX7ujrp+p8q3aybBOGOW4giBo+I=; b=a+7cQhWtv/BFcCKHye3FG15641NnRTzDPV5hDGG4uYVjBz32eFWqLM4zTYdb30xzOp ZDzTXwg+vi9CSHApPCLIhBMrLC2HZG/gHgXqjti+EUB5i4PizWhSp3D7o8uNZGf46JPx b7OGaSAnagj5TdPy18Nf79ybnHyt5atYQnmv7zqL/vbCXHTPkFeWowjmB6DELwY92ixv DNsvZlhkyTDLBPPK0UtbwmpOBexjVb8cvWo19iN/BaC+diZjxuk0zsUd4umZIUTn7Izb 9X/ddY3iqIajs+5JWaG3X7BriwrpySfkSk8eQJoYo1s4wfXelT40zsotm4u3m2ALCGj/ x9uQ== X-Gm-Message-State: AOAM532OrvF5fNz3k5ryRVKo0rNpS5Brn75L4PPJoHj4+WkZ7GaTta2t ZZw/y94illuf8UaqUQ7hsZw= X-Google-Smtp-Source: ABdhPJz0LtoLSxB37SctKhTOTD9FJeCxqP+PCxypZCCGzbg63UlxFKrrH/GjCixXwHZ5VSwf61s3kw== X-Received: by 2002:a5d:5609:: with SMTP id l9mr14726218wrv.140.1602275326035; Fri, 09 Oct 2020 13:28:46 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-104-055.46.114.pool.telefonica.de. [46.114.104.55]) by smtp.googlemail.com with ESMTPSA id o6sm13814066wrm.69.2020.10.09.13.28.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 13:28:45 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Date: Fri, 9 Oct 2020 22:28:42 +0200 References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> To: Mark Millard , Kyle Evans , Robert Crowston , freebsd-arm@freebsd.org In-Reply-To: Message-Id: <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C7KR43vhDz4qkv X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.88)[-0.876]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org,protonmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.104.55:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.97)[-0.968]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::434:from]; RCVD_TLS_ALL(0.00)[]; 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: Fri, 09 Oct 2020 20:28:49 -0000 > Am 09.10.2020 um 21:25 schrieb Mark Millard : >=20 >=20 > Linux has its own dts/dtsi/... sources instead of using the .dtb files > from the RPi folks, not directly based on any vintage of the RPi .dtb > files if I understand right=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6= .. FreeBSD imports the linux-dts : = https://github.com/freebsd/freebsd/tree/master/sys/gnu/dts/arm64/broadcom > =E2=80=A6=E2=80=A6=E2=80=A6. I use apt to update the ubuntu microsd = card once and a while. I simply used the Raspberry Pi Imager(automatically updates itself to = latest) to get a =E2=80=9Ereproducible" `latest`- msdos-partition of Ubuntu : https://www.raspberrypi.org/downloads/ And it booted FreeBSD on the 4GB-model from SSD(w/o SD-card) (until = reported hang) ( additionally I changed in config.txt from disable-bt to miniuart-bt) =E2=80=A6=E2=80=A6. >=20 > =E2=80=A6.. (=E2=80=9EUSB MSD boot also requires > the firmware from Raspberry Pi OS 2020-08-20 or newer.") Yes, , eeprom-update is a MustHave for 2020.10 USB-boot, it also can be done by formatting an firmware-SD-card with=20 the Raspberry Pi Imager - tool . My GUESSED(my favorite term since some time :-) following steps for the = 8GB-model should be: 'Special Agent kevans=E2=80=98=20 could inspect the following for dts and perhaps adopt it to fbsd-values = for an early=20 VL805-controller reset in u-boot : (That patches are not upstreamed yet afaik) = https://patchwork.ozlabs.org/project/linux-pci/patch/20200629161845.6021-4= -nsaenzjulienne@suse.de/ = https://patchwork.ozlabs.org/project/linux-pci/patch/20200629161845.6021-5= -nsaenzjulienne@suse.de/ Then we probably need `Special Agent Crowston=E2=80=99 again with his JTAG-Debugger=20 to read out the values where exactly Fbsd-boot-kernel hangs in 2020.10 = booted off of pure USB . .. sounds all quite easy , but possibly isn=E2=80=99t , as we know=E2=80=A6= Regards K. From owner-freebsd-arm@freebsd.org Fri Oct 9 21:25:27 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 32FEA42D87F for ; Fri, 9 Oct 2020 21:25:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4C7LhQ2DR6z4vKL for ; Fri, 9 Oct 2020 21:25:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: IpOOmCYVM1lL9yuIHV0jQV5Ov0.WOIvMT1RoDmcnWB9R8SVT98mAvtq_JRnwAh. Yxvu5In0OAVeMY471_rET312xx_ak2UatpWVhKJpFOYpvyzUVeuADySnCHaXpb.84K8coMD3teeB KRmfOkrXbTjA1NN.xqkSzi96Mbk2OS3jOgXO195RJppBOpdCPgmvnK5SBjOtQtrTH86AZ5RDlCOq yMqt2hsVj7mBq9G63MBzsjTUfDaIfQj.sNROmkHZxE3qXd2mk7yw23LiIc6a1aUuIB3_Biou2_Ba 1QzS399bKwvyzftx90qK5Jg_pvdGaEq_iDUT9AyExu91pN991bNuQ1Fnwsh4PcDrLeDg5DQYRSXW d5GTg6Vy7uy4eqV3KWQkFvIom8pBxyjzr_Y0BrjTuY2ElqrDj4MxoXCLO3oAoLM6lhiHcHqcA6Bl lvGw1yJkskINuJ8kwKrH_xw5ZWyppFVlT6euGcwPbS2jeyXTyTWPaiIGhh8XBihVXp4QtNRoXvrK jn_9SJeQ.odc75e38pD6B6BQHRr8LBmdih8ubOq6ZyWA38kwtfdAZwXKrk65xaTg3SCASIxObbeW QnaWi1fB4RjY5I76agoklPYCbfuam60vrA8EsSkDkRmFB8PS.j1vmRhXgY3YElkxOEMFI8oXNrBF YWwtFrVz673OJRGuUPEHnz_RnDwZ3HBb8RRf4qBn5UZaWpZw69iBqerpg7ohyVgLCu933KWqwAA4 GaWBQpvNR.F9q9eTkXp_rXTqyH.jggO3BdGFTbF6hbsiTr3NMpV5ao2O.uor1_TeOZa1OycglS31 2F9v5loiB0Y6RJNzeCrfTpOsHsT8g4rr1q3T8q3BN0coBgtTVYT55ObvInJhrL6hFLPG.cEmxUUs 0GHo6yB7FpuhUUF7lntlgi2reYwZtg.new89chffYD6WzYEebru2qaiIcKxyEHlR21ZqPMW92rm0 9LESIL9U7gfSiymJeNMDrm52SumRbBXtIBY9OzX5QQTXjCx2gXRUbBWfmMMumi5BuexKE.O9wTpH B5qBxol1s5PXTnKc4XRf7LLcB54519OCf4.meMpBNjKMnrLvSdQi4SEv3w7g_xhLzQnGWZlPZvhL yIFR4pensh3eTRUCmMmj2ZOXC.GmccjgCwcm6iLv_HZ.i_3HO4zk5gBpbvA6DaRNqwAG8kaHXwDJ qGWcW8d3QUVViD9ayJcdp4H4HbiBm.FXyI8.LwwKAvG_.8d2t4Y3SUD9NlzkjPi1wmXKu2O76uno .OjYpPLNi3x1HBktBSR6W5YJlkcxc48H.pPAWfXvjxrXczH8n9TM0B6m5EfS7Lh3BlLhD9.IEdzr 8rruwFLNjdpdk62YNtOX24SxMjKDIlXQZSX2bR.S56syrQDdbPVJG.mOZLSptfn9qFOoprQXrx_m _iFYd60TX04EKDgPt0SIJtVeCUQ4YyNliJZJbMMfaqPsiTxqx32EgcC36Rpy.EiBvOS_GS_0RGmZ _IwQVQEIFmpEykytPQMgMmXy5HH.2eVBVr0XgV1UW9sEEp1iPpiKv8XmVZZidxEp9wwWpNvJkTrh YCfOiFHO2FccE9ARGc6P5nMj47ggYw.LsgaM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 21:25:23 +0000 Received: by smtp403.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 76f127122ada5ae05a21fe3b1b3f6391; Fri, 09 Oct 2020 21:25:23 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> Date: Fri, 9 Oct 2020 14:25:21 -0700 Cc: Robert Crowston , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C7LhQ2DR6z4vKL X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.93 / 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.43)[-0.431]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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(-1.02)[-1.017]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.98)[-0.981]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; FREEMAIL_CC(0.00)[protonmail.com,freebsd.org]; 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: Fri, 09 Oct 2020 21:25:27 -0000 On 2020-Oct-9, at 13:28, Klaus Cucinauomo = wrote: >=20 > Am 09.10.2020 um 21:25 schrieb Mark Millard : >>=20 >>=20 >> Linux has its own dts/dtsi/... sources instead of using the .dtb = files >> from the RPi folks, not directly based on any vintage of the RPi .dtb >> files if I understand right=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6= .. >=20 > FreeBSD imports the linux-dts : > = https://github.com/freebsd/freebsd/tree/master/sys/gnu/dts/arm64/broadcom FreeBSD imports lots of linux-dts material that it does not put to use. Only some of the imported material is used. release/arm64/RPI3.conf indicates use of: (There is not RPi4 release yet.) DTB_DIR=3D"/usr/local/share/rpi-firmware" DTB=3D"bcm2709-rpi-2-b.dtb bcm2710-rpi-3-b.dtb bcm2710-rpi-3-b-plus.dtb = bcm2711-rpi-4-b.dtb" . . . EMBEDDEDPORTS=3D"sysutils/u-boot-rpi3 sysutils/rpi-firmware" . . . UBOOT_DIR=3D"/usr/local/share/u-boot/u-boot-rpi3" . . . DTB_FILES=3D"armstub8.bin armstub8-gic.bin bootcode.bin = fixup_cd.dat \ fixup_db.dat fixup_x.dat fixup.dat LICENCE.broadcom \ start_cd.elf start_db.elf start_x.elf start.elf \ fixup4.dat fixup4cd.dat fixup4db.dat fixup4x.dat = start4.elf \ start4cd.elf start4db.elf start4x.elf ${DTB}" . . . for _UF in ${UBOOT_FILES}; do chroot ${CHROOTDIR} cp -p ${UBOOT_DIR}/${_UF} \ ${FATMOUNT}/${_UF} done for _DF in ${DTB_FILES}; do chroot ${CHROOTDIR} cp -p ${DTB_DIR}/${_DF} \ ${FATMOUNT}/${_DF} done chroot ${CHROOTDIR} cp -p ${DTB_DIR}/config_rpi4.txt \ ${FATMOUNT} chroot ${CHROOTDIR} cp -p ${DTB_DIR}/config_rpi3.txt \ ${FATMOUNT}/config.txt chroot ${CHROOTDIR} mkdir -p ${FATMOUNT}/overlays for _OL in ${OVERLAYS}; do chroot ${CHROOTDIR} cp -p ${OL_DIR}/${_OL} \ ${FATMOUNT}/overlays/${_OL} done It is not using sys/gnu/dts/arm64/broadcom/ material. >> =E2=80=A6=E2=80=A6=E2=80=A6. I use apt to update the ubuntu microsd = card once and a while. >=20 > I simply used the Raspberry Pi Imager(automatically updates itself to = latest) > to get a =E2=80=9Ereproducible" `latest`- msdos-partition of Ubuntu : The Raspberry Pi Imager is a way to install RaspiOS to media from Windows, macOS, ubuntu, or RaspiOS. It does not install Windows, macOS, or ubuntu but RaspiOS (an abbreviation of "Raspberry Pi OS"). > https://www.raspberrypi.org/downloads/ ubuntu's RPi* images are available via links from: https://ubuntu.com/download/raspberry-pi with arm64 links going to: = https://ubuntu.com/download/raspberry-pi/thank-you?version=3D20.04.1&archi= tecture=3Darm64+raspi These are not via the rpi organization's web site and www.raspberrypi.org does not provide the ubuntu image(s). > And it booted FreeBSD on the 4GB-model from SSD(w/o SD-card) (until = reported hang) > ( additionally I changed in config.txt from disable-bt to miniuart-bt) Looks to be that you were using RaspiOS's DTB and related materials directly, not ubuntu's materials. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Oct 9 22:19:33 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 3C4C042EEA0 for ; Fri, 9 Oct 2020 22:19:33 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C7Mtr3ktzz3VD1; Fri, 9 Oct 2020 22:19:32 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x441.google.com with SMTP id x7so3209805wrl.3; Fri, 09 Oct 2020 15:19:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=px9wZzw6Uhs2Dcb1NQ8DeUEDeXYP9pnzb3L/ce8kZwE=; b=lUmepH0l3LkyHtWvPIRwp8sTMPVcdc7CkIjLRauFiSSLjatXpxe6gUj+XaiRGZN9/R Ermi78EPfogpdYCOra0JiK6Kp4ZRKY/KNmmEFyf8bcwmZPaNJbIAChv7+ghUMZGMmBnz TKBh8LfgIt2fgqgDpNzA34w9XVP4v3wCRD/dihwriKwjKr2SgOQYqdNRPmqu5VUwusE6 FqDX+d9dogl5L73AvrbsG/dFZPQhS9OFom9kNYU9aeCnJIlvprnYAPP7EexvuBqO/RU0 3aw+/CYkQ6JvDUOBQDZokljZc9MFLE3CXnCyPj8iV/cnh/S+65IU5Ad/gyTEl443r892 7nDw== X-Gm-Message-State: AOAM530iGa6k/QT/yiUYQMcfTLpX07YhPivnBKg3SNPf74J0vJwCjCQD cRGx4RGS/f5VGMGYFipMWgM= X-Google-Smtp-Source: ABdhPJy/hk0yPQ0zLf0du7p9IzYFzb3IXbCIL+Dy81Kjxnw2fT7dl50scmiS3H7x14RVXiuyKBenQw== X-Received: by 2002:adf:e601:: with SMTP id p1mr18349070wrm.172.1602281970874; Fri, 09 Oct 2020 15:19:30 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-104-055.46.114.pool.telefonica.de. [46.114.104.55]) by smtp.googlemail.com with ESMTPSA id v17sm14370573wrc.23.2020.10.09.15.19.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 15:19:30 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Date: Sat, 10 Oct 2020 00:19:27 +0200 References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> To: Mark Millard , Robert Crowston , Kyle Evans , freebsd-arm@freebsd.org In-Reply-To: <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C7Mtr3ktzz3VD1 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.08 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.64)[-0.641]; FREEMAIL_TO(0.00)[yahoo.com,protonmail.com,freebsd.org]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.104.55:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.97)[-0.972]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::441:from]; RCVD_TLS_ALL(0.00)[]; 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: Fri, 09 Oct 2020 22:19:33 -0000 > Am 09.10.2020 um 23:25 schrieb Mark Millard : >=20 >=20 > The Raspberry Pi Imager is a way to install RaspiOS to > media from Windows, macOS, ubuntu, or RaspiOS. It does > not install Windows, macOS, or ubuntu but RaspiOS (an > abbreviation of "Raspberry Pi OS=E2=80=9C... > =E2=80=A6.These are not via the rpi organization's web site and = www.raspberrypi.org does not provide the ubuntu image(s)=E2=80=A6.. Sorry Mark, but what you say is wrong , Open the RaspberryPi-imager tool ( I=E2=80=99m a Mac-user, so got the = Mac-version) , Goto ->=20 ChooseOS-> Ubuntu-> Ubuntu 20.04.1 LTS (RPI3/4)/64-bit server OS for = arm64 architectures=E2=80=A6 Let it write to SD or USB=E2=80=A6 then mount the ubuntu-msdos-partition = and copy over the whole crap=20 to your FreeBSD-USB-boot-media for the 4GB-model =E2=80=A6. enjoy to see FreeBSD booting from USB without SD_card =E2=80=A6 Perhaps you will stop enjoying the greatful boot-process when it will = hang short before it initializes RobOCrow`s pcie-driver :-) Ha Ha but it boots 2020.10 and that=E2=80=99s the first step before fixing the = hang... Regards K. From owner-freebsd-arm@freebsd.org Fri Oct 9 22:26:36 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 0C6AB42F33A for ; Fri, 9 Oct 2020 22:26:36 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C7N2z03pVz3Vjv; Fri, 9 Oct 2020 22:26:34 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x430.google.com with SMTP id h5so1745497wrv.7; Fri, 09 Oct 2020 15:26:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=zjKDkXczT1zjMAQWJLliHvqVFFAyKUlejunHoShM3OE=; b=jW9xLMb4ykbYHqdmBMj7kAFU5i2yJFbgyuW4ySxaMBLlSiPQ+/T6OB1nMzYkZvGoNB AdqZ30Cs4GUW8zLmGnNg7dYn0ktXOJ8/WlQ4Fj7D/DTdjmdGEDeNihTZCNqGmnvpR/lo FCXrMjXgT+EqEXY9ZUapLBVa+Po7XU4w9hMuNETDpuxa5f0T/u1ipei8g0zz2Cr8L6at HCOdf0akKwAlTckn8kvsAWgs4xMI2Iz4EMwucTTk4DuH3s1z+ReQSZbZIsRFlBrHEOVB gJgxozIsKj2Sk7IDmL3gxUUBCqgj9WZLc73iAXLW0YsFUVXP4AnlnEVHR6cxmPBUxH7Z GW7w== X-Gm-Message-State: AOAM5319koh4TxIkOyyyEF/TuQY8OAKKeYmDX01v0M1plvexMnXpB/N/ YS0+PjEI0/7nXIPInkx75vQuyPrGxAc= X-Google-Smtp-Source: ABdhPJxjqGDK7Tgjh3Rr3V9mSstwCjO88VCkrvaXIg7JXtTE/CHD9ezFzqoAEoRDCVIhEcJ7sLH3Iw== X-Received: by 2002:adf:edcf:: with SMTP id v15mr15987918wro.291.1602282393463; Fri, 09 Oct 2020 15:26:33 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-104-055.46.114.pool.telefonica.de. [46.114.104.55]) by smtp.googlemail.com with ESMTPSA id p21sm13780830wmc.28.2020.10.09.15.26.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 15:26:32 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Date: Sat, 10 Oct 2020 00:26:31 +0200 References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> To: Mark Millard , Robert Crowston , Kyle Evans , freebsd-arm@freebsd.org In-Reply-To: Message-Id: <7BA174C6-A1F2-45D2-BFD8-B8974E9C5B23@googlemail.com> X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C7N2z03pVz3Vjv X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.06 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.62)[-0.619]; FREEMAIL_TO(0.00)[yahoo.com,protonmail.com,freebsd.org]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.104.55:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.968]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.98)[-0.976]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::430:from]; RCVD_TLS_ALL(0.00)[]; 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: Fri, 09 Oct 2020 22:26:36 -0000 > Am 10.10.2020 um 00:19 schrieb Klaus Cucinauomo = : > =E2=80=A6=E2=80=A6. and copy over the whole crap=20 > to your FreeBSD-USB-boot-media for the 4GB-model =E2=80=A6. > =E2=80=A6. of course you know WHAT exactly you have to copy over and what not ;-), so I didn`t explicitly mention.. K.= From owner-freebsd-arm@freebsd.org Fri Oct 9 22:48:37 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 4AA0942FA97 for ; Fri, 9 Oct 2020 22:48:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4C7NXM56P4z3WhV for ; Fri, 9 Oct 2020 22:48:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: HX6cp9kVM1n.kFW1dLs7kdMw4ryx301NlqQbRYBd9GQfr.LSYLhUfpcqaoCIyZC fynzTQQ_6.QNSy.EFO26z_cMiGLLLZVRgxg.nPviR3lbGR87IZKTln.VXWJZv2lPHEnswka2B2XR ACb7ydb47FtM6A1FSflxKKWCSW3oFl7l7EiWun_RCgPLcdr837Gjx7dbF5OZwlcOFoi2HqGN0_gT JKf5qfFKtkJO_C.LggMuVVWD3ApE2ND0fNlCGGMjYCW7e235Le24kaa.fsGU7CW2jPV3ju8gurw1 ODsKjd8GgYN41VxVI9olIQjxhqDT6Mcyb_gCDvSuTeYwiblny3nS17nuglyRKuQriiVkrtyRELfo wG6Y_MSQf6q4YgfGM_rd.Gb9ae0VtZWO1Ys5meSD.vW8FnozUsTX3A7yn.l_oRscRkMuMH9UXXsM 8qKO5AOQe5pi216ellpT9OcJQ9vZAOZE5011y8Vzuxtu3gcz2mhwS9yf943ExuuXZ47jAshtsCUw M6obweo7tsT9VYjAIAwuypg3X0NYikpgcd2Mm6PE7QbBHL_PTTYyxcjR4ikVPF7vsFEdm0AP958A SnxQXi0pY26JwkFiVmmqaNhso.FZsjZEL9Rht__qI1QyfVagkIfIBXKpNdiASj4DH.kx2ddesNYi oc91W5_JSEpqeUdr.qdZLdrYp71TgApIhiYsDU1tyBBdo8Xpg.VB3s9W36Fun0VbiRDPHKFztKls dNjmoVaXygdzh..sLnjz2e3d8NRZsVCtdRfNnI3o78Kr.Inetn2GKunN6hFMgrvc7lJ5CWaCcRrG _VUfocFCGdnvdbBiEJY7VEdQDIM.yl2AqMA4oe5NlRpC38vZdvPFUmH_4DWNWIGSS4YVIGSwLExb 6f0iIEKAJyEkPfMI6aq2tke5rX1Qk8BCbkRXs.uciBKyvn5aPtWg4Z8JLthnAJLwk9VxQz6x6IhH 8_k2MWaY.o4xIzTXZ8islwo7K7MxuF.7HdzJXn_pEi0h3TGer8bQIkvsBDUEuraX9ulpqfFlcTfT 3E_U8smLR.taK2cLEdsHUp2y2K71u2PaV4.2_UNquLqh78AQCClqinnqfIWqZWQwYsPAw767.0dO TmV8wJiLTQoA5lSCNs2_9d4leJiSlEbui4UFWIN64hG2HM2xBrp8H4bymycI4ldJxGyPmGRVb2Xd EqdhpDbRvzxn_hfhsYnTcz19aUO7_j9AgrMjyf8DoxbHlKv9rigOf5zw3zMNOSx8puGyME_VMYLx xtLXCDz1__ymio6fos1g4jB9gJ9s2KgC70U8ibeC5SMIBSFp__aDQPJWmfbU5diYT6l0WKdAOYYQ 0DWQiz5SdWySr1Kq_itEGV0kOwhs.cpG4EcsffGk.riCcUb0pZUuXQka_yDhTTR9iWDRZYapy9uN yKAPOqAy74lxlS9UvbOReMYgpS6bE0pqqEhzN7pgEE.wHztmgDP7RFIELmvsvVlTW8thimTh9z9C _CqxbMpa7qku2PooC3b1qG_fD8gTvfiZ_SXuBUurvXL7iHDxyjW9KWRXBqvcpRY.PltYXRJrJ Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 22:48:33 +0000 Received: by smtp417.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2fb1fed29c2ad76b8d106bcd88b9aa18; Fri, 09 Oct 2020 22:48:32 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: Date: Fri, 9 Oct 2020 15:48:30 -0700 Cc: Robert Crowston , Kyle Evans , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <36A6B0E4-7578-4EFF-8095-9030DA36214B@yahoo.com> References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C7NXM56P4z3WhV X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.54 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.08)[-1.081]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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.97)[-0.973]; 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.988]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; FREEMAIL_CC(0.00)[protonmail.com,freebsd.org]; 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: Fri, 09 Oct 2020 22:48:37 -0000 On 2020-Oct-9, at 15:19, Klaus Cucinauomo = wrote: > Am 09.10.2020 um 23:25 schrieb Mark Millard : >>=20 >>=20 >> The Raspberry Pi Imager is a way to install RaspiOS to >> media from Windows, macOS, ubuntu, or RaspiOS. It does >> not install Windows, macOS, or ubuntu but RaspiOS (an >> abbreviation of "Raspberry Pi OS=E2=80=9C... >> =E2=80=A6.These are not via the rpi organization's web site and = www.raspberrypi.org does not provide the ubuntu image(s)=E2=80=A6.. >=20 > Sorry Mark, but what you say is wrong , >=20 > Open the RaspberryPi-imager tool ( I=E2=80=99m a Mac-user, so got the = Mac-version) , > Goto ->=20 > ChooseOS-> Ubuntu-> Ubuntu 20.04.1 LTS (RPI3/4)/64-bit server OS for = arm64 architectures=E2=80=A6 Ahh. I see. Sorry for the noise. I did not get that you had selected ubuntu from inside the RaspberryPi-imager User Interface. Another (implicit) bad guess at context on my part. In this case, my comments about the .dtb files not being RaspiOS based and not matching the ones that FreeBSD is based on using for RPI3 builds applies as far as I know: it is the same material as available from the ubuntu web site for installing 2020.04.1 . The notes about the vintages of start4.elf and fixup4.dat predating 2020-Aug-20 by a notable amount also applies. It will be interesting to see if 2020.10 uses newer start*.elf and fixup*.dat materials when it is released later this month --as well what vintage of dts materials it ends up being based on. > Let it write to SD or USB=E2=80=A6 then mount the = ubuntu-msdos-partition and copy over the whole crap=20 > to your FreeBSD-USB-boot-media for the 4GB-model =E2=80=A6. > enjoy to see FreeBSD booting from USB without SD_card =E2=80=A6 > Perhaps you will stop enjoying the greatful boot-process when it will = hang short before it initializes RobOCrow`s pcie-driver :-) Ha Ha > but it boots 2020.10 and that=E2=80=99s the first step before fixing = the hang... =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Oct 9 22:56:57 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 0DE1442FB39 for ; Fri, 9 Oct 2020 22:56:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 4C7Njz5hVqz3X6t for ; Fri, 9 Oct 2020 22:56:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: YX1sRW0VM1nlHOgRzQ4Vnxllvm6GZxTzw0Lqox4hWC6vSCFkDu3FKgWm_dnGM6r XLiZnwCfH59IvkHGuyKpxM7QHxNLqiPMIRcLwYuvHxH3nuRn0h8zAXUEV0_Ppe3yOvkXEV9i52NZ J2VcPjNJh9Hhlq0AZN7UiJopvqiunZpPyOVJas9ZT1AvLaLEV3hYwpjz5GfabnEaZWACaZWLv5Or FiudxYaePZPG8OjvPyFzuJqbysXuP.hcQFVnr95wdJe3JjTExHoos_bGON3G.sEb1oE4AsBq7vjE CbhqXc70M0kyJuR7jcOxzCVJy_e6OCqwCGq.qXboWKAAoOSJIt62Orp2IrPsEb8jN6koQ4sjhq2R gbaPpbo6vx9UyGmkHCvRUMgONZCzNVWG7n5WP9xL1zYD0vGmwWYtZX.90zyxmBK7tp1eKssCLeC9 iayT9XvGuol5ECdiX85sphROnOX_zPTH7k6sWVNXSmzAO70hEMSQ6GKM8UeprZrqllRnwYSPnBF6 oUsDyMdVDweXI7UPDV9JhMsSfqQ6B_1xffAqdxUDZ7IBf4mH_m5kaRFlGpdFCM0QDyoAxhp2qPEU jbReJkYO.Qek26Fm7P83CX_i4Wnmy4zxd1XG7PNW9ozafLhjm4hLak_4vX7R32zAwGt67Z6Y_lf. Q2kh7lpKPT8IPBYaWL71UaFz_Ec5IfSnrdzyzAxqU2WVUl4D1Vqw3eESFd4zwMXoL3XOQyLjanYb 5XdwtWxOoz7pHkvcURjEXVSBBDBYJkS3i.oaAuj3PVQLytPNByABEFkDwar8etI1_cEHVM423xvB Fl7SLLHmqnsQn.Dxiv_Ownuj2N2uDgdtcbvX0lTtt.AdJEEMz6Zpj0sZw1XrJMgDFqJ10Yx61_RZ bmkmnWFRwCp58Wup2n7OeqBvI8nfA.A.nwwdnNrx5qApkQjpLKW97BVdGBg6BMEgcM3EnqBF1WE5 vaAGA90tf1SmyBSZ6a2IrsWb1R_tNDV8l73CSyGC8yQpKeu2.oR5hnh94p2RFLq76j0XeCDlvQgr stzKP.AZzYNerKeg0SeK9QRZA_11mlVfWgdAxd2HDHcYrwOkY5TJ5TLxjLnC3CmNBMT7TFOtS5vD e1urfknidV3edTXAsBNKcOYs6OARPP55BVX3LrV3sawHRa.0KhtrxJQC1R9ehHwGeRvFfXKNA7ba Ur03DpiMWIrwG_mVZioiIiuxzHWf704niQ_5z_iJkn3R_O_9z91cZ86SIHVuAbhITTRUeaJTIhnQ y5s8vLcnkI60FwqQb_B3_ENZJCxnl80DnBTKLsQc8qoNvyi8T_2MJHzeo0ivNjj9WqM.6VHK4tP8 CTeFbt_QcB.nmcO7VwwBkgzCxRa9fAAfrfpPlARb0fvbWZEbVrkW27FLEi3BkoU8vBNuqMJ0XvKI epquSevO18VafAJ9C.MnKp_HFh8p68eV1D5YoUSsdN29fu8gXZ9IN4kn3mlZ9fFjUOgXamuob8lu 089jwH2txHFIx8Fc12SM0a27u8Y.WDgMH7JqemOhe_9vq0mjNq8e46UkRK8mZylZJ9seV.s4jEJt HMj9iS6s- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Oct 2020 22:56:54 +0000 Received: by smtp423.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a21cb776d69f872967ddb5820497badf; Fri, 09 Oct 2020 22:56:53 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <36A6B0E4-7578-4EFF-8095-9030DA36214B@yahoo.com> Date: Fri, 9 Oct 2020 15:56:52 -0700 Cc: Robert Crowston , Kyle Evans , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <0EDAC217-E53F-4C06-81F4-35FF5550DEE8@yahoo.com> References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <36A6B0E4-7578-4EFF-8095-9030DA36214B@yahoo.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C7Njz5hVqz3X6t X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.47 / 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.01)[-1.010]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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.97)[-0.974]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.98)[-0.982]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; FREEMAIL_CC(0.00)[protonmail.com,freebsd.org]; 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: Fri, 09 Oct 2020 22:56:57 -0000 On 2020-Oct-9, at 15:48, Mark Millard wrote: >=20 > On 2020-Oct-9, at 15:19, Klaus Cucinauomo wrote: >=20 >> Am 09.10.2020 um 23:25 schrieb Mark Millard : >>>=20 >>>=20 >>> The Raspberry Pi Imager is a way to install RaspiOS to >>> media from Windows, macOS, ubuntu, or RaspiOS. It does >>> not install Windows, macOS, or ubuntu but RaspiOS (an >>> abbreviation of "Raspberry Pi OS=E2=80=9C... >>> =E2=80=A6.These are not via the rpi organization's web site and = www.raspberrypi.org does not provide the ubuntu image(s)=E2=80=A6.. >>=20 >> Sorry Mark, but what you say is wrong , >>=20 >> Open the RaspberryPi-imager tool ( I=E2=80=99m a Mac-user, so got the = Mac-version) , >> Goto ->=20 >> ChooseOS-> Ubuntu-> Ubuntu 20.04.1 LTS (RPI3/4)/64-bit server OS for = arm64 architectures=E2=80=A6 >=20 > Ahh. I see. Sorry for the noise. I did not get that you had selected > ubuntu from inside the RaspberryPi-imager User Interface. Another > (implicit) bad guess at context on my part. >=20 > In this case, my comments about the .dtb files not being RaspiOS based > and not matching the ones that FreeBSD is based on using for RPI3 > builds applies as far as I know: it is the same material as available > from the ubuntu web site for installing 2020.04.1 . The notes about > the vintages of start4.elf and fixup4.dat predating 2020-Aug-20 by a > notable amount also applies. >=20 > It will be interesting to see if 2020.10 uses newer start*.elf and > fixup*.dat materials when it is released later this month --as well > what vintage of dts materials it ends up being based on. >=20 >> Let it write to SD or USB=E2=80=A6 then mount the = ubuntu-msdos-partition and copy over the whole crap=20 >> to your FreeBSD-USB-boot-media for the 4GB-model =E2=80=A6. >> enjoy to see FreeBSD booting from USB without SD_card =E2=80=A6 >> Perhaps you will stop enjoying the greatful boot-process when it will = hang short before it initializes RobOCrow`s pcie-driver :-) Ha Ha >> but it boots 2020.10 and that=E2=80=99s the first step before fixing = the hang... FYI for the u-boot vintage/variant involved for ubuntu: # strings /boot/firmware/uboot_rpi_4.bin | grep 2020 gcc (Ubuntu 9.2.1-28ubuntu1) 9.2.1 20200203 02/11/2020 U-Boot 2019.07+dfsg-1ubuntu6 (Feb 11 2020 - 10:43:57 +0000) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Oct 9 23:20:30 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 3C52C42FECB for ; Fri, 9 Oct 2020 23:20:30 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C7PF91tJvz3Xwg; Fri, 9 Oct 2020 23:20:28 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x32d.google.com with SMTP id q5so11311779wmq.0; Fri, 09 Oct 2020 16:20:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=jn/XlEli0ix22vQHATDQH68MLWCK/HIST3rhx4I2ps8=; b=EO8OoJEnkQpkvngyqRuACs8yS2xEVCsh+h1vTzg6sEiml4LOhJ+I3dzMMUDAtGza4T klYfO55KT4twX4f3GUY6ZTFWIZqVrbEgMYMCOzsB62Re4Wxgpid85eQCSqqRPlbUt6jC YP939ic7A2P5unlxvoIj0pVUd7cMUoKs30qI4D4j/M1/wYQWs0d4s2NIYPQ+xmWaRiGk ziec4M2+vqFXtLw3IgVRzCZXBy445ACqOvbrBxduKoqDSokG2xSPwSWoL9KHBfjDjuMI n+SHQY22vdH1tvrYHRtCPB4M+6l60W7sC4Qr2i0/DwhrCo0unF0POhztY2UTrq198Ske Y/vA== X-Gm-Message-State: AOAM532XheUdoJcf71kGahMozy2kwslQm32oTuRZl01RkhOcT8ZKXnO8 MTY5qrFbS7nUdlms8jrADco= X-Google-Smtp-Source: ABdhPJzqH0Ac6LenUyN0ih8+6MgN6trgXJfOHBLqbY60BSCmH4eOCuoa7UHOWViZ6w4d5xbe5xabyw== X-Received: by 2002:a1c:2ed3:: with SMTP id u202mr208863wmu.85.1602285626409; Fri, 09 Oct 2020 16:20:26 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-104-055.46.114.pool.telefonica.de. [46.114.104.55]) by smtp.googlemail.com with ESMTPSA id g139sm14025865wme.2.2020.10.09.16.20.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 16:20:25 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Date: Sat, 10 Oct 2020 01:20:23 +0200 References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <36A6B0E4-7578-4EFF-8095-9030DA36214B@yahoo.com> To: Mark Millard , Robert Crowston , Kyle Evans , freebsd-arm@freebsd.org In-Reply-To: <36A6B0E4-7578-4EFF-8095-9030DA36214B@yahoo.com> Message-Id: <83BA1DDB-C725-470C-B382-9D229860E2F1@googlemail.com> X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C7PF91tJvz3Xwg X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.08 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.65)[-0.645]; FREEMAIL_TO(0.00)[yahoo.com,protonmail.com,freebsd.org]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.104.55:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.968]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.97)[-0.971]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32d:from]; RCVD_TLS_ALL(0.00)[]; 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: Fri, 09 Oct 2020 23:20:30 -0000 > Am 10.10.2020 um 00:48 schrieb Mark Millard : > =E2=80=A6. Sorry for the noise. =E2=80=A6... the more noise, the more we find out ;-)..=20 and of course also for me , probably all of us, that=E2=80=99s all = really confusing stuff from raspberrypi.org=20 because very strange that ubuntu`msdos is compatible with 2020.10=20 while their GitHub-stuff isn=E2=80=99t (in our msdos-part) . > =E2=80=A6=E2=80=A6 > . > FYI for the u-boot vintage/variant involved for ubuntu: >=20 > # strings /boot/firmware/uboot_rpi_4.bin | grep 2020 > gcc (Ubuntu 9.2.1-28ubuntu1) 9.2.1 20200203 > 02/11/2020 > U-Boot 2019.07+dfsg-1ubuntu6 (Feb 11 2020 - 10:43:57 +0000) =E2=80=A6.. I even didn=E2=80=99t boot it, just copied the msdos-part=E2=80=A6=20 all files in ubuntu server msdos are of date /31st of July 2020 / , the only reason why I used that distro is really because it seems to = be a raspberrypi.org official image =20 And I GUESSED(!;-) it has to boot up 2020.10 , and that was right=E2=80=A6= But puuuh, all strange stuff Regards K.= From owner-freebsd-arm@freebsd.org Sat Oct 10 00:17:21 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 C66774316B3 for ; Sat, 10 Oct 2020 00:17:21 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C7QVm5R8jz3bbh; Sat, 10 Oct 2020 00:17:20 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x42b.google.com with SMTP id h5so1900232wrv.7; Fri, 09 Oct 2020 17:17:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=qJ1Q3qu2A2QvWdfpxYnBZGyeMcAO+8GUS946+hAsprk=; b=DjZz1O8LrM6o69SxLWksMSW7wES+UbMuv+IRGCVArtjPaYnkDI345Ts8E7nunGxrGk aGDmq5PO0Zm0bFGkNozsW/U+6NrUhrf5qgyRsA7RypX8Ws5rKXnRHZkPRx3+FfXFMl4E 2VI86QAcQWQfab8mxuD2AYsnyFUCxt6QPOi4m9M9Jxy9318IbMnTB5Dl8JZfj0DL9QCj 5DqPQB/4FKUz/u04IkZH3/+WeFxnw9g/OMEitYxpCS2Tnto7xlnM1T6itKv71pG/xtVx /jUM6EYBP9K5FYi7TnHuMm6sKfECpsJoE3cCSoFWo3rSAoKZXvX0RoArUAgwvnBUTohk Xt4A== X-Gm-Message-State: AOAM531ueYiaaNz8ZTFMvGYmmnf1cIFGGuVGBMfzfEhUj4qmjBY6ojeo lRzV5hu/n0B6BHCfW5UFmfqqW7Ag7qs= X-Google-Smtp-Source: ABdhPJwh8JGJ3CaU3ypzBSvT4ITAR2b/S+12RVfsWfnd0ivRI8wR4hyJ9+lWCPoOgUjrh0I2l5MLCw== X-Received: by 2002:adf:a50e:: with SMTP id i14mr14217779wrb.121.1602289038076; Fri, 09 Oct 2020 17:17:18 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-104-055.46.114.pool.telefonica.de. [46.114.104.55]) by smtp.googlemail.com with ESMTPSA id p13sm14087610wmb.5.2020.10.09.17.17.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 17:17:17 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Date: Sat, 10 Oct 2020 02:17:15 +0200 References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> To: Mark Millard , Kyle Evans , Robert Crowston , freebsd-arm@freebsd.org In-Reply-To: <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> Message-Id: <27E7A6A9-04A4-4B15-96CB-84AE478ED755@googlemail.com> X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C7QVm5R8jz3bbh X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.07 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.63)[-0.630]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org,protonmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.104.55:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.970]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.97)[-0.975]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42b:from]; RCVD_TLS_ALL(0.00)[]; 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 00:17:21 -0000 > Am 09.10.2020 um 23:25 schrieb Mark Millard : >=20 > FreeBSD imports lots of linux-dts material that it does not put > to use. Only some of the imported material is used. >=20 > release/arm64/RPI3.conf indicates use of: > (There is not RPi4 release yet.) >=20 > DTB_DIR=3D"/usr/local/share/rpi-firmware" > DTB=3D"bcm2709-rpi-2-b.dtb bcm2710-rpi-3-b.dtb = bcm2710-rpi-3-b-plus.dtb bcm2711-rpi-4-b.dtb" > . . . > EMBEDDEDPORTS=3D"sysutils/u-boot-rpi3 sysutils/rpi-firmware" > . . . > UBOOT_DIR=3D"/usr/local/share/u-boot/u-boot-rpi3=E2=80=9C > =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6. >=20 > It is not using sys/gnu/dts/arm64/broadcom/ material. ah, `forgot to mention : [dtb =3D DeviceTree-Blob =3D=3D compiled dts(DeviceTreeSource)] So the dtb`s you mention are compiled off of the dts. So I GUESS ;-) that sys/gnu/dts/arm64/broadcom/ isn=E2=80=99t a dead = unused directory =E2=80=A6 Regards K. From owner-freebsd-arm@freebsd.org Sat Oct 10 00:22:00 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 BE88C43155F for ; Sat, 10 Oct 2020 00:22:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4C7Qc6562Dz3c4s for ; Sat, 10 Oct 2020 00:21:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: KEYldM0VM1kbZgAVyERZf_mOdA1En9CD.wg6U76EarnS0Enbw8mEVC8jbi0JtzB Ym8On8FUOm96sgNJUgcq9UeEO2pcE85.dmNcWTm3CuZhqrDnFR5n_J64U1jMEeLb_RF8_zvo8A9u lMd8Gxh91KchNXh0pb9ezcUweW91qmv8GtSSIgLMQdBCzhY_30snnC6SAedSJf_3BFSvQG2Qw5za 9UO6kRLwwJShAfrJArNGOaCTVOOYwHQKUvYeBT0Ornl3WaqORRu7uqT09lrNUUbdCjrvD97TslO4 wIWP9CExJ9GwCXMxIBZSjxi6GWiNGeEuyKjBuuZuC1A0Lnos8Hcn2Lg232dPScAcacLEHPf8Xiz_ KBfK196azan7JEWCkcmkH6uwGdSeQZhT9s1Fgw7MLtd_bMN_xUhsGtdwwV70Z9VopXpOsPxBD160 CVFqbquz65arEEtdrhTQxCwwqDvDLqbVNI2GQBFMM31XxksV643eellJtcVY7eiB5l8Yf6G4lD9B hBdjaO6zuQ4iOr_EADdlAYzF.97QhVwfs1VPRA5q0ieO771IeyIkPsdukkI.kvcNaeRZaGf2c8FG dB1dgbb1_CvSUml50wo3iaz6jsQkp4Af5xJ0s8PonJBIoe8iXtQD0JH4AvjPLcVFCb1pJrHmbSMG O3gJCRtpkCCjJ7mna8_.LIwQMQuueCKtRQpWD8G7ChLV3L069crQRXQ69h.qEHRavstYmX7p0W1S YcEYuP5Aqlr6oRwbEIcc1YIGL6WVeTD.x3xh2k0T2R58X__2fcpo86w83HVEgMv5XeuKdWYQfeil g9dS982qQm9DZzI93yW.4HugYY4Vjr4eBEvjfvURyknp8EczHDkiZOcKHRrApBWnttJbw3OASOPk 8Usi2wR7ZGA5cHgntj2SrvO.xJyOEIrITT4JbP9zmRgbxXGgCDgTBj85lmnooXFQc4r.tK5NdKVT um3IF4LQ5hNO0gRLOfaMGS_vp7U.5Td.ohoo62XA.Xm9s6g8okuyhMDmyQEKIaj6CsilmIzK2XDl lXRDR1wm6eQhKm3xTG7Ti0FjT7Q3i.mM_Iki9pRfAZh1.PCejzRO4jQsvc8LM5yIRX94UFZhrsbB a68QhhYy6U9ywxgc5rTbvbJudAw7PBtZdjeQaBV2LMDicTPZqWYt9VTYF2KCmWfVfWhD4SOhJEGO z1zvoV7SgoqKtiT5dQGNna7DW.KUhB0PfvanI8_W5AMdQQf4zapJi.5sRFoddz1AuzIxMhrGmDxc bjv3.QR_5Zjg1t5ahTVfXuYysjnSGUHgEjBE.73oXQ3hLXdC._P26.aaq281LvquMUaDlDl73L0y TEBlm9NtqIEZ49YH8lY4aW.yqL9VR.11BVFUGfH5VJLoPinrB0zpBQ_Tl5VZkUBmgvGiGUaq8mXy ZTZG1too_D.AO5YQYYl46SfCD2sp_9cQ37LDoYUckiZcbYIA4NxCLYMTurYfvdXQjogQ42FPoRdo cHnvmqa2FDOYnoOGlEs0meTTZ9yN67g4tcO_A9joqPlnfV_cFUG8oOW8IhUliGL1krAHwAizRnm8 - Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 10 Oct 2020 00:21:56 +0000 Received: by smtp414.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e9bbda6d2dc48703a606e8b7df55c48b; Sat, 10 Oct 2020 00:21:53 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <83BA1DDB-C725-470C-B382-9D229860E2F1@googlemail.com> Date: Fri, 9 Oct 2020 17:21:52 -0700 Cc: Robert Crowston , Kyle Evans , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <36A6B0E4-7578-4EFF-8095-9030DA36214B@yahoo.com> <83BA1DDB-C725-470C-B382-9D229860E2F1@googlemail.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C7Qc6562Dz3c4s X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.54 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.08)[-1.081]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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.97)[-0.974]; 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.987]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; FREEMAIL_CC(0.00)[protonmail.com,freebsd.org]; 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 00:22:00 -0000 On 2020-Oct-9, at 16:20, Klaus Cucinauomo = wrote: >> Am 10.10.2020 um 00:48 schrieb Mark Millard : >> =E2=80=A6. Sorry for the noise. =E2=80=A6... >=20 > the more noise, the more we find out ;-)..=20 > and of course also for me , probably all of us, that=E2=80=99s all = really confusing stuff from raspberrypi.org=20 > because very strange that ubuntu`msdos is compatible with 2020.10=20 > while their GitHub-stuff isn=E2=80=99t (in our msdos-part) . Does not go so well for FreeBSD in my context . . . My FreeBSD USB3 SSD is partitioned as: # gpart show -p . . . =3D> 40 468862048 da0 GPT (224G) 40 2008 - free - (1.0M) 2048 413138944 da0p1 freebsd-ufs (197G) 413140992 9437184 da0p2 freebsd-swap (4.5G) 422578176 204800 da0p3 ms-basic-data (100M) 422782976 46079112 - free - (22G) # gpart show -pl . . . =3D> 40 468862048 da0 GPT (224G) 40 2008 - free - (1.0M) 2048 413138944 da0p1 RPi4Broot (197G) 413140992 9437184 da0p2 RPi4Bswap (4.5G) 422578176 204800 da0p3 RPi4BEFI (100M) 422782976 46079112 - free - (22G) So it is the 3rd partition that has the msdos file system. Turns out that the start4.elf / fixup4.dat vintage in the ubuntu materials assumes the msdos file system to be the first one instead of looking for it. So, attempting to use the ubuntu vintage start4.elf / fixup4.dat, I end up with: QUOTE Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini =20 Type: Hard Disk Capacity: 228936.5 MB =3D 223.5 GB (468862128 x 512) ... is now current device ** Unrecognized filesystem type ** END QUOTE After that it tries to boot from ethernet (which was not connected). This is not true of the start4.elf / fixup4.dat vintage used by the uefi/ACPI v1.20 materials. That start4.elf / fixup4.dat pair finds and uses the 3rd partition for the msdos file system based material just fine.=20 So using older materials than the 2020-Aug-20 RaspiOS related ones does have tradeoffs. >> =E2=80=A6=E2=80=A6 >> . >> FYI for the u-boot vintage/variant involved for ubuntu: >>=20 >> # strings /boot/firmware/uboot_rpi_4.bin | grep 2020 >> gcc (Ubuntu 9.2.1-28ubuntu1) 9.2.1 20200203 >> 02/11/2020 >> U-Boot 2019.07+dfsg-1ubuntu6 (Feb 11 2020 - 10:43:57 +0000) > =E2=80=A6.. > I even didn=E2=80=99t boot it, just copied the msdos-part=E2=80=A6=20 > all files in ubuntu server msdos are of date /31st of July 2020 / That well predates 2020-Aug-20. /boot/firmware/ is the mounted msdos file system under ubuntu. uboot_rpi_4.bin is one of the things in that file system. > , the only reason why I used that distro is really because it seems to = be a raspberrypi.org official image =20 https://www.raspberrypi.org/downloads/ lists the following "Third Party Operating System Images" (down a ways on the page), saying: QUOTE Third-party operating system images for Raspberry Pi are also available: Ubuntu MATE Ubuntu Core Ubuntu Server OSMC LibreELEC Mozilla WebThings PiNet RISC OS Weather Station IchigoJam RPi END QUOTE Clicking on the image for one of those takes you to the third party's web site for it, such as https://ubuntu.com/download/raspberry-pi/ for "Ubuntu Server". The RaspberryPi-imager apparently gives access to some of those 3rd party operating systems images as well. > And I GUESSED(!;-) it has to boot up 2020.10 , and that was right=E2=80=A6= > But puuuh, all strange stuff What I report about finding and using the msdos file system is from before u-boot would have been started. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Oct 10 00:39:20 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 1BB7F431EEA for ; Sat, 10 Oct 2020 00:39:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4C7R063MGrz3d9r for ; Sat, 10 Oct 2020 00:39:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: maU81D4VM1kmjwkLcD_AkJWhtW5iXdPxo2IRfl39YBen5YhNsSBWxAGqbO9ymgf EIRRAE0IqYZOzfXBumv0NU3MbR7crKmzhZqDSmS4fWoh0BxtHJFin5B.6MF104bVvXFWY07Bo_EK 3IH_IlS4Fi9mJ54tJLUG3MvkO_LHTXJEbPl3hcLMBr7scw8NEmr7_RPzl7T334ENWLpZwfWJgCZF fwoNSMYuHpuOy3q1TpYD41GOY0WAhQQ1b8Lo8qNi59xx6ZvvZfyFs6VzlYV1iWNqBNOeDGoV85SJ RVmh11znBRmrUyrQH.yi5VDZ1gFkvNO6mZrY8RjYbTlM0o18sUQZQkO9QyNbPCZyzImeGDdtvxJd qkXrENTO9B9HnS.WE87xGR7j_SoGc5n7RTVCF2sGeHhUUe1i6XrISt1_U5vjnUmFRSnd2QeXttIg MyfjqAZSJRdroPFD2DjxsaMzKa_VZooz3UB7PNEK5HuFmfTEFyVySroIx3tpveNaoRh1j53ytT3_ EZqznOePkRYp6M6rE9Jg.BwgrEgSQwX_hLvbJrXA1SUass9Uu1sLspgoTfnYoXzEXRzS3DQISzZX DKew6SgpG_Qv3BjckBYTUEURsN3OdU4DmeCsDmItdlsitbiRvS9o6lCWwux1PfgEmCThigLxY52_ TmHsHYuJR2fha0hv6IT.rufZ2UKDd9ibmhsEvQgUU4l30UTpAREgZIG3RAgZIbQ4xrcYwISlKIyt yLrKnSBR1xzS28PJQZgey.2gcA0oCiKDAAddQjC3QJQHaiyxi0y7GZ6Fft_MSKaJyJHQWHlunfCn F5VmxiyiB_G_1qlaxHqQ3etYG1YfqUkBnYxiQ0Em0zpOyG4p4JmPh5K2s56iB.hbBo3_s6mDrWvd jJRHtMtYgjddvgdLm6UU7uBgTuxTBS51QUzYha_TbYfqMymBj3AfYVfI4EqUHOEFWihuh5WvFhOC m5Rdb1Az4YAFrG2okyAAtjtavPGtNBFue09gE61SnGOhuObNjvqKUdzvh7.2IABoHPpcMU8BG50B qGjrOYnXbe.CR7E9A4WU8gnBMqnZvsQhnVl67DNpTV9jdS2madN79fnlqieBtd9nWfv2qogGth9y H.jXFLSuNLhjxnCe1Zx7XaejDa5OtvdNf5geurThmwfZu9ylfiCabHQ78pEhwiEvinVdIOf4iA0l HocyYskYwpx7lf4EBdFzx1pBaYv83ICMS4vbd0a2utb0AOAc2HjOz.sof5NKS3Du4sRoMhOjyNZx ioj.F3P9XSuG2ve_YTgrOG5ReQQoGXDYSB2ioPrxyINxNfNfxxwLZyHNcis9fzYj0NdVVla9pVXj c_xa33o2t9OU0PTaEK21vpXOVnorXHF4b3oUEGl9HsRR5cU1dcrpYRNdPBR8XugO_BjmxH3Iproj IQo6EZ6wPDyWs1Nre9qB9TK7cFTfxOwFcXKdMEcPU3K3ZCfXlp5knGB8RFEwIv2oJh1LTN1dS6uw a2Ulqz94yDX._YXW2_5.hj5Tq27qpi8gNuF2G72.IqhYTWc0Fk43_83TFKlJw6qhORngREXvxdfe UTWqP Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 10 Oct 2020 00:39:15 +0000 Received: by smtp406.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 85b52a3704df94eaf3d496a9cc913c28; Sat, 10 Oct 2020 00:39:14 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <27E7A6A9-04A4-4B15-96CB-84AE478ED755@googlemail.com> Date: Fri, 9 Oct 2020 17:39:13 -0700 Cc: Kyle Evans , Robert Crowston , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <93E411FA-6024-4E2F-AAFF-C051AF4F35EE@yahoo.com> References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <27E7A6A9-04A4-4B15-96CB-84AE478ED755@googlemail.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C7R063MGrz3d9r X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.54 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.08)[-1.078]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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.97)[-0.974]; 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.988]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; FREEMAIL_CC(0.00)[freebsd.org,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 00:39:20 -0000 On 2020-Oct-9, at 17:17, Klaus Cucinauomo = wrote: >> Am 09.10.2020 um 23:25 schrieb Mark Millard : >>=20 >> FreeBSD imports lots of linux-dts material that it does not put >> to use. Only some of the imported material is used. >>=20 >> release/arm64/RPI3.conf indicates use of: >> (There is not RPi4 release yet.) >>=20 >> DTB_DIR=3D"/usr/local/share/rpi-firmware" >> DTB=3D"bcm2709-rpi-2-b.dtb bcm2710-rpi-3-b.dtb = bcm2710-rpi-3-b-plus.dtb bcm2711-rpi-4-b.dtb" >> . . . >> EMBEDDEDPORTS=3D"sysutils/u-boot-rpi3 sysutils/rpi-firmware" >> . . . >> UBOOT_DIR=3D"/usr/local/share/u-boot/u-boot-rpi3=E2=80=9C >> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6. >>=20 >> It is not using sys/gnu/dts/arm64/broadcom/ material. >=20 >=20 > ah, `forgot to mention : > [dtb =3D DeviceTree-Blob =3D=3D compiled dts(DeviceTreeSource)] > So the dtb`s you mention are compiled off of the dts. > So I GUESS ;-) that sys/gnu/dts/arm64/broadcom/ isn=E2=80=99t a dead = unused directory =E2=80=A6 Look at the sysutils/rpi-firmware port that creates and fills in /usr/local/share/rpi-firmware/ with the .dtb files that are copied by the above procedure. It makes no use of sys/gnu/dts/arm64/broadcom/ at all. Instead it does things like the following in its Makefile: USE_GITHUB=3D yes GH_ACCOUNT=3D raspberrypi (I omit a 2nd account that is also listed.) GH_PROJECT=3D firmware (I omit a 2nd project that is also listed.) FW_TAG=3D 2042453 . . . GH_TAGNAME=3D ${FW_TAG} (I omit a 2nd TAGNAME that is also listed.) and in its distinfo it has: TIMESTAMP =3D 1596906388 SHA256 (raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz) =3D = a90ce74236fa04cbb11232c077a1271afdeefb5b0af417a88076c4948e569cd4 SIZE (raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz) =3D = 186178244 (I omit a 2nd file that is also listed.) So it gets a .tar.gz from github that supplies the material, in a already compiled/built form as it turns out. No use is made of FreeBSD's sys/gnu/dts/arm64/broadcom/ by this = technique. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Oct 10 01:08:25 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 55E08433464 for ; Sat, 10 Oct 2020 01:08:25 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C7Rdh3X21z3fww for ; Sat, 10 Oct 2020 01:08:24 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x334.google.com with SMTP id d3so11432415wma.4 for ; Fri, 09 Oct 2020 18:08:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=GWNpszfwUlRaJABGEdrSuMQQ9ldausolPYl9O3joDD8=; b=Ut7IVSxfbbqFS8/Hw/3LHVhoRR98ldinKPqH+BiFVhMTL9D46tc4N3WkjNnt4PIskM eSdyx3n/ik3ZgVkF3BQkmrhlbgvFkSQSoDzzyEXDY2h6ZSaK9s8cqWlb/3p2suushKmn C2zTZUhXasqqcj6tcWK+xDXNw0yJpBHmdiUb+eebTjPtx1nzSE+urFaJX/hEvOiDkEFZ TMUJzmC52Hmtab3XJINm5iTYjIDnwUK1slQCs5HJ7qdVno4jrlevaKoO4sW6Wq59i/SH b29ohket/b8fiyH0J3DZifgvLSWJ9IiTMOMaCDFJXsBG06YMiIuCbuvdilLF4TEzFzbR TTaQ== X-Gm-Message-State: AOAM532ueZwNxKgb9VEy4D07qZ+Q3ar+6HqgTxy2fKGgfV6Li1qy02sC qbDaIgHLy/3hGGq+uaA1PiE= X-Google-Smtp-Source: ABdhPJwr3059suyQyQNKoxM4UW/dmqADDicDlJ3WYakl0w7MM9UuDXrrmV4sul8EKUJz2zrVlizZdw== X-Received: by 2002:a1c:9d90:: with SMTP id g138mr482139wme.5.1602292102823; Fri, 09 Oct 2020 18:08:22 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-104-055.46.114.pool.telefonica.de. [46.114.104.55]) by smtp.googlemail.com with ESMTPSA id r1sm13355891wro.18.2020.10.09.18.08.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 18:08:21 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Date: Sat, 10 Oct 2020 03:08:19 +0200 References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <27E7A6A9-04A4-4B15-96CB-84AE478ED755@googlemail.com> <93E411FA-6024-4E2F-AAFF-C051AF4F35EE@yahoo.com> To: Mark Millard , freebsd-arm@freebsd.org In-Reply-To: <93E411FA-6024-4E2F-AAFF-C051AF4F35EE@yahoo.com> Message-Id: <7CB99D94-6F37-4150-9D1B-9488D4FE83EF@googlemail.com> X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C7Rdh3X21z3fww X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.62 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-1.15)[-1.147]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.971]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.104.55:received]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::334:from]; RCVD_TLS_ALL(0.00)[]; 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 01:08:25 -0000 > Am 10.10.2020 um 02:39 schrieb Mark Millard : > =E2=80=A6=E2=80=A6 > ... > No use is made of FreeBSD=E2=80=99s sys/gnu/dts/arm64/broadcom/ by = this technique. >=20 Seems to be unclear(at least to me), whether ever used or never ...while absolutely possible that you`re right here. ` have discussed that with Rob Crowston & Mike Karels some time ago,=20 The problem was the bcm2711-rpi-4-b.dtb , which at that time shouldn=E2=80= =99t be changed because to stay compatible with the 8GB-model., so possibly since then there never was a newer dts compiled to dtb. But I G U E S S(still can=E2=80=99t resist;-) that we now have to = patch&compile( at least bcm2711-rpi-4-b) to stay in touch with 2020.10 > Am 10.10.2020 um 02:21 schrieb Mark Millard : > My FreeBSD USB3 SSD is partitioned as:=E2=80=A6=E2=80=A6.. > After that it tries to boot from ethernet (which was > not connected). Tomorrow I will look again exactly with which partition tables I booted = the SSD,=20 for today I am completely dizzy from all that rpi-dtb stuff , I can=E2=80=99= t remember what I did :-) From owner-freebsd-arm@freebsd.org Sat Oct 10 01:46:28 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 232EE435757 for ; Sat, 10 Oct 2020 01:46:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4C7STZ5Xx3z413h for ; Sat, 10 Oct 2020 01:46:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: WamZx7gVM1kObKlQL5ol4..yiqh3whAYiCSdAdg8MOmmj2HAmQcnbNfSllj3hS9 8X39PJ8eHT_j4.yTsUtG9jhu026r87WVq6EqN69FMdBtHsGCnqqqV9dNXE0Pr._xnDhcvgyQ6k5H faSNas3SC8L6y3TFT3GqkvPApNFRAeIvlRt24wpNqfoDgXGHN5LqLXPPt7PhGhw7dsvuljcC0Wbf zNFjm5yoPdDnY4AVrjYWY64acyxaewzcKKZBZIpwpAiLE3R6XzmOYaPy2ba_o3hFzHPkRcNv7Nrp IF9xnjtzG6qy8lylNF9jBGSitQWp9Yjcyioh3bPhJqB64.5R09lPw8MxxPwJ5sb80EgKEdnhARuz L_1hU6RwNzGN8UVWLNn59Nr7lV.ig0i5lTgVV6HY923jDzM_xiges3eS6xEzW_vUGgfTPVAybNG5 2NAh9IbXX1Naquk2qnCn3QNf0HMZVun1OrADGE23S8ndfW3Toh3kZ4F5RPcXXkxPId1qR.abyc65 u_D5W9AZosf1O1QihxZil11cZKpz.3zHC4ofKgLG_ocNQbVAP_z6O_nUoDYnFFroT3c3gW9RCqq9 5PssT.qX7DUxO98LXFDlni7SrkrFp_K4gAqDtBB1Q2CWp8xreFi8JJXHqfgk55qKPtrXAGhA853R Qs8gk6jFUlxzLfQ4l4CONp2lXvl1trEl4dmnOrHGs140rM5KFjgkG88u72z.p0CA_o4M486rKFGw 1g0ZVWfu2JW08yd4AOdkVK2bwH1f5lyI6omtRZqUdqHbK8HVt2llTMdqfOphJJgcBWe3GBslEz3D gUf8ruf6Ojob72dYcEri2B6bodARHh_0CD0TinFVMpABeJuHVn3d7RzxfBEPv0P6s9RXdSZhGYrZ MaMiJIVAr2aORa.6phl8Lb.IucW9KbnRcOytIYbv5PymaPmKo9BKDiNXTPJZMWf2gK0GlysDZ_8z sJo3Hn9YQZqrJstUE6lR64P5Jm79rARXdTOA3AfS_CrKVzja8smAjOpxZRYsPwf6qTqY_rmC5dNM nV6.zURSQpT6ybz0kMs0SSL5rI_XX4WvXqG3mMzeEL3P0ZICUET6jpD2dxiTNhOAKFK.CcN2G2Wn avToDK1oFdV7r52fttAkrD3rH1lFOMWJcKWSDxZhbKg4v_UNsHD1cTQJfsZ0y0jYofDIQ4i__ckI J05lJHvjeMhswP_5JYp7_5k4IFYf66_IXfEpi8usQBp2bGmRctOfqLxuk_NgS2RRG2FakN6nnXuG y_fbZ2kpxWRSDbpSVAlUDPauy9I60itAhkdifeF6WLsEa1ifqWQiOx20XouvjFg05fpheCK_CIZD hIZkRzo5etG1bSZIJpuJtwu5cf6G5uiQOX_jn2wzDE9RKOvhKxeUTD4lnnlBeTKFY7lc5i6em6y7 vGNKDo2MRYpovWAyXrqejWe.Zqza.m2jnr8CGjMqvRgNGgTcplWi5YviMIi5gSc4L4b9x2SCYwHq 6SfCIFw.qUiVX1qI9yPQjypPHhwqvHtG81ocpUYEh1TmmJqIamJQdK4WqSkQJSDUAEIGRpgJLu4a JT265BLjjwIn2DSNOjM46ofKk_G61ZitRzfs- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 10 Oct 2020 01:46:24 +0000 Received: by smtp401.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6f3edf89877cf1e27f49d481f4efe051; Sat, 10 Oct 2020 01:46:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <7CB99D94-6F37-4150-9D1B-9488D4FE83EF@googlemail.com> Date: Fri, 9 Oct 2020 18:46:20 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <27E7A6A9-04A4-4B15-96CB-84AE478ED755@googlemail.com> <93E411FA-6024-4E2F-AAFF-C051AF4F35EE@yahoo.com> <7CB99D94-6F37-4150-9D1B-9488D4FE83EF@googlemail.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C7STZ5Xx3z413h X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.59 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.12)[-1.121]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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.97)[-0.973]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; 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 01:46:28 -0000 On 2020-Oct-9, at 18:08, Klaus Cucinauomo = wrote: >> Am 10.10.2020 um 02:39 schrieb Mark Millard : >> =E2=80=A6=E2=80=A6 >> ... >> No use is made of FreeBSD=E2=80=99s sys/gnu/dts/arm64/broadcom/ by = this technique. =46rom the log for one of my builds of sysutils/rpi-firmware : ( I ignore armstub8*.bin related things. ) =3D=3D=3D> License BROADCOM accepted by the user . . . =3D> Attempting to fetch = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz . . . =3D=3D=3D> Extracting for rpi-firmware-1.20200723.g20200723 =3D> SHA256 Checksum OK for = raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz. . . . =3D=3D=3D> Patching for rpi-firmware-1.20200723.g20200723 cp -f /usr/ports/sysutils/rpi-firmware/files/config.txt = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/ cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi_0_w.txt = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/ cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi3.txt = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/ cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi3_edk2.txt = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/ cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi4.txt = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/ /bin/rm -f = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/kernel= .img /bin/rm -f = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/kernel= 7.img . . . So, if you want to see what sysutils/rpi-firmware is currently based on, you can try that: fetch = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz yourself and then look at the content of the .tar.gz produced. When I try it: fetch = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz fetch: = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz: size of = remote file is not known raspberrypi-firmware-1.20200723.g20200723-2042 177 MB 8136 kBps = 22s # tar -tf raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz | = more firmware-2042453/ firmware-2042453/.github/ firmware-2042453/.github/ISSUE_TEMPLATE/ firmware-2042453/.github/ISSUE_TEMPLATE/bug_report.md firmware-2042453/README.md firmware-2042453/boot/ firmware-2042453/boot/COPYING.linux firmware-2042453/boot/LICENCE.broadcom firmware-2042453/boot/bcm2708-rpi-b-plus.dtb firmware-2042453/boot/bcm2708-rpi-b.dtb firmware-2042453/boot/bcm2708-rpi-cm.dtb firmware-2042453/boot/bcm2708-rpi-zero-w.dtb firmware-2042453/boot/bcm2708-rpi-zero.dtb firmware-2042453/boot/bcm2709-rpi-2-b.dtb firmware-2042453/boot/bcm2710-rpi-2-b.dtb firmware-2042453/boot/bcm2710-rpi-3-b-plus.dtb firmware-2042453/boot/bcm2710-rpi-3-b.dtb firmware-2042453/boot/bcm2710-rpi-cm3.dtb firmware-2042453/boot/bcm2711-rpi-4-b.dtb firmware-2042453/boot/bootcode.bin firmware-2042453/boot/fixup.dat firmware-2042453/boot/fixup4.dat firmware-2042453/boot/fixup4cd.dat firmware-2042453/boot/fixup4db.dat firmware-2042453/boot/fixup4x.dat firmware-2042453/boot/fixup_cd.dat firmware-2042453/boot/fixup_db.dat firmware-2042453/boot/fixup_x.dat firmware-2042453/boot/kernel.img . . . firmware-2042453/boot/overlays/wittypi.dtbo firmware-2042453/boot/start.elf firmware-2042453/boot/start4.elf firmware-2042453/boot/start4cd.elf firmware-2042453/boot/start4db.elf firmware-2042453/boot/start4x.elf firmware-2042453/boot/start_cd.elf firmware-2042453/boot/start_db.elf firmware-2042453/boot/start_x.elf . . . (I'll not list it all.) The .tar.gz provides the .dtb files directly., no compilation needed. The .tar.gz contains lots of unused files and directories as well as the ones to be put on RPi* media. > Seems to be unclear(at least to me), whether ever used or never > ...while absolutely possible that you`re right here. > ` have discussed that with Rob Crowston & Mike Karels some time ago,=20= > The problem was the bcm2711-rpi-4-b.dtb , which at that time = shouldn=E2=80=99t be changed because to stay compatible with the = 8GB-model., > so possibly since then there never was a newer dts compiled to dtb. The fetch command picks out a specific commit and ignores more recent commits (until the Makefile and distinfo are changed to cause and check the results of a different fetch command). > But I G U E S S(still can=E2=80=99t resist;-) that we now have to = patch&compile( at least bcm2711-rpi-4-b) to stay in touch with 2020.10 >=20 >> Am 10.10.2020 um 02:21 schrieb Mark Millard : >> My FreeBSD USB3 SSD is partitioned as:=E2=80=A6=E2=80=A6.. >> After that it tries to boot from ethernet (which was >> not connected). >=20 > Tomorrow I will look again exactly with which partition tables I = booted the SSD,=20 > for today I am completely dizzy from all that rpi-dtb stuff , I = can=E2=80=99t remember what I did :-) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Oct 10 01:54:12 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 482A943640B for ; Sat, 10 Oct 2020 01:54:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4C7SfW0Bbcz41bM for ; Sat, 10 Oct 2020 01:54:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: qTuw3KAVM1nskXO2Cp2QVm6NoPBn6GOUwD1omONBmHTP0JmKne25P.DqCurgtX2 pYfAHoMaRLs3GhZ.eixV.H9xNBPPmIImAX2nQQk5lYaju2eNOBTYmmTAKFTgnggD8OMxi2I28cUb UHqurX8GaBl9okum8a2EC304TkNocOBY4m2J6NLbcA6LrQ8SPzBaSqFza7kuGR2TSyizBAupdygc 4hndEPRGYwCClFKYeYwtapDjpgGRC6AUgMHy0y3ZOL.p0Yj0RsfaIMVK6sa_MNnAtmsQH0LXED4o QJduZevMjb5KS7rGrYHbydOqeIIvbUWiY8R1lBMijReFShP.mNS35fEAAoK6S6V2xOcWVCin90rA bBs.yRFNEPqGSDxmNMGGk1Nm6yR1MflBIYRAAPHJKxmESwoQLFQblIWFxIU7KuPsGHAA0rGBigwK o1u.aG5MxNn0dFH_cvQvvWIH.pZ7oewLBgtxwhlMBNZjvUSyPwdKRJAQ_6VOZceB9Y7ZC1n_mfJG ZNeToFd2RGTfKZ6yK_Qef9IiAt9MNhLVZFuKLOiw8hZxeo0TbF2KW7KV4pbAMN6W3KCkQglZlKjW Wjm3SqeR7dBzo1pIiXwdSNyUV6ZdG9anONY6hwrqTrk6bN4IlEk6MLFy4Ov4dOE08siJRdKE7hKu 9Bx0sVINXRT8Bvi5E8ORfYNwc59N2v5qsPRSZBNuLi7zqh6Y.4grDJtdwQi4BgRletCLQ9cMEVXM drQq2TBm7sDrFIn0X0p8EYObDXBZUQuD3g0pFK5ok.wU2A38uTN6b5NXNQnkj0lZsPYRObrBzV0i CwOLVmenvDI_E32EeCyxJffPlH7RYv0qItkBScEjhoh68lftcECxMLurGqwWnFe1DIC_hfahnG4F fpWdqFNL6BBg8FtO9NA14sh8qdyUYsVaczi0Cd5IHbzyLo74eLjBh2Sa9.jZNV5vCX5zj5nYCoTb u4UFb3wtR1zC4yZEJpuzbKMwQvakv9yyp8cJJmCRNLn6Bdp1VMQfNXrqkfqcmCVa5e3H_nONmdfn kRYze.9MFSEN_nl2SZKm.VgZOgj8RtPAt.pYZGPZ2M9cJzXrXwt19GXEalxcNaD4dhzvLaIhKL0E q8lDNXTUG.GlAq4awfJAt3TDuunpJ9JMOFG.4R1BplXsCPls86XM.6j8TX.5W5aI81r18qW9SK7k HgyPIN4jLBmJ1reggR1nW95KqurM7WgvIi7B8w1Ei3gMxFJwSvzCtQ.4yQ.gcZ6NUQVTv4Aza_sd pFDGu118xkdPXAV2LQ.y1vk4BlD7e22I3vhcxyqM_M5fYRFWpFhH.mKcRU0kdTnRvq4UAtLgoSIN QyIe9iLpxLjpHB28YM5OBY1Gy9jAq9O7N3qdE8Hk_qyVXbDECk86Y5BYAmDYqlEwR2U0yBSY_J6J qe3lmbWLzbfW0x5ysYdmtBEjaXdWxHqsWstJ_04LEinKdFvIui.7zEabjq_ycxn.YAGwbzzzE2K9 BXDTRx8IBqLnWpXok3saN6_UaaWbTtcUsDdBUud5iu3TlfoB7PF026_CB9i2dT7DaXK7NZ9rvqM9 L5uNIRwyBJgBn0_f2WGwwzWRfz6Pf8ixSEYY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 10 Oct 2020 01:54:08 +0000 Received: by smtp404.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a14b12f270e082c1acfdeec7e322dcd6; Sat, 10 Oct 2020 01:54:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: Date: Fri, 9 Oct 2020 18:54:06 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5B658E5E-C438-4A05-99F5-8E4B67A89488@yahoo.com> References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <27E7A6A9-04A4-4B15-96CB-84AE478ED755@googlemail.com> <93E411FA-6024-4E2F-AAFF-C051AF4F35EE@yahoo.com> <7CB99D94-6F37-4150-9D1B-9488D4FE83EF@googlemail.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C7SfW0Bbcz41bM X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.59 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.12)[-1.121]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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.97)[-0.973]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; 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 01:54:12 -0000 On 2020-Oct-9, at 18:46, Mark Millard wrote: > On 2020-Oct-9, at 18:08, Klaus Cucinauomo wrote: >=20 >>> Am 10.10.2020 um 02:39 schrieb Mark Millard : >>> =E2=80=A6=E2=80=A6 >>> ... >>> No use is made of FreeBSD=E2=80=99s sys/gnu/dts/arm64/broadcom/ by = this technique. >=20 > =46rom the log for one of my builds of sysutils/rpi-firmware : > ( I ignore armstub8*.bin related things. ) >=20 > =3D=3D=3D> License BROADCOM accepted by the user > . . . > =3D> Attempting to fetch = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz > . . . > =3D=3D=3D> Extracting for rpi-firmware-1.20200723.g20200723 > =3D> SHA256 Checksum OK for = raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz. > . . . > =3D=3D=3D> Patching for rpi-firmware-1.20200723.g20200723 > cp -f /usr/ports/sysutils/rpi-firmware/files/config.txt = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/ > cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi_0_w.txt = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/ > cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi3.txt = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/ > cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi3_edk2.txt = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/ > cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi4.txt = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/ > /bin/rm -f = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/kernel= .img > /bin/rm -f = /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/kernel= 7.img > . . . >=20 > So, if you want to see what sysutils/rpi-firmware is currently based = on, > you can try that: >=20 > fetch = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz >=20 > yourself and then look at the content of the .tar.gz produced. >=20 > When I try it: >=20 > fetch = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz > fetch: = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz: size of = remote file is not known > raspberrypi-firmware-1.20200723.g20200723-2042 177 MB 8136 = kBps 22s >=20 > # tar -tf raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz = | more > . . . > . . . >=20 > (I'll not list it all.) >=20 > The .tar.gz provides the .dtb files directly., no compilation > needed. >=20 > The .tar.gz contains lots of unused files and directories > as well as the ones to be put on RPi* media. A better listing would have shown dates and such: # tar -tvf raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz = | more drwxrwxr-x 0 root root 0 Nov 22 2019 firmware-2042453/ drwxrwxr-x 0 root root 0 Nov 22 2019 = firmware-2042453/.github/ drwxrwxr-x 0 root root 0 Nov 22 2019 = firmware-2042453/.github/ISSUE_TEMPLATE/ -rw-rw-r-- 0 root root 2147 Nov 22 2019 = firmware-2042453/.github/ISSUE_TEMPLATE/bug_report.md -rw-rw-r-- 0 root root 1255 Nov 22 2019 = firmware-2042453/README.md drwxrwxr-x 0 root root 0 Nov 22 2019 firmware-2042453/boot/ -rw-rw-r-- 0 root root 18693 Nov 22 2019 = firmware-2042453/boot/COPYING.linux -rw-rw-r-- 0 root root 1594 Nov 22 2019 = firmware-2042453/boot/LICENCE.broadcom -rw-rw-r-- 0 root root 24201 Nov 22 2019 = firmware-2042453/boot/bcm2708-rpi-b-plus.dtb -rw-rw-r-- 0 root root 23938 Nov 22 2019 = firmware-2042453/boot/bcm2708-rpi-b.dtb -rw-rw-r-- 0 root root 23719 Nov 22 2019 = firmware-2042453/boot/bcm2708-rpi-cm.dtb -rw-rw-r-- 0 root root 24379 Nov 22 2019 = firmware-2042453/boot/bcm2708-rpi-zero-w.dtb -rw-rw-r-- 0 root root 23643 Nov 22 2019 = firmware-2042453/boot/bcm2708-rpi-zero.dtb -rw-rw-r-- 0 root root 25265 Nov 22 2019 = firmware-2042453/boot/bcm2709-rpi-2-b.dtb -rw-rw-r-- 0 root root 25394 Nov 22 2019 = firmware-2042453/boot/bcm2710-rpi-2-b.dtb -rw-rw-r-- 0 root root 27054 Nov 22 2019 = firmware-2042453/boot/bcm2710-rpi-3-b-plus.dtb -rw-rw-r-- 0 root root 26435 Nov 22 2019 = firmware-2042453/boot/bcm2710-rpi-3-b.dtb -rw-rw-r-- 0 root root 25249 Nov 22 2019 = firmware-2042453/boot/bcm2710-rpi-cm3.dtb -rw-rw-r-- 0 root root 40659 Nov 22 2019 = firmware-2042453/boot/bcm2711-rpi-4-b.dtb -rw-rw-r-- 0 root root 52304 Nov 22 2019 = firmware-2042453/boot/bootcode.bin -rw-rw-r-- 0 root root 6744 Nov 22 2019 = firmware-2042453/boot/fixup.dat -rw-rw-r-- 0 root root 6193 Nov 22 2019 = firmware-2042453/boot/fixup4.dat -rw-rw-r-- 0 root root 3089 Nov 22 2019 = firmware-2042453/boot/fixup4cd.dat -rw-rw-r-- 0 root root 9181 Nov 22 2019 = firmware-2042453/boot/fixup4db.dat -rw-rw-r-- 0 root root 9183 Nov 22 2019 = firmware-2042453/boot/fixup4x.dat -rw-rw-r-- 0 root root 2655 Nov 22 2019 = firmware-2042453/boot/fixup_cd.dat -rw-rw-r-- 0 root root 9816 Nov 22 2019 = firmware-2042453/boot/fixup_db.dat -rw-rw-r-- 0 root root 9816 Nov 22 2019 = firmware-2042453/boot/fixup_x.dat -rw-rw-r-- 0 root root 5142424 Nov 22 2019 = firmware-2042453/boot/kernel.img . . . -rw-rw-r-- 0 root root 1056 Nov 22 2019 = firmware-2042453/boot/overlays/wittypi.dtbo -rw-rw-r-- 0 root root 2880356 Nov 22 2019 = firmware-2042453/boot/start.elf -rw-rw-r-- 0 root root 2775076 Nov 22 2019 = firmware-2042453/boot/start4.elf -rw-rw-r-- 0 root root 775872 Nov 22 2019 = firmware-2042453/boot/start4cd.elf -rw-rw-r-- 0 root root 4582664 Nov 22 2019 = firmware-2042453/boot/start4db.elf -rw-rw-r-- 0 root root 3536680 Nov 22 2019 = firmware-2042453/boot/start4x.elf -rw-rw-r-- 0 root root 688068 Nov 22 2019 = firmware-2042453/boot/start_cd.elf -rw-rw-r-- 0 root root 4857160 Nov 22 2019 = firmware-2042453/boot/start_db.elf -rw-rw-r-- 0 root root 3794600 Nov 22 2019 = firmware-2042453/boot/start_x.elf This illustrates the lack of updates based on lack of updates to the Makefile and distinfo file. More recent material is available from github but is being ignored for now. >> Seems to be unclear(at least to me), whether ever used or never >> ...while absolutely possible that you`re right here. >=20 >> ` have discussed that with Rob Crowston & Mike Karels some time ago,=20= >> The problem was the bcm2711-rpi-4-b.dtb , which at that time = shouldn=E2=80=99t be changed because to stay compatible with the = 8GB-model., >> so possibly since then there never was a newer dts compiled to dtb. >=20 > The fetch command picks out a specific commit and ignores more > recent commits (until the Makefile and distinfo are changed to > cause and check the results of a different fetch command). >=20 >> But I G U E S S(still can=E2=80=99t resist;-) that we now have to = patch&compile( at least bcm2711-rpi-4-b) to stay in touch with 2020.10 >>=20 >>> Am 10.10.2020 um 02:21 schrieb Mark Millard : >>> My FreeBSD USB3 SSD is partitioned as:=E2=80=A6=E2=80=A6.. >>> After that it tries to boot from ethernet (which was >>> not connected). >>=20 >> Tomorrow I will look again exactly with which partition tables I = booted the SSD,=20 >> for today I am completely dizzy from all that rpi-dtb stuff , I = can=E2=80=99t remember what I did :-) >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) 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) From owner-freebsd-arm@freebsd.org Sat Oct 10 07:14:39 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 72C8F43E3BE for ; Sat, 10 Oct 2020 07:14:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (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 4C7bmF5NJFz4Jqt for ; Sat, 10 Oct 2020 07:14:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: IAfj1qEVM1mYdgP7DM9iAzQCokCBhJhWJ8IjWLvIastN9Ojv_iguXdVkjlaB_I7 _lquhndbe6UyZuCZGlSulb184Z4eidasZPcNEMPT_YEqG8Jcki6ez8CYDC0GMcml2GIPDZ5.QPcB 7iGWf59ABYnFlEIbZx0ZEJ4CwIkHD2ICRc_vbvNczkIkk5kRU7nvZj54ofnQ8NSa5F_uevKhjQ6Y 7zCzGUcSI49JffGyUrkDx23AAK_L6SrEWrXnOY02Kb7HTQyn_fofG7MZOFKRN.nco1HJ0nsbKx0L 8xIi7w_4rOpUz2YfkgIj7LsqdpXlX6FMklF0m_3JHWB4D1QIrv2X9g_QauE3Nc7C5WI2vx0piOci 5IMfvnRD.bBM5u5tvTLoAqR3qrsz3WmzW.IhEn2pzIFrdRw9A4ASALPq6Gbl5mgnI.pEZdIWLkyg L7Kcrc5DUu5Ex8PGNFoMmMXTUl8IdX_ypQYPjJMEYXimvfmEUsSha1c8Z718T3t7lsC11qej94PB OaeYuf3BaFPvcDF_vhrNBeuQZnyl78sGbnh.ATnAzEYSOofqPg05lk4c2UOklkyHHrTHiZ5FOTJn 6WH3HuR33FODTifuBpBwXTKQTPzEZDFL8aNICJhtN7nNOM3BVq8avknD8B11a6DxSdWdwQ7vb2ZP AMgmbe3QKBTLBnJntAX1UWAVA_OQ.EdQbrNORlOAfUZ3kFtXG27qqyK7eibbNlWQwczZzPHn55St MkI7TGj89iXbQg56jkHCHF__XmQrdogSgwXFHMzncOYDrhppPDmK1RXm8139qTFlFn.zwxiMKzqN QWIvFRyO0W0CGvJPi_1oYrfpyjNFiyPtI0MLFLNQv4ZMy0HolvIgkEPT1wpqhJnslS_YCkMx6nkC 9HP2FMstK4TQW5RvVOfVgtE4AwkmAol89IFv.XziexxrbH.iqPduUuscnB7TnsFoybq4UFvcLEX8 4qdksjRjNNFYXmH7Uef4phdasZP_MFtkTj7iRtXHLyxWMU_qzfxDow6N74kNTTw6i3bGkwczIIyZ 40zd4fuM5UcEVXYC3uwBrtJs7C7frwW2RORy3zsdgH50LEcsEXYgYucs0ucuJTXDKQGyhsPhCCrl u0aHslfENbjoMIkmA6N9SNsJYkSjDQh3sPL8qrdgs_cXYxaU3bUUvm8UAAdjfl7z7bZ8K0OFMpQQ LE4YYJrwMtT8p5nXoQN0S4TT6KTg4rFZoE.sMgdgIRjT.kynvPcNgSMQDGMSdDrHLSH5Fdte8NFe QI6fpRJsrhQrwbmHYehrieGFhYR3KBmPy75HffG_m6JmPLHY60ijr74hlZNCU64wNaYTvDzPPefp Xp9Hysj7Ed5X3ZG8VQl6T1cjYVeuouyBwzhdupNGFuZXiokd6sJdU07c_PoxZdwo7P86OrMJ7FmK Cr01LeUxFmRArHUZPA6dTxtBpYC_TX7ASW9AegBrV_52MVhhHGgFcMgJJS6yHwPG58nnSHqSpQdp 8a4bb5bRhHVSfDP8l0R49ddoIdStKwu0fc44dAp4pWudFu3c.NyE1qPtOlrDrIlsF33qSJ.WcCdL yplfJCP3hHBsQHumgmC6qJ7OzPwiI9p7EuopR Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 10 Oct 2020 07:14:34 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 84dbf4c6108faa33476407e6634b7b47; Sat, 10 Oct 2020 07:14:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) From: Mark Millard In-Reply-To: <5B658E5E-C438-4A05-99F5-8E4B67A89488@yahoo.com> Date: Sat, 10 Oct 2020 00:14:32 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <27E7A6A9-04A4-4B15-96CB-84AE478ED755@googlemail.com> <93E411FA-6024-4E2F-AAFF-C051AF4F35EE@yahoo.com> <7CB99D94-6F37-4150-9D1B-9488D4FE83EF@googlemail.com> <5B658E5E-C438-4A05-99F5-8E4B67A89488@yahoo.com> To: Klaus Cucinauomo X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C7bmF5NJFz4Jqt X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.61 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.14)[-1.135]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.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.97)[-0.974]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; 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 07:14:39 -0000 On 2020-Oct-9, at 18:54, Mark Millard wrote: > On 2020-Oct-9, at 18:46, Mark Millard wrote: >=20 >> On 2020-Oct-9, at 18:08, Klaus Cucinauomo wrote: >> . . . >>=20 >>> But I G U E S S(still can=E2=80=99t resist;-) that we now have to = patch&compile( at least bcm2711-rpi-4-b) to stay in touch with 2020.10 I've reproduced the "hangs during rainbow" problem in a microsd-card-only context when modern firmware is in use with u-boot 2020.10 . USB3/xHCI/PCIe access-attemtps are not required for the problem to happen. I've sent other E-mail about it, but my hypothesis is that the armstub8-gic.bin requirement for: device_tree_address=3D0x4000 and where/how start4.elf and fixup4.dat are loading before the device tree activity are conflicting=20 for how things are kept track of in RAM for start4.elf and fixup4.dat --and the two activities are stomping on or using some of each other's values in memory. I expect that the older firmware has the structural conflict with armgstub8-gic.bin as well but just happens to be less likely to run into a conflict that made it obvious that there was a problem. As far as I can tell, it would have to be armstub8-gic.bin 's requirements that would have to change if I'm correct about the above. ( Similarly for armstub8.bin .) >>>> Am 10.10.2020 um 02:21 schrieb Mark Millard : >>>> My FreeBSD USB3 SSD is partitioned as:=E2=80=A6=E2=80=A6.. >>>> After that it tries to boot from ethernet (which was >>>> not connected). >>>=20 >>> Tomorrow I will look again exactly with which partition tables I = booted the SSD,=20 >>> for today I am completely dizzy from all that rpi-dtb stuff , I = can=E2=80=99t remember what I did :-) >>=20 >>=20 >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Oct 10 19:14:41 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 363424284BB for ; Sat, 10 Oct 2020 19:14:41 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C7vl40k60z4CjP; Sat, 10 Oct 2020 19:14:39 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x344.google.com with SMTP id z22so11170647wmi.0; Sat, 10 Oct 2020 12:14:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=VRmMITgAfsn3Sfpqe9eThKUPFyKMWGQaM8qUkruj/Gk=; b=UyaDaLrcCm3kTSMJc4vN63lf8mEjjOpUu2jA21GqA1Ecl+zqvGwL4o4x3V2KxLE+ky C8RmY0Mv20j1HF+tbh41aMM4ZkRjLOPR2pbj2hpOFnxvLtmcwv8Pafjjv2clipjItJAh pmssVhQMLXge73520ur46Yuaao0SOH+J/7sswyLuTVniveRAISz3c68eFuqR/RgKySUB Y3wWc0lfTvyXB72znc+7yl31kb4m4+VQqGWoWxIVBcN3WeedWoYKrNwPbs7kKSsEu0u7 LxxOnMV95AZqVNIb5Fv8ehWa5ge7fXMZyxSJIDfxG2EcOPByBn6FzSyrT/XsiBr7QpCy ztFg== X-Gm-Message-State: AOAM530VhJvM4EuC3GN/XLHeqK3xwzTs2PDbV8VPwv+c/pJ/b/k+pw+7 yEDME7+m1WzPDQQfv/c72knQxQ+U4oY= X-Google-Smtp-Source: ABdhPJww2syy1xXhtIub2OUgg10aXZiCTJKvi82X7f2UDAFDuRXLrY8IIDQhK5euITmh0L/6edYThw== X-Received: by 2002:a1c:8057:: with SMTP id b84mr3695289wmd.116.1602356945957; Sat, 10 Oct 2020 12:09:05 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-108-089.46.114.pool.telefonica.de. [46.114.108.89]) by smtp.googlemail.com with ESMTPSA id u17sm18781399wri.45.2020.10.10.12.09.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Oct 2020 12:09:05 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Date: Sat, 10 Oct 2020 21:09:03 +0200 References: <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <27E7A6A9-04A4-4B15-96CB-84AE478ED755@googlemail.com> <93E411FA-6024-4E2F-AAFF-C051AF4F35EE@yahoo.com> <7CB99D94-6F37-4150-9D1B-9488D4FE83EF@googlemail.com> <5B658E5E-C438-4A05-99F5-8E4B67A89488@yahoo.com> To: Mark Millard , Robert Crowston , Kyle Evans , freebsd-arm@freebsd.org In-Reply-To: Message-Id: <3ED953B1-1A3A-40A7-A7B9-5C67DCE30A0B@googlemail.com> X-Mailer: Apple Mail (2.3654.0.3.2.52) X-Rspamd-Queue-Id: 4C7vl40k60z4CjP X-Spamd-Bar: +++++++++++ X-Spamd-Result: default: False [11.35 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,body]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(0.00)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.06)[-0.061]; FREEMAIL_TO(0.00)[yahoo.com,protonmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[46.114.108.89:received]; R_DKIM_ALLOW(0.00)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_CSS(4.00)[46.114.108.89:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.95)[0.945]; BAD_REP_POLICIES(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.108.89:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.97)[0.966]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::344:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-Spam: Yes 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 19:14:41 -0000 > Am 10.10.2020 um 09:14 schrieb Mark Millard : >=20 >>=20 >>=20 >>> On 2020-Oct-9, at 18:08, Klaus Cucinauomo wrote: >>> . . . >>>=20 >>>> G U E S S(still can=E2=80=99t resist;-) >=20 >=20 > I've sent other E-mail about it, but my hypothesis is > that the armstub8-gic.bin requirement for: >=20 > device_tree_address=3D0x4000 >=20 > and where/how start4.elf and fixup4.dat are loading > before the device tree activity are conflicting=20 this time your hypothesis seems to be a GOLDEN GUESS it=E2=80=99s even = better, yeah lol, so let`s discuss it in your other email=E2=80=A6. hint: take a look into the msdos-patition of ubuntu and search for an = armstub8-gic.bin ;-)=20 K.