Brijesh-Thakkar opened a new pull request, #20730: URL: https://github.com/apache/nuttx/pull/20730
*Note: Please adhere to [Contributing Guidelines](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md).* ## Summary Fixes #17516. Flash builds for RP2040 (`CONFIG_RP2040_FLASH_BOOT=y`) need the 256-byte second stage bootloader (boot2), which is built from the pico-sdk sources. Since cf72133d3c ("rp2040: Continue to build even if PICO_SDK_PATH is not set", #2887), the Make build silently skips boot2 when `PICO_SDK_PATH` is not set: - `arch/arm/src/rp2040/Make.defs` skips `include chip/boot2/Make.defs`, so `rp2040_boot_stage2.S` is never built and the `.boot2` section is empty. - The vector table then lands at `0x10000000`, where the BOOTROM expects boot2. The boot2 CRC check fails and the board falls back to BOOTSEL. - If `picotool` is in `$PATH`, a `nuttx.uf2` is still produced without any warning. That's exactly what the reporter hit. #2887 made this non-fatal because CI had no pico-sdk at the time. CI now provides `PICO_SDK_PATH` everywhere RP2040 boards are built (Docker image, `tools/ci/platforms/linux.sh`, `ubuntu.sh`, `windows.ps1`), and the CMake build already fails when it is unset. So the original reason no longer applies. Changes: - `tools/rp2040/Config.mk`: for flash builds, a PREBUILD check that `PICO_SDK_PATH` is set and that the boot2 source for `CONFIG_RP2040_FLASH_CHIP` exists under it. Otherwise it stops with an error explaining how to fix it. The check runs in PREBUILD rather than at parse time, because `Config.mk` is also read by `configure.sh` and `make distclean`, and those must keep working without the SDK. - `arch/arm/src/rp2040/Make.defs`: include `boot2/Make.defs` unconditionally for flash builds, so the two paths cannot drift apart again. - `arch/arm/src/rp2040/boot2/rp2040_boot_stage2.cmake`: add the same file-exists check. CMake previously only checked that the variable was set, so a wrong path failed later with an unhelpful message. - `Documentation/platforms/arm/rp2040/index.rst`: document that `PICO_SDK_PATH` is required for flash builds. ## Impact - **Users:** building an RP2040 flash config without the pico-sdk now fails immediately with a clear message, instead of producing an image that does not boot. Builds with `PICO_SDK_PATH` set are unchanged. - **Boards:** all RP2040 boards share this path (raspberrypi-pico, raspberrypi-pico-w, adafruit-feather-rp2040, adafruit-kb2040, adafruit-qt-py-rp2040, pimoroni-tiny2040, seeed-xiao-rp2040, w5500-evb-pico, waveshare-rp2040-lcd-1.28, waveshare-rp2040-zero). rp23xx / rp23xx-rv are not affected: RP2350 has no boot2. - **SRAM boot configs** (`CONFIG_RP2040_FLASH_BOOT=n`, e.g. `nshsram`): not affected, still build without the SDK. - **`configure.sh` / `make distclean`:** still work without the SDK. - **CI:** no change expected, since CI already exports `PICO_SDK_PATH`. - **Compatibility:** anyone who built flash configs without the SDK was getting a non-booting image, so no working setup breaks. - **Security:** none. ## Testing Host: Ubuntu 26.04 LTS (x86_64), arm-none-eabi-gcc 14.2.1 20241119 (14.2.rel1), pico-sdk 2.2.0 (same version as CI), picotool 2.2.0 (built from source). "Before" = master at c6e866578e. "After" = this PR. All runs use stock defconfigs with the Make build unless noted. Images were checked by reconstructing the flash image from `nuttx.uf2` and verifying the boot2 CRC32 in its first 256 bytes, the same check the BOOTROM performs. No board was flashed: the bug is in the generated image, so it can be shown at the image level. **raspberrypi-pico:usbnsh:** | Check | Before, SDK unset | Before, SDK 2.2.0 | After, SDK unset | After, SDK 2.2.0 | |---|---|---|---|---| | build | succeeds, no warning | succeeds | **fails early with error** | succeeds | | nuttx.uf2 | produced (659 blocks) | produced (660) | not produced | produced (660) | | UF2 family ID | 0xE48BFF57 | 0xE48BFF56 | — | 0xE48BFF56 | | boot2 CRC32 | **FAIL** (stored 0xC302E7FE, calc 0x7CD56999) | OK (0xD58F0B07) | — | OK (0xD58F0B07) | | at 0x10000000 | vector table | boot2 code | — | boot2 code | **Other cases (after this PR):** | Case | Result | |---|---| | `raspberrypi-pico:usbnsh`, `PICO_SDK_PATH` = non-existent path | fails early: boot2 source not found | | `raspberrypi-pico:usbnsh`, `PICO_SDK_PATH` = existing dir that is not an SDK | fails early: boot2 source not found | | `raspberrypi-pico:nshsram`, no SDK | builds (no boot2, as expected) | | `raspberrypi-pico-w:telnet`, SDK set | builds, boot2 CRC OK | | `adafruit-feather-rp2040:nsh`, SDK set | builds, boot2 CRC OK | | `configure.sh` + `make distclean`, no SDK | work | **Error output (Make, SDK unset):** ``` $ unset PICO_SDK_PATH $ make distclean && ./tools/configure.sh -l raspberrypi-pico:usbnsh && make ... Loaded configuration '.config' Configuration saved to '.config' tools/Unix.mk:535: *** "PICO_SDK_PATH is not set, it is needed to build the boot2 stage, the image will not boot without it. Run: export PICO_SDK_PATH=<path to pico-sdk>". Stop. ``` **CMake (`cmake -B build -DBOARD_CONFIG=raspberrypi-pico:usbnsh`):** - SDK unset: configure fails (existing check, unchanged). - Bogus path: configure fails with the new boot2-source-not-found message. - SDK set: builds, `nuttx.uf2` has family 0xE48BFF56, boot2 CRC OK. **checkpatch:** ``` $ ./tools/checkpatch.sh -g HEAD~..HEAD ✔️ All checks pass. ``` ## Notes - The pico-w build has a fallback that writes a dummy CYW43 firmware file to `/tmp` when `PICO_SDK_PATH` is unset. For flash configs this is now unreachable, because the build stops earlier. That's fine, since those configs could not produce a bootable image anyway. It could be cleaned up in a follow-up. - Possible follow-up: an `ASSERT` in the RP2040 flash linker scripts that `.boot2` is exactly 256 bytes. That would catch an empty boot2 regardless of how the build got there. I kept it out of this PR to keep the change small. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
