My first thought was that if we could use the second sd port (SD1) for a "bios chip" EEPROM a SPI multiplexer wouldn't be necessary.mahjongg wrote:actually, but this is an educated guess, as I don't know exactly how the SD-card is addressed during booting, but IF it happens to use the simple SPI mode (which all SD-Cards support, as a baseline communications mode), then there could be a way to provide a PI with an extended boot mechanism. Its an idea which I have mentioned before to moderators and staffers but which was never picked up.
IF the GPU uses the SPI (single-bit serial) protocol, then it may be possible to add some digital multiplex logic, so that after a reset the PI boots through SPI not from the SD-Card but from a standard SPI EEPROM.
The code in the EEPROM could contain slightly smarter software than what is now used, and offer some extra's in line with PCBIOS chips, initializing the GPU for a default video mode (VGA 640x480), then on a keypress offer a BIOS menu, which gives the ability to direct the rest of the boot process to something other than the SD-Card, and perhaps a few important "BIOS settings", now handled by config.txt, which can be stored in the same EEPROM.
When the "BIOS code" is exited the digital multiplexers are reset so the SD-Card interface is reset to the SD_card instead of a serial EEPROM.
This would give a situation almost identical to modern PC's.
it does rely however on the ability of the hardcoded bootcode to boot from SPI EEPROM instead of the card, it also requires a tiny amount of extra hardware.
But after a little research I stumbled across this thread where gsh posted a list of possible boot modes:
So the 5 possible boot modes of the BCM2835 are:gsh wrote:Flash
SD (broadcom or SDHCI interface)
The flash interface isn't much cop because it is a little limited to which devices it will support, It could be enabled for compute module rather than the eMMC but would be difficult to do!
I2C / SPI slave interfaces, currently undocumented (will happen at some time) but quite slow to push the bootcode through that interface. Note this is slave only not I2C to an external eeprom or anything...
Host is not accessible on CM or Pi (the pins don't get out)
So actually USB and SD are currently the only ones that make sense
- I2C/SPI Slave
- SD / eMMC
- USB (Slave)
But first I have some basic questions which I hope somebody will be able to anserwer
- Does the "Flash"-mode use the SMI (Secondary Memory Interface) with GPIO mode ALT1 and is this meant to talk to NAND chips ?
- SPI Slave is obviously on GPIO 18-21 with mode ALT3 but which pins can be used for I2C Slave ?
- are there more informations about the "host"-pins/-interface and is there a reason why they are not accessible on the CM ?
- Does the SD boot mode also include boot from SD1(Second SD Interface) on GPIO 22-27 (ALT3) or only from SD0 (GPIO 47-53) ? This would also be interesting for a HAT with a second SD slot
- How are the boot modes selected ?