This patch adds a process that is started automatically to request DHCP
configuration. It also moves the IP configuration ahead of autostart processes
in case some autostart process depends on the IP configuration.
This patch replaces the pinmux APIs that require users to look up an arbitrary
function number for the desired function of each pin. The replacement API
functions have intuitive names and permit users to pass board-level IO port
numbers. The API functions internally convert those to CPU-level port numbers
when necessary. Furthermore, when configuring a pin to be a digital input or
output, those API functions also perform the corresponding configuration
operation on the CPU-level GPIO port. The revised APIs halt when users attempt
to configure a currently-unsupported GPIO, specifically those in the GPIO_SUS
port range and those implemented on the expander chip EXP2. This also means
that such ports are left unconfigured during initialization, whereas the
pinmuxing for them was setup by the old implementation.
This patch refactors the pinmux configuration code for Intel Galileo to simplify
it. This patch also corrects an off-by-one error in how the pin number is
checked in galileo_pinmux_set_pin.
This patch adds a general protection exception handler that prints a
message indicating the faulting instruction and the error code. This is
useful when debugging general protection exceptions.
Enable the 32.768-kHz crystal on all the CC2538 platforms where it is
present in order to get a better time accuracy.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
This patch fixes UART system call authorization initialization (when
protection domain support is enabled) to only initialize the system call
entrypoint and authorization data structures once, prior to per-port
setup. Previously, if two UARTs were configured, the setup procedure for
the second UART would erase the system call authorization for the
first (console) UART, resulting in a crash upon the next attempt to
perform console output.
This patch adds a Dockerfile for building a container configured as a
build environment for Intel Galileo boards. This patch also provides
documentation for using the containerized build environment. Finally, it
streamlines the instructions for booting Contiki on Galileo and includes
other documentation refinements.
#1684 slightly varied RF startup time and, as a result, threw ContikiMAC timing configuration off. This manifests itself with very poor CC13xx PROP mode radio performance, as documented in #1747.
This pull fixes this bug by slightly increasing ContikiMAC's inter-packet interval. This gives the receiver a little more time to respond with an ACK to unicast frames.
Fixes#1747
`CC2650_FAST_RADIO_STARTUP` is required for TSCH, but it currently breaks ContikiMAC. We set the default value to the one that will work with the default choice of RDC.
Fixes#1744
This adds support for flashing to multiple devices, by implementing the
$MOTES option used by the Z1.
This replaces the $PORT interface, as it only allowed flashing to one
device at a time, and the $MOTES interface was still used for other
tasks (such as getting a list of connected devices).
A foreach loop is used to dynamically create an upload rule per device
that needs to be flashed.
The "main" upload rule depends on the device specific ones.
This allows for parallel flashing.
The PORT variable can still be sued for backwards compatibility.
Changed the MOTES variable that makes a $(shell) call to not be
recursively expanded.
- platform/atarixl/Makefile.atarixl: put two more objects into high memory
- platform/atarixl/contiki-conf.h: define WWW_CONF_WGET_EXEC
- tools/6502/Makefile: add 'clean' target; remove unused CONTIKI define
Change certain CPP conditionals into C conditionals, which should be possible for the compiler to optimize at runtime. This makes the source code easier to read.
According to the CC1310LP design files, the flash on it is the same as the flash on the CC2650 LP (MX25R8035F 8Mbit). However, the flash on some CC1310 LPs reportedly identifies itself as the 16Mbit one (MX25R1635F). Instruction sets are identical, we simply need to tell the driver to recognise this part's Device ID.
The block that controls the `.upload` target is unnecessarily replicated in multiple sub-board Makefiles. This was originally done because the SmartRF and the Launchpad can be programmed with the c2538-bsl script, whereas the sensortag cannot.
This commit moves the `cc2538-bsl` / `.upload` target logic to the top level cpu Makefile (`cpu/cc26xx-cc13xx/Makefile.cc26xx-cc13xx`). Board makefiles simply set the make variable `BOARD_SUPPORTS_BSL` to 1 to signal that they can be programmed by the BSL script. If `BOARD_SUPPORTS_BSL` is not equal to 1, trying to use the `.upload` target will return an error message.
For example:
```
$ make BOARD=sensortag/cc2650 cc26xx-demo.upload
using saved target 'srf06-cc26xx'
This board cannot be programmed with the ROM bootloader and therefore does not support the .upload target.
```
Two errors have been spotted, when IPv6 is enabled in the ravenusb
Project-Makefile:
#CONTIKI_NO_NET=1
CONTIKI_WITH_IPV6=1
The compile error results from a variable name mismatch in cdc_task.c
The variable 'r' is undeclared and should be renamed to 'route'
The linker also fails with 'undefined references'
This has been mediated by adding 'core/net' to Modules in the
Project-Makefile.
This patch adds a simple non-driver protection domain sample to serve
as an example for defining other non-driver protection domains. It
simply performs a ping-pong test of protection domain switching
latency during boot, including optional accesses to a private metadata
region, and prints out the results.
This patch extends the protection domain framework with an additional
plugin to use Task-State Segment (TSS) structures to offload much of
the work of switching protection domains to the CPU. This can save
space compared to paging, since paging requires two 4KiB page tables
and one 32-byte page table plus one whole-system TSS and an additional
32-byte data structure for each protection domain, whereas the
approach implemented by this patch just requires a 128-byte data
structure for each protection domain. Only a small number of
protection domains will typically be used, so
n * 128 < 8328 + (n * 32).
For additional information, please refer to cpu/x86/mm/README.md.
GCC 6 is introducing named address spaces for the FS and GS segments
[1]. LLVM Clang also provides address spaces for the FS and GS
segments [2]. This patch also adds support to the multi-segment X86
memory management subsystem for using these features instead of inline
assembly blocks, which enables type checking to detect some address
space mismatches.
[1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
[2] http://llvm.org/releases/3.3/tools/clang/docs/LanguageExtensions.html#target-specific-extensions
This patch implements a simple, lightweight form of protection domains
using a pluggable framework. Currently, the following plugin is
available:
- Flat memory model with paging.
The overall goal of a protection domain implementation within this
framework is to define a set of resources that should be accessible to
each protection domain and to prevent that protection domain from
accessing other resources. The details of each implementation of
protection domains may differ substantially, but they should all be
guided by the principle of least privilege. However, that idealized
principle is balanced against the practical objectives of limiting the
number of relatively time-consuming context switches and minimizing
changes to existing code.
For additional information, please refer to cpu/x86/mm/README.md.
This patch also causes the C compiler to be used as the default linker
and assembler.
This patch configures Isolated Memory Regions (IMRs) to block DMA to
code and data regions that do not contain any data that needs to be
DMA-accessible.
The Intel Quark X1000 SoC includes support for Isolated Memory Regions
(IMRs), which are specified using range registers and associated
control registers that are accessible via the message bus. This patch
adds a driver for accessing those registers.
The Intel Quark X1000 SoC includes a message bus that is accessible
via PCI configuration registers. It communicates to various SoC
components such as the Isolated Memory Region (IMR) registers and the
Remote Management Unit. This patch adds a driver for accessing the
message bus.
