Boot from USB on RPi4 8GB?

Discussion:

Mark Millard via freebsd-arm

2021-05-30 08:55:29 UTC

Is there any documentation or a howto in order to get FreeBSD to boot from a USB3 disk on the RPi4 8GB? I dd'd the latest 13.0-RELEASE image (FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img) to the USB3 SSD, but it does not boot. (The same image works just fine when written to the sdcard.) It looks like it's unable to locate the USB disk and then gets stuck in a loop trying for network boot. When I get to U-Boot prompt, it says there are no USB storage devices. If I issue "usb start", there are still no devices.

(I assume no microsd card was in the microsd card slot.)

I've not seen or heard of that U-Boot report before.
But you made it to U-Boot so the RPi4B firmware
worked for getting U-Boot from the USB3 drive.

This suggests the U-Boot stage is having the problem.

So I've no specific solutions, not having seen the
kind of report before. I've just more generic notes
and questions.

[I'll note that I've had no problem with USB3 SSD
booting the RPi4B's that I have access to (no
microsd card involved).]

One test is to use the microsd card that boots
via the microsd card slot and instead put it in
a USB3 microsd card reader, plug the reader into
a USB3 port, and try to boot from just that.

If that boots, then there would seem to be some
device incompatibility with your specific USB3
"boot" drive. If, instead, booting via the reader
fails, then things are rather odd. (See later
notes about SOC vintages.)

# rpi-eeprom-update
BOOTLOADER: up to date
CURRENT: Thu 29 Apr 16:11:25 UTC 2021 (1619712685)
LATEST: Thu 29 Apr 16:11:25 UTC 2021 (1619712685)
RELEASE: stable (/lib/firmware/raspberrypi/bootloader/stable)
Use raspi-config to change the release.
VL805_FW: Using bootloader EEPROM
VL805: up to date
CURRENT: 000138a1
LATEST: 000138a1

Since you got to U-Boot the RPI4B's bootloader worked.
The above is what I currently use in the RPi4B's,
8 GiBYte and 4 GiByte ones.

If I dd Raspberry Pi OS (2021-05-07-raspios-buster-armhf-lite.img) to the same disk, it boots up no problem. I'm thinking this is a U-Boot/rpi-firmware problem, but I don't really know where to begin.

FYI: if you ever want to use both a 64-bit kernel and
a 64-bit user space, there are BETA's of such (Debian
Buster based):

https://downloads.raspberrypi.org/raspios_lite_arm64/images/
https://downloads.raspberrypi.org/raspios_arm64/images/

(I'm not claiming any gain from such for the problem at hand.)

I tried building my own image using crochet,

https://wiki.freebsd.org/arm/ reports about crochet:

"Alternatively, images for many boards can be built by crochet (deprecated) or using FreeBSD's release build infrastructure."

There were no commits at https://github.com/freebsd/crochet
between 2019-Oct-06 and 2021-Apr-23. But there are some
on 2021-Apr-24.

I do my own builds based on using make commands but I do
not use the release scripts for building. I build for a
variety of systems.

but that didn't work either.
I'm also not sure whether I should be using sysutils/u-boot-rpi4 (I used this) or sysutils/u-boot-rpi-arm64?

Either should generally work. (But see later notes
about RPi4B SOC vintages.)

FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img was based on
sysutils/u-boot-rpi-arm64 . I've historically built and
used a variant of sysutils/u-boot-rpi4 but my history
goes back before sysutils/u-boot-rpi-arm64 existed. I
do not do anything were the configuration variations
involved matter so I'm not familiar with the distinctions.

I've used both a previous 2020.10 based U-Boot and a
more recent 2021.04 based U-Boot.

After installing sysutils/rpi-firmware (1.20210303.g20210303), should I just copy /usr/local/share/rpi-firmware/* to the boot partition and rename config_rpi4.txt to config.txt?

I assume you mean the msdos file system partition when
you reference "boot partition". The msdos file system
needs to contain:

A) copies of /usr/local/share/rpi-firmware/* materials,
using config_rpi4.txt content as the config.txt
content. The copy should be recursive, to pick up
the likes of the overlay/ subdirectory tree.

B) a copy of an appropriate u-boot.bin ( from
/usr/local/share/u-boot/u-boot-rpi-arm64/ or
/usr/local/share/u-boot/u-boot-rpi4/ ).
(See later notes as well.)

C) A copy of /boot/loader.efi (the FreeBSD loader)
placed at/as efi/boot/bootaa64.efi in teh msdos
file system.

I use a USB3 SSD that has small enough power requirements
to not require a powered hub. (I also use a 5.1V 3.5A
power supply as part of that context.) I've never tried
spinning rust or higher powered USB3 media.

It is unclear what the dd command details were like for
the transfer to the USB3 media. So I just assume that
it was okay.

You may want to have an empty file named timeout in
the msdos file system. It allows for extra time.
(I doubt it helps, since U-Boot did load and start.)

What does:

# rpi-eeprom-config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41

report in your context? (An equivalent command is
"vcgencmd bootloader_config". I show example output
above.)

Can you see the top of the SOC? Or is there a
heatsink or some such on it? (There is something
there to read if it can be seen.)

One possibility is that you have newer hardware that
the normal U-Boot vintages that FreeBSD has used do
not handle.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080
is about someone that instead of having only:

QUOTE
Old Pi has the following identifying marks on the SOC package:
BROADCOM
2711ZPKFSB06BOT
TE1919
045-23 B3 W
END QUOTE

the person also had an example of a 2 GiByte:

QUOTE
New Pi has the following identifying marks on the SOC package:
BROADCOM
2711ZPKFSB06C0T
TA2105
054-05 B3 W
END QUOTE

The:

2711ZPKFSB06BOT
vs.
2711ZPKFSB06C0T

is significant. If you have a 8GiByte "C0T" RPi4B it
would be the first known example. In such a case, you
might want to try the u-boot referenced in Comment 15 of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080 .
It got the 2 GiByte "C0T" to boot. (But that context
could not even boot via the microsd card slot with the
normal media content from 13.0-RELEASE .)

I do not know if the 2021.04 U-Boot that the since
updated port now provides would work for this context
or not. I've no access to any "C0T" RPi4B's (or any
Pi400's or CM4's).

There is a category of USB device that U-Boot still does
not support as far as I know: those where the one device
has multiple storage LUNs (instead of just one Logical
Unit Number identifying storage).

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253983
is about such a context, where we eventially figured out
the "multiple storage LUN" issue.

But the error messages from the U-Boot of the time was
not what you report.

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

William Carson via freebsd-arm

2021-05-30 17:59:52 UTC

Permalink

Thank you for the quick and thorough reply!

Post by Mark Millard via freebsd-arm

(I assume no microsd card was in the microsd card slot.)

Correct.

Post by Mark Millard via freebsd-arm
I've not seen or heard of that U-Boot report before.
But you made it to U-Boot so the RPi4B firmware
worked for getting U-Boot from the USB3 drive.
This suggests the U-Boot stage is having the problem.
So I've no specific solutions, not having seen the
kind of report before. I've just more generic notes
and questions.
[I'll note that I've had no problem with USB3 SSD
booting the RPi4B's that I have access to (no
microsd card involved).]

I'm trying to use a SAMSUNG (MZ-V7E500BW) 970 EVO SSD 500GB - M.2 NVMe, attached via the Geekworm X872 M.2 NVMe 2280/2260/2242/2230 SSD Expansion Board.

Post by Mark Millard via freebsd-arm
One test is to use the microsd card that boots
via the microsd card slot and instead put it in
a USB3 microsd card reader, plug the reader into
a USB3 port, and try to boot from just that.

Hmm, this worked just fine.

Post by Mark Millard via freebsd-arm
If that boots, then there would seem to be some
device incompatibility with your specific USB3
"boot" drive. If, instead, booting via the reader
fails, then things are rather odd. (See later
notes about SOC vintages.)

Since you got to U-Boot the RPI4B's bootloader worked.
The above is what I currently use in the RPi4B's,
8 GiBYte and 4 GiByte ones.

FYI: if you ever want to use both a 64-bit kernel and
a 64-bit user space, there are BETA's of such (Debian
https://downloads.raspberrypi.org/raspios_lite_arm64/images/
https://downloads.raspberrypi.org/raspios_arm64/images/
(I'm not claiming any gain from such for the problem at hand.)

I tried building my own image using crochet,

"Alternatively, images for many boards can be built by crochet (deprecated) or using FreeBSD's release build infrastructure."
There were no commits at https://github.com/freebsd/crochet
between 2019-Oct-06 and 2021-Apr-23. But there are some
on 2021-Apr-24.

Yes, this is very disappointing, but I was able to copy the board/RaspberryPi3 and modify it to use the appropriate ports/firmware files. I used a similar process for my ROCKPRO64 and Khadas EDGE-V boards and they both worked. I'm happy to confine my testing to an official FreeBSD image if it makes things easier to troubleshoot :)

Post by Mark Millard via freebsd-arm
I do my own builds based on using make commands but I do
not use the release scripts for building. I build for a
variety of systems.

but that didn't work either.
I'm also not sure whether I should be using sysutils/u-boot-rpi4 (I used this) or sysutils/u-boot-rpi-arm64?

Either should generally work. (But see later notes
about RPi4B SOC vintages.)
FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img was based on
sysutils/u-boot-rpi-arm64 . I've historically built and
used a variant of sysutils/u-boot-rpi4 but my history
goes back before sysutils/u-boot-rpi-arm64 existed. I
do not do anything were the configuration variations
involved matter so I'm not familiar with the distinctions.
I've used both a previous 2020.10 based U-Boot and a
more recent 2021.04 based U-Boot.

After installing sysutils/rpi-firmware (1.20210303.g20210303), should I just copy /usr/local/share/rpi-firmware/* to the boot partition and rename config_rpi4.txt to config.txt?

I assume you mean the msdos file system partition when
you reference "boot partition". The msdos file system
A) copies of /usr/local/share/rpi-firmware/* materials,
using config_rpi4.txt content as the config.txt
content. The copy should be recursive, to pick up
the likes of the overlay/ subdirectory tree.
B) a copy of an appropriate u-boot.bin ( from
/usr/local/share/u-boot/u-boot-rpi-arm64/ or
/usr/local/share/u-boot/u-boot-rpi4/ ).
(See later notes as well.)
C) A copy of /boot/loader.efi (the FreeBSD loader)
placed at/as efi/boot/bootaa64.efi in teh msdos
file system.
I use a USB3 SSD that has small enough power requirements
to not require a powered hub. (I also use a 5.1V 3.5A
power supply as part of that context.) I've never tried
spinning rust or higher powered USB3 media.

I can confirm those are the steps I followed. I'm not sure what's considered "high powered" but the Samsung tech specs say this particular model uses 5.7 W on average and 10.0 W maximum. But it does seem curious that the Raspberry PI OS will boot this disk without issue, so I don't think it's the drive. I also tried a Samsung 950 PRO using a different enclosure (QNINE NVME Enclosure, M.2 PCIe SSD (M Key) to USB 3.0 External Case), but it behaved the same.

Post by Mark Millard via freebsd-arm
It is unclear what the dd command details were like for
the transfer to the USB3 media. So I just assume that
it was okay.
You may want to have an empty file named timeout in
the msdos file system. It allows for extra time.
(I doubt it helps, since U-Boot did load and start.)

Correct - the empty timeout file did not help. However I was able to capture the beginning of the boot process:

"scanning bus xhci_pci for devices... Device NOT ready
Request Sense returned 02 04 01
3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
Card did not respond to voltage select! : -110

Device 0: unknown device
***@7d580000 Waiting for PHY auto negotiation to complete.."

(This was with the USB3 disk attached and no sdcard in the slot; no ethernet attached either.)

Post by Mark Millard via freebsd-arm
# rpi-eeprom-config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41
report in your context? (An equivalent command is
"vcgencmd bootloader_config". I show example output
above.)

***@raspberrypi:~# rpi-eeprom-config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0

Post by Mark Millard via freebsd-arm
Can you see the top of the SOC? Or is there a
heatsink or some such on it? (There is something
there to read if it can be seen.)
One possibility is that you have newer hardware that
the normal U-Boot vintages that FreeBSD has used do
not handle.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080
QUOTE
BROADCOM
2711ZPKFSB06BOT
TE1919
045-23 B3 W
END QUOTE
QUOTE
BROADCOM
2711ZPKFSB06C0T
TA2105
054-05 B3 W
END QUOTE
2711ZPKFSB06BOT
vs.
2711ZPKFSB06C0T

Mine reads 2711ZPKFSB06B0T.

Post by Mark Millard via freebsd-arm
is significant. If you have a 8GiByte "C0T" RPi4B it
would be the first known example. In such a case, you
might want to try the u-boot referenced in Comment 15 of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080 .
It got the 2 GiByte "C0T" to boot. (But that context
could not even boot via the microsd card slot with the
normal media content from 13.0-RELEASE .)
I do not know if the 2021.04 U-Boot that the since
updated port now provides would work for this context
or not. I've no access to any "C0T" RPi4B's (or any
Pi400's or CM4's).
There is a category of USB device that U-Boot still does
not support as far as I know: those where the one device
has multiple storage LUNs (instead of just one Logical
Unit Number identifying storage).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253983
is about such a context, where we eventially figured out
the "multiple storage LUN" issue.
But the error messages from the U-Boot of the time was
not what you report.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

Mark Millard via freebsd-arm

2021-05-30 20:28:33 UTC

Permalink

On 2021-May-30, at 10:59, William Carson via freebsd-arm <freebsd-arm at freebsd.org> wrote:

Thank you for the quick and thorough reply!

Post by Mark Millard via freebsd-arm

Post by Mark Millard via freebsd-arm
. . .
# rpi-eeprom-config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41
report in your context? (An equivalent command is
"vcgencmd bootloader_config". I show example output
above.)

[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0

That looks like an old default is still in place.

What my output showed is the modern default they ship
with as I understand. You may want to update.

If you want more debug output from the RPi4B firmware,
you could use:

BOOT_UART=1

I normally do. I've just not gotten around to updating
that specific device yet. That goes along with using:

enable_uart=1
uart_2ndstage=1
dtdebug=1

in config.txt . I use dtoverlay=disable-bt in config.txt
which causes the better UART to be used for the serial
console. There is also the alternative:
dtoverlay=miniuart-bt

The (or an) explicit BOOT_ORDER in rpi-eeprom-config
might be appropriate as well. I saw no reason to change
or eliminate the others and left them in place on the
other RPi4B's.

https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md

lists the following for config.txt use:

bootcode_delay (default 0, so 0 sec)
boot_delay (default 1, so 1 sec)
boot_delay_ms (default 0, so 0 msec)

It also has notes about uart_2ndstage use and the like.
I've never had to use these but if your device takes a
while to become ready, thse might be able to help.

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

Mark Millard via freebsd-arm

2021-05-30 20:50:16 UTC

Permalink

Post by Mark Millard via freebsd-arm
. . .
I use a USB3 SSD that has small enough power requirements
to not require a powered hub. (I also use a 5.1V 3.5A
power supply as part of that context.) I've never tried
spinning rust or higher powered USB3 media.

I view the power supply that I use as just giving a little
more margin, not as a way to increase what the devices
total to.

. . . I'm not sure what's considered "high powered" but the Samsung tech specs say this particular model uses 5.7 W on average and 10.0 W maximum. But it does seem curious that the Raspberry PI OS will boot this disk without issue, so I don't think it's the drive. I also tried a Samsung 950 PRO using a different enclosure (QNINE NVME Enclosure, M.2 PCIe SSD (M Key) to USB 3.0 External Case), but it behaved the same.

. . .

Then you need to use a powered hub for that device.

https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md
lists:

"Maximum total USB peripheral current draw" as: 1.2A ,
which at 5.1V is 6W.

That figure is the total for all USB devices attached
that are not powered independently.

That document also says that a 5.1V supply is required,
not 5V.

The power supply that the RPi folks supply is 5.1V @ 3A
or 15.3W. Even the 5.1V 3.5A power supply that I use
only multiplies out to 17.85W.

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

Mark Millard via freebsd-arm

2021-05-30 21:08:20 UTC

Permalink

Post by Mark Millard via freebsd-arm

I view the power supply that I use as just giving a little
more margin, not as a way to increase what the devices
total to.

. . .
Then you need to use a powered hub for that device.

I should have just referred to independent power. You
had written:

QUOTE
I'm trying to use a SAMSUNG (MZ-V7E500BW) 970 EVO SSD 500GB - M.2 NVMe, attached via the Geekworm X872 M.2 NVMe 2280/2260/2242/2230 SSD Expansion Board.
END QUOTE

https://geekworm.com/products/raspberry-pi-4-x872-m-2-nvme-2280-2260-2242-2230-ssd-expansion-board

shows that it has its own power connector and has an image
that says "please power x872 via DC Jack of XH2.54 connector
if SSD is not recognized or low power". Later text on the
page says:

QUOTE
Specifications:
Power Supply
• 5Vdc +/-5% , Powered by Raspberry Pi USB port
• 5Vdc via DC power jack or XH2.5 connector, Extra power for the SSD
END QUOTE

So, if I gather right, you need to connect a power
supply to the X872 and another to the RPi4B.

Another image says "Note: NOT recommended to use SAMSUNG SSD,
if use SAMSUNG SSD, please close WiFi". Later text on the page
says the same.

Post by Mark Millard via freebsd-arm
https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md
"Maximum total USB peripheral current draw" as: 1.2A ,
which at 5.1V is 6W.
That figure is the total for all USB devices attached
that are not powered independently.
That document also says that a 5.1V supply is required,
not 5V.
or 15.3W. Even the 5.1V 3.5A power supply that I use
only multiplies out to 17.85W.

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

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

William Carson via freebsd-arm

2021-05-30 23:54:29 UTC

Permalink

Post by Mark Millard via freebsd-arm

I view the power supply that I use as just giving a little
more margin, not as a way to increase what the devices
total to.

. . .
Then you need to use a powered hub for that device.

I should have just referred to independent power. You
QUOTE
I'm trying to use a SAMSUNG (MZ-V7E500BW) 970 EVO SSD 500GB - M.2 NVMe, attached via the Geekworm X872 M.2 NVMe 2280/2260/2242/2230 SSD Expansion Board.
END QUOTE
https://geekworm.com/products/raspberry-pi-4-x872-m-2-nvme-2280-2260-2242-2230-ssd-expansion-board
shows that it has its own power connector and has an image
that says "please power x872 via DC Jack of XH2.54 connector
if SSD is not recognized or low power". Later text on the
QUOTE
Power Supply
• 5Vdc +/-5% , Powered by Raspberry Pi USB port
• 5Vdc via DC power jack or XH2.5 connector, Extra power for the SSD
END QUOTE
So, if I gather right, you need to connect a power
supply to the X872 and another to the RPi4B.
Another image says "Note: NOT recommended to use SAMSUNG SSD,
if use SAMSUNG SSD, please close WiFi". Later text on the page
says the same.

A-ha, indeed. I just noticed that as well. I've gone ahead and ordered a supplementary power supply and a lower-power NVMe to do more testing. I'll send an update once I've received and tested them.

Thank you for hopefully pointing me in the right direction.

Post by Mark Millard via freebsd-arm
https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md

Post by Mark Millard via freebsd-arm
"Maximum total USB peripheral current draw" as: 1.2A ,
which at 5.1V is 6W.
That figure is the total for all USB devices attached
that are not powered independently.
That document also says that a 5.1V supply is required,
not 5V.
or 15.3W. Even the 5.1V 3.5A power supply that I use
only multiplies out to 17.85W.

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

Mark Millard via freebsd-arm

2021-05-31 03:49:32 UTC

Permalink

Post by William Carson via freebsd-arm

Post by Mark Millard via freebsd-arm

I view the power supply that I use as just giving a little
more margin, not as a way to increase what the devices
total to.

. . .
Then you need to use a powered hub for that device.

A-ha, indeed. I just noticed that as well. I've gone ahead and ordered a supplementary power supply and a lower-power NVMe to do more testing. I'll send an update once I've received and tested them.
Thank you for hopefully pointing me in the right direction.

I do not know if the "supplementary power supply" would be sufficient
for the existing drive to work, but it is likely necessary. Similarly
for any other drive that could require a significant portion of the
1.2A at times. (I've no clue what else you have plugged into USB or
how much power(/current) those devices take (if any). So I do not
know what to subtract from the 1.2A.)

The USB3 SSDs that I'm using are based on:

ATA Version is: ATA8-ACS, ACS-2 T13/2015-D revision 3
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)

This helps explain why I've got no power problem: older
technology. Note that SATA 3.0 can be somewhat faster
than the original USB3 already, at least in some respects.

Post by William Carson via freebsd-arm

Post by Mark Millard via freebsd-arm
https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md

Post by Mark Millard via freebsd-arm
"Maximum total USB peripheral current draw" as: 1.2A ,
which at 5.1V is 6W.

(Possibly should have listed the 6.12W figure.)

Post by William Carson via freebsd-arm

Post by Mark Millard via freebsd-arm

Post by Mark Millard via freebsd-arm
That figure is the total for all USB devices attached
that are not powered independently.
That document also says that a 5.1V supply is required,
not 5V.
or 15.3W. Even the 5.1V 3.5A power supply that I use
only multiplies out to 17.85W.

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

Mark Millard via freebsd-arm

2021-05-30 23:25:23 UTC

Permalink

T. . .

. . .

This does not involve a U-Boot at all --and also is an armv7 boot,
instead of an aarch64 boot. It may also be that this manages to
use less power on the SSD during booting than a
Firmware -> U-Boot -> FreeBSD-Loader -> FreeBSD-Kernel+World would.

RaspiOS and RaspiOS64 boot a kernel*.img directly from the firmware,
without using U-Boot. We already know that the firmware was working
to find, load, and start U-Boot. So this boot does not tell us much
new about the boot sequence that is used for FreeBSD (U-Boot and
later stages).

The issue seems to be tied to U-Boot's stage of activity based on
your reports of the notices output.

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