Description of problem: While with 20180310 compose the RPi3 did not automatically boot because of bug 1552130, with 20180314 compose the uboot prompt never appears: the display stays stuck at the "multicolor" screen. Version-Release number of selected component (if applicable): Fedora-Minimal-armhfp-28-20180314.n.2-sda.raw Fedora-Xfce-armhfp-28-20180314.n.2-sda.raw.xz bcm283x-firmware-20180307-1.7fdcd00.fc28
I believe this might be an issue with u-boot not firmware. Also looks to be RPi3 only (not RPi2)
I've not been able to recreate this with Fedora-Minimal-armhfp-28-20180314.n.2-sda.raw.xz on a couple of different RPi3s. I'm wondering if there's not been a power regression which is causing the device to pull too much power while booting the firmware and that the PSU might not be coping. What is the rating of the PSU you're using?
(In reply to Peter Robinson from comment #2) > I'm wondering if there's not been a power regression which is causing the > device to pull too much power while booting the firmware and that the PSU > might not be coping. What is the rating of the PSU you're using? I will check ASAP. However, as said before, using 20180310 compose at least uboot prompt appears. And F27 boots without issues as well. Obviously using the same PSU and SD card on the same RPi.
> However, as said before, using 20180310 compose at least uboot prompt Sure, that doesn't mean there's not regressions in power consumption as stated. > appears. And F27 boots without issues as well. Obviously using the same PSU > and SD card on the same RPi. See above. We usually only see rainbow in two circumstances 1) incompatible RPi (zero, original editions) 2) now a powerful enough PSU. I've tested this across 4 different RPis, includingthe 3+, and not managed to recreate it so I'm trying to ascertain why that is.
(In reply to Peter Robinson from comment #4) > See above. We usually only see rainbow in two circumstances 1) incompatible > RPi (zero, original editions) 2) now a powerful enough PSU. I've tested this > across 4 different RPis, includingthe 3+, and not managed to recreate it so > I'm trying to ascertain why that is. Well. I will try again ASAP. Maybe my fault on copying the image on the SD card, maybe I have to try another PSU. I'm using arm-image-installer on F27 workstation to copy the image to the SD, do you? Thanks.
> I'm using arm-image-installer on F27 workstation to copy the image to the > SD, do you? I use a-i-i but on F-28, completely irrelevant though
(In reply to Peter Robinson from comment #2) > I'm wondering if there's not been a power regression which is causing the > device to pull too much power while booting the firmware and that the PSU > might not be coping. What is the rating of the PSU you're using? The PSU is 5V - 3000ma
Update. I've used another microSD. And... it works! The previous SD, that works well with F27 and 20180310 compose, is a Samsung EVO+ 32GB U1 This "new" one is a SanDisk 16GB C10
I reproduced this using a Samsung EVO 16G card, other cards seem to work ok(tested S&P, A-Data). The Samsung card works when I use bcm283x-firmware-20180209-1.b1a7f4a.fc28.
Do you have another similar rated PSU you could try with the same SD card, I suspect there's been some change with the firmware but we'll need to engage with the vendor for this, and to do that we'll need more data, likely test some more firmwares too.
I tested using the official 2.5a, Official 2a and a Geekworm 3a PSU with no change using the Samsung card.
Scratch build here that should fix the problem, please test https://koji.fedoraproject.org/koji/taskinfo?taskID=25756818 you can install the uboot-images-armv7 noarch rpm on x86 and copy the rpi3_32 u-boot binary on the vfat partition
(In reply to Peter Robinson from comment #12) > Scratch build here that should fix the problem, please test > > https://koji.fedoraproject.org/koji/taskinfo?taskID=25756818 > > you can install the uboot-images-armv7 noarch rpm on x86 and copy the > rpi3_32 u-boot binary on the vfat partition It doesn't seem to solve the issue. However, I mounted the 20180310 compose. By process of elimination, I copied the files in the vfat partition from such compose, inside the vfat parition of the 32GB SD card (containing the 20180314 compose). The file that allows the system to move forward in the boot process, leaving all the other files unchanged, seems to be start_cd.elf from 20180310 compose. Subsequently there is a kernel panic after unpacking the initramfs. This make sense?
Well. I extracted the content of bcm283x-firmware-20180307-1.7fdcd00.fc28 in the vfat partition, and same issue as this bug. Using instead the content of bcm283x-firmware-20180209-1.b1a7f4a.fc28 I'm able to reach the initial setup!
Scratch build seems to be working with bcm283x-firmware-20180307-1.7fdcd00.fc28 U-Boot 2018.03 (Mar 17 2018 - 07:58:37 +0000) DRAM: 998 MiB RPI 3 Model B (0xa22082) MMC: mmc@7e202000: 0, sdhci@7e300000: 1 Loading Environment from FAT... *** Warning - bad CRC, using default environment Failed (-5) In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0
> However, I mounted the 20180310 compose. > By process of elimination, I copied the files in the vfat partition from > such compose, inside the vfat parition of the 32GB SD card (containing the > 20180314 compose). > The file that allows the system to move forward in the boot process, leaving > all the other files unchanged, seems to be start_cd.elf from 20180310 > compose. > Subsequently there is a kernel panic after unpacking the initramfs. > > This make sense? No, not really TBH. Which files did you copy, from where to where. You mentioned you copied from the 20180310 compose to what compose/image.
arm-trusted-firmware-1.5-0.4.rc3.fc28 bcm283x-firmware-20180316-1.25cf637.fc28 uboot-tools-2018.03-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1556e768e2
(In reply to Peter Robinson from comment #16) > > Which files did you copy, from where to where. You mentioned you copied from > the 20180310 compose to what compose/image. Never mind. However now, with the latest builds, it works even on the 32GB SD card, following these steps: - using compose Fedora-Minimal-armhfp-28-20180319.n.0-sda.raw.xz (that still doesn't work as it is) - copy the content of ../bcm283x-firmware-20180316-1.25cf637.fc28.armv7hl.rpm to the vfat partition on the SD card - copy the rpi_3_32b/u-boot.bin file from uboot-images-armv7-2018.03-3.fc28.noarch.rpm to the vfat partition on the SD card, renaming it to rpi3-u-boot.bin Thanks.
arm-trusted-firmware-1.5-0.4.rc3.fc28, bcm283x-firmware-20180316-1.25cf637.fc28, uboot-tools-2018.03-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1556e768e2
Proposed as a Blocker for 28-beta by Fedora user pbrobinson using the blocker tracking app because: Not sure if this is a blocker or a FE, but basically there's some SD cards (primarily seems to be Samsung EVO) that fail to boot that previously worked on the Raspberry Pi. An updated uboot/firmware combination from upstream feedback has been confirmed to fix this issue.
I'd call this a clear +1 FE; I don't think it would pass the "last blocker" test, because it's only a subset of cards[*] that are involved. In other words, if this fix from upstream isn't complete, I wouldn't slip *just* for this. But since we have a suspected fix, let's include it. [*] Of course, it *would* happen to be the one I just ordered with my new RPi3...
+1 FE
Agree with Stephen's rationale, clear +1 FE. That's +3, setting accepted.
I also endorse the wording 'suspected fix'. All fixes are suspicious. :P
Yeah, +1 FE for sure. I also don't think I would call it a blocker as it's limited in scope.
+1 FE since its happening only on certain SD cards.
arm-trusted-firmware-1.5-0.4.rc3.fc28, bcm283x-firmware-20180316-1.25cf637.fc28, uboot-tools-2018.03-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.