General • Re: RP235X OTP Bootloader

I'm not sure what you mean with bare metal - the bootloader is a (flashless) image just like any other, you can use all the SDK functions you like, minus space constraints.

I mean not using the Pico SDK, not calling any PICO SDK functions, controlling the chip and peripherals by peeking and poking register addresses.

The size constraint seemed the big issue with less than 8 KB of OTP to place the bootloader in. I made a conscious decision to have it as small as I could to leave as many OTP rows free as possible for other uses.

While Pico SDK might well be able to create an executable which fits I didn't want any bloat which could otherwise be avoided, and I didn't want the faff of figuring out how to get the SDK build to exclude things I didn't want. It simply seemed more logical to me to go the bare metal route and only have what I need.

Also have you seen the encrypted bootloader example from raspberry pi: https://github.com/raspberrypi/pico-exa ... /encrypted ?

I had, but I couldn't understand it, couldn't figure out what it was doing, wasn't sure it was even relevant to what I was looking to do.

It seemed easier and quicker to start from nothing than try to figure it out so I simply ignored it

As I want a serial bootloader emulating UART Boot Mode at a more sensible baud rate, I don't want my code living at 0x20000000 when running. It would need to move itself to the stack area as the first thing it does.

You don't need to, you can choose any target address in main SRAM with the OTPBOOT_DST0/1 registers.

As I want my bootloader to allow uploads to any and all RAM the bootloader cannot be within that RAM.

I wasn't sure what would happen if I had an executable which didn't start at 0x2000000, I wasn't inclined to investigate, and, as I would have to move it from wherever the copy to RAM put it, it seemed safest to stick with 0x20000000.

Plus I will need to write an uploader.

The picotool can do the uploading part if you encode the binary into a json file. I haven't seen good tooling from raspberry pi's part for actually converting a binary to the json format though, but something to consider.

I saw JSON mentioned for what seemed to be bulk setting of OTP, but I was more meaning uploading a Pico SDK built Run from RAM user program via my own bootloader.

I may investigate further but thought creating a '.sh' file to apply one OTP setting at a time by calling 'picotool' would be an easy if inefficient approach to start with.

99% of what would happen on the real bootloader can be simulated by just loading a RAM image over USB.

Yes, that's the approach I was going to take, a standard Pico SDK Run from RAM program to ensure the code logic is sound via USB. Then the same via UART, then the bare metal build which should work the same. After that, move it to OTP.

But I am well used to things not working the first time and expect that here, maybe having not set some clock or register bit which needs setting when going through the OTP path which hasn't proved a problem going through the other paths. Simple things, easily fixed with another version, but with OTP that chip is then out of the running, and another is needed.

Statistics: Posted by hippy — Sun Jul 06, 2025 6:47 am

---