>> 2) Use a 1F/5V supercap on the TPS65217B BAT pin (or a battery,
>> but that has regulatory complications, and lifetime issues), with
>> this supercap giving the system enough time to gracefully close
>> the filesystems. Has anyone tried that?
>
> That's one heck of a cap! Be careful with using the BAT pins with
> anything other than a battery, it may not behave how you expect.
A TI employee said [1] "The battery charger should work fine with a
supercap. You'll need to make sure the TS (battery temp sense) pin
is at a proper voltage to allow charging. If the supercap does not
have a temperature sensor, you can simply put a 10k resistor from TS
to GND."
Interesting. I'll keep that in mind. I hadn't considered super caps.
Your 1 F cap, charged to 4.2 V, only has about 2.45 mWh (if my math is
correct) of energy. Assuming that the "Kernel Booting (Peak)" current
consumption measurement is roughly right in the bone SRM (rough worst
case), that's about 0.485 mWh energy consumed per second, leading to
only a few seconds of run time from the 1 F cap.
Personally, I want to err on the side of being able to get at least 20
to 30 seconds of run time with the battery/cap voltage above 3.5 V, so
1 F isn't quite enough for my pessimism.
However, your 1 F super cap is quite a bit smaller, physically, than my
current battery of choice (0.9 Ah 3.7 V nominal, 4.3 V full) and the
cost is actually lower. The concept of a super cap instead of a battery
wasn't something I considered, but now it seems like a worthy thing to
look into further.
From a quick search, it seems hard to find 10 F (or so) super caps with
5 V (or so) rating. I think 10 F (or so) would be more the run time I'd
like. Shutdown isn't instant and I've seen > 10 second shutdowns.
Plus, there's going to be some latency between the TPS65217 switching to
battery/cap power and the system being able to detect and issue the
shutdown (a polling architecture here would be bad, seconds count!).
Related to this is that preproduction XAM335x chips, which appear on all
my bones up through rev A6 boards, all have a RTC errata where if core
voltage goes away (if TPS65217 enters SLEEP or OFF mode) that the RTC
loses track of time. So the RTC isn't reliable exactly when you'd need
it to be. For this reason, I'm using an external TI bq32k RTC on I2C.
The SYS_5V voltage should stay present if a battery is connected even
with the TPS65217 OFF and we have a linear regulator powering the
external RTC from SYS_5V so we can track time while off. A super cap
wouldn't be as useful here as the capacity wouldn't last more than a few
days (weeks maybe?) of OFF time whereas we expect the 0.9 Ah battery to
last months if it's fully charged.
My use case (maybe yours, too?) is that our customers' normal way of
shutting down will simply be to pull the power cord out and wait for the
LEDs to turn off. When the power cord is reinserted, it powers back up.
> I don't believe the existing system will detect the power source
> changing in order to initiate a shutdown. It should be possible
> based on my reading of the data sheets and I'll be implementing it
> soon (if this capability doesn't already exist), so if you have
> any existing code to do so (or can point me to some), I'd love to
> contribute.
No code at the moment... the TPS65217B exposes some registers that
note the power supply I think, but they'd need to be polled
frequently...
Page 22 of the TPS65217 data sheet says, "Interrupt events include
pushbutton pressed/released, USB and AC voltage status change." So the
TPS65217 should be pulling the NNMI interrupt pin on the AM335x
(connected to Cortex-A8 core). When the TPS65217 interrupt occurs, the
kernel needs to check the interrupt register, see what caused the
interrupt, then read the state of the STATUS registers to see what the
current power source is. If it's not AC, shut the heck down! 
I'm not sure that kernel space can issue a shutdown command, so init may
have to be notified. If anyone has pointers to how to notify init of
conditions from kernel space, could you point me to docs / code?
Alternately, the kernel could emit a ctrl-alt-del which init should
catch. This part I haven't thought through well, yet.
-Andrew
