Hacker News new | ask | show | jobs
by crote 826 days ago
For those wondering about why there's both a boot ROM and the boot2 in flash:

The flash chips used support both a basic SPI mode, and an advanced QSPI mode. There is a well-defined standard protocol for basic SPI mode, so virtually all chips will respond to the same read command for simple slow byte-by-byte reading. The only thing left to try is the four SPI modes (Does clock idle high or low? Do we transfer on the full pulse, or on the half pulse?) - hardware often even supports two of them, and there's only one set which actually makes sense.

QSPI, on the other hand, is more of a wild-west. You need to run a bunch of chip-specific commands to enter QSPI mode, and there are quite a few possible variations for QSPI read commands, not to mention a lot of different timing requirements. Trying out all of them isn't really possible, hence the chip-specific boot2 segment.

Staying in SPI mode isn't really viable either because the application code is stored in the flash chip. To give an example, jumping to a random instruction would incur a 1280 ns read with a W25Q80BW flash chip operating in SPI mode (realistically x10 due to a lower safe clock frequency), whereas QSPI mode can reliably do that in as little as 125 ns. With the RP2040 running at 133MHz a 16-cycle delay for a random jump or a read from a data block is not too bad, but a 170 or even 1700-cycle delay is just way too much.

2 comments

Great info, and now some chips are supporting Octo-SPI which is even more vendor dependent. At some point we're basically back to parallel flash...
TBH, a lot of the details are fairly standardized across vendors, and/or are discoverable through SFDP. Parsing the SFDP tables would take a nontrivial amount of program memory, though; I don't know as I'd want to embed that logic in ROM.
The irony of an 8-bit wide serial bus.... %-#
And where the document talks about SSI, it essentially means SPI (just with differential signalling etc.)? In other words, is it this SSI?: <https://en.wikipedia.org/wiki/Synchronous_Serial_Interface>
It's a "synchronous serial interface" similar to SPI, but that isn't what the Wikipedia article you're linking to is about.

It's the DW_apb_ssi peripheral from Synopsys (https://www.synopsys.com/dw/ipdir.php?c=DW_apb_ssi).

It's always a bit funny to me how much of the Synopsis IP ends up in different chips. As an example a decade+ ago I implemented a from-scratch USB Peripheral stack on an STM32 microcontroller, basically because the vendor SDK wasn't capable of doing what I needed or being readily modified to do what I needed. A couple of years ago I was debugging some firmware for a chip from a completely different vendor and noticed that the USB registers looked... familiar. Looked back at the original project and was somewhat surprised to discover that it was exactly the same registers in the same order just mapped to a different spot in memory.
The same thing has happened in the Linux kernel - there are multiple semi-duplicate SoC USB drivers for the Synopsys core.