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.

Device Tree generated from Linux 4.20.17

There are other am335x boards which require different platform
configurations, such as the BeagleBone Blue.

The tk1 SMMU implementation does not need to dynamically allocate
memory as the PDs are not managed by user-level. Convert to static.

Add a device tree overlay such that all memory on the exynos4 fits in
the kernel window. It's unknown if the memory past 0x50000000 is valid,
when the elf-loader attempts to write to it it hangs.

This is workaround for part of binary verification, which currently
cannot handle some modes of array access.

If we place the user image at the end of memory, the user image can be
beyond the kernel window. Handle this in arch_init_freemem by comparing
to paddr's not pptrs.

This change allows us to know, from just the kernel and dtb, where user
level untyped objects start being allocated from.

- allocate rootserver objects from last available freemem region.
- move create_rootserver_objects call into init_freemem.

The user image could be on either side of mode_reserved_region. Fix this
by assuming there is 1 or 0 mode_reserved_regions, and checking if the
user image is either side.

This fails early if the build process failed to calculate a suitable
MAX_NUM_FREEMEM_REG.

Previously, the boot allocator would do dynamic calculations to
minimise fragmentation, then throw away the smallest regions.
With the new boot allocator, we can reasonably predict that
fragmentation will create at most one extra region, so this commit
adds one freemem slot for ARM.

Prior to this change, the boot process would dynamically allocate
memory for root server objects based on the order of initialisation.
Allocation was a best-fit algorithm.

This change preallocates all memory for root server objects to an
aligned untyped just after the user image. By allocating the objects in
order of size, allocation is greatly simplified and the ability to
reproduce the allocation offline based on the kernel and user image
sizes is increased.

Prior to this change, seL4_MappingFailedLookupLevel() would retrun '22'
after any failed EPT mapping operation. This change fixes this to return
the correct amount of unresolved bits in the address.

Cache `platform_yaml` so we can reference it from `elfloader-tool` CMake
logic.

- read PMUSERENR_ENABLE first before updating. On the cortex-a8
(specifically omap3) not doing this would result in the kernel aborting.
- do not read DBGDSCR_ext on cortex-a8, read DBGDSCR_int. This is only
implemented in armv7.1, not armv7, and also causes the kernel to abort.

These tools sometimes style differently across different versions.

With the increased faults on various configurations (hyp, mcs) we need
more bits to identify faults.

While masking and unmasking IRQs seems to work for some IRQ sources,
there are IRQ sources where masking an IRQ during a claim causes no
more IRQs to be raised after the IRQ is unmasked. This change
explicitly follows the claim->acknowledgement procedure that the
PLIC expects.

We add support for seL4_IRQControlGet and seL4_IRQControlGetTrigger. If
a platform doesn't support setting the trigger, then
seL4_IRQControlGetTrigger will return an error. If the platform doesn't
have a PLIC driver, then it won't have any IRQs that can be requested.

Also authored by: Siwei Zhuang <siwei.zhuang@data61.csiro.au>

Previously we only handled IRQs generated by the BBL running in machine
mode via changes to supervisor interrupt pending (SIP) bits. Now that we
need to support shared global interrupts through the PLIC we need to
modify the way interrupts are processed.

We additionally remove many DONT_TRANSLATE annotations on functions that
the CParser is able to parse.

Also authored by: Siwei Zhuang <siwei.zhuang@data61.csiro.au>

We assume the PLIC is currently the only global interrupt controller
that RISC-V platforms are going to use. Each platform may have a
different programmers model for interracting with the hardware
controller. We provide a common interface for PLIC drivers to implement
that the kernel will use to manage IRQs.

Also authored by: Siwei Zhuang <siwei.zhuang@data61.csiro.au>

- Create device untypeds for platform devices that can be passed to user
space.
- Create kernel device mapping for devices required by the kernel.
Note that the current kernel device mapping is simply a 1GiB of page
physical memory as that contains all devices for all RISC-V platforms
that are currently supported.

For now we keep the RISC-V platforms under the spike kernel platform
name. Splitting the different platform definitions into different header
files will help maintainability as we add different device layouts and
kernel device drivers.

PPTR_USER_TOP represents the first inaccessible user address which is
usually ((2^(38-12))-1)*0x1000 on SV39. This corresponds to the first
address of the last page in the lower half of the top level page table.

Add a comment and diagram explaining the current structure of the SV39
kernel address space. The top half of the virtual address space is
reserved for the kernel and consists of the Kernel window of all
accessible physical memory, the kernel ELF mapping and the Kernel device
mapping region.

There is a 1GiB region reserved at the top of the Kernel virtual address
space to map devices used by the kernel into. The start of this range is
referred to by PPTR_KDEV. This also represents the end of the Kernel ELF
window mapping.

Verification requires the KERNEL_BASE to be 1GB aligned at the start of
the kernel elf window. It was also the location where the kernel elf was
mapped. As we have to include SBI memory in the kernel elf window,
the KERNEL_ELF_BASE is introduced for the real kernel elf mapping.
Keeping KERNEL_BASE unchanged.