... from the device UT listed by platform_gen. The kernel itself
does not care about this memory, and it is just given as device UT.
We also just remove the reserved array entirely from the return of
`get_physical_memory` since it only seems to be a footgun, it's
only used internally to affect what memory the kernel wants to use.
Co-authored-by: Kent McLeod <kent@kry10.com>
Signed-off-by: julia <git.ts@trainwit.ch>
`align_memory()` in hardware.py both modifies the first normal memory
region to adjust the base of it for alignment, and adds an extra
reserved region to our list of reserved regions. This then feeds
through `get_addrspace_exclude` which inverts the regions given
and turns it into the available "device memory" at user-level.
dev_mem = hardware.utils.memory.get_addrspace_exclude(
list(reserved) + phys_mem + kernel_devs, config)
Anything as an argument to this is not given as "device memory" by
the kernel. (It does not precisely match how the kernel works).
However, since `align_memory()` has adjusted both the phys_mem up
(which *would* have added this region as "device" memory) but also
added it to "reserved" region, which then made it disappear entirely,
as "reserved" regions are not exposed to userspace.
However, this **does not** match the behaviour of the kernel, as it was
not reserved, so this behaviour did not match the untypeds given to
userspace. This commit solves this by removing the extra reserved
region being added for that memory.
PR #1426 worked around this issue by removing the alignment on AArch64.
Whilst this fixed the issue that microkit was seeing, it just masked
the underlying issue. Reverting that PR, then applying this fix,
results in the following platform_gen.yaml:
devices:
- end: 0x1000000
start: 0x0
- end: 0xff800000
start: 0x3b400000
- end: 0xff841000
start: 0xff801000
- end: 0x100000000000
start: 0xff843000
memory:
- end: 0x3b400000
start: 0x1000000
Note especially the device region from 0x0 to 0x1000000; which is the
combination of the 0x0 to 0x1000 reserved region, and the 0x1000 to
0x1000000 reserved by the kernel's alignment requirement. Previously,
the platform_gen.yaml reported only the 0x0 to 0x1000 region,
devices:
- end: 0x1000
start: 0x0
- end: 0xff800000
start: 0x3b400000
- end: 0xff841000
start: 0xff801000
- end: 0x100000000000
start: 0xff843000
memory:
- end: 0x3b400000
start: 0x1000000
I will be following this commit up with a PR to instead make the
alignment-reserved region into a new memory region, since there's not
any reason why userspace can't use this memory.
This has been tested on a few platforms with sel4test and with
microkit on the pi4B.
Signed-off-by: julia <git.ts@trainwit.ch>
Instead of special handling for the SBI region in the kernel, which can
be platform specific, treat it as a reserved memory region in the device
tree which is sufficient to prevent the kernel from turning the reserved
region into kernel untyped caps.
Signed-off-by: Kent McLeod <kent@kry10.com>
Right now the `platform_gen.json` and `platform_gen.yaml` files contain
regions that are not actually used by the kernel. This is fine for
`platform_gen.h` because they are guarded by #ifdefs with kernel config
defines but the same approach does not work for YAML and JSON.
So, this patch changes the Python scripts that generate this files so
that they only generate the regions that actually end up being used.
Signed-off-by: Ivan-Velickovic <i.velickovic@unsw.edu.au>
The ELF loader may well be satisfied with a smaller alignment, but the
compile time assert in the kernel requires super section alignment for
physBase.
Signed-off-by: Gerwin Klein <gerwin.klein@proofcraft.systems>
For verification flexible w.r.t kernel placement in physical memory, we
need to relate physBase as a named constant to its abstract equivalent.
Unfortunately, apart from enums, the C programming language does not
have real constants. The C parser follows the C standard and requires
enums constants to be storable as int, meaning without major overhaul
enums are not sufficient for storing word_t-sized memory addresses.
Since the linker scripts can't deal with static inline functions
in the constants they need (KERNEL_ELF_BASE and KERNEL_ELF_PADDR_BASE),
we provide the following preprocessor definitions for the linker
specifically:
* PHYS_BASE_RAW (the numerical value returned by physBase())
* KERNEL_ELF_BASE_RAW
* KERNEL_ELF_PADDR_BASE_RAW
Signed-off-by: Rafal Kolanski <rafal.kolanski@proofcraft.systems>
At the end of the physical address range, the last address isn't turned
into an UT object. The scripts generating the memory regions
unnecessarily round down to a small page size when they could instead
round down to the smallest UT size and this memory could be used for
smaller kernel objects.
Signed-off-by: Kent McLeod <kent@kry10.com>
- Provide a nicer string for debugging purposes.
- improve comments about the purpose of __repr__() and __str__()
Signed-off-by: Axel Heider <axelheider@gmx.de>
- A region can't be created from an invalid range
- A region might be too small to support the change. There is no trivial
way to fix this.
Signed-off-by: Axel Heider <axelheider@gmx.de>
The structure actually describes kernel frames and not kernel devices.
In most of the cases a peripherals will fit into one page, but some can
need more pages. On some platform there are no kernel devices at all.
Provides the macro NUM_KERNEL_DEVICE_FRAMES as simple way to find out if
there are mapping that hides the corner cases. This eventually allows
implementing a generic handling even on RISC-V without much overhead, so
the hack for HiFive/Spike can be removed.
Signed-off-by: Axel Heider <axelheider@gmx.de>
Using explicit field name in the assignment states more clearly what the
generated code does. It is also more robust and allows the compiler to
catch potential inconsistencies in case the structure details change.
Signed-off-by: Axel Heider <axelheider@gmx.de>
Avoid the warning 'WARNING:root:Not sure how to parse interrupts for
"/cpus/cpu@0/interrupt-controller"' when building for platform hifive.
Signed-off-by: Axel Heider <axel.heider@hensoldt-cyber.de>
CMake treats any text output that is generated by tools during the
configuration phase as important if it isn't part of a message(STATUS)
command. Output generated by hardware_gen.py often shows up as warnings
about device tree properties that are usually uninformative. Resolving
some of the warning conditions removes these messages for most
platforms.
- Setting kernel_size in hardware.yml to 0x1000 to handle cases where
the kernel only needs the first page of a device that has a
device-tree definition larger than that.
- Remove status print about each Interrupt processed as it's usually not
useful information.
- Only process IRQs for a selected kernel device if the rule for that
device has any interrupt queries. This prevents warnings for IRQ
controllers that the script doesn't know how to process when it
doesn't need to.
Signed-off-by: Kent McLeod <kent@kry10.com>
For 64-bit, this adds a 2nd-level page table for mapping devices using
2MiB frames instead of 1GiB frames.
The boot mapping and hardware header generator have also been fixed to
correctly report the number of large frames needed for devices rather
than only reporting the first. The frame size is also specified
correctly (rather than assuming mapping with 4KiB frames).
This likely fixes an issue whereby only the first 4KiB frame of a device
was reserved but the remaining region of that kernel device could be
mapped at user level.
Signed-off-by: Curtis Millar <curtis.millar@data61.csiro.au>
"const TYPE *ptr" creates a non-const pointer to const data; for the
pointer itself to be rodata requires "TYPE *const ptr".
Taking the size of the pointer is caught by -Werror by default; suppress
that.
Signed-off-by: Stefan O'Rear <sorear@fastmail.com>
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.
The elfloader is going to start using devices based on the device tree.
Add an output method for hardware_gen.py that generates header files
that the elfloader can use. Currently they contain an array of
"devices", where each device has a compatiblity string and a series of
regions (represented simply as the physical address of the region).
For now, the elfloader only uses the serial device specified by the
stdout-path property in the DTB.
Currently on x86 device untypeds are generated by passing the entire
address space minus any parts that are reserved by the kernel or that
are "real" memory (e.g. kernel image, physical RAM).
On ARM and RISC-V, device untypeds were generated at compile-time from
a device tree. This patch moves ARM and RISC-V to use the same approach
as x86, and moves the code from x86 into a common location that's
shared between the three architectures.
Co-Authored-By: Anna Lyons <anna@gh.st>
This is almost a complete rewrite from the old hardware_gen.py.
It separates the 'parse DT' stage from the 'generate output'
devices more strictly, and is hopefully easier to understand and
easier to extend.
We also no longer generate the 'devices' list (in YAML)
or the dev_p_regs array (in C), as the kernel will implicitly
expose all non-RAM untypeds as devices.
