this allows us to build a simulation-focused xous image
this was previously called cramium-fpga but that precise
configuration is less accurate as the simulation environment
makes more shortcuts (and can include more peripherals)
than the fpga environment.
we don't have pio block on nto; let's avoid maintaining two
versions of the code base for a non-essential feature (the
downside of not having this is that the system could end
up locking up if no processes call yield_slice(), but in
practice this happens often enough that we can get away with
it -- at least at this stage).
the `cramium-soc` target is now the simulation target (just
the bare bones chip in a simulation harness, using the `dabao`
board configuration which is basically just a breakout board).
baosec continues to be the prototype for the first USB dongle
coming out.
right now our patch set assumes a single HW configuration for
cryptography accelerators.
This isn't going to be true going forward. A more scalable approach
to patching accelerators is going to be needed.
For now, we're just falling back to software acceleration for
the cramium target.
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.
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.
