This is set to 0 in the image creator, but the keying ceremony
should set this to something more secure after the device has
been initialized (and likewise, re-encrypt the swap region
to match the new, secure key).
looks like about 9 crates will be affected by this. Point them
all to the latest version of the API, and specify the
"precursor" feature (which activates our patch)
A missing translation will cause a panic in the localization
macro. As a short term solution. The stub function in the
i18n_helper.py just fills anything missing with its English
placeholder. Note: After refactoring the python packing, I intend
to add an "auto machine translate" funciton as well.
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.
