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.
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.
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 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.
This patch adds support for PCI BAR1 and also changes
the pci_init(), instead of having one function for each `bar`
we now set the `bar` to pci_config_addr_t parameter before calling
the pci_init() function..
