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>
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>
- most were trivial
- missing group close or open
- extra space
- no doxygen comment
- name commad might open an implicit group
this hould also be implicit cosed but does not happen somtimes
- crazy: internal declared groups have to be closed internal
Instead of retrieving a pointer with NETOPT_STATS, retrieve the current
data. This avoids data corruptions when reading from one thread (e.g.
the thread running the shell (ifconfig command)) while another thread
is updating it (e.g. the netif thread).
The issue affects all boards, as users typically expect the count of
TX packets and the number of TX bytes to refer to the same state. For
16 bit and 8 bit platforms even a single netstat entry can read back
corrupted.
This fixes the issue by just copying the whole netstat_t struct over
without requiring explicit locking on the user side. A multi-threaded
network stack still needs to synchronize the thread responding to
netopt_get with the thread writing to the netstat_t structure, but that
is an implementation detail no relevant to the user of the API.
This avoids a race condition where the default router slots for the 6LBR
are used up by router advertisements from the 6Lo network that arrived
before router advertisements from the upstream network.
The border router should ignore 'default routers' from the 6Lo network as
it consitutes the uplink for that network.
If multihop distribution is not done using RA messages, then the
routers follow [RFC4861], which states that they merely do some
consistency checks; in this case, nothing in Section 8.1 applies.
- https://datatracker.ietf.org/doc/html/rfc6775#section-8.1
A single IP address will be added as a /128 prefix.
It makes sense to advertise it, as neighbors can then know that
the address/prefix is on-link.
It does however not make sense to advertise the prefix as suitable
for auto-configuration.
Co-authored-by: Fabian Hüßler <fabian.huessler@st.ovgu.de>
If the fib contains a route to a subnet via another host, it can not
be on-link.
Consider fib entries when deciding whether an address is on-link.
If a route via another host is a stronger match than an on-link
prefix, the address must be off-link.
Sending a RA with ltime = 0 does not get us added to the default router
list, but the options (and therefore the RIO) are still parsed.
This even appears to work with Linux as a receiver.
When the default router was removed or could not be added, `dr` will
be NULL.
In this case, don't cease sending router solicitations - we still don't
have a default router.
Consider the following: A node tries to forward a packet to another
host for which it does not know the route yet. It assumes it to be
on-link and starts a neighbor solicitation, putting the node address
in the destinatio cache.
Later the route is known (via a second hop) but the host is still in
the NIB.
The result is that gnrc_ipv6_nib_get_next_hop_l2addr() ends up in the
"nib: %s is in NC or on-link, start address resolution" case and does
not attempt to resolve the route.
This results in the host remaining unreachable even though now a route
is present.
If a node has two interfaces A with 2001:16b8:45b5:9af8:5884:3bff:fe4f:a903
and B with 2001:16b8:45b5:9afa:5884:3bff:fe4f:a902 and receives a neighbor
solicitation on A for an address configured on interface B, answer the neighbor
solicitation instead of bailing out with
> Target address 2001:16b8:45b5:9afa:5884:3bff:fe4f:a902 is not assigned
> to the local interface
This option was unused before, honor it to make it possible to start
with router advertisements disabled and enable them at run time.
The defaults remain unchanged by that.
If we switch the interface in gnrc_ipv6_nib_get_next_hop_l2addr()
we must also re-get the nib entry from the 'proper' interface.
Otherwise we will always find the host unreachable on the 'wrong'
interface.
Consider the following configuration:
nib prefix
2001:16b8:4569:88fc::/62 dev #7 expires 7081 sec deprecates 3481 sec
2001:16b8:4569:88fe::/63 dev #6
If `_on_link()` stops at the first match, a packet received from #7 with a
destination in the downstream subnet in #6 would always be sent back via #7
if this happens to be the first entry in the list.
Instead, consider all prefixes and return the one that is the closest match.
When two threads use `gnrc_ipv6_nib_get_next_hop_l2addr()` to determine
a next hop (e.g. when there is both an IPv6 sender and a 6LoWPAN
fragment forwarder), a race condition may happen, where one thread
acquires the NIB and the other acquires the network interface resulting
in a deadlock. By releasing the NIB (if acquired) before trying to
acquire the network interface and re-acquiring the NIB after the network
interface is acquired, this is fixed.
Non-routing 6LNs do not have to join the solicited nodes address, so
probing for a neighbor using that address may be in vain and only
spamming the LLN with unnecessary messages. RFC 6775 basically assumes
this in section 5.2:
> There is no need to join the solicited-node multicast address, since
> nobody multicasts NSs in this type of network.
In accordance with RFC 6775, section 5.2 an NCE should be set STALE
when an ARO renews the address registration for the address:
> The routers SHOULD NOT garbage-collect Registered NCEs (see
> Section 3.4), since they need to retain them until the Registration
> Lifetime expires. Similarly, if NUD on the router determines that
> the host is UNREACHABLE (based on the logic in [RFC4861]), the NCE
> SHOULD NOT be deleted but rather retained until the Registration
> Lifetime expires. A renewed ARO should mark the cache entry as
> STALE. Thus, for 6LoWPAN routers, the Neighbor Cache doesn't behave
> like a cache. Instead, it behaves as a registry of all the host
> addresses that are attached to the router.
When `nce` is NULL on the duplicate check, the later re-fetching of the
`nce` might result in an actual NCE entry that then contains a
duplicate, so we need to re-check the EUI-64 again as well.
