From owner-freebsd-arm@freebsd.org Sun Jul 19 02:18:43 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 560D137AE91 for ; Sun, 19 Jul 2020 02:18:43 +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 4B8T755Zsdz43Q9 for ; Sun, 19 Jul 2020 02:18:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: APplh04VM1l4K3r.GxcL2HXkEWPmCjxgJS92JHGffmos7Dw7O5TanLO7oOcgTRm gnzCHC_YPVLYWKISl9mMMD6mr3tCObAj3GBEgssn2.5TxM.ADDaFICY22sB5CT92ohFXUY54N2Xv QJa1Xw5WA6.CAONG58SLcOe.fkOFWhvLPK4v1RAJJ6nQsk1rSO4MmkjQxhCBwn1_UeosfGF.mpDg hPfcLMwxm97uLqQ7Zyyf2bilbM6kFxDWgzcb3e_7zlSB_KRymek6.82wjlRXHCOp0gRH3HpUJWcS QQJC2nrX26dBtE6A.twsKcNXt0ngUcNcLDzhMb2zqQ6.dN63IKuABgmv41e5.GgthMMyfVfiyxwg KyNAiDntMkrUP3S2wlSNCNwgW14GRS2chmt5Fcr7oOyk2zK_AO2WBOG_kPR8i5vO7rIZkfBRvAKk WBYmHrK79w18fZjXZd9bVtSflJnoiXrfhpkoJFEO4E0cltHTHYe2Xv1ozzJnKVhcWYdZ_pVHrVS2 zqincRG.U_fEO1OkNbJ9r0a.D4tTM_G9F_eWwx7rDGnif0s3zzLwLDAw1lbMrJRzV3BAHRs_ET4J .FJ9aMUQgk0sPAn2G5PsaKi2npBu_ymRPr7SAHdUZvwF1cODYYNc8BmR9MryrsD67gDPwRa919Ih 6hWONQtLVzVqCdFEv1DoZiqqVMMBbdk6IdDeBP0zSl6DGKpf2QafatsJO8Qvv4AXwO2IltWHogYp v90aZi_LiOz5DRb5QHz5vvjqpEzECWwpU2fbVvxRfqJrKQVoe3t2zyg3sHI4Roj4h4XKVLC5KeTi 70I3ltjJdZIJn6E3jl9rBAR53xvmi7naUU0Ln0duUq.QFbrxLhdi6ZXNg8ZSORM0j8rpvFcey07z MUCtaWa1e0nv_qNVScZFologFHLKxbdf2SvIboYTrJfMOYD97i8e9NldLBl_0LUrabgpWWhLkkp9 8Cd0U8b41mu18ZXhLG0.ipx3Nd4QASo2GGbCYzTPP9vc3jkoexXB9I1qhB2viKmzA.J.d.J.aPGR iKooi5OejtLrXy2sSa5FbNNgJ58ub4.dZ7l8Z9efhIssFDeqIIqjF_C7fTkn_hm71BGyyVpYgyu8 OIJjtI8mZ1f_SL7WpmjNIO7oZwWY_rZ.OaB.UMddf_T4XnEHtIpqPiUplh29vnHrskj632VRg6vX Wv69lOaViaxp9oFrYsJEKmQrEZgKSdWn1oaY4DaiLS2QB69RTghewjlNmrEOaZyCoJqFcHmmAUTs ZS36pfrsSnzwft16FofFWhOFpZBrHHtr4V2c61qnq6DLmAGiQLl2kv1RctewJc_mdZDDiTbDAw72 VQsHCI88pTx13NCGyjuINMs9p6Z7pgJjVv_DhX6Nv5Tu8RBVstSbHM.6pH7sxxElkJothgAdPsyI .tu11cfqLYwGM7rj3T_2p7eyntvwBJ5bd_BZVYDp5nZrI01BYhmSFP9_KJ8M- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Jul 2020 02:18:40 +0000 Received: by smtp428.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 28a90e4c2536469b905325cbc613bac4; Sun, 19 Jul 2020 02:18:38 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: FYI: RPi4 (8 GiByte) USB3 vs. head -r363123: still a no-go for booting a USB3 / in my experiments From: Mark Millard In-Reply-To: Date: Sat, 18 Jul 2020 19:18:37 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <64A12BF8-9E2D-441D-8765-52B6D3907A58@yahoo.com> References: To: Robert Crowston X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B8T755Zsdz43Q9 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.14 / 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.62)[-0.617]; FREEMAIL_TO(0.00)[protonmail.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/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.030]; 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.69.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; 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: Sun, 19 Jul 2020 02:18:43 -0000 > On 2020-Jul-18, at 14:37, Robert Crowston = wrote: >=20 > I believe this differential (https://reviews.freebsd.org/D25261) would = resolve it, but I haven't got around to addressing the comments there = yet. >=20 > -- RHC. Yep, a -r363123 kernel with that also it booted / from the USB3 SSD. (The kernel came from the mmcsd0.) Notes for this u-boot-rpi4 based context: Unlike for uefi v1.17, genet0 and mmcsd0 show up. There is a big asymmetry for sending vs. receiving over genet0 (192.168.1.126 here): # iperf3 -c 192.168.1.120 --get-server-output -B 192.168.1.126 Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.126 port 56649 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 22.7 MBytes 191 Mbits/sec 85 38.4 KBytes = =20 [ 5] 1.00-2.00 sec 23.4 MBytes 196 Mbits/sec 146 25.7 KBytes = =20 [ 5] 2.00-3.00 sec 23.2 MBytes 195 Mbits/sec 226 27.1 KBytes = =20 [ 5] 3.00-4.00 sec 23.3 MBytes 195 Mbits/sec 229 95.0 KBytes = =20 [ 5] 4.00-5.00 sec 23.6 MBytes 198 Mbits/sec 228 83.7 KBytes = =20 [ 5] 5.00-6.00 sec 23.7 MBytes 199 Mbits/sec 209 7.13 KBytes = =20 [ 5] 6.00-7.00 sec 23.7 MBytes 199 Mbits/sec 207 49.8 KBytes = =20 [ 5] 7.00-8.00 sec 23.6 MBytes 198 Mbits/sec 217 1.43 KBytes = =20 [ 5] 8.00-9.00 sec 23.6 MBytes 198 Mbits/sec 224 71.3 KBytes = =20 [ 5] 9.00-10.00 sec 23.5 MBytes 197 Mbits/sec 242 8.55 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 234 MBytes 197 Mbits/sec 2013 = sender [ 5] 0.00-10.27 sec 234 MBytes 191 Mbits/sec = receiver Server output: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.126, port 57882 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.126 port = 56649 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 16.4 MBytes 138 Mbits/sec =20 [ 5] 1.00-2.00 sec 23.4 MBytes 196 Mbits/sec =20 [ 5] 2.00-3.00 sec 23.2 MBytes 195 Mbits/sec =20 [ 5] 3.00-4.00 sec 23.1 MBytes 194 Mbits/sec =20 [ 5] 4.00-5.00 sec 23.6 MBytes 198 Mbits/sec =20 [ 5] 5.00-6.00 sec 23.7 MBytes 199 Mbits/sec =20 [ 5] 6.00-7.00 sec 23.7 MBytes 199 Mbits/sec =20 [ 5] 7.00-8.00 sec 23.6 MBytes 198 Mbits/sec =20 [ 5] 8.00-9.00 sec 23.6 MBytes 198 Mbits/sec =20 [ 5] 9.00-10.00 sec 23.5 MBytes 197 Mbits/sec =20 [ 5] 10.00-10.27 sec 6.30 MBytes 197 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.27 sec 234 MBytes 191 Mbits/sec = receiver iperf Done. Rock64orRPi4# iperf3 -R -c 192.168.1.120 --get-server-output -B = 192.168.1.126 Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.126 port 25404 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec =20 [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.26 sec 1.09 GBytes 910 Mbits/sec 923 = sender [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec = receiver Server output: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.126, port 41483 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.126 port = 25404 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 83.7 MBytes 702 Mbits/sec 62 1.61 MBytes = =20 [ 5] 1.00-2.00 sec 111 MBytes 932 Mbits/sec 92 1.61 MBytes = =20 [ 5] 2.00-3.00 sec 111 MBytes 934 Mbits/sec 93 175 KBytes = =20 [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 95 88.4 KBytes = =20 [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 94 268 KBytes = =20 [ 5] 5.00-6.00 sec 111 MBytes 932 Mbits/sec 89 291 KBytes = =20 [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 92 4.28 KBytes = =20 [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 92 1.27 MBytes = =20 [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 94 1.61 MBytes = =20 [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 96 1.42 MBytes = =20 [ 5] 10.00-10.26 sec 29.3 MBytes 931 Mbits/sec 24 1.61 MBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.26 sec 1.09 GBytes 910 Mbits/sec 923 = sender iperf Done. My attempt to duplicate an about 11 GiByte .tar file failed: # cp -aRx /usr/obj/clang-armv7-on-aarch64.tar /usr/obj/mmjnk.tar g_vfs_done():gpt/Rock64root[READ(offset=3D274911461376, = length=3D32768)]error =3D 5 c/usr/obj/clang-armv7-on-UFS /dev/gpt/Rock64root (/) cylinder checksum = failed: cg 270, cgp: 0x0 !=3D bp: 0xa023cccf aarch64.tar: Input/output error UFS /dev/gpt/Rock64root (/) cylinder checksum failed: cg 270, cgp: 0x0 = !=3D bp: 0xa023cccf pid 1123 (ntpd), jid 0, uid 0: exited on signal 6 (core dumped) pid 1240 (login), jid 0, uid 0: exited on signal 11 (core dumped) Same media as used for Rock64 experiments. I've had no evidence of problems there. However uefi based booting the RPi4 also has problems unless uefi is set to force 3 GiBytes of RAM (at most). The problem has usually been visible as the diff after the copy showing 4 KiByte or slightly less having differences according to diff or cmp or the like. There is evidence of the content and where changing without updates to the files, suggesting garbage read data. Again, same media for 3GiByte RAM or on the Rock64: no evidence of problems for such operations. My initial guess is that the handling of the RPi4 DMA limitations is not yet correct overall, apparently for both uefi and u-boot style booting. > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 = Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2= =80=90 > On Wednesday, 15 July 2020 10:09, Mark Millard via freebsd-arm = wrote: >=20 >> I did the following experiment mostly just to observe >> the current status for sysutils/u-boot-rpi4 based >> booting of the RPi4 (with rather modern RPi4 firmware >> in use). (I normally use uefi/acpi instead of u-boot, >> uefi now at v1.17 . I was hoping to see if u-boot based >> also had a bug that uefi contexts have.) >>=20 >> With the kernel on the microsd card (and earlier stage >> materials), boot -v reported (before mounting / from >> USB3 became relevant): >>=20 >> pci1: on pcib1 >> pcib1: allocated bus range (1-1) for rid 0 of pci1 >> pci1: domain=3D0, physical bus=3D1 >> found-> vendor=3D0x1106, dev=3D0x3483, revid=3D0x01 >>=20 >> domain=3D0, bus=3D1, slot=3D0, func=3D0 >> class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D0 >> cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) >> intpin=3Da, irq=3D0 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 4 messages, 64 bit >> map[10]: type Memory, range 64, base 0, size 12, memory = disabled >>=20 >>=20 >> pcib1: slot 0 INTA is routed to irq 82 >> xhci0: irq 82 at device 0.0 on = pci1 >> pcib1: allocated memory range (0xf8000000-0xf8000fff) for rid 10 of = xhci0 >> xhci0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xf8000000 >> xhci0: 32 bytes context size, 64-bit DMA >> xhci0: attempting to allocate 1 MSI vectors (4 supported) >> xhci0: using IRQ 83 for MSI >> xhci0: MSI enabled >> xhci0: Controller reset timeout. >> xhci0: XHCI halt/start/probe failed err=3D18 >> xhci0: Controller reset timeout. >> device_attach: xhci0 attach returned 6 >> . . . >> simplebus2: xhci@7e9c0000 mem 0x7e9c0000-0x7eabffff irq 78 disabled = compat generic-xhci (no driver attached) >>=20 >> So the USB3 ends up unavailable. >>=20 >> / would have been from a USB3 SSD if things had worked. >>=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 Sun Jul 19 11:30: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 B09B635BF9A for ; Sun, 19 Jul 2020 11:30:46 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B8jN54NJNz4RmC for ; Sun, 19 Jul 2020 11:30:45 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sun, 19 Jul 2020 11:30:38 +0000 To: Mark Millard From: Robert Crowston Cc: freebsd-arm Reply-To: Robert Crowston Subject: Re: FYI: RPi4 (8 GiByte) USB3 vs. head -r363123: still a no-go for booting a USB3 / in my experiments Message-ID: <7J4Opq5TWFEhuN7xv3tq206mMjbDK67p35GadBDuaJRKtDuObVfk7M8ItEEUgumC_jKkoMqC2ZJVUCpNifY579oBq1UDthM1wXjG3tBBTj0=@protonmail.com> In-Reply-To: <64A12BF8-9E2D-441D-8765-52B6D3907A58@yahoo.com> References: <64A12BF8-9E2D-441D-8765-52B6D3907A58@yahoo.com> MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 4B8jN54NJNz4RmC X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.76 / 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:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.84)[-0.841]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.134:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.949]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.971]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.134:from] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 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: Sun, 19 Jul 2020 11:30:46 -0000 VGhlIGV0aGVybmV0IHByb2JsZW0gY291bGQgYmUgY2F1c2VkIGJ5IHRoZSByZWNlbnQgY2hhbmdl IGluIHVwc3RyZWFtIGR0YiwgdG8gY2hhbmdlIHRoZSBldGhlcm5ldCBkcml2ZXIgdG8gb3BlcmF0 ZSBpbiByZ21paS1yeGlkIG1vZGUgaW5zdGVhZCBvZiByZ21paSBtb2RlLiBTZWUKaHR0cHM6Ly9y ZXZpZXdzLmZyZWVic2Qub3JnL0QyNTI1MS4gSSBoYXZlIG5vdCBub3RpY2VkIHRoaXMgcGVyZm9y bWFuY2UgcHJvYmxlbSB5b3UgcmVwb3J0IG15c2VsZiwgd2hlbiB1c2luZyB1cHN0cmVhbSBkdGJz IGZyb20gSnVuZSAyMDIwLgoKWW91IGFyZSByaWdodCB0aGF0IHdlIGFyZSBub3QgaGFuZGxpbmcg dGhlIDMgR0IgRE1BIGxpbWl0IGluIHRoZSBwY2llIGRyaXZlci4gVW5mb3J0dW5hdGVseSwgaXQg ZGlkIG5vdCBzZWVtIGVhc3kgdG8gdGhyZWFkIHRoZSBhcHByb3ByaWF0ZSBidXMgdGFnIHRocm91 Z2ggd2l0aG91dCByZXdyaXRpbmcgaGFsZiB0aGUgaW5oZXJpdGVkIGRyaXZlciBzdGFjaywgYW5k IGluIG15IHRlc3RpbmcgdGhlIFVTQiBkcml2ZXIgYWx3YXlzIGFsbG9jYXRlZCBpdHMgRE1BIGJ1 ZmZlcnMgaW4gdGhlIGxvd2VyIDMgR0Igd2l0aG91dCBiZWluZyB0b2xkLiBCdXQgb2J2aW91c2x5 IGl0IGlzIHRoZSB3cm9uZyB0byByZWx5IG9uIGx1Y2ssIHNvIEnigJlsbCBoYXZlIGEgdGhpbmsg YWJvdXQgaXQuCgrigJQgUkhDLgoKT24gU3VuLCBKdWwgMTksIDIwMjAgYXQgMDM6MTgsIE1hcmsg TWlsbGFyZCA8bWFya2xtaUB5YWhvby5jb20+IHdyb3RlOgoKPj4gT24gMjAyMC1KdWwtMTgsIGF0 IDE0OjM3LCBSb2JlcnQgQ3Jvd3N0b24gPGNyb3dzdG9uIGF0IHByb3Rvbm1haWwuY29tPiB3cm90 ZToKPj4KPj4gSSBiZWxpZXZlIHRoaXMgZGlmZmVyZW50aWFsIChodHRwczovL3Jldmlld3MuZnJl ZWJzZC5vcmcvRDI1MjYxKSB3b3VsZCByZXNvbHZlIGl0LCBidXQgSSBoYXZlbid0IGdvdCBhcm91 bmQgdG8gYWRkcmVzc2luZyB0aGUgY29tbWVudHMgdGhlcmUgeWV0Lgo+Pgo+PiAtLSBSSEMuCj4K PiBZZXAsIGEgLXIzNjMxMjMga2VybmVsIHdpdGggdGhhdCBhbHNvIGl0IGJvb3RlZCAvIGZyb20K PiB0aGUgVVNCMyBTU0QuIChUaGUga2VybmVsIGNhbWUgZnJvbSB0aGUgbW1jc2QwLikKPgo+IE5v dGVzIGZvciB0aGlzIHUtYm9vdC1ycGk0IGJhc2VkIGNvbnRleHQ6Cj4KPiBVbmxpa2UgZm9yIHVl ZmkgdjEuMTcsIGdlbmV0MCBhbmQgbW1jc2QwIHNob3cgdXAuCj4KPiBUaGVyZSBpcyBhIGJpZyBh c3ltbWV0cnkgZm9yIHNlbmRpbmcgdnMuIHJlY2VpdmluZwo+IG92ZXIgZ2VuZXQwICgxOTIuMTY4 LjEuMTI2IGhlcmUpOgo+Cj4gIyBpcGVyZjMgLWMgMTkyLjE2OC4xLjEyMCAtLWdldC1zZXJ2ZXIt b3V0cHV0IC1CIDE5Mi4xNjguMS4xMjYKPiBDb25uZWN0aW5nIHRvIGhvc3QgMTkyLjE2OC4xLjEy MCwgcG9ydCA1MjAxCj4gWyA1XSBsb2NhbCAxOTIuMTY4LjEuMTI2IHBvcnQgNTY2NDkgY29ubmVj dGVkIHRvIDE5Mi4xNjguMS4xMjAgcG9ydCA1MjAxCj4gWyBJRF0gSW50ZXJ2YWwgVHJhbnNmZXIg Qml0cmF0ZSBSZXRyIEN3bmQKPiBbIDVdIDAuMDAtMS4wMCBzZWMgMjIuNyBNQnl0ZXMgMTkxIE1i aXRzL3NlYyA4NSAzOC40IEtCeXRlcwo+IFsgNV0gMS4wMC0yLjAwIHNlYyAyMy40IE1CeXRlcyAx OTYgTWJpdHMvc2VjIDE0NiAyNS43IEtCeXRlcwo+IFsgNV0gMi4wMC0zLjAwIHNlYyAyMy4yIE1C eXRlcyAxOTUgTWJpdHMvc2VjIDIyNiAyNy4xIEtCeXRlcwo+IFsgNV0gMy4wMC00LjAwIHNlYyAy My4zIE1CeXRlcyAxOTUgTWJpdHMvc2VjIDIyOSA5NS4wIEtCeXRlcwo+IFsgNV0gNC4wMC01LjAw IHNlYyAyMy42IE1CeXRlcyAxOTggTWJpdHMvc2VjIDIyOCA4My43IEtCeXRlcwo+IFsgNV0gNS4w MC02LjAwIHNlYyAyMy43IE1CeXRlcyAxOTkgTWJpdHMvc2VjIDIwOSA3LjEzIEtCeXRlcwo+IFsg NV0gNi4wMC03LjAwIHNlYyAyMy43IE1CeXRlcyAxOTkgTWJpdHMvc2VjIDIwNyA0OS44IEtCeXRl cwo+IFsgNV0gNy4wMC04LjAwIHNlYyAyMy42IE1CeXRlcyAxOTggTWJpdHMvc2VjIDIxNyAxLjQz IEtCeXRlcwo+IFsgNV0gOC4wMC05LjAwIHNlYyAyMy42IE1CeXRlcyAxOTggTWJpdHMvc2VjIDIy NCA3MS4zIEtCeXRlcwo+IFsgNV0gOS4wMC0xMC4wMCBzZWMgMjMuNSBNQnl0ZXMgMTk3IE1iaXRz L3NlYyAyNDIgOC41NSBLQnl0ZXMKPiAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtCj4gWyBJRF0gSW50ZXJ2YWwgVHJhbnNmZXIgQml0cmF0ZSBSZXRyCj4g WyA1XSAwLjAwLTEwLjAwIHNlYyAyMzQgTUJ5dGVzIDE5NyBNYml0cy9zZWMgMjAxMyBzZW5kZXIK PiBbIDVdIDAuMDAtMTAuMjcgc2VjIDIzNCBNQnl0ZXMgMTkxIE1iaXRzL3NlYyByZWNlaXZlcgo+ Cj4gU2VydmVyIG91dHB1dDoKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFNlcnZlciBsaXN0ZW5pbmcgb24gNTIwMQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4g QWNjZXB0ZWQgY29ubmVjdGlvbiBmcm9tIDE5Mi4xNjguMS4xMjYsIHBvcnQgNTc4ODIKPiBbIDVd IGxvY2FsIDE5Mi4xNjguMS4xMjAgcG9ydCA1MjAxIGNvbm5lY3RlZCB0byAxOTIuMTY4LjEuMTI2 IHBvcnQgNTY2NDkKPiBbIElEXSBJbnRlcnZhbCBUcmFuc2ZlciBCaXRyYXRlCj4gWyA1XSAwLjAw LTEuMDAgc2VjIDE2LjQgTUJ5dGVzIDEzOCBNYml0cy9zZWMKPiBbIDVdIDEuMDAtMi4wMCBzZWMg MjMuNCBNQnl0ZXMgMTk2IE1iaXRzL3NlYwo+IFsgNV0gMi4wMC0zLjAwIHNlYyAyMy4yIE1CeXRl cyAxOTUgTWJpdHMvc2VjCj4gWyA1XSAzLjAwLTQuMDAgc2VjIDIzLjEgTUJ5dGVzIDE5NCBNYml0 cy9zZWMKPiBbIDVdIDQuMDAtNS4wMCBzZWMgMjMuNiBNQnl0ZXMgMTk4IE1iaXRzL3NlYwo+IFsg NV0gNS4wMC02LjAwIHNlYyAyMy43IE1CeXRlcyAxOTkgTWJpdHMvc2VjCj4gWyA1XSA2LjAwLTcu MDAgc2VjIDIzLjcgTUJ5dGVzIDE5OSBNYml0cy9zZWMKPiBbIDVdIDcuMDAtOC4wMCBzZWMgMjMu NiBNQnl0ZXMgMTk4IE1iaXRzL3NlYwo+IFsgNV0gOC4wMC05LjAwIHNlYyAyMy42IE1CeXRlcyAx OTggTWJpdHMvc2VjCj4gWyA1XSA5LjAwLTEwLjAwIHNlYyAyMy41IE1CeXRlcyAxOTcgTWJpdHMv c2VjCj4gWyA1XSAxMC4wMC0xMC4yNyBzZWMgNi4zMCBNQnl0ZXMgMTk3IE1iaXRzL3NlYwo+IC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0KPiBbIElEXSBJ bnRlcnZhbCBUcmFuc2ZlciBCaXRyYXRlCj4gWyA1XSAwLjAwLTEwLjI3IHNlYyAyMzQgTUJ5dGVz IDE5MSBNYml0cy9zZWMgcmVjZWl2ZXIKPgo+IGlwZXJmIERvbmUuCj4gUm9jazY0b3JSUGk0IyBp cGVyZjMgLVIgLWMgMTkyLjE2OC4xLjEyMCAtLWdldC1zZXJ2ZXItb3V0cHV0IC1CIDE5Mi4xNjgu MS4xMjYKPiBDb25uZWN0aW5nIHRvIGhvc3QgMTkyLjE2OC4xLjEyMCwgcG9ydCA1MjAxCj4gUmV2 ZXJzZSBtb2RlLCByZW1vdGUgaG9zdCAxOTIuMTY4LjEuMTIwIGlzIHNlbmRpbmcKPiBbIDVdIGxv Y2FsIDE5Mi4xNjguMS4xMjYgcG9ydCAyNTQwNCBjb25uZWN0ZWQgdG8gMTkyLjE2OC4xLjEyMCBw b3J0IDUyMDEKPiBbIElEXSBJbnRlcnZhbCBUcmFuc2ZlciBCaXRyYXRlCj4gWyA1XSAwLjAwLTEu MDAgc2VjIDExMSBNQnl0ZXMgOTMzIE1iaXRzL3NlYwo+IFsgNV0gMS4wMC0yLjAwIHNlYyAxMTEg TUJ5dGVzIDkzMyBNYml0cy9zZWMKPiBbIDVdIDIuMDAtMy4wMCBzZWMgMTExIE1CeXRlcyA5MzMg TWJpdHMvc2VjCj4gWyA1XSAzLjAwLTQuMDAgc2VjIDExMSBNQnl0ZXMgOTMzIE1iaXRzL3NlYwo+ IFsgNV0gNC4wMC01LjAwIHNlYyAxMTEgTUJ5dGVzIDkzMyBNYml0cy9zZWMKPiBbIDVdIDUuMDAt Ni4wMCBzZWMgMTExIE1CeXRlcyA5MzMgTWJpdHMvc2VjCj4gWyA1XSA2LjAwLTcuMDAgc2VjIDEx MSBNQnl0ZXMgOTMzIE1iaXRzL3NlYwo+IFsgNV0gNy4wMC04LjAwIHNlYyAxMTEgTUJ5dGVzIDkz MyBNYml0cy9zZWMKPiBbIDVdIDguMDAtOS4wMCBzZWMgMTExIE1CeXRlcyA5MzMgTWJpdHMvc2Vj Cj4gWyA1XSA5LjAwLTEwLjAwIHNlYyAxMTEgTUJ5dGVzIDkzMyBNYml0cy9zZWMKPiAtIC0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtCj4gWyBJRF0gSW50ZXJ2 YWwgVHJhbnNmZXIgQml0cmF0ZSBSZXRyCj4gWyA1XSAwLjAwLTEwLjI2IHNlYyAxLjA5IEdCeXRl cyA5MTAgTWJpdHMvc2VjIDkyMyBzZW5kZXIKPiBbIDVdIDAuMDAtMTAuMDAgc2VjIDEuMDkgR0J5 dGVzIDkzMyBNYml0cy9zZWMgcmVjZWl2ZXIKPgo+IFNlcnZlciBvdXRwdXQ6Cj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBTZXJ2 ZXIgbGlzdGVuaW5nIG9uIDUyMDEKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IEFjY2VwdGVkIGNvbm5lY3Rpb24gZnJvbSAxOTIu MTY4LjEuMTI2LCBwb3J0IDQxNDgzCj4gWyA1XSBsb2NhbCAxOTIuMTY4LjEuMTIwIHBvcnQgNTIw MSBjb25uZWN0ZWQgdG8gMTkyLjE2OC4xLjEyNiBwb3J0IDI1NDA0Cj4gWyBJRF0gSW50ZXJ2YWwg VHJhbnNmZXIgQml0cmF0ZSBSZXRyIEN3bmQKPiBbIDVdIDAuMDAtMS4wMCBzZWMgODMuNyBNQnl0 ZXMgNzAyIE1iaXRzL3NlYyA2MiAxLjYxIE1CeXRlcwo+IFsgNV0gMS4wMC0yLjAwIHNlYyAxMTEg TUJ5dGVzIDkzMiBNYml0cy9zZWMgOTIgMS42MSBNQnl0ZXMKPiBbIDVdIDIuMDAtMy4wMCBzZWMg MTExIE1CeXRlcyA5MzQgTWJpdHMvc2VjIDkzIDE3NSBLQnl0ZXMKPiBbIDVdIDMuMDAtNC4wMCBz ZWMgMTExIE1CeXRlcyA5MzMgTWJpdHMvc2VjIDk1IDg4LjQgS0J5dGVzCj4gWyA1XSA0LjAwLTUu MDAgc2VjIDExMSBNQnl0ZXMgOTMzIE1iaXRzL3NlYyA5NCAyNjggS0J5dGVzCj4gWyA1XSA1LjAw LTYuMDAgc2VjIDExMSBNQnl0ZXMgOTMyIE1iaXRzL3NlYyA4OSAyOTEgS0J5dGVzCj4gWyA1XSA2 LjAwLTcuMDAgc2VjIDExMSBNQnl0ZXMgOTMzIE1iaXRzL3NlYyA5MiA0LjI4IEtCeXRlcwo+IFsg NV0gNy4wMC04LjAwIHNlYyAxMTEgTUJ5dGVzIDkzMyBNYml0cy9zZWMgOTIgMS4yNyBNQnl0ZXMK PiBbIDVdIDguMDAtOS4wMCBzZWMgMTExIE1CeXRlcyA5MzMgTWJpdHMvc2VjIDk0IDEuNjEgTUJ5 dGVzCj4gWyA1XSA5LjAwLTEwLjAwIHNlYyAxMTEgTUJ5dGVzIDkzMyBNYml0cy9zZWMgOTYgMS40 MiBNQnl0ZXMKPiBbIDVdIDEwLjAwLTEwLjI2IHNlYyAyOS4zIE1CeXRlcyA5MzEgTWJpdHMvc2Vj IDI0IDEuNjEgTUJ5dGVzCj4gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAt IC0gLSAtIC0gLQo+IFsgSURdIEludGVydmFsIFRyYW5zZmVyIEJpdHJhdGUgUmV0cgo+IFsgNV0g MC4wMC0xMC4yNiBzZWMgMS4wOSBHQnl0ZXMgOTEwIE1iaXRzL3NlYyA5MjMgc2VuZGVyCj4KPiBp cGVyZiBEb25lLgo+Cj4gTXkgYXR0ZW1wdCB0byBkdXBsaWNhdGUgYW4gYWJvdXQgMTEgR2lCeXRl IC50YXIgZmlsZSBmYWlsZWQ6Cj4KPiAjIGNwIC1hUnggL3Vzci9vYmovY2xhbmctYXJtdjctb24t YWFyY2g2NC50YXIgL3Vzci9vYmovbW1qbmsudGFyCj4gZ192ZnNfZG9uZSgpOmdwdC9Sb2NrNjRy b290W1JFQUQob2Zmc2V0PTI3NDkxMTQ2MTM3NiwgbGVuZ3RoPTMyNzY4KV1lcnJvciA9IDUKPiBj L3Vzci9vYmovY2xhbmctYXJtdjctb24tVUZTIC9kZXYvZ3B0L1JvY2s2NHJvb3QgKC8pIGN5bGlu ZGVyIGNoZWNrc3VtIGZhaWxlZDogY2cgMjcwLCBjZ3A6IDB4MCAhPSBicDogMHhhMDIzY2NjZgo+ IGFhcmNoNjQudGFyOiBJbnB1dC9vdXRwdXQgZXJyb3IKPiBVRlMgL2Rldi9ncHQvUm9jazY0cm9v dCAoLykgY3lsaW5kZXIgY2hlY2tzdW0gZmFpbGVkOiBjZyAyNzAsIGNncDogMHgwICE9IGJwOiAw eGEwMjNjY2NmCj4gcGlkIDExMjMgKG50cGQpLCBqaWQgMCwgdWlkIDA6IGV4aXRlZCBvbiBzaWdu YWwgNiAoY29yZSBkdW1wZWQpCj4gcGlkIDEyNDAgKGxvZ2luKSwgamlkIDAsIHVpZCAwOiBleGl0 ZWQgb24gc2lnbmFsIDExIChjb3JlIGR1bXBlZCkKPgo+IFNhbWUgbWVkaWEgYXMgdXNlZCBmb3Ig Um9jazY0IGV4cGVyaW1lbnRzLiBJJ3ZlIGhhZCBubwo+IGV2aWRlbmNlIG9mIHByb2JsZW1zIHRo ZXJlLgo+Cj4gSG93ZXZlciB1ZWZpIGJhc2VkIGJvb3RpbmcgdGhlIFJQaTQgYWxzbyBoYXMgcHJv YmxlbXMKPiB1bmxlc3MgdWVmaSBpcyBzZXQgdG8gZm9yY2UgMyBHaUJ5dGVzIG9mIFJBTSAoYXQg bW9zdCkuCj4gVGhlIHByb2JsZW0gaGFzIHVzdWFsbHkgYmVlbiB2aXNpYmxlIGFzIHRoZSBkaWZm Cj4gYWZ0ZXIgdGhlIGNvcHkgc2hvd2luZyA0IEtpQnl0ZSBvciBzbGlnaHRseSBsZXNzCj4gaGF2 aW5nIGRpZmZlcmVuY2VzIGFjY29yZGluZyB0byBkaWZmIG9yIGNtcCBvciB0aGUKPiBsaWtlLiBU aGVyZSBpcyBldmlkZW5jZSBvZiB0aGUgY29udGVudCBhbmQgd2hlcmUKPiBjaGFuZ2luZyB3aXRo b3V0IHVwZGF0ZXMgdG8gdGhlIGZpbGVzLCBzdWdnZXN0aW5nCj4gZ2FyYmFnZSByZWFkIGRhdGEu Cj4KPiBBZ2Fpbiwgc2FtZSBtZWRpYSBmb3IgM0dpQnl0ZSBSQU0gb3Igb24gdGhlIFJvY2s2NDoK PiBubyBldmlkZW5jZSBvZiBwcm9ibGVtcyBmb3Igc3VjaCBvcGVyYXRpb25zLgo+Cj4gTXkgaW5p dGlhbCBndWVzcyBpcyB0aGF0IHRoZSBoYW5kbGluZyBvZiB0aGUgUlBpNAo+IERNQSBsaW1pdGF0 aW9ucyBpcyBub3QgeWV0IGNvcnJlY3Qgb3ZlcmFsbCwKPiBhcHBhcmVudGx5IGZvciBib3RoIHVl ZmkgYW5kIHUtYm9vdCBzdHlsZSBib290aW5nLgo+Cj4+IOKAkOKAkOKAkOKAkOKAkOKAkOKAkCBP cmlnaW5hbCBNZXNzYWdlIOKAkOKAkOKAkOKAkOKAkOKAkOKAkAo+PiBPbiBXZWRuZXNkYXksIDE1 IEp1bHkgMjAyMCAxMDowOSwgTWFyayBNaWxsYXJkIHZpYSBmcmVlYnNkLWFybSA8ZnJlZWJzZC1h cm1AZnJlZWJzZC5vcmc+IHdyb3RlOgo+Pgo+Pj4gSSBkaWQgdGhlIGZvbGxvd2luZyBleHBlcmlt ZW50IG1vc3RseSBqdXN0IHRvIG9ic2VydmUKPj4+IHRoZSBjdXJyZW50IHN0YXR1cyBmb3Igc3lz dXRpbHMvdS1ib290LXJwaTQgYmFzZWQKPj4+IGJvb3Rpbmcgb2YgdGhlIFJQaTQgKHdpdGggcmF0 aGVyIG1vZGVybiBSUGk0IGZpcm13YXJlCj4+PiBpbiB1c2UpLiAoSSBub3JtYWxseSB1c2UgdWVm aS9hY3BpIGluc3RlYWQgb2YgdS1ib290LAo+Pj4gdWVmaSBub3cgYXQgdjEuMTcgLiBJIHdhcyBo b3BpbmcgdG8gc2VlIGlmIHUtYm9vdCBiYXNlZAo+Pj4gYWxzbyBoYWQgYSBidWcgdGhhdCB1ZWZp IGNvbnRleHRzIGhhdmUuKQo+Pj4KPj4+IFdpdGggdGhlIGtlcm5lbCBvbiB0aGUgbWljcm9zZCBj YXJkIChhbmQgZWFybGllciBzdGFnZQo+Pj4gbWF0ZXJpYWxzKSwgYm9vdCAtdiByZXBvcnRlZCAo YmVmb3JlIG1vdW50aW5nIC8gZnJvbQo+Pj4gVVNCMyBiZWNhbWUgcmVsZXZhbnQpOgo+Pj4KPj4+ IHBjaTE6IDxQQ0kgYnVzPiBvbiBwY2liMQo+Pj4gcGNpYjE6IGFsbG9jYXRlZCBidXMgcmFuZ2Ug KDEtMSkgZm9yIHJpZCAwIG9mIHBjaTEKPj4+IHBjaTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9 MQo+Pj4gZm91bmQtPiB2ZW5kb3I9MHgxMTA2LCBkZXY9MHgzNDgzLCByZXZpZD0weDAxCj4+Pgo+ Pj4gZG9tYWluPTAsIGJ1cz0xLCBzbG90PTAsIGZ1bmM9MAo+Pj4gY2xhc3M9MGMtMDMtMzAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAo+Pj4gY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNh Y2hlbG5zej0wIChkd29yZHMpCj4+PiBsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKPj4+IGludHBpbj1hLCBpcnE9MAo+Pj4gcG93ZXJz cGVjIDMgc3VwcG9ydHMgRDAgRDMgY3VycmVudCBEMAo+Pj4gTVNJIHN1cHBvcnRzIDQgbWVzc2Fn ZXMsIDY0IGJpdAo+Pj4gbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDAsIHNp emUgMTIsIG1lbW9yeSBkaXNhYmxlZAo+Pj4KPj4+Cj4+PiBwY2liMTogc2xvdCAwIElOVEEgaXMg cm91dGVkIHRvIGlycSA4Mgo+Pj4geGhjaTA6IDxYSENJIChnZW5lcmljKSBVU0IgMy4wIGNvbnRy b2xsZXI+IGlycSA4MiBhdCBkZXZpY2UgMC4wIG9uIHBjaTEKPj4+IHBjaWIxOiBhbGxvY2F0ZWQg bWVtb3J5IHJhbmdlICgweGY4MDAwMDAwLTB4ZjgwMDBmZmYpIGZvciByaWQgMTAgb2YgeGhjaTAK Pj4+IHhoY2kwOiBMYXp5IGFsbG9jYXRpb24gb2YgMHgxMDAwIGJ5dGVzIHJpZCAweDEwIHR5cGUg MyBhdCAweGY4MDAwMDAwCj4+PiB4aGNpMDogMzIgYnl0ZXMgY29udGV4dCBzaXplLCA2NC1iaXQg RE1BCj4+PiB4aGNpMDogYXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICg0IHN1 cHBvcnRlZCkKPj4+IHhoY2kwOiB1c2luZyBJUlEgODMgZm9yIE1TSQo+Pj4geGhjaTA6IE1TSSBl bmFibGVkCj4+PiB4aGNpMDogQ29udHJvbGxlciByZXNldCB0aW1lb3V0Lgo+Pj4geGhjaTA6IFhI Q0kgaGFsdC9zdGFydC9wcm9iZSBmYWlsZWQgZXJyPTE4Cj4+PiB4aGNpMDogQ29udHJvbGxlciBy ZXNldCB0aW1lb3V0Lgo+Pj4gZGV2aWNlX2F0dGFjaDogeGhjaTAgYXR0YWNoIHJldHVybmVkIDYK Pj4+IC4gLiAuCj4+PiBzaW1wbGVidXMyOiB4aGNpQDdlOWMwMDAwIG1lbSAweDdlOWMwMDAwLTB4 N2VhYmZmZmYgaXJxIDc4IGRpc2FibGVkIGNvbXBhdCBnZW5lcmljLXhoY2kgKG5vIGRyaXZlciBh dHRhY2hlZCkKPj4+Cj4+PiBTbyB0aGUgVVNCMyBlbmRzIHVwIHVuYXZhaWxhYmxlLgo+Pj4KPj4+ IC8gd291bGQgaGF2ZSBiZWVuIGZyb20gYSBVU0IzIFNTRCBpZiB0aGluZ3MgaGFkIHdvcmtlZC4K Pj4+Cj4KPiA9PT0KPiBNYXJrIE1pbGxhcmQKPiBtYXJrbG1pIGF0IHlhaG9vLmNvbQo+ICggZHNs LW9ubHkubmV0IHdlbnQKPiBhd2F5IGluIGVhcmx5IDIwMTgtTWFyKQ== From owner-freebsd-arm@freebsd.org Sun Jul 19 18:57: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 E895A36614E for ; Sun, 19 Jul 2020 18:57:47 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B8vHv3L6sz3ddl for ; Sun, 19 Jul 2020 18:57:47 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1595185061; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=u4sTXYvjI8EmsqECwZGwv6Jo1KvVX1FttrHPM7IJSnfJ+dwjUihFfC9OtnrNB7x7IZno+qXH0zeoq dj6FnOjZrWOHtfbN3an7qVvdPRa963IPV5NVBj0FSevaxGYkq46zEMIjOoH53M4mTQkerYJW3zr1M3 ZOVl1PT1tXlfl4fHFMP1VyB+rFmrJWDC0BWdbezfj2YTjtp7Ax65hj+2EzHiVT+lCDG/4G1IvbiQ38 SqrITpJjMWpTTvpo7flrn0TkicFMhhnUdQig1qxFpDU0+HDZ2tHhoLxuq5RTT7WiSwMiw4RI5DMLoz 1dsqK23A1g4og/nq9ZcZ5B7g5di1OKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=79R6++d3ZZX6H48mqew5CFe6UcLbdBz/nHDho4UGORk=; b=uSeK0Jq4dM02p1HNY8JNRGRFVTi2kXu0TFnvEH+As0aJo2PC8vh6/hmgA2iOrsiWr5klSNcoiADVl FsPVqefTgiQqt7PwuYZ5o/Mnbw1wUZGW5NHEWvMtWBGidMKay58of7S3dWM1dv5jHwHKdGvQuqu72p lefeGOJ+1KSqVizfBs7rFfnhhnwpUa36i9lQBJGnqq9xayn5ugk//vv7j+BfYxllTEHVXmdN1/4cl6 qNn8N7tcbzRWB/C1js9p/p7mGPujA88RvmROHZa9VqWybKp9RIzvZZTjj/WK0ytz8SIkru1PLyRSv8 pEP9Iyp2BNhbNgjU6IAy94p7CVWCStQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=79R6++d3ZZX6H48mqew5CFe6UcLbdBz/nHDho4UGORk=; b=c7s11aJr9KCt8v5YmunDTM2DEebB6ghq7bGwWxd4R+xm2S1DUTQo07QB4Fy0TO2QaleitKp893V7O +KZeOccw6CfM4P8NzGI+kkk9kuthDhfnSiU7q/zV+MgjWKAGTyxInxU34KtAYn4GM5yXkYe2OtSUZA bQN1YO9rxLYqZspFz4nDasvhcD2g03IXqz3RVMFNT5QPG1FnhV4z9d/v6kGwaoDTLUBaiglplTz9qf jgkRE9zsSWqR45b/L5U1rwchx0AlLz9UoBbgGzlNmZmVwcVYbzpH3Vwc5Qm2CGy2zFu+FyrNYMDoKN wfr/iU7PKW83xjEBoa4Ib1KYOCH49/A== X-MHO-RoutePath: aGlwcGll X-MHO-User: b6c5b590-c9f1-11ea-a2ba-9f0c275c2f69 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id b6c5b590-c9f1-11ea-a2ba-9f0c275c2f69; Sun, 19 Jul 2020 18:57:39 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 06JIvbhD067374; Sun, 19 Jul 2020 12:57:37 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <4ede9edaf4638ba5d8e8bcb75662bf9c096e5e39.camel@freebsd.org> Subject: Re: DS3231 on BeagleBone Black with FreeBSD 13-CURRENT exactly 20 h off backwards From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org Date: Sun, 19 Jul 2020 12:57:37 -0600 In-Reply-To: References: <3BE2A8B4-AD53-4DFE-8C38-D5BB4063CFE9@obsigna.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B8vHv3L6sz3ddl X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, 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: Sun, 19 Jul 2020 18:57:48 -0000 On Wed, 2020-07-15 at 12:15 -0300, Dr. Rolf Jansen wrote: > > BTW: the following looks strange: > > > > https://github.com/freebsd/freebsd/blob/b2d136be8c26e5efaf82b7bb25432207a682e250/sys/dev/iicbus/ds3231.c#L526 > > 6 > 25432207a682e250/sys/dev/iicbus/ds3231.c#L526> > > > > This would add 256 instead of 100 when rolling over the century, > > really? On real world systems this will let to a Year-2100 problem, > > better we solve this quickly, since the time is running, and 80 > > years compares to nothing on the geologic time scale :-D I overlooked this part of your message previously. Actually, the value 0x100 is correct because the numbers here are expressed in bcd. So 99 years is 0x099 and 100 years is 0x100. In practice, all this century rollover stuff is moot, because the next century rollover is 2099->2100 and the datasheet says they only handle leap years correctly through 2099. > DS3231_HOUR_MASK_24HR is definitely wrong, since this prevents the > setting of times above 20 h. Reading said data sheet, I am almost > sure, that DS3231_HOUR_MASK_24HR must be the same as > DS3231_HOUR_MASK_12HR = 0x3f. Actually, it looks like the entire problem is that I simply swapped the values for DS3231_HOUR_MASK_12HR and DS3231_HOUR_MASK_24HR when I added those constants. Fixed in r363330. -- Ian From owner-freebsd-arm@freebsd.org Sun Jul 19 21:12: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 B369D369C31 for ; Sun, 19 Jul 2020 21:12:58 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.25]) (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.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B8yHs0D5wz43jc; Sun, 19 Jul 2020 21:12:56 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1595193174; s=strato-dkim-0002; d=obsigna.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=EC+HnTWSVf5olAFVlf54zsVv7alBjh1k6UQPEB7Pxp4=; b=DsQXIpd4zMhKSqJaKuCV0d+587+KrmfQ4kQpg6M+5kkugLAY+f4xHHM5Aw3T4tH01R 3p0tOIGxGKBy9C6YLA+xDEdlVeoyoqnGsQY67MW4OacKTgVISan53yS4nPAU4w6rJbqu FfvUYsLxoeMmhdo+Wz1SS60NnCu7vh9IEg5ks+lmNGfvaAGTWsYaWmeYCXS5Sa28VISS 4OzZTlsFWREInDyjKyBrWt0F+U+fVDTZ01Lx0JLBYTC0qSE6qzJqQjuZEFmpRug+fiQx upc2mgrgYuKGy/vmLSRbyMwunKqsTLJEgByVCks+YCz4vtNzclKvS4GlN8j9gDGKoSfC WVBA== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio0dVbInGjc9PbZFAm0A==" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 46.10.5 DYNA|AUTH) with ESMTPSA id 006e94w6JLCsh59 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 19 Jul 2020 23:12:54 +0200 (CEST) Received: from rolf-mini.obsigna.com (rolf-mini.obsigna.com [192.168.222.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 930FD1350F91D; Sun, 19 Jul 2020 18:12:49 -0300 (-03) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: DS3231 on BeagleBone Black with FreeBSD 13-CURRENT exactly 20 h off backwards From: "Dr. Rolf Jansen" In-Reply-To: <4ede9edaf4638ba5d8e8bcb75662bf9c096e5e39.camel@freebsd.org> Date: Sun, 19 Jul 2020 18:12:48 -0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3BE2A8B4-AD53-4DFE-8C38-D5BB4063CFE9@obsigna.com> <4ede9edaf4638ba5d8e8bcb75662bf9c096e5e39.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3445.104.14) X-Rspamd-Queue-Id: 4B8yHs0D5wz43jc X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=obsigna.com header.s=strato-dkim-0002 header.b=DsQXIpd4; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@obsigna.com designates 85.215.255.25 as permitted sender) smtp.mailfrom=freebsd-rj@obsigna.com X-Spamd-Result: default: False [-0.91 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[obsigna.com:s=strato-dkim-0002]; NEURAL_HAM_MEDIUM(-1.03)[-1.035]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24]; DMARC_NA(0.00)[obsigna.com]; NEURAL_SPAM_SHORT(0.11)[0.107]; NEURAL_HAM_LONG(-0.98)[-0.983]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[obsigna.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[85.215.255.25:from]; FROM_NAME_HAS_TITLE(1.00)[dr]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[85.215.255.25:from]; ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(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: Sun, 19 Jul 2020 21:12:58 -0000 > Am 19.07.2020 um 15:57 schrieb Ian Lepore : >=20 > On Wed, 2020-07-15 at 12:15 -0300, Dr. Rolf Jansen wrote: >>> BTW: the following looks strange: >>>=20 >>>=20 > = https://github.com/freebsd/freebsd/blob/b2d136be8c26e5efaf82b7bb25432207a6= 82e250/sys/dev/iicbus/ds3231.c#L526 >>> 6 >> 25432207a682e250/sys/dev/iicbus/ds3231.c#L526> >>>=20 >>> This would add 256 instead of 100 when rolling over the century, >>> really? On real world systems this will let to a Year-2100 problem, >>> better we solve this quickly, since the time is running, and 80 >>> years compares to nothing on the geologic time scale :-D >=20 > I overlooked this part of your message previously. Actually, the = value > 0x100 is correct because the numbers here are expressed in bcd. So 99 > years is 0x099 and 100 years is 0x100. In practice, all this century > rollover stuff is moot, because the next century rollover is = 2099->2100=20 > and the datasheet says they only handle leap years correctly through > 2099. >=20 >> DS3231_HOUR_MASK_24HR is definitely wrong, since this prevents the >> setting of times above 20 h. Reading said data sheet, I am almost >> sure, that DS3231_HOUR_MASK_24HR must be the same as >> DS3231_HOUR_MASK_12HR =3D 0x3f. >=20 > Actually, it looks like the entire problem is that I simply swapped = the > values for DS3231_HOUR_MASK_12HR and DS3231_HOUR_MASK_24HR when I = added > those constants. Fixed in r363330. It does work now. Thank you very much for fixing it that quickly. I didn't recognize that the century rollover was done in BCD. You are = correct of course. Sorry for the false alarm. Stay healthy! Best regards Rolf=20 From owner-freebsd-arm@freebsd.org Sun Jul 19 21:51: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 8CB9436A8B9 for ; Sun, 19 Jul 2020 21:51:58 +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 4B8z8s3YdJz44wb for ; Sun, 19 Jul 2020 21:51:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: b_ePC5EVM1nFV0az0qBAk.aa0ml7yS07YeoV9sOm7A8PskWX5H4PQO_OYAv7YZ5 p2JIPgBAydPwRYpFvNyZvf9txMBb9YEsxxFd.J6uNFtFcK2iuVHgqbnIToDdmuM1IW7lMOPUKjNe EH1Kmeg5vU1hoh3t7Ga4d6NwJ0V1nQxUnZrJmEf4CXLG0Fp2ymnehus941On810NxomRkbElIDYX NUBSbHKF_qXBdVg4ns49UHbzQYcCT8j8SuuJrjPObYdSp.mVEKDsabVZZ4uegXRMHwzn99UpSPCW xAXHnrMglBvSGPG8XRDt6HjH1oir8gFrW9mZGR13EWGYiKLgDPR3waCwPlBQI6xn5lwXIwE0riG9 HggkwjxuzNrkG83Z8wnC13Q0U7DyYeJHpQl_6zGWSMjjj5wJzRUY_T05QOCBg9m3D18CCgg5Ep4z ZaAxegjIw4w4LKAVH7hgjnX0t.w2BaFIEZoV42IHggHRMEkgC4Kg54Bjpp5YuvBAKTLKgO_Br3Fa 3mg.e.wpr9tJ8La0De5KbfRl3qbv38ljHY7iu5TX3XrBQASKZzLkdOGtorXGCkPv.1Hu_B8ixxXl IjzlHRKM3KYjNEQXq1O65iNCyv.12XRX7n789BqSlI2xafPksMv4.NGc7jc5yjp.9cbMggl843Qn q0AZ0Jsh4xm25S_FN07.YGlHkxNV7QcON4x6F2Gkk1FW2hDv1SOuUz3lqkoMJhexty5J1OHcEAAT wSGfvFxc2FjuYXWagFdlICoa0TRc7Y8HTTsxn9DVV.iVREX2guZB7J8QljxjMdGi9JshQiURjCFV F9932f.oe_7ueEcdkVC3zibdE75Zaacl0Cwk_liAtgYPe7loo4dNNzvbpPOBe.eliL7x9rmYBqzG vCYntm1LvIjvNuI1xK2gISgzkpSTqwFCmSuMj0kgmy59P5xRxJYv5R.9wu20wCzlDSJgpZZp2J_J Npu3uCDuqgHY6pkXDtkwG.d918eBwTnT.6kDo7Qwn4RJ_H9fN7iSUgp1eGyQThKQnaYH083cMix3 .fn7loRK4KKGP3TwiWRCgrXvd_lJlZ3yp.C7q9c5prquP0IdcuLYUna1M9l1QWcjleinRfpAIzZk WlZKPNprdmSo5qsGzIhIX.rZ3FIAmqeU5fpBWA10jKkMM.1KAG3HW6aFWlSsX.BSPgCrKqUonD_l s2jR1eSmrEhf7ODc9vo887v8I6pGL4eL9HSY598AGSbyKGwmuhSVKLdz2y_dJbTVmzH5zjOmAx9i 0u7m3rynTKiwN7toHovQCdzbloM4R2oV6edFBJTNPrYwpN_KfaZQ4r7vV92EuFjC4zKMZ.jxPCtD a1L_0nSFHnULQEwdZgGv05OFSQlr6_4JMWyHrFYQPnr4FNPnrHw78_jk1c9pDUdQZdEFPP.SfIVS ay6egvtsRKNu5jMr0ku7LIcoTu5H22v4RqrhB15F03k4pEVeY26jCnBiMmSMjwg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Jul 2020 21:51:55 +0000 Received: by smtp419.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f3c4c8330cd97b1b0adb3df6aa94ce55; Sun, 19 Jul 2020 21:51:52 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: FYI: RPi4 (8 GiByte) USB3 vs. head -r363123: still a no-go for booting a USB3 / in my experiments From: Mark Millard In-Reply-To: <7J4Opq5TWFEhuN7xv3tq206mMjbDK67p35GadBDuaJRKtDuObVfk7M8ItEEUgumC_jKkoMqC2ZJVUCpNifY579oBq1UDthM1wXjG3tBBTj0=@protonmail.com> Date: Sun, 19 Jul 2020 14:51:51 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <5C8DD645-5C24-4155-AA4C-819AF3AF3B3D@yahoo.com> References: <64A12BF8-9E2D-441D-8765-52B6D3907A58@yahoo.com> <7J4Opq5TWFEhuN7xv3tq206mMjbDK67p35GadBDuaJRKtDuObVfk7M8ItEEUgumC_jKkoMqC2ZJVUCpNifY579oBq1UDthM1wXjG3tBBTj0=@protonmail.com> To: Robert Crowston X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B8z8s3YdJz44wb X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 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.32)[-0.320]; FREEMAIL_TO(0.00)[protonmail.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/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; 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.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; 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: Sun, 19 Jul 2020 21:51:58 -0000 On 2020-Jul-19, at 04:30, Robert Crowston = wrote: > The ethernet problem could be caused by the recent change in upstream = dtb, to change the ethernet driver to operate in rgmii-rxid mode instead = of rgmii mode. See=20 > https://reviews.freebsd.org/D25251. I have not noticed this = performance problem you report myself, when using upstream dtbs from = June 2020. https://reviews.freebsd.org/D25251 was added to head as -r362353 and my testing was based on head -r3630123 . So my report is based on D25251. I do see that sys/gnu/dts/arm64/broadcom/bcm2711-rpi-4-b.dts is base on Linux 5.5 (checked-in to FreeBSD 4 months ago). But the port Makefile sysutils/rpi-firmware/Makefile indicates: FW_TAG=3D 2042453 for PORTVERSION=3D 1.20190925.g20200109 . Looking on github 2042453 is the 2019-Nov-22 commit for "kernel: Bump to 4.19.85". It seems to be from between official Tags 1.0290925 and 1.20200114 . The most recent official Tag is 1.20200601+arm64 and has materials in part based on "kernel: Bump to 5.4.42". (That is a raspberrypi/linux number.) The most recent "kernel: Bump to" for master is for 5.4.51 (committed on 2020-Jul-13). One of the items in that is: kernel: ARM: dts: Make bcm2711 dts more like 5.7 (I assume 5.7 is an upstream linux version indication.) So newer than where sys/gnu/dts/arm64/broadcom/bcm2711-rpi-4-b.dts is based. Certainly makes it interesting to figure out what combination of things should be used overall. Your wording suggests to me 1.20200601+arm64 (i.e., f382cc1), if your wording is for an officially tagged version. > You are right that we are not handling the 3 GB DMA limit in the pcie = driver. Unfortunately, it did not seem easy to thread the appropriate = bus tag through without rewriting half the inherited driver stack, and = in my testing the USB driver always allocated its DMA buffers in the = lower 3 GB without being told. But obviously it is the wrong to rely on = luck, so I=E2=80=99ll have a think about it. Until such a time, is there a good way to limit a RPi4 to the lower <=3D 3 GiBytes overall for the u-boot case? (There is an explicit selection for the uefi case.) Having a mode of operation that avoids the unreliable status could prove important for the duration. > =E2=80=94 RHC. >=20 > On Sun, Jul 19, 2020 at 03:18, Mark Millard wrote: >>=20 >>=20 >> > On 2020-Jul-18, at 14:37, Robert Crowston wrote: >> > >> > I believe this differential (https://reviews.freebsd.org/D25261) = would resolve it, but I haven't got around to addressing the comments = there yet. >> > >> > -- RHC. >>=20 >> Yep, a -r363123 kernel with that also it booted / from >> the USB3 SSD. (The kernel came from the mmcsd0.) >>=20 >>=20 >> Notes for this u-boot-rpi4 based context: >>=20 >>=20 >> Unlike for uefi v1.17, genet0 and mmcsd0 show up. >>=20 >>=20 >> There is a big asymmetry for sending vs. receiving >> over genet0 (192.168.1.126 here): >>=20 >> # iperf3 -c 192.168.1.120 --get-server-output -B 192.168.1.126 >> Connecting to host 192.168.1.120, port 5201 >> [ 5] local 192.168.1.126 port 56649 connected to 192.168.1.120 port = 5201 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 22.7 MBytes 191 Mbits/sec 85 38.4 KBytes >> [ 5] 1.00-2.00 sec 23.4 MBytes 196 Mbits/sec 146 25.7 KBytes >> [ 5] 2.00-3.00 sec 23.2 MBytes 195 Mbits/sec 226 27.1 KBytes >> [ 5] 3.00-4.00 sec 23.3 MBytes 195 Mbits/sec 229 95.0 KBytes >> [ 5] 4.00-5.00 sec 23.6 MBytes 198 Mbits/sec 228 83.7 KBytes >> [ 5] 5.00-6.00 sec 23.7 MBytes 199 Mbits/sec 209 7.13 KBytes >> [ 5] 6.00-7.00 sec 23.7 MBytes 199 Mbits/sec 207 49.8 KBytes >> [ 5] 7.00-8.00 sec 23.6 MBytes 198 Mbits/sec 217 1.43 KBytes >> [ 5] 8.00-9.00 sec 23.6 MBytes 198 Mbits/sec 224 71.3 KBytes >> [ 5] 9.00-10.00 sec 23.5 MBytes 197 Mbits/sec 242 8.55 KBytes >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.00 sec 234 MBytes 197 Mbits/sec 2013 sender >> [ 5] 0.00-10.27 sec 234 MBytes 191 Mbits/sec receiver >>=20 >> Server output: >> ----------------------------------------------------------- >> Server listening on 5201 >> ----------------------------------------------------------- >> Accepted connection from 192.168.1.126, port 57882 >> [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.126 port = 56649 >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-1.00 sec 16.4 MBytes 138 Mbits/sec >> [ 5] 1.00-2.00 sec 23.4 MBytes 196 Mbits/sec >> [ 5] 2.00-3.00 sec 23.2 MBytes 195 Mbits/sec >> [ 5] 3.00-4.00 sec 23.1 MBytes 194 Mbits/sec >> [ 5] 4.00-5.00 sec 23.6 MBytes 198 Mbits/sec >> [ 5] 5.00-6.00 sec 23.7 MBytes 199 Mbits/sec >> [ 5] 6.00-7.00 sec 23.7 MBytes 199 Mbits/sec >> [ 5] 7.00-8.00 sec 23.6 MBytes 198 Mbits/sec >> [ 5] 8.00-9.00 sec 23.6 MBytes 198 Mbits/sec >> [ 5] 9.00-10.00 sec 23.5 MBytes 197 Mbits/sec >> [ 5] 10.00-10.27 sec 6.30 MBytes 197 Mbits/sec >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-10.27 sec 234 MBytes 191 Mbits/sec receiver >>=20 >>=20 >> iperf Done. >> Rock64orRPi4# iperf3 -R -c 192.168.1.120 --get-server-output -B = 192.168.1.126 >> Connecting to host 192.168.1.120, port 5201 >> Reverse mode, remote host 192.168.1.120 is sending >> [ 5] local 192.168.1.126 port 25404 connected to 192.168.1.120 port = 5201 >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-1.00 sec 111 MBytes 933 Mbits/sec >> [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec >> [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec >> [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec >> [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec >> [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec >> [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec >> [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec >> [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec >> [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.26 sec 1.09 GBytes 910 Mbits/sec 923 sender >> [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec receiver >>=20 >> Server output: >> ----------------------------------------------------------- >> Server listening on 5201 >> ----------------------------------------------------------- >> Accepted connection from 192.168.1.126, port 41483 >> [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.126 port = 25404 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 83.7 MBytes 702 Mbits/sec 62 1.61 MBytes >> [ 5] 1.00-2.00 sec 111 MBytes 932 Mbits/sec 92 1.61 MBytes >> [ 5] 2.00-3.00 sec 111 MBytes 934 Mbits/sec 93 175 KBytes >> [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 95 88.4 KBytes >> [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 94 268 KBytes >> [ 5] 5.00-6.00 sec 111 MBytes 932 Mbits/sec 89 291 KBytes >> [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 92 4.28 KBytes >> [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 92 1.27 MBytes >> [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 94 1.61 MBytes >> [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 96 1.42 MBytes >> [ 5] 10.00-10.26 sec 29.3 MBytes 931 Mbits/sec 24 1.61 MBytes >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.26 sec 1.09 GBytes 910 Mbits/sec 923 sender >>=20 >>=20 >> iperf Done. >>=20 >>=20 >> My attempt to duplicate an about 11 GiByte .tar file failed: >>=20 >> # cp -aRx /usr/obj/clang-armv7-on-aarch64.tar /usr/obj/mmjnk.tar >> g_vfs_done():gpt/Rock64root[READ(offset=3D274911461376, = length=3D32768)]error =3D 5 >> c/usr/obj/clang-armv7-on-UFS /dev/gpt/Rock64root (/) cylinder = checksum failed: cg 270, cgp: 0x0 !=3D bp: 0xa023cccf >> aarch64.tar: Input/output error >> UFS /dev/gpt/Rock64root (/) cylinder checksum failed: cg 270, cgp: = 0x0 !=3D bp: 0xa023cccf >> pid 1123 (ntpd), jid 0, uid 0: exited on signal 6 (core dumped) >> pid 1240 (login), jid 0, uid 0: exited on signal 11 (core dumped) >>=20 >> Same media as used for Rock64 experiments. I've had no >> evidence of problems there. >>=20 >> However uefi based booting the RPi4 also has problems >> unless uefi is set to force 3 GiBytes of RAM (at most). >> The problem has usually been visible as the diff >> after the copy showing 4 KiByte or slightly less >> having differences according to diff or cmp or the >> like. There is evidence of the content and where >> changing without updates to the files, suggesting >> garbage read data. >>=20 >> Again, same media for 3GiByte RAM or on the Rock64: >> no evidence of problems for such operations. >>=20 >> My initial guess is that the handling of the RPi4 >> DMA limitations is not yet correct overall, >> apparently for both uefi and u-boot style booting. >>=20 >> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 = Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2= =80=90 >> > On Wednesday, 15 July 2020 10:09, Mark Millard via freebsd-arm = wrote: >> > >> >. . . =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 Jul 19 22:08: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 6171B36B1C7 for ; Sun, 19 Jul 2020 22:08:24 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B8zWq2VqDz46Cp for ; Sun, 19 Jul 2020 22:08:23 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sun, 19 Jul 2020 22:08:11 +0000 To: Mark Millard From: Robert Crowston Cc: freebsd-arm Reply-To: Robert Crowston Subject: Re: FYI: RPi4 (8 GiByte) USB3 vs. head -r363123: still a no-go for booting a USB3 / in my experiments Message-ID: In-Reply-To: <5C8DD645-5C24-4155-AA4C-819AF3AF3B3D@yahoo.com> References: <64A12BF8-9E2D-441D-8765-52B6D3907A58@yahoo.com> <7J4Opq5TWFEhuN7xv3tq206mMjbDK67p35GadBDuaJRKtDuObVfk7M8ItEEUgumC_jKkoMqC2ZJVUCpNifY579oBq1UDthM1wXjG3tBBTj0=@protonmail.com> <5C8DD645-5C24-4155-AA4C-819AF3AF3B3D@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=7.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 mail.protonmail.ch X-Rspamd-Queue-Id: 4B8zWq2VqDz46Cp X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 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]; 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)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.22:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.909]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.34)[0.344]; NEURAL_HAM_LONG(-0.93)[-0.934]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.22:from] 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, 19 Jul 2020 22:08:24 -0000 > Certainly makes it interesting to figure out what > combination of things should be used overall. Sorry, yes, the dtb I mostly use is ahead of FreeBSD's pkg content. The 8 G= B rpi4 model I obtained refuses to boot with the start4.elf and other boot = firwmare from November, so I just obtained the newest version for the whole= boot partition. i.e., the newest versions of those files from the Raspberr= y Pi Foundation. That broke ethernet (by moving to rgmii-rxid) which I then= fixed in D25251. I appreciate this complicates the situation. > Until such a time, is there a good way to limit a RPi4 to > the lower <=3D 3 GiBytes overall for the u-boot case? You could set hw.physmem=3D"3G" in /boot/loader.conf. I don't know if that = guarantees FreeBSD will specifically see the lowest 3 GB. The bus tag shoul= d not be too hard to fix though. -- 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, 19 July 2020 22:51, Mark Millard wrote: > > > On 2020-Jul-19, at 04:30, Robert Crowston wro= te: > > > The ethernet problem could be caused by the recent change in upstream d= tb, to change the ethernet driver to operate in rgmii-rxid mode instead of = rgmii mode. See > > https://reviews.freebsd.org/D25251. I have not noticed this performance= problem you report myself, when using upstream dtbs from June 2020. > > https://reviews.freebsd.org/D25251 was added to head as > -r362353 and my testing was based on head -r3630123 . > So my report is based on D25251. > > I do see that sys/gnu/dts/arm64/broadcom/bcm2711-rpi-4-b.dts > is base on Linux 5.5 (checked-in to FreeBSD 4 months ago). > > But the port Makefile sysutils/rpi-firmware/Makefile indicates: > FW_TAG=3D 2042453 for PORTVERSION=3D 1.20190925.g20200109 . > Looking on github 2042453 is the 2019-Nov-22 commit for > "kernel: Bump to 4.19.85". It seems to be from between official > Tags 1.0290925 and 1.20200114 . > > The most recent official Tag is 1.20200601+arm64 and has > materials in part based on "kernel: Bump to 5.4.42". (That > is a raspberrypi/linux number.) > > The most recent "kernel: Bump to" for master is for 5.4.51 > (committed on 2020-Jul-13). One of the items in that is: > > kernel: ARM: dts: Make bcm2711 dts more like 5.7 > > (I assume 5.7 is an upstream linux version indication.) > So newer than where > sys/gnu/dts/arm64/broadcom/bcm2711-rpi-4-b.dts is based. > > Certainly makes it interesting to figure out what > combination of things should be used overall. Your wording > suggests to me 1.20200601+arm64 (i.e., f382cc1), if your > wording is for an officially tagged version. > > > You are right that we are not handling the 3 GB DMA limit in the pcie d= river. Unfortunately, it did not seem easy to thread the appropriate bus ta= g through without rewriting half the inherited driver stack, and in my test= ing the USB driver always allocated its DMA buffers in the lower 3 GB witho= ut being told. But obviously it is the wrong to rely on luck, so I=E2=80= =99ll have a think about it. > > Until such a time, is there a good way to limit a RPi4 to > the lower <=3D 3 GiBytes overall for the u-boot case? (There > is an explicit selection for the uefi case.) Having a mode > of operation that avoids the unreliable status could prove > important for the duration. > > > =E2=80=94 RHC. > > > > > > On Sun, Jul 19, 2020 at 03:18, Mark Millard marklmi@yahoo.com wrote: > > > > > > On 2020-Jul-18, at 14:37, Robert Crowston wrote: > > > > I believe this differential (https://reviews.freebsd.org/D25261) wo= uld resolve it, but I haven't got around to addressing the comments there y= et. > > > > -- RHC. > > > > > > Yep, a -r363123 kernel with that also it booted / from > > > the USB3 SSD. (The kernel came from the mmcsd0.) > > > Notes for this u-boot-rpi4 based context: > > > Unlike for uefi v1.17, genet0 and mmcsd0 show up. > > > There is a big asymmetry for sending vs. receiving > > > over genet0 (192.168.1.126 here): > > > > > > iperf3 -c 192.168.1.120 --get-server-output -B 192.168.1.126 > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Connecting to host 192.168.1.120, port 5201 > > > [ 5] local 192.168.1.126 port 56649 connected to 192.168.1.120 port 5= 201 > > > [ ID] Interval Transfer Bitrate Retr Cwnd > > > [ 5] 0.00-1.00 sec 22.7 MBytes 191 Mbits/sec 85 38.4 KBytes > > > [ 5] 1.00-2.00 sec 23.4 MBytes 196 Mbits/sec 146 25.7 KBytes > > > [ 5] 2.00-3.00 sec 23.2 MBytes 195 Mbits/sec 226 27.1 KBytes > > > [ 5] 3.00-4.00 sec 23.3 MBytes 195 Mbits/sec 229 95.0 KBytes > > > [ 5] 4.00-5.00 sec 23.6 MBytes 198 Mbits/sec 228 83.7 KBytes > > > [ 5] 5.00-6.00 sec 23.7 MBytes 199 Mbits/sec 209 7.13 KBytes > > > [ 5] 6.00-7.00 sec 23.7 MBytes 199 Mbits/sec 207 49.8 KBytes > > > [ 5] 7.00-8.00 sec 23.6 MBytes 198 Mbits/sec 217 1.43 KBytes > > > [ 5] 8.00-9.00 sec 23.6 MBytes 198 Mbits/sec 224 71.3 KBytes > > > [ 5] 9.00-10.00 sec 23.5 MBytes 197 Mbits/sec 242 8.55 KBytes > > > > > > [ ID] Interval Transfer Bitrate Retr > > > [ 5] 0.00-10.00 sec 234 MBytes 197 Mbits/sec 2013 sender > > > [ 5] 0.00-10.27 sec 234 MBytes 191 Mbits/sec receiver > > > > > > Server output: > > > > > > --------------- > > > > > > Server listening on 5201 > > > > > > ------------------------- > > > > > > Accepted connection from 192.168.1.126, port 57882 > > > [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.126 port 56= 649 > > > [ ID] Interval Transfer Bitrate > > > [ 5] 0.00-1.00 sec 16.4 MBytes 138 Mbits/sec > > > [ 5] 1.00-2.00 sec 23.4 MBytes 196 Mbits/sec > > > [ 5] 2.00-3.00 sec 23.2 MBytes 195 Mbits/sec > > > [ 5] 3.00-4.00 sec 23.1 MBytes 194 Mbits/sec > > > [ 5] 4.00-5.00 sec 23.6 MBytes 198 Mbits/sec > > > [ 5] 5.00-6.00 sec 23.7 MBytes 199 Mbits/sec > > > [ 5] 6.00-7.00 sec 23.7 MBytes 199 Mbits/sec > > > [ 5] 7.00-8.00 sec 23.6 MBytes 198 Mbits/sec > > > [ 5] 8.00-9.00 sec 23.6 MBytes 198 Mbits/sec > > > [ 5] 9.00-10.00 sec 23.5 MBytes 197 Mbits/sec > > > [ 5] 10.00-10.27 sec 6.30 MBytes 197 Mbits/sec > > > > > > [ ID] Interval Transfer Bitrate > > > [ 5] 0.00-10.27 sec 234 MBytes 191 Mbits/sec receiver > > > iperf Done. > > > Rock64orRPi4# iperf3 -R -c 192.168.1.120 --get-server-output -B 192.1= 68.1.126 > > > Connecting to host 192.168.1.120, port 5201 > > > Reverse mode, remote host 192.168.1.120 is sending > > > [ 5] local 192.168.1.126 port 25404 connected to 192.168.1.120 port 5= 201 > > > [ ID] Interval Transfer Bitrate > > > [ 5] 0.00-1.00 sec 111 MBytes 933 Mbits/sec > > > [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec > > > [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec > > > [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec > > > [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec > > > [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec > > > [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec > > > [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec > > > [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec > > > [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec > > > > > > [ ID] Interval Transfer Bitrate Retr > > > [ 5] 0.00-10.26 sec 1.09 GBytes 910 Mbits/sec 923 sender > > > [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec receiver > > > > > > Server output: > > > > > > --------------- > > > > > > Server listening on 5201 > > > > > > ------------------------- > > > > > > Accepted connection from 192.168.1.126, port 41483 > > > [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.126 port 25= 404 > > > [ ID] Interval Transfer Bitrate Retr Cwnd > > > [ 5] 0.00-1.00 sec 83.7 MBytes 702 Mbits/sec 62 1.61 MBytes > > > [ 5] 1.00-2.00 sec 111 MBytes 932 Mbits/sec 92 1.61 MBytes > > > [ 5] 2.00-3.00 sec 111 MBytes 934 Mbits/sec 93 175 KBytes > > > [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 95 88.4 KBytes > > > [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 94 268 KBytes > > > [ 5] 5.00-6.00 sec 111 MBytes 932 Mbits/sec 89 291 KBytes > > > [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 92 4.28 KBytes > > > [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 92 1.27 MBytes > > > [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 94 1.61 MBytes > > > [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 96 1.42 MBytes > > > [ 5] 10.00-10.26 sec 29.3 MBytes 931 Mbits/sec 24 1.61 MBytes > > > > > > [ ID] Interval Transfer Bitrate Retr > > > [ 5] 0.00-10.26 sec 1.09 GBytes 910 Mbits/sec 923 sender > > > iperf Done. > > > My attempt to duplicate an about 11 GiByte .tar file failed: > > > > > > cp -aRx /usr/obj/clang-armv7-on-aarch64.tar /usr/obj/mmjnk.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 > > > > > > g_vfs_done():gpt/Rock64root[READ(offset=3D274911461376, length=3D3276= 8)]error =3D 5 > > > c/usr/obj/clang-armv7-on-UFS /dev/gpt/Rock64root (/) cylinder checksu= m failed: cg 270, cgp: 0x0 !=3D bp: 0xa023cccf > > > aarch64.tar: Input/output error > > > UFS /dev/gpt/Rock64root (/) cylinder checksum failed: cg 270, cgp: 0x= 0 !=3D bp: 0xa023cccf > > > pid 1123 (ntpd), jid 0, uid 0: exited on signal 6 (core dumped) > > > pid 1240 (login), jid 0, uid 0: exited on signal 11 (core dumped) > > > Same media as used for Rock64 experiments. I've had no > > > evidence of problems there. > > > However uefi based booting the RPi4 also has problems > > > unless uefi is set to force 3 GiBytes of RAM (at most). > > > The problem has usually been visible as the diff > > > after the copy showing 4 KiByte or slightly less > > > having differences according to diff or cmp or the > > > like. There is evidence of the content and where > > > changing without updates to the files, suggesting > > > garbage read data. > > > Again, same media for 3GiByte RAM or on the Rock64: > > > no evidence of problems for such operations. > > > My initial guess is that the handling of the RPi4 > > > DMA limitations is not yet correct overall, > > > apparently for both uefi and u-boot style booting. > > > > > > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Ori= ginal Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90= =E2=80=90 > > > > On Wednesday, 15 July 2020 10:09, Mark Millard via freebsd-arm free= bsd-arm@freebsd.org wrote: > > > > . . . > > =3D=3D > > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Jul 19 23:39: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 B6E0236DA2B for ; Sun, 19 Jul 2020 23:39:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 4B91Xz5h4zz4CKZ for ; Sun, 19 Jul 2020 23:39:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: xiAozGAVM1m0DW9_1pr5l_IWQhbn6t9rMF.tNf0qIjwmtJHrxSmWv2H1BapVOAA Eaen7L7vU_bQkABtZ5CmvsK3vf0_HgtZ3FikTxgGleBbtMCe8a8xUd8zHPf.lnPC.kkmsI6hUe6Z Z3zyAsit2BWColEWexUkIadVHUPW6Oo4UPBK33dBV_Rq_VX.S66AAS6nMux0a.7fXhVmFv3LRk3q f0y1CXYF840OB8oWPMCiYgRPIuK88EfcEwAvQ7DyIyMchgbOptQSxLzYaQgPMGhnCDIhNaEy_C9G PM4FvQIVAvjnIQsDj_rMmqc6793n7JNS4nqlO5lNgHGnEOF97DajgCTgtXhxYm__TvFaqvH7rUfW hwOv11Ml8SqKnnA8V1h6Fcv.Rng8_daMN7zgzlQvmds4.yccp3xBxyhEVEEmQKDRfQYfZRTbrYRJ 8V9NtzQc0sDAfkcIO4HujVctCdl5OfxEjRSV3nNGlM_eJiZjTjQLECP37Rq7DlHYN_8syGuBcMIB gGPtCNLrF6UuSxyCwjYdXSM0x6klQpSaPHWOUaAa1Qr6ouaPX0kohrDYxnAgQjNJDre6qLfhxzfV tI_Zso28myMzstGq27yLt6zyLJrbu.4nIJJHdjWVkc93i1AreGWqjXeW8yGNxD7.gtxSKlRVrNq7 yuKQfJyEW2st6kgcJKhFzgtZtmh_WW77SHdlLrxpDkR5_f_dYLdm2Oj55TWWbcVnPDU0stY.gyXv L4YGD94XpUxfB6YES4nLDiJCyLoKPpLNUkq36eeCLVTM.zbIeTLI7dClIi1TmB8321ksOOTHSFKP m3mFN0syjOEmMdF1SOQuXNAZ.8mPUMeV3gIrtjl8HgJa33uP7U7m_5mYz3aBbsrGm7lwORne6.S3 RUpmgmbp.I1wvbGuB6NMiKxqdknKUXoYDGLc8y5_sXK17xFQ22uHUDKv5bNXNq06ecoP7eEus0Q9 5LbEkHzl7tgARa3Mphxxt0TPDlvcUutz._ww.nItma3lXQM6p21UQ.62yAYIbxx68xndFTZNAfZu haITbK9O6IL3YL26PEqubRYjkkRIcWz4wHxeMnSfgV.CyrTVTBnhFZ31OQ1xztqpMv75T8ZG7d1I .v.siOaS7fK3B2vqxbQHY3gwMoM4m_1j_mZMFrHbbLeVFVQA1356CLwdjbFkC0FNTBGYs9q7uPe2 McpBwl93_n1_W6_QOA5zUnQkJEg48Hq2oLOwhxRgKtsejf0RxHAHWsIkK3rTulfcomZBRV7R5cGM jgWqyfR0qHxxGVpjTIpBX6a_OPKDAGtEiB95eIyq2cTOoORVBR6VzUDNfAdCXcqNH3sgwbK_VOWO hX3iDv.v2MLymuEy6xgFia_WwCC8q9Tlcpm9JknMvCC57_VXI6FlSli28g_e5hhdOjCibbi2Pwo7 Eyj86YGCuhl4bZpAVrtiba_Oa0_ftCg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Jul 2020 23:39:30 +0000 Received: by smtp406.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 36a07736d5b918a431e3ca3806277bb7; Sun, 19 Jul 2020 23:39:21 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: FYI: RPi4 (8 GiByte) USB3 vs. head -r363123: still a no-go for booting a USB3 / in my experiments From: Mark Millard In-Reply-To: Date: Sun, 19 Jul 2020 16:39:19 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <37CA77CB-8B78-4219-B6F8-64158826BC26@yahoo.com> References: <64A12BF8-9E2D-441D-8765-52B6D3907A58@yahoo.com> <7J4Opq5TWFEhuN7xv3tq206mMjbDK67p35GadBDuaJRKtDuObVfk7M8ItEEUgumC_jKkoMqC2ZJVUCpNifY579oBq1UDthM1wXjG3tBBTj0=@protonmail.com> <5C8DD645-5C24-4155-AA4C-819AF3AF3B3D@yahoo.com> To: Robert Crowston X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B91Xz5h4zz4CKZ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 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.92)[-0.920]; FREEMAIL_TO(0.00)[protonmail.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/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; 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.69.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; 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: Sun, 19 Jul 2020 23:39:32 -0000 On 2020-Jul-19, at 15:08, Robert Crowston = wrote: >> Certainly makes it interesting to figure out what >> combination of things should be used overall. >=20 > Sorry, yes, the dtb I mostly use is ahead of FreeBSD's pkg content. = The 8 GB rpi4 model I obtained refuses to boot with the start4.elf and = other boot firwmare from November, so I just obtained the newest version = for the whole boot partition. i.e., the newest versions of those files = from the Raspberry Pi Foundation. That broke ethernet (by moving to = rgmii-rxid) which I then fixed in D25251. I appreciate this complicates = the situation. The uefi context requires more recent than even June, no official tab yet. I'd started with what I use there but may need to explore alternatives for u-boot-rpi4 based contexts for u-boot-rpi4 based operation. >> Until such a time, is there a good way to limit a RPi4 to >> the lower <=3D 3 GiBytes overall for the u-boot case? >=20 > You could set hw.physmem=3D"3G" in /boot/loader.conf. I don't know if = that guarantees FreeBSD will specifically see the lowest 3 GB. The bus = tag should not be too hard to fix though. Hmm. Seemed to do nothing: # vmstat procs memory page disks faults cpu r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us = sy id 0 0 0 301M 7.5G 996 0 3 0 1.5K 5 0 0 10236 1.8K 18K 2 = 4 94 So, using set hw.physmem=3D"3G" at the loader prompt and then booting got me to what I report below. But, for all I know it could be random variations not related to the set that I typed. What I report below seems to have done fairly extensive file system damage as seen in attempting to boot afterwards. So far this way of operating does not seem viable, at least given the firmware vintage I'm using. login: root ld-elf.so.1: /usr/bin/login: Shared object has no run-time symbol table FreeBSD/arm64 (Rock64orRPi4) (ttyu0) login: root ld-elf.so.1: /usr/bin/login: Shared object has no run-time symbol table FreeBSD/arm64 (Rock64orRPi4) (ttyu0) login: panic: ufs_dirbad: /: bad dir ino 12760706 at offset 0: mangled = entry cpuid =3D 2 time =3D 1595201136 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff00000082eb1c lr =3D 0xffff00000010e688 sp =3D 0xffff00006cb7c010 fp =3D 0xffff00006cb7c210 db_trace_self_wrapper() at vpanic+0x194 pc =3D 0xffff00000010e688 lr =3D 0xffff00000047b428 sp =3D 0xffff00006cb7c220 fp =3D 0xffff00006cb7c270 vpanic() at panic+0x44 pc =3D 0xffff00000047b428 lr =3D 0xffff00000047b290 sp =3D 0xffff00006cb7c280 fp =3D 0xffff00006cb7c320 panic() at ufs_lookup_ino+0xbb4 pc =3D 0xffff00000047b290 lr =3D 0xffff00000079943c sp =3D 0xffff00006cb7c330 fp =3D 0xffff00006cb7c410 ufs_lookup_ino() at vfs_cache_lookup+0xc4 pc =3D 0xffff00000079943c lr =3D 0xffff000000552ae0 sp =3D 0xffff00006cb7c420 fp =3D 0xffff00006cb7c490 vfs_cache_lookup() at lookup+0x5f4 pc =3D 0xffff000000552ae0 lr =3D 0xffff00000055d7e8 sp =3D 0xffff00006cb7c4a0 fp =3D 0xffff00006cb7c510 lookup() at namei+0x464 pc =3D 0xffff00000055d7e8 lr =3D 0xffff00000055ccd4 sp =3D 0xffff00006cb7c520 fp =3D 0xffff00006cb7c610 namei() at kern_chdir+0x4c pc =3D 0xffff00000055ccd4 lr =3D 0xffff0000005794a0 sp =3D 0xffff00006cb7c620 fp =3D 0xffff00006cb7c790 kern_chdir() at do_el0_sync+0x3bc pc =3D 0xffff0000005794a0 lr =3D 0xffff00000084e0cc sp =3D 0xffff00006cb7c7a0 fp =3D 0xffff00006cb7c830 do_el0_sync() at handle_el0_sync+0x90 pc =3D 0xffff00000084e0cc lr =3D 0xffff000000831224 sp =3D 0xffff00006cb7c840 fp =3D 0xffff00006cb7c980 handle_el0_sync() at 0x212168 pc =3D 0xffff000000831224 lr =3D 0x0000000000212168 sp =3D 0xffff00006cb7c990 fp =3D 0x0000ffffffffebf0 KDB: enter: panic [ thread pid 1299 tid 100145 ] Stopped at 0x403b2910 db>=20 > -- RHC. >=20 > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 = Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2= =80=90 > On Sunday, 19 July 2020 22:51, Mark Millard wrote: >=20 >>=20 >>=20 >> On 2020-Jul-19, at 04:30, Robert Crowston = wrote: >>=20 >>> The ethernet problem could be caused by the recent change in = upstream dtb, to change the ethernet driver to operate in rgmii-rxid = mode instead of rgmii mode. See >>> https://reviews.freebsd.org/D25251. I have not noticed this = performance problem you report myself, when using upstream dtbs from = June 2020. >>=20 >> https://reviews.freebsd.org/D25251 was added to head as >> -r362353 and my testing was based on head -r3630123 . >> So my report is based on D25251. >>=20 >> I do see that sys/gnu/dts/arm64/broadcom/bcm2711-rpi-4-b.dts >> is base on Linux 5.5 (checked-in to FreeBSD 4 months ago). >>=20 >> But the port Makefile sysutils/rpi-firmware/Makefile indicates: >> FW_TAG=3D 2042453 for PORTVERSION=3D 1.20190925.g20200109 . >> Looking on github 2042453 is the 2019-Nov-22 commit for >> "kernel: Bump to 4.19.85". It seems to be from between official >> Tags 1.0290925 and 1.20200114 . >>=20 >> The most recent official Tag is 1.20200601+arm64 and has >> materials in part based on "kernel: Bump to 5.4.42". (That >> is a raspberrypi/linux number.) >>=20 >> The most recent "kernel: Bump to" for master is for 5.4.51 >> (committed on 2020-Jul-13). One of the items in that is: >>=20 >> kernel: ARM: dts: Make bcm2711 dts more like 5.7 >>=20 >> (I assume 5.7 is an upstream linux version indication.) >> So newer than where >> sys/gnu/dts/arm64/broadcom/bcm2711-rpi-4-b.dts is based. >>=20 >> Certainly makes it interesting to figure out what >> combination of things should be used overall. Your wording >> suggests to me 1.20200601+arm64 (i.e., f382cc1), if your >> wording is for an officially tagged version. >>=20 >>> You are right that we are not handling the 3 GB DMA limit in the = pcie driver. Unfortunately, it did not seem easy to thread the = appropriate bus tag through without rewriting half the inherited driver = stack, and in my testing the USB driver always allocated its DMA buffers = in the lower 3 GB without being told. But obviously it is the wrong to = rely on luck, so I=E2=80=99ll have a think about it. >>=20 >> Until such a time, is there a good way to limit a RPi4 to >> the lower <=3D 3 GiBytes overall for the u-boot case? (There >> is an explicit selection for the uefi case.) Having a mode >> of operation that avoids the unreliable status could prove >> important for the duration. >>=20 >>> =E2=80=94 RHC. >>>=20 >>>=20 >>> On Sun, Jul 19, 2020 at 03:18, Mark Millard marklmi@yahoo.com wrote: >>>=20 >>>>> On 2020-Jul-18, at 14:37, Robert Crowston wrote: >>>>> I believe this differential (https://reviews.freebsd.org/D25261) = would resolve it, but I haven't got around to addressing the comments = there yet. >>>>> -- RHC. >>>>=20 >>>> Yep, a -r363123 kernel with that also it booted / from >>>> the USB3 SSD. (The kernel came from the mmcsd0.) >>>> Notes for this u-boot-rpi4 based context: >>>> Unlike for uefi v1.17, genet0 and mmcsd0 show up. >>>> There is a big asymmetry for sending vs. receiving >>>> over genet0 (192.168.1.126 here): >>>>=20 >>>> iperf3 -c 192.168.1.120 --get-server-output -B 192.168.1.126 >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> Connecting to host 192.168.1.120, port 5201 >>>> [ 5] local 192.168.1.126 port 56649 connected to 192.168.1.120 port = 5201 >>>> [ ID] Interval Transfer Bitrate Retr Cwnd >>>> [ 5] 0.00-1.00 sec 22.7 MBytes 191 Mbits/sec 85 38.4 KBytes >>>> [ 5] 1.00-2.00 sec 23.4 MBytes 196 Mbits/sec 146 25.7 KBytes >>>> [ 5] 2.00-3.00 sec 23.2 MBytes 195 Mbits/sec 226 27.1 KBytes >>>> [ 5] 3.00-4.00 sec 23.3 MBytes 195 Mbits/sec 229 95.0 KBytes >>>> [ 5] 4.00-5.00 sec 23.6 MBytes 198 Mbits/sec 228 83.7 KBytes >>>> [ 5] 5.00-6.00 sec 23.7 MBytes 199 Mbits/sec 209 7.13 KBytes >>>> [ 5] 6.00-7.00 sec 23.7 MBytes 199 Mbits/sec 207 49.8 KBytes >>>> [ 5] 7.00-8.00 sec 23.6 MBytes 198 Mbits/sec 217 1.43 KBytes >>>> [ 5] 8.00-9.00 sec 23.6 MBytes 198 Mbits/sec 224 71.3 KBytes >>>> [ 5] 9.00-10.00 sec 23.5 MBytes 197 Mbits/sec 242 8.55 KBytes >>>>=20 >>>> [ ID] Interval Transfer Bitrate Retr >>>> [ 5] 0.00-10.00 sec 234 MBytes 197 Mbits/sec 2013 sender >>>> [ 5] 0.00-10.27 sec 234 MBytes 191 Mbits/sec receiver >>>>=20 >>>> Server output: >>>>=20 >>>> --------------- >>>>=20 >>>> Server listening on 5201 >>>>=20 >>>> ------------------------- >>>>=20 >>>> Accepted connection from 192.168.1.126, port 57882 >>>> [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.126 port = 56649 >>>> [ ID] Interval Transfer Bitrate >>>> [ 5] 0.00-1.00 sec 16.4 MBytes 138 Mbits/sec >>>> [ 5] 1.00-2.00 sec 23.4 MBytes 196 Mbits/sec >>>> [ 5] 2.00-3.00 sec 23.2 MBytes 195 Mbits/sec >>>> [ 5] 3.00-4.00 sec 23.1 MBytes 194 Mbits/sec >>>> [ 5] 4.00-5.00 sec 23.6 MBytes 198 Mbits/sec >>>> [ 5] 5.00-6.00 sec 23.7 MBytes 199 Mbits/sec >>>> [ 5] 6.00-7.00 sec 23.7 MBytes 199 Mbits/sec >>>> [ 5] 7.00-8.00 sec 23.6 MBytes 198 Mbits/sec >>>> [ 5] 8.00-9.00 sec 23.6 MBytes 198 Mbits/sec >>>> [ 5] 9.00-10.00 sec 23.5 MBytes 197 Mbits/sec >>>> [ 5] 10.00-10.27 sec 6.30 MBytes 197 Mbits/sec >>>>=20 >>>> [ ID] Interval Transfer Bitrate >>>> [ 5] 0.00-10.27 sec 234 MBytes 191 Mbits/sec receiver >>>> iperf Done. >>>> Rock64orRPi4# iperf3 -R -c 192.168.1.120 --get-server-output -B = 192.168.1.126 >>>> Connecting to host 192.168.1.120, port 5201 >>>> Reverse mode, remote host 192.168.1.120 is sending >>>> [ 5] local 192.168.1.126 port 25404 connected to 192.168.1.120 port = 5201 >>>> [ ID] Interval Transfer Bitrate >>>> [ 5] 0.00-1.00 sec 111 MBytes 933 Mbits/sec >>>> [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec >>>> [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec >>>> [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec >>>> [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec >>>> [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec >>>> [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec >>>> [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec >>>> [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec >>>> [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec >>>>=20 >>>> [ ID] Interval Transfer Bitrate Retr >>>> [ 5] 0.00-10.26 sec 1.09 GBytes 910 Mbits/sec 923 sender >>>> [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec receiver >>>>=20 >>>> Server output: >>>>=20 >>>> --------------- >>>>=20 >>>> Server listening on 5201 >>>>=20 >>>> ------------------------- >>>>=20 >>>> Accepted connection from 192.168.1.126, port 41483 >>>> [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.126 port = 25404 >>>> [ ID] Interval Transfer Bitrate Retr Cwnd >>>> [ 5] 0.00-1.00 sec 83.7 MBytes 702 Mbits/sec 62 1.61 MBytes >>>> [ 5] 1.00-2.00 sec 111 MBytes 932 Mbits/sec 92 1.61 MBytes >>>> [ 5] 2.00-3.00 sec 111 MBytes 934 Mbits/sec 93 175 KBytes >>>> [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 95 88.4 KBytes >>>> [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 94 268 KBytes >>>> [ 5] 5.00-6.00 sec 111 MBytes 932 Mbits/sec 89 291 KBytes >>>> [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 92 4.28 KBytes >>>> [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 92 1.27 MBytes >>>> [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 94 1.61 MBytes >>>> [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 96 1.42 MBytes >>>> [ 5] 10.00-10.26 sec 29.3 MBytes 931 Mbits/sec 24 1.61 MBytes >>>>=20 >>>> [ ID] Interval Transfer Bitrate Retr >>>> [ 5] 0.00-10.26 sec 1.09 GBytes 910 Mbits/sec 923 sender >>>> iperf Done. >>>> My attempt to duplicate an about 11 GiByte .tar file failed: >>>>=20 >>>> cp -aRx /usr/obj/clang-armv7-on-aarch64.tar /usr/obj/mmjnk.tar >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> g_vfs_done():gpt/Rock64root[READ(offset=3D274911461376, = length=3D32768)]error =3D 5 >>>> c/usr/obj/clang-armv7-on-UFS /dev/gpt/Rock64root (/) cylinder = checksum failed: cg 270, cgp: 0x0 !=3D bp: 0xa023cccf >>>> aarch64.tar: Input/output error >>>> UFS /dev/gpt/Rock64root (/) cylinder checksum failed: cg 270, cgp: = 0x0 !=3D bp: 0xa023cccf >>>> pid 1123 (ntpd), jid 0, uid 0: exited on signal 6 (core dumped) >>>> pid 1240 (login), jid 0, uid 0: exited on signal 11 (core dumped) >>>> Same media as used for Rock64 experiments. I've had no >>>> evidence of problems there. >>>> However uefi based booting the RPi4 also has problems >>>> unless uefi is set to force 3 GiBytes of RAM (at most). >>>> The problem has usually been visible as the diff >>>> after the copy showing 4 KiByte or slightly less >>>> having differences according to diff or cmp or the >>>> like. There is evidence of the content and where >>>> changing without updates to the files, suggesting >>>> garbage read data. >>>> Again, same media for 3GiByte RAM or on the Rock64: >>>> no evidence of problems for such operations. >>>> My initial guess is that the handling of the RPi4 >>>> DMA limitations is not yet correct overall, >>>> apparently for both uefi and u-boot style booting. >>>>=20 >>>>> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 = Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2= =80=90 >>>>> On Wednesday, 15 July 2020 10:09, Mark Millard via freebsd-arm = freebsd-arm@freebsd.org wrote: >>>>> . . . >=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 Tue Jul 21 04:25:40 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 5079C376E89; Tue, 21 Jul 2020 04:25:40 +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 4B9lrc62fMz461q; Tue, 21 Jul 2020 04:25:36 +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 06L4PaCh092174 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Jul 2020 21:25:36 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 06L4PaZv092173; Mon, 20 Jul 2020 21:25:36 -0700 (PDT) (envelope-from fbsd) Date: Mon, 20 Jul 2020 21:25:35 -0700 From: bob prohaska To: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Compiling www/chromium on rpi3 Message-ID: <20200721042535.GA92117@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4B9lrc62fMz461q 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.11 / 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.69)[0.693]; 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.35)[0.351]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.17)[0.170]; 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]; 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, 21 Jul 2020 04:25:40 -0000 After considerable time www/chromium compiled with -DBATCH on an RPI3 running r362742. More's the wonder, it actually works....well, mostly. Clicking on the rightmost "controls" menu item (three dots) drops the box for the menu, but it never fills and disapears immediately. There are lots of warnings and messages on the controlling terminal: bob@www:~ % chrome [48076:1331765248:0720/200813.457803:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id [48076:1331765248:0720/200813.525958:ERROR:browser_dm_token_storage_linux.cc(100)] Error: /etc/machine-id contains 0 characters (32 were expected). [48076:1386545408:0720/200814.206727:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [48076:1386545408:0720/200814.208308:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [48076:1386545408:0720/200814.771508:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [48076:1386545408:0720/200814.772553:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") ^C[48076:1331765248:0720/200908.297408:ERROR:network_service_instance_impl.cc(262)] Network service crashed, restarting service. [48076:1428254720:0720/200923.984849:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [48076:1428254720:0720/200923.987716:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [48076:1428254720:0720/200923.990565:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [48087:1331765248:0720/200924.072468:ERROR:viz_main_impl.cc(152)] Exiting GPU process due to errors during initialization Both hald and dbus are enabled. Is there some other service to be turned on? If a session is opened across the network a browser window opens but remains blank, at least on rapsiOS. At that point it seems stuck, but responds to control-C on the controlling terminal to kill it. Compliments and thanks to the many folks who made this exercise work at all! Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sat Jul 25 08:13: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 643513A2FF5 for ; Sat, 25 Jul 2020 08:13:37 +0000 (UTC) (envelope-from furkan@fkardame.com) Received: from sender4-of-o53.zoho.com (sender4-of-o53.zoho.com [136.143.188.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BDJjr4BK4z3dn2 for ; Sat, 25 Jul 2020 08:13:36 +0000 (UTC) (envelope-from furkan@fkardame.com) ARC-Seal: i=1; a=rsa-sha256; t=1595664813; cv=none; d=zohomail.com; s=zohoarc; b=GrWcg1EW05jnEF75dpsPKZMm8pg4o72ByuYgncrnR36IJ0XFIKlZv7Dbfxa0aBTX+bdnjLlP5Fu8BZBuoBb5umKlNputtCENnH5Jr8u4WNVORHEPMT1bacWTk+vG3Tq7ZAmnLwvCKzEjHtFD+8Vz4Hgp81/6Yj8YeMfLtHiFlHk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1595664813; h=Content-Type:Date:From:MIME-Version:Message-ID:Subject:To; bh=z/6JkMUQNqraCOSWqn+Qp4k94JQ0bbVgnJhodlKd/rk=; b=CEe0/zDfxESFHHF6jGqt+GXZiT7jnN/tVtgKhB8k/fitVJKHg5rzJVTYGaewRWXQfOdqxj3Qq4/ojONw+YR46RD5Waw3nYFijvtUQT/t21gv9Kz1gudK4k9MVy6oCq9WHKYiXwfdhgOXbjPXwjN/aEHOmnrYJIgcya4Dzi0U1aQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=fkardame.com; spf=pass smtp.mailfrom=furkan@fkardame.com; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1595664813; s=fktech; d=fkardame.com; i=furkan@fkardame.com; h=Date:From:To:Message-Id:Subject:MIME-Version:Content-Type; bh=z/6JkMUQNqraCOSWqn+Qp4k94JQ0bbVgnJhodlKd/rk=; b=YAvZBpULUyMG3lv7bfc0cL62rkXVdtzT7I352phl2W3UyIjxz6hcwa1wizpoBiU0 yxRKeO9RFR/rXlYNl6viwVDRkWt68t7OsiFjNxvyzBLN9nr1rpj1Q7SXXm87D12ARY0 wu1PirHVDCjj5zzkDyEiiNd4axTnpGU3BnK1g0uQ= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1595664812064733.6742821491695; Sat, 25 Jul 2020 01:13:32 -0700 (PDT) Date: Sat, 25 Jul 2020 11:13:32 +0300 From: Furkan Salman To: Message-Id: <1738508c81d.ade76d5f44716.6557434417901359010@fkardame.com> Subject: NanoPi R2S only 1 ethernet working. MIME-Version: 1.0 Importance: Normal User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Rspamd-Queue-Id: 4BDJjr4BK4z3dn2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=fkardame.com header.s=fktech header.b=YAvZBpUL; dmarc=pass (policy=none) header.from=fkardame.com; spf=pass (mx1.freebsd.org: domain of furkan@fkardame.com designates 136.143.188.53 as permitted sender) smtp.mailfrom=furkan@fkardame.com X-Spamd-Result: default: False [-5.05 / 15.00]; NEURAL_HAM_MEDIUM(-1.01)[-1.014]; RWL_MAILSPIKE_VERYGOOD(0.00)[136.143.188.53:from]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:136.143.188.0/23]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.05)[-1.054]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[fkardame.com:~]; DMARC_POLICY_ALLOW(-0.50)[fkardame.com,none]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.53:from]; NEURAL_HAM_SHORT(-1.19)[-1.190]; R_DKIM_PERMFAIL(0.00)[fkardame.com:s=fktech]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1] 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: Sat, 25 Jul 2020 08:13:37 -0000 Hello,=C2=A0This email is specifically for Sir.=C2=A0 Ganbold,=C2=A0 as one= of the user reported that he can only get only 1 ethernet to work in Nanop= i R2S, using ganbold sirs freebsd image,=C2=A0 I have asked him for boot lo= gs, I am waiting to recieve my R2S so I can start debugging it and see how = I can help in adding its support to FreeBsd and opnsense.Where can I find t= he nanopiR2S uboot port?=C2=A0=C2=A0Regarding RockPiE I was able to get bot= h the lan to work with Gonzo's fix which was picked by s133pw@1k3r.Thank yo= u everyone for your hard work.=C2=A0 From owner-freebsd-arm@freebsd.org Sat Jul 25 22:14: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 221CC3721AC for ; Sat, 25 Jul 2020 22:14:26 +0000 (UTC) (envelope-from furkan@fkardame.com) Received: from sender4-of-o53.zoho.com (sender4-of-o53.zoho.com [136.143.188.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BDgN069d2z3TKN for ; Sat, 25 Jul 2020 22:14:24 +0000 (UTC) (envelope-from furkan@fkardame.com) ARC-Seal: i=1; a=rsa-sha256; t=1595715260; cv=none; d=zohomail.com; s=zohoarc; b=balF8TlVStasmhq7D9AuoUR0fnhJUXwgBXX5SeqK2ehFDQuc/gBIlN7QC6DIFRTQpgFKdxZe/d3/uNBkriWYUf4ROpUmayT7hAxLPRi9XuTr1vsxBNxjJc16ZVL14RYwoAxmo/4QbEdgenGFoPTzrcxZRg4a7tQRtNQo54WGlJI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1595715260; h=Content-Type:Date:From:MIME-Version:Message-ID:Subject:To; bh=P+AsfuolEFYZX8bIHihSrOeq0yJVMaC3AEluyiHc+mI=; b=JJ2OYzXsiZxfGHSIE4Rroa6dxtGZaW3FDm3Ijy2en05gARPq+Q1RUp5f44wd/mIo5IW2usf7NLhUDyXopiT85/DoQ1myCdLPpik9T0EjH1THBKE4DRiwQCQxDCZUBUb48yoy6dJRxdVrgigUpKcoLR10ZxdgRYtPhYM2Kk/YpZ4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=fkardame.com; spf=pass smtp.mailfrom=furkan@fkardame.com; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1595715260; s=fktech; d=fkardame.com; i=furkan@fkardame.com; h=Date:From:To:Message-Id:Subject:MIME-Version:Content-Type; bh=P+AsfuolEFYZX8bIHihSrOeq0yJVMaC3AEluyiHc+mI=; b=GYRbW1+4G1Q+cjIqraUs9Pvh+OBjIU20QrfpOGIlTWjkRiGLttqNFDhQM1r431Mw 6/rzII29IAvQ6IPkNk98pZgWJT1f27DxV7baGIhpJTsIZCdZeJpRrVncCOpDJXsPU1v O4miMesTos5ej+k2b0pg0HA8Hcku1wA/t9fj2tHg= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1595715258149399.2203997676396; Sat, 25 Jul 2020 15:14:18 -0700 (PDT) Date: Sun, 26 Jul 2020 01:14:18 +0300 From: Furkan Salman To: Message-Id: <173880a8722.bb536d3356132.5366446314492261272@fkardame.com> Subject: Re: NanoPi R2S only 1 ethernet working. MIME-Version: 1.0 Importance: Normal User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Rspamd-Queue-Id: 4BDgN069d2z3TKN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=fkardame.com header.s=fktech header.b=GYRbW1+4; dmarc=pass (policy=none) header.from=fkardame.com; spf=pass (mx1.freebsd.org: domain of furkan@fkardame.com designates 136.143.188.53 as permitted sender) smtp.mailfrom=furkan@fkardame.com X-Spamd-Result: default: False [-3.08 / 15.00]; FAKE_REPLY(1.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[136.143.188.53:from]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:136.143.188.0/23]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.06)[-1.055]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.03)[-1.030]; DKIM_TRACE(0.00)[fkardame.com:~]; DMARC_POLICY_ALLOW(-0.50)[fkardame.com,none]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.53:from]; NEURAL_HAM_SHORT(-0.21)[-0.207]; R_DKIM_PERMFAIL(0.00)[fkardame.com:s=fktech]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1] 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: Sat, 25 Jul 2020 22:14:26 -0000 Hello,=C2=A0Here is the boot logs provided by the tester.=C2=A0https://past= ebin.com/mu5hkLRGIt is from opnsense forum.=C2=A0https://forum.opnsense.org= /index.php?topic=3D12186.msg82862#msg82862As gonzo have already added suppo= rt for rk3328 onboard lan for rockpiE then the same can be used for r2s,=C2= =A0 I guess that should work.=C2=A0Thank you.=C2=A0