1
0
mirror of https://github.com/RIOT-OS/RIOT.git synced 2024-12-29 04:50:03 +01:00
RIOT/cpu/nrf52
bors[bot] 9ff9704fe5
Merge #19010 #19149
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>
2023-01-15 23:31:00 +00:00
..
include doc: fix unbalaced grouping 2022-09-14 15:05:25 +02:00
periph cpu/nrf52-9160: add periph_spi_init_gpio 2022-02-08 09:17:48 +01:00
radio/nrf802154 drivers/nrf802154: do not filter broadcast PAN ID 2022-06-29 17:39:30 +02:00
vectors cpu/nrf52: initial kconfig modeling 2021-09-29 10:17:47 +02:00
cpu.c cpu: call early_init() 2023-01-08 22:26:12 +01:00
Kconfig cpu/nrf52: nRF52x MCUs support Bluetooth 5 Advertising 2022-08-12 16:15:20 +02:00
Makefile cpu/nrf52: split up vector definition 2020-08-09 21:46:06 +02:00
Makefile.dep cpu/nrf52-9160: add periph_spi_init_gpio 2022-02-08 09:17:48 +01:00
Makefile.features cpu/nrf52: nRF52x MCUs support Bluetooth 5 Advertising 2022-08-12 16:15:20 +02:00
Makefile.include cpu/nrf52: handling RIOTBOOT_LEN for tinyusb_dfu 2023-01-15 18:09:55 +01:00
Makefile.nimble.dep cpu/nrf52/Makefile.dep: move radio dependencies from boards/common 2021-09-29 10:16:31 +02:00
Makefile.nrf802154.dep cpu/nrf52/Makefile.dep: move radio dependencies from boards/common 2021-09-29 10:16:31 +02:00
Makefile.nrfmin.dep cpu/nrf52/Makefile.dep: move radio dependencies from boards/common 2021-09-29 10:16:31 +02:00
spi_twi_irq.c cpu/nrf5x: allow multiple I2C and SPI buses on a shared periph 2022-08-30 10:05:34 +02:00