Date: Thu, 8 Apr 2021 13:02:26 -0700 From: Mark Millard <marklmi@yahoo.com> To: Peter Cornelius <pcc@gmx.net> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: JMicron jms561 umass on arm64? Message-ID: <5099D78C-6656-4E4A-9F20-23F31A4397FE@yahoo.com> In-Reply-To: <trinity-93090f7c-f2f9-4cec-8b27-1af7de718f7a-1617905889857@3c-app-gmx-bs32> 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> <A2E9C605-ABB3-40E3-931C-7FB10CDD0990@yahoo.com> <20210408150934.GA99223@www.zefox.net> <694B7C84-E627-4E17-9148-4C4BB54FAD17@yahoo.com> <trinity-93090f7c-f2f9-4cec-8b27-1af7de718f7a-1617905889857@3c-app-gmx-bs32>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Apr-8, at 11:18, Peter Cornelius <pcc at gmx.net> wrote: > Thank you, Mark and Bob, >=20 >>>> 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.) >>>>=20 >>>=20 >>> I forgot to mention that before initially booting FreeBSD on >>> my Pi4B I booted it with RasPiOS and ran sudo apt update/upgrade. >>> That likely fixed the firmware on the Pi without intelligent >>> intervention. >>=20 >> How would booting RasPiOS via RasPiOS media and running >> apt update/upgrade automatically update the firmware that >> is on the FreeBSD media, files like start4.elf on the >> msdos file system on FreeBSD boot media? >>=20 >> I was not writing of things like the eepprom update that >> enables USB booting on older RPi*'s that did not support >> such initially. I explicitly mentioned start4.elf and >> "firmware-boot-stage media". >>=20 >> Unless there were more steps than described, I doubt the >> activity updated what I was refering to. >=20 > I think we may have some confusion here. There was some sort of EEPROM = firmware upgrade [4] which I also did last round Raspbian was up (either = Jan 11 or Feb 16). I also had to do that last year (August?) in order to = make the RPI4 boot FreeBSD at all. I think the EEPROM upgrade tool is = too Linuxish and does not run under FreeBSD (at least I failed). I'll note that the official eeprom versions for USB are are: ( see = https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware/critical = ) (The newer names "default" and "latest" were handled via adding symbolic links to the old directory names. But the RPi folks have been frequently using the newer terminology after getting tired of confusions from the old terminology.) default (historically a.k.a. critical): pieeprom-2020-09-03.bin with vl805-000138a1.bin and those work in the RPi4B's that I have access to: it is what I'm using in all of them. latest (historically a.k.a. stable): pieeprom-2020-09-03.bin with vl805-000138a1.bin (both matching the = above) pieeprom-2020-12-11.bin with vl805-000138a1.bin pieeprom-2021-01-11.bin with vl805-000138a1.bin pieeprom-2021-01-16.bin with vl805-000138a1.bin pieeprom-2021-02-16.bin with vl805-000138a1.bin pieeprom-2021-03-18.bin with vl805-000138a1.bin However, various of those have problems and none has reached a status of being classified as a recommended "default". More recent ones tend to, in part, fix parts of earlier ones from the list but may introduce other issues. Unless one has specific evidence to the contrary for their context, I'd recommend: pieeprom-2020-09-03.bin with vl805-000138a1.bin (i.e., the most recent default/critical files as things are now). >> Unless you go back far enough into last year, the >> RPi* firmware needs to that vintage that has: >>=20 >> # 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) >=20 > I am aware of bug 252971 [5] and can confirm that I do have this = version. On the media that had a 2021-Feb-23 FreeBSD kernel build? (I'm not sure of the kernel's status back then.) > Actually built on March 3 this year. Before that, I had to go back to = some September? October? U-Boot I think that u-boot is being confused with other things here . . . The commit-hook notices in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252971 go like follows . . . comments #16 and #17 are not for any sysutils/u-boot-* but for sysutils/rpi-firmware . Comments #26 and #29 and #30 are for FreeBSD's kernel, not u-boot. Comments #31 and #32 and #33 are for sysutils/rpi-firmware again, not u-boot. There are no commit-hook notices relative to u-boot at all. I'll note that comments #31 and #32 and #33 are the ones for for update that switched sysutils/rpi-firmware to the RPi* firmware build with date: VC_BUILD_ID_TIME: Feb 25 2021 (This is not u-boot at all.) The RPi folks tagged that build as 20210303. (They do not tag based on the build-date but based on something like the date it was "approved as to-be-tagged".) > to get the box back up running with USB (such as to use my USB = keyboard & mouse, for instance). I see no evidence that u-boot changes were involved. If specific u-boot changes (vs. sysutils/u-boot-*) vintages being stable can be identified, I'd like to be able to identify them. (There is one known issue for u-boot, in that it does not correctly/fully handle a USB device that has multiple storage LUNs in the device. That is still true as far as I know. There was some investigation of this during the isolation of combination of things worked. That is how we discovered that it was a u-boot issue.) > I just connected a USB3 hub with a USB2 memstick and a USB3 disk to = the USB3 hub of the RPI4, and both storage devices are detected = immediately on either USB3 port of the RPI4. >=20 > Which gives me a sensation of looking in the wrong spot... >=20 > Thanks again, and >=20 > All the best, >=20 > Peter. >=20 > [4] = https://jamesachambers.com/raspberry-pi-4-bootloader-firmware-updating-rec= overy-guide/ > [5] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252971 The RPi* situation was confusing enough, with multiple problems in multiple sets of firmware/kernels and combinations. I'm trying to not leave a fuzzy identification of what releases were at issue and what modern combinations are known to generally work. Folks have already spent enough time on bad combinations of materials in recent months. =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?5099D78C-6656-4E4A-9F20-23F31A4397FE>