lots of terrible stuff going on, nothing tested, but we have
a baseline of whatever they put in C directly forced into Rust.
A lot of really naughty things going on with raw pointers in this
driver -- it's going to be a challenge to oxidize.
The loader bringup now has some IRQ testing built into it.
Couldn't actually get an IRQ to trigger, but it has to do something
more with me not getting the RV IRQ machine bits configured right
than anything else. However, the stub is useful for confirming
which IRQ bits actually fire on the UDMA UART implementation,
which is the big point. There's an ambiguity in the wiring
of the UDMA block which isn't explained at all, which is the
fact that there's an RX interrupt and an RX_CHAR interrupt.
I still don't know what RX_CHAR does, but the RX interrupt
does fire when a character is received, so that's the one
we're going to use.
not quite sure why it is even there, might just be a thing from
really old code we never removed. Removing this allows us to
specify pointer types to non-copy elements, making Rust do
the hard work of figuring out how big of a block we need to zero.
some errors were made in clearing memory because we weren't
using the Rust type system to our advantage. This cleans up
the phase 1 loader to use the native types of the block plus
the slice length we intend to create to block-zero the correct
region size.
also simplify mem::size_of to size_of
because the print! macro becomes a dummy when debug printing is
off, we get a bunch of warnings about unused variables because
the print! arguments aren't used. Add _ before variable names
to quiet these warnings.
trying to condense most of the RPT API into the loader so
that the userspace can use a single dependency for this.
We can't condense the kernel API into the loader unfortunately,
because the kernel actually uses a different type for representing
a process. This is probably a mistake, and is something that
may be fixed later so we can merge the representations.
We had a "coincidence" before that allowed things to work,
where we had some data line up that we happened to think
was some other header data, so we "fixed" it by
subtracting the offset of the header data.
Actually, it wasn't.
Clarify that decrypt_src_page_at() offsets are relative
to the beginning of encrypted data, and not relative
to the absolute beginning of the disk.
Image creation is now fixed so that stuff lines up to what
this routine expects, and some asserts added to try and
save ourselves in the future as we try to fix other bugs
we discover over time.
loaders are hard.
