the data section is generally pretty small, a few k, and there
are cases where we need more initialization entries. This keeps
the structure from growing beyond 256 bytes.
The code base had evolved through several code names, interim
names, company names and chip names that alternatively did or did
not exist.
Baochip is the definitive name of the company, and the Baochip1x
(full part number BAO1X2S4F-WA) is the definitivey part number of
the SoC. For convenience, the part number is shortened to 'bao1x'
in most feature flags and variable references.
This commit fixes all of the odd names and removes some unmaintained
early targets.
1. nonce should be generated from the LSB of the commit hash.
security doesn't come from the nonce, and having the commit hash
in the nonce is helpful for version control of the swap image
(although it doesn't capture "dirty" builds, e.g. builds
made with uncommitted changes).
2. fix IniS regions to not require special alignment. Since the
data is copied (similar to IniE), we don't have to waste space
page-aligning things so that offsets map perfectly between
the image on disk and in RAM.
3. add checks that the loading position of data inside the
swap image matches our expectations. We should have 0x1000
bytes of unencrypted header, then 0x1000 bytes of XArgs + padding,
and then image data should start.
There is a "just so" coincidence in that the image data by
the MiniElf program always lines up at an address > 0x1000, making
space for the XArgs. I actually don't know why this padding is
there, but the "section" doesn't decode to anything we
can parse. Maybe it's some reserved space for OS-specific
loader shenanigans?
Not sure how this even worked in the first place....I think we
always just got lucky with the size of .gcc_except_table. However,
something changed in the last rustc update that causes this section
to align to a 256-byte boundary instead of a 4-byte boundary, which
exposes downstream alignment issues.
This patch now captures the actual offset alignment + padding,
which is somewhat complicated by the fact that we throw away
the first section (not sure why??? it doesn't seem to have
a valid name or header, but the first 0x114 bytes are non-existent)
so we have to factor this into all the downstream padding efforts.
Make the first word in the signature block a jump past the block
this is for the cramium target, where the best memory efficiency
happens if we align the data to the bottom of the memory. This
means that the signature block ends up "in the way" of the boot
process, because the reset vector can only be configured to something
on a 16k-page boundary (e.g., we'd waste 15k of memory without this).
This will require some reworking of the existing code base for
checking signatures down the line.
Each platform interprets this differently.
On Precursor, it's the offset in FLASH of the swap region.
Probably, flags should be added to configure this somehow for each
platform, but still figuring a lot of things out.
The plan is on Cramium for the swap data to always be at 0
in the external SPI, so, we don't store an offset (field is
ignored).
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).
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 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.
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.
