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 code base had evolved through several code names, interim
names, company names and chip names that alternatively did or did
not exist.
Baochip is the definitive name of the company, and the Baochip1x
(full part number BAO1X2S4F-WA) is the definitivey part number of
the SoC. For convenience, the part number is shortened to 'bao1x'
in most feature flags and variable references.
This commit fixes all of the odd names and removes some unmaintained
early targets.