Date: Thu, 8 Apr 2021 02:00:29 -0700 From: Mark Millard <marklmi@yahoo.com> To: Peter Cornelius <pcc@gmx.net> Cc: FreeBSD-arm@freebsd.org Subject: Re: JMicron jms561 umass on arm64? Message-ID: <A2E9C605-ABB3-40E3-931C-7FB10CDD0990@yahoo.com> In-Reply-To: <trinity-c3148d05-2413-4522-b67d-8be37f8c0dad-1617868014706@3c-app-gmx-bs02> References: <trinity-96292338-af50-4ea1-a4cf-0afcd97dfe35-1617806989816@3c-app-gmx-bs02> <20210407153732.GA50562@www.zefox.net> <trinity-2bcace35-09e8-4e81-87be-53287568c3c1-1617827433585@3c-app-gmx-bs02> <20210407211513.GA53438@www.zefox.net> <trinity-c3148d05-2413-4522-b67d-8be37f8c0dad-1617868014706@3c-app-gmx-bs02>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Apr-8, at 00:46, Peter Cornelius <pcc at gmx.net> wrote: > Thanks, Bob, >=20 >> I'll do a little top-posting to sidestep the HTML mess below.... >> [...] >> You'll likely get a wider readership of posts in plain text. >=20 > Sorry about that. My main box just broke and is in repair and the = bl**min' web GUI set HTML on *every single* message I send. I hope to = have found a permanent knob now, though. The stupid Aw: in the subject = line, and not reducing to a single Re: also is really embarrasing but = there seems to be no knob for that... sigh! Not used to consumer UIs any = more. >=20 >> usb reset >=20 > That cuts the branch I currently sit on (USB, HDMI). And does not show = anything ... but an error (gone now, rpi4 continues to boot when I pull = the keyboard off to type this). I'd love to boot (e. g. bootcmd_usb0) = from the disks but to do that, I'd have to get them on-line first, I = guess... >=20 > I also noted earlier, that, in my current setup, upon the first boot = after power-up, I have no means to interfere with the boot process at = all until FreeBSD was up at least once. Subsequent 'warm' reboots do = give me access to the boot prompts (u-boot, FreeBSD loaders). >=20 > I also was hoping that, once BSD's taking over, USB would be reset, = all devices found, etc. ... but looks like life's not that easy. I'll = dig further into U-Boot now as the root cause seems to live there... >=20 >> Since moving to a Pi4 (also running -current) I've had less trouble, >> so the Pi you're using seems to make a difference. >=20 > I have an RPI48GB with the current indicated below [3]. >=20 > Thanks again, and >=20 > All the best, >=20 > Peter. >=20 > --- >=20 > [1] I believe, = https://www.jmicron.com/file/download/1026/JMS561_Product+Brief.pdf > [2] https://wiki.radxa.com/Dual_Quad_SATA_HAT > [3] Note: Later builds so far have not booted despite of current = u-boot (March 2021) > FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #1: Tue Feb 23 = 02:30:31 UTC 2021 > root@rpi4:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 >=20 2021-Feb-23 in [3] predates the good RPi firmware build by a couple of days --and by the tagging of the good RPi firmware by some more days (Mar 3rd?). (The FreeBSD sysutils/rpi-firmware port tends to be bound to tagged versions sometime after the tag is placed.) As I remember it was 13.0-RC3 image that was the first 13.0-RC* to have the good RPI firmware: prior builds were bound to older sysutils/rpi-firmware versions that got older, badly-behaved RPi firmware relative to USB use. The time frame for main [14] snapshot images to start to have the good firmware overlapped with debug builds that paniced for internal FreeBSD problems. One should use later builds that have the new firwmware and the fixes to FreeBSD. The (first?) recent good RPi firmware version contains, for example, # strings start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) Prior to that build the the RPi firmware builds had bad behavior for some time. (The otherstart*.elf have the same day but varying build times.) I expect that until you have the above RPi firmware build in place on the firmware-boot-stage media, all other efforts are going to be messed up by the older firmware. (I've no clue if the RPi firmware is a sufficient fix by itself for your context even with a modern FreeBSD relateive to what was fixed, but the RPi firmware likely is a necessary part of the overall fix.) Note the lack of referencing u-boot in the above: so far as I know u-boot was working fine over the time that the RPi firmware was badly behaved, not that such was obvious at the time. It just did not need to be changed from what was officially built over the time frame. =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?A2E9C605-ABB3-40E3-931C-7FB10CDD0990>