This patch extends the protection domain framework with a third plugin
that is a hybrid of the previous two. The hardware task switching
mechanism has a strictly-defined format for TSS data structures that
causes more space to be consumed than would otherwise be required.
This patch defines a smaller data structure that is allocated for each
protection domain, only requiring 32 bytes instead of 128 bytes. It
uses the same multi-segment memory layout as the TSS-based plugin and
leaves paging disabled. However, it uses a similar mechanism as the
paging plugin to perform system call dispatches and returns.
For additional information, please refer to cpu/x86/mm/README.md.
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 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 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 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 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 slightly revises CFLAGS and LDFLAGS to specify the
optimization and debugging options and linker script in a way that is
compatible with using Clang as the C compiler and to invoke the linker
(i.e. CC = clang and LD = clang).
This patch adds a driver for an MMIO-accessible 16X50 UART. It
assumes that the boot firmware assigned an MMIO range to the UART. It
operates in polled mode with FIFOs enabled.
This patch adds the pci.c and pci.h files, which support access to PCI
configuration registers through a function interface. It defines the
PCI configuration register access I/O port addresses and the
pci_config_addr union and structure to assist in specifying addresses
of PCI configuration registers. It also defines the PCI configuration
register identifier for PCI BAR0.
This patch also adds wrappers for 32-bit 'in' and 'out' port I/O
instructions. They were placed in helpers.S, since they may be useful
to other modules besides just the PCI support module.
This patch moves the compiler and linking options related to QuarkX1000
SoC to Makefile.x86_quarkX1000 since it is more suitable. For instance,
'-m32' should be used in any platform based on QuarkX1000, not only
Galileo. The same rationale applies for the others options (e.g. -march,
mtune).
According to [1], we should disable non-maskable and maskable interrupts
while initializing RTC. Otherwise, the RTC may be left in an undefined
state (non-functional) if an interrupt occurs. Currently, maskable
interrupts are already disabled, but NMI is not.
This patch adds helpers APIs to enable/disable non-maskable interrupts
(NMI) and changes rtc_init() to disable NMI while initializing the RTC.
NMI enable/disable code is legacy-PC specific therefore it was put in
driver/legacy_pc/ directory.
Regarding the RTC initialization changes, just calling nmi_disable() and
nmi_enable is not enough since NMI and RTC share the same IO port. So We
should also set the NMI_ENABLE bit while selecting the RTC_INDEX.
Additionally, the nmi_disable() call is not strictly required since we
set the NMI_ENABLE bit while selecting the RTC_INDEX. However, to make
clear hat we are disabling NMI and to improve readability (by matching
NMI disable/enable), the nmi_disable() call was purposely used.
[1] http://wiki.osdev.org/RTC
This is a refactoring patch, no functionality is changed. It moves
loader.S and galileo.ld from platform/galileo/ to cpu/x86/ directory
since they seem to be more SoC-specific than platform-specific.
It also renames galileo.ld to quarkX1000.ld since it can be used by
any platform based on Quark X1000 SoC, not only Galileo.
Furthermore, this patch also renames loader.S to bootstrap_quarkX1000.S
since it is pretty much a bootstrap code to any platform based on Quark
X1000 SoC.
This commit turns cpu_init() into a SoC-agnostic function by
removing any SoC specific calls and isolating them into their
own SoC implementation.
We start this by isolating all IRQs initialization code from
the legacy-pc target, pic_init() and spurious IRQ7 registration,
into a new interface: irq_init() from irq.h. Future SoCs will have
to provide their own implementation of this interface.
This model is to be followed by future initialization code that
we may need to add and which is not common to all x86 SoCs.
Now the cpu/x86/ provides a Makefile.x86_common and a
Makefile.x86_pc. The former includes the common Makefile
and adds legacy pc specific implementations (currently,
drivers only) into the building context, while the latter
has everything that defines the bootstrap of a x86 CPU.
This commit also fixes platform/galileo/ so it includes the
correct makefile - Makefile.x86_quarkX1000. Galileo uses
a Quark X1000 SoC which is not an IBM Generic PC-like CPU,
but it does provide most of a PCs peripherals through
its "Legacy Bridge". Thus, it makes sense that QuarkX1000's
Makefile includes code from the legacy_pc x86 cpu.
