Date: Tue, 23 Jun 2020 23:53:49 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Booting 8 GiByte RPi4 with even UEFI coming from the USB3 SSD (that has GPT partitioning) Message-ID: <B07E873D-E656-45C8-9378-F69845989972@yahoo.com> References: <B07E873D-E656-45C8-9378-F69845989972.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B07E873D-E656-45C8-9378-F69845989972>