have to absorb a version change due to xous-semver change
might as well also update the utra/svd generator dependencies
since that's been held off for a long time now.
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.
the backup flag can be left "hanging around" if a restore of PDDB
is aborted. This command allows a user to override that setting
in case this is necessary.
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.
