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 is a fairly major re-org of where key constants go that
define platform features. things that were in xous-rs that were
platform specific (namely precursor) were moved into a boards file,
and things that are generic to the system (like PAGE_SIZE) are moved
to a public location in xous-rs::arch.