for now, publish a xous-riscv package, until we can absorb
this into the kernel directly.
Want to recode all the assembly files into inline-assembly now
that it is supported in Rust, but, let's not put that yak on
the list of yaks to shave before we have a separable kernel.
- strip out gdb-stub. Per xobs, the feature never worked, and it
depends upon a branch of a git repo which is not allowed by crates.io
Since the feature hasn't been developed, and crates.io will not
allow even an optional feature that points to a git repo, the feature
was stripped out.
- rename "kernel" to "xous-kernel", so that we can live in a crates.io
package namespace that is specific to Xous.
still have to figure out the riscv package issue.
this is necessary because we need the full SVD path to generate
the whitelist of physical pages that can be addressed. Since the
SVD path is now domiciled in utralib, a file called "SVD_PATH"
is created in the target/ directory which contains the resolved
path to the SVD file given the abstract target/rev feature pair.
this fix makes it so that
1) you always get a correct build when the SVD spec is toggled
2) you don't always rebuild when nothing has changed
(2) is with the caveat that the no-change flag is only clean
after your second build (i.e. your third run will be fast).
I'm not quite sure why but I think it's because the "changes"
to the config file tracker are computed throughout the first
build and the second build still sees that file as recently
changed, so, it'll trigger a rebuild (could also just be
a race condition because the timestamp of the rebuild is
at the same second that the file was regenerated, so conservatively
you'd rebuild the next time).
- default SVD file is specified now as a constant at the top of xtask
- SVD files are now tracked to commit refs in the betrused-soc tree
this is so that we don't have to guess which crate rev corresponds
to which SVD rev -- we specify it explicitly with a feature flag.
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.
