Enable the handling of flashing `softdevice.hex` when flashing the firmware
for openocd.
However, for flashing, only the `hexfile` and `binfile` can currently be used.
The `elffile` is generated with local pages aligned to `0x10000` which makes
the program starting at `0x1f000` be flashed from `0x10000` with padding bytes
even if the `.text` section is indeed at `0x1f000`:
readelf --sections bin/nrf52dk/gnrc_networking.elf
...
[ 1] .text PROGBITS 0001f000 00f000 00f698 00 AX 0 0 16
...
readelf --segments bin/nrf52dk/gnrc_networking.elf
...
LOAD 0x000000 0x00010000 0x00010000 0x1e6a0 0x1e6a0 R E 0x10000
...
The padding bytes would go through `verify_image` in `openocd` so be expected
to not be overwritten but are by `softdevice.hex`
Using --nmagic at link time removes the local page alignement but would
need dedicated testing.
`examples/gnrc_networking_mac/udp.c` is a duplicate of the file in
`gnrc_networking`. However, while the latter moved along in code style
and static analysis, the first was left a bit at the wayside. This
change resyncs the two files.
This adds a new target "archive-check".
Thin archives should be created with relative paths so that archives created
in a build container are useful in the host. This check ensures there are no
absolute paths inside thin archives.
Normal, or thick archives contain a copy of the object code. Thin
archives, on the contrary, are just an index to the .o files.
This patch does two things:
1. Change ARFLAGS to enable the "T" options.
2. Call AR with all relative paths.
The second step is necessary because the build system handles all
absolute paths. If the index in the thin archive contains absolute
paths, archives created in docker are no usable outside, and moving
the objects breaks the archive.
If all arguments to AR are relative, the resulting archive contains
filenames *relative to the .a file* and nothing should break as long
as the relative location of the .a and .o remains unchanged.
Compilation time is unchanged, but disc usage is reduced by approximately
50%. These are the result of a full RIOT build:
| Thin Archive | no | yes | Savings (%) |
| -------------- | ------: | ----: | ----------- |
| pkg (10e6 KiB) | 1 790 | 905 | 49% |
| Non pkg | 71 | 71 | 1% |
| Total | 1 812 | 976 | 46 % |
The default channel configuration is managed within the Makefiles of many
examples and tests. This commit moves the default channel logic to
`makefiles/default-channel.ink.mk` to ease maintenance. All Makefiles that
previously managed the default channel configuration themself have been
updated to include that file.
The default channel configuration of the cc110x has been added
This (re-)introduces the `CC110X_DEFAULT_CHANNEL` preprocessor macro to set the
default channel of the `cc110x` at compile time. The same macro has been used
in the previous version of the driver, so some users might still expect it to
work.
