still have some...mysterious...problems around feature
flags that aren't being invoked when i think they should be.
but let's commit this checkpoint because I suspect I may need to
roll back to here several times and I try to figure out the
root cause of the issues.
remove features that we don't need so as to make the tree as
simple as possible to descend
in particular if we're just pinging the HAL layer for some simple
constants we don't have to pull in the hairball of std targets
1 - lock the CPU
2 - go into userspace to do the write
3 - on exit from userspace, mark the page as swapped in the original
process so that if it tries to read the data it fetches a new clean
copy
4 - free the page from the RPT so the data can be grabbed later
5 - unlock the CPU
writepage uses a *direct* memory message (no rkyv) for efficiency
this saves us an extra page spent on the sideband data shuffling
by loading those args directly into the cpu registers that
get shuttled along with a memory message (the now increasingly
misnamed "advisory" fields of length/valid).
unfortunately this doesn't get us all the way there. There
is always a chance that the call that marks a page as dirty
is not coupled closely enough to the actual update of the page
data. Without actual hardware support for this we can't use this
approach.
the explicity "spinor" interface is no longer needed (or even
compatible!) because we now have the swap-mapped spinor layer
the main concern I have at this point is there is a potential race
condition between marking a page as dirty and when the data is actually
updated on the page. Some locking might be necessary to fix this,
but possibly it might be sufficient just to mark a page as dirty
immediately before it's written?
another option might be to handle the writes in an interrupt context
so that the write data + dirty mark are atomic. Need to think about
this a bit.
These routines provide for two types of behaviors:
1. deallocating dirty pages. Here, pages are unmapped from RAM
after they are committed to FLASH.
2. write dirty pages to flash. Here, pages are kept mapped in RAM
for future use, but the dirty bit is cleared. This allows the
pages to be quickly released in case of memory pressure.
more of a work-around than anything else. the observation is
the PDDB_A* series of constants aren't used outide of the crate
for gen2-targets and so we just remove it as a dependency in
the lib.rs side of things.
This clears up the cargo error we're getting. still don't know
why the dependency tree is not working for that particular target,
but someone is pulling a pddb dependency and it's not obvious who.
still broken, there is a weird dependency problem on
board-baosec target that is still to be debugged, but
wanted to get everything committed so i can try bigger
experiments without losing state
this constant was just used to create a "realistic" test case
instead of trying to add the dependency we just hard-code the
constant into the test case, because in the end what we wanted
was that specific constant to test a specific edge case of
a progress bar.
