I think we're OK to get away with this, but, it's a pretty big
set of assumptions we're making so let's write it up in a location
that we're likely to look at if/when things break.
these currently only make sense in a simulation environment,
but they allow us to work the significant configuration test
cases for practical execution to make sure we haven't missed
something in the coreuser spec.
- disable IRQs on departure
- put EV enable outside of the HAL function
this is necessary because we need all HAL calls to be finished
before an interrupt happens to avoid locking problems
- 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.
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.
