Error in README: the SoC boot ROM isn't responsible for loading data from SD card

[Googulator]

On the Pi 4, the SoC's internal ROM loads the first external bootloader from SPI, only accessing the SD card for loading recovery.bin if necessary. It's the SPI boot code that needs to read the SD card, and if that can't read GPT, that's a bug to be reported to the RPF.

[pbatard]

Well, without any source for these bootloaders, one could also speculate that, since we definitely know that the hardcoded SoC bootrom has SD access built in and early bootloading code space comes at a premium, the SPI boot code could very well rely on the boot rom code to provide the low level SD file system I/O (e.g. through undocumented VideoCore calls), as opposed to duplicating its own SD file system I/O access code, which isn't exactly trivial and would seem wasteful to have twice if it can be avoided.

Do you have evidence that appears to confirm that the SD file system I/O code is effectively duplicated between SoC boot rom and SPI bootcode?

Also, I would encourage you to engage with the RPF directly on this if you have a chance, as that would help us since our resources are a bit limited at the moment and any time we can avoid spending on matters that are not directly related to the development of the UEFI firmware is welcome. You're also free to propose a PR for a readme fix.

[cleverca22]

this is a listing of files ive extracted from the existing spi images

-rw-r--r-- 1 clever users  61K Dec  3 21:24 bootcode.bin
-rw-r--r-- 1 clever users  21K Dec  3 21:24 memsys00.bin
-rw-r--r-- 1 clever users  21K Dec  3 21:24 memsys01.bin
-rw-r--r-- 1 clever users  21K Dec  3 21:24 memsys02.bin
-rw-r--r-- 1 clever users  21K Dec  3 21:24 memsys03.bin
-rw-r--r-- 1 clever users  21K Dec  3 21:24 memsys04.bin
-rw-r--r-- 1 clever users  21K Dec  3 21:24 memsys05.bin
-rw-r--r-- 1 clever users  21K Dec  3 21:24 memsys06.bin
-rw-r--r-- 1 clever users  21K Dec  3 21:24 memsys07.bin
-rw-r--r-- 1 clever users  227 Dec 12 14:59 bootconf.txt

they total to ~230kb, and the limit is 512kbyte, so they have plenty of room to add more

the other major limit, is that until dram is online, bootcode.bin is limited to 128kbyte of ram (via the L2 cache), assuming things are the same as the older pi's

definitely seems like there is room to add GPT support

semi-related, ive been working on porting the open-firmware to the rpi4 at https://github.com/cleverca22/rpi-open-firmware

once the basic board bring-up is working, it should be fairly simple to shove the tianocore build into the arm reset vector, and let it finish things, the only issue is the lack of services provided by the firmware

[pbatard]

Thanks. I'm not disputing that GPT access isn't doable or that there might not be enough physical space to do it. Just whether the Pi Foundation are ever going to invest the resources to do so, especially if they've just being reusing the SD and file I/O routines that the SoC already provides ondie in its own boot ROM (since at the very least it needs to access SD and FAT to re-flash the EEPROM).

Because the whole thing is closed source, we're all just speculating as to what the Pi Foundation may or may not do at this stage. What we can state however is that GPT does not work with the current SoC/EEPROM combination and therefore is unlikely to be supported by the Bcm2711 ondie bootrom.

Thus, even if we report a bug, I see it as unlikely that the Pi Foundation are going to invest resources to add GPT support since there are most likely only 2 manners in which they implemented file I/O in their EEPROM code:

• By calling on the existing ondie SoC bootcode, that already provides these feature (and only supports MBR)
• By copying code provided by Broadcom that adds the feature... which most likely is derived straight from the ondie SoC bootcode, if not a 1:1 copy, and therefore only supports MBR.

Which means that I'm doubtful the Pi Foundation will see it as the simple "bugfix" we'd like to present it to them, that they could address by leveraging existing GPT-aware code that Broadcom already have. Instead, they'll probably treat it as a new feature to add (and officially support, which takes resources in the long run!!), and require a somewhat better justification than "because a bunch of folks, for whom it is not exactly essential, would like it"...

Still, if someone wants to go ahead and report a bug to see what the Pi Foundation has to say, we would appreciate it.

Nice work on the open-firmware though. As far as I'm concerned, I sure wouldn't mind ditching as many as the closed source blobs as we can, especially as the VideoCore init with the Pi 4 is starting to step on our toes. So if it reaches a stage where we can use it with the UEFI firmware, we'll certainly look into providing that option. I'll try to play with it when I get a chance, but don't expect anything fast...

[pbatard]

I'm going to close this issue for now, as being pedantically accurate in a Readme that is targeted at general end-users (since the goal of this repository is to provide binary consumables for the population at large) is the least of our worries right now.

Again, if someone wants to provide a Readme patch, I'll happily apply it.