A BinaryFile was previously identified only by its path,
thus if a bianry file represented an app rather than a service,
there was no information that could go in the manifest for the gam.
This let's one optionally specify a name for a BinaryFile.
passing this flag causes the loader to print debug output.
This slows down the loading process but gives you some visibility
into what's going on (maybe also an idea for the future to add
VDBG flags for verbosity, they exist in the code but not exposed
as command line options).
This creates:
1) An `xtask' command that allows someone to compile individual apps
without compiling the entire image (note that this is required because
xtask generates files that contain gam context names, and if you just
do a regular `cargo build' building the app will fail)
2) A python file app_server.py that acts as a server to give the
app-loader a list of the apps and actually send it the
3) A basic UX that allows app-loader to set the server, get the list
of apps, and load apps.
Currently, this mostly works, except that there is some random
`ShareViolation' when the app-loader loads the app.
When the user selects App Loader from the app menu, a new menu shows
up that displays the currently loaded apps (in the future this will
contain options to add/remove apps as well). This is a much more sane
approach than whatever I was doing before because it requires minimal
changes to the rest of the source tree (I had to change xtask so that
it would replace -'s with _'s in constant names so that I could name
my app app-loader).
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.
