Rainbow screen with some SD cards on 3A+, 3B, 3B+ but not Pi 2 (Was: v1.30 doesn't boot past rainbow on 3A+, 3B, 3B+. Works on Pi 2 v1.2) #24
Comments
|
Crazy thing. I went back to 1.27 and it wasn't working and I know for a fact that release worked. The SD card. No explanation yet, but my "Samsung EVO 32Gib" doesn't work in 3A+/3B/3B+, while SanDisk Ultra Plus does. |
andreiw
changed the title
|
This issue seems to have the same symptoms as #17 |
|
Also affects my Samsung EVO 32GB on RPi UEFI v1.36. Related serial log: Issues #17 and #33 are the same thing. As @rob-the-dude mentioned there, the following bit is key:
My observations:
@rob-the-dude: might be interesting to add what kind of SD card you're seeing this on, as I'm tallying 3x Samsung EVO thus far.. It can be reproduced with just ARM TF-A (I did use config.txt from UEFI release v1.36). Check out ARM TF-A: I used UEFI release v1.36 as firmware base, then swapped out I've been able to reproduce it on v2.3, v2.4, v2.5 of ARM TF-A; earlier releases fail to initialize the UART correctly. Someone on #17 suggests downgrading RPi3 UEFI to v1.24 worked for them; as that contains ARM TF-A v2.3 downgrading the Raspberry Pi firmware might offer additional clues... |
|
I had another go at hunting this down based on the clues provided in the linked issue - this time by bisecting the Raspberry Pi firmware: The previous commit (9e3c23ce77) boots fine whereas 11a76e07ef consistently fails to boot as long as it's a decently warm boot (left it to idle on UEFI setup for a few minutes prior to testing). This also means this project's release v1.23 is the last to ship a good firmware revision for SD cards affected. Unfortunately, the commit message is rather nondescript, but does suggest an upstream branch switch is involved. start.elf 11a76e07ef: start.elf 9e3c23ce77: This doesn't rule out it ends up being a bug in TF-A, but someone from Raspberry Pi might be able to tell whether there are in fact relevant changes between these start.elf revisions. Tagging in case they might be able to investigate on their end: @pelwell @popcornmix |
|
Just to warn you - that update contains probably the largest number of changes for non-Pi 4 devices. |
|
Well, I know it's been a LONG time since I chimed in on this, but I just encountered it again. I've been using u-boot instead of UEFI for the past year or so, and didn't run into this issue. But I recently dusted some stuff off and tried to get UEFI working again. And I hit this problem again, on two different SDs: a Samsung 64 EVO Plus and a KOOTION 64 GB (bought off Amazon). The Samsung booted once (from cold boot) but would not warm boot afterward. The KOOTION failed each time I tried. So I copied the u-boot.bin and adjusted the config.txt file to use it instead of RPI_EFI.fd. I did 5 warm reboots in a row without failure. Then I tweaked the config.txt file back to load RPI_EFI.fd, and it failed again on the first time. I feel somewhat confident that the problem is in UEFI's handling of the RPI 3B+ SD interface. I've never seen u-boot fail with these cards. And now I seem to be able to reproduce the failure with UEFI regularly, while never reproducing it with u-boot. |
Same here - or well, I reboot my Raspberry Pi 3 infrequently enough to completely forget about needing a cold reboot and then end up Googling to re-read my own analysis..
More specifically that would be ARM TF-A (used by RPi UEFI). Refer my comment prior to this where I managed to reproduce it without UEFI and just TF-A. I didn't dig any further in 2021, as proprietary VideoCore firmware is somehow involved which means it's best suited for the Raspberry Pi Foundation to sort out. Hardware documentation (for the RPi SDHOST controller) neither is available to the general public. My best guess is that it's some sort of timing issue. The observation that the failure case can be avoided by cold booting (as in actually cold) is interesting - some sort of a clocking issue affected by temperature? Things that might help:
Bonus, intriguing snippet from the BCM2835 ARM Peripherals document:
Neither driver touches those registers, though. |
sdhost controller (initial clock rate, bus width), and then configure those parameters. This change allows warm reboots of UEFI on Raspberry Pi 3B+ where existing code often fails with "unknown error". See discussion at: pftf/RPi3#24 The basic problem was that a number of SD commands are issued before sensible initialization configurations have been committed. I suspect that the primary culprit is setting the "slow card" bit, but the initial clock rate also seemed wrong, as did the missing voltage settings.
|
I spent some time comparing and debugging with both u-boot and TF-A. I've got a small patch that fixes this problem for me, though I have very limited ability to test it. ARM-software/arm-trusted-firmware#1995 The basic idea is that some initial configuration parameters (clock rate, bus width) aren't configured into the hardware before commands start being sent. I suspect that the particular setting that matters is the "slow card" bit, but the initial clock setting also seemed wrong to me. I'm certainly interested in feedback. I don't quite know how to push for this to be included in ARM's TF-A, but I've at least put it up here so folks can see it. |
Add initial configuration parameters for Rasperry Pi 3's sdhost controller, and then configure and use those parameters. This change allows warm reboots of UEFI on Raspberry Pi 3B+ where existing code often fails with "unknown error". See discussion at: pftf/RPi3#24 The basic idea is that some initial configuration parameters (clock rate, bus width) aren't configured into the hardware before commands start being sent. I suspect that the particular setting that matters is the "slow card" bit, but the initial clock setting also seemed wrong to me. Change-Id: I526def340def143f23f3422f1fc14c12c937ca7f Signed-off-by: Rob Newberry <[email protected]>
|
The fix I provided has been merged into TF-A. A new build of UEFI for RPi3 with that fix included will hopefully resolve this issue. |
|
@rob-the-dude, thanks for doing this. To keep in line with what we've been doing until now when it comes to TF-A, we'll have to wait for the formal v2.9 release so that we can use https://github.com/pftf/pitf to build the TF-A binaries. Then, we'll need to submit these binaries for integration in https://github.com/tianocore/edk2-non-osi/tree/master/Platform/RaspberryPi/RPi3/TrustedFirmware. And once that is done, we'll be able to build a new RPI3 UEFI firmware that integrates these changes... |
|
Glad to help, and that sounds like a great plan. Thanks!
… On Apr 18, 2023, at 4:08 AM, Pete Batard ***@***.***> wrote:
@rob-the-dude <https://github.com/rob-the-dude>, thanks for doing this.
To keep in line with what we've been doing until now when it comes to TF-A, we'll have to wait for the formal v2.9.0 release so that we can use https://github.com/pftf/pitf to build the TF-A binaries.
Then, we'll need to submit these binaries for integration in https://github.com/tianocore/edk2-non-osi/tree/master/Platform/RaspberryPi/RPi3/TrustedFirmware.
And once that is done, we'll be able to build a new RPI3 UEFI firmware that integrates these changes...
—
Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKLXWJJFTRTS3NJBFDSSU6LXBZYZVANCNFSM4SMNN7UA>.
You are receiving this because you were mentioned.
|
…boot The newly released TF-A v2.9 contains a fix for an issue that has been affecting some Raspberry Pi 3 users, when trying to issue a reboot with some types of SD cards (See: pftf/RPi3#17, pftf/RPi3#24). This fix is documented at: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20297 We also use this opportunity to update the TF-A binaries for RPi4. Signed-off-by: Pete Batard <[email protected]> Acked-by: Ard Biesheuvel <[email protected]>
|
this is confirmed to be a non-issue anymore ? |
This is an interesting one since the image boots on the 64-bit Pi 2 but hangs on Pi 3/3B+/3A+.
I did not check serial.
The text was updated successfully, but these errors were encountered: