Date: Fri, 9 Apr 2021 12:47:50 -0700 From: Mark Millard <marklmi@yahoo.com> To: Peter Cornelius <pcc@gmx.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: JMicron jms561 umass on arm64? Message-ID: <AFC94E42-7BE0-422D-8A2E-62745BD0A4E9@yahoo.com> In-Reply-To: <trinity-17aa86d8-be8c-434e-9815-443ce0ce0d54-1617993216878@3c-app-gmx-bs30> 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> <5099D78C-6656-4E4A-9F20-23F31A4397FE@yahoo.com> <trinity-17aa86d8-be8c-434e-9815-443ce0ce0d54-1617993216878@3c-app-gmx-bs30>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Apr-9, at 11:33, Peter Cornelius <pcc at gmx.net> wrote:
Thank you, Mark,
>> 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.
>=20
> I apologize for not having been precise in my elaborations. I now =
understand that
>=20
> Power-on of the RPI
> loads EEPROM
> loads Firmware rpi-firmware-1.20210303.g20210303
> loads U-Boot u-boot-rpi4-2020.10 (config.txt says =
kernel=3Du-boot.bin)
loads EFI/BOOT/bootaa64.efi (a copy of FreeBSD's loader.efi)
loads FreeBSD's kernel
loads other parts of FreeBSD. (I'll stop with this.)
Also, these days there is sysutils/u-boot-arm64 that is
used for official microsd card images instead of
sysutils/u-boot-rpi4 . (There are some detailed differences
in the u-boot configurations but u-boot-arm64 deals with
RPi4 and RPi3 and RPi2 V1.2 used as aarch64.)
> loads "FreeBSD" [3]
>=20
> And each of them may or may not be able to properly provide access to =
USB. In any case, FreeBSD [3] does start, and does detect USB devices, =
so I'm happy this far.
>=20
> Returning to my initial issue, what puzzles me is that I do not seem =
to be able to see the hat [2] at all
Have you stopped the boot in u-boot and looked around to see if
u-boot sees the SATA drives via the USB3/hat? There is:
QUOTE
U-Boot 2020.10 (Dec 13 2020 - 08:04:27 +0000)
DRAM: 7.9 GiB
RPI 4 Model B (0xd03114)
MMC: mmc@7e300000: 1, emmc2@7e340000: 0
Loading Environment from FAT... In: serial
Out: serial
Err: serial
Net: eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 3 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot: 2 =08=08=08 1 =08=08=08 0=20
END QUOTE
The "2 1 0" does not give much time to stop the autoboot.
There is a help command that reports the
first words of command with a one-line
description:
Hit any key to stop autoboot: 0=20
U-Boot> help
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
blkcache - block cache diagnostics and control
boot - boot default, i.e., run 'bootcmd'
. . .
Typing just a first word tends to report more
help:
U-Boot> usb
usb - USB sub-system
Usage:
usb start - start (scan) USB controller
usb reset - reset (rescan) USB controller
usb stop [f] - stop USB [f]=3Dforce stop
usb tree - show USB device tree
usb info [dev] - show available USB devices
usb test [dev] [port] [mode] - set USB 2.0 test mode
(specify port 0 to indicate the device's upstream port)
Available modes: J, K, S[E0_NAK], P[acket], F[orce_Enable]
usb storage - show details of USB storage devices
usb dev [dev] - show or set current USB storage device
usb part [dev] - print partition table of one or all USB storage =
devices
usb read addr blk# cnt - read `cnt' blocks starting at block `blk#'
to memory address `addr'
usb write addr blk# cnt - write `cnt' blocks starting at block `blk#'
from memory address `addr'
U-Boot>=20
My understanding is that EFI/BOOT/bootaa64.efi gets
its usb device information from the u-boot, not on its
own.
Is is the case that the FreeBSD kernel can get access to
devices that u-boot and EFI/BOOT/bootaa64.efi do not
provide. In some system's that do not boot from just
USB I've loaded the FreeBSD kernel from microsd card
media but had that kernel then use the USB device for
the rest of the stages, not needing to keep the
microsd card in place even.
However, a device not noticed by FreeBSD kernel at all
is still a possibility.
> while
> (a) Raspbian did see it (and the disks, so I understand that the hat =
is in order),
> (b) There are reports that the JMS561 [1] should be detected also by =
FreeBSD, and
> (c) FreeBSD does detect any other USB device I I can find and hook up =
to either one of the USB3 ports (indicating that the RPI is fine).
>=20
> In short, my expectation (hope?) was that I hook up the board and =
proceed with the disks, or at least be able to re-set the bus so that it =
finds at least a ugen device to build upon, but as-is, no trace of any =
device... I'm a bit lost and would appreciate any pointers.
I'm a little familiar with how to look around in
u-boot (using help). But I'm not familiar overall
with all the stages and issues involved in tracking
down what it takes to enable devices that are not
showing up.
I will note that one thing that was discovered was
that u-boot does not well support having a USB device
with more than one storage LUN in the device. It
produces messages like:
Scanning disk usb_mass_storage.lun1...
** Unrecognized filesystem type **
** Unrecognized filesystem type **
Scanning disk usb_mass_storage.lun3...
ERROR: failure to add disk device usb_mass_storage.lun3, r =3D 20
Error: Cannot initialize UEFI sub-system, r =3D 20
2676208 bytes read in 41 ms (62.2 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Error: Cannot initialize UEFI sub-system, r =3D 20
EFI LOAD FAILED: continuing...
BOOTP broadcast 1
DHCP client bound to address 192.168.1.171 (121 ms)
*** ERROR: `serverip' not set
(Text is actually from a test that Fedora's configuration
at the time was getting the same sort of problem from its
u-boot build. The text just happened to be handy to grab.)
It seemed that such a device needed to be plugged in after
u-boot was no longer involved (and to be unplugged before
u-boot would again be involved).
I mention this because having multiple SATA drives possible
might be an example of multiple storage LUNs for a single
USB device. There is:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253983
that starts before the u-boot tie was known and progresses
through it being discovered --and that mistakenly indicates
"Closed FIXED" to indicate that it was not a FreeBSD
problem. (No problem was "fixed": just isolated to not
be FreeBSD's problem.)
> 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 =
Firmware/Das 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
Given recent FreeBSD kernel problems that have been addressed
for USB (at least for debug builds), why still back on a 2021-Feb-23
kernel? Have you tried a modern snapshot of main [14] and/or 13.0-R
to see if the SATA drives show up? At this point basic experiments
are probably better done on rather modern FreeBSD builds (but
before the hanging-processes mess from main d36d68161517 ).
> [4] =
https://jamesachambers.com/raspberry-pi-4-bootloader-firmware-updating-rec=
overy-guide/
> [5] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252971
=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?AFC94E42-7BE0-422D-8A2E-62745BD0A4E9>