One could also send a binary stub that sets up fast CPU clock speed and decompresses the rest of the firmware at the RP2350 side. Should be even faster.
Just like old C64 decrunchers and Amiga PowerPacker. Or Fabrice Bellard's LZEXE. (Is there anything that guy did NOT write?!)
This is awesome.
I've had similar ideas but wasn't able to do any prototyping yet as I only have Pico 2 boards that don't expose the CSn pin in the pinout.
Rather than UART booting every time I thought it might be nice to use UART Boot just as a way to deliver the firmware update to the sub chip - so the UART image you load would just be a program that accepts a larger image (over UART again) and would write to the flash for subsequent boots. I think that would get around the SRAM and boot time downsides the author mentioned. Is there a reason this might not work?
We (Pimoroni) actually shipped this technique in PicoVision, used to load the “GPU” firmware (an RP2040 used to offload the HDMI signal generation) at runtime-
Are you implying the SWD signals would send the RAM contents every time? If I had to do that, I would first use a logic analyzer like Saleae to capture the SWD signals of a JLink performing the necessary operations to load the image into RAM. Then figure out, from the bytes that get send and received, whatever needs to be parameterized, and where to put the image data itself, perhaps by capturing different scenarios, and seeing what changes. Maybe even look up the SWD spec. You would also need to figure out what kind of back and forth is necessary, what must block waiting for a response. From there, assuming there isn't cryptography involved, it just becomes a matter of providing bytes to a bus in the correct order or timing based on the proper events. Some of those bytes are "canned" and never change. Some of them are parameters that describe some important quantity relevant your specific image. And the rest are your firmware image, probably chunked up with some overhead wrapped around it. I allow for the possibility that SWD is far more complex than I imagine, but this approach works pretty well for figuring out whats going on with SPI or I2C or BLE.
SWD and the associated debug interfaces are all documented by ARM; there's no need to reverse-engineer anything here. See the ADIv5 documentation [1] for a starter.
> I allow for the possibility that SWD is far more complex than I imagine, but this approach works pretty well for figuring out whats going on with SPI or I2C or BLE.
SWD is pretty well documented. I won't claim its simple, but, in my opinion, it's decent at what it does. The RISC-V folks haven't seemed to be able to do better (and, IMO, did quite a bit worse in a few places, actually).
The big problem with the SWD wire protocol ARM documentation (and everybody who copies it) is that they don't point out the fact that when you go from Write-to-Read the active edge of the clock changes. In SPI-speak, you switch from CPHA=1 to CPHA=0. This makes sense if you stop to think about it for a moment because during debug there is no clock. Consequently, SWD must provide the clock and you switch from "put something on DATA a half phase early->pulse clock to make chip do something with it" to "pulse clock which makes chip put something on Data->read it a half phase later". However, if it has never been pointed out to you before, it's likely to trip you up.
Sigrok (or similar) which can decode SWD properly and a digital signal analyzer (even a cheap $10 one) are your friends.
The only diagrams which seem to resemble scope traces that point this out are on obscure Chinese engineering blogs.
Just like old C64 decrunchers and Amiga PowerPacker. Or Fabrice Bellard's LZEXE. (Is there anything that guy did NOT write?!)
Rather than UART booting every time I thought it might be nice to use UART Boot just as a way to deliver the firmware update to the sub chip - so the UART image you load would just be a program that accepts a larger image (over UART again) and would write to the flash for subsequent boots. I think that would get around the SRAM and boot time downsides the author mentioned. Is there a reason this might not work?
https://github.com/pimoroni/picovision/blob/main/drivers/dv_...
[1]: https://developer.arm.com/documentation/ihi0031/a
SWD is pretty well documented. I won't claim its simple, but, in my opinion, it's decent at what it does. The RISC-V folks haven't seemed to be able to do better (and, IMO, did quite a bit worse in a few places, actually).
The SWD description at the packet/command level: https://arm-software.github.io/CMSIS-DAP/latest/index.html
There is open source code directly from ARM for it: https://github.com/ARMmbed/DAPLink/tree/main/source/daplink/...
The documentation of the actual wire protocol is also extensive, but a little more scattered: https://developer.arm.com/documentation/ihi0031/a?lang=en https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/...
The big problem with the SWD wire protocol ARM documentation (and everybody who copies it) is that they don't point out the fact that when you go from Write-to-Read the active edge of the clock changes. In SPI-speak, you switch from CPHA=1 to CPHA=0. This makes sense if you stop to think about it for a moment because during debug there is no clock. Consequently, SWD must provide the clock and you switch from "put something on DATA a half phase early->pulse clock to make chip do something with it" to "pulse clock which makes chip put something on Data->read it a half phase later". However, if it has never been pointed out to you before, it's likely to trip you up.
Sigrok (or similar) which can decode SWD properly and a digital signal analyzer (even a cheap $10 one) are your friends.
The only diagrams which seem to resemble scope traces that point this out are on obscure Chinese engineering blogs.
Thanks for the writeup.