This adds some UX feedback in the edge case that a suspend could not
happen due to a blocking sever, e.g. a sha512 hash pending or
a SPINOR flash write/erase pending.
The UI will tell the user to retry again; usually the ops in
a normally functioning system for hashes or SPI are very short,
so we could almost just retry automatically but I think for now
I want to see if this edge case actually happens.
I was this many years old when I learned that:
- If you put a `let` inside a block and then pass it outside
the block, it definitely gets a different address. This was causing
KP's in the interrupt handler routine because I was using a block
to mark off the configuration feature and then passing the handle
to the data structure outside the block; instead of just aliasing
the handle over as I assumed it actually makes a copy in a new
address location. This made debugging really hard until I figured
that out, the solution was to put #cfg directives on every line
related to the feature instead of grouping them together into a
block and using a single #cfg directive.
- event_wait() takes longer than 2us to execute. However, the
sha512 computation is done in 2us. So, by the time we checked
if we should wait and called event_wait(), the interrupt that
would wake us up from event_wait would have already happened.
This race condition is what broke event_wait() in the first place.
We now just use a spin loop without even a yield(); as the yield
would take longer to execute than waiting for the hash function
to finalize.
fully integrates wifi on and off commands. measured standby power
when wifi is off is "immeasurable" (0 mA), so probably < 1-2mA.
fix ui transitions so that the off request is respected, through
sleep/resume cycles as well.
somehow, on windows builds, this doesn't break; but when building
under linux, the kernel config difference matters. Now that I
know how to pass features down, let's do it right.
- boot PIN is not requested on root password init. it's redundant,
as it is actually set when you format the PDDB
- boot key was mistakenly a copy of the encrypted private key
for ed25519 key signing. "oops". didn't catch that bug until now...
i don't think it has a big impact on existing user base, because
the key is never exposed outside the rootkey server, and the
ed25519 key itself is encrypted with the root password and then
used as the boot key. But still -- that's just not what was intended.
- root password is requested twice to check the validity of the password
