19086: Remodel the USB in Kconfig r=aabadie a=MrKevinWeiss
### Contribution description
#### The issues with current architecture
Generally there has been some confusion on how to manage KConfig with respect to the board selection of default STDIO backends, specifically for boards that require a USB based backend as there are possible stacks to use.
The `<BOARD>.config` way of selecting cannot handle conditional selects.
The issues is more with boards such as `esp32s2-wemos-mini`, currently some USB stack will be selected regardless of overridding the preferred STDIO.
Selecting a USB stack directly with `STDIO_USB*` creates some circular dependency issues with kconfig and is hard to manage.
We also have a mutually exclusive USB stacks, TINYUSB or USBUS which should probably be a choice.
#### Desired behaviour
1. Ideally we want a board to default to the most obvious STDIO implementation, for example, if I have nucleo, it uses a UART, for some ESPs, USB is the default way to communicate.
2. These backends could always be overridden though, for example, I may just connect directly to a UART and want my STDIO there, or maybe use a ble based STDIO.
3. The next condition would be specifically for boards with a USB based STDIO. Since we have a TINYUSB stack and a USBUS stack we would want to use the associated STDIO depending on the stack the application selects.
4. However, if nothing is selected by the application, than bring in a USB stack (board based preference) unless there is a specific non-USB based STDIO is selected. For these boards that have this requirement, we DO NOT want to bring in the USB stack if the STDIO is specifically overridden (important for kconfig).
#### Update kconfiglib package to RIOT-OS org managed one
There is a problem with the upstreamed Kconfiglib implementation and the maintainer is not responsive to the fix. The issue is to do with `menuconfig`s in choices and has been fixed with the RIOT-OS based fork. This PR requires this fix.
#### Changes to the USB stack
A new entry point is introduced `USB_DEVICE` which indicates wanting a USB device but not caring which stack is used. This allows making a `choice` between the `TINYUSB` and `USBUS` stack allowing mutual exclusivity.
Making the USB stack a `choice` means that a specific stack cannot be selected from non-board/non-cpu/non-application based symbols. Thus the `REQUIRES_` design pattern is used for a module to indicate a specific stack should be selected. This is needed for the `MODULE_TINYUSB_NETDEV` in this case.
#### Changes to USB STDIO implementations
The `MODULE_STDIO_CDC_ACM` and `MODULE_STDIO_TINYUSB_CDC_ACM` are both depends on now, using a `REQUIRES_USB_STDIO` to select the dependencies.
This means we do not have to use `select PACKAGE_TINYUSB if TEST_KCONFIG && !MODULE_USBUS` in the board select.
##### Why not just select the USB from STDIO_USB
Issue with using select for STDIO choices is that we cannot check which stack we are using to default the STDIO to that, breaking desired behaviour 3.
#### The `FORCE_USB_STDIO`
Desired behaviour 4 means that we do not want to bring in the USB stack if we override, say, to the UART STDIO backend. Due to the limitations of Kconfig, this is my solution to prevent the USB from being brought in if there is an STDIO that doesn't need it. It is only for the `esp32s2-wemos-mini` board and would not be used in other places and would only need to be explicitly disabled for applications requiring different STDIO backend and no USB. It is not perfect but I think the best solution and fairly understandable...
<details><summary><h4>Issues with Kconfig</h4></summary>
When using a `choice` and having conditional defaults, for example:
```kconfig
choice IMPL
default FOO if CHOOSE_FOO
default BAR
```
there is a limitation of the level of the level of knowledge that can be expected from Kconfig, a limitation on circular dependencies, and a limitation that the dependencies only get resolved once.
For example, if ` BAR` selects something that would eventually select `CHOOSE_FOO`, then the default should be `FOO` and which would no longer select `BAR` preventing the select `CHOOSE_FOO`... Messy stuff and we would want an error saying no no no.
What Kconfig cannot handle is something like:
```kconfig
choice IMPL
bool "Implementation"
default FOO if CHOOSE_FOO
default BAR
config FOO
bool "Foo"
config BAR
bool "Bar"
endchoice
config CHOOSE_FOO
bool
config SYMBOL
bool
select CHOOSE_FOO if !BAR
```
`SYMBOL` causes a circular dependency in Kconfig even though the only possible outcome for the `choice` selection would be static. If we select `BAR` then `CHOOSE_FOO` would not be selected and we stay with `BAR`. If we select `FOO` than `CHOOSE_FOO` will be selected which stays with `FOO`. Everything should be fine, but isn't because Kconfig does not resolve to that degree, it simply sees that there is a dependency of the `IMPL` choice outcome (ie. `if !BAR`) that is a condition for a dependency of the `IMPL` choice selection (ie. ` if CHOOSE_FOO`).
This is a limitation of the Kconfig what what makes this problem so challenging, with Make we say "select some sort of USB backend if no other stdio is specifically requested" and it will.
</details>
An attempt at remodelling the dependencies of the USB stack in Kconfig.
Currently there are some issues, especially with the integration of TinyUSB package as a backend.
This will require a kconfiglib package fix though...
### Testing procedure
`TEST_KCONFIG=1 BOARD=reel make menuconfig -C examples/hello-world`
### Issues/PRs references
Requires https://github.com/ulfalizer/Kconfiglib/pull/123 to be merged upstream or fork for RIOT
Relates maybe to #18998 and #19038
19672: pkg/micropython: model in Kconfig r=aabadie a=aabadie
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19549: pkg/littlefs2: bump version to 2.6 r=benpicco a=benpicco
19608: build system: fix `make compile-commands BUILD_IN_DOCKER=1` r=benpicco a=maribu
### Contribution description
Just run `make compile-commands` outside of docker, as the compile commands generated in the docker container won't be helpful for tools outside of the container anyway.
19657: drivers/mpu9x50: clean up code r=benpicco a=maribu
### Contribution description
Avoid using floating point arithmetic and some minor cleanups.
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
This release bumps the on-disk minor version of littlefs from lfs2.0 -> lfs2.1.
This change is backwards-compatible, but after the first write with the new version,
the image on disk will no longer be mountable by older versions of littlefs.
19335: ipv6/nib: 6LBR should not send RS on their downstream interface r=fabian18 a=fabian18
19581: cpu/samd5x: enable FDPLL1 at 200MHz r=benpicco a=dylad
### Contribution description
This PR allows to use the second FDPLL (the first one is used to generated the 120MHz frequency used by the core and some peripherals). The second FDPLL is setup to run at 200MHz which is the maximum allowed by this MCU.
In fact, I reused the existing function which setup FDPLL0 so it can be used in a generic way for both PLL (since they are the same IP).
I change the way the computation offset (left shift by 5) is done because 200MHz << 5 wouldn't fit inside an `uint32_t` and I wanted to avoid using an `uint64_t` here
Two additional commits are present for a small cleanup and a fix.
This is currently unused in our codebase, so it shouldn't impact this platform too much as the `ONDEMAND` bit is set. the FDPLL will not be running out of the box. But `@gschorcht` might need it pretty soon.
### Testing procedure
This PR can be tested on a `same54-xpro` and an oscilloscope using the following the patch:
```
From 76490845ec72387b24116bdd364a61365c186aa1 Mon Sep 17 00:00:00 2001
From: Dylan Laduranty <dylan.laduranty@mesotic.com>
Date: Thu, 11 May 2023 17:42:16 +0200
Subject: [PATCH] removeme! for debug purpose
Signed-off-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
---
cpu/samd5x/cpu.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/cpu/samd5x/cpu.c b/cpu/samd5x/cpu.c
index f778991a5b..2866c8c9e5 100644
--- a/cpu/samd5x/cpu.c
+++ b/cpu/samd5x/cpu.c
`@@` -220,7 +220,7 `@@` static void fdpll_init(uint8_t idx, uint32_t f_cpu)
}
static void gclk_connect(uint8_t id, uint8_t src, uint32_t flags) {
- GCLK->GENCTRL[id].reg = GCLK_GENCTRL_SRC(src) | GCLK_GENCTRL_GENEN | flags | GCLK_GENCTRL_IDC;
+ GCLK->GENCTRL[id].reg = GCLK_GENCTRL_SRC(src) | GCLK_GENCTRL_GENEN | flags | GCLK_GENCTRL_OE | GCLK_GENCTRL_IDC;
while (GCLK->SYNCBUSY.reg & GCLK_SYNCBUSY_GENCTRL(id)) {}
}
`@@` -384,6 +384,12 `@@` void cpu_init(void)
dma_init();
#endif
+ sam0_gclk_enable(SAM0_GCLK_200MHZ);
+ /* output both FDPLL (GCLK0 and GCLK4) to gpios */
+ gpio_init_mux(GPIO_PIN(PB, 14), GPIO_MUX_M);
+ gpio_init_mux(GPIO_PIN(PB, 10), GPIO_MUX_M);
+ /* PB14 -> EXT2 PB10 -> QSPI SCK */
+
/* initialize stdio prior to periph_init() to allow use of DEBUG() there */
early_init();
--
2.35.3
```
It will output both FDPLLs to PB14 and PB10. Their frequency can then be measured using an oscilloscope.
### Issues/PRs references
None.
19612: pkg/ndn-riot: drop unmaintained pkg r=benpicco a=maribu
### Contribution description
Upstream [1] has seen no activity since 2018, so it safe to assume this is dead. It is reasonable to assume that any users - if there ever were any - have moved on.
Fixes https://github.com/RIOT-OS/RIOT/issues/15638
[1]: https://github.com/named-data-iot/ndn-riot
19643: examples/suit_update: some test fixes r=aabadie a=kaspar030
19655: net/ipv6: make use of clz in ipv6_addr_match_prefix() r=benpicco a=benpicco
Co-authored-by: Fabian Hüßler <fabian.huessler@st.ovgu.de>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
- Replace all users of `$(RIOTBASE)/build` with the already present
`$(BUILD_DIR)` variable
- Replace all users of `$(BUILD_DIR)/pkg` with the already present
`$(PKGDIRBASE)` variable
- Create a `CACHEDIR.TAG` file in the `$(BUILD_DIR)`
When using openthread with the ieee802154_submac module, a hard fault is
triggered otherwise because the submac's init function calls the
event_handler callback.
19525: semtech-loramac: extend list of supported radio with sx1261, sx1262 and sx1268 r=maribu a=aabadie
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19346: pkg/tinydtls: allow build for AVR r=benpicco a=benpicco
19512: SUBSYSTEMS.md: add jia200x to subsystems r=benpicco a=jia200x
19513: boards/nrf52840dongle/doc: Update nrfutil pointers r=benpicco a=chrysn
### Contribution description
Nordic changed its nrfutil; this change adjust to it.
I'm not fully happy with recommending that tool at all due to its bad quality (see rambling in https://github.com/RIOT-OS/RIOT/issues/19511), but short of soldering on a debug header or touch-probing it with wires it's the only way in to the device. I may later add follow-up recommendations to switch to riotboot, but this now at least fixes the immediate issue.
### Testing procedure
* Look at the updated documentation.
### Issues/PRs references
Closes: https://github.com/RIOT-OS/RIOT/issues/19511
19514: dist/testbed-support: remove obsolete boards from iotlab archi r=benpicco a=aabadie
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: chrysn <chrysn@fsfe.org>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
19375: tools/renode: add support for target reset r=benpicco a=aabadie
19376: boards/stm32f4discovery: use default port to access stdio via cdc acm r=benpicco a=aabadie
19377: pkg/tinyusb: fix default VID/PID configuration r=benpicco a=gschorcht
### Contribution description
This PR fixes the default VID/PID configuration if tinyUSB board reset feature is used.
While reviewing PR #19086 I was wondering why `esp32s2-wemos-mini` requires to set `USB_VID`/`USB_PID` explicitly to `USB_VID_TESTING`/`USB_PID_TESTING`. The reason was that tinyUSB board reset feature wasn't declared as RIOT internal.
### Testing procedure
Flashing `esp32s2-wemos-mini` should still work.
```
BOARD=esp32s2-wemos-mini make -C tests/shell flash
```
The VID/PID should be `1209:7d00` and not `1209:7d01`.
### Issues/PRs references
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Defining the feature as RIOT internal avoids that the board has to set USB_VID and USB_PID explicit to USB_VID_TESTInG/USB_PID_TESTING if tinyUSB board reset feature is used.
- Changed user provided synchronization functions in order to completely eliminate the platform dependency from FatFs code.
- Fixed a potential error in f_mount when FF_FS_REENTRANT.
- Fixed file lock control FF_FS_LOCK is not mutal excluded when FF_FS_REENTRANT && FF_VOLUMES > 1 is true.
- Fixed f_mkfs creates broken exFAT volume when the size of volume is >= 2^32 sectors.
- Fixed string functions cannot write the unicode characters not in BMP when FF_LFN_UNICODE == 2 (UTF-8).
- Fixed a compatibility issue in identification of GPT header.
19331: pkg/tinydtls: Adjust defaults r=miri64 a=chrysn
### Contribution description
This adjusts two defaults in tinydtls:
* Default verbosity is set to warning. At the info level, this module produces way more output (several lines per new connection, and even per message) than is common in RIOT.
* If gcoap is used, the buffer size is adjusted to the gcoap buffer size plus overhead. Otherwise, CoAP-over-DTLS works fine until one happens to request larger resources.
### Testing procedure
* Run examples/gcoap_dtls
* Send a CoAP request from outside, eg. with `aiocoap-client 'coaps://[fe80::3c63:beff:fe85:ca96%tapbr0]/.well-known/core' --credentials testserver.json` (where testserver.json is `{"coaps://[fe80::3c63:beff:fe85:ca96%tapbr0]/*": {"dtls": {"psk": {"ascii": "secretPSK"}, "client-identity": {"ascii": "Client_identity"}}}}`).
Before, there are messages shown for every request; now there are none.
Modify `examples/gcoap/server.c` as follows:
```patch
diff --git a/examples/gcoap/server.c b/examples/gcoap/server.c
index bf2315cd01..28e1faac27 100644
--- a/examples/gcoap/server.c
+++ b/examples/gcoap/server.c
`@@` -68,7 +68,7 `@@` static const coap_resource_t _resources[] = {
};
static const char *_link_params[] = {
- ";ct=0;rt=\"count\";obs",
+ ";ct=0;rt=\"count\";obs;looooooooooooooooooooooong-attribute=\"loooooooooooooooooooooooooooooong\"",
NULL
};
```
The request passes; without this patch, it is stuck in retransmissions until "Network error: Retransmissions exceeded".
### Issues/PRs references
This contributes to making #19289 usable with a minimum level of security. (That module fills up the gcoap buffer to the brim). While the module handles the verbosity as well as it can (occasionally admitting that it lost bytes of output), the previous verbosity produces an infinite stream of stdout data. (But the default should be quiet immaterial of that particular PR).
Co-authored-by: chrysn <chrysn@fsfe.org>