f6973fc64d
* Adds RISC-V compilation option to the IDE and Platform.IO. * Build RP2350-RISCV libpico, libbearssl * Fix RP2350 BearSSL library (was copied from RP2040, now built for M33) * New GCC 14.2 toolchain is required (12.4 RISC-V support is borked) * Newlib locking fixed prototypes * Manually force all runtime init code into RP2350 binaries * Add RISC-V to CI * Remove RP2350 BOOT2.S files, binaries (not used) * Clean up minor GCC 14.x warnings * Add RP2350-RISCV OTA build, link * Add RISC-V FreeRTOS files (configuration still not running, but builds) * Add basic documentation |
||
|---|---|---|
| .. | ||
| uzlib@6d60d651a4 | ||
| CMakeLists.txt | ||
| make-ota.sh | ||
| memmap_ota_rp2040.ld | ||
| memmap_ota_rp2350-riscv.ld | ||
| memmap_ota_rp2350.ld | ||
| ota.c | ||
| ota_clocks.c | ||
| ota_command.h | ||
| ota_lfs.c | ||
| ota_lfs.h | ||
| pico_sdk_import.cmake | ||
| README.md | ||
Arduino-Pico OTA Bootloader
This directory contains a small "stage 3" bootloader (after the boot ROM and the boot2.S flash configuration) which implements a power fail safe, generic OTA method.
The bootloader is built here into an .ELF, without boot2.S (which will come from the main app), configured to copy itself into RAM (so that it can update itself), and included in the main applications. Exactly 12KB for all sketches is consumed by this OTA bootloader.
It works by mounting the LittleFS file system (the parameters are stored by the main app at 0x3000-16), checking for a specially named command file. If that file exists, and its contents pass a checksum, the bootloader reads from the filesystem (optionally, automatically decompressing GZIP compressed files) and writes to application flash.
Every block is checked to see if it identical to the block already in flash, and if so it is skipped. This allows silently skipping bootloader writes in many cases.
Should a power failure happen, as long as it was not in the middle of writing a new OTA bootloader, it should simply begin copying the same program from scratch.
When the copy is completed, the command file's contents are erased so that on a reboot it won't attempt to write the same firmware over and over. It then reboots the chip (and re-runs the potentially new bootloader).
If there is no special file, or its contents don't have a proper checksum, the bootloader simply adjusts the ARM internal vector pointers and jumps to the main application.
The files in the LittleFS filesystem can come over WiFi, over an Ethernet object, or even over a serial port.