JMicron jms561 umass on arm64?

Thu Apr 8 20:02:34 UTC 2021

On 2021-Apr-8, at 11:18, Peter Cornelius <pcc at gmx.net> wrote:

> Thank you, Mark and Bob,
> 
>>>> 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.)
>>>> 
>>> 
>>> 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.
>> 
>> 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?
>> 
>> 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".
>> 
>> Unless there were more steps than described, I doubt the
>> activity updated what I was refering to.
> 
> 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:
>> 
>> # 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)
> 
> 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=252971

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.
> 
> Which gives me a sensation of looking in the wrong spot...
> 
> Thanks again, and
> 
> All the best,
> 
> Peter.
> 
> [4] https://jamesachambers.com/raspberry-pi-4-bootloader-firmware-updating-recovery-guide/
> [5] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252971

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.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)