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>
Instead of having a single, shared buffer, simply stack-allocate the log
buffers.
This paves the way in the future to allow for buffers that are
larger-sized and span multiple pages. But most importantly it alleviates
inter-thread locking and contention when passing messages.
Signed-off-by: Sean Cross <sean@xobs.io>
Previously, we would reject buffers that were the maximum allowed size.
This is reported in #141.
Allow these maximally-sized buffers to be printed, since they don't end
up causing a problem.
Signed-off-by: Sean Cross <sean@xobs.io>
just couldn't let it go. figured out the issue is a race condition
in how the Litex UARTs are constructed...I don't know how Litex
normally handles this kind of situation but they have this funky
construction where reading the fifo doesn't advance it, you have
to...clear the pending bit. I think it was meant to be a "clever"
thing that saves an instruction or something like that since you
always have to clear the pending bit.
Anyways, the previous incarnation of this loop checked to see
if the pending bit was set again and if it was it'd run back
and fetch another character. This turns out to be a bad idea
because the pending bit goes through a multireg and other stuff
before it's readable which means it has a lot of delay on it.
This leads to a race condition.
This version actually checks if the fifo is empty and if it isn't,
it reads the character *and* pumps the pending bit (because
the FIFO doesn't auto-advance when you read it, you have to clear
the pending bit).
This works a lot better, but it's not at all well documented how
this works and it's very hard to tell from reading the source code
because it's written using really fancy migen abstractions that
are also poorly documented and have a lot of cursed constructions.
Anyways. At least the console doesn't die now when you type
a control character, *but* you do have the problem that the
escape codes get mis-interpreted sometimes. If it really really
becomes important later on to fix that it would involve tracing
out the sequence of keys that arrive at InjectKey and figuring
out if things are coming out of order or what is triggering the
bad escape codes.
there is still some mysterious problem involving a race condition
of the raw hardware console UART Rx path deciding it doesn't want
to report new characters anymore to the interrupt handler that
is triggered when multi-byte sequences are shoved down the
pipe. So long as you're typing simple commands it's fine, but
escape sequences tend to lock things up. I don't think there's
enough ROI to continue investigating this facility.
Each Cargo.toml now includes a comment which remnids maintainers
of the dependency policy for Xous (that is, nail down every dependency
to the minor number).
Versions are pinned down to the minor number. Yes, this means that
we don't automatically pull in features and bug updates from crates.io,
but it also means we don't pull in new attack surfaces and code that
hasn't been tested or reviewed. I'd like this process to be very deliberate
and not automatic for Xous.
The `rand` crate is almost pinned down to a single version, except
for an odd dependency that's pulled in by hosted mode that depends
on rand 0.8.4 via a subordinate dependency via the `tempfile` crate.
Pondering if it's worth it to try and eliminate that, because the
0.8.4 version doesn't get compiled into any version that touches
real hardware. It just makes it harder to analyze the Cargo.lock
file, mostly. I think I'll leave it as-is.
this at least removes a panic that crashes processes. it does
mean that some log messages can get silently lost, but this is
better than crashing if the arguments to the logger can't be
parsed for some reason?
This removes all custom string formatting from the `log-server`.
This should improve performance, because we're not roundtripping between
various archive formats. We instead do a single copy and operate
directly on that buffer. We also now write bytes directly, as opposed to
creating intermediate strings.
This fixes a memory issue that was introduced recently.
Signed-off-by: Sean Cross <sean@xobs.io>
Mark the private fields in a `MemoryRange` struct as being private. This
allows us to perform operations on the memory range armed with the
knowledge that the entire range is valid and unaliased.
Signed-off-by: Sean Cross <sean@xobs.io>
Previously, the log server would call `setup` on an uninitialized
struct. This is very undefined behavior, and risked running into
optimization errors.
This reworks the log server such that the singleton is protected by a
`None` value that gets initialized.
Signed-off-by: Sean Cross <sean@xobs.io>
This rewrites the entire project so that most runnable projects now use
`xous-ipc` instead of `xous::String` where possible.
This also removes `rkyv` from the list of dependencies in `xous-rs`.
Signed-off-by: Sean Cross <sean@xobs.io>
