MoPi/simbamon power button bit set on boot

[jonathanhogg]

I'm getting three different MoPis (an original Kickstarter one and two recently purchased) causing issues on boot with a RaspberryPi A+. The issue is that simbamon reports that the power button has been pressed as it starts up, causing it to tell init to halt the system.

The A+ is running a variant of Raspbian (wheezy), a custom kernel build (3.18.16+aufs3) and the version of simbamon included in Raspbian (no obvious version number in the script).

Example boot log after applying power and then pressing the power button until the LEDs light up:

[   38.114031] simbamon: first run after boot, sleeping for 2...
[ ok ] Started simbamon.
[   40.138978] simbamon: ...boot delay done
[   41.543282] simbamon: MOPI_STATUS is 4233
[   41.661670] simbamon: shutting down (POWER_OFF; 4233)
INIT: Sending processes the TERM signal

My current hack is to read the status in simbamon in the if [ -z "$PREVIOUSLY_RUN" ] block and wait 30 seconds if the shutdown bit is set. This seems to mostly make the problem go away as the next time that it reads the status, that bit isn't set anymore.

[jonathanhogg]

Actually, my hack is not reliable. It appears that I am seeing the bit becoming set after first read as well:

[ ok ] Started simbamon.
udhcpd: Disabled. Edit /etc/default/udhcpd to enable it.
[   40.802242] simbamon: ...boot delay done
[   43.297613] simbamon: MOPI_STATUS is 4105
[   46.762208] simbamon: shutting down (POWER_OFF; 4233)
INIT: Sending processes the TERM signal

I swear that I'm not going anywhere near the power button!

[jonathanhogg]

Interesting. I just had the power button flag set itself spontaneously while the Pi was running. Right after I switched the CPU frequency governor! Could a change in CPU frequency be upsetting the i2c code and causing it to misread data? Or does the MoPi have any firmware hackery for simulating a power button press in overcurrent conditions or something?

I currently under-clock the Pi A+ after boot is complete using a set of low _min config.txt frequencies and an initial_turbo.

[hamishcunningham]

In development we saw glitching on the i2c bus quite frequently, which lead
to setting the high bit in the status word, IIRR.

To fix it, the python communication code did something like multiple calls
and averaged them. [cc'ing Fred, who wrote that code]

I suspect what you're seeing is glitching that is a similar process,
perhaps triggered by the patched kernel you're using, or frequency changes.
(This post suggests that clock stretching in the Pi i2c bus is the root
cause: raspberrypi/linux#254 )

A possible workaround might be to do multiple reads in the simbamond code;
or to swap in "advancedRead" in mopiapi.py; or to look further into the
Broadcomm i2c bug referenced above

Sorry not to be more definite! Nasty problem to debug :-(

h

On 13 October 2015 at 17:15, Jonathan Hogg notifications@github.com wrote:

Interesting. I just had the power button flag set itself spontaneously
while the Pi was running. Right after I switched the CPU frequency
governor! Could a change in CPU frequency be upsetting the i2c code and
causing it to misread data? Or does the MoPi have any firmware hackery for
simulating a power button press in overcurrent conditions or something?

—
Reply to this email directly or view it on GitHub
#63 (comment)
.

Hamish Cunningham
Professor of Computer Science, University of Sheffield, UK
+44 7920 765 455 https://twitter.com/@HCunningham hamish@gate.ac.uk
https://pi.gate.ac.uk https://hamish.gate.ac.uk https://gate.ac.uk

[jonathanhogg]

Ta for this. It would seem to match what I'm seeing. I think I may ditch simbamon and just use the API directly. This Pi is effectively running a single program and it's written in Python anyway; this way I can extract and log interesting battery data while I'm at it.

I'll leave this issue open in case it's something that you want to think about; feel free to close if you don't think there's anything useful you can do.

[hamishcunningham]

Thank Jonathan, that sounds like a good solution :-)