Date: Tue, 16 Mar 2021 15:22:10 -0700 From: Mark Millard <marklmi@yahoo.com> To: tech-lists <tech-lists@zyxst.net> Cc: freebsd-arm@freebsd.org Subject: Re: rpi4b main-n245392-8423f5d4c12 won't boot due to microsd timeout [FIXED] Message-ID: <548DA04C-8CF0-4898-9C9A-423B8A400AE5@yahoo.com> In-Reply-To: <YFDgUMrSv1uHkx6A@ceres.zyxst.net> References: <A2A5B0EA-3BEA-4721-9E65-83D4FBF56724.ref@yahoo.com> <A2A5B0EA-3BEA-4721-9E65-83D4FBF56724@yahoo.com> <YE%2BY4HsI5KxfTLxG@ceres.zyxst.net> <79EB88DA-0144-4A12-B716-3CF5011F16C4@yahoo.com> <YFDgUMrSv1uHkx6A@ceres.zyxst.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-16, at 09:44, tech-lists <tech-lists at zyxst.net> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?548DA04C-8CF0-4898-9C9A-423B8A400AE5>