SPI boot

[cleverca22]

in addition to the current SD and ethernet boot options, i'm thinking the firmware should also support an SPI boot option

BOOT_ORDER=0x3 for example, would then boot from the configured SPI chip, loading start4.elf from it, and then that loads config.txt and kernel.img as normal

the bootconf.txt should have config to say which group of SPI pins to use (for example, 7-11 or 16-21) which SPI controller to use (despite 19-21 sharing the main data/clock, they have different chip-enable lines, so using the right one can be important) and of couse, which chip-enable to use within that controller

this would allow a hat style board with a large enough SPI chip, could hold start4.elf + a custom arm baremetal kernel

that kernel, could also be a full tianocore build, offering full uefi support, any SD card with a valid efi system partition would just boot, without needing firmware files

the external SPI chip can also use the existing filesystem that the internal one does, it already has support for named files and sharing code keeps the bootcode size small and saves development time

[andreiw]

This is a great idea and I really hope the Pi Foundation sees value in it. I definitely see where the could be a "UEFI shield", say with an FTDI USB chp, a battery backed RTC and a SPI chip (or SD card via SPI) large enough to contain both firmware and NVRAM.

(UEFI project is http://rpi4-uefi.dev)

A

[timg236]

Thanks for the detailed comments. Can't say for sure if when this would happen but I think the bootloader loading a minimal RAM-FS/binary blob from arbitrary boot media (including SPI and maybe GPT partition from USB MSD) is a good step. This would contain start.elf and be passed to start.elf after loading so start.elf can load the kernel, device-tree overlays etc

Maybe in future there can be a very cutdown start.elf which only uses the bootrom RAM image allowing a load of legacy and proprietary internal FS code to be deleted :)

[lurch]

I definitely see where the could be a "UEFI shield"

Sounds like a bit of a niche use-case? :man_shrugging:

EDIT: Apologies if my comment was ill-informed.

[andreiw]

Is the Arm server ecosystem niche? See https://rpi4-uefi.dev/about/ for the reasoning why it matters.

[cleverca22]

i was thinking each file (config.txt, start.elf, kernel.img) would be in the SPI, using the same magic+name scheme as how bootconf.txt is currently stored

but on the idea of a ramfs that holds all of those in one blob, android has something similar, though that makes it more complex to update things on a USB stick

[timg236]

I was thinking that the SPI format might actually be reusable in other places eg over a network connection. This can be compressed for speed and passed to start.elf as a read only blob meaning that start.elf wouldn’t need to do additional network access. It might need to be tweaked to allow longer filenames but that’s about it.

[cleverca22]

if you do choose to go that route, id love for some extra documentation on how the SPI passes the file on to start4.elf, then custom start4.elf files can take advantage of it, and not need to implement network!

[derestle-htwg]

To boot the rpi4 over the headers with SPI would allow to use the raspberry in combination with a mounted PCB with an SPI-Flash. No removable/unstable uSD-Card or USB-Stick. Just a socket with stable pin headers sockets. What runs over the SPI-Bus is another story. May it be UEFI, Linux, Bare-metal self made OS or whatever. This would allow to use the RPI4 as an ComputeModule. But without the need to redevelop the HDMI, Network, etc, etc interfaces. That would allow the Rpi4 in an more industrial oriented way that uSD or USB-Boot.

[timg236]

The bootloader and start.elf will be updated support GPT partitions for SD-CARD and USB. There's no need to add extra complexity into the bootloader to load other executables from SPI flash.

[derestle-htwg]

The Computemodules have an integrated flash for a reason. They don't want USB-, SD- or Ethernet boot.

But if a compute module is used one has to add all that other stuff like ethernet, etc, etc... Then i can go directly and use an STM32MP15x or Ti Sitara...

The only thing that stops me from using a Raspberry in a design is that USB/Ethernet/Network booting. If i had the chance to use an SPI, or I2C or UART or whatever then i'd be happy. And honestly i do not understand why SPI is considered complexity. In this particular case an SPI-Boot seems to me to be the most simple one from the perspective of the EEPROM software. I don't - and i also think most other people, too - expect a super SPI boot with twinkling stars and sugar icing. I just want to get the thing started with a stable and reliable connection through GPIO headers. May it be UART, I2C, SPI. Or by me i also would accept JTAG. But i just need something to get that machine booted without anything a PEBCAK can remove.

[lurch]

But i just need something to get that machine booted without anything a PEBCAK can remove.

Use a case that doesn't allow access to the SD-slot? :shrug:

[derestle-htwg]

@lurch, another problem is the durability of uSD-Cards. Booting through GPIO Headers would offer the possibility to implement an own solution with the requested durability. But to me it looks as if no one who has access to the source is really interested. i think i have to look elsewhere.

[lurch]

another problem is the durability of uSD-Cards.

Which can be mitigated by using high-quality uSD-cards and/or using readonly/overlay filesystems? (IIRC there's options for the latter built into the Preferences app on Raspberry Pi OS) :shrug:

[timg236]

Locked. Bluesky conversions to the forums please