Description of problem: After upgrading to bcm283x-firmware-20210819-1.25e2b59.fc35 the Raspberry Pi 3b is extremely slow in uboot and usually fails to boot into linux. Version-Release number of selected component (if applicable): bcm283x-firmware-20210819-1.25e2b59.fc35 How reproducible: Most of the time. Additional info: Downgrading to bcm283x-firmware-20210714-1.7208c3d.fc35, the RPi3 works as expected. No errors or performance issues when booting the RPi4.
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.
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 stable repository. If problem still persists, please make note of it in this bug report.