Bug 255080 - U-Boot build for Raspberry Pi 4 (arm64) does not boot from MicroSD card slot
Summary: U-Boot build for Raspberry Pi 4 (arm64) does not boot from MicroSD card slot
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: 13.0-STABLE
Hardware: arm64 Any
: --- Affects Only Me
Assignee: freebsd-arm (Nobody)
URL:
Keywords: loader
Depends on:
Blocks:
 
Reported: 2021-04-15 07:45 UTC by Leo Schneider
Modified: 2021-04-30 07:26 UTC (History)
9 users (show)

See Also:


Attachments
rPi OS CPU info (1.63 KB, text/plain)
2021-04-17 20:51 UTC, Nicolai Plum
no flags Details
FreeBSD 13-RELEASE "boot -v" dmesg (36.11 KB, text/plain)
2021-04-17 21:29 UTC, Nicolai Plum
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Leo Schneider 2021-04-15 07:45:26 UTC
TEST SCENARIO

1. Flashed the image FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz in MicroSD using dd on MacOS
2. Inserted flashed MicroSD on RaspberryPi 4 slot
3. U-Boot fails to find the MicroSD
4. U-Boot then looks for USB storage but can't find it
5. U-Boot then try to boot from network
6. Same MicroSD card is inserted in a MicroSD-USB adapter and inserted on Raspberry  Pi USB Port
7. FreedBSD boots OK

OBSERVATIONS
1: The U-Boot build doesn't include the command 'sdboot' thus it was not possible to manually force the boot from the MicroSD card slot
2: The U-Boot "boot_targets" has "mmc" defined
3. It switches to "mmc0" which I assume is the MicroSD card but complains "** No partition table -  mmc 0 **" and then switch to network boot
Comment 1 Mark Millard 2021-04-15 09:23:21 UTC
I did the following:

1. Flashed the image FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz onto a MicroSD, using dd on a Rock64 running FreeBSD.

2. Inserted flashed MicroSD in various RaspberryPi 4 slots (RPi4B 8 GiByte v1.4, RPI4B 4 GiByte v1.1, RPi3B 1 GiByte v1.2, RPi2B 1GiByte v1.2 [so: cortex-a53 version]).

3. They all booted just fine from the MicroSD. (The growfs happened on the 8 GiByte RPi4B.)

There must be something more involved in your context's
details that contributes to your results. The problem will
be to identify what all contributes to the distinctions.

If you can capture and attach the serial console output, it
might be useful for someone trying to help.


I will note that it is normal for there to be messages about
both mmc0 and mmc1. For example for a USB3-SSD-only boot, no
microsd card in place, there is in the recent log file that
I recorded (for other reasons at the time):

mmc0: No compatible cards found on bus
mmc1: No compatible cards found on bus
Comment 2 Mark Millard 2021-04-15 18:13:05 UTC
(In reply to Mark Millard from comment #1)

I recorded the RPi4B 8 GiByte booting from the media:

mmcsd0: 31GB <SDHC SDCIT 3.0 SN 002BC426 MFG 10/2016 by 65 42> at mmc1 50.0MHz/4bit/65535-block

So mmc1 was used for the card, not mmc0.

Notably the mmc0 and mmc1 messages are from the FreeBSD kernel, just
before the cpu information (in case yours was from a different time
frame):

mmc0: No compatible cards found on bus
mmcsd0: 31GB <SDHC SDCIT 3.0 SN 002BC426 MFG 10/2016 by 65 42> at mmc1 50.0MHz/4bit/65535-block
bcm2835_cpufreq0: ARM 600MHz, Core 200MHz, SDRAM 400MHz, Turbo OFF
Release APs...Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
done
CPU  0: ARM Cortex-A72 r0p3 affinity:  0
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
 Instruction Set Attributes 0 = <CRC32>
 Instruction Set Attributes 1 = <>
         Processor Features 0 = <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32>
         Processor Features 1 = <>
      Memory Model Features 0 = <TGran4,TGran64,SNSMem,BigEnd,16bit ASID,16TB PA>
      Memory Model Features 1 = <8bit VMID>
      Memory Model Features 2 = <32bit CCIDX,48bit VA>
             Debug Features 0 = <2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3,Debugv8>
             Debug Features 1 = <>
         Auxiliary Features 0 = <>
         Auxiliary Features 1 = <>
CPU  1: ARM Cortex-A72 r0p3 affinity:  1
CPU  2: ARM Cortex-A72 r0p3 affinity:  2
CPU  3: ARM Cortex-A72 r0p3 affinity:  3

The earlier mmc0 or mmc1 kernel messages were in the sequence:

mmc0: <MMC/SD bus> on sdhci_bcm0
fb0: <BCM2835 VT framebuffer driver> on simplebus0
fb0: keeping existing fb bpp of 32
fbd0 on fb0
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 592x448(592x448@0,0) 32bpp
fb0: fbswap: 1, pitch 2368, base rx3eaf5000, screen_size 1060864
sdhci_bcm1: <Broadcom 2708 SDHCI controller> mem 0x7e340000-0x7e3400ff irq 79 on simplebus1
mmc1: <MMC/SD bus> on sdhci_bcm1


The only u-boot tiem frame references to "mmc" or "MMC" were in the sequence:

MMC:   mmc@7e300000: 1, emmc2@7e340000: 0
Loading Environment from FAT... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 4 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  2  1  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
7[r[999;999H[6n8Scanning disk mmc@7e300000.blk...
Disk mmc@7e300000.blk not ready
Scanning disk emmc2@7e340000.blk...

So I did not get the partition table message, but your was for
mmc0 and in my context the microsd card showed up on mmc1 instead,
at least as the FreeBSD kernel names things.

You may need to quote more context of the text around the mmc
messages as part of helping people help you.
Comment 3 christer.solskogen 2021-04-15 18:38:40 UTC
Do you have a mouse connected? I've seen the same thing with my device when a mouse is connected.
Comment 4 Mark Millard 2021-04-16 04:39:00 UTC
(In reply to christer.solskogen from comment #3)

FYI: In my context having a mouse also connected to the RPi4B
8 GiByte did not create a problem. Booting still just worked.
Comment 5 Nicolai Plum 2021-04-17 17:49:35 UTC
I am seeing this problem too. A new rPi will not boot from a FreeBSD image in the internal SD card slot.

I have two rPis under test, I will call them Old Pi and New Pi. Both are Raspberry Pi Model 4 B 2GB. One is about a year old, the other is new (purchased a few days ago from one of the larger dedicated rPi supply houses). 

The FreeBSD image used is FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img downloaded a few days ago, file datestamped 09 April 2021, I will call it FreeBSD henceforth.

The Raspberry Pi OS image used is 2021-03-04-raspios-buster-armhf-full.img. I will call it Raspberry Pi OS henceforth.

I used the same SD card throughout, rewriting OS images as needed.

New Pi will boot Raspberry Pi OS from an SD card in the built-in SD card slot.

Old Pi will boot FreeBSD from an SD card in the built-in SD card slot.

New Pi will not boot FreeBSD from an SD card in the built-in SD card slot (the exact same image, without rewriting, that Old Pi booted successfully)

New Pi will boot FreeBSD from an SD card in an USB to SD card adapter (the same adapter I used to write the image in the first place).

New Pi appears to have the same overall components as Old Pi but the RAM chip has an entirely different identifier and the SOC package has slightly different set of numbers/letters on it.

Things I am confident of:
* New Pi does not have a broken SD card slot, nor does it have other hardware problems preventing booting.
* Old Pi has similarly fully functional hardware.

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


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


The boot messages on New Pi when failing to boot from SD card in SD slot (transcribed from a literal screenshot using my phone camera):
------< cut here

Net: eth0: ethernet@7d580000 
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB... 
Bus xhci pci: Register 5000420 NbrPorts 5 
Starting the controller
USB XHCI 1.00

scanning bus xhci _pci for devices... 2 USB Device(s) found 
       scanning usb for storage devices... 0 Storage Device(s) found 
Hit any key to stop autoboot: 0 
switch to partitions #0, OK 
mmc0 is current device 
** No partition table - mmc 0**

Device 0: unknown device 
ethernet@7d580000 Waiting for PHY auto negotiation to complete..
------< cut here

The system then tries to network boot.


Partial boot messages from New Pi when succeeding in booting from SD card in USB to SD adapter (transcribed from photographs, and some messages missed as the screen clears after the first set of messages):
Part 1:
------< cut here
Net: eth0: ethernet07d580000 
PCIe BRCH: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... Device NOT ready 
   Request Sense returned 02 3A 00
3 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found 
Hit any key to stop autoboot: 1
------< cut here
Part 2:
------< cut here
Consoles: EFI console
    Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk0p1:
FreeBSD/arm64 EFI loader, Revision 1.1

   Command line arguments: loader.efi
   Image base: 0x39cfc000 
   EFI version: 2.80
   EFI Firmware: Das U-Boot (rev 8224.4096)
   Console: conconsole (0)
   Load Path: /efi\boot\bootaa64.efi
   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0, 0x0,0x9,0x0,0x3)/UsbClass(Oxbda,0x306,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18f
a8) 
Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,
0x9,0x0,0x3)/UsbClass(Oxbda,0x306,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
Setting currdev to disk0p1:
Trying /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,
0x0,0x3)/UsbClass(0xbda,0x306,0x0,0x0,6x0)/HD(2,0x01,0,0x197c7,0x5e6821) 
Loading /boot/defaults/loader.conf
Loading /boot/defaults/loader.conf 
Loading /boot/device.hints
Loading boot/loader.conf 
Loading /boot/loader.conf.local
/
-----< cut here


It may be that newer rPi hardware MMC slots are not recognised.

Any suggestions welcome!
Comment 6 Nicolai Plum 2021-04-17 17:50:55 UTC
Additonal notes:
The only things connected to the rPi were:
HDMI cable to hdmi0 connector
Power (3A USB-C PSU)
SD card (in SD slot) or USB to SD adapter containing SD card.
Comment 7 Mark Millard 2021-04-17 18:00:32 UTC
(In reply to Nicolai Plum from comment #5)

2711ZPKFSB06BOT
vs.
2711ZPKFSB06C0T

is a major change in that there is a bunch of logic
special to the B0T variant to deal with a DMA limitation
of not being able to span the full address space. The
C0T variant has the hardware fixed and is not limited
to the lower 3 GiBytes. The RPi firmware likely configures
the C)T parts differently in various ways.

Likely someone with appropriate knowledge and interest
is going to need to get their hands on examples of
2711ZPKFSB06C0T like parts with 4 GiByte and 8 GiByte
RAM sizes.
Comment 8 Mark Millard 2021-04-17 18:15:24 UTC
(In reply to Nicolai Plum from comment #5)

You may want to add an attachment with boot -v
output up to the failure, possibly including
early (pre-FreeBSD) serial console information
if it can be recorded. The information likely
would be of interest to anyone that wanted to
work on supporting C0T parts.

It may be that more modern RPi firmware is needed
for C0T parts. (I'm not claiming sufficiency, just
necessity may be involved.) A similar point might
go for the u-boot involved. More than FreeBSD code
may be involved in getting the C0T parts to be
supported.
Comment 9 Mark Millard 2021-04-17 19:54:04 UTC
(In reply to Nicolai Plum from comment #5)

Any chance that you could do the following via a
RaspiOS or RaspiOS64 boot of the 2711ZPKFSB06C0T
based RPi4B?

# cat /proc/cpuinfo

# cat /sys/firmware/devicetree/base/model

See:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
Comment 10 Nicolai Plum 2021-04-17 20:51:11 UTC
Created attachment 224199 [details]
rPi OS CPU info
Comment 11 Nicolai Plum 2021-04-17 21:29:53 UTC
Created attachment 224200 [details]
FreeBSD 13-RELEASE "boot -v" dmesg
Comment 12 Nicolai Plum 2021-04-17 21:33:03 UTC
The Linux (Raspberry Pi OS) CPU/model info and FreeBSD verbose boot messages are attached to this bug report.

Having a USB keyboard attached also seemed to mess up the early boot phases (as mentioned in previous comments), causing what looked like USB initialisation timeouts at the boot stage with the Raspberry logo. 

There's a narrow time window to plug in the keyboard after this USB init is done but before U-Boot looks for devices so that the keyboard is visible to the FreeBSD boot loader and "boot -v" can be typed in.
Comment 13 Mark Millard 2021-04-17 22:44:19 UTC
(In reply to Nicolai Plum from comment #10)

Interesting, that "Revision	: b03114" shows up in:

https://github.com/raspberrypi/documentation/commit/ff3b562d6044cb50545104a04567614feb09dd91#diff-8e1dd306076bc874881b22ac322895672ea78ebaa50a53283660f588fb8b6218

which shows that hardware/raspberrypi/revision-codes/README.md had a
2020-Nov-25 update that added both:


+ | b03114 | 4B                | 1.4      | 2GB   | Sony UK      |
and:
+ | c03130 | Pi 400            | 1.0      | 4GB   | Sony UK      |

in the same commit. There is no other "b03114" in the table. (There
are other *03114 codes already in the table at that point.)

It looks like b03114 may identify a part code ending in C0T. But
also of note is that even the modern version of that table only
has that code for 2GB. (Other codes could also identify C0T but
it may be that the codes are generally not that specific.)
Comment 14 Mark Millard 2021-04-17 23:41:11 UTC
(In reply to Nicolai Plum from comment #5)

The text:

QUOTE
scanning bus xhci _pci for devices... 2 USB Device(s) found 
       scanning usb for storage devices... 0 Storage Device(s) found 
Hit any key to stop autoboot: 0 
switch to partitions #0, OK 
mmc0 is current device 
** No partition table - mmc 0**
END QUOTE

is from U-Boot, not from RPi firmware, nor from FreeBSD's loader
or FreeBSD's kernel. In other words: U-Boot is having this initial
problem. It looks necessary (but possibly not sufficient overall)
to have a U-Boot that knows how to deal with the model of RPi4B.
There is some possibility that the .dtb files from the RPi firmware
contribute to what U-Boot is doing and might also need updating.
(I would not expect this.)

This suggests that testing using 2021.04 U-Boot instead of
the 2020.10 U-Boot would be an appropriate substitution.

Unfortunately, "pkg upgrade" on 13.0-RELEASE will not get the
updated sysutils/u-boot-rpi-arm64 materials in
/usr/local/share/u-boot/u-boot-rpi-arm64/ to copy to the msdos
file system. The updated U-Boot must be created/copied another
way.
Comment 15 Klaus Küchemann 2021-04-18 02:25:02 UTC
(In reply to Mark Millard from comment #14)
<<...This suggests that testing using 2021.04 U-Boot instead of
the 2020.10 U-Boot would be an appropriate substitution....>>
---
if you need the latest (master):
U-Boot 2021.04 (Apr 18 2021 - 01:33:43 +0000) :
for download here :
https://sourceforge.net/projects/fbsd-u-boot-2021-04-apr18-2021/files/u-boot.bin/download

K.
Comment 16 Mark Millard 2021-04-18 03:30:28 UTC
(In reply to Klaus Küchemann from comment #15)

So, which does that u-boot.bin correspond to?:

/usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
/usr/local/share/u-boot/u-boot-rpi3/u-boot.bin
/usr/local/share/u-boot/u-boot-rpi4/u-boot.bin
None of the above

13.0-RELEASE is based on /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
--but back before the 2021.04 update: 2020.10 .
Comment 17 Klaus Küchemann 2021-04-18 03:38:04 UTC
(In reply to Mark Millard from comment #16)
<<So, which does that u-boot.bin correspond to?...>>

... /u-boot-rpi4/u-boot.bin, since this report is an rpi4-issue.

if you need another/further u-boot.bin-compilation, just let me know.

K.
Comment 18 Mark Millard 2021-04-18 04:16:15 UTC
(In reply to Klaus Küchemann from comment #17)

I do not have a failing context to test so I'd not be a user.
I'd leave it to such a user if they want a closer match to the
options used to make the 13.0-RELEASE image's U-Boot . Now,
at least, they can look into the distinctions if they care to.

(My normal use is probably more limited than most. I doubt
that my normal use would demonstrate the build option
differences as they would be seen on a RPi4B. But, as I
remember, there are some distinctions for
u-boot-rpi4/u-boot.bin vs. u-boot-rpi-arm64/u-boot.bin for
an RPi4B.)
Comment 19 Mark Millard 2021-04-18 23:10:31 UTC
(In reply to Nicolai Plum from comment #5)

https://lists.freebsd.org/pipermail/freebsd-arm/2021-April/023667.html

is a report of a b03114 RPi4B (2GB) that boots fine with
13.0-RELEASE. The B0T vs. C0T part suffix is not known:
already covered by heat sink.

However, it does suggest 3 possibiliites:

A) Differing EEPROM content versions
B) Differing board/CPU revisions
C) A combination of both

(A) would definitely not lead to b03114 not changing.

So I propose another test under RaspiOS or RaspiOS64:

# vcgencmd bootloader_config
and/or:
# rpi-eeprom-config
Comment 20 Mark Millard 2021-04-18 23:15:17 UTC
(In reply to Mark Millard from comment #19)

I incorrectly wrote "not" twice. Trying again:

(A) would definitely not lead to b03114 changing.
Comment 21 Mark Millard 2021-04-19 13:42:41 UTC
(In reply to Mark Millard from comment #20)

Looks like I asked for the wrong thing for what I was thinking.
The b03114 that boots fine via 13.0-RELEASE's RPI build is reported
on the lists as having the below (reported by Denis Ovsienko).
I was actually thinking of the CURRENT: line, just below the BOOTLOADER:
line, and the RELEASE: line, just after the LATEST: line. I'll note
that I use the same BOOTLOADER version on the RPi4B's that I have access
to, including the 8 GiByte ones (d03114):

root@raspberrypi:~# rpi-eeprom-update 
BOOTLOADER: up-to-date
  CURRENT: Thu  3 Sep 12:11:43 UTC 2020 (1599135103)
   LATEST: Thu  3 Sep 12:11:43 UTC 2020 (1599135103)
  RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
           Use raspi-config to change the release.

 VL805_FW: Using bootloader EEPROM
    VL805: up-to-date
  CURRENT: 000138a1
   LATEST: 000138a1

root@raspberrypi:~# lspci 
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 10)
01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host
 Controller (rev 01)

root@raspberrypi:~# lsusb 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@raspberrypi:~# grep -E '^[^#]' /boot/config.txt 
dtparam=i2c_arm=on
dtparam=audio=on
[pi4]
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
gpu_mem=16

root@raspberrypi:~# vcgencmd bootloader_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

root@raspberrypi:~# 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

I will note that I've had problems with "gpu_mem=16"
attempts in the past and so use "gpu_mem=32" instead.
I normally only use HDMI output for a console when it
is in use at all. I use a serial console and ssh
normally, X11 use is very rare for me.
Comment 22 Mark Millard 2021-04-19 17:48:00 UTC
(In reply to Mark Millard from comment #21)

I'll note that there is a newly-promted EEPROM default/critical
available as of today, but it is untested with the
RPi-firmware/U-Boot/FreeBSD-loader/FreeBSD-kernel combination
as far as I know:

pieeprom-2021-03-18.bin

Previously the most recent default/critical EEPROM promotion was
of:

pieeprom-2020-09-03.bin

That one has been in fairly general use for some time.

It is possible that the C0T parts may do better with one vs.
the other, not necessarily matching what works well with B0T
parts.

For reference:

https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md
Comment 23 Nicolai Plum 2021-04-19 19:14:33 UTC
Success!

The updated u-boot.bin provided by Klaus Küchemann (comment #15) boots the C0T hardware without problems. This includes with a keyboard attached. 

Test conditions:
Hardware: Raspberry Pi 4B, 2GB RAM, 128GB SD card in the internal SD card slot.
Software: FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img with updated u-boot.bin as above.

Method:
I burned a fresh copy of FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img to the SD card (visible as da1 on my amd64 machine);
mounted the MSDOS-format partition (/dev/da1s1);
copied the updated u-boot.bin to that MSDOS filesystem;
unmounted it;
and moved the SD card to the rPi.

So it would appear the fix for this is u-boot.bin, at least to get the system to boot.

Thank you to both Mark Millard and Klaus Küchemann for your help.

Would you like any more information from this system to help with further development, or would you like me to try any other changes?

What's the process for getting u-boot.bin updated in the release images? (I'm new to this - this is the first deficiency I have found in FreeBSD that affected me in ~15 years of using it).
Comment 24 Mark Millard 2021-04-19 20:19:29 UTC
(In reply to Nicolai Plum from comment #23)

I'm not sure that there is an update processes that would
provide a already-fixed image for 13.0-RELEASE for the
RPI image (until 13.1-RELEASE). This is especially true
because the part of it being updated is not build from
materials in FreeBSD's src.git .

It is likely that once the quarterly ports builds start to
have the 2021.04 vintage of sysutils/u-boot-rpi-amd64
content that the future stable/13 snapshots at:

https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/

(once created) will pick up the u-boot update and will
work.

Similar points go for main [14] snapshots:

https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/

but for "latest" instead of "quarterly".
Comment 25 Mark Millard 2021-04-19 20:22:09 UTC
(In reply to Mark Millard from comment #22)

I've updated the RPi4B 8 GiByte EEPROM to the new
default (a.k.a. critical) and had no problems
booting via a microsd card or a USB3 SSD. But
that tests B0T instead of C0T parts.
Comment 26 Mark Millard 2021-04-19 20:29:46 UTC
(In reply to Mark Millard from comment #24)

I probably should have warned that the "latest" for
13.0 has not been updated since back in Jan. As stands,
for 13.0 quarterly is the most recent available.

It is likely possible to request that quarterly update
to the more recent 2021.04 based u-boot vintages. That
would not fix 13.0-RELEASE images but it would make
getting the needed u-boot.bin easy in a standard way
for then copying in place.
Comment 27 Klaus Küchemann 2021-04-19 20:48:07 UTC
(In reply to Nicolai Plum from comment #23)

I'm glad that it works. If you want, you can close this pr with:
fixed by comment 15 .

Regards
K.
Comment 28 Mark Millard 2021-04-19 21:05:53 UTC
(In reply to Klaus Küchemann from comment #27)

I do not think that closing the defect as fixed is
appropriate until FreeBSD does not require the
workaround. Otherwise the required change can get
lost/forgotten easier.

Comment #15 does provide a workaround.

Another, for those using the Lastest repo via
pkg on some machine, is to install the
sysutils/u-boot-rpi-arm64 package (or
sysutils/u-boot-rpi4 package) and copy the
/usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
( or /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin )
to replace the older u-boot.bin on the msdos file
system on the rpi4 boot media.

Similarly one could build and install the
sysutils/u-boot-rpi-arm64 or sysutils/u-boot-rpi4
port and then copy the file over.
Comment 29 Klaus Küchemann 2021-04-19 21:29:22 UTC
(In reply to Mark Millard from comment #28)
<<.. workaround...>>

it's not a workaround, upgrading u-boot.bin seems instead a strictly requirement 
to boot the machine from uSD, as far as I understand comment 23 .
upgrading( or even downgrading) parts of the msdos-partiton by hand 
is a standard requirement since months ( or perhaps years:-) for the RPI4 here.
but who knows that better than e.g you ?!
...
Regards
K.
Comment 30 Mark Millard 2021-04-19 22:11:54 UTC
(In reply to Klaus Küchemann from comment #29)

Declaring this fixed means that FreeBSD should not be
considered for change for the issue. For example,
no reason to have quarterly update the u-boot vintage
that it is based on (until next quarter).

That is all that I'm referring to. What you have
done is handy but does not update the quarterly
package builds to have the new vintage of the
u-boot ports.

Those that decide if such updates are made may well
give this a "no plan to fix" status, just waiting
for the next quarter. At that point closing the defect
would be appropriate in my view, not before.
Comment 31 Klaus Küchemann 2021-04-20 00:39:33 UTC
(In reply to Mark Millard from comment #30)
<<..Those that decide..>>

You and me decide what has to be done on the msdos-partition, no one else. ;-) 
Ha Ha...

`ve added Mike to cc so he can close this pr or leave it open.

Regards
K.
Comment 32 Wen Heping freebsd_committer 2021-04-23 14:30:27 UTC
My RPI4b+ with 4G memory still failed boot with the updated u-boot.bin provided by Klaus Küchemann (comment #15) :(

wen
Comment 33 Klaus Küchemann 2021-04-23 15:56:29 UTC
(In reply to Wen Heping from comment #32)

do you have dmesg/console-output/OS-version/firmware-version(if not current default release- image) ?
Comment 34 Mark Millard 2021-04-23 16:35:03 UTC
(In reply to Wen Heping from comment #32)

What does it say on top of the processor? Other example contexts
reported have reported:

BROADCOM
2711ZPKFSB06BOT
TE1919
045-23 B3 W

vs.

BROADCOM
2711ZPKFSB06C0T
TA2105
054-05 B3 W

Is your microsd based on FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz
but with just u-boot-bin updated on the msdos file system? Some other
combination of materials? If some other: what other combination?

Do you have a serial console set up? Can you report captured output from
it? Does it show the:

QUOTE
scanning bus xhci _pci for devices... 2 USB Device(s) found 
       scanning usb for storage devices... 0 Storage Device(s) found 
Hit any key to stop autoboot: 0 
switch to partitions #0, OK 
mmc0 is current device 
** No partition table - mmc 0**
END QUOTE

that was reported in comment #5 ?
Comment 35 Wen Heping freebsd_committer 2021-04-23 22:46:42 UTC
(In reply to Mark Millard from comment #34)
My microsd is based on FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz,
and I updated u-boot-bin with the file suggested in Comment15. 

I did not set up serial console now, sorry have no more message.

Thank your reply.

wen
Comment 36 Mark Millard 2021-04-23 23:09:51 UTC
(In reply to Wen Heping from comment #35)

What of the text printed on the top of the processor?

Just in case: in your note you wrote "u-boot-bin" but
the file name should be "u-boot.bin". If in copying
things around you made a similar typo, it is possible
that the old u-boot.bin was not updated/replaced for
your test.

Without a serial console and copies of output recorded
from it, it is going to be difficult for anyone to
help you. On screen the "first error notice" may well
have scrolled off screen by the time things stop.
Still, you could try transcribing material from when
things stop --or adding an attachment that is a
picture of that screen. It might provide something
of some use.

At this point it is not even clear if your problem is
significantly related to what has been learned for this
bugzilla so far --vs. if it would be better submitted as
a separate problem.
Comment 37 Klaus Küchemann 2021-04-23 23:47:53 UTC
(In reply to Wen Heping from comment #35)

as Mark indicated in comment #36, we are quite sure that your problem is probably not related to u-boot-issues. I have booted your setup on the same machine as yours(older model) 2 minutes ago....Is yours a newer model?
the u-boot.bin from comment #15 is even working on the new RPI 400, as I`ve read somewhere .
a quick sroll through u-boot`s git  also has no news the last days related to the RPI4 
so the (comment #15 ) u-boot.bin really should work.

K.
Comment 38 Wen Heping freebsd_committer 2021-04-24 07:35:07 UTC
(In reply to Mark Millard from comment #36)
On top of processor say:

2711ZPKFSB06BOT
TE1917
183-04 B3 W

I write FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz to my microSD card,
and I replace u-boot.bin.

The same card boot my RPI3b+ well.

wen
Comment 39 Mark Millard 2021-04-24 08:40:07 UTC
(In reply to Wen Heping from comment #38)

Thanks for the information. We now know that the newer processor
variant is not involved in your issue --which is important to
know.

Thanks also for reporting that it works in your RPi3B+ . That
gives some useful context.

One question would be: did the microsd card boot the RPi3+
before the u-boot was replaced as well? Right now we have
no information indicating a u-boot specific problem. If the
old u-boot also worked in the RPi3B+ then it would seem
likely that involving the new u-boot just complicates
things and the pure FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img
transfer would likely be a better basis for investigation.



Unfortunately, between the two items that you report, it means
that information from the display or from serial console output
appears to be essential to anyone getting a clue about what it
going on. It is the first unexpected messages reported that are
likely the important ones.

So far it looks like your problem is likely not the one associated
with comment #5 (which the original description seems to match for
the lesser information it provides): the "** No partition table -
mmc 0 **" related messages from u-boot.
Comment 40 Mark Millard 2021-04-24 09:07:16 UTC
(In reply to Wen Heping from comment #38)

If you could boot RasPiOS or RasPiOS64 on the RPi4B
you could try the following sorts of commands and
report the outputs (I show example outputs from
earlier comments):

# rpi-eeprom-update 
BOOTLOADER: up-to-date
  CURRENT: Thu  3 Sep 12:11:43 UTC 2020 (1599135103)
   LATEST: Thu  3 Sep 12:11:43 UTC 2020 (1599135103)
  RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
           Use raspi-config to change the release.

 VL805_FW: Using bootloader EEPROM
    VL805: up-to-date
  CURRENT: 000138a1
   LATEST: 000138a1

I will note that in recent days another version of the
EEPROM has been promoted to the default/critical status
so "LATEST" may be more recent than shown above, even
if you are using "RELEASE: default". It woudl depend on
the detailed vintage of your RasPiOS* install.

# vcgencmd bootloader_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

# lspci 
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 10)
01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host
 Controller (rev 01)

# lsusb 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Mostly this allows for some cross-checking if some of that might
be unexpectedly different in your context.
Comment 41 Klaus Küchemann 2021-04-24 16:39:33 UTC
(In reply to Wen Heping from comment #38)

you see the rainbow on your hdmi-display, right ?
if so, please plug the hdmi-cable in the first slot, next to the PSU-plug.
by the way , that's not a bug and if your model is not a newer one: it 
will boot FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz from https://download.freebsd.org/ftp/releases/arm64/aarch64/ISO-IMAGES/13.0/ out of the box. Mark will tell you how you can get a better resolution on hdmi while booting ;-)

K.
Comment 42 Hōkan 2021-04-24 17:04:39 UTC
I'll note that I couldn't boot when I had more than 1 device (keyboard and/or disk) plugged in to a USB3 port.  Once the boot started I could plug in more devices.  I have a powered USB3 hub but I've tested without it and didn't see any difference.

Updating u-boot from comment #15 resolved the issue for me.

I'm booting from a pair of ZFS-mirrored usb drives.
Comment 43 Mark Millard 2021-04-24 18:13:07 UTC
(In reply to Klaus Küchemann from comment #41)

(Klaus: Good suggestion to check on the HDMI cable connection.)

The config.txt has a line:

hdmi_safe=1

that restricts the resolution but allows more contexts
to display something (instead of ending up with a blind
context). hdmi_safe can be disabled one of 3 ways by
changing the line:

A) Use: hdmi_safe=0
B) Use: #hdmi_safe=1
C) Delete the line.

Booting afterward to make it use the adjusted line is
then required.
Comment 44 Wen Heping freebsd_committer 2021-04-25 23:21:42 UTC
(In reply to Klaus Küchemann from comment #41)
You are right, now I boot my RPI4 after I put hdmi-cable in the first slot.

Raspian boot both: hdmi-cable in the first slot and second slot.

Thank you !

wen
Comment 45 Wen Heping freebsd_committer 2021-04-25 23:22:25 UTC
(In reply to Mark Millard from comment #43)
Thank you !

wen
Comment 46 Mark Millard 2021-04-25 23:52:59 UTC
(In reply to Leo Schneider from comment #0)

Leo S.: Can you report on if the manual u-boot update to a
2021.04 based version fixes the problem for you as well?

Other supporting details, like what the top of your
processor indicates for:

2711ZPKFSB06BOT
vs.
2711ZPKFSB06C0T

and what RAM size the RPi4 has could be of use for confirming
or denying the context is as expected from what comment #5 has
lead to.
Comment 47 Mark Millard 2021-04-30 07:26:27 UTC
In looking around I ran into some notes for a U-Boot patch
for the RPi4's with newer parts. It may hint at why a
021-04 U-Boot is needed and may also hint at variations
that the FreeBSD kernel possibly could deal with.

QUOTE
. . .
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Date: Thu, 19 Nov 2020 18:48:17 +0100
Subject: [PATCH 11/16] pci: pcie-brcmstb: Fix inbound window configurations

So far we've assumed a fixed configuration for inbound windows as we had
a single user for this controller. But the controller's DMA constraints
were improved starting with BCM2711's B1 revision of the SoC, notably
available in CM4 and Pi400. They allow for wider inbound windows. We can
now cover the whole address space, whereas before we where limited to
the lower 3GB.

This information is passed to us through DT's 'dma-ranges' property and
it's specially important for us to honor it them since some interactions
with the board's co-processor assume we're doing so (specifically the
XHCI firmware load operation, which is handled by the co-processor after
u-boot has correctly configured the PCIe controller).
. . .
END QUOTE

I'll note an implication of the dma-ranges for RPi4's being
possibly dynamically adjusted before being handed to the kernel
--instead of just hardcoded in the bcm2711-rpi-4-b.dtb file
provided by the RPi firmware. (There are bcm2711-rpi-400.dtb
and bcm2711-rpi-cm4.dtb files as well.)