The rationale is that xous-rs should have only architecture
specific code, e.g.: riscv, arm, x86, etc. To make other
crates that depend on it not specify the features.
This could be useful when using xous-rs with `libstd`
for example.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
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.
Most of the changes introduced in this commit were rolled back,
but, there is now a test facility that's hanging out for the PDDB
to help with future debug efforts.
The patch was motivated by a problem observed in FSCB consistency
when it's updated. Ultimately the root cause was traced to a
cache coherence problem and it's fixed by a patch in the spinor
crate.
However, this patch still retains a check that the data is coherent,
in case the flushing routine isn't complete or some other factor
was missed. It also includes a large amount of commented-out code
that keeps a bit of history used to debug the problem -- eventually,
we can just cull that but it's kept around in case we got the
root cause wrong (or there were multiple causes and coherence is
just one of them).
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 adds some UX feedback in the edge case that a suspend could not
happen due to a blocking sever, e.g. a sha512 hash pending or
a SPINOR flash write/erase pending.
The UI will tell the user to retry again; usually the ops in
a normally functioning system for hashes or SPI are very short,
so we could almost just retry automatically but I think for now
I want to see if this edge case actually happens.
somehow, on windows builds, this doesn't break; but when building
under linux, the kernel config difference matters. Now that I
know how to pass features down, let's do it right.
this facility is necessary in case a worker accidentally picks
the wrong setting, disabling the feature for the device. When
the factory test completes, a call is made to reset the parameter.
This was a slightly complicated affair because the the don't ask
flag is contained within the rootkeys enclave itself, and we can't
just give access to rootkeys willy-nilly. So the flag is passed
through the PDDB and then to the rootkeys enclave. It's not harmful
to have it reset by an unauthorized actor; the pop-up will not
happen if passwords are, in fact, already set.
- add an autotrigger feature for the basis stress test so it can
be run in a fuzzer loop
- various fixes and improvements to the implementation to help
integrate with CI
takes about 1MiB of heap to decode the test PNG.
Putting the heap increase at boot seems to not
work, it causes other processes to not spawn. The condition
is not terribly reproducible, so it's probably a concurrency
issue of some type.
still getting a heap allocation failure, something is
looking for 256k and even when the heap is increased
to a couple megabytes we get heap allocation failures.
This allows for `ditherpunk` config to have a much larger
stack size on select processes only.
The cost comes at a 4k fixed overhead for the sacrificial
wrapper thread, so we lose about 20k of runtime RAM, even
when ditherpunk is *not* activated (because we're
always wrapping the threads).
There is no impact on scheduling or CPU utilization, as the
wrapper thread blocks and is never scheduled once the real
main starts. However, it does subtract one thread from the
total available thread pool.
this contains a dependency to `failure` two levels down that has a critical
vulnerability. Unfortunately no new versions of debug-here have been
published in a while. It's no longer used, so just stripping it out
altogether.
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>
Also note here that we have:
- Run all the AES test vectors and confirmed the pass for both
hw and sw
- Updated the benchmark numbers for the new AES implementation
A lot of packages are depending on 0.6 api, which requires a crate
that has OS specific TRNG calls. This patch keeps the 0.5 calls
inside the TRNG crate as direct API calls, and migrates to support
a 0.6 api to a patched version of getrandom that supports Xous.
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>
Also note here that we have:
- Run all the AES test vectors and confirmed the pass for both
hw and sw
- Updated the benchmark numbers for the new AES implementation
A lot of packages are depending on 0.6 api, which requires a crate
that has OS specific TRNG calls. This patch keeps the 0.5 calls
inside the TRNG crate as direct API calls, and migrates to support
a 0.6 api to a patched version of getrandom that supports Xous.
remaps keys based on the assumed keymap based on the user's
preference for the keyboard layout on the device.
So far, only dvorak and QWERTY are supported.
Also includes the USB test commands in shellchat.
This is different from the usb-test crate, in that it's fully
integrated into Xous. usb-test is just for quick-testing the USB
driver, in the absence of most of the rest of Xous.
This is basically the Rust example for the web server, with
some tweaks. Add a command to make the device buzz when
a particular URL is hit, and to wait before responding when
another one is hit.
Added a get_text_multi() method on modals which builds, shows and returns text taken from a modal view with a given amount of fields.
Calling get_text() is equal to a call to get_text_multi() with fields = 1.
The test routine for shellchat "cheats" and accesses the I2C block
to test the RTC during factory operations. This is not aesthetic
and is also potentially a security hole since we don't want less
trusted stuff willy-nilly playing with i2c.
Rewrite to
1) remove i2c references from shellchat
2) replace RTC calls with the newer non-dangerous llio calls that are
limited to read out the initialized time variables.
It's crappy because it uses a busy wait loop to poll the udp
rx socket in order to accurately emulate the Xous async callback
feature (which is _not_ emulated for Tcp, for example).
It's more accurate because this emulation happens. But it's a lot
more complicated to implement it because zero-cost async UDP callbacks
aren't really a host-native feature (but they are a Xous-native feature!),
and I didn't want to .. pull in tokio or mio code surface into
the Xous hosted mode, seemed a bit like crushing a fly by dropping
a house on it. Maybe that's a fine solution in Oz, but Xous doesn't live in Oz.
Total bodge -- we lop off the TCP stack at the Xous API level, and
substitute it with a native host TCP stack.
Caveat hacker: this means that a lot of OS-specific net properties
will carry through to the hosted mode emulation. This is adequate
for "smoke testing" a build but do not be shocked, *shocked* if
there are more bugs to be found because of some weird host integration
issue.
since xous 0.9.5, we've had a Box and we've had threads, so now we
can put the callback in a Box and pass it to a thread, instead
of relying on an `unsafe` work-around to get the callback function
pointer into the thread's environment.
also remove async write callbacks: in practice, these aren't used
Downside of this refactor is that threads for handling the
callbacks are not spawned on demand, they are spawned at boot,
leading to about an extra 68k of RAM used (most of it being
consumed in the codec block, actually). Some of this is also
probably extra object code because we're using more of the stdlib
primitives, which carry some weight.
