This is the weirdest damn thing. All the crates say 0.4.19 as
the chrono version, but the actual version in the lockfile
is 0.4.33. And there isn't an error about it?
Anyways, this update the pins to reflect what's in the lockfile.
The nominal purpose of this is to allow other services to delay
interactions that could interfere with an EC update.
Note that anyone could call this routine and mark the EC as not
ready, since the llio block is not secured and the API is public.
I don't think it's a security problem, but is a DoS vector.
Wait until after the struct is created. This will cause it to be placed
in a fixed address, which works around an issue that appeared in 1.71.0.
Signed-off-by: Sean Cross <sean@xobs.io>
- make the "base" field no longer public. It is accessible, but only
through an `unsafe` method, because, it is unsafe.
- add accessors to offest/mask fields. Because, it's not at all
unsafe to access these, and it can be useful for bit-ops that are
not part of the generic set of UTRA.
- add Arc to AtomicCSR, and require `std` for AtomicCSR types.
This should not break anything, I checked inside @foundation-devices
keyOS and they don't seem to be using AtomicCSR anywhere.
The Arc makes it a bit safer to clone the AtomicCSR base pointer
and share it between threads, but it will have an impact on performance.
The USB stack (which requires AtomicCSR) was regression testing and the
impact seems minimal.
Recall that the main purpose of AtomicCSR is to provide a CSR accessor
that does not require a mutable reference to the base object. This
can make certain Rust idioms a bit cleaner. We wrap the base accessor
in Arc+Atomic to try and improve the safety of throwing the borrow
checker under the bus, but it's still not perfect because hardware
mutable state can have side-effects within hardware itself that cannot
be modeled or checked by Rust's borrow checker.
Alright, this one was very tricky.
The problem here turns out that if the very last operation
on the RTC was a write before powering off, any spurious
clock/data noise is interpreted as a valid write to the RTC!
Thus, if the last thing you do to the RTC before a suspend is
a write of some sort, the RTC is going to be corrupted. During
shutdown, the RTC lines slam up and down a couple of times:
- they drop low as vcore discharges
- they then pop high once vcore is dead
- they then slowly drop low as vddio drops
in both of these cases, they drop with a very slow (>10ms)
fall time, which gives ample time for the RTC to get excited
and think maybe some data is being written to it! Also on boot,
there is a brief glitch of SDA/SCL at the same time, which looks
very much like a start condition.
Anyways, this patch does two things:
1. Performs a dummy read to a register that is "far from" any
critical data resisters. This puts the I2C state machine
of the RTC in "read" mode, so any future clock cycles just
keep wheeling through the RTC bank as a read, instead of clocking
in data as a write. There is a non-zero chance that the noise
"could" emulate a valid I2C transaction (it'd have to create
the bit pattern that addresses the RTC, with the right timing),
but in practice this hasn't been seen.
2. Disables the RTC block on suspend, prior to suspend. This
will prevent the RTC engine from issuing any new commands as
the core starts to shut down. It's conceivable that e.g. the
"start" bit could randomly flip high as the power goes down
and since the I2C engine is now in the always-on domain it'll
dutifully start clocking out bits as the power goes away.
This patch seems to have stabilized the RTC corruption problem
that was previously witnessed.
