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.
