the init() function on this object may actually be called several
times within a single boot context because the codec is powered down
as a separate subsystem from the rest. however, the interrupt should
still only be hooked exactly once. This flag tracks that state.
Boxing the `Codec` object and sticking it on the heap causes
audio playback to hard-lock (no kp, no other explanation given).
Not sure what the issue is, but a cleaner fix is arguably to simply
increase the stack size so the objects can be allocated there.
I suspect the problem may have to do with how the FIFO structures
are memory-mapped and somehow this does not play nice with
Box (there are `unsafe` routines within it).
The codec object contains a lot of data including a `FrameRing` buffer
as well as some other services. With the latest version of Rust, this
has grown large and no longer fits onto the stack. As a result, it
crashes with a stack overflow immediately upon boot.
Move the Codec onto the heap. This frees up stack and allows it to run
under Rust 1.69.0.
Signed-off-by: Sean Cross <sean@xobs.io>
Individual I2C register reads and writes, even if to multiple bytes,
are atomic.
However, some i2c operations require multiple reads and writes
to be strung together without interruption for them to be valid.
A "mutex" is added, which if a program using I2C calls it prior
to their I2C operation, it will block if another program is
already using the I2C block for an uninterruptable series of
operations. The caller will automatically be unblocked once
the untinterruptable transactionts are completed.
Note that this is a collaborative exercise, a caller can still
try to initiate an I2C operation without getting a mutex first,
in which case it could interrupt another block that is doing something
uninterruptable. At the moment this merely generates a warning on
the console, but eventually, this will become a panic.
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>
This is a start on issue #111, where instead of starting a throw-away
server and doing a "yield" loop to emulate blocking behavior, messages
are instead stored so they don't drop, thus keeping a blocking
message blocking.
Add a "Later" stage, and have exactly one "Last" stage.
"Last" to suspend is the ticktimer -- this is crucial for
basically everything else to work. The other really
low level stuff that needs to work to the last minute is
now in the "Later" bin.
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.
Was doing disjoint loads and stores on an Atomic, really, should
be using the fetch_add, fetch_sub variants to be proper.
Didn't seem to impact anything but maybe there's a future version
of me that high fives me for doing this.
So far it's been no problem to suspend these in any order, but as
more services come to rely upon them it's better if they suspend after
any client applications have been suspended.
this prevents less trusted processes from connecting to servers
after the kernel initializations are done.
this works so long as we don't have disconnects from the kernel
servers. In order to support disconnects we will also need a
way to re-enumerate the SID to guarantee that we don't have a re-use
problem. But for now, the kernel is not designed with any practical
disconnect mechanism; there is no code that calls the Quit mechanism
on any server.
the connection number is re-used for all objects created
within a process space, so you can't `Drop` the connection
immediately when an object goes out of scope. You have to
make sure all instance of the object go out of scope. This
patch adds reference counting to all the objects so that
the `Drop` function works as intended.
the concurrency issues on I2C are getting hairy, and it was probably a
dubious decision from the start to merge I2C into the LLIO block; but
originally this was motivated by the idea of keeping all the
"miscellaneous slow stuff" in one process to keep the memory footprint
small and make code a bit more readable.
Keeping I2C in the same process space as the LLIO but splitting it
into its own thread and server splits the difference, by giving us
more options to deal with the concurrency, without inflating the size
of the kernel binary and allocating a lot of extra static data.
