- 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.
In general, hosted mode is assumed "by default" if the target
is not Xous. This allows packages to be built cleanly on command
lines that don't know to pass a --feature flag to specify a target.
However, an explicit "hosted" flag is still retained so that we
can confirm the build system intent. This saves us from the failure
mode that we thought we were building for target A, but accidentally
ommitted the flag, and instead we've been silently building for
"hosted" mode without any warning. The main consumer of the "hosted"
flag is now just the build.rs script inside of the utralib.
This will allow for e.g. xous on riscv32-imac but not a precursor
target, for example: by using feature selectors we get to have
a bigger range of targets that we support, such as for implementations
that haven't been upstreamed or have official target-triples.
The downsides are:
- patch override libraries don't absorb feature flags. so, for
example, the AES crate that is used to patch other crates won't
be aware of the target features without modifying the referencing
crates.
- features are normally meant to be additive, but target features
are mutually exclusive. The mutex is enforced by a check in
utralib that throws a panic on build if two targets are accidentally
selected at the same time.
This macro will be removed, since it is no longer necessary. Remove this
macro across the project and replace it with a standard `main()`
function.
Signed-off-by: Sean Cross <sean@xobs.io>
a small bug was found in the device core that is now fixed. the
device core was not computing the target for the SETUP transaction
correctly if the HEAD of the OUT descriptor was set in advance of
the SETUP transaction. we now see much more consistent SETUP
transactions, and even the first IN response.
the next challenge is figuring out why the second IN response doesn't
seem to be issued.
we're now two packets into the setup.
i think i see one fundamental mismatch between how the driver
behaves and how the hardware runs. it has to do with where the
ep0 data gets deposited for a SETUP or OUT transaction --
the HEAD of the list can't be allocated the transaction is
completely ready to go.
will bang on this more tomorrow, but this is progress at least.
interrupts seem to behave much more like i think they should.
i think the interrupt unit on the spinalHDL block is not made to
have the whole set enabled/disabled frequently, it just wants
to have the bits banged to clear the interrupts. enabling and
disabling interrupts as a whole causes some erratic operations.
NB: the reference linux driver only enables them once and never
turns them off.
also, realized just now that OUT is from the direction of the host.
so OUT on the device is incoming data. oops.
things are moving in the right direction, i'm seeing the next
IN packet being issued by the USB driver on the precursor
side, but it's not being sent by the hardware. yet.
