Re: Raspberry Pi 4 and M.2 SATA SSD recognized but not booting or available for install - unsupported interface

On Apr 11, 2024, at 06:40, Johan Helsingius <julf@Julf.com> wrote:

> I got an Aron One M.2 enclosure for the RPi 4 that includes
> a M.2 SATA SSD slot. I want to install freebsd 14, but when I
> boot from a microSD card image or USB stick,   bsdinstall
> doesn't allow me to install on the SSD, and trying to manually
> partition and install I can't get the RPi to boot from it, despite
> the fact that the USB stick image recognizes the SSD.

As far as I know, bsdinstall does nothing for U-Boot materials for
any system that requires such. That is always additional activity.

But for the aarch64 RPi*'s (RPi5 not covered here), it also does
not deal with any of the following. I'll ignore armv7 details here.

The RPi* firmware that goes in the msdosfs (EFI) file system:
( *.dtb config.txt fixup*.dat overlays/* start*.elf )
( sysutils/rpi-firmware supplies those in
  /usr/local/share/rpi-firmware/ )
( The RPi4B does not use bootcode.bin but that is another firmware
  files. )

Also:
armstub8-gic.bin
armstub8.bin
( sysutils/rpi-firmware bundles those two, although they are not
  rpi* firmware )

And:
u-boot.bin
( sysutils/u-boot-rpi-arm64 supplies that in
  /usr/local/share/u-boot/u-boot-rpi-arm64/ )

None of that material is part of FreeBSD but is required anyway.
The appropriate files need to be appropriately copied to the
msdosfs (EFI) file system that the RPi firmware is to use.

FreeBSD does supply a loader.efi that is part of FreeBSD. But,
again, it is not automatically copied to be the likes of:

EFI/BOOT/bootaa64.efi

in a msdosfs (EFI) file system. There should be only one
EFI/BOOT/bootaa64.efi for booting and it should be on the
same media as the FreeBSD to be booted. u-boot.bin will
load and start the first it finds. For single-media booting,
there normally is only one msdosfs (EFI) file system that
has all the above materials.

The config.txt may need the likes of the following added:

#
# Local addition that avoids USB3 SSD boot failures that look like:
#   uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT
#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ?
# WARNING, not sufficient for "boot -s": that needs the full force_turbo=1
initial_turbo=60

Having a serial console setup greatly helps having evidence of how far
things got and what was reported for partial boots that fail (once you
get that far).

I'll note that it seems likely that most folks do not use bsdinstall
at all, instead starting with a snapshot or release image. (I'm not
claiming that you should do so: I do not know your context.)

> Here is the relevant dmesg output:
> 
> # dmesg | grep da1
> da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
> da1: <Argon Forty 0> Fixed Direct Access SPC-4 SCSI device
> da1: Serial Number 0000000000E4
> da1: 400.000MB/s transfers
> da1: 457862MB (937703088 512 byte sectors)
> da1: quirks=0x2<NO_6_BYTE>
> 
> da0 is the USB stick:
> 
> # dmesg | grep da1
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0: <SanDisk U3 Cruzer Micro 8.02> Removable Direct Access SCSI device
> da0: Serial Number 0877601B45D25B94
> da0: 40.000MB/s transfers
> da0: 15283MB (31301631 512 byte sectors)
> da0: quirks=0x2<NO_6_BYTE>
> 
> I would understand the SSD not being recognized at all...
> 
> Any advice/hints?
> 

Output from the likes of:

# gpart show
# gpart show -pl

? It is not even clear which you are using of GPT vs. MBR.


===
Mark Millard
marklmi at yahoo.com