for some reason the loader has a lot of code devoted to formatting
debug prints of floating point numbers. In the version of the loader
that's being built for production I think we shouldn't need any
of this?
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.
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).
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 :(
