primarily modify the loading method to mark pages with A/D flags
as needed to work around lack of A/D handling in the trap handler
of Xous.
Also inside main.rs is a todo list for polishing off the vex-ii
port and turning into something actually sustainable for Denarius
once we have more of a full SoC model available.
the switch based on target is now absorbed into the new() function.
This paves the way for us to add more CSR ranges into the global
configuration object, i.e. IRQ csrs for I2C.
add a note about the dirty flag - it's not "dead" per se, I
think it is helpful to leave a bread crumb for future hw revs
that might have hardware-enforced dirty bit setting on the PTE.
KB_C2 pin on this test board just got shorted to ground internally
in the chip. I think it may have been due to power glitches
when the ammeter was switching modes feeding through and causing
trouble for the system.
Anyawys, disable that row and remap some keys so we can continue
with testing. MPW boards will hopefully be retired soon enough...
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.
