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>
144 lines
4.9 KiB
Plaintext
144 lines
4.9 KiB
Plaintext
/**
|
|
* @defgroup pkg_tinyusb TinyUSB package
|
|
* @ingroup pkg
|
|
* @brief Provides the tinyUSB stack as package
|
|
* @author Gunar Schorcht <gunar@schorcht.net>
|
|
* @see https://github.com/hathach/tinyusb
|
|
*
|
|
* # TinyUSB
|
|
*
|
|
* tinyUSB is an open-source cross-platform USB Host/Device stack for
|
|
* embedded systems.
|
|
*
|
|
* @note This package is distinct from (and incompatible with) the USB stack
|
|
* provided around USBUS in RIOT (see @ref usb). They differ in the level of
|
|
* abstraction and in the set of supported devices.
|
|
*
|
|
* # Usage
|
|
*
|
|
* Add the following entries to your application makefile:
|
|
* - Enable tinyUSB package
|
|
* ```makefile
|
|
* USEPKG += tinyusb
|
|
* ```
|
|
* - Select whether to use the tinyUSB device stack or the tinyUSB host stack or both:
|
|
* ```makefile
|
|
* USEMODULE += tinyusb_device
|
|
* ```
|
|
* - Select the device/host classes to be used, for example:
|
|
* ```makefile
|
|
* USEMODULE += tinyusb_class_cdc tinyusb_class_msc
|
|
* ```
|
|
*
|
|
* Either add `tinyusb_setup()` to your main function to explicitly initialize
|
|
* the tinyUSB stack including the used peripherals and start the tinyUSB
|
|
* thread, or use the `auto_init` module (**default**).
|
|
*
|
|
* ```c
|
|
* int main(void)
|
|
* {
|
|
* ...
|
|
* // If auto-initialization is not used (module `auto_init`),
|
|
* // initialize the tinyUSB stack including used peripherals and
|
|
* // start the tinyUSB thread. Auto-initialization is used by default.
|
|
* tinyusb_setup();
|
|
*
|
|
* while (1) {
|
|
* ...
|
|
* }
|
|
*
|
|
* return 0;
|
|
* }
|
|
* ```
|
|
*
|
|
* If it is necessary to override the default configuration defined in
|
|
* `tusb_config.h`, create a file `tinyusb_app_config.h` in your application
|
|
* directory and override the configuration to be changed.
|
|
* ```c
|
|
* #define CONFIG_TUSBD_CDC_NUMOF 2
|
|
* ```
|
|
*
|
|
* By default, the number of `CONFIG_TUSBD_*_NUMOF` device class and
|
|
* `CONFIG_TUSBH_*_NUMOF` host class interfaces are defined to 1 if the
|
|
* corresponding `tinyusb_class_*` and `tinyusb_device`/`tinyusb_host`
|
|
* module are enabled, and 0 otherwise.
|
|
* That is, there is one interface of each class.
|
|
*
|
|
* For example, if the `tinyusb_device` and `tinyusb_class_cdc` modules are
|
|
* enabled, `CONFIG_TUSBD_CDC_NUMOF` is defined to 1 by default. The number of
|
|
* all other `CONFIG_TUSBD_*_NUMOF` device class interfaces are 0.
|
|
*
|
|
* If you add the `tinyusb_app_config.h` file in your application directory
|
|
* to override the default configuration, add the application path to the
|
|
* include paths at the end of your
|
|
* application's Makefile. This is necessary so that the tinyUSB stack
|
|
* uses the file `tinyusb_app_config.h` from your application directory
|
|
* and thus the file `tusb_config.h` from the tinyUSB package.
|
|
* ```makefile
|
|
* USEPKG += tinyusb
|
|
* USEMODULE += tinyusb_class_cdc
|
|
* USEMODULE += tinyusb_class_msc
|
|
* USEMODULE += tinyusb_device
|
|
*
|
|
* include $(RIOTBASE)/Makefile.include
|
|
*
|
|
* INCLUDES += -I$(APPDIR)
|
|
* ```
|
|
*
|
|
* Implement the callbacks of the enabled classes.
|
|
*
|
|
* For most common device classes and their configuration, the tinyUSB
|
|
* package automatically generates the required descriptors and descriptor
|
|
* callbacks for any combination of
|
|
* - up to two interfaces of the class CDC ACM,
|
|
* - up to two interfaces of the Generic In/Out HID class,
|
|
* - up to one DFU interface
|
|
* - up to one MSC device interface and,
|
|
* - up to one interface of the Vendor device class.
|
|
*
|
|
* Any other combination, either a different number of these device class
|
|
* interfaces or the use of a different device class interface, requires the
|
|
* implementation of custom descriptors and the callbacks.
|
|
*
|
|
* All symbols of the generated descriptors and their callback functions are
|
|
* defined as weak symbols so that the application can override parts of the
|
|
* descriptors or the callback functions that handle them. For example, the
|
|
* array `tusb_desc_hid_0_report`, which defines the HID report descriptor for
|
|
* HID device 0, making the device a generic in/out HID device
|
|
*
|
|
* ```c
|
|
* __attribute__((weak))
|
|
* uint8_t const tusb_desc_hid_0_report[] =
|
|
* {
|
|
* TUD_HID_REPORT_DESC_GENERIC_INOUT(CONFIG_TUSBD_HID_EP_SIZE),
|
|
* };
|
|
* ```
|
|
*
|
|
* could be overridden by the application with
|
|
*
|
|
* ```c
|
|
* uint8_t const tusb_desc_hid_0_report[] =
|
|
* {
|
|
* TUD_HID_REPORT_DESC_KEYBOARD(HID_REPORT_ID(REPORT_ID_KEYBOARD)),
|
|
* TUD_HID_REPORT_DESC_MOUSE(HID_REPORT_ID(REPORT_ID_MOUSE)),
|
|
* };
|
|
* ```
|
|
*
|
|
* to make the device to be a composite keyboard/mouse device.
|
|
*
|
|
* Please refer `$RIOTBASE/tests/pkg_tinyusb_cdc_msc` and the
|
|
* [tinyUSB documentation](https://docs.tinyusb.org/en/latest/reference/getting_started.html)
|
|
* for details.
|
|
*/
|
|
|
|
/**
|
|
* @defgroup pkg_tinyusb_stdio_cdc_acm STDIO over USB CDC-ACM (tinyUSB)
|
|
* @ingroup sys_stdio
|
|
* @brief Standard input/output backend using tinyUSB CDC ACM
|
|
* @see pkg_tinyusb
|
|
*
|
|
* To enable this, select the `tinyusb_stdio_cdc_acm` module:
|
|
*
|
|
* USEMODULE += stdio_tinyusb_cdc_acm
|
|
*/
|