deac/osd-contiki
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
osd-contiki/cpu/x86/Makefile.x86_quarkX1000

89 lines
3.1 KiB
Makefile
Raw Normal View History

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.
2015-08-10 17:34:02 +02:00
# See mm/README.md for a description of available settings:
X86_CONF_PROT_DOMAINS ?= none
x86: Break Makefile.x86 into common and pc specific ones 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.
2015-04-29 19:58:29 +02:00
include $(CONTIKI)/cpu/x86/Makefile.x86_common
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.
2015-08-10 17:34:02 +02:00
CONTIKI_CPU_DIRS += drivers/legacy_pc drivers/quarkX1000 init/legacy_pc net mm
x86: Break Makefile.x86 into common and pc specific ones 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.
2015-04-29 19:58:29 +02:00
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-01-07 02:00:45 +01:00
CONTIKI_SOURCEFILES += bootstrap_quarkX1000.S rtc.c pit.c pic.c irq.c nmi.c pci.c uart-16x50.c uart.c gpio.c i2c.c eth.c shared-isr.c
x86, galileo: Add driver for Isolated Memory Regions (IMRs) 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.
2015-09-27 07:27:42 +02:00
CONTIKI_SOURCEFILES += imr.c msg-bus.c
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.
2015-08-10 17:34:02 +02:00
CONTIKI_SOURCEFILES += stacks.c
ifneq ($(X86_CONF_PROT_DOMAINS),none)
CONTIKI_SOURCEFILES += prot-domains.c $(X86_CONF_PROT_DOMAINS)-prot-domains.c imr-conf.c
ifeq ($(X86_CONF_PROT_DOMAINS),paging)
LINKERSCRIPT_SFX = _paging
X86_CONF_SYSCALLS_INT = 1
ifeq ($(X86_CONF_USE_INVLPG),1)
CFLAGS += -DX86_CONF_USE_INVLPG
endif
# This matches the definition of X86_CONF_PROT_DOMAINS__PAGING in prot-domains.h:
CFLAGS += -DX86_CONF_PROT_DOMAINS=1
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
2015-08-08 00:43:10 +02:00
else ifeq ($(X86_CONF_PROT_DOMAINS),tss)
# This matches the definition of X86_CONF_PROT_DOMAINS__TSS in prot-domains.h:
CFLAGS += -DX86_CONF_PROT_DOMAINS=2
X86_CONF_MULTI_SEG = 1
CONTIKI_SOURCEFILES += tss-prot-domains-asm.S
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.
2015-08-10 17:34:02 +02:00
else
$(error Unrecognized setting for X86_CONF_PROT_DOMAINS: \
$(X86_CONF_PROT_DOMAINS). See cpu/x86/mm/README.md for \
descriptions of available settings)
endif
ifeq ($(X86_CONF_SYSCALLS_INT),1)
CONTIKI_SOURCEFILES += syscalls-int-asm.S tss.c
endif
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
2015-08-08 00:43:10 +02:00
ifeq ($(X86_CONF_MULTI_SEG),1)
LINKERSCRIPT_SFX = _multi_seg
CONTIKI_SOURCEFILES += multi-segment.c
# Due to the way the multi-segment implementation of protection domains define
# tightly-bounded stack segments, the base pointer register cannot be used as
# a general-purpose register in all circumstances. The stack segment is used
# by default for a data access that uses the base pointer as the base register
# to compute the address. If the data referenced by the base pointer is not
# on the stack, then the access will fail. Thus, it is necessary to disable
# the omit-frame-pointer optimization. See mm/README.md for more details of
# how multi-segment protection domains are implemented.
CFLAGS += -fno-omit-frame-pointer
endif
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.
2015-08-10 17:34:02 +02:00
endif
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-05-08 00:20:14 +02:00
galileo: Fix Makefile.galileo 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).
2015-07-07 00:34:00 +02:00
CFLAGS += -m32 -march=i586 -mtune=i586
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.
2015-08-10 17:34:02 +02:00
LDFLAGS += -m32 -Xlinker -T -Xlinker $(CONTIKI)/cpu/x86/quarkX1000$(LINKERSCRIPT_SFX).ld
# The C compiler is used to invoke the assembler, so the CFLAGS should be
# passed to it on the command line:
ASFLAGS = -c $(CFLAGS)
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-07-10 20:21:00 +02:00
x86, galileo: Use IMRs to restrict DMA 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.
2015-09-30 06:29:35 +02:00
ifeq ($(X86_CONF_RESTRICT_DMA),1)
CONTIKI_SOURCEFILES += imr-conf.c
CFLAGS += -DX86_CONF_RESTRICT_DMA
LDFLAGS += -Xlinker -T -Xlinker $(CONTIKI)/cpu/x86/quarkX1000_dma.ld
endif
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-07-10 20:21:00 +02:00
### UEFI support
UEFI_DIR = $(CONTIKI_CPU)/uefi
ifndef EN_UEFI
# Include a Makefile generated by the build_uefi.sh script, if available.
# If that script was not run, then UEFI support will not be built.
-include $(UEFI_DIR)/Makefile.uefi
endif
ifeq ($(EN_UEFI),1)
EDK2_DIR = $(UEFI_DIR)/edk2
GEN_FW = $(EDK2_DIR)/BaseTools/Source/C/bin/GenFw
CONTIKI_CPU_DIRS += uefi
CONTIKI_SOURCEFILES += bootstrap_uefi.c
CFLAGS += -I$(EDK2_DIR)/MdePkg/Include -I$(EDK2_DIR)/MdePkg/Include/Ia32
else
$(info Note: UEFI support is disabled.)
x86: Remove spurious UEFI-related info message This patch removes a spurious info message in a UEFI-related portion of a Makefile.
2015-12-11 20:14:36 +01:00
$(info To enable UEFI support, run $(CONTIKI_CPU)/uefi/build_uefi.sh prior)
$(info to building Contiki.)
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-07-10 20:21:00 +02:00
endif
Reference in a new issue Copy permalink