Bug 255080

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

(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.

Do you have a mouse connected? I've seen the same thing with my device when a mouse is connected.

(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.

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!

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.

(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.

(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.

(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

Created attachment 224199 [details]
rPi OS CPU info

Created attachment 224200 [details]
FreeBSD 13-RELEASE "boot -v" dmesg

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.

(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.)

(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.

(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.

(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 .

(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.

(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.)

(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

(In reply to Mark Millard from comment #19)

I incorrectly wrote "not" twice. Trying again:

(A) would definitely not lead to b03114 changing.

(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.

(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

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).

(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".

(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.

(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.

(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.

(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.

(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.

(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.

(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 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

(In reply to Wen Heping from comment #32)

do you have dmesg/console-output/OS-version/firmware-version(if not current default release- image) ?

(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 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

(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.

(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 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

(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.

(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.

(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.

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.

(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 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 2021-04-25 23:22:25 UTC

(In reply to Mark Millard from comment #43)
Thank you !

wen

(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.

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.)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256441 may also be related to this U-boot issue.  I created a separate ticket since I thought it was a bit different to this one, but maybe it has the same underlying cause.

(In reply to Roger Leigh from comment #48)

Nothing in this bugzilla has the error message that contains:

Failure to add disk device usb_mass_storage.lun0

which yours does. It is a separate issue.

I tried to install latest FreeBSD 14 snapshot FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20211028-4827bf76bce-250301.img.xz and dd-ed this image to the microSD card for Raspberry Pi 3b+.

The result is still the same - no MMC device:

U-Boot> mmc info
MMC Device 0 not found
no mmc device at slot 0
U-Boot> mmc part
MMC Device 0 not found
no mmc device at slot 0
U-Boot> mmc list
mmc@7e300000: 2
U-Boot> version
U-Boot 2021.7 (Oct 28 2021 - 05:44:44 +0000)

aarch64-none-elf-gcc (FreeBSD  Ports Collection for aarch64noneelf) 8.4.0
GNU ld (GNU Binutils) 2.37

A full log from the serial console:

U-Boot 2021.07 (Oct 28 2021 - 05:44:44 +0000)

DRAM:  948 MiB
RPI 3 Model B+ (0xa020d3)
MMC:   mmc@7e300000: 2
Loading Environment from FAT... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: usb dr_mode not found
USB DWC2
scanning bus usb@7e980000 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1

Device 0: unknown device
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/01-b8-27-eb-fe-70-8a
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-bcm283x
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
Config file not found
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed
lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup failed

U-Boot> mmc info
MMC Device 0 not found
no mmc device at slot 0
U-Boot> mmc part
MMC Device 0 not found
no mmc device at slot 0
U-Boot> mmc list
mmc@7e300000: 2
U-Boot> version
U-Boot 2021.07 (Oct 28 2021 - 05:44:44 +0000)

aarch64-none-elf-gcc (FreeBSD Ports Collection for aarch64noneelf) 8.4.0
GNU ld (GNU Binutils) 2.37

U-Boot> bdinfo
boot_params = 0x0000000000000100
DRAM bank   = 0x0000000000000000
-> start    = 0x0000000000000000
-> size     = 0x000000003b400000
flashstart  = 0x0000000000000000
flashsize   = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate    = 115200 bps
relocaddr   = 0x000000003b35a000
reloc off   = 0x000000003b2da000
Build       = 64-bit
current eth = lan78xx_eth
ethaddr     = b8:27:eb:fe:70:8a
IP addr     = <NULL>
fdt_blob    = 0x000000003af4e750
new_fdt     = 0x000000003af4e750
fdt_size    = 0x0000000000007640
Video       = fb active
FB base     = 0x000000003eaf0000
FB size     = 656x416x32
lmb_dump_all:
    memory.cnt             = 0x1
    memory.reg[0x0].base   = 0x0
                   .size   = 0x3b400000

    reserved.cnt           = 0x2
    reserved.reg[0x0].base = 0x0
                     .size = 0x1000
    reserved.reg[0x1].base = 0x3af4d370
                     .size = 0x4b2c90
arch_number = 0x0000000000000000
TLB addr    = 0x000000003b3f0000
irq_sp      = 0x000000003af4e740
sp start    = 0x000000003af4e740
Early malloc usage: 598 / 2000
U-Boot>

(In reply to Anton Kochkov from comment #50)

yes, there seems to be a mismatch of file-versions in the release again(I didn't research the issue for now)...
for a quick fix you can override this one(u-boot.bin 2020.10) to your msdods-partition:  

https://sourceforge.net/projects/freebsd-bug-id-255080/files/u-boot.bin/download

(In reply to Klaus Küchemann from comment #15)
Are you able to share the configuration you use for building this?