iotlab-m3 boards always ended up not being able to flash after time.
This changes managed to fix and flash boards that where able to be flashed with
the deprecated `ft2232` driver and not with the `ftdi` driver used in RIOT.
It combines configuration from openocd, iot-lab, RIOT config and Alexandre
Abadie feedback
* http://repo.or.cz/openocd.git/blob/HEAD:/tcl/interface/ftdi/iotlab-usb.cfg
* ftdi configuration
* https://github.com/iot-lab/iot-lab-gateway/blob/2.4.1/gateway_code/static/iot-lab-m3.cfg
* `trst_and_srst` config
* Alexandre feedback and http://openocd.org/doc/html/Reset-Configuration.html
* 'connect_assert_srst' reset configuration
* it prevents errors in the output on first flash
* should help on boards with invalid code
* It was taken from what Alexandre found for board 'b-l072z-lrwan1'
* It requires using '-c reset halt' instead of '-c halt' before debug
* RIOT
* Keep the `configure -rtos` auto
The new tool (mkconstfs2) features:
* more robust filename handling: no need for mangling,
and works on Windows.
* Better output generation: nothing is written in case
of failures.
* Allows more control over the files that are included:
- does not traverse directories, filenames must be explicitly
given.
- The "root" can be explicitly given (thus the tool can get
the same result independently of the CWD).
Thanks to MichelRottleuthner for making it work with Windows paths.
Since IPHC also manipulates the total number of bytes of a received
datagram (by decompressing it), this also needs to be exposed. I guess
I was too focused on introducing a *generic* packet buffer for a future
virtual reassembly buffer (where it isn't needed, but so isn't `pkt` to
be honest), that I totally forgot about it in #9352.
This fixes an alignment issue I encountered in the static version of
the packet buffer.
The bug is caused by a race-condition where a certain order of
operations leads to a chunk being released according to the
byte-alignment of the platform, but overlapping potential space for
a future `_unused_t` struct e.g. (x mark allocated regions):
Future leak of size sizeof(_unused_t) Time
v |
+------------+-----+--------------------+ |
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| +
+------------+-----+--------------------+ |
|
+------------+--+--+--------------------+ |
| |xxxxxxxxxxxxxxxxxxxxxxx| +
+------------+--+--+--------------------+ |
|
+-----+------+--+--+--------------------+ |
|xxxxx| |xxxxxxxxxxxxxxxxxxxxxxx| +
+-----+------+--+--+--------------------+ |
|
+-----+------+-----+---------+----------+ |
|xxxxx| |xxxxxxxxxx| +
+-----+------+-----+---------+----------+ |
|
+-----+------+-----+--------------------+ |
|xxxxx| |xxxxxxxxxxxxxxxxxxxxxxxxxx| +
+-----+------+-----+--------------------+ |
|
+------------+-----+--------------------+ |
|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| +
+------------+-----+--------------------+ |
|
+------------+-----+--------------------+ |
|xxxxxxxxxxxxxxxxxx| | +
+------------+-----+--------------------+ |
|
+------------+-----+--------------------+ |
| |xxxxx| | +
+------------+-----+--------------------+ |
v
Sadly, I wasn't able to create a reproducable unittest that show-cases
this corner-case, since I don't understand the order of operations that
cause this one 100%, but the bug is reproducable (but also not
reliably) by sending large (i.e. fragmented) packets to a 6Lo-enabled
host from more than 1 host simultaneously (use `gnrc_pktbuf_cmd` to
check).
By making the size of `_unused_t` the only condition for alignment,
this bug is fixed.
