This patch set goes across all the toolchains and brings
in the support for split SVD descriptions of SoCs.
This is helpful for dealing with designs that have multiple
"top" files for the same core IP set. For exmaple, you may have
a SoC that you are developing that targets silicon, but
you have a version that wraps this in additional peripherals
available only in an FPGA emulator that are used for debugging.
In this case, you can have one SVD file be the description of
the SoC itself, and another SVD file describe just the "delta"
introduced by the FPGA wrapper that emulates/controls the SoC.
In order to reduce friction of bringing on new platforms and experimenting
in utralib and svd2utra, xous-core now by default pulls these libraries
from the local repository.
Differences between the local version and the published version for
just these two packages are now downgraded to warnings, instead of
hard errors. This is because a difference does not indicate that
crates.io has had a modification we didn't expect; it simply means
we forgot to publish the package and we should eventually do so
once we have stabilized changes, so that others who rely upon it
can have the updated version.
But, with this patch, at least if we are experimenting with utralib
or svd2utra we don't have to publish a patch to bump revisions on
every major package every single time for a build to succeed.
I think this is an OK trade-off, but happy to roll this decision
back if it affects @eupn / @jeandudey negatively.
The new location makes a lot more *sense* (previously the
cache said 'git' when it was actually crates.io) but
it broke the verifier. This is now fixed.
This change is made with the intention of making the xous-rs crate a bit
more freestanding without depending on the xtask build system.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
- make the "base" field no longer public. It is accessible, but only
through an `unsafe` method, because, it is unsafe.
- add accessors to offest/mask fields. Because, it's not at all
unsafe to access these, and it can be useful for bit-ops that are
not part of the generic set of UTRA.
- add Arc to AtomicCSR, and require `std` for AtomicCSR types.
This should not break anything, I checked inside @foundation-devices
keyOS and they don't seem to be using AtomicCSR anywhere.
The Arc makes it a bit safer to clone the AtomicCSR base pointer
and share it between threads, but it will have an impact on performance.
The USB stack (which requires AtomicCSR) was regression testing and the
impact seems minimal.
Recall that the main purpose of AtomicCSR is to provide a CSR accessor
that does not require a mutable reference to the base object. This
can make certain Rust idioms a bit cleaner. We wrap the base accessor
in Arc+Atomic to try and improve the safety of throwing the borrow
checker under the bus, but it's still not perfect because hardware
mutable state can have side-effects within hardware itself that cannot
be modeled or checked by Rust's borrow checker.
Restrict crates.io published set to just APIs, not implementation
files. Nobody is using the implementations anyways -- it was requested
but I've never seen the package pulled except for CI.
in practice this has not been a useful indicator, and we
have stabilized the SVD format so that changes in the code don't
cause the SVD files to go incompatible anymore.
this should make maintenance a bit easier going forward, hopefully.
also merge in cramium support to harmonize the forks for easier
cross-patches in the future.
