I think I may have to be patient on waiting for docus on how to
tune the trng, so, turning off these warnings for now. trng tuning
will be "an event", I expect.
Make the first word in the signature block a jump past the block
this is for the cramium target, where the best memory efficiency
happens if we align the data to the bottom of the memory. This
means that the signature block ends up "in the way" of the boot
process, because the reset vector can only be configured to something
on a 16k-page boundary (e.g., we'd waste 15k of memory without this).
This will require some reworking of the existing code base for
checking signatures down the line.
kernel load last isn't necessary
add some asserts to help sanity check things. In particular,
the kernel mapped memory can't exceed 0xA000 in length, otherwise
it bumps into hard-coded constants in the kernel for where hardware
mapped pages should go (i.e., panic framebuffer, debug UART, etc.)
Page mapping just can't be done during the phase 1 loading, because
we move the loading point by an unpredictable amount which messes
up phase 2. I mean, we could try to predict the amount, but it's easier
if we just stick with the current algorithm instead of trying to
do both at once. Basically, phase 1 must be "no-alloc" entirely
as it copies.
Phase 2 can allocate page table entries, because all the data
is copied to RAM and you know where that starts; and you can start
to append data to the end of that without affecting the loading
points of programs.
Undo a previous patch to force kernel to load last. Turns out
this is legal, it was only problematic because of other bugs.
Also, reflect swap_root in the BootConfig structure and not
in InitialProcess structure.
+ Various other debug fixes
this is more robust, and should work across all architectures.
Note that the reliability of the check is slightly impacted
since we're now checking for a subset of valid numbers, so
the number of bytes checked is doubled.
In swap configuration, the loader does a lot more: it has
to decrypt full pages of RAM and hold them temporarily;
up to two pages at once, once for the decrypt of the source
swap image, and one for the encrypt to swap memory.
This causes a lot more stack to be used than the original loader.
Add some debugging for this, and an assert based on a heuristic
that the RPT (runtime page tracker) last few entries ought to
be 0. This I think is probably true on most platforms. If this
fails to be true, then, we can probably modify the assert to
fail if any number in the RPT is greater than the number of
processes: this should be true in *all* cases, but a stack smash
is very likely to write something in there that's larger than
the number of allowable processes in the system.
load checking is aware of all three types of sections, and
can natively call the encrypt/decrypt ops to ensure that
the encrypted swap is set up correctly.
