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 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 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 adds an example program to print out information about the
configuration of the Intel Quark X1000 SoC Isolated Memory Regions
(IMRs), the Host System Management Mode Controls register, and the
Host Memory I/O Boundary register.
This patch adds an example for I2C callbacks that is very similar to
the i2c-LSM9DS0 example except that it uses a PWM device that is built
into the platform.
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 introduces an example application to demonstrate how to use
GPIO driver APIs to manipulate interrupt pins.
The application uses default galileo pinmux initialization and sets
the GPIO 5 (IO2) as output pin and GPIO 6 (IO3) as interrupt. It toggles
the output pin stat at every half second in order to emulate an interrupt.
This triggers an interrupt and the application callback is called.
This patch introduces an example application to demonstrate how to use
GPIO driver APIs to manipulate input pins.
The application uses default galileo pinmux initialization and sets the
GPIO 5 (IO2) as output pin and GPIO 6 (IO3) as input. It toggles the
output pin state at every half second and checks the value on input pin.
This patch adds an example application that shows how to use I2C driver
APIs to communicate with LSM9DS0 sensor. At every 5 seconds, the
application reads the "Who Am I" register from gyroscope sensor and
prints if the register value matches the expected value.
This patch introduces an example application to demonstrate how to use
GPIO driver APIs to manipulate output pins. The application sets the
GPIO 4 pin as output pin and toggles its state at every half second.
Michael LeMay
Ricardo de Almeida Gonzaga