The conditional definitions in project-conf.h depending on
CONTIKI_TARGET_<TARGET_NAME> were ignored at link time, which broke the
linker script if it used these definitions, so the flashed applications
could crash or malfunction.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
If the setup of socket 0 to 3 with 4+2+1+1KB is detected then the W5100 is _not_ initialized, otherwise it does set up socket 0 and 1 with 4KB each. Either way socket 0 is used - now with 4KB instead of 8KB as before.
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.
Bug fixes include:
- keep interrupts disabled during lpm_sleep() so that we don't
miss any interrupts we may have been expecting
- check that the pending etimer isn't already expired (and don't sleep
at all if it is)
- check that the about-to-be scheduled rtimer wakeup is neither too
far into the future nor too close into the future (or even in the
past) before actually setting the interrupt (should fix#1509); If
the time is out of bounds we use a default min or max value instead.
- Correctly handle LPM_MODE_MAX_SUPPORTED set to zero (and added a
macro for the zero value) so that sleeping can be disabled altogether
- If no etimer is set, we specify a wakeup time which is reasonably far
into the future instead of setting none at all (this will save on
power consumption whenever no etimers are set).
Also did a bit of refactoring in that some long functions were broken
into multiple functions.
This patch revises the I2C and GPIO initialization code to always be
run during platform boot rather than within each process that requires
it.
This patch also revises the gpio-output example to use a pin that is
set as an output by the default pinmux configuration. Previously, it
used a pin that was set as an output by the pinmux configuration that
is in effect when the OS does not change the pinmux configuration.
This patch permits interrupts to be generated by both the I2C and GPIO
controllers for simultaneously-executing applications. The controllers
share a single interrupt pin, INTC. Prior to this patch,
quarkX1000_gpio_init() routed INTA to PIRQC and IRQ 10 (due to an
incorrect assumption that INTA is connected to the GPIO controller),
and quarkX1000_i2c_init() routed INTC to PIRQC and IRQ 9. The I2C
controller initialization is a prerequisite for GPIO initialization,
so the final configuration was that INTA and INTC were both routed to
PIRQC and IRQ 10. Thus, only the GPIO ISR was being invoked, even if
the I2C controller was actually responsible for the interrupt.
This patch refactors the I2C and GPIO ISR setup and handler code so
that the shared portions are combined in
cpu/x86/drivers/legacy_pc/shared-isr.[ch]. The I2C and GPIO drivers
communicate their interrupt information to the shared component by
placing structures in a specific section of the binary.
When sending a command to the CC13xx/CC25xx RF core, we wait for command completion by checking the LSB of CMDSTA (correctly so). However, in doing so we also zero out the 3 CMDSTA return bytes. For some commands, those bytes contain useful information (e.g. an RSSI value) and are required by the caller.
This problem manifests itself e.g. in PROP mode `channel_clear()`, whereby the caller will always see an RSSI value of 0.
This pull therefore fixes the logic in `rf_core_send_cmd()` to check for command completion by blocking on the CMDSTA result byte without zeroing out the 3 return bytes.
Fixes#1465
Fix the following warning issued by GCC ARM Embedded 5-2015-q4-major:
../../cpu/cc2538/dev/udma.c: In function 'udma_init':
../../cpu/cc2538/dev/udma.c:59:10: warning: passing argument 1 of 'memset' discards 'volatile' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
memset(&channel_config, 0, sizeof(channel_config));
^
In file included from <toolchain-path>/arm-none-eabi/include/string.h:10:0,
from ../../platform/cc2538dk/./contiki-conf.h:12,
from ../../cpu/cc2538/dev/udma.c:38:
<toolchain-path>/arm-none-eabi/include/string.h:25:7: note: expected 'void *' but argument is of type 'volatile struct channel_ctrl (*)[4]'
_PTR _EXFUN(memset,(_PTR, int, size_t));
^
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The PKA drivers and examples were full of include paths missing the
appropriate prefix, or using angle brackets instead of double quotes or
the other way around.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Add generic AES functions that should be able to support all the modes
of operation of the hardware AES crypto engine, i.e. ECB, CBC, CTR,
CBC-MAC, GCM, and CCM.
This makes it possible to easily implement these modes of operation
without duplicating code.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
This patch adds support for building the UEFI EDK2 tools on 32-bit
hosts. It also revises the script to support rebuilding the tools
when the script is re-invoked after the EDK2 repository has previously
been downloaded.
This patch refactors the MMIO routines in the GPIO and I2C drivers to
eliminate the base_addr parameter that specifies the MMIO base
address. Instead, just the MMIO routines themselves retrieve the base
address from the driver structure.
This patch adds support for optionally building EFI binaries in
addition to Multiboot ELF binaries. It includes a script,
build_uefi.sh, that downloads tool and library sources from the EDK II
project, builds the GenFw tool that is used to create UEFI binaries,
and creates a makefile that is included from the main x86 common
makefile and enables UEFI support in the Contiki build system. If the
script is not run prior to building Contiki, then an informational
message will be displayed with instructions for running build_uefi.sh
if UEFI support is desired. This patch also adds the path to the
auto-generated makefile to .gitignore.
This patch modifies the linker script for the Intel Quark X1000 to
account for the output file section offsets and alignment expectations
of the EDK II GenFw project.
This patch also adds a newlib patch to remove the weak symbol
attribute from floating point stdio support routines. See
<newlib>/newlib/README for an explanation of how the newlib developers
intended for _printf_float and _scanf_float to be linked. Newlib
declares them as weak symbols with the intention that developers would
force them to be linked only when needed using a linker command line
option. However, some but not all Contiki programs require them, so
we cannot simply always include or exclude them. Instead, we remove
the weak symbol attributes and rely on the linker to automatically
determine whether or not they should be linked. This avoids an issue
in which weak symbols were undefined in the intermediate DLL generated
as part of the UEFI build process. That resulted in the GenFw program
emitting "ERROR 3000" messages when it encountered relocations
referencing such an undefined symbol.
Finally, this patch updates README.md to both make some revisions to
account for the UART support introduced in previous patches as well as
to provide instructions for using the UEFI support.
This patch modifies the newlib and Contiki C and C++ compiler flags to
omit exception handling unwind tables (see
http://wiki.dwarfstd.org/index.php?title=Exception_Handling).
Removing these tables saves space in debug builds and has not caused
any readily-apparent functional changes.
Here is the size listing for an example program built without this
patch:
text data bss dec hex filename
76002 1508 21224 98734 181ae all-timers.galileo
Here is the size listing for the same program with this patch:
text data bss dec hex filename
72918 1508 21224 95650 175a2 all-timers.galileo
The primary motivation for this patch is to help enable UEFI support.
The .eh_frame and .eh_frame_hdr sections that are otherwise generated
are treated as code sections by the EDK2 GenFw program, since they are
read-only alloc sections. They get grouped with the actual code
sections, ahead of the data sections. This perturbs symbols and
complicates debugging.
This patch adds a simple, space-efficient driver for the Ethernet
interface built into the Intel Quark X1000. It only allocates a
single packet descriptor for each of the transmit and receive
directions, computes checksums on the CPU, and enables
store-and-forward mode for both transmit and receive directions.
This patch adds gpio-pcal9535a.c and gpio-pcal9535a.h files,
which support access to I2C-based PCAL9535A GPIO controller
configuration register through a function interface.
The PCAL9535A is a low-voltage 16-bit GPIO expander with interrupt
and reset for I2C-bus/SMBus applications. It contains the PCA9535
register set of four pairs of 8-bit Configuration, Input, Output,
and Polarity Inversion registers, and additionally, the PCAL9535A has
Agile I/O, which are additional features specifically designed to
enhance the I/O. More about PCAL9535A can be found in its datasheet[1].
This driver is needed in order to configure Galileo pinmux.
[1] - http://www.nxp.com/documents/data_sheet/PCAL9535A.pdf
This patch adds the i2c.c, i2c.h and i2c-registers.h files,
which support access to I2C controller configuration register
through a function interface.
This patch adds the gpio.c and gpio.h files, which support
access to GPIO Controller (non-legacy) configuration register
through a function interface.
It doesn't add interrupt support due to pinmux reasons. On
Galileo Gen 2 we need to configure a pin as input/interrupt
using pinmux and this can only be achieved through I2C. There's
one pin exported by default as GPIO output and we used this one
to test this driver.
In the future, we plan to add an I2C driver and a pinmux configuration
driver in order to solve this kind of problems.
