This explains why the DTS overlays intentionally throw away part of
the kernel memory window.

This is a hack that allows user-space tools like the capDL static
allocator to work. Otherwise, the allocator (currently unaware of the
kernel window) would think that there is a 28-bit untyped at pptr
0xf0000000, and would generate untyped derivations that are not
available at runtime.

Note that we clamp to 0xff000000 on exynos4 and exynos5, *not*
0xfff00000 (PPTR_TOP), to avoid the ASID PD hole at
0xff000000..0xff200000. The affected platforms are ARM VM platforms;
VM images are often larger than 13MiB and would overlap the ASID hole
if loaded from PPTR_TOP. init_freemem fails if this overlap exists.

This is so KernelDTBSize can be consumed by other tools.

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.

This matches the other GIC regions.

This adds support for the 64-bit i.MX8M Quad evaluation kit.
Currently only AArch64 EL1 is supported.

This is to reflect that this driver provides support for features that
are newer than gic_pl390 such as virtualisation.

Share definitions between gic_pl390.h and gic_v3.h.

Checking the value of the register write pending bit before reading from
the generic timer is an optimisation

This enables invocations to change the trigger mode of an IRQ.

TODO: Decide what EOI mode we want.

This driver should be compatible with GIC v3 implementations

This is in preparation for providing this driver as a generic GIC v3
driver.

Separate system register initialisation from redistributor register
initialisation

- Use array for storing per-core mapping of the redistributor register
mappings.
- Locate the base address of each of these mappings based on iterating
through the full device mappings looking for matchin MPIDR values.
- When accessing redistributor registers, index into the array based on
current logical core id.
- On single core configurations these arrays only have one element.

mpidr_map is used to store a lookup from seL4 logical core to mpidr
value for that core.
mpidr_to_gic_affinity correctly transforms the mpidr value stored in
mpidr_map to an appropriate GICD_IROUTER register value.

Some ARMv8 cores do not have a GIC that has backwards
compatibility. This adds ARM GIC 500 (GICv3 and GICv4) support to
seL4. It should also be noted that there are much more distributor and
redistributor registers than in previous version. The platform
implementor that needs a GIC500 should take care to set up the kernel
devices properly.

Change-Id: Ia7c546f7874a758ecd1ee8a29dd749eb3a2444f3

This is required for Arm devices that have more registers and require
larger memory mappings.

Some platforms and configurations do not allow user code to change the
value of the register used for TLS. On these architectures a syscall can
be used to allow the kernel to update the register on their behalf.

This does not immediately update the value in the user context on many
configurations as the values are only stored in the user context on a
context switch.

Switched appropriate naming conventions.
Was using the aarch64, have switched to aarch64 names.

TIPDRURW -> tpidr_el0
TPIDRURO -> tpidrro_el0
TPIDRPRW -> tpidr_el1

Switch TLS register on aarch32 from TPIDURO (tpidrro_el0) to tpidr_ro so
that it can be written to from user-land.

Thread ID registers tpidr_el0 have been added to the user context for
aarch32 and aarch64.

Only the thread ID that is writeable from EL0 is saved in the TCB and
saved/restored on context switch.

Thread IDs that are only changed within a VM (the read-only thread ID
for exception level 0 and the thread ID for exception level 1) are
stored in the VCPU and saved and stored as part of VM enable/disable.

Thread IDs that are only changed with VMs have been separated out into
hypervisor code.

The globals frame no longer serves its original purpose of informing a
thread of its IPC buffer address, and instead as a virtual
implementation of thread ID registers.

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.

This removes the assumption that each platform sotres the IPC buffer
address in a platform-specific register. The IPC buffer address is
instead stored in a thread-local variable in libsel4 which must be
initialised by the runtime.

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.

It is 16 bytes on 32-bit systems and 32 bytes on 64-bit systems

INTERNAL implies FORCE but in some versions of CMake if a config option
has been passed in via a -D option the INTERNAL set doesn't override the
value when it should.

See: https://gitlab.kitware.com/cmake/cmake/issues/19015
  INTERNAL does not imply FORCE for CACHE

All options that get unset are based on the selected platform and are
not allowed to be in the public config cache.

Instead of setting this option on each platform that supports aarch64,
we set it for all aarch64 platforms. It is expected that every valid
aarch64 platform has an FPU and will be correctly context switched by
the kernel.

These values are specified by the platform and not user configurable

At the stage where this is processed, Kernel32 hasn't been defined yet.

The UL_CONST macro was leading to a macro definition that didn't have
brackets around the addition and using the constant in negative
arithmetic operations was leading to incorrect results.

This change adds support for Hifive unleashed board. It also removes the
outdated hifive suport from the spike platform.

There is a different DTS file for 32bit spike platform.

The DTS compilation was arm platforms only. Moving it to the top level
config file, making it available to RISCV platforms. The generated files
are almost identical with minor differences. A new argument(--arch) is
added to the hardware_gen.py for the differences.

BeagleBone Blue is a BeagleBone variant aimed at robotics applications.
Device Tree generated from Linux 4.20.17

Overlay the incorrect memory size in the device tree, and enlarge the
kernel window appropriately.
BeagleBone Black has 512MiB memory.