Quote:
Originally Posted by pazos
Wow, @DomesticExtremis, You did your own research.
Probably you're right on the various low level bits. I hadn't time to check. My suggestion about UVLO was just after a quick read of the datasheet, but given there's an specific error for that on kernel sources I would came to the same conclusion as you: not our problem.
|
I'm no expert, that's why it is slow and ponderous. It makes my head hurt and my eyes go funny, but I'm slowly getting somewhere
Quote:
Please keep in mind that the PMIC you're exploring is just for driving power to the screen and shouldn't have the capacity of powering the whole system down. There is another PMIC based on MSP430 that's driven via i2c and that handles the various bits exposed to linux (battery, frontlight, GPIO...) and it is the one that could reset the SoC on demand.
https://github.com/pazos/linux-2.6.3.../mxc/pmic/core
|
Yes I get that, I think it's some other processor, or the code that puts the eReader into 'sleep' mode. The chip puts itself into standby mode based one of a certain set of errors which is equivalent to the eReader being in Sleep mode (when the eReader is 'powered down', the chip is in sleep mode, just to avoid confusion).
ETA: actually the eReader is not in sleep mode because the front light stays on. It just fails to boot fully according to the console messages. However the chip goes into standby, as it would if the eReader were sleeping.
Quote:
On my Kobo Aura HD it has its own serial header (labeled J2) but it just produces gliberish data connected at standard baud rates from 9600 to 115200.
|
Yes my Aura h2o has two headers. J5 is the one for the serial console, J1 is near an MSP430 DIP package, but just gives out unreadable characters. I suspect this one might be used for calibrating the screen voltages - apparently that can be done and I think the optimal voltages used change for each screen unit.