Re: RPI4-4Gb Boot fails from SD card (both my build AND the official 14.3 build)

From: Karl Denninger <karl_at_denninger.net>
Date: Sun, 27 Jul 2025 17:07:28 UTC
root@NewFS:/work/OBJ/ARM64-14-NTP-STABLE # pkg info|grep rpi
rpi-firmware-1.20230405.g20230405 Firmware for RaspberryPi Single Board 
Computer
u-boot-rpi2-2025.04            Cross-build das u-boot for model rpi2
u-boot-rpi3-2025.04            Cross-build das u-boot for model rpi3
u-boot-rpi4-2025.04            Cross-build das u-boot for model rpi4

I do not have the other one you referenced on my build box -- I will add 
it.....

u-boot-rpi4 *_does not_* boot the "4" but does boot on the "3".

u-boot-rpi3 *_does_* boot both.

Neither implicates the firmware group of files which is from 2023 and 
has not been disturbed.

After grabbing the other u-boot package all three have distinct sizes 
and checksums and all three claim to be from the same 2025.04 date.

Only the u-boot-rpi3-2025.04 copy of uboot will boot and run both the 
"3" and "4" I have here.

On 7/27/2025 12:54, Mark Millard wrote:
> On Jul 27, 2025, at 07:53, Karl Denninger<karl@denninger.net> wrote:
>> Now this is interesting.....
>> The image I have been running (and the one apparently in the official releases -- I'll have to go look but I mimic'd what it was doing for ARM64 on the Pis) was using the u-boot binary out of the rpi-4 package.
>> If I copy in the u-boot.bin file out of the rpi-3 package the older Pi4 I have here boots and runs.  The u-boot.bin files are different in both size and content despite allegedly being the same version.
> I'm having trouble uniquely identifying what you are trying to
> reference.
>
> There are 3 relevant U-Boots for 64-bit use (arm64/aarch64):
>
> ) sysutils/u-boot-rpi-arm64
>
>    The most recentlky created of the 3 and was created to handle
>    both RPi4B's and RPi3B's. At one time that worked.
>
> ) sysutils/u-boot-rpi3
>
>    Was not intended to boot/support the RPi4B and its content
>    (used to do the build) predates the RPi4B.
>
> ) sysutils/u-boot-rpi4
>
>    Created to boot/support the RPi4B's, not the RPi3B's. This was
>    before sysutils/u-boot-rpi-arm64 was later created.
>
> The modernhttps://cgit.freebsd.org/src/ has just:
>
> release/arm64/RPI.conf
>
> for the RPi3B's/RPi4B's and such that uses:
>
> EMBEDDEDPORTS="sysutils/u-boot-rpi-arm64 sysutils/rpi-firmware"
>
> There is no release/arm64/*.conf using either of the others
> any more (other than in the history).
>
> So, of the 3 U-Boot's, which are you referencing in each case
> for the 2 you seem to be mentioning?
>
>
> Side note:
>
> I updated the EEPROM in the old 4 GiByte RPi4B and the
> result for a microsd card boot is:
>
> . . .
> sdhci_bcm1-slot0: ===========================================
> mmcsd0: Error indicated: 1 Timeout
> mmcsd0: Error indicated: 1 Timeout
> mmcsd0: Error indicated: 1 Timeout
> mmcsd0: Error indicated: 1 Timeout
> mmcsd0: Error indicated: 1 Timeout
> mountroot: waiting for device /dev/ufs/rootfs...
> Mounting from ufs:/dev/ufs/rootfs failed with error 19.
>
> Loader variables:
>    vfs.root.mountfrom=ufs:/dev/ufs/rootfs
>    vfs.root.mountfrom.options=rw
>
> Manual root filesystem specification:
>    <fstype>:<device> [options]
>        Mount <device> using filesystem <fstype>
>        and with the specified (optional) option list.
>
>      eg. ufs:/dev/da0s1a
>          zfs:zroot/ROOT/default
>          cd9660:/dev/cd0 ro
>            (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>
>    ?               List valid disk boot devices
>    .               Yield 1 second (for background tasks)
>    <empty line>    Abort manual input
>
> mountroot>
>
>> I do not have (yet) one of the newer Pi4s to test with but do have one coming, so I'll check that one as well -- and in the meantime, well, guess where I'll be pulling the u-boot binary from in my builds since this one works with both the "3" and "4"s that I have.....
>>
>> On 7/27/2025 08:10, Karl Denninger wrote:
>>> On 7/26/2025 23:40, Mark Millard wrote:
>>>> On Jul 26, 2025, at 18:24, Karl Denninger<karl@denninger.net> wrote:
>>>>
>>>>
>>>>> Well, the same card (physically the same card) boots in the Pi3 with the same FreeBSD load *and* the same card loaded with an "official" Pi firmware load boots in the 4 and runs. I have attempted this with two very different SD cards -- one Sandisk Ultra that previously had Kodi on it and was running in that specific Pi4 and the second is one that while slower is one of a dozen here of a series that have served me extremely well in Pis for a very, very long time.
>>>>> The builds on my box (and apparently the one on the FreeBSD official image page) are all using 2025-04 u-boot as the official FreeBSD load off the distribution page behaves exactly the same way -- the EFI loader boots without incident, gets and loads the kernel, the kernel boots as expected but the mmc driver takes timeouts and cannot see the sd card after the kernel comes up, thus root mount fails.
>>>>>
>>>> Summary: The below booted from a microsd card just fine
>>>> on one system --but not on another-- based on:
>>>>
>>>> FreeBSD-14.3-STABLE-arm64-aarch64-RPI-20250724-f0a7a1bda375-272016.img.xz
>>>>
>>>> It failed for a rather old 4 GByte RPi4B that I got access
>>>> to (older EEPROM content as well) --but worked on a modern
>>>> 8 GiByte RPi4B.
>>> Lovely.  So from appearances there's a hardware difference that apparently results in this; this is an older one (quite old) which is the only "4" I have right now.  I guess it get relegated to Kodi use (if ever); I'll see about sourcing some newer ones (whether I borked it when I updated its firmware as Kodi wanted or whether its rot somewhere in the FreeBSD driver code that breaks for this hardware but not newer stuff I don't know.)
>>> I'll play with some older u-boot copies I have laying around but since the EFI loader and then kernel starts I'll wager that ain't the issue and see about sourcing a couple of the newer ones to play with for the purpose I'm screwing with these in the first place.
>>>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/