Add support/documentation for booting from SPI (and NAND)

[Olma2]

According to: https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/bootflow.md
it is possible to boot from SPI or NAND though there is currently no full GPU support. I'm not sure what GPU support refers to in this case? Is it related to the boot process or just to video output?

Theoretically the SD card slot could be used however this was not confirmed up to now, see here: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=161372
Also according to bootflow.md it is theoretically possible to boot from a second SD card through the GPIO pins and therefore maybe also via an attached SPI EEPROM (like here: https://linux-sunxi.org/Bootable_SPI_flash ) but this is not yet supported.
What would need to be done to boot the rpi via SPI from the SD card slot or the GPIO header pins?

[pelwell]

GPU is what some people call the VideoCore processor, since it traditionally provides graphics services to the ARM.

Before we say "No", please explain what you mean by "Theoretically the SD card slot could be used". The SD slot uses GPIOs 48-53, which could give you access to MOSI and SCLK but not MISO.

[Olma2]

I'm aware what a GPU is in general but I don't know what

"NAND boot and SPI boot modes do work, although they do not yet have full GPU support"

means in this specific case.
From what I know the GPU on the rpi is in large parts responsible for the boot process and of course also for video output. So there is either the possibility that boot via SPI works but there is no video output after it has fully booted or the SPI boot works but other parts of the GPU boot process fail.

The part for using the SD card slot refers to those two posts:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=161372&p=1210483#p1044633
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=161372&p=1210483#p1046122

However, mahjongg was not 100% sure about that. So if true it could maybe be confirmed here.

[pelwell]

"NAND boot and SPI boot modes do work, although they do not yet have full GPU support"

This means that it would take (at least) software development resources to make use of the SPI and NAND boot modes that the BCM2835 processor supports. And this would be the reason for a "No" from us - without a compelling use case we would rather put our efforts into other areas.

[ghollingworth]

Is there a reason why you think NAND or SPI would be better than eMMC or SD card?

The limitation is that the 'bootcode.bin' (second stage bootloader) doesn't know about SPI or NAND, so we'd need to add that functionality so we can load start.elf and config.txt. Also start.elf (the firmware) doesn't know how to access kernel.img config.txt, cmdline.txt etc.

In total this is actually a fair amount of extra work to enable these boot modes and currently we don't see any reason for it.

[d3vi1]

I can think of a simple scenario. A small Linux that can program SD Cards. Boot from NAND or SPI with a 1MB Linux (initrd included) and insert SD card after SD card in the Raspberry PI for automated image writing.

[JamesH65]

Unfortunately that is a tiny use case, and not really enough to be worth spending the large amount of dev time required.

[meesokim]

For wide use cases of Raspberry Pi, especially Pi Zero is pretty cost effective solution for the commercial embedded system. But Micro SD card is expensive even if it is smallest capacity. If Pi Zero can boot from SPI memory chip like Microchips serial flash, it can be more reliable boot feature rather than Micro SD.

I think it is definitely useful for industrial use of Raspberry Pi.

[vanvught]

For wide use cases of Raspberry Pi, especially Pi Zero is pretty cost effective solution for the commercial embedded system. But Micro SD card is expensive even if it is smallest capacity. If Pi Zero can boot from SPI memory chip like Microchips serial flash, it can be more reliable boot feature rather than Micro SD.

I think it is definitely useful for industrial use of Raspberry Pi.

Also we can store program parameters in SPI flash. All very useful for embedded use of Raspberry Pi Zero.

[derestle-htwg]

A reason for me to use the SPI Boot mode is that I want to use the Raspberry pi in an industrial environment where runtimes are 20 years+.

We made good experience with soldered Flash IC's, and bad experience with mechanical attached (Micro)-SD / USB due to all the vibration and unreliability.
Of course there is the compute module with it's eMMC. But all the other things are missing like Ethernet Jack + Phy....

The best way for me would be to boot The Raspberry 3B+ over GPIO Headers.
I don't care if i connect a SPI-Flash with a FAT Filesystem to the Raspberry or one like the Bootable_SPI_Flash.
I Don't Care if i have a Protocoll handler Microcontroller sit on the other side and send the bootcode.bin and start.elf over UART with a protocoll like the USB Device mode.

I just want to boot the standard 3B+ Pi over it's GPIO Headers

[JamesH65]

Whilst this is a nice to have, it seems exceptionally unlikley we will implement this - the cost to do so is high, vs the number of people likely to use it very low.

Using the Copmpute module is the best best, building a base board that matches your use case.

[derestle-htwg]

Hello JamesH65.
What do you mean with the cost to do so?
I Understand you can't change the on chip Rom for the current generation. But the Raspberry 3B+ won't be the last one (at least i hope so). And Features like Ethernet Boot have already been added.

As far as i understood it is already possible to load a binary through SPI. How hard can it be to load it through the SPI on the GPIOs instead of the other one?
Someone who boots through the SPI on the GPIOs doesn't need a all-in-one solution with unicorns and sugar. But at least the possibility to get a few Kbytes of Code to the cache and to execute it.

it would be lovely to only just solder a SPI-Rom there. But also if i had to insert a little Microcontroller for the SPI-Communication would be ok.

or UART...
or JTAG...
or I2C...
But at least something.

If i have to develop a complex baseboard with ethernet and so on just to add the Raspberry Compute module i can also use any other Board which CPU has a way better documentation.

Best regards

Btw:

As great as the raspberry Project is. The Documentation of the bcm283X is terrifying.
When i see a chip with that amount of documentation i usually get disgusted just by looking at it.

Compare it to the Documentation of an Sitara or STM32.
That is what i call documentation.

[vanvught]

@derestle-htwg

As great as the raspberry Project is. The Documentation of the bcm283X is terrifying.

Sadly to write here, you are describing the Orange Pi Zero. That board has SPI flash on board and can boot from both SDCard and SPI flash. The SoC documentation is better then the BCM SoC documentation (but not so good as the STM32).
The onboard SPI flash (and the EMAC) is my motivation for using the Orange Pi Zero (slowly moving away from the BCM SoC).

[JamesH65]

@ghollingworth I don't know what is or isn't possible with regard to this, so you might be better suited to comment.

[dcamp314]

I can think of a simple scenario. A small Linux that can program SD Cards. Boot from NAND or SPI with a 1MB Linux (initrd included) and insert SD card after SD card in the Raspberry PI for automated image writing.

If you're swapping SD cards then you are physically present and had might as well boot initramfs from an SD boot card before inserting the first target card.