Investigate way to force GP2040-CE to reboot into BOOTSEL via picotool invocation

[bsstephan]

Which problem is this feature request solving?

It'd be interesting to be able to script BOOTSEL operations, such as rebooting to apply new firmware, or rebooting into a quasi service mode in order to apply new configs via gp2040ce-binary-tools. This has come up in a couple different contexts on the Discord and I think it's plausible.

Describe the solution you would like to see

picotool help reboot includes these flags:

        -f, --force
            Force a device not in BOOTSEL mode but running compatible code to reset so the command can be executed. After executing the
            command (unless the command itself is a 'reboot') the device will be rebooted back to application mode
        -F, --force-no-reboot
            Force a device not in BOOTSEL mode but running compatible code to reset so the command can be executed. After executing the
            command (unless the command itself is a 'reboot') the device will be left connected and accessible to picotool, but without
            the RPI-RP2 drive mounted

We just need to understand what "compatible code" means.

Can you submit a pull request?

Assuming this exists, yes.

Are you planning on working on this feature yourself?

I'm interested in looking once I get time.

[bsstephan]

I am unassigning this and leaving it in the "backlog" for now. This won't be possible until/unless GP2040-CE supports multiple USB interfaces, which is not something I'm interested in tackling right now, if it's even possible without confusing some of our supported consoles.

Research:

https://github.com/illusiaDecafish/bootselBoot

There is a solution to reset Pico via USB from a host with some limitations:

An executable code with pico_stdio_usb module is installed and executed on the board.
The board is connected to a host computer via USB.

Default mode of pico_stdio_usb module has three intefaces on its USB descriptor. Interface#0 and interface#1 are for CDC (Communication data class) device and interface#2 is for resetting the device. The interface#2 can receive a control transfer with bRequest field set 0x01 or 0x02. 0x01 request invokes BOOTSEL boot and 0x02 regular flash boot.