This loop was useful in bringing up the GC2145 camera, so
we should keep this code around. had to be refactored/shuffled
around a bit to compensate for e.g. bitrot.
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).
