make it long enough that it's unlikely to have two identical
ones randomly connected to the same machine
but short enough that it's likely/conceivable to have a collision
this cleans up the feature dependency tree a bit and also adds
some ability to print an error when the double lock condition
is discovered. it should be solved but it can only be detected
at runtime. Insntead of it being a silent failure (because
the server hung in an interrupt context and couldn't emit any characters),
it sets an atomic bool that can be checked and reported upon by
the main thread.
also cleans up debug uart acquisition.
there is a lock that happens in serial console interactions with
local echo where the instant feedback of a character entered causes
the USB object to be locked when the interrupt handler enters to
receive a character that was just sent.
The fix to this is to add the ability to disable interrupts before
entering a critical section (such as enqueuing data for a write)
and then re-enabling after tha section is done.
After some contemplation, we should include the keystore in the
core service set featured by the dabao-xous configuration.
The pros are: any compatibility/sharing of resources
that require access to RRAM, one-way counters, UUIDs, etc.
will either require a wholly separate implementation that is
"insecure" or it could just reuse the baosec work. Furthermore,
as cryptographic accelerators are laid into the keystore,
the APIs become available to the dabao environment
The cons are: more space is used in a space-constrained
dabao environment (roughly 140k "deadweight" at the start, but
as cryptographic APIs get layered in this can grow substantially);
the key slots are "used up" in part by the scheme, which leaves
less key slots available for user-defined purposes.
This is mitigated by the fact that there are a couple thousand
key slots, and so even though we use a couple hundred of them
it's still not the whole range.
Also, the baosec/dabao feature flag can be used to feature-out
cryptographic APIs/accelerators that are too obscure or not
useful for the dabao environment, to "lighten up" the
firmware load.
The "press button" path cleanly shuts down the USB stack
before going into the next stage.
"boot" does not; it missed the additional code added at the
end of the main routine.
Refactor the "boot" routine to be a function call now, so any
future improvements to the boot process are used by both paths.
this ensures that a given app is not included more than once
significantly, this allows for an app to be in the default list
and also selectable from the menu and you don't end up with
two copies of it in the binary.
