dearsky/pico-fido
1
0
Fork 0
Code Issues 46 Pull Requests 1 Actions Packages Projects Releases 22 Wiki Activity

V7.0 "soft-bricked" rp2350 with secure boot enabled #211

New Issue
Closed
opened 2025-12-07 07:05:03 +08:00 by IlyaMZP · 2 comments
IlyaMZP commented 2025-12-07 07:05:03 +08:00 (Migrated from github.com)
Copy Link

I compiled the latest v7.0 release and flashed it to update my existing pico 2 key. It worked initially, but after a few seconds it rebooted and came back in the flash mode (as a mass storage device).

Thinking it must be some sort of incompatibility with a previous version, I grabbed a fresh Raspberry Pi Pico 2 (that never even has been flashed) and executed the following commands:

git clone https://github.com/polhenarejos/pico-fido
cd pico-fido
git submodule update --init --recursive
mkdir build
cd build
PICO_SDK_PATH="/usr/share/pico-sdk/" cmake .. -DPICO_BOARD=pico2 -DSECURE_BOOT_PKEY="/data/pico-fido/private.pem" -DVIDPID=Yubikey5
make
picotool otp load pico_fido.otp.json
cp pico_fido.uf2 /run/media/$USER/RP2350/; sudo umout /run/media/$USER/RP2350/

It flashed successfully and started blinking its LED, but after a few seconds the same thing happened: it now boots immediately into the flash mode. Even if I flash the same uf2 file, it still reboots immediately into the flash mode without even blinking the LED.
Previously compiled version no longer works, I assume it's because of the rollback prevention.

CMake output:

Using PICO_SDK_PATH from environment ('/usr/share/pico-sdk/')
PICO_SDK_PATH is /usr/share/pico-sdk
Target board (PICO_BOARD) is 'pico2'.
Using board configuration from /usr/share/pico-sdk/src/boards/include/boards/pico2.h
Auto-converting non-specific PICO_PLATFORM='rp2350' to 'rp2350-arm-s'
Defaulting platform (PICO_PLATFORM) to 'rp2350-arm-s' based on PICO_BOARD setting.
-- Defaulting build type to 'Release' since not specified.
Defaulting compiler (PICO_COMPILER) to 'pico_arm_cortex_m33_gcc' since not specified.
Configuring toolchain based on PICO_COMPILER 'pico_arm_cortex_m33_gcc'
Defaulting PICO_GCC_TRIPLE to 'arm-none-eabi'
-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-gcc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/arm-none-eabi-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/arm-none-eabi-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Power cycle on reset: 	 enabled
-- OATH Application: 		 enabled
-- OTP Application: 		 enabled
-- VIDPID:			 'Yubikey5'
-- Delayed boot:		 disabled
-- USB HID Interface:		 enabled
-- USB CCID Interface:		 enabled
-- USB WebCCID Interface:	 enabled
-- USB VID/PID:			 0x1050:0x0407
-- EdDSA support:		 disabled
-- Current tag for mbedTLS: v3.6.2
-- Target tag for mbedTLS:  v3.6.5
-- Updating mbedTLS source code...
Build type is Release
Using picotool from /usr/bin/picotool
-- Found Python3: /usr/bin/python3.13 (found version "3.13.7") found components: Interpreter
TinyUSB available at /usr/share/pico-sdk/lib/tinyusb/hw/bsp/rp2040; enabling build support for USB.
BTstack available at /usr/share/pico-sdk/lib/btstack
cyw43-driver available at /usr/share/pico-sdk/lib/cyw43-driver
mbedtls available at /usr/share/pico-sdk/lib/mbedtls
lwIP available at /usr/share/pico-sdk/lib/lwip
-- Secure Boot Key /data/pico-fido/private.pem
-- Found version:		 7.0
-- Setting rollback version:	 2
-- Configuring done (0.8s)
-- Generating done (0.0s)
-- Build files have been written to: /tmp/pico-fido/build

Pico-SDK version is 2.2.0

Not sure how to debug this, since I don't have a debug probe.

I compiled the latest v7.0 release and flashed it to update my existing pico 2 key. It worked initially, but after a few seconds it rebooted and came back in the flash mode (as a mass storage device). Thinking it must be some sort of incompatibility with a previous version, I grabbed a fresh Raspberry Pi Pico 2 (that never even has been flashed) and executed the following commands: ``` git clone https://github.com/polhenarejos/pico-fido cd pico-fido git submodule update --init --recursive mkdir build cd build PICO_SDK_PATH="/usr/share/pico-sdk/" cmake .. -DPICO_BOARD=pico2 -DSECURE_BOOT_PKEY="/data/pico-fido/private.pem" -DVIDPID=Yubikey5 make picotool otp load pico_fido.otp.json cp pico_fido.uf2 /run/media/$USER/RP2350/; sudo umout /run/media/$USER/RP2350/ ``` It flashed successfully and started blinking its LED, but after a few seconds the same thing happened: it now boots immediately into the flash mode. Even if I flash the same uf2 file, it still reboots immediately into the flash mode without even blinking the LED. Previously compiled version no longer works, I assume it's because of the rollback prevention. CMake output: ``` Using PICO_SDK_PATH from environment ('/usr/share/pico-sdk/') PICO_SDK_PATH is /usr/share/pico-sdk Target board (PICO_BOARD) is 'pico2'. Using board configuration from /usr/share/pico-sdk/src/boards/include/boards/pico2.h Auto-converting non-specific PICO_PLATFORM='rp2350' to 'rp2350-arm-s' Defaulting platform (PICO_PLATFORM) to 'rp2350-arm-s' based on PICO_BOARD setting. -- Defaulting build type to 'Release' since not specified. Defaulting compiler (PICO_COMPILER) to 'pico_arm_cortex_m33_gcc' since not specified. Configuring toolchain based on PICO_COMPILER 'pico_arm_cortex_m33_gcc' Defaulting PICO_GCC_TRIPLE to 'arm-none-eabi' -- The C compiler identification is GNU 14.2.0 -- The CXX compiler identification is GNU 14.2.0 -- The ASM compiler identification is GNU -- Found assembler: /usr/bin/arm-none-eabi-gcc -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/arm-none-eabi-gcc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/arm-none-eabi-g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Power cycle on reset: enabled -- OATH Application: enabled -- OTP Application: enabled -- VIDPID: 'Yubikey5' -- Delayed boot: disabled -- USB HID Interface: enabled -- USB CCID Interface: enabled -- USB WebCCID Interface: enabled -- USB VID/PID: 0x1050:0x0407 -- EdDSA support: disabled -- Current tag for mbedTLS: v3.6.2 -- Target tag for mbedTLS: v3.6.5 -- Updating mbedTLS source code... Build type is Release Using picotool from /usr/bin/picotool -- Found Python3: /usr/bin/python3.13 (found version "3.13.7") found components: Interpreter TinyUSB available at /usr/share/pico-sdk/lib/tinyusb/hw/bsp/rp2040; enabling build support for USB. BTstack available at /usr/share/pico-sdk/lib/btstack cyw43-driver available at /usr/share/pico-sdk/lib/cyw43-driver mbedtls available at /usr/share/pico-sdk/lib/mbedtls lwIP available at /usr/share/pico-sdk/lib/lwip -- Secure Boot Key /data/pico-fido/private.pem -- Found version: 7.0 -- Setting rollback version: 2 -- Configuring done (0.8s) -- Generating done (0.0s) -- Build files have been written to: /tmp/pico-fido/build ``` Pico-SDK version is 2.2.0 Not sure how to debug this, since I don't have a debug probe.
polhenarejos commented 2026-01-26 08:29:25 +08:00 (Migrated from github.com)
Copy Link

It is not bricked. By design, RP2350 is not possible to brick.
If you sign with your own private key, then you need to burn the your public key hash in the OTP related with secure boot. PicoKeys use index 0, so you must use indexes 1-5.

It is not bricked. By design, RP2350 is not possible to brick. If you sign with your own private key, then you need to burn the your public key hash in the OTP related with secure boot. PicoKeys use index 0, so you must use indexes 1-5.
IlyaMZP commented 2026-02-06 17:57:04 +08:00 (Migrated from github.com)
Copy Link

It is not bricked. By design, RP2350 is not possible to brick.

I know. I obviously can flash any other image and it works fine. But whenever I flashed the pico-fido (properly, with flashing OTP and then flashing the signed uf2), it booted one time and then went right back into the flash mode.

If you need any more info, I could build and flash the latest commit and check if it works. But for now I stopped using pico-fido.

I'm not sure what you mean by you must use indexes 1-5
Is it a build-time variable? (SECURE_BOOT_BOOTKEY_INDEX ?)
Why did it work before, but stopped working on version 7.0?

> It is not bricked. By design, RP2350 is not possible to brick. I know. I obviously can flash any other image and it works fine. But whenever I flashed the `pico-fido` (properly, with flashing OTP and then flashing the signed uf2), it booted one time and then went right back into the flash mode. If you need any more info, I could build and flash the latest commit and check if it works. But for now I stopped using pico-fido. I'm not sure what you mean by `you must use indexes 1-5` Is it a build-time variable? (SECURE_BOOT_BOOTKEY_INDEX ?) Why did it work before, but stopped working on version 7.0?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something isn't working
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dearsky
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dearsky/pico-fido#211
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?