From owner-freebsd-arm@freebsd.org Sun Mar 7 05:30:48 2021 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 F21BB5592F6 for ; Sun, 7 Mar 2021 05:30:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.ne1.yahoo.com (sonic309-22.consmr.mail.ne1.yahoo.com [66.163.184.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 4DtVS738qzz3t4y for ; Sun, 7 Mar 2021 05:30:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615095045; bh=NQk2pRmZiNAgj/Mc1H3XWC5gSAD+sAlKSP9GQDFdTQt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=RsGH2a8gBz1wk0Zog0D5U8GFab7LhNXoH/qqtiAOeW6NzYqxZ8OuIzYW2ELHp7pxinXvTM8LDSkQuafxz3wr0t6MBBrImLdAyVjfD/eMg8Uhj+hMwuBBljDHRgaS9AW4nsBcEDtbRD3Mgy5RUkT/hc0wvH4jKE75Ks2QaGV0v1Zk6hEqmOx1bXS4GmbbJKld1IV2rZzcoMnfGxOE+tYSRmIFyGG02kCBX4HoAVU2H+wr/yEOMgunAzKkCK4G0dQ3CTzN4NmDJDEGd9HdXkLO+w09PYUE11tn+UfxKQDc52uiqaTINVc1e9hLIGUqz5AYpQCAnYQYGVx0srYgaXNVCw== X-YMail-OSG: 5ThjM9MVM1nIdHLjZdbVH4_0rPKr4jBRYT5bLoqD2EGUxR0D_VZ0o.e16Bq0iYA D3rrnc.wulQpzs_sigHGa3qK_1A6ArQ5shOvV19zijR2LeKmKGeLIkroOYfxyjcdjT1q7dnmNDaz mc8bBDu3woDYlLyhpN4OzivnC0lQmH1FlAhoktwklRuJJJIr4UQHyF.mgHlqDXXQ05P46pdgaOpo kZkqOt116HKJ9J1CxxQ5_SjXmmMFQAizrwVftSPX5dFIyFrVnPEcdhvcJieVDbhjIv68JUWolusL pACtlnMpJuT_fEAr1w.eNHm7tG7XySDFJW5eoRGGKQWYh1IvxY59H4x65pcJ_jHNmUy0glbvkhU6 AS.vscDJwRqfidPEXbU.5kLBdJUv.DjaqaMTfR_yYjXDkzzRAfZahs8I2SQ4c_EgC1NpmJy7MCxu rdV6YWXzarmh.ACFCQAyxpDp0A.n4MMBlAVGuTF8M0Buh75rzYx_r4xPu2VP48y0PujLAbUrJlXv VyMoKkiuJd3jUJpwcWadRborzJO2gw8VchTh_jhoyeUugx2hErQgzm0ZgoGC_hXiIpL5PGQ3q44m Vz5BybUbWT7oIAm_kTSnnC_Y50GFD1Z4UEkIB2bl_pCX1336WjEAboPi.kXP2I_EN5RKMHGpYscJ msvcZr5GFE94UO8LCPcJv5n.PcUWhAIzGMGcPVJhT8KrYhLJr1LGC1BELHH5rR1lMU4JUZOOlAGH uvxJr8CIIqzRbNMjniMWzssep9CP2THQ4FqF8iv.oHo2vtZQVt9i4xA7pOyurmmjWOaZ3PzHJeDK zwk97Oni58rmpIODhvgo62faQwE2YiMyRE8BQ2GdnxVatyW6jnm5B0pRCbE2t4T3DvJXNQLcchkr j9jmIQ95kTxRYSYpLLtsaYRWXJ_xWixylpL.DTUq0yEj9FRY2z3Ackf_6Fq2CrQlIWFTyN96dmHw 2twlT9Aa8mwLrnvEhLsYCmQjIrlrSIKGQlHt40d.L073fQrUPqvbb9m54CfZ4Sym8exvx2wHFs5W Md7MJPeIrnRPv89SUZgxYJinYt9D6sgtOiNV7A2OylCMXvJNmKinPUxeX6DngPCDqGN_5MPRJ.aM LW25qu5MjUB_vys.oxI_RsvlOfSf.CQEfuYgLm4m3FuVSFKBLV4wMutd9sx4VOAaGQY7snxisCYd .EK9y5w2mTvhSpPRVVLcMGw9dgXU.Nmld4sg3xPWsQ4bvmfLTC_4fZKrwzp76AMxMxfFnEk3eW6u zpJGfTSGu02QONtkl8NQqLgRo4bPzhoLV4X8s4Jn5maUyzTWh8zE86I_s2hC734V_0RHRrof1Jg4 _HyUil72RI3Ld37zmzFjpN8U4Z.cmBKrqWGnnFh9mf5_fj9q1dAsug5rDVKSlmKTYAGsK63vmUll vZZ9zyF.HQIGB9k18fTrs0kQMv7MKDw_6sz5ipOUdsEwGuCUnz61BdT2_wN6QACb_ZXq.6ciCDpx dzO0KlqGkW.nQQQPwKxIGt16iIPI2_Jc_XiG6o5EvVDsU3.R1DEcILK3bCE.uHUbRKAvcBLkkbce vXXISvElD_0JvFClqm1v.HTSOVC8ACZmx_hiQco88wowKD_slIEucZCQ_njNC7Eu0Gpe9soSENU4 oHRc5UYq8Va1qqd1KQPUln1EBNm4jpgJDthfH8WWSIrdWZoHXkv0wimrt8Df.dFlPVh7DKbPKBhj .MZu_wto_D5HkeodBLsTbKxS3jctheoKH7dzcnd1s13Sx5b3PdeWEP0WCb30mRSMy.1G9.wnBQ4f ZLb7_OmxkXGQc1ddVdwSOYZSwYnXePelxDFj_o4H9eel3Fkl8Tt_vXIqlA_syZ.ZA8oxKuebNNmV fRhDTZ6O8hOK8xWj2h_NbzxWrtvdt2kdf1OPItBLbj6InRHsqaR7IGLIq0ZfX7RwIlJ9w8tQ6jWF vSZ4DEywuMMfiUPN2jc8FjJlOMrpxrvLbZ7Jv8G0y8lHu1U9ZnZYhDJnL8Wb0k9bc4aT7uM_OLiR o8.YmhbMbWuhRHe4AW7lekqHIAirwTgNWAd39B1VsH85.rjPqMZQGzWtcKJJamZIolq_sWS4qLAB YTPsucrCjV7pvuxYikQdIy2IWfSU1gM58Kb5VoRl6m8Zqn1YWIBvIxwtDC5UPva10WpVgE0meX7R p7lr_Y4X6BDZl0.izqfU.yq3yw1d8KGBW6oxgSGB1kKlvTYndcV0bq9oTOoSjgvbdA7B9Eq8U5GQ jt48gvU1t2BYqDj84xDA4DrnNB.0c1fp.CwVZfGn7POBW_KY4QH5WCJv.1PhYbbwYii65JhR4hIp FvDM_.J2iGxVzPMase0uOJiHRYF01bqTWhVsvXHZL7g7onfO_9108Em4FTgUCcKvmGzvgLe.vNYX LPMbYonQoWPa_iK1_XKcZPKIysxdK9jFQTpdnxJ4JJr5kfmsXNJoN6lFNXMaQvSmNvXmWajLPyzR D2NoUtZtBDqSD2Tf2pKPkh3dXJhmS5x4ZL8V2hVTRmysZ3OrBkivcxw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sun, 7 Mar 2021 05:30:45 +0000 Received: by smtp421.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 17ef5e283f6b118ec277c2f02372df48; Sun, 07 Mar 2021 05:30:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: RPi4 Status and sysutils/rpi-firmware (and rng) From: Mark Millard In-Reply-To: <20210307021628.GA99890@www.zefox.net> Date: Sat, 6 Mar 2021 21:30:33 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210307021628.GA99890@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DtVS738qzz3t4y X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.82 / 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.322]; 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:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.184.148:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.184.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.184.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.184.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2021 05:30:49 -0000 On 2021-Mar-6, at 18:16, bob prohaska wrote: > On Sat, Mar 06, 2021 at 03:14:46PM -0800, Mark Millard via freebsd-arm = wrote: >> bob prohaska fbsd at www.zefox.net wrote on >> Sat Mar 6 17:38:40 UTC 2021 : >>=20 >>> On Sat, Mar 06, 2021 at 11:42:06AM +0000, Mark Murray wrote: >>>>=20 >>>>=20 >>>>> On 6 Mar 2021, at 11:37, Gordon Bergling = wrote: >>>>> Done in e797dc58bd29c5bc0873fc620fc11d5332f90e7f. Thanks for the = approval. >>>>=20 >>>> You are welcome. Thanks for doing the work! >>>>=20 >>>> M >>>> -- >>>=20 >>> Any hint when a bootable snapshot image might become available? >>> The target host is an 8GB Pi4 without a serial console, so it's >>> limited to USB keyboard and HDMI console, no wired ethernet. >>=20 >> Are you picky about debug-builds ( main [so 14] ) vs. non-debug >> builds ( stable/13 or releng/13.0 based )? >>=20 > Nope. main based (debug): Thursday/Friday via: https://lists.freebsd.org/pipermail/freebsd-snapshots/ (stable/13 will likely show up there on that sort of schedule once 13.0-RELEASE is no longer active.) (Until 13.0-RELEASE is out . . .) releng/13.0 based (non-debug): Friday/Saturday via http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.0/ >> Also, are you picky about sysutils/rpi-firmware already being >> up to date in what you get vs. your having to replace the files >> with files from a recent sysutils/rpi-firmware build? >>=20 > Not at all.=20 Looks like rpi-firmware-1.20210303.g20210303 is in the built ports in the on-going p567446_se53138694a build listed at: http://ampere2.nyi.freebsd.org/jail.html?mastername=3Dmain-arm64-default It indicates 11 ports remaining to build overall. (I've not checked if any of the 11 are multi-day of themselves.) Then there is the time for getting copies to various servers. So it looks like the official rpi-firmware port build will show up in, say, a few days. Of course, there is also the option of building sysutils/rpi-firmware directly and copying from the installed material. >> Technically I've no clue how to know what sysutils/rpi-firmware >> vintage or sysutils/u-boot-rpi4-arm64 vintage would be used in >> future builds on the FreeBSD build servers. The FreeBSD commit >> hash/id does not identify that information in any way that I >> know of. For past builds, as far as I know one must examine the >> files contained and back trace the vintage that they came from. >> Nothing reports what it takes to reproduce the context that I >> know of. Such points seem to be involved for all media-builds >> that have sysutils/* materials providing some the media content. >>=20 > The git versioning scheme does seem to leave us with a raging > case of chicken-vs-egg syndrome. An imperfect solution would=20 > be an improvement over the status quo. This problem is not new with git for FreeBSD: same problem before, same problem once ports is also git based. The tie between the vintages of parts contributing to the media for something like *-arm64-aarch64-RPI*.img.xz is not in any publicly-trackable place(s), so far as I know. > But, blind optimism triumphed over hard-earned experience, > at least in this case 8-) >=20 > Herb's advice worked, by combining the most recent Pi4 snapshot > with the msdos files in the link provided in Manu's post: > https://github.com/raspberrypi/firmware That should work. But there have been commits there from after 1.20210303 was tagged as a release for distribution. sysutils/rpi-firmware is tied to 1.20210303 now. This can lead to possibly wanting to instead use: https://github.com/raspberrypi/firmware/tree/1.20210303/ to get to the materials that have been tagged that should match sysutils/rpi-firmare will be using for a while. https://github.com/raspberrypi/firmware is sort of like stable/13 (vs. releng/13.0) for FreeBSD (but with binary files) unless you only reference appropriately tagged commits. (The closest approximation to FreeBSD's main seems to not be publicly accessible.) stable/13 and the like tend to be in working condition for FreeBSD use more than https://github.com/raspberrypi/firmware materials are, even when using tagged versions. (Failing for FreeBSD need not mean failing for raspiOS or raspiOS64 for most users.) > I probably wasn't efficient about it, simply overwriting everything > that looked obviously relevant (and expecting to break something > like the path to the kernel) but it worked. Replacing old files is generally the correct procedure, other than config.txt . The question can be picking a good set of file vintages to copy. (There can be fairly regular additions and removals in overlays/ so it is not all just replacement.) > The HDMI console text is too big, but the keyboard works Folks with poor eye sight for the context tend to argue for the default being fairly large, figuring others can more easily do something explicit to make the display match what they prefer. (More difficult if you already can not well read what is displayed by default.) Of course, the sizing of what is displayed before FreeBSD's loader is even involved (or, may be, FreeBSD's u-boot choice) is not up to FreeBSD. I've not experimented in this area on a RPi* (yet?). > and top > seems to see all 8 GB of RAM. Didn't think to check the mouse 8-( I've not done the huge-file copy-corruption testing recently, and never with stable/13 or releng/13.0 or a 13.0-BETA*/RC* . I probably should try, booting a 13.0-RC* image as the context (other than the rpi-firmware replacements). I use a file that is notably bigger than the RAM. Historically, if the corruption problems show up the technique to get a reliable environment was to restrict it to using 3 GiBytes, possibly via some text in config.txt . This also applied to the RPi4B 4 GiByte models. > Alas, with no wired ethernet at the location I can't do much=20 > as-is. However, it does motivate me to consider a second Pi4 > to be placed in my private "data center". Altogether it is a > large step forward. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)