Date: Wed, 7 Dec 2022 12:52:08 -0800 From: Mark Millard <marklmi@yahoo.com> To: adr <adr@SDF.ORG> Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD on RPI4 B 8G rev 1.4 Message-ID: <35EF99CB-ECA2-4F93-9CC3-6528820321D5@yahoo.com> In-Reply-To: <5f1ba830-60e-407d-c09f-d75ab0946ca6@SDF.ORG> References: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG> <047DB634-2D87-402D-A65C-A4F517E042BD@yahoo.com> <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG> <5f1ba830-60e-407d-c09f-d75ab0946ca6@SDF.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 7, 2022, at 11:21, adr <adr@SDF.ORG> wrote: > On Tue, 6 Dec 2022, adr wrote: >> Yes, I could be more specific. When I said "the only way >> I can run..." I mean the official images don't even boot. >> >> The errors differ but they were related to xhci I think. I'll make >> some test with the u-boot in ports, but after reading your experience >> with other rev 1.4 boards I wonder if this could be related with >> the eeprom firmware, if this is even possible. > > It was a usb hub with sd card reader. There was no card there, > u-boot choked trying to read it. Yes, how silly of me. FYI: U-Boot has problems with individual USB devices (one USB port in use) that have multiple LUN's in the device that are populated with storage media. Having media in more than one slot of a multi-media reader is an example. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256441 . It has the subject: U-Boot build for Raspberry Pi 3B and 4B (arm64) does not boot from MicroSD card slot when >1 USB storage devices are present The issue has been demonstrated on Linux systems that use U-Boot as well. It is not FreeBSD specific at all. Similarly, I've demonstrated it on both RPi4B's and a Rock64: not platoform specific either. It appears to just be a property of how U-Boot works things days. Another earlier example was reported in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253983 Subject: RPI4 boot fails when geekworm x829 is attached over USB (Mistakenly classified as "closed fixed"). This was not a multimedia reader type of context but still involved the multiple storage media via one USB port kind of context, so LUN's involved. It was Comment #42 before I'd managed to duplicate the problem (via finally trying a multi-media reader with multiple storage media plugged in). > I would appreciate if someone share his/her experience with 13.1 > release, stable and current. It's there any advantage of using > stable|current at this moment? One big issue is how much self-support and tracking of status of a branch is reasonable for you? Is doing your own builds from source and installs of them reasonable? Is the time for building from source going to be tolerable, including when large time-consuming subsets or full rebuilds are needed? It is messy to update an existing install from a snapshot or from artifacts.ci materials (the only forms of prebuilt stable/13 or main [so: 14] material available). These are normally build-from-source and install-update for updating once the initial install is in place. No builds are required for progressing from 13.1-RELEASE to 13.1-RELEASE-p?? and eventually to 13.2-RELEASE and the like. Without having a clue what the range of intended usage is, I'm not sure what other aspects would always be significantly involved in driving the choice of which to use. My context is rather limited in its range of use, so I'm not likely to have as much to contribute as various other folks. For reference, for weekly snapshots and for artificat.ci snapshots there are: http://ftp.freebsd.org/pub/FreeBSD/snapshots/arm64/ and: https://artifact.ci.freebsd.org/snapshot/ === Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35EF99CB-ECA2-4F93-9CC3-6528820321D5>