Firmware fails to boot a GPT SD-card using autoboot.txt on first partrition on Pi 4-B #654
Comments
|
Also, could you point me to the documentation which GPT UUID-Type should I use for the VFAT partition, the one for |
|
For autoboot.txt we recommend using MBR partitions. If you are using GPT these FAT partitions with EFI GUID should be the first partitions in the GPT table i.e. FAT->EXT4->FAT will cause problems since start.elf will treat the partition number to be the Nth bootable 'FAT' partition and not the raw partition number |
|
@timg236, thanks very much for your quick answer. I really like to have GPT to pull all the systemd features based on GPT (such as repart.d). So, in my case, I have the first three partitions that are FAT. FAT ( What should the Also, do you mean the main issue is because the UUID types for theses FAT partitions are bad? i.e. they must be Should I add the partition attribute Legacy BIOS bootable to these "FAT" partitions? I am sorry for these too many questions. I am pretty confused to be honest. IIRC I was able to make it work on a Pi 5 (my memories may be corrupted... so do not trust my words :) I have to test it again). Note: I have these lines in the logs: Do you want I dump the output of EDIT; |
|
The primary partition numbers are 1-based, so autoboot.txt would be partition 1, FAT A partition 2, FAT B partition 3 Partition 0 means "default" which in most cases will end up mapping to 1 Pi4/Pi5 and older accept the basic-data or EFI GUIDs |
|
@timg236, I still think there is something weird after the bootloader tries to load the files from the partition located by the I wonder if |
|
I have exactly same issue! |
|
I don't think non-zero partitions (reboot or autoboot.txt) have ever worked with GPT on Pi4 ... I took a tour of the interactions between the legacy file-systems and based something together (attached) ... seems to work but have almost certainly broken something else. MBR or GPT works with contiguous partition layouts like this. Don't expect boot to work from hybrid GPT EFI parts or non-contiguous boot partitions. |
|
I forgot to say that the attached .zip contains a fix candidate. If you are able to verify that this works for you then it will be easier to get this into the release pipeline. |
|
Thanks, it works! |
|
@timg236, Thank you very much for your fix. Also, I wonder if the firmware/bootloader should also look for the partition type UUID Extended Boot Loader Partition
Additionally, I cannot boot a GPT SD-card on a Raspberry Pi 3; However, I was able to boot an hybrid GPT/MBR (if I remember correctly), is that correct? |
|
Thanks for the test report! SD_GPT_XBOOTLDR seems like it might be a useful addition on Pi5, although bootrom will not recognize this partition type UUID for loading recovery.bin from the SD card. On BCM2711 the split SPI flash bootloader and start4.elf make such a change more difficult e.g. it might load start4.elf and then fail unless both are up to date. Hybrid should work so long as the GPT is in primary partition 4 i.e. so the bootrom and bootcode.bin can't see it. There is some native support for GPT in Pi3B (maybe just plus) in the bootrom. To see if the bootrom is able to load a partition enable UART debug in bootcode.bin - if you get UART output then it's fixable in software. |
|
@timg236 I can also confirm that your fixed version works as expected for me! thanks! |
|
@timg236, OOS, since the bootloader propagates the index of the nth FAT partition used to boot the system via the fdt, is it possible to get the device used to boot the system? i.e. the SD-card, the eMMC, the USB or even the network? "Similar" to the EFI variable LoaderDevicePartUUID ( |
|
See /proc/device-tree/chosen/bootloader/partition although the normal approach would be to put the partition id in the appropriate cmdline.txt |
Do you mean I should use I would like to distinguish if I booted from the SD card or from the eMMC. And sadly, I cannot using the the
To be honest, I would prefer to have that information from the bootloader itself since it is the only reliable way to have it. I guess this is not the right place to discuss any longer on that topic. And I am sorry for that. However, is there a better place for asking such feature? |
|
The partition number, boot-order and selected boot mode are made available via device-tree which uniquely identifies the boot media. |
I don't understand your logic - since cmdline.txt is one of several files loaded by the bootloader from the boot volume, it is arguable that its content is the most reliable indication of where it was loaded from. |
@gportay I think that you might have misinterpreted the documentation - the |
|
I am sorry, my asking is poluting the issue with unrelated purpose.
I think I have understood the documentation. I get
True, at the exception it is not possible to make the distinction between SD-Card or eMMC at it has been said, if both are made available at the same time, I am right?
I have mentioned the EFI variable (using UUID) to justify my request. And I do not think the UUID is the way to go as UUID are not necessarily uniques (at least for filesystems) especially with A/B redundancy filesystems or installer that copies itself to another device.
Well, it seems to, but it implies to mount the nth FAT filesystem of the SD-Card and eMMC to compare the FWIW, I guess the boot partition by identifying the root device and I expect it is on the same device. I was wondering if there is something even more simple using the device-tree and the answer is no for now. To be honest, I think I was looking for a node |
It's not possible to have both SD-Card and eMMC connected at the same time - they both connect to the same physical pins. For the "standard" Raspberry Pi boards, only SD-card is available. For the Compute Module boards, only eMMC is available on CMs containing built-in eMMC; SD-card is only available on the "Lite" Compute Modules. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I faces a boot failure on a Raspberry Pi 4 (64-bit), with the following "settings":
sfdisk --dumpis attached below),autoboot.txton partition 1 (not using the "tryboot reboot flag", its content is attached below),The bootloader reads the file
autoboot.txtin the first partition of typeEBD0A0A2-B9E5-4433-87C0-68B6B72699C7,The bootloader reads the files (
config.txt,start4.elf, andfixup4.dat) in the second partition (boot_partition=2), it starts the "firmware?" filefixup4.datand hangs with the ACT LED blinking 7 times in loop.IIUC, the ACT LED tells me the firmware does not find the kernel.
I am probably mixing firmware and bootloader terms. Could you clarify to me what file is the firmware and what file is the bootlader please?
Important: I am using Buildroot.
Note: The system boots correctly if using MBR SD-Card. The system boots correctly if using GPT SD-Card without
autoboot.txt(i.e. bootingconfig.txton partition 1; in short,sudo dd if=/dev/sdb2 of=/dev/sdb1).I appears the firmware cannot reads things from the SD-card if using
autoboot.txt; see the error below.Steps to reproduce the behaviour
Clone the firmware repository and enters the sources:
Make the partition-table to the SD-card...
... and make the filesystems:
Create the file
autoboot.txton partition 1:Create the file
config.txtand copy the files on partition 2:Device (s)
Raspberry Pi 4 Mod. B
Bootloader configuration.
I am not using the Raspberry Pi OS. I can provide the inputs if requested.
System
I am not using the Raspberry Pi OS. I can provide the inputs if requested.
Bootloader is 2024-12-07, i.e. file
Firmware is 03554ca336a03ace164f36755144e0d8c060062d:
Linux is technically 890917550f578c485ac76aaf6b1b136a64b89bfe, i.e. that commit. It should be:
Bootloader logs
USB boot
N/A.
NVMe boot
N/A.
Network (TFTP boot)
N/A.
The text was updated successfully, but these errors were encountered: