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.
CPU is sleeping during I2C transactions, leaving the bus in a state
where the I2C transaction is continuously being fired over and over
again because the way LiteX creates CSRStorage, it gives the
CPU precedence over the block's update.
Basically what happens is that the CPU writes something to the
I2C, goes to sleep, and leaves the I2C block selected. This causes
the I2C block unable to clear its own I2C transaction initiation
register, subsequently leading to the I2C transaction being repeated
over and over again until the CPU wakes up and stops jamming the
bus in that state.
By forcing WFI on during I2C transactions, the CPU is more responsive
during I2C and also we prevent the I2C transactions from being restarted.
This was verified using an oscilloscope.
Restrict crates.io published set to just APIs, not implementation
files. Nobody is using the implementations anyways -- it was requested
but I've never seen the package pulled except for CI.
fix an issue where I2C, if not working well on resume, is not
recovered correctly. This patch improves that and hardens
the RTC code so that it handles a case that normally panics
with a try-harder loop.
When a block of data perfectly fits we fail to allocate the
next page, violating the loop invariant that there's data available
to write.
However, we can't always allocate a new page when we run out
because if we're at the end of the process we shouldn't allocate
a new page (I think). Thus we track if the last section was
a perfect fit, and if it was, we force a new page allocation
before copying more data.
This is an edit in phase 1 of the loader.
