7 ms·

RP2040 Boot Sequence

186 points by vmoore 3y ago

blueflow 3y ago
Official documentation: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p..., Booting is page 130 ff
dmitrygr 3y ago
This is a rehash of official docs, which are both clearer and more detailed. Suggest reading official docs. See “boot” section in rp2040 TRM
crote 3y 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.
- stevefolta 3y ago
  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 https://en.wikipedia.org/wiki/Synchronous_Serial_Interface>
  - duskwuff 3y ago
    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 https://www.synopsys.com/dw/ipdir.php?c=DW_apb_ssi).
    - tonyarkles 3y ago
      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.
      - dezgeg 3y ago
        The same thing has happened in the Linux kernel - there are multiple semi-duplicate SoC USB drivers for the Synopsys core.
- mips_r4300i 3y ago
  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...
  - duskwuff 3y ago
    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.
  - gorkish 3y ago
    The irony of an 8-bit wide serial bus.... %-#
MenhirMike 3y ago
> Power is applied to the chip, and the RUN pin is high. The chip will be held in reset for as long as RUN is not high. Is that a typo, or do I not understand this? Should it be "as long as RUN is high"? Because I assume that the RUN pin is active low, so as long as it is high, the chip will be held in reset?
- colejohnson66 3y ago
  Nope. RUN is active-high:[0;pg12] > Global asynchronous reset pin. Reset when driven low, run when driven high. If no external reset is required, this pin can be tied directly to IOVDD. RST pins tend to be active-low, which is the same thing. Perhaps Raspberry Pi decided to call it the "run" pin instead of the "reset" one to avoid possibly confusing hobbyists? [0]: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...
- NotYourLawyer 3y ago
  I think the second sentence should be in parentheses.
crmd 3y ago
It's kind of annoying that the author made me search for what an RP2040 was, rather than including it in the first paragraph. https://en.wikipedia.org/wiki/RP2040 https://en.wikipedia.org/wiki/RP2040
- Goz3rr 3y ago
  That doesn't seem unusual to me, given that to get to this page you either have to be searching for the specific terms already (and know what they are) or come from the homepage -> RP2040 (Raspberry Pi Pico) projects -> Custom serial bootloader for the RP2040 -> Preliminary reading RP2040 boot sequence
  - crmd 3y ago
    I came to that page directly from the front page of HN. I think it's reasonable to assume a significant portion of their traffic today directly to this page didn't already know what RP2040 is. Missed opportunity to educate readers.
    - skybrian 3y ago
      It might be nice, but most web pages aren't written with Hacker News in mind. We share them anyway. You should expect to sometimes encounter documents where you aren't the target audience and you have to look up terms.
    - anyfoo 3y ago
      Do you want every single subpage in the world to reexplain its context again? Do you expect every SF Chronicle article to explain to you what SF is?
- anyfoo 3y ago
  I mean, in as much as it is annoying when an article about, say, NTFS internals does not explain what NTFS stands for, or what a filesystem is. If you're the target audience, you'll know already.
vbezhenar 3y ago
This complexity forced me to abandon it for learning and switch to STM32. I was able to write blinky with few dozens of assembly instructions for STM32. I spent like month reading about SPI, QSPI, flash chips and still was not able to understand how to proceed with RP2040 other than copy&paste their "bootloader" as an opaque blob. May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the other hand just worked and I gradually learned to blink the chip, to write linker script, to write UART, to use C, to use CMSIS and so on. In the end I was able to write a commercial firmware with it. I understand that if I would just use their SDK with cmake, that wouldn't be a problem, but I'm not going to use their SDK. I hate cmake and I need to understand everything from the ground up. I think that at this moment I can grok this bootloader and write my own version of it, because I know much more about it, but it wouldn't serve its purpose as a chip for learning. IMO that's a flawed approach: to throw infinitely complex tools onto a beginner. It's much easier to start simple, with just an assembler and may be linker. And a chip for beginners must not require those complex initialization procedures. This chip is also incredibly complex with its two cores and PIO cores. It's absolutely cool thing, but it's absolutely not for beginners, it's for experienced engineers. I'd prefer something simple, like STM32, with built-in flash, but with proper documentation and without any compromises. Like flexible voltage source, on-board programmer, plenty of hardware blocks, not cheap price (because who cares if chip cost is $1 or $10 for hobby). RP2040 documentation is superb, I must admit. That's what they did perfectly.
- joezydeco 3y ago
  I don't totally agree with this perspective. Adafruit ships these in dev boards with a CircuitPython layer ready to go - you can have it up and doing something in 90 seconds if you're the Arduino type of hobbyist. You don't need to know a thing about the bootloader at all except maybe to hold down the bootstrap line with a pushbutton to reflash the system if it's bricked. The USB loader is incredibly slick and modern. All this bootstrap sequencing is pretty typical for an ARM Cortex unit, and it's not as overburdened with options like, say, a TI Sitara. They're still unbricking with TFTP. For $0.70 in onesies this is a pretty nice piece of silicon.
  - 3y ago
vha3 3y ago
Some fun easter eggs in the bootrom. It seems like kilograham is a Doors fan: https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5bc007f81d7f2416b48db90f313434/bootrom/bootrom.ld#L14 https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...
- duskwuff 3y ago
  There's another really subtle easter egg hidden in bootrom_rt0.S: https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5bc007f81d7f2416b48db90f313434/bootrom/bootrom_rt0.S#L442-L444 https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5... And the explanation: https://news.ycombinator.com/item?id=30970274 https://news.ycombinator.com/item?id=30970274
StefanBatory 3y ago
I encourage you to check the rest of his website. I only skimmed for a moment, but I'm deeply impressed.

186 points by vmoore 3y ago

Official documentation: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p..., Booting is page 130 ff

dmitrygr 3y ago

This is a rehash of official docs, which are both clearer and more detailed. Suggest reading official docs. See “boot” section in rp2040 TRM

crote 3y 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.

stevefolta 3y ago
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 https://en.wikipedia.org/wiki/Synchronous_Serial_Interface>
- duskwuff 3y ago
  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 https://www.synopsys.com/dw/ipdir.php?c=DW_apb_ssi).
  - tonyarkles 3y ago
    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.
    - dezgeg 3y ago
      The same thing has happened in the Linux kernel - there are multiple semi-duplicate SoC USB drivers for the Synopsys core.
mips_r4300i 3y ago
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...
- duskwuff 3y ago
  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.
- gorkish 3y ago
  The irony of an 8-bit wide serial bus.... %-#

MenhirMike 3y ago

> Power is applied to the chip, and the RUN pin is high. The chip will be held in reset for as long as RUN is not high. Is that a typo, or do I not understand this? Should it be "as long as RUN is high"? Because I assume that the RUN pin is active low, so as long as it is high, the chip will be held in reset?

colejohnson66 3y ago
Nope. RUN is active-high:[0;pg12] > Global asynchronous reset pin. Reset when driven low, run when driven high. If no external reset is required, this pin can be tied directly to IOVDD. RST pins tend to be active-low, which is the same thing. Perhaps Raspberry Pi decided to call it the "run" pin instead of the "reset" one to avoid possibly confusing hobbyists? [0]: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...
NotYourLawyer 3y ago
I think the second sentence should be in parentheses.

crmd 3y ago

It's kind of annoying that the author made me search for what an RP2040 was, rather than including it in the first paragraph. https://en.wikipedia.org/wiki/RP2040 https://en.wikipedia.org/wiki/RP2040

Goz3rr 3y ago
That doesn't seem unusual to me, given that to get to this page you either have to be searching for the specific terms already (and know what they are) or come from the homepage -> RP2040 (Raspberry Pi Pico) projects -> Custom serial bootloader for the RP2040 -> Preliminary reading RP2040 boot sequence
- crmd 3y ago
  I came to that page directly from the front page of HN. I think it's reasonable to assume a significant portion of their traffic today directly to this page didn't already know what RP2040 is. Missed opportunity to educate readers.
  - skybrian 3y ago
    It might be nice, but most web pages aren't written with Hacker News in mind. We share them anyway. You should expect to sometimes encounter documents where you aren't the target audience and you have to look up terms.
  - anyfoo 3y ago
    Do you want every single subpage in the world to reexplain its context again? Do you expect every SF Chronicle article to explain to you what SF is?
anyfoo 3y ago
I mean, in as much as it is annoying when an article about, say, NTFS internals does not explain what NTFS stands for, or what a filesystem is. If you're the target audience, you'll know already.

vbezhenar 3y ago

This complexity forced me to abandon it for learning and switch to STM32. I was able to write blinky with few dozens of assembly instructions for STM32. I spent like month reading about SPI, QSPI, flash chips and still was not able to understand how to proceed with RP2040 other than copy&paste their "bootloader" as an opaque blob. May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the other hand just worked and I gradually learned to blink the chip, to write linker script, to write UART, to use C, to use CMSIS and so on. In the end I was able to write a commercial firmware with it. I understand that if I would just use their SDK with cmake, that wouldn't be a problem, but I'm not going to use their SDK. I hate cmake and I need to understand everything from the ground up. I think that at this moment I can grok this bootloader and write my own version of it, because I know much more about it, but it wouldn't serve its purpose as a chip for learning. IMO that's a flawed approach: to throw infinitely complex tools onto a beginner. It's much easier to start simple, with just an assembler and may be linker. And a chip for beginners must not require those complex initialization procedures. This chip is also incredibly complex with its two cores and PIO cores. It's absolutely cool thing, but it's absolutely not for beginners, it's for experienced engineers. I'd prefer something simple, like STM32, with built-in flash, but with proper documentation and without any compromises. Like flexible voltage source, on-board programmer, plenty of hardware blocks, not cheap price (because who cares if chip cost is $1 or $10 for hobby). RP2040 documentation is superb, I must admit. That's what they did perfectly.

joezydeco 3y ago
I don't totally agree with this perspective. Adafruit ships these in dev boards with a CircuitPython layer ready to go - you can have it up and doing something in 90 seconds if you're the Arduino type of hobbyist. You don't need to know a thing about the bootloader at all except maybe to hold down the bootstrap line with a pushbutton to reflash the system if it's bricked. The USB loader is incredibly slick and modern. All this bootstrap sequencing is pretty typical for an ARM Cortex unit, and it's not as overburdened with options like, say, a TI Sitara. They're still unbricking with TFTP. For $0.70 in onesies this is a pretty nice piece of silicon.
- 3y ago

vha3 3y ago

Some fun easter eggs in the bootrom. It seems like kilograham is a Doors fan: https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5bc007f81d7f2416b48db90f313434/bootrom/bootrom.ld#L14 https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...

duskwuff 3y ago
There's another really subtle easter egg hidden in bootrom_rt0.S: https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5bc007f81d7f2416b48db90f313434/bootrom/bootrom_rt0.S#L442-L444 https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5... And the explanation: https://news.ycombinator.com/item?id=30970274 https://news.ycombinator.com/item?id=30970274

StefanBatory 3y ago

I encourage you to check the rest of his website. I only skimmed for a moment, but I'm deeply impressed.