Rock64, U-Boot 2024.01, and direct USB3 booting: part way there

U-Boot 2024.01 handles the USB3 port. This means I've
gotten the boot sequence to load the kernel from the
USB3 boot media.

The details:

U-Boot 2024.01 is on media that the internal code can
handle for finding, loading, and starting U-Boot. In
my context, this is a removable E.MMC device. Nothing
else on this device is needed. EFI/ must not be
present. dtb/ should(/must?) not be present.

The USB3 media I'm using looks like it could use a
usb_pgood_delay 2000 (or some such) but I've a powered
USB3 hub that tends to lead to avoiding such a setting
being required, and I'm using that so far.

The msdosfs is on the USB3 media and has the
EFI/BOOT/bootaa64.efi . It was copied from the
USF /boot/loader.efi .

The msdosfs also has a dtb/rockchip/rk3328-rock64.dtb
for U-Boot to find and use. It was copied over from
the UFS /boot/dtb/rockchip/rk3328-rock64.dtb .

(I ignore here also having materials for a RPi* boot.)

On plugging in power, the boot sequence finds, loads,
and starts the FreeBSD kernel based on the the UFS
file system on the USB3 media.

But it does not mount from ufs:/dev/ufs/rootfs .
boot -v reports the following. I unsure if the
"regulator: shutting down . . ." notices indicate
something has been disabled that would be needed.
There are no "Root mount waiting for:" notices.
There is a "Unresolved linked clock found: usb480m_phy"
notice.

. . .
usbus1: 480Mbps High Speed USB v2.0
usbus2: 480Mbps High Speed USB v2.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 5.0Gbps Super Speed USB v3.0
. . .
ugen4.1: <Synopsys XHCI root HUB> at usbus4
uhub3 on usbus4
uhub3: <Synopsys XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus4
. . .
Release APs...done
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
GEOM: new disk mmcsd0
TCP_ratelimit: Is now initialized
GEOM: new disk mmcsd0boot0
Unresolved linked clock found: hdmi_phy
GEOM: new disk mmcsd0boot1
Unresolved linked clock found: usb480m_phy
mmcsd0: Error indicated: 4 Failed
regulator: shutting down unused regulators
regulator: shutting down vcc_sd... busy
uhub1: 1 port with 1 removable, self powered
uhub3: 2 ports with 2 removable, self powered
uhub0: 1 port with 1 removable, self powered
uhub2: 1 port with 1 removable, self powered
ugen4.2: <vendor 0x05e3 product 0x0610> at usbus4
uhub4 on uhub3
uhub4: <vendor 0x05e3 product 0x0610, class 9/0, rev 2.10/92.10, addr 1> on usbus4
uhub4: MTT enabled
uhub4: 4 ports with 1 removable, self powered
ugen4.3: <vendor 0x05e3 product 0x0616> at usbus4
uhub5 on uhub3
uhub5: <vendor 0x05e3 product 0x0616, class 9/0, rev 3.00/92.10, addr 2> on usbus4
uhub5: 4 ports with 1 removable, self powered
ugen4.4: <OWC Envoy Pro mini> at usbus4
umass0 on uhub5
umass0: <OWC Envoy Pro mini, class 0/0, rev 3.00/1.00, addr 3> on usbus4
umass0:0:0: Attached to scbus0
pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0
pass0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
pass0: Serial Number REDACTED
pass0: 400.000MB/s transfers
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REDACTED
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
da0: Delete methods: <NONE(*),ZERO>

And there is no more output.

The same media boots the RPi4B tried just fine.
Via an EDK2 microsd card also being involved, it
boots the RPi5 just fine as well.

===
Mark Millard
marklmi at yahoo.com