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).
- updates enables or disables updates in the loader
- verilator-only will turn off routines that access hardware not
present in verilator (e.g. leads to a bus lockup)
- simulation-only turns of features that take a long amount of time
and aren't necessary in simulation, such as bulk clearing of
all RAM - in simulation, we can configure the simulator to do this
for us prior to boot; but in HW, of course, RAM is just random,
or worse, has the previous session's secrets in it.
cramium-soc is moving closer to the platonic SoC specifier,
and the board-* features are for the specific boards that use
cramium-soc
This division of feature flags feels a lot nicer and cleaner -
if it holds up to further development, I think this style might
become the new standard for Xous (as opposed to a single level
of feature flag where both SoC and board target are conflated in
terms of meaning - which kind of made sense when the CPU was
an FPGA and could actually have different features for different
boards, but for ASICs this wouldn't happen).
verilator doesn't implement the TRNG, so the TRNG is bodged.
A warning is left in to help remind us/alert us if the bodge
is accidentally put into production.
the 'dabao' board type is introduced, which is the breakout board
codename.
camera and display are feature-gated behind their respective board
definitions.
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.
I felt uncomfortable leaving the oscillator setting entirely
outside the PLL routine, so as a compromise I defer the oscillator
switch-over until after the initial PLL settings are loaded.
This makes both the simulation model and the actual hardware
happy. I think probably what the simulation model *should* have
done is consider the "powerdown" pin when checking the validity
of the signals going into the PLL model - but this is impossible
to modify/check because the PLL is provided as an encrypted blob :(
this transition was in the reference C code, but in verilog simulation
it turns out it activates the PLL in an invalid mode which can lead
to glitching. Removing this makes both the simulation happy and
presumably the PLL happier as well.
this doesn't protect against malicious tampering (because
the public key is the developer key) but it will at least
catch correctness errors in USB upload and filesystem
behavior.
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.
the curve 25519 accelerator hw is different on different targets
so it can't be enabled for all of them all at once.
This is going to be come a bigger problem as time goes on...
