#
79da0792 |
|
01-Mar-2020 |
Gerwin Klein <gerwin.klein@data61.csiro.au> |
Convert license tags to SPDX identifiers This commit also converts our own copyright headers to directly use SPDX, but leaves all other copyright header intact, only adding the SPDX ident. As far as possible this commit also merges multiple Data61 copyright statements/headers into one for consistency.
|
#
297d2b63 |
|
04-Sep-2019 |
Kent McLeod <Kent.Mcleod@data61.csiro.au> |
CMake: Invoke configuration files to build kernel This leverages #!/usr/bin/env -S cmake -P to invoke a cmake configuration file as a script that configures and builds a kernel in the current directory with the configuration that was invoked. It is a quick way for producing a kernel.elf or kernel_all_pp.c input file to verification for a particular config.
|
#
d5ded0c4 |
|
06-May-2019 |
Kent McLeod <Kent.Mcleod@data61.csiro.au> |
CMake: Process platform files in -C config Allow projects that use the kernel as a subproject to configure the kernel in -C scripts. CMake supports providing a script via -C upon first initialisation of a build directory. This script is expected to populate the configuration cache for the rest of the build to depend on. This is how standalone kernel builds are currently configured. However in buildsystems that add the kernel as a subproject, it was up to the application to modify configuration properties before or after the kernel was imported. This lead to circular dependencies where properties were changed by a module later in the build, but this then invalidated properties that were set based on the first property's original value. This lead to running CMake multiple times in order for settings to reach a stable state. We now assume that most shared system configuration occurs in initial -C settings evaluation. seL4Config.cmake is a configuration module that the kernel exports that allows a configuration script to set kernel platform and architecture settings in a way that doesn't introduce circular dependencies. seL4Config can be imported into other configuration files. This should make it easier for a full system configuration script to query and configure kernel configuration values without introducing circular dependencies on configuration properties.
|
#
3207abee |
|
20-Mar-2019 |
Curtis Millar <curtis.millar@data61.csiro.au> |
RFC-3: Update context for x86 to use FS and GS. TLS_BASE virtual register is replaced with FS_BASE and GS_BASE virtual registers. The FS_BASE and GS_BASE virtual registers are moved to the end of the context so they need not be considered in the kernel exit and entry implementation. Removed tracking of ES, DS, FS, and GS segment selectors on kernel entry and exit. ES and DS are clobbered on kernel entry with the RPL 3 selector for a DPL 3 linear data segment. FS is clobbered on exit with the RPL 3 selector for the DPL 3 segment with FS_BASE as the base. This is done on exit to reload the value from the GDT. GS is clobbered on exit with the RPL 3 selector for the DPL 3 segment with GS_BASE as the base. This is done on exit to reload the value from the GDT. Kernel entry and exit code is refactored, simplified, and improved in light of the above changes. x64: update verified config to use fsgsbase instr The verification platform for x64 relies on the fsgsbase instruction.
|
#
4ede700f |
|
06-May-2019 |
Kent McLeod <Kent.Mcleod@data61.csiro.au> |
CMake: Invert plat config.cmake processing order Instead of processing each platform CMake file during the arch's config.cmake file, we process all of the platform CMake files first. This is primarily motivated by wanting to move platform configuration into a config file that is processed via a -C argument to the initial build initialisation command. Now a platform config is responsible for setting the kernel architecture and it's own platform/arch specific config settings. Where previously a platform was chosen in an arch specific way via either setting KernelARMPlatform or KernelX86Sel4Arch or KernelRiscVPlatform, a platform can now be set by KernelPlatform. In cases where a platform may further parameterise its configuration it is free to choose its own config options to query. Platforms that support multiple seL4 architectures should use KernelSel4Arch to query this. Platforms that provide sub platforms such as exynos5 and subplatforms exynos5250, exynos5410 and exynos5422 can be selected by specifying KernelPlatform=exynos5, KernelARMPlatform=exynos5410 for example.
|
#
96bff79f |
|
13-Sep-2017 |
Adrian Danis <Adrian.Danis@data61.csiro.au> |
Add verified configuration for x64
|