This commit rewrites the entire Microkit tool from Python to Rust.
This is was done for the following reasons:
* The current tool was difficult to build from source. It took too long,
did not have any cache for rebuilds, and sometimes would not reliably
build/link with musl.
* While perhaps not as extensive as C, Rust does have some verification
tooling surrounding it, meaning it is possible for us to verify the
Microkit tool in the future. Although at this time there are no
concrete plans to verify the tool.
This rewrite, while not significantly reducing our dependencies in
general, does improve the situation. We are no longer dependent on
pyoxidizer, which was causing most of the issues with the tool.
We introduce a dependency on the Rust toolchain. The tool itself has
two dependencies (for XML parsing). No other dependencies are needed,
and it was a conscious decision to re-invent the wheel where the Rust
standard library was lacking (compared to the Python standard library).
The other programming languages considered for the rewrite were Zig and
Go. While they both have their benefits and costs (as does Rust), they
were not chosen due to them not being in any other seL4 Foundation
supported projects meaning that it could have been difficult to continue
maintaining the tool in the future.
The main cost of rewriting the tool in Rust is that it has undoubtedly
become more complicated and harder to understand. This could potentially
result in a higher barrier to entry for contributors. However, most
contributions such as adding platform support will not need to touch the
tool.
Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
Add the `--tool-target-triple` option to specify which target
to build the tool for. Unfortunately Rust does not allow you to
cross-compile from Linux to macOS, however this will allow x64 macOS
hosts to cross-compile to ARM64 macOS. In theory the reverse would
work as well but I have not tried it.
Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
The Microkit tool can now be built for x64 macOS as well as ARM64
macOS, allowing the use of the Microkit SDK in macOS environments.
Note that unlike the Linux Microkit tool, the macOS one will be
dynamically linked due to macOS not supporting statically linked
binaries.
Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
The version of seL4 that Microkit used previously failed to build
for the i.MX8MM-EVK which is why this was disabled.
Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
Previously the linker script referred to crt0.o which is why it was
necessary that it was part of the SDK. However, now libmicrokit.a
contains crt0.o and so it is not necessary to continue distributing
crt0.o separately.
Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
The seL4 build system is configured to find installations of compilers
on the host, meaning that the `aarch64-none-elf-` toolchain that we use
might not be used when building seL4 depending on what other toolchains
are installed.
Signed-off-by: Ivan-Velickovic <i.velickovic@unsw.edu.au>
The seL4 Core Platform project is being renamed to seL4 Microkit.
It is to be referred to as seL4 Microkit in a non-seL4 context, and
Microkit everywhere else.
The standalone seL4 kernel ELF does not successfully build for the
i.MX8MM-EVK. This is fixed in a later version of seL4. In the interest
of having the SDK build, we temporarily disable building the SDK for
this platform.
Signed-off-by: Ivan-Velickovic <i.velickovic@unsw.edu.au>
This starts by factoring out the `putc` implementation and the
specific physical address at which the loader is linked.
Signed-off-by: Ben Leslie <benno@brkawy.com>
Previously the default 'python3' in the user's path would be
during the kernel build. Instead this explicitly instructs the
kernel cmake build system to use the python3 that is running
build_sdk.py. This ensure better reproducibility of the kernel
build process, and avoids relying on the user's environment.
To assist in this the requirements.txt is updated to include
deps required for the kernel build process (ply and Jinja2).
This ensures the kernel has the correct libraries during build.
Finally, the README.md is update to direct to the latest
commit on the seL4 core platform support branch. The kernel
has minor updates to avoid unnecessary deps on older Python
packages. Specifically, the kernel at one point in time supported
build with either Python2 or Python3. This is no longer supported
however the scripts previously contained some legacy code and
dependencies designed to support this.
Signed-off-by: Ben Leslie <benno@brkawy.com>
The README recommends creating the Python environment in 'pyenv', however
the build_sdk.py script hard codes './env/bin/' search path.
Use Python executable location to correctly determine search path.
Signed-off-by: Ben Leslie <benno@brkawy.com>
Gerwin Klein