Bug 1999180

U-Boot 2021.10-rc2 (Aug 23 2021 - 00:00:00 +0000)

DRAM:  992 MiB
RPI 3 Model B+ (0xa020d3)
MMC:   sdhci_setup_cfg: Hardware doesn't specify base clock frequency
sdhci_setup_cfg: Hardware doesn't specify base clock frequency
mmcnr@7e300000 - probe failed: -22
mmc@7e202000: 0sdhci_setup_cfg: Hardware doesn't specify base clock frequency

Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: 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
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
Found DTB mmc 0:2 /dtb/broadcom/bcm2837-rpi-3-b-plus.dtb
14630 bytes read in 107 ms (132.8 KiB/s)
827392 bytes read in 4487 ms (179.7 KiB/s)
Scanning disk mmc...
sdhci_setup_cfg: Hardware doesn't specify base clock frequency
Scanning disk mmcnr...
Disk mmcnr not ready
Found 4 disks
No EFI system partition
Booting /efi\boot\bootaa64.efi

The errors are the same on the Raspberry Pi 4, they just go by with no noticeable slow down. 

U-Boot 2021.10-rc2 (Aug 23 2021 - 00:00:00 +0000)

DRAM:  2 GiB
RPI 4 Model B (0xb03111)
MMC:   sdhci_setup_cfg: Hardware doesn't specify base clock frequency
sdhci_setup_cfg: Hardware doesn't specify base clock frequency
mmcnr@7e300000 - probe failed: -22
sdhci_setup_cfg: Hardware doesn't specify base clock frequency

Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:    serial
Out:   serial
Err:   serial
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
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
Found DTB mmc 0:2 /dtb/broadcom/bcm2711-rpi-4-b.dtb
26385 bytes read in 23 ms (1.1 MiB/s)
827392 bytes read in 58 ms (13.6 MiB/s)
sdhci_setup_cfg: Hardware doesn't specify base clock frequency

Reproduced with F34 Uboot, installing only the new firmware

U-Boot 2021.04 (Apr 21 2021 - 00:00:00 +0000)

DRAM:  992 MiB
RPI 3 Model B+ (0xa020d3)
MMC:   sdhci_setup_cfg: Hardware doesn't specify base clock frequency
sdhci_setup_cfg: Hardware doesn't specify base clock frequency
mmcnr@7e300000 - probe failed: -22
mmc@7e202000: 0sdhci_setup_cfg: Hardware doesn't specify base clock frequency

Loading Environment from FAT... fsm 1, hsts 00000080
read timeout error - HSTS 00000080
WARNING at drivers/mmc/bcm2835_sdhost.c:414/bcm2835_send_command()!
WARNING at drivers/mmc/bcm2835_sdhost.c:382/bcm2835_prepare_data()!
WARNING at drivers/mmc/bcm2835_sdhost.c:414/bcm2835_send_command()!
WARNING at drivers/mmc/bcm2835_sdhost.c:414/bcm2835_send_command()!
unable to select a mode
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: 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 
WARNING at drivers/mmc/bcm2835_sdhost.c:414/bcm2835_send_command()!
fsm 1, hsts 00000080
read timeout error - HSTS 00000080
WARNING at drivers/mmc/bcm2835_sdhost.c:414/bcm2835_send_command()!
WARNING at drivers/mmc/bcm2835_sdhost.c:382/bcm2835_prepare_data()!
WARNING at drivers/mmc/bcm2835_sdhost.c:414/bcm2835_send_command()!
WARNING at drivers/mmc/bcm2835_sdhost.c:414/bcm2835_send_command()!
unable to select a mode
no mmc device at slot 1

Device 0: unknown device
lan78xx_eth Waiting for PHY auto negotiation to complete...... done
BOOTP broadcast 1
DHCP client bound to address 192.168.0.39 (4 ms)
Using lan78xx_eth device
TFTP from server 192.168.0.20; our IP address is 192.168.0.39

This seems to be dependant on the mSD card with RPi3. I have some that work despite the errors, others do not. When it works there is also a significant delay to boot.

I see this with the arm-image-installer built images on the rpi3 as well, although I've never seen it actually boot Linux. It starts the boot process, clears the screen and its (apparently) dead. The current pftf (DT) rpi3 images have recent DT's/etc too and seem to work fine, so I will roll the uboot/etc back and see if I can isolate where what changed.

Looking at the code, it probably has something to do with the start* firmware files since uboot is recovering the SD clock rates from the rpi mailbox interface.

I rolled the start_x and fixup_x files back and the messages are gone and it sorta works now. I was using the workstation disk, and the initial setup menu probably showed up at some point (or it was blank, I got a menu I should have been able to modify at one point), but generally, it boots to the "starting gnome manager" line now. If I start it multiuser it boots up to the login prompt (I'm giving it selinux=0 now too), but I can't actually login because the root password wasn't set but first run apparently got disabled.

Anyway, I'm not really sure how any of this is working at the moment with the new rpi firmware, it looks like uboot is mostly doing the right thing although I'm not 100% sure it powering on the right device (I big hammer it for edk2 and power everything that looks suspicious, the rpi mailbox docs aren't great) before trying to read the clock rate. Its that mailbox call which is now failing and causing uboot to go bonkers and fail to program the mmc divisors correctly (or even at all since it bails when it discovers max_clk==0). 

I should say the latest ptft firmware are also having assorted DT boot problems, which we apparently are getting lucky and avoiding with ACPI. In fact the mailbox failing to respond would have likely caused the 5.14 kernel clock patch that I complained about to fail with DT too.

Tested using RPi3 and Fedora-Workstation-35-20210907.n.0.aarch64.raw.xz as well as Fedora-Minimal-35-20210907.n.0.aarch64.raw.xz. Both do eventually boot, however there is a 10-12 minute wait time after GRUB. When booting with an RPi4, the delay is much less (a matter of seconds). I will propose this as a blocker as it could be argued that this is not a reasonable amount of time to wait for a positive user experience. That said, I don't think we could get the upstream support as quickly as we would need in order not to slip our Beta milestone... Would like to propose as a blocker if anything to get some discussion on what to do.

Proposed as a Blocker for 35-beta by Fedora user coremodule using the blocker tracking app because:

 Proposing as a violation of the basic criterion, "Release-blocking dedicated installer images must boot to the expected boot menu, and then after a reasonable timeout to the installer." [0]

[0] https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_image_boot_behavior

+3 in https://pagure.io/fedora-qa/blocker-review/issue/439 , marking accepted. We do note that this may wind up having to be waived for Beta if it can't be fixed in a reasonable time.

FEDORA-2021-2722ec19d0 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-2722ec19d0

FEDORA-2021-2722ec19d0 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-2722ec19d0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-2722ec19d0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-2722ec19d0 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-b1079b7042 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b1079b7042

FEDORA-2021-b1079b7042 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b1079b7042`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b1079b7042

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-b1079b7042 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b1079b7042

Proposed as a Blocker for 35-final by Fedora user pbrobinson using the blocker tracking app because:

 This is the proper firmware fix from upstream which we need in GA so upgrades (should, this is a RPi foundation firmware fix afterall) continue to work properly

FEDORA-2021-b1079b7042 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b1079b7042`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b1079b7042

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-b1079b7042 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.