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.
- 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....!
