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>
Turns out the build time only seems to capture the last time
you managed to force a full rebuild (???). Even though cargo
indicates that a rebuild had happened of the main.rs, the environment
variable containing the time is not being updated, because the
build.rs file isn't being run. But! if you force a trigger of
that file, then cargo decides to rebuild *everything* which greatly
increases the build time, which is a drag for development.
So, just remove the build time notice. If it's not going to be
correct, better to not emit it than to be outright misleading...
