There's a hardware bug that makes concurrent camera and SPIM
traffic unreliable. The work-around is to place the camera
code inside the XIP area so we don't have to hit SPIM to swap
in code while the camera is running.
However, we do need to figure out a more reliable fix for this.
this is a slimmed down target designed for a smaller memory
footprint. there is some loss of process isolation security but
also a boost in performance due to more items sharing a memory
space.
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
