This was introducing a mysterious "line" artifact on text rendering
in new systems.
Probably need to do some real on-device testing of this change
because the automated tests won't catch a dirty bit error on
the LCD.
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
cramium-soc i think should be deprecated everywhere because
it is redundant with the board targets: anywhere you see a board
target that includes the crossbar soc it should also transitively
pull in the cramium-soc dependency equivalents.
we'll chase this out more later, but for now we're just trying
to get the PDDB to compile
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).
add a note about the dirty flag - it's not "dead" per se, I
think it is helpful to leave a bread crumb for future hw revs
that might have hardware-enforced dirty bit setting on the PTE.
This is a bad idea because yield_slice() causes the active
process to hand off to a new one (without an IRQ). However,
the idea of most flash operations is we really want them
atomic - we can't have something else decide to go and muck
with flash while say, we are waiting for a page erase to
complete. So, implement spin locking to block the CPU
during phases where the hardware operation is non-interruptable.
this is a much simpler, race condition-free version of flash
writing which has the penalty of requiring a copy of the page
to be made by the caller before the write. However the
copy is mostly already paid for because on the initial access
to the page, we had to copy the flash into RAM.
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.
