BOOTSEL activity-LED (`REBOOT2_FLAG_REBOOT_TYPE_BOOTSEL` + `GPIO_PIN_SPECIFIED`) does not drive the configured GPIO on RP2350

## What's wrong On RP2350 (Pico 2, current `develop` bootrom), the BOOTSEL activity-LED feature exposed via `REBOOT2_FLAG_REBOOT_TYPE_BOOTSEL` / `rom_reset_usb_boot_extra()` does not appear to drive the specified GPIO at all, regardless of arguments. ## Repro Three test firmwares, all run on the same Pico 2 board. Each call to `rom_reboot` is preceded by three visible blinks on GPIO 25 (driven from user code) to confirm the firmware actually ran. Built against `develop` at fdd65e6c. ### Test 1 — sanity check (user code only) ```c gpio_init(25); gpio_set_dir(25, GPIO_OUT); gpio_put(25, 1); while (1) tight_loop_contents(); ``` **Result:** LED solid on. Confirms GPIO 25 reaches the LED, polarity is active-high, and the pin can be driven from user code. ### Test 2 — SDK-correct args, no `ACTIVE_LOW` ```c rom_reboot( REBOOT2_FLAG_REBOOT_TYPE_BOOTSEL | REBOOT2_FLAG_NO_RETURN_ON_SUCCESS, 10, /* p0 = flags */ BOOTSEL_FLAG_GPIO_PIN_SPECIFIED, // 0x20 /* p1 = gpio */ 25); ``` Equivalent to `rom_reset_usb_boot_extra(25, 0, false)`. **Expected:** MSD up, activity-LED idle-low (LED off idle, briefly on during MSD activity since this LED is active-high). **Observed:** MSD up and serving reads correctly. LED stays off throughout, including during sustained reads driven from the host: ``` for i in $(seq 1 200); do cat /media/$USER/RP2350/INFO_UF2.TXT > /dev/null; done ``` ### Test 3 — SDK-correct args, `ACTIVE_LOW` set (the diagnostic that nails it) ```c rom_reboot( REBOOT2_FLAG_REBOOT_TYPE_BOOTSEL | REBOOT2_FLAG_NO_RETURN_ON_SUCCESS, 10, /* p0 = flags */ BOOTSEL_FLAG_GPIO_PIN_SPECIFIED | BOOTSEL_FLAG_GPIO_PIN_ACTIVE_LOW, // 0x30 /* p1 = gpio */ 25); ``` Equivalent to `rom_reset_usb_boot_extra(25, 0, true)`. **Expected:** with `ACTIVE_LOW`, the bootrom holds the pin idle **high**. On this active-high LED that means LED solid on during BOOTSEL idle, briefly dipping off during activity. **Observed:** LED stays off the entire time BOOTSEL is up — no idle drive, no activity blinks. ## Why Test 3 is the smoking gun Test 2 alone could be explained as "bootrom is driving the pin but the reads I'm generating don't register as observable activity pulses on the host." Test 3 rules that out: it requires no activity dependence — the bootrom should be holding the pin **statically high** for the whole BOOTSEL session — and the pin stays low. So the bootrom isn't driving GPIO 25 at all under any tested combination, even with `BOOTSEL_FLAG_GPIO_PIN_SPECIFIED` clearly set. ## Environment - SDK: `origin/develop` at fdd65e6c - Board: Raspberry Pi RP2350 (Pico 2), `Board-ID: RP2350`, `INFO_UF2.TXT` reports `UF2 Bootloader v1.0` - USB ID in BOOTSEL: `2e8a:000f` - Host: Linux 6.12, libusb-based control-transfer triggers ruled out; tests call `rom_reboot` directly - Toolchain: `arm-none-eabi-gcc 14.2.1` ## Related - Today's testing also resolved the related argument-order question (originally #2949): the SDK's `rom_reset_usb_boot_extra()` passes `(p0 = flags, p1 = gpio)` and the bootrom does interpret them in that order. The doc comments were reversed; PR #2955 fixes them. So the wrong arg order is **not** the cause of this bug — my tests above use the correct order and still see no LED drive. - PR #2947 fixes a separate `wValue` bit-overlap in `src/rp2_common/pico_stdio_usb/reset_interface.c` that confounded my earlier USB-control-transfer-based BOOTSEL tests; today's tests bypass that path entirely. ## What I haven't ruled out - Whether the activity-LED feature works under some specific bootrom revision or specific host-side trigger I haven't tested. If there's a known-good repro pointing at a working configuration on RP2350, I'd appreciate the pointer. - Whether there's an additional enable bit I'm missing. `src/common/boot_picoboot_headers/include/boot/picoboot_constants.h:27-30` only documents `DISABLE_MSD_INTERFACE`, `DISABLE_PICOBOOT_INTERFACE`, `GPIO_PIN_ACTIVE_LOW`, `GPIO_PIN_SPECIFIED`. The `bootrom.h` doxygen still uses a stale `GPIO_PIN_ENABLED` name for the 0x20 flag — same value, just an inconsistent name (orthogonal to this bug). - Whether GPIO 25 specifically is reserved by the bootrom on RP2350. Worth retrying with a different GPIO if anyone has a Pico 2 with an LED wired to e.g. GPIO 2 they can flash and report. Happy to send the firmware sources / a self-contained reproducer repo if useful.