Commit Graph

10 Commits

Author SHA1 Message Date
Michael LeMay
73774def6b x86, galileo: Add sample non-driver protection domain
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.
2016-04-22 08:16:43 -07:00
Michael LeMay
4cdb7ba9b6 x86: Add TSS-based protection domain support
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
2016-04-22 08:16:39 -07:00
Michael LeMay
3908253038 x86: Add support for (paging-based) protection domains
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.
2016-03-21 17:18:06 -07:00
Michael LeMay
b0de416682 x86: Adjust UEFI header size
The UEFI GenFw program inserts headers ahead of the code in the UEFI
binary.  The linker script adjusts the starting address of the .text
section to account for that.  This prevents the symbols from being
perturbed.  This patch accounts for a recent change in the size of the
headers added by the GenFw program.
2016-03-21 17:18:06 -07:00
Michael LeMay
c815fa4511 x86: Use shared ISR for I2C and GPIO
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.
2016-02-16 21:19:44 -08:00
Michael LeMay
f85654a82f x86, galileo: Add UEFI support
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.
2015-12-21 08:06:14 -02:00
Andre Guedes
6b433aede1 x86: Improve release binary size
This patch adds -ffunction-sections and -fdata-sections to the
'release' CFLAGS so each function and data is place into its
own section in the output file. It also adds --gc-section to
the 'release' LDFLAGS so the linker removes the sections which
are not referenced.

This patch also adds -ffunction-sections and -fdata-sections
options to CFLAGS from build_newlib.sh. This increases newlib
static libraries size, however, the Contiki image shrinks even
more since --gc-section removes "dead code" from newlib.

As a practical effect, all unused function and data (as well as
sections such as .eh_frame) are striped out from the final elf
binary. This shrinks our release binary drastically.

Finally, to prevent --gc-section from removing .multiboot section,
this patch adds KEEP(*(.multiboot)) to quarkX1000.ld.
2015-12-21 08:06:14 -02:00
Jesus Sanchez-Palencia
bdcf58033a x86: Group sections for QuarkX1000
Child sections can be created depending on the CFLAGS used when building Contiki.
For instance, if built with -ffunction-sections or -fdata-sections would create
one section per function/variable and -Os sometimes split part of .text into one
child section.

This can also be an issue if we start linking with external libraries that are
built in such a way. Since we can't foresee how the port is going to be used,
we should make sure it is ready for the cases above.

This patch fixes this by correctly grouping child sections into their parent
sections.

Patch developed while investigating a bug with José Souza (jose.souza@intel.com).
2015-12-21 08:06:14 -02:00
Andre Guedes
13bbe8a5b5 x86: Don't generate .note.gnu.build-id section
This patch adds "--build-id=none" to default LDFLAGS so
.note.gnu.build-id section is not generated. This section
contains unique identification for the built files what is
not important to us (at least at this moment).

This change simplifies all linker scripts for SoCs based on x86
(at this moment we only have Quark X1000) since we don't have to
care about it anymore.
2015-12-21 08:06:14 -02:00
Andre Guedes
a8849b2909 x86: Move bootstrap code and linker script to cpu/x86
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.
2015-12-21 08:06:14 -02:00