Re: Some issues related to the port of Raspberry Pi.

From: Mark Millard <>
Date: Sat, 29 Jul 2023 20:38:07 UTC
On Jul 29, 2023, at 11:30, ykla <> wrote:

> In we are indeed using the same version of Raspberry Pi firmware i.e. 1.20230405, I am using freebsd 13.2 release of u-boot,

FYI for 13.2-RELEASE (at least the RPi* aarch64 image): Its U-Boot
was specially built/installed, avoiding the problematical version.
After mounting the msdosfs file system from the 13.2-RELEASE RPi*
aarch64 media that I have:

# strings /mnt/u-boot.bin | grep "U-Boot 20"
U-Boot 2022.10 (Apr 07 2023 - 02:47:36 +0000)

> which one are you using?

I already indicated my U-Boot context in the material that
you replied to:

I actually use my own U-Boot build, in part because some of my USB3
boot media require something like a usb_pgood_delay for U-Boot to
tolerate them. My in-use build is based on 2023.01 :

# strings /boot/efi/u-boot.bin.2023.01.arm64 | grep "U-Boot 20"
U-Boot 2023.01 (Feb 06 2023 - 08:06:49 +0000)

I'll note that one way to identify the RPi* firmware build
in the tagged release is to do the likes of:

# strings /boot/efi/start4.elf | grep VC_BUILD_ID_
VC_BUILD_ID_TIME: 10:50:39
VC_BUILD_ID_TIME: Mar 17 2023
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 82f3750a65fadae9a38077e3c2e217ad158c8d54 (clean)

on the start*.elf file of interest.

Sometimes a new tagged release is for changes elsewhere and
this part does not change. The above from 1.20230405 is
actually unchanged from the prior 1.20230317 tagged release,
for example.

Another thing that is involved is the RPi* EEPROM content's
vintage. The tagged versions of the files used to update the
EEPROM can be accessed via:

An oddity of the last release for this is that it
has 2 tags for bf7419c:

a) 1 based on YYYY.MM.DD (normal):  v2023.01.11-138c0
b) 1 based on YYYY.DD.MM (unusual): v2023.11.01-138c0

Again, if I can, I tend to use tagged releases of these,
not development versions.

I'm not aware of being able to use FreeBSD to manage the
EEPROM contents. I use RaspiOS64 (my abbreviation) for
such management.

> Mark Millard <> 于 2023年7月30日周日 上午2:07写道:
> On Jul 29, 2023, at 09:23, ykla <> wrote:
> > 
> > Hi,
> > However, strangely, when I replaced the rpi4-firmware in the ports with the latest version from the official Raspberry Pi source and copied it to a USB drive, the system started to loop with the following code.
> > 
> > ---------------
> > 
> > Net: eth0:ethernet@7d580000
> > PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> > starting USB……
> > Bus xhci_pci:Reglster 58000420 NbrPorts 5
> > Starting the contorller
> > USB XHCI 1.00
> > scanning bug xhci_pci for devices... Unexpected XHCI event TRB, Skipping

I'll note that I've never gotten that "Unexpected XHCI
event TRB" message historically. So I'm not familiar
with what leads to it.

> > 6a0 000000004 01000000 01008401)
> That output looks like U-Boot output, before FreeBSD's UEFI loader
> has been loaded. (I'd be  more sure if there was more context.) Of
> course the RPi* firmware and .dtb starts being involved before
> U-Boot starts and, so, is involved.
> I actually use my own U-Boot build, in part because some of my USB3
> boot media require something like a usb_pgood_delay for U-Boot to
> tolerate them. My in-use build is based on 2023.01 :
> # strings /boot/efi/u-boot.bin.2023.01.arm64 | grep "U-Boot 20"
> U-Boot 2023.01 (Feb 06 2023 - 08:06:49 +0000)
> (My config.txt references that name.)
> So, the later material below is not based on the same U-Boot that
> you are using.
> > ---------------
> > The original author seems to have abandoned the project, so I forked a copy from the ports archive. You can find it here: and
> > I don't understand programming very well. Can someone help me with this problem?
> > 
> > Additionally, the author of raspberrypi-userland (who is the same person as the firmware's port author) has also deleted the project. There is currently no upstream for this project
> > 
> > The current Raspberry Pi 4B 8GB version has issues with booting. The current u-boot booting process gets stuck at the rainbow screen.see also
> > If someone could provide assistance, I would be very grateful.
> > 
> > I'm not sure if the upstream has made any fixes for this issue.
> > 
> I expect that you may not be using an officially tagged release
> but instead are using a development version of the RPi* firmware.
> I avoid the development versions when I can.
> I had no trouble with the firmware-1.20230405 materials, the
> most recent tagged release available. The RPi4B context is
> the 8 GiByte Rev 1.5 with the "C0T" part number label on the
> top of the SOC.
> The tagged versions are available via:
> The most recent there is:
> I downloaded:
> and did:
> # tar -xf 1.20230405.tar.gz firmware-1.20230405/boot/ firmware-1.20230405/
> # rm ~/firmware-1.20230405/boot/kernel*.img
> to extract the relvent material.
> I updated one of the RPi4B USB3 boot media to have this firmware
> (and .dtb's) in its msdosfs file system.
> It booted the 8 GiByte RPi4B Rev 1.5 just fine (based, in
> part, on my U-Boot build, however).
> The media I picked to test with has not had its FreeBSD updated
> in a while:
> # uname -apKU
> FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082

Mark Millard
marklmi at