The loader image uses the original signing method, because changing
that would require us to modify the gateware ROM, which is a huge
pain in the ass, and doesn't buy us anything.
Thus only the kernel signing uses the pre-hash method.
This requires us to modify our dependencies to have dalek-ed25519
as one of our dependencies.
Which requires another patch in this commit set to implement
sha512 for hosts, since we patch the sha2 crate for all targets
to our local version.
This creates:
1) An `xtask' command that allows someone to compile individual apps
without compiling the entire image (note that this is required because
xtask generates files that contain gam context names, and if you just
do a regular `cargo build' building the app will fail)
2) A python file app_server.py that acts as a server to give the
app-loader a list of the apps and actually send it the
3) A basic UX that allows app-loader to set the server, get the list
of apps, and load apps.
Currently, this mostly works, except that there is some random
`ShareViolation' when the app-loader loads the app.
This fix causes the script to exit if `--config` was selected.
You will need to run
`python3 -m pip install --upgrade precursorupdater`
to pull in the fix. It should be live now.
Thanks for reporting this bug.
This patch set goes across all the toolchains and brings
in the support for split SVD descriptions of SoCs.
This is helpful for dealing with designs that have multiple
"top" files for the same core IP set. For exmaple, you may have
a SoC that you are developing that targets silicon, but
you have a version that wraps this in additional peripherals
available only in an FPGA emulator that are used for debugging.
In this case, you can have one SVD file be the description of
the SoC itself, and another SVD file describe just the "delta"
introduced by the FPGA wrapper that emulates/controls the SoC.
- make the "base" field no longer public. It is accessible, but only
through an `unsafe` method, because, it is unsafe.
- add accessors to offest/mask fields. Because, it's not at all
unsafe to access these, and it can be useful for bit-ops that are
not part of the generic set of UTRA.
- add Arc to AtomicCSR, and require `std` for AtomicCSR types.
This should not break anything, I checked inside @foundation-devices
keyOS and they don't seem to be using AtomicCSR anywhere.
The Arc makes it a bit safer to clone the AtomicCSR base pointer
and share it between threads, but it will have an impact on performance.
The USB stack (which requires AtomicCSR) was regression testing and the
impact seems minimal.
Recall that the main purpose of AtomicCSR is to provide a CSR accessor
that does not require a mutable reference to the base object. This
can make certain Rust idioms a bit cleaner. We wrap the base accessor
in Arc+Atomic to try and improve the safety of throwing the borrow
checker under the bus, but it's still not perfect because hardware
mutable state can have side-effects within hardware itself that cannot
be modeled or checked by Rust's borrow checker.
this somehow causes the build to break, and I just checked and
I don't see warnings on our build. There must be some config
differences on hosts, but I'm not sure what it is...
quick-xml 0.19.0, a dependency of svd2utra, uses features
that Rust will deprecate.
Unfortunately, the only versions of quick-xml that do not
use the deprecated language features also break a portion
of the API. In particular, quick-xml will no longer take
a `File` as an input: it will only take a `Path`.
This means that the API for svd2utra is also broken, because
originally it was designed to take a `File`
This patch refactors svd2utra to work with the latest quick-xml,
but also breaks any code that calls svd2utra's generate
APIs.
Fortunately this is fairly easy to fix, the calling code
will typically already have the Path somewhere in it, so
instead of opening the Path and passing it into the function,
one may simply pass in the Path.
