From owner-freebsd-arm@freebsd.org Tue Mar 16 22:22:16 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 1884D570414 for ; Tue, 16 Mar 2021 22:22:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F0ST26lCDz3nKD for ; Tue, 16 Mar 2021 22:22:14 +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=1615933333; bh=mSsoan+pAwg2cI4vzEQsSvvWi/0RB8xi+EjU6bodp/Y=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Mag1t5/qAUcj8uy2jOCGEpWKhlHL1ojbwnwK77UxlPJ+jxFbC7JRZ2GDqWvM5I3k+rRHwvMy7rYng79yMUUwRzau7o32w2r1lDfC9bINaObchwSpoLzCiRf54X2fTJ1wTWWgfmUMjcKOobpv9gTu+vQ4JwYKWRhcftaR41r1wW4fmLoxMOk3MTbgIsP/GRvNjdVeJXOpmYgU6NjvopJZd9j/F1G1p+rB19u5L37GYrK5TogaRkaREoOaLmxgzVE0xZSdxfXiVCxkBC040sVSm7/JY3SKcR68n2Ohw4vFIXwnZtiWyVcUrkQAACOirbmipcd4hWhINA8vtU9/WycMsw== X-YMail-OSG: UvOIPEoVM1lIl7jHkf0XctAbVyOUcUOn5jpiXFOFIJ4S8hPKqul4C_dN_XAYNvO 1x6MS2i6XzIuJ1bCwXjJSg2nzvx8380ROF1aeXgcRqdhqTsbFwjg5ke4c9apiCJGdSG3nkrMClWW gNgfvghAsZr2vTwHFewJ1ryvMsckMsZKPw8B355uq9.jnM6qW47S6wSqDRNXCcog8TdNWS8xm9WV ablow.aezAL05_kio.1wchrXpGB98cM8T7y_RJGtCxRuCZ.RDYgT.JaRQXnqsB47EWk_irBYZ5Az 4ePAq7lcRppX7ieoIy5I.fSlvLayprzHWIIREH.2PRC39hSass0arGHxT0I5WZc6lBzaatwiqWz8 sEO1JGu4sxFf.eYP_Q80lJxFqHxsd6440iG.alJcA_xLHpuTKrfv_uX._Hav4atqyKqo0Zgah3VE fy919.CFoog3Jsfn4I7q.4GNBrF4jpMrpAcTjpW5hkylKOoKPzbw1aOCbqgzweltZ3w5qziNDyLS sZMN8VY_SwBXgbbOf1ImuXmg0tbUecdC36_sDuuA8vJ1AvthMLQ.myRg7ge7t3qFcNYXEnbnW5Hv 64IRvUUmCbVjZXu5cflvDMmTRIEcYb_dI3gEVFmaGrBSRSOMfLuuf3iUO_4M8u_OWwXhuzHD1ELE RJENzYfpwzwIxT8tYmpd4iSoDlFuDSTceoOVkDMcn7tXOvHTF3vY6.PJEvvzoXWSimxvZk_pGBDn pQj7nemR8kvMBF0flIbr7wkOZrhqQHC14OzP7KAMy_AB6a3qYrqe55wfnmif2DFLCYfRx2UIcycy j6sHm6Ye8ZLiED2aNFz1sNp8amEZFMXB0CWiJXj8lFkXINr_oht05Bg93dItwI6XKtyqF_6M6BqA yrRoBM2rooZGRcJtAdr5kjvhydtvcaURvPaKzmup2ccwHblyc7jqoTEdZbhRystgX_gUbvIDHFtp Qq38lXxKNkCk_l04OGqm81WuieNQlao.LOcuHsa3LqavO.HcL4r2dMF.tJHBeZO.EuTqSwybIEWI 6S_zWvwbXg4qaNLRi15yi1H9JRLE3.JGU4dBjxDZNpYahOFe9oVDpRl22_5xv4vrJvyS0xYzvudM rldtEKzUFLeHIJF1rgXpG7MDo_7eSnIKOfkb4kRqoEjm3S9btSXxKg6aWOulluuG9TH0vaZfgL4D 6.LwGZkMM6nZLL7G3KjKRBIOwr2dBvMPhM7KH0FH6WvnlTejyf970cmpkE5C9xiSe_EJRPI3iqeu U8k5UrUYxtIMY263nM6Zn5M_Z0A30iXhwcjSd4ZHSW3DgQDBQaDxCLOkkMR3ZeSscdY.Sx455YmL 451J9G2VcpW3eHDuFCLY5UuO5ZoIhZU.Mu8acN4CNT3VIddlfUoTYrAnaciBUtWhhslA6x7F4HlX uzuSSVuozm3Evy2ALKD013p899Hrf9p2w1S6g.Su.rjmDWDvOvcUttO82sCTEsKSnj1w7LxSzwZ8 esEChpDuUCTycyNOrzDPtXoOjJnx99_3_uqMW.oA43HM8HLzNnsuHPfQ70vYSl1nvTEJQFuGTJIP yBcl9sMHIQBbEspASl7Wee3PERNho9eQVLDPv7e1y54F_XXqbI5N4P_0eeuOVh7WbNld60fyaVw8 kmZifE12K9Jd.YOSk2DVFKKgXuTO_bTyS6e9IMOIoPd9Rn9VTUAs4YQkkk8T9N565ERJj5G6OedJ Byof1.UlpFCuNFPC8A.JJn4D1g0SloomNgJVwvNoxAD7Txuo7UbGTng_wEmtO1v0Oxtv6lzCOzYy Kfcg9l4uFZCcR9dRG4c35CLnA5ZjcMIXaK83Wtu9AC33PUi5xzEmxN87cGmDqT5CmkuDQM2xT39M KjTCP22J72LfBZEtuKqnoqVJ36O2GbqUGueGv1c.1uPHzIH6gk6Zkcbjdijo76NkfjCEf1MYU4ek ofiESjOTRUpF..wk_CsbcmP_X7iVGwq8PBCLunYkqFxpXu80MJpqrgrDPqNKFJP_LGl3juquP32p y.fFodtLHkzNGw58tgr.gxtgiUssH96gGz8hbzCwRtHC7wmDUXLnP8sdX6HcZCMGlqPT2xN7YGtV yXn9zBzw1.mMRFVcYWzQwj.qecjWqrs7hrNonNkucRbWUnjEqWujHsBzlp03fJeSt0lpICK53jKY y_NXA30BqqgOBNJ.lID6Vtct5YpoRE0J3znk9W1kMKhABzGJupIdewiG8qGmMxjnr81SlxvmW0mp tx87ZRHfIJKnrTQ8skXHd6xZmkfSbeOD.D480zDaBDGnWi7Gj5Jr57tL2YhhQc_fCht3zZy2ONUy LRlYbNMRO_X2AHbgH9yxSFf710qJRE2mdVD.EpTAtIZEU7cq0pVxLh5NvwxExaeomMS0xtas96rr yTq0PTz9lSkt3MXtrRm0.C_jUM1aovAboIc1iSv6aIGESSDfULc.4UT7zbMbENaMZ_Xf_PfKROrE eQ7fWVwIG.IkVW0Q7CUIHJvNK4T9t3Tpoj6LJnkjr9qXDM2cbasxHv0JN.S0RxbLDwRE5nV1ZIeE Kt44HGmmHPtdKxM_n4hISO6It8q4PU1m5_fe3zJ0Z X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 16 Mar 2021 22:22:13 +0000 Received: by smtp416.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8f6600ce32a141b2a3002bff3be9b00f; Tue, 16 Mar 2021 22:22:11 +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: rpi4b main-n245392-8423f5d4c12 won't boot due to microsd timeout [FIXED] From: Mark Millard In-Reply-To: Date: Tue, 16 Mar 2021 15:22:10 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <548DA04C-8CF0-4898-9C9A-423B8A400AE5@yahoo.com> References: <79EB88DA-0144-4A12-B716-3CF5011F16C4@yahoo.com> To: tech-lists X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4F0ST26lCDz3nKD X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.206: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)[98.137.68.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; 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: Tue, 16 Mar 2021 22:22:16 -0000 On 2021-Mar-16, at 09:44, tech-lists wrote: > On Mon, Mar 15, 2021 at 06:50:02PM -0700, Mark Millard wrote: >=20 >> So there would seem to be no urgent aspect of >> existing RPi[34] u-boot ports vs. Klaus K.'s >> build(s) to lead Klaus to put up reviews on >> Phabricator for updates to: >>=20 >> sysutils/u-boot-rpi-arm64 >> sysutils/u-boot-rpi3 >> sysutils/u-boot-rpi4 >=20 > I don't know what (version) those ports make, as I've never = tested/used them. My way of working (directly updating firmware files) = is a hangover from the time when there was little support for the = rpi4/8GB and I've just never changed my method. Maybe that needs = changing. Where those ports are/were used in official FreeBSD builds . . . sysutils/u-boot-rpi-arm64 (from latest) is what is used in building the official, weekly snapshots' FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-*.img.xz images. Some version from quarterly is used in building the official: FreeBSD-13.0-*-arm64-aarch64-RPI.img.xz images. FreeBSD-13.0-RC3-arm64-aarch64-RPI.img.xz this week should finally use a sysutils/u-boot-rpi-arm64 version from quarterly that no longer has the RPi* firmware based USB problem(s). = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz from last week was the first to use a version of sysutils/u-boot-rpi-arm64 from latest that no longer had the RPI*firmware USB problem(s) but it had FreeBSD kernel USB problems reported by its debug kernel. [I'm ignoring u-boot's not handling having multiple storage LUNs in a USB device here.] Back when there were separate snapshots for RPi4 and RPi3 for 64-bit, sysutils/u-boot-rpi4 and sysutils/u-boot-rpi3 were used. (The detailed u-boot options for at least sysutils/u-boot-rpi4 are somewhat different than for sysutils/u-boot-rpi-arm64 .) Two of the ports are intended to be RPi4 vs. RPi3 (and RPi2 v1.2) specific. In an RPi4 context, materials from sysutils/u-boot-rpi3 should not be used. What versions are built . . . As far as I know all the u-boot ports are currently picking up the default 2020.10 assignment that is in sysutils/u-boot-master plus whatever local patches that they may have. sysutils/u-boot-master specifies other details for specific ports as well. >>> [1] how would I "test" the installed[2] u-boot.bin to make sure it = was >>> working correctly? >>=20 >> I was thinking of whatever criteria you used when you >> wrote: >>=20 >> QUOTE >> . . . >>> = https://sourceforge.net/projects/fbsd-rpi4-u-boot2021-04-klaus/files/u-boo= t.bin/download >>=20 >> Pleased to report this new u-boot works perfectly! thank you >> END QUOTE >=20 > what I was looking for when I asked the question was whether you might > know a method of testing it programmatically. I mean, I'm not a = programmer, so I don't know where to look. I don't even know what the > three firmware files do, apart from leveraging the booting process.=20 u-boot is used in booting but (for the most part?) does not survive the OS finishing its boot: basically nothing to test for u-boot after booting successfully. General testing is just if you are having boot problems. The mess is if the answer is yes and then the problem needs to be tracked down to contributions from some combination of firmware, u-boot, loader.efi (bootaa64.efi), FreeBSD kernel, or world materials (in part depending on how far things got for the configuration). > By "works perfectly", what I mean is it seems to do everything asked = of it. > The stable/13 machine, as well as self-hosting, runs poudriere for = about 500 > packages, runs mail clients, is a web server, uses usb3+zfs for > additional (2Tb) storage, boots off sdcard, is clocked at 2GHz. "Boots off sdcard" and possibly "is clocked at 2GHz" are the parts of that tied to u-boot. (u-boot could force the initial conditions for what the later stages see for cpu clock rates and such.) "Booting off USB without use of a microsd card" would be another form of test tied to u-boot. > I don't know what else to test apart from transferring files from = sdmmc to > usb3 storage and back and checking for crc errors, I mention because = there was an issue with large file transfers a while ago. The large file transfer problems that I know of were for RPi4's with > 3 GiByte RAM configured and the fix was to the FreeBSD kernel. (uefi/ACPI booting is still limited to <=3D 3 GiByte for reliable operation: the kernel fix was only to code not involved for ACPI handling.) >> I had not quizzed you about what it takes to have the >> status "works perfectly". >=20 > Hopefully, the above answers that. If not, please suggest some tests = to > run? I think your activity was fine for the purposes involved. You might want to recheck some official snapshots and 13.0 releases as they are released, hopefully not having to make substitutions copied from elsewhere else once this week's materials are available (including the debug FreeBSD kernel). >> (I would expect that "works perfectly" has to involve how the = combination of u-boot and RPi* firmware operate together in making the >> judgment.) >=20 > All I can say for certain is that this combination > wget > = https://sourceforge.net/projects/fbsd-rpi4-u-boot2021-04-klaus/files/u-boo= t.bin/download > -O u-boot.bin > fetch > = https://github.com/raspberrypi/firmware/raw/0591568b29a724de406aa737fc8e13= f68c423f3f/boot/start4.elf > fetch > = https://github.com/raspberrypi/firmware/raw/0591568b29a724de406aa737fc8e13= f68c423f3f/boot/fixup4.dat Hopefully none of that copying will be needed to get materials once this week's 13.0-RC3 and main snapshots are available and materials from them are put to use (msdos file system materials). Getting such materials from the official builds helps check that the official builds are good. Getting them from elsewhere does not directly do so. > "work perfectly" (but see [3]), with both a stable/13 (13-n244890) = GENERIC rpi4 and current/14 (main-n245454) rpi4 with a GENERIC-NODEBUG = kernel. >=20 >> [2] has both a different u-boot and a different >> group of RPi* firmware files. >>=20 >> There would seem to be no urgent aspect of the >> existing sysutils/rpi-firmware port vs. the >> Mar 10 2021 RPI* materials to lead anyone to >> put up a review on Phabricator for updating: >=20 > I'm not sure either way because I don't know if or how any of the = three > files work when it comes to initialising usb, or sdmmc which is where = I > started. Both the RPi* firmware and u-boot could potentially mess things up. As things are, absent specific evidence, the RPi* firmware is more likely to be what broke things if something is discovered to be broken. The 3 different u-boots are alternatives for each other, although two are intended to be RPi4 vs. RPi3(/RPi2 V1.2) specific. For helping check modern official-build materials, sysutils/u-boot-rpi-arm64 is the one to check. > Additionally, main-n245454 (generic, so debug kernel) unmodified will = boot if there's nothing usb attached. If my usb3 disk is plugged in = after it boots, the pi will panic. If I reboot replacing just the u-boot = with Klaus's u-boot, I get the same result.=20 Until this week's main snapshot build and 13.0-RC3 build, problems with USB are expected and are from one or both of 2 places: A) Older RPi* firmware that is known-broken B) FreeBSD debug kernel panics about inappropriate sleeping being allowed for memory allocations. (Recently added validation code reporting pre-existing problems as I understand.) NOTE: (B) was not limited to arm or aarch64 platforms but (A) is so limited. Both should be fixed in this week's build materials. u-boot was not involved in causing either of those problems. (The only known u-boot issue for USB seems to be that it does not support USB devices that have multiple storage LUNs in the device.) > If I replace all 3 files with the latest versions as described in the > URLs, (again generic kernel so with debug on main/14), it will still = panic when usb is plugged in. Presumably these "latest" files are ahead = of those made by ports. It only takes the debug kernel to be involved to have the panics about inappropriate sleeping being allowed. This problem was not limited to RPi4 or aarch64 or even to arm. Even with good RPi* firmware and a good u-boot, it was a problem made obvious by the debug FreeBSD kernel. > So, the things that are fixed for me are sdmmc initialisation = (presumably > u-boot fixed this) on stable/13 As I remember you initially reported a 2020.07 or some such older u-boot before you updated it. So not necessarily surprising that an update helped. > and usb initialisation (which making a > generic kernel on main/14 fixes). For debug FreeBSD kernel, it takes both a modern enough kernel build vintage and an appropriate RPi* firmware vintage before USB booting and the like will work well. Neither is sufficient by itself, both are necessary. In other words: There has been more than one USB-support problem present recently for RPi4's, problems being from separate pieces of software. This makes it messier to track the issues. > [3] only thing tested on current/14 is booting and buildworld Sounds good. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)