On 13 May 2015 at 16:48, Johan Hovold <johan@xxxxxxxxxx> wrote:
> By the way, perhaps you should add a comment in the tps node explaining
> why ti,pmic-shutdown-controller must not be disabled (on what revisions
> of hardware) as well?
There are actually three separate obstacles for RTC-only sleep (only
one of which actually BeagleBone-specific), so the "why" is a bit of a
long story. The end result can however be stated briefly:
Only BBBs prior to rev A6 properly support RTC-only mode. The rare BBW
with a 2.x processor also supports it, provided nothing is connected
to its expansion ports that leaks significant current from 3v3exp to
processor I/Os while in reset.
Any BeagleBone with an AM335x 2.x can be patched to properly support
RTC-only mode. (Though reconnecting vdds to LDO3 is really no fun, and
not a patch I could have done myself.)
For reference, the details on the three problems:
1. Most BeagleBone Whites use AM335x 1.0 which freezes the RTC when
vdd_core is gone or power-on reset is asserted, rendering RTC-only
sleep mostly useless. The BeagleBone Black, and a few BBWs, use
AM335x 2.x which fixed this.
Of all problems this is the most benign one since it merely results in
loss of functionality. The other two risk hardware damage.
2. TI issued a notice that the AM335x "vdds" supply must be among the
first to come up, and changed the official connection diagram for the
TPS65217C/D (used for boards with DDR3/3L memory) by moving vdds from
LDO3 to LDO1, and the BBB implemented this change in rev A6A.
This change is incompatible with RTC-only sleep (a fact mentioned by
TI), so this rules out RTC-only sleep for any AM335x board with
DDR3/3L memory unless it predates (or ignored) TI's advice or uses a
different power supply scheme altogether. Boards with DDR2 memory
(TPS65217A/B) such as the BBW are not affected.
Curiously, based on preliminary measurements, I have not observed any
leakage to vdds when it is powered up "late" (LDO3). In contrast,
during shutdown vdds begins to leak heavily (far in excess of rated
max current) to other rails once they drop low enough, and moving vdds
to LDO1 only makes this situation persist even longer (and
indefinitely in RTC-only sleep). I've asked TI support for some
clarification on this, but not yet received any response.
3. All BeagleBones have a mismanaged external regulator for the
"3v3exp" (BBW) / "3v3b" (BBB) rail, which remains enabled longer than
the AM335x's 3.3V supplies ("3v3a").
On the BBW, external hardware may end up sourcing current into
processor I/Os, which feeds the 3v3a through protection diodes. Since
the 3v3a is used as enable-signal for the regulator, if non-negligible
current is leaked via this path, 3v3a remains "logic high" and the
situation will persist indefinitely. If the currents remain modest
this won't necessarily violate any absolute maximum ratings, but I'd
still worry about the processor's long-term health.
On BBB rev A6 and later the situation is the same, but without
dependency on external hardware: the current from on-board pull-up
resistors already suffices (3v3a remains at ~1.4V), and since rev A6A
the leakage from vdds would also get the job done. Worse still, since
the buffer for the console port is powered by the 3v3b, having a
serial cable attached causes a dangerous amount of current to be
driven into UART0_RXD (~45 mA) and I captured an event which I fear
may have been a brief latch-up.
On BBBs prior to rev A6 the regulator is enabled by LDO2 (whose only
other use is the power led), which prevents it from staying on
indefinitely. It is however enabled 1ms before and disabled 1ms after
the processor's 3.3V supplies, so external hardware must still avoid
driving much current into I/O pins during those windows, e.g. by
keeping drivers disabled while reset is asserted. As mentioned above,
the console port buffer violates this rule.
Technically this problem is also present when performing a full
shutdown ("OFF-mode"), but then the main supply is cut at the start of
the power-down sequence, which proceeds while running off rapidly
draining capacitors. Heavy current draw from 3v3b will drain them even
faster, thus making the issue self-limiting. (This however does not
apply when running on battery power, in which case even a full
shutdown is hazardous on an unpatched BBB rev A6 or later.)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
