The way it's now it's easy to interpret that there was an error, when
really there was not. As seen in issue #19025 quite some time can be
spent following a wrong clue.
19166: boards/seeedstudio-gd32: complete and improve board definition r=kaspar030 a=gschorcht
### Contribution description
This PR completes and improves the board definition for the Seeedstudio GD32 RISC-V Dev board. It
- adds the user LED and Button definitions to `board.h` (bef4209109)
- adds the SAUL support for user LED and Button definitions (7a5b2f1fb43f5e28eec4f65c8e7367510be6eb80)
- changes the OpenOCD configuration (32c0c4b1b5b9705ffcd2bb02a1d868ad35ca3bbc)
- to be usable with Upstream OpenOCD release version 0.12.0
- to allow different FTDI configuration and other adapters
- adds a documentation with flashing guide, feature list, support status, pinout, schematic reference (9dcc83b8ceb8a9ce526f0a03053a242e866ebf4a)
These changes is the first PR for a number of follow-up PR I will provide in next days to extend the GD32VF103 support. I have already working
- `periph_adc` support,
- `periph_spi` support,
- `tinyusb_device` support,
and almost finished
- `periph_i2c` support (implemented and working with some errors),
- `pm_layered` support (implemented but not working correctly yet), and
- `periph_usbdev` support (implemented by extending `usbdev_synopsys_dwc2 driver but bot working yet).
I will try to implement
- `periph_gpio_irq` support,
- `periph_rtc` support, and
- `periph_rtt` support.
Since I'm using the Sispeed Longan Nano board for testing, I will add the board definition for this board. I will then move some board definitions to a common folder.
### Testing procedure
Green CI.
Documentation should be generated correctly.
Flashing the `seeedstudio-gd32` should still work.
`tests/leds` should work.
### Issues/PRs references
19171: tests/gnrc_rpl: Disable CI test for native r=benpicco a=maribu
### Contribution description
This disables the `tests/grnc_rpl` test run for `native`. This test is too flaky to be included in the CI.
### Testing procedure
Not needed
### Issues/PRs references
None
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
19079: cpu/esp32: add periph_flashpage support r=kaspar030 a=gschorcht
### Contribution description
This PR provides the `periph_flashpage` support for ESP32x SoCs.
For byte-aligned read access to constant data in the flash, the MMU of all ESP32x SoCs allows to map a certain number of 64 kByte pages of the flash into the data address space of the CPU. This address space is called DROM. Normally the whole DROM address space is assigned to the section `.rodata`. The default flash layout used by all ESP32x SoCs is:
| Address in Flash | Content |
|:-----------------------|:-----------|
| `0x0000` or `0x1000` | bootloader |
| `0x8000` | parition table |
| `0x9000` | `nvs` parition with WiFi data |
| `0xf000` | `phy_init` partition with RF data |
| `0x10000` | `factory` partition with the app image |
The factory partition consists of a number of 64 kByte pages for the sections `.text`, `.rodata`, `.bss` and others. The `.text` and `rodata` sections are page-aligned and are simply mapped into the instruction address space (IROM) and the data address space (DROM), respectively. All other sections are loaded into RAM.
If the `periph_flashpage` module is used, the `periph_flashpage` driver
- decreases the size of the `.rodata` section in DROM address space by `CONFIG_ESP_FLASHPAGE_CAPACITY`,
- adds a section `.flashpage.writable` of size `CONFIG_ESP_FLASHPAGE_CAPACITY` at the end of DROM address space that is mapped into data address space of the CPU,
- reserves a region of size `CONFIG_ESP_FLASHPAGE_CAPACITY` starting from `0x10000` in front of the image partition `factory` and
- moves the image partition `factory` by `CONFIG_ESP_FLASHPAGE_CAPACITY` to address `0x10000 + CONFIG_ESP_FLASHPAGE_CAPACITY`.
The new flash layout is then:
| Address in Flash | Content |
|:-----------------------|:-----------|
| `0x0000` or `0x1000` | bootloader |
| `0x8000` | parition table |
| `0x9000` | `nvs` parition with WiFi data |
| `0xf000` | `phy_init` partition with RF data |
| `0x10000` | flashpage region |
| `0x10000 + CONFIG_ESP_FLASHPAGE_CAPACITY` | `factory` partition with the app image |
This guarantees that the flash pages are not overwritten if a new app image with changed size is flashed. `CONFIG_ESP_FLASHPAGE_CAPACITY` has to be a multiple of 64 kBytes.
~The PR includes PR #19077 and PR #19078 for the moment to be compilable.~
### Testing procedure
The following tests should pass.
```
USEMODULE='esp_log_startup ps shell_cmds_default' BOARD=esp32-wroom-32 make -j8 -C tests/periph_flashpage flash term
```
```
USEMODULE='esp_log_startup ps shell_cmds_default' BOARD=esp32-wroom-32 make -j8 -C tests/mtd_flashpage flash term
```
### Issues/PRs references
Depends on PR #19077
Depends on PR #19078
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
If a board has fixed defines for `WS281X_PARAM_PIN` and `WS281X_PARAM_NUMOF`
the test will overwrite them.
This leads to the LEDs *not* working in with the test, which is very confusing.
19159: boards/rpi-pico-w: fix too large board image r=benpicco a=krzysztof-cabaj
### Contribution description
PR #19071 adds Raspberry Pico W board to RIOT. Unfortunately, current Doxygen version used for generation boards documentation available in RIOT webpage, do not scale images. In effect current [documentation](https://doc.riot-os.org/group__boards__rpi__pico__w.html) presents to users very, very huge board image. This PR change this image to smaller one, like in other boards.
### Testing procedure
```
make doc
xdg-open doc/doxygen/html/group__boards__rpi__pico__w.htm
```
and compare with current [documentation](https://doc.riot-os.org/group__boards__rpi__pico__w.html).
### Issues/PRs references
PR #19071
Co-authored-by: krzysztof-cabaj <kcabaj@gmail.com>
19157: sys/shell_lock: do not call strlen, less jumpy r=benpicco a=kfessel
### Contribution description
the current `_safe_strcmp` depends on not being optimized and not being inlined (implicitly given by the -O0), this new one does less (would say not since even O3 had compile results that should not return early or show different runtimes for different secrets).
the runtime of strlen depend on the length of the string (password) therefor it is removed. `ifs` are very jumpy and depend on the contend of password, this avoids `ifs` sadly clang still compiles some boolean statements to if.
with this PR the `__attribute__((optimize("O0")))` should be removable.
### Testing procedure
see https://godbolt.org/z/x35b85cEx
and run the `<RIOT>/tests/shell_lock`
### Issues/PRs references
#19155 made me aware of this function
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
19060: SUBSYSTEMS.md: migrate subsystem list from wiki r=maribu a=jia200x
19154: tests/gcoap_dns: Remove duplicate r=miri64 a=Teufelchen1
### Contribution description
Removes a duplicated test. Originally, the test should have looked different and not be a duplicate. However, the behavior the test aimed at is no longer present anyway, hence it can be removed - rather than fixed.
Further insights can be provided by `@miri64`
Co-authored-by: Jose Alamos <jose@alamos.cc>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
18477: gnrc_static: add static network configuration r=miri64 a=benpicco
19101: CI: update check-labels-action r=miri64 a=kaspar030
19155: Revert "sys/pm_layered: pm_(un)block add attribute optimize(3)" r=maribu a=Teufelchen1
Revert "sys/pm_layered: pm_(un)block add attribute optimize(3) -shortens hotpath"
This reverts commit 5447203921.
### Contribution description
Compiling `examples/gnrc_networking_mac` using `TOOLCHAIN=llvm` yields the following error:
```
RIOT/sys/pm_layered/pm.c:77:16: error: unknown attribute 'optimize' ignored [-Werror,-Wunknown-attributes]
__attribute__((optimize(3)))
```
As indicated, this is because the attribute `optimize` is GCC only and not present in LLVM.
Compare the manpages of [GCC](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html) and [LLVM](https://clang.llvm.org/docs/AttributeReference.html).
### Testing procedure
Since this should only affect performance and not behavior, no special testing is needed. I am not aware of any tests in RIOT which could verify that assumption.
### Issues/PRs references
Introduced in #18846
There is another instance of this attribute being used in[ shell_lock.c](6fb340d654/sys/shell_lock/shell_lock.c (L80)). Since the usage is security related, I omit it from this PR.
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
