19733: cpu/msp430: reorganize code r=maribu a=maribu
### Contribution description
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this:
```C
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
```
This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families.
In addition, it cleans up the `msp430_regs.h` by dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19747: gnrc/ipv6/nib: reset rs_sent counter also for not-6LN interfaces r=maribu a=fabian18
19769: cpu/nrf53: add initial support with nRF5340DK-APP board r=maribu a=dylad
### Contribution description
This PR adds support for nRF5340 MCU and its associated Nordic development board, nRF5340DK.
This MCU provides a dual Cortex-M33, one application core running at up to 128MHz, and one network core running at up to 64MHz.
Peripherals are inherited from others Nordic MCUs families so it shouldn't be hard to add more of them in followup PRs.
For now, only the minimal set of peripherals is supported:
- GPIO / GPIO_IRQ
- UART
- TIMER
### Testing procedure
Build the usual test application for the supported peripherals and flash the board.
nRF5340DK provides two serial ports on its embedded debugger. RIOT's shell should be available on the first one (/dev/ttyACM0)
### Issues/PRs references
#18576#19267
19782: cpu/msp430: fix for ti's msp430-gcc-opensource package ld version r=maribu a=hugueslarrive
### Contribution description
My msp430 toolchain (https://www.ti.com/tool/MSP430-GCC-OPENSOURCE) was broken by #19484:
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
/opt/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld: .rodata not found for insert
collect2: error: ld returned 1 exit status
make: *** [/home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/../../Makefile.include:761 : /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf] Erreur 1
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version
GNU ld (Mitto Systems Limited - msp430-gcc 9.3.1.11) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+'
9.3
1.11
2.34
hugues@p700:~/github/cpu_msp430_common/RIOT$ /opt/ti/msp430-gcc/msp430-elf/bin/ld --version | grep -Eo '[0-9]\.[0-9]+$'
2.34
```
### Testing procedure
```
hugues@p700:~/github/cpu_msp430_common/RIOT$ BOARD=msb-430 make -j64 -C examples/hello-world
make : on entre dans le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
Building application "hello-world" for "msb-430" with MCU "msp430fxyz".
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/core/lib
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/boards/common/msb-430
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/drivers/periph_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/auto_init
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/div
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/libc
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/malloc_thread_safe
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/newlib_syscalls_default
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/preprocessor
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/sys/stdio_uart
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430fxyz/periph
"make" -C /home/hugues/github/cpu_msp430_common/RIOT/cpu/msp430_common/periph
text data bss dec hex filename
8612 722 866 10200 27d8 /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world/bin/msb-430/hello-world.elf
make : on quitte le répertoire « /home/hugues/github/cpu_msp430_common/RIOT/examples/hello-world »
```
### Issues/PRs references
Introduced by #19484, highlighted in #16727.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@posteo.net>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
The MSP430 vendor files already provide macros containing register
constants and symbols (provided via linker scripts) containing addresses
of peripheral registers. So lets make use of that rather than
maintaining a long list of constants.
19770: cpu/nrf5x_common: reset all available CC channels r=maribu a=dylad
### Contribution description
Properly reset all CC channels of a given timer at initialization (except the last one which seems to be used for capture only in the driver).
The issue with the previous code was that some CCs were not clear on some nRF52 MCUs.
For instance, nRF52840 has 4 CCs for its two first timers, then 6 CCs for all others.
nRF9160 and nRF5340 also have 6 CCs for all its timer peripherals.
Thus, loop through the reported number of channels and clear the associated register instead of hardcoding the first 3 CC channels.
### Testing procedure
CI should be enough I think.
### Issues/PRs references
None.
19773: cpu/nrf{52,9160}: remove duplicate sevonpend bit r=maribu a=dylad
### Contribution description
This PR removes duplicate calls of `SCB_SCR_SEVONPEND` bit in nRF52 and nRF9160.
This call is already done [here](7c320055a1/cpu/cortexm_common/cortexm_init.c (L60))
### Testing procedure
Flash a nRF52 or nRF9160-based board and check that the board is still alive.
### Issues/PRs references
None. I notice this duplicate call when porting nRF53.
19774: boards/frdm-k22f: fixes long lines in periph_conf.h r=maribu a=hugueslarrive
19775: boards/frdm-k64f: fixes long lines and comma separated by whitespaces… r=maribu a=hugueslarrive
… warnings
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: dylad <dylan.laduranty@mesotic.com>
Co-authored-by: Hugues Larrive <hlarrive@pm.me>
Vera++ doesn't like `#error` preprocessor directives without a quoted
string afterwards (and also my syntax highlighter doesn't like this as
well). So let's add the quotes to have the tools not spooked out.
19712: cpu/riscv: Add PMP driver r=MrKevinWeiss a=Teufelchen1
### Contribution description
Hi! 🐘
this adds a basic RISC-V physical memory protection (PMP) driver to RIOT. Well, 'driver' might be a stretched, feels more like a little utility :)
EDIT: Also added a no-execute RAM option for the hifive & a corresponding test
Since I only have an Hifive rev b, it's only enabled on this board / cpu. I also tested the code on an ESP32-C but the feature can't be enabled there, as `cpu/riscv_common/` is not used by the ESP32...
### Testing procedure
* Grab a hifive rev b
* go to `examples/hello-world`
* Add `USEMODULES += periph_pmp` to the `Makefile`
* Include `pmp.h` in `main.c`
* Add code e.g. `print_pmpcfg(0);`
* compile & flash & term
You should see something like this:
```
# Hello World!
# You are running RIOT on a(n) hifive1b board.
# This board features a(n) fe310 MCU.
# pmp00cfg: - R-X OFF 0x00000000 - 0x00000000
```
Co-authored-by: Teufelchen1 <bennet.blischke@outlook.com>
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx]
MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible
MCU families the code was located in the msp430fxyz folder, resulting
in case of the UART driver in particularly bizarre code looking roughly
like this:
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
This splits the peripheral drivers for USCI and USART serial IP blocks
into separate files and relocates everything in cpu/msp430, similar to
how cpu/stm32 is organized.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
19703: cpu/sam0_eth: interrupt based link detection/auto-negotiation r=benpicco a=benpicco
19724: dist/tools/openocd: add OPENOCD_SERVER_ADDRESS variable r=benpicco a=fabian18
19735: nrf5x_common: Clear I2C periph shorts r=benpicco a=bergzand
### Contribution description
The I2C peripheral's shortcuts are used with the read and write register to automatically stop the I2C transaction or to continue with the next stage.
With simple I2C read and write bytes these shorts are not used, but are also not cleared by the function in all cases, causing it to use the shortcut configuration set by a previous function call. This patch ensures that the shorts are always set by the read and write functions
### Testing procedure
Should be possible to spot with a logic analyzer and the I2C periph test. Maybe the HIL test can also detect it :)
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
The I2C peripheral's shortcuts are used with the read and write register
to automatically stop the I2C transaction or to continue with the next
stage.
With simple I2C read and write bytes these shorts are not used, but are
also not cleared by the function in all cases, causing it to use the
shortcut configuration set by a previous function call. This patch
ensures that the shorts are always set by the read and write functions
Always enable the internal pull-up on the SCL line to always have a
functional I2C bus. This may increase power consumption where an
external pull up is present as well. But let's wait for a real world
use case where this would help to extend battery life before making
this configurable.
This fixes https://github.com/RIOT-OS/RIOT/issues/19021
19689: cpu/sam0_eth: disable PHY when MAC is sleeping r=maribu a=benpicco
19700: pkg/openthread: Fix Kconfig and broken example r=maribu a=MrKevinWeiss
### Contribution description
There were some improvements that could be make to the kconfig modeling of the `pkg/openthread` after looking a bit closer.
The bigger problem is the hash check on nightlies require reproducible builds, however, even with make, the builds are not reproducible. So, for now, I just rename the `app.config.test` to `skip.app.config.test` to prevent murdock from trying to do a hash check but still letting it be useable.
### Testing procedure
Green murdock, all modules match `examples/openthread`
- Rename `skip.app.config.test` to `app.config.test`
- Run the following
```
./dist/tools/compile_test/compile_like_murdock.py -j 8 -a examples/openthread/ -b all -m
```
<details>
```
examples/openthread/ cc2538dk PASS
examples/openthread/ frdm-kw41z PASS
examples/openthread/ iotlab-a8-m3 PASS
examples/openthread/ iotlab-m3 PASS
examples/openthread/ nrf52840-mdk PASS
examples/openthread/ nrf52840dk PASS
examples/openthread/ omote PASS
examples/openthread/ openlabs-kw41z-mini PASS
examples/openthread/ openlabs-kw41z-mini-256kib PASS
examples/openthread/ openmote-cc2538 PASS
examples/openthread/ phynode-kw41z PASS
examples/openthread/ reel PASS
examples/openthread/ remote-reva PASS
examples/openthread/ remote-revb PASS
examples/openthread/ samr21-xpro PASS
examples/openthread/ usb-kw41z PASS
```
</details>
### Issues/PRs references
Fixes an aspect of broken master
19701: sys/usb/Kconfig: Fix default PID r=maribu a=MrKevinWeiss
### Contribution description
Seems like I just didn't have the correct `USB_PID` defined in the `usb-codes.inc.mk`.
It should be 0x7D01 not 0x7001.
It only shows up in nightlies since the hash would mismatch.
### Testing procedure
Simulated nightly testing with:
```
./dist/tools/compile_test/compile_like_murdock.py -j 8 -a tests/pkg/tinyusb_cdc_acm_stdio/ tests/pkg/tinyusb_cdc_msc/ tests/pkg/tinyusb_cdc_msc/ tests/sys/fido2_ctap/ tests/sys/usbus_board_reset/ tests/sys/usbus_msc/ -b arduino-zero samd21-xpro nucleo-f767zi -v
```
<details>
```
tests/pkg/tinyusb_cdc_acm_stdio/ arduino-zero PASS
ctests/pkg/tinyusb_cdc_acm_stdio/ nucleo-f767zi PASS
tests/pkg/tinyusb_cdc_acm_stdio/ samd21-xpro PASS
tests/pkg/tinyusb_cdc_msc/ arduino-zero PASS
tests/pkg/tinyusb_cdc_msc/ nucleo-f767zi PASS
tests/pkg/tinyusb_cdc_msc/ samd21-xpro PASS
tests/pkg/tinyusb_cdc_msc/ arduino-zero PASS
tests/pkg/tinyusb_cdc_msc/ nucleo-f767zi PASS
tests/pkg/tinyusb_cdc_msc/ samd21-xpro PASS
tests/sys/fido2_ctap/ arduino-zero PASS
tests/sys/fido2_ctap/ samd21-xpro PASS
tests/sys/usbus_board_reset/ arduino-zero PASS
tests/sys/usbus_board_reset/ nucleo-f767zi PASS
tests/sys/usbus_board_reset/ samd21-xpro PASS
tests/sys/usbus_msc/ arduino-zero PASS
tests/sys/usbus_msc/ nucleo-f767zi PASS
tests/sys/usbus_msc/ samd21-xpro PASS
```
### Issues/PRs references
Broken master in nightlies.
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com>
19677: boards/nucleo-l432k: provide three periph_timer instances r=maribu a=maribu
### Contribution description
- `cpu/stm32/periph_timer`: Generalize to also work with timers that do not have 4 channels
- `boards/common/stm32`: Add timer config for three timers based on TIM2, TIM15, and TIM16 (the three general-purpose timers of the STM32L4)
- `boards/nucleo-l432kc`: Make use of the new timer config
19683: cpu/sam0_eth: clean up init() r=maribu a=benpicco
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
19610: drivers/periph/rtc: improve doc on rtc_set_alarm r=maribu a=maribu
### Contribution description
- point out behavior on denormalized time stamps
- use errno codes to indicate errors (and adapt the few instances of actual error handling to use them)
19670: cpu/stm32: stm32f4 BRR from BSRR r=maribu a=kfessel
### Contribution description
sometimes one wants to save one instruction :)
just write the bits we need to write.
### Testing procedure
tests/periph/gpio_ll tests this
### Issues/PRs references
`@maribu` might know some reference
maybe #19407
19678: gnrc_sixlowpan_iphc: fix NULL pointer dereference r=maribu a=miri64
19679: gnrc_sixlowpan_frag_sfr: fix ARQ scheduler race-condition r=maribu a=miri64
19680: gnrc_sixlowpan_frag_rb: fix OOB write in _rbuf_add r=maribu a=miri64
19681: sys/xtimer: improve documentation r=maribu a=maribu
### Contribution description
- Add a warning that xtimer is deprecated, so that new code hopefully starts using ztimer
- Add a hint that `ztimer_xtimer_compat` can be used even after `xtimer` is gone
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de>
- point out behavior on denormalized time stamps
- use errno codes to indicate errors (and adapt the few instances of
actual error handling to use them)
The assumption that all STM32 timers have exactly four channels no
longer holds. E.g. the STM32L4 has the following general purpose timers:
- TIM2: 32 bit, 4 channels
- TIM15: 16 bit, 2 channels
- TIM16: 16 bit, 1 channel
Hence, a new field is added to the timer configuration to also contain
the number of timer channels. Due to alignment the `struct` previously
was padded by 16 bit, so adding another 8 bit field doesn't increase
its size.
For backward compatibility, a value of `0` is considered as alias for
`TIMER_CHANNEL_NUMOF` (or 4), so that the number of timer channels
only needs to be set when the timer is different from the typical 4
channel timer. This helps backward compatibility.
19618: cpu/stm32: fix riotboot settings for L4 and WB r=benpicco a=gschorcht
### Contribution description
This PR fixes the `riotboot` configuration for L4 and WB.
The family is not called `stm32l4` or `stm32wb` but `l4` and `wb`. That is, the `riotboot` configuration didn't work at all. Furthermore, a minimum `RIOTBOOT_LEN` of `0x2000` is required for L4.
Found when investigating the compilation errors for `bootloaders/riotboot_serial` in PR #19576.
### Testing procedure
1. Green CI.
2. Use the following commands:
```
BOARD=nucleo-l496zg make -C tests/riotboot info-debug-variable-RIOTBOOT_HDR_LEN
BOARD=p-nucleo-wb55 make -C tests/riotboot info-debug-variable-RIOTBOOT_HDR_LEN
```
In master these commands give
```
0x400
```
With this PR these commands give
```
0x200
```
as expected.
3. Use the following commands:
```
BOARD=nucleo-l496zg make -C tests/riotboot info-debug-variable-RIOTBOOT_LEN
BOARD=p-nucleo-wb55 make -C tests/riotboot info-debug-variable-RIOTBOOT_LEN
```
In master these commands give
```
0x1000
```
With this PR these commands give
```
0x2000
```
as expected.
### Issues/PRs references
19639: tests/net/gnrc_mac_timeout: add automated test r=aabadie a=aabadie
19644: gnrc_ipv6_nib: include RIO with all subnets in downstream RA r=benpicco a=benpicco
19649: gnrc_sixlowpan_iphc: prefix bits outside context must be zero r=benpicco a=benpicco
19656: gnrc/ipv6_auto_subnets: allow to configure minimal prefix length r=benpicco a=benpicco
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
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>
The family is not called `stm32l4` or `stm32wb` but `l4` and `wb`. That is, the `riotboot` configuration didn't work. A minimum `RIOTBOOT_LEN` of `0x2000` is required for WB.
