BOOT ERROR: Code 45 - 'Fatal firmware error' (Large partitions >1GB)

[wlcina]

Describe the bug
Rpi 500+ wont boot with some systems installed. I changed the partition size (not default recommended by PINN) - this seems to be an issue

To reproduce
Clean install of PINN on RPI 500+, I added Batocera_RPi5, raspios_arm64_full, LibreElec_RPi5 and DietPi_RPi5
PINN boots well
I choose particular partition size eg for Batocera about 1.5TB for raspios 512GB, Elec 32GB, and rest for DietPI, that seems to be an issue, maybe partition size has some kind of requirement??

From OS:
Batocera boots well, no issues

raspios_arm64_full, LibreElec_RPI5, does not boot, the same error message appears while trying to boot

HID [01:00] 2.00 000000:02 register HID
VID 0x1e4b MN Vi3000 Internal PCIe NVMe M.2 SSD 2TB
NVME on 0
Trying partition: 0
type: 16 lba: 8192 'mkfs.fat' ' V ^ ' ckysters 64887 (4)
Trying partition: 8
Unexpected error @ 0x3fc114b2
BOOT ERROR: code 45 - 'Fatal firmware error'

and raspberry pi power on button starts to blink in sequence: 4x long green blinks, then 5x fast green blinks, a bit pause and repeating the sequence

Expected behaviour
Boot any OS I installed through PINN

Actual behaviour
OSes does not boot

System
RPi 500+
PINN v3.9.3 built: Nov 22 2024
edit 1) tried also with the latest (downloaded from git) 3.9.7, the issue remains (even I installed each oses through PINN again)
edit 2) tried also on 4TB samsung NVME drive, the same result

Logs
If applicable, add the relevant output from /tmp/debug or dmesg.

Additional context
Add any other relevant context for the problem.

[wlcina]

Updated issue, culprit seems to be partition size as before actual install I change the partition size to my own values. Once I left as PINN default, everything went ok without issue

[procount]

Can you provide some more details on how you changed the partition sizes, like what values you used?
I've not experienced such an error and have had no previous reports.
EDIT: I would stick to 3.9.3 for now, as there have been reported problems with 3.9.4 - 3.9.7.

[wlcina]

This is the setup which wont boot Raspios for example (also LibreElec and Dietpi), Batocera boots. The size is based on default, I just moved some hundreds GB from LibreElec and Dietpi to batocera (to be able to get at least 1TB there) and raspios (I am intending for daily use)

[wlcina]

Another example where Raspios and LibreElec does not work. Batocera boots flawlesly each time. I also took screen of error during booting in this case Raspios in this configuration.

[wlcina]

According to my lame investigation, ( raspberrypi/rpi-eeprom#776 )
PARTITION_WALK=0 could help to solve this issue, anyway I dont know where to put them, as I did not find any bootconf.txt

[lurch]

bootconf.txt is the contents of the settings inside the EEPROM (i.e. that you'd typically modify with rpi-eeprom-config. See https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#editing-the-current-bootloader-configuration for more info.

[wlcina]

bootconf.txt is the contents of the settings inside the EEPROM (i.e. that you'd typically modify with rpi-eeprom-config. See https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#editing-the-current-bootloader-configuration for more info.

Thanks, I will not play with eeprom, I am merely user without any advanced knowledge of linux or such stuff. I will wait until someone find out whats wrong, or some kind of update. But thank you and I appreciate the info!

[procount]

I'm not sure PARTITION_WALK would solve this issue as it seems unrelated.
The error seems to indicate there is a firmware issue, which is stored in the EEPROM on the Pi5. So it might be worth updating the bootloader to the latest version. See for example: https://forums.raspberrypi.com/viewtopic.php?t=385231
However, as your OSes seem to work when you don't alter the partition sizes, it could be a partition size problem (which a new bootloader may or may not solve, but it's worth a shot as you should always use the latest bootloader version)
It looks like you are using a 2TB drive, which happens to be the maximum size that PINN can deal with as it uses MBR partitioning, so the sizes you chose should be ok. I don't think it's the OSes that are the problem themselves, but more likely their position on the drive, since they are all located after the very large Batocera partition.
You could try reducing the size of the Batocera OS to see if that improves the situation - maybe try a binary search of different sizes. (I don't have a 2TB drive handy to test this out).

[lurch]

So it might be worth updating the bootloader to the latest version.

They already are using the latest bootloader EEPROM 😉
https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware-2712/latest and https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware-2712/release-notes.md both agree that 2025-12-08 is the latest version, and the bootloader screenshot above shows that they're using 2025/12/08.

[procount]

They already are using the latest bootloader EEPROM 😉

Ah, so they are! I hadn't looked closely enough.
So what remains is to try smaller partition sizes for Batocera to see if there is a problem with large sizes. Or maybe the output of sudo fdisk -l might yield some answers...?

[wlcina]

I suspect the size of partition is the culprit, I made this one (split evenly) - everything was ok (batocera and raspios boots correctly)

I tried allocate about 200gb more to batocera (I need about 1.1TB space), and Raspios shows the same error (and do not boot). I noticed batocera is always first to install, maybe change the order of install can help - meaning batocera will be the last partition?

This setup does not work, so I believe you are right and size of partition is the culprit.

[procount]

For partition sizes that don't work, e.g. your last try if you still have it, could you post the output of fdisk -l (along with the partition sizes requested if different from the last screen shot)?

From within PINN, you can get to a command terminal by pressing 'ctrl-alt-f2' and logging in with root/raspberry. Then type fdisk -l and take a photo of the output.

Alternatively, if you plug your drive into another OS installation, you may need to type sudo fdisk -l

[lurch]

I pointed one of my Raspberry Pi colleagues at this issue, and he had a quick look and says it looks like the huge partition size is triggering an assert in the bootloader code. However he won't have time to look at it in more depth until next year.

[wlcina]

Hello, here is output from fdisk -l | less (had to do it as list was too long)

[procount]

Thanks for posting. The output looks ok to me.
As Lurch mentioned, it looks like there is a problem with the bootloader and large partitions, so you'll have to wait for the New Year for this to be fixed. Meanwhile you'll need to keep your partition sizes smaller - I suggest < 1TB from your experiments above.