Zip depends on time, which had some issues compiling on Rust v1.80: https://github.com/time-rs/time/issues/681
Update it to 2.1.6 in order to fix the issue.
Did not notice any apparent regression due to this update as of now.
at the moment an SVD pointer hangs out that messes builds up
when changing targets (sometimes) -- this is the pointer that
includes extra files in the build for targets that have disjoint
RTL sources. add a flag for cleaning this up.
We had a "coincidence" before that allowed things to work,
where we had some data line up that we happened to think
was some other header data, so we "fixed" it by
subtracting the offset of the header data.
Actually, it wasn't.
Clarify that decrypt_src_page_at() offsets are relative
to the beginning of encrypted data, and not relative
to the absolute beginning of the disk.
Image creation is now fixed so that stuff lines up to what
this routine expects, and some asserts added to try and
save ourselves in the future as we try to fix other bugs
we discover over time.
loaders are hard.
- swap works on hardware (at least reading in the encrypted
images works)
- renode version is deliberately configured to trigger an edge
case in the swapper, and is broken -- to be debugged
Haven't dug into it, but the AES instruction is not working
correctly in MPW cramium target silicon. There isn't a great way
to selectively disable hardware acceleration for sub-targets of
patched crates. So, as a work-around, we use xtask to patch
the default arguments of the AES crate, just for cramium-soc
targets, to use software emulated AES. This allows us to move
on with bring-up. To wit, there is another AES accelerator
on-chip that could be much faster than RV32 AES acceleration
(and with better DPA characteristics), and to use that option,
we might have to use a patch like this anyways, because Rust
doesn't have a good way to pass feature flags through patched
crates like this.
