Booting 8 GiByte RPi4 with even UEFI coming from the USB3 SSD (that has GPT partitioning)

[Mark Millard]

[I mostly ignore here the issue of occasional 4K
blocks transfers to USB being garbage. (That was
in earlier list submittals.)  Similarly for lack
of access to the built-in Ethernet and the lack
of microsd card access. These were all originally
found via a 4 GiByte RPi4 and likely apply here.]


I was able to boot an 8 GiByte RPi4 with UEFI on the
USB3 SSD that also holds the root UFS, instead of
it being on the microsd card in the slot. The same
is true for the 4 GiByte RPi4 (v1.1). In part I had
to use the 4 GiByte one for part of setting things
up.


Context:

The RPi4's involved have the stable (not beta)
USB-MSB rpi-eeprom update and associated modern
firmware. UEFI's RPI_EFI.fd from, e.g., v1.16 .


Note about the microsd card slot content:

I used a microsd card with an empty msdosfs
on it (no UEFI even). This is because I found
that the UEFI v1.16 and before code gets
stuck in a loop when the slot is empty, doing
what the debug RPI_EFI.fd reports as a
indefinitely repeating sequence of 3 messages:

Card should be MMC
MMCSendCommand(371): MMC_CMD1 ERRI MmcStatus 0x18040
MMCSendCommand(371): MMC_CMD55 ERRI MmcStatus 0x18040

Apparently the card detect pin is not wired up
on the RPi4's and that complicates things and
the complication is not handled yet.

True of both RPi4's.


Note about setting Serial instead of Graphical and
setting to disable the 3 GiByte limit:

Attempts to set these based on using the 8 GiByte RPi4
failed to update the UEFI settings. It worked fine
using the 4 GiByte RPi4. And, after that, the 8 GiByte
RPi4 used the saved settings just fine (same media
used on both RPi4's).


How some things look for what I've done:

# vmstat
 procs    memory    page                      disks     faults       cpu
 r  b  w  avm  fre  flt  re  pi  po   fr   sr da0 pa0   in   sy   cs us sy id
 0  0  0 248M 7.6G 3.5K   0  18   0 4.0K    2   0   0 1997 3.1K 3.5K  1  2 97

# gpart show -p
=>       40  468862048    da0  GPT  (224G)
         40       2008         - free -  (1.0M)
       2048  413138944  da0p1  freebsd-ufs  (197G)
  413140992    9437184  da0p2  freebsd-swap  (4.5G)
  422578176     204800  da0p3  ms-basic-data  (100M)
  422782976   46079112         - free -  (22G)

# df -m
Filesystem             1M-blocks  Used  Avail Capacity  Mounted on
/dev/gpt/Rock64root       195378 57896 121852    32%    /
devfs                          0     0      0   100%    /dev
/dev/msdosfs/RPI4EFIFS        99     7     92     7%    /usb_efi

# find /usb_efi/ -print | sort
/usb_efi/
/usb_efi/EFI
/usb_efi/EFI/BOOT
/usb_efi/EFI/BOOT/BOOTAA64.EFI
/usb_efi/OVERLAYS
/usb_efi/OVERLAYS/disable-bt.dtbo
/usb_efi/OVERLAYS/miniuart-bt.dtbo
/usb_efi/RPI_EFI.fd
/usb_efi/Readme.md
/usb_efi/bcm2711-rpi-4-b.dtb
/usb_efi/config.txt
/usb_efi/fixup4.dat
/usb_efi/start4.elf

# more /usb_efi/config.txt
arm_64bit=1
enable_uart=1
uart_2ndstage=1
enable_gic=1
armstub=RPI_EFI.fd
disable_commandline_tags=1
disable_overscan=1
device_tree_address=0x1f0000
device_tree_end=0x200000
dtoverlay=disable-bt
over_voltage=6
arm_freq=2000


I've not done anything significant for testing because
of the already-known "some 4K blocks of garbage" issue
in file I/O to the USB3 SSD.

I'll note that the same USB3 SSD is used to boot and
operate a Rock64 and the Rock64 does not have the I/O
problems.

I will note that I've not found block-corruption
issues so far on NetBSD booted via UEFI, same RPi4's,
same type of USB3 SSD. The problem looks to be FreeBSD
specific.

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