card did not respond to voltage select -110

[APTI]

I have a raspberry pi 4 b 8G ram... i had it working great with fedora until the ssd died. Now I put the image on the new and yes it is brand new ssd, and I get "card did not respond to voltage select -110" on boot. it just sits there on it. I can see the boot options in uboot but the error happens. I am beating my head against the wall on this one. I have never had a problem like this before and very little information on it. I can put rasberry pi os on the chip and it boots and runs fine. However I am wanting to get fedora back on it and I get this error. I have redownloaded OS so that is not the issue. the pi is working fine with rapberry pi os on it. it is not the chip it checks fine and works with RPOS on it. What could be causing this error and how do I get past it? I am frustrated with this now and asking for some help.
I should not have to say this but I want real help not things like use another flavor of OS, that is not a good option. I can tell it is not a power issue as the voltage is supplied by a battery. Yes this is robotic project so the battery is 18v going into a buck board set to 5.086 volts.
Looking for direction and keep in mind it is working with RPOS and used to work with fedora until having to reload using balena etcher and fedora media writer.

 

[theLegionWithin]

poked around for a bit and from what I can find the "card did not respond to voltage select -110" issue seems to be a u-boot issue as it doesnt just affect raspberry pi's but several other sbc's. presumably the firmware is bad/corrupted.

now, how to recompile u-boot and whatnot? I dont know if I'd trust these "AI" steps, and I dont have a raspberry pi myself, but here ya go: https://www.google.com/search?clien...poWPAxVtFTQIHX7_Ij8Q0NsOegQIQxAA&aep=10&ntc=1

 

[APTI]

poked around for a bit and from what I can find the "card did not respond to voltage select -110" issue seems to be a u-boot issue as it doesnt just affect raspberry pi's but several other sbc's. presumably the firmware is bad/corrupted.

now, how to recompile u-boot and whatnot? I dont know if I'd trust these "AI" steps, and I dont have a raspberry pi myself, but here ya go: https://www.google.com/search?clien...poWPAxVtFTQIHX7_Ij8Q0NsOegQIQxAA&aep=10&ntc=1

I got about as far as you, I think I would prefer to find something that works rather than compile new and hope. Not to mention update overwriting the working version. But at least you are confirming my suspicions, so any other option that may work?

 

[Trml]

I saw your question regarding raspi dual-boot.

I don't have experience with dual-boot on the pi, but may have pointers. E.g. I run Openbsd on a pi 4b and was surprised how smooth that installation went. Once I find time, I'll have a look at its boot setup.

I saw this topic only yesterday, assume it is about the same issue, and reply here not to disrupt the other thread discussion with off-topic technical.

 

[Trml]

I had a look and the Openbsd did not yield anything at first glance. It uses a boota64.efi, which should be similar to what fedora does, but it does not show any of the dtb files piOS /boot contains. I also searched for your error message and the interwebs are absolutely splattered with it for all sorts of SBC and all sorts of distros (far wider than pi/fedora). Some pointed to power supply, as does the fedora wiki. From there I had a browse for solutions to multiboot. There are some custom solutions I saw, e.g. https://forums.raspberrypi.com/viewtopic.php?t=282912 and another called PINN. You might want to check if one of those supports fedora for this route. If not one could certainly devise a custom one; simplest would be to use grub - which should be supported by default both for PiOS and fedora (i.e. avoiding u-boot).

Finally, I had a look at u-boot and saw the project supports two different device configs:

Raspberry Pi — Das U-Boot unknown version documentation

Quote
"

• rpi_4_defconfig- Raspberry Pi 4b​
• rpi_arm64_defconfig- Raspberry Pi 3b- Raspberry Pi 3b+- Raspberry Pi 4b- Raspberry Pi 400- Raspberry Pi CM 3- Raspberry Pi CM 3+- Raspberry Pi CM 4- Raspberry Pi zero 2​

rpi_arm64_defconfig uses the device-tree provided by the firmware instead ofthe embedded one. It allows to use the same U-Boot binary to boot differentboards.
"

Whatever fedora's uboot uses, it can only be one of the defconfig's. Maybe fedora git has related changes that made it start to fail. To stick with u-boot I would look for those and how to try the other one.

My absolute recommendation remains that you simply use an USB3 connected SSD. I understand if you want to stick to a proven fedora desktop image for your project, but SD-cards are simply not suited for a system that permanently writes stuff.

 

[APTI]

I had a look and the Openbsd did not yield anything at first glance. It uses a boota64.efi, which should be similar to what fedora does, but it does not show any of the dtb files piOS /boot contains. I also searched for your error message and the interwebs are absolutely splattered with it for all sorts of SBC and all sorts of distros (far wider than pi/fedora). Some pointed to power supply, as does the fedora wiki. From there I had a browse for solutions to multiboot. There are some custom solutions I saw, e.g. https://forums.raspberrypi.com/viewtopic.php?t=282912 and another called PINN. You might want to check if one of those supports fedora for this route. If not one could certainly devise a custom one; simplest would be to use grub - which should be supported by default both for PiOS and fedora (i.e. avoiding u-boot).

Finally, I had a look at u-boot and saw the project supports two different device configs:

Raspberry Pi — Das U-Boot unknown version documentation

Quote
"

• rpi_4_defconfig- Raspberry Pi 4b​
• rpi_arm64_defconfig- Raspberry Pi 3b- Raspberry Pi 3b+- Raspberry Pi 4b- Raspberry Pi 400- Raspberry Pi CM 3- Raspberry Pi CM 3+- Raspberry Pi CM 4- Raspberry Pi zero 2​

rpi_arm64_defconfig uses the device-tree provided by the firmware instead ofthe embedded one. It allows to use the same U-Boot binary to boot differentboards.
"

Whatever fedora's uboot uses, it can only be one of the defconfig's. Maybe fedora git has related changes that made it start to fail. To stick with u-boot I would look for those and how to try the other one.

My absolute recommendation remains that you simply use an USB3 connected SSD. I understand if you want to stick to a proven fedora desktop image for your project, but SD-cards are simply not suited for a system that permanently writes stuff.

The project is a robotic project that runs headless. It runs off of battery so power consumption is very high on the requirement list. Powering a hard drive or ssd could reduce life. The SD card is almost entirely read only. very very very few writes once set up. What is needed is the simplest way to make it work. It was great while it did work but the project sat on hold for a couple months and then the SD card was blown. Simple replacement, not. Get a name brand and reload the Fedora OS and, well you read the issues.
What is needed is to get Fedora working on this the way it had been. Have it run headless and reliably. Human intervention is not allowed once it is running, other than telling the robot to execute a program of course.
I can say that I have seen PI's with power supply issues, but that is not the case here. The dedicated battery that supplies power to the pi is an 18V battery that runs to a buckboard to regulate the voltage at 5.03V with amperage of 3 to 4. It is pretty solid there. So when somebody blames the power supply they are wrong in this case. The power supply is custom designed for the PI and very solid.
Our backup plan is to switch it to RPIOS at the end of September if Fedora is not fixed.

 

[Trml]

You ask for direction in your original post. The first thing you should do is a solid reproduction of the issue using a rasppi certified power supply. Once you have done that, repeat the same with full debug symbols. Only then repeat it with your custom mobile power supply. Without questioning your related experience in any way, your issue report will need both as substance for any third-party analyzing your issue.

 

[APTI]

You ask for direction in your original post. The first thing you should do is a solid reproduction of the issue using a rasppi certified power supply. Once you have done that, repeat the same with full debug symbols. Only then repeat it with your custom mobile power supply. Without questioning your related experience in any way, your issue report will need both as substance for any third-party analyzing your issue.

that was actually one the first things done. Needed to make sure the power was adequate so matched the buckboards to a working RPI power supply. Have also used it on the bench to ensure all was ok. Checked it using RPIOS and it said it was fine one both supplies. I was fairly thorough in my approach, or at least I think I was.
It took a bit but finally got to bugzilla to make a proper report of the person. Had to go through redhat to get the information but was able to see the code of conduct and that allowed me to point out multiple violations line by line.
although reporting the person was more a tangent, My main goal is to get the problem looked at and fixed. For a person with access to the information they should be easily able to stop the voltage adjust or fix it. I hope.
You mention using debug symbols, you just hit something I am not familiar with. Can you explain that a bit? Keep in mind the system does not even boot, in fact it loses connection with the sd card due to this error. I can't even get to grub.

 

[Trml]

It runs off of battery so power consumption is very high on the requirement list. Powering a hard drive or ssd could reduce life.

I forgot to mention: Out of curiosity and to keep footprint low, I measured power consumption of our pi 4b with USB3 attached SSD (budget 500MB sata ssd, Intenso brand in an external enclosure) at the power socket for about a month last year. It runs default piOS desktop, no sd-card, has a monitor and keyboard attached but is used headless usually. Mentioning the details, since it's possible to deactivate hdmi port etc for power savings and I did none of that. It idles at 3.8w to 4.2w including SSD.

If that's low enough for you to test USB boot, make sure the rpi-eeprom is updated, the new firmware provides easy default boot order configuration since beginning of this year (or was it '24?).

 

[APTI]

I forgot to mention: Out of curiosity and to keep footprint low, I measured power consumption of our pi 4b with USB3 attached SSD (budget 500MB sata ssd, Intenso brand in an external enclosure) at the power socket for about a month last year. It runs default piOS desktop, no sd-card, has a monitor and keyboard attached but is used headless usually. Mentioning the details, since it's possible to deactivate hdmi port etc for power savings and I did none of that. It idles at 3.8w to 4.2w including SSD.

If that's low enough for you to test USB boot, make sure the rpi-eeprom is updated, the new firmware provides easy default boot order configuration since beginning of this year (or was it '24?).

If I am wrong please tell me, but the firmware is not like a bios update written to the chips. it is a file found at boot. Which is where the problem lies for fedora. I will see about the eeprom update and hope it helps. I would prefer to not have to add an ssd as it will require another design change in the framework to hold it. However if that is the only way I will redesign again.

just checked and eeprom is up to date with a 2023 date on it. have to order the usb to sata connection so back to waiting

 

[Trml]

The pi 4b has an eeprom, 512Kb I believe, and like a bios, yes. You can up-/downgrade it. Theoretically (if it was upgraded), it could introduce a regression too. I don't know how fedora uses uboot, which can act as first/second stage bootloader. You find releases on github and the https://www.raspberrypi.com/documen...pi.html#raspberry-pi-bootloader-configuration
documentation gives info on various methods to enable and capture debug output.

Regarding the power consumption: our said Pi runs on ethernet, i.e. the watt figure I measured does not include wifi/bluetooth.