this should cause the backlight to turn on anytime there is
an incoming U2F packet, allowing a user to read the screen
and see what they are trying to allow for authentication even
in a dark room.
by marking the EC as ready after all the update checks are done
we can ensure that the PDDB mount dialog does not attempt to come
up during an EC update.
Mark `MemoryRange::as_slice()` and `MemoryRange::as_slice_mut()` as
unsafe.
This is due to the fact that not all representable types can be cast to
an arbitrary value. For example, if Process A sends random values to
Process B, then Process B casts the memory to a slice of `bool`, then
any values that are not 0 or 1 are undefined.
Because these functions can leak UB into the program, they are marked as
unsafe.
This patch adds `unsafe {}` blocks to all instances where this function
is called. Additionally, all instances have been checked to verify that
they do not cast to any invalid types -- most use `u8` or `u32`.
Additionally, the long-deprecated `MemoryRange::from_parts()` call was
removed, since that causes UB without being marked as unsafe.
Signed-off-by: Sean Cross <sean@xobs.io>
Mods to allow the EC to support open wifi networks. Requires an
update to the EC as well as Xous for this to function.
Before filing an issue, please check that EC version is v0.9.13-5-g8f7e23f
or greater by running `ver ec` inside shellchat.
I decided to go back on the idea of not changing the modals
and now all modals use the new larger font as well.
This creates issue #396, which I will deal with later once
I have the time to do some more testing. I'm pretty sure
some other dialog boxes are broken now too.
This change is made with the intention of making the xous-rs crate a bit
more freestanding without depending on the xtask build system.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
ssid scans can now be in-progress, and they also record
the time elapsed since the last scan was performed.
this allows the network manager to be a bit smarter about when
it decides to kick off a scan.
the ssid scan dialog box is also updated to show
the scan results in progress. This addresses #336.
Adds a menu item (defaults to 0 or off) for autosleep timeout in
minutes.
Once the autosleep timeout is hit, the system tries to suspend.
- It will not try to sleep if the system is plugged in.
- It will reset the timer if the power state changes (plug/unplug).
- It will reset the timer every time a key is pressed.
- The timer is reset on suspend, so it does not try to immedaitely re-sleep on wake.
The autosleep handler is domiciled in the "pump" loop which is
responsible for updating the uptime timestamp in the status bar.
It is pinged at a 1 second interval.
Therefore, the sleep timeout has a +/-1 second variability in it,
and also, a quick plug-unplug event (< 1 second) will likely go
unnoticed.
this should fix the issue on #382. The behavior is now:
*device not plugged in*
1. select "Lock device (reboot)"
2. device reboots
3. device goes to sleep
4. user wakes up the device
5. user is challenged with the unlock PIN
*device is plugged in*
1. select "Lock device (reboot)"
2. device reboots
3. user is challenged with the unlock PIN
I think this should be the "least surprising" outcome given
the description of the menu item.
The crate just re-exports the com_rs crate. This patch changes usages of
com_rs-ref to use com_rs directly.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
This flag is only set if the user selects "Lock (reboot)".
This way, the device sleeps immediately after boot, and makes easier turning it on and off in a safe manner.
sometimes it can take a bit longer for the EC to respond to
version requests. Instead of hard coding a timeout and check
poll the EC over a longer period, which leads to a system more
tolerant of the variations in startup times.
Time services are moved into the DNS crate so that the EC
update thread can remain running and consuming resources.
The problem is that we are out of connections in the connection table
(it's limited to 32 total), and in order to allow a "force update"
function for the EC we need to hold on to more connections than
are possible.
The "time" service is fairly self contained and could be moved
elsewhere. It sort of logically fit in the status crate initially
because the status crate manages preferences and displays the
current time on the screen, but it's modular enough that we could
put the service in any process space, at a minor trade-off of
the time UX function being public. This was avoided for a long
time because it could be a security risk but in the end the records
that store time zone and offsets are in the PDDB, which are accessible
to anyone who knows the names of these records, which is in the end
equivalent to knowing the name of the time UX server.
Thus the time UX server was made a dynamically registered "public"
server with just one connection (so only a minor downgrade in security,
the only vector exists in between boot and when the time servers
connect up), and the time server itself was slotted into the DNS
server's process space.
The DNS server was chosen because the DNS service itself is
very lightweight and will be unlikely to grow any heavier, so there
is little risk in merging the time service into the DNS crate's
process connection allocation.
adds the menu item and handler for a force update
revises some of the wording of the menus so they are more
self-consistent
leaves the EC update handler thread running permanently so
that force updates can be caught and handled
- don't hard panic if the time seems wrong; just clear
the PDDB entries, and move on. This at least allows the
user to intervene to fix the time, intsead of insta-crashing
when anything seems wrong and depriving users an opportunity
to fix anything
- fix HW derpiness by introducing some dummy reads during
the resetting of the hardware process.
One thing I wanted to do was to have the RTC always powered
off of the battery. This is not a default mode but it's an
option. In theory, this is a more efficient because anyways,
VDD comes from VBAT, right? However, the RTC hardware gets
a little side-eye when VBAT is higher than VDD most of the
time and reports a strange error code. The power savings
is miniscule -- some tens of nanowatts -- so I'm not going
to fight with the RTC hardware quirks anymore.
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.
also defer the preference thread from loading until after the
PDDB mount thread is started -- doesn't make sense to start it
any earlier than that, since it depends on the PDDB being mounted.
