mirror of
https://github.com/RIOT-OS/RIOT.git
synced 2024-12-29 04:50:03 +01:00
9ff9704fe5
19010: bootloaders/riotboot: add tinyUSB DFU support r=benpicco a=gschorcht ### Contribution description This PR provides - the tinyUSB DFU and DFU Runtime support and - the `riotboot_tinyusb_dfu` bootloader that uses the tinyUSB DFU mode to flash new application images. ~This PR includes PR #18983 for now to be compilable.~ ### Testing procedure 1. Use any board that supports the `riotboot´ and `tinyusb_device` features and flash the bootloader first, for example ``` BOARD=nucleo-f767zi make -C bootloaders/riotboot_tinyusb_dfu flash ``` and check that the `riotboot_tinyusb_dfu` bootloader is in DFU mode: ``` dfu-util --list ``` 3. Flash a first application using the following command: ``` FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \ make -C tests/saul PROGRAMMER=dfu-util riotboot/flash-slot0 ``` and check that the application starts and is seen as upgradable: ``` dfu-util --list ``` 4. Restart the node in bootloader DFU mode by: ``` dfu-util -e ``` Flash a second application, for example ``` FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \ make -C tests/shell PROGRAMMER=dfu-util riotboot/flash-slot1 ``` and check that the second application starts and is seen as upgradable: ``` dfu-util --list ``` ### Issues/PRs references ~Depends on PR #18983~ 19149: SECURITY: Describe that declassification is an option r=benpicco a=chrysn ### Contribution description Our security policy does not contain provisions for the case when what is reported is not what we consider an actual security issue. As it is described now, everything reported through security@ would go through the full treatment, including a point release. I'm not sure it belongs into the text itself (as it's more about how security reporters interact with the project than internals), but declassification should IMO be backed at least by 3 maintainers, and no strong NACK. ### Issues/PRs references #19141 followed that procedure after some chat on it on the maintainers channel. (In the discussion, I proposed declassification, with 2.5 people supporting it and one "I was about to, but can we be sure nobody is using it?" voice). Co-authored-by: Gunar Schorcht <gunar@schorcht.net> Co-authored-by: chrysn <chrysn@fsfe.org> |
||
|---|---|---|
| .. | ||
| arm7_common | ||
| atmega32u4 | ||
| atmega128rfa1 | ||
| atmega256rfr2 | ||
| atmega328p | ||
| atmega1281 | ||
| atmega1284p | ||
| atmega2560 | ||
| atmega_common | ||
| atxmega | ||
| avr8_common | ||
| cc26x0_cc13x0 | ||
| cc26x2_cc13x2 | ||
| cc26xx_cc13xx | ||
| cc2538 | ||
| cortexm_common | ||
| efm32 | ||
| esp32 | ||
| esp8266 | ||
| esp_common | ||
| fe310 | ||
| gd32v | ||
| kinetis | ||
| lm4f120 | ||
| lpc23xx | ||
| lpc1768 | ||
| msp430_common | ||
| msp430fxyz | ||
| native | ||
| nrf5x_common | ||
| nrf51 | ||
| nrf52 | ||
| nrf9160 | ||
| qn908x | ||
| riscv_common | ||
| rpx0xx | ||
| sam0_common | ||
| sam3 | ||
| sam_common | ||
| samd5x | ||
| samd21 | ||
| saml1x | ||
| saml21 | ||
| stellaris_common | ||
| stm32 | ||
| doc.txt | ||
| Kconfig | ||