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>
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.
The init code tried to set up the ECC block to report errors by writing
into the softirq block. Correct the block so that it goes into the
spinor block instead.
Signed-off-by: Sean Cross <sean@xobs.io>
Keyboard setting is "the one and only" exception to user settings
that are saved without encryption. This is because you need your
keyboard layout to be set in order for you to type your password.
Thus, this needed a bit of a special-case to handle its storage record.
We decided to lop off 1 page from the loader and have it store
the keyboard layout code.
Let's hope we can have the discipline to really just store that
one word of information and not later be like "gee wally, you have
a whoooole 4092 unused bytes of space we can cram unencrypted
user settings in, sure would be a waste to not put those use those".
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.
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.
- you can only "patch" regions of memory. caller provides a slice
to the region of data they are patching, so that patches can be
computed by the lib-side code of the server.
- erasing is done with a "patch" with all 0xff's as the write data.
a sequence of pure 0xff for a page does not actually cause a write,
the condition is detected and the write is skipped after an erase.
- patches attempt to be somewhat intelligent and not re-write unchnaged
data, or erase blocks that don't need udpating. However, if a user
submits a "sparse patch" with just a couple bytes modified in a
megabyte region they can expect bad performance. Ideally, in that
scenario, each of the smaller modifications are submitted as
individual calls to the patch function, instead of regurgitating
all the data and hoping that hthe patch function does some intelligent
diffing to be as light-fingered as possible about updating the flash.
In other words, the onus is on the calling server to format
patches intelligently. The patch server does only the simplest,
safest optimizations. You don't want to be shuttling megabytes of
redundant data anyways between servers for many other reasons....!
