Got you on the script front. My issue is slightly different, when I get into my magic state, pressing the power button does nothing.
Which board revision Jonathon ? This board I noticed this on last night is an Element14 RevC. But on our A5A’s I never noticed the USR LEDs cycling like that.
Element14 revC.
I think what you are describing is the power ramp issue. I don’t think what I’m experiencing is the same thing. I’ve been through the power ramp issue and I just use my external KL16 to toggle the BBB pwr button a few seconds after power is applied, which kicks the board into boot.
Jon
Gerald, I do not have this setup yet, but perhaps in the future may have the means. Is this something that might be easily checkable via JTAG ? I’ve never used JTAG before, and do not have the header in place, but do have a JTAG emulator.
One thing that has been stopping me from seriously considering this as a debugging option, is that I do not know if there is an open source ( gcc - as in GNU compiler collection - Not the compiler its self ) tool. Passed that, it’s all new to me, and probably a steep learning curve initially.
I’ll take the “sound of crickets” reaction as this is too complicated a question to answer 
I’ll look into it on my own at some point . . .
Element14 revC.
I think what you are describing is the power ramp issue. I don’t think what I’m experiencing is the same thing. I’ve been through the power ramp issue and I just use my external KL16 to toggle the BBB pwr button a few seconds after power is applied, which kicks the board into boot.
Jon
Not trying to be difficult, or argumentative . . . but no, I think we’re experiencing the same thing. Only because the board will not boot up Linux at all after it gets into this state. The LEDs will cycle on, then off, but then nothing. I have to physically remove the power from the board for a few seconds, before it’ll boot again. Passed that, sometimes, the processes of removing the power may have to be repeated a few times before the board does finally boot. However this last part seems to mostly apply to our A5A’s mostly. I do not recall the Element14 RevC’s doing this.
So just in case this is helpful to the whole process:
william@beaglebone:~$ uname -a
Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC 2015 armv7l GNU/Linux
william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01
william@beaglebone:~$ pstree
init-±bluetoothd
-cron
-dbus-daemon
-7*[getty]
-rpc.idmapd
-rpc.statd
-rpcbind
-rsyslogd—3*[{rsyslogd}]
-sshd—sshd—sshd—bash—pstree
`-udevd—2*[udevd]
The output of pstree is just to show that I’m not running systemd, but instead sysv.
After reading all about the WDT inside the sitara the only way to cold
reset the processor is to power cycle it OR
pull PMIC_PGOOD low which pulls PORZ low which will cold reset the IC.
IT seems to me that there is some shortsightedness of TI not allowing
the cold reset to be pulsed from a WDT.
In case of a processor hang where a warm reset cannot allow the IC to
recover.
So you may want to find that signal on the board and tie your external
WDT to it and see if this solves your problem.
Maybe in the next rev of the BBB this can be some how made available for
an external WDT.
We could do that. I just need some information on which pin to remove from the expansion header.
Gerald
Just do it like the battery inputs allow a pin/hole for later population
if required.
I doubt anybody would give up any I/O pins without a fight.
We can do that. Nothing pending that calls for a design update. So, it will be a while.
Gerald
Got it into broken state again. My notes were incorrect, I see 5V on the power button, and 0V on the reset button. Holding down power button for 8 seconds results in a blip on USR2, but no boot.
I’m thinking it’s got to be cape-based, and I’m holding a pin high that shouldn’t be high until after boot. But I’m not using any of the EMMC pins or boot pins (or any P8 pins for that matter).
We can speculate all day long, but measuring the 5V current consumption will tell us a lot more about the power mode state than anything else.
Regards,
John
You can measure power all you want but if there is no way to reset the
processor what good is the device in a remote location. I have had
things on a remote mountain top at a transmitter site in winter that if
things were unresponsive
would ruin 2 or 3 days trying to get there to reset the device on a
snowmobile.
Fail-safe computers are desirable. Hangs with no way to reboot a system
are not.
We are just trying to debug the problem. This is a process of elimination so that we can narrow down the problem.
I have two BBB Rev A5A and I have never seen this problem. Admittedly, I boot these boards over NFS and I use SystemD. I also use this device to switch the power to the BBB on/off:
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G137361754360
With the 5V adapter always on, this ODroid Smart Power does a clean power-on via an electronic switch.
Regards,
John
Kernel version 4.1.13-ti-r33
BBB V A5A
After logging in, BBB 5V current is ~375mA
echo -n “mem” > /sys/power/state
BBB 5V current is 56mA
USR LED’s are all off
PWR LED on
Power Button press has no effect (1 second)
Reset Button press has no effect
I’m not sure why, but
echo mem > /sys/power/state
does not return from suspend when I press any key on the keyboard; however
echo standby > /sys/power/state
does work correctly and returns to running state when I press any key on the keyboard. Also, pressing the power button (1 second) also returns to run mode.
Regards,
John
If i remember right, in v4.1.x the usarts are not enabled by default
as a wakeup source anymore.
so make sure you enable it:
http://elinux.org/OMAP_Power_Management
Regards,
Hi Robert,
cat /sys/devices/platform/ocp/44e09000.serial/power/wakeup
enabled
Strange that it works for standby and not mem.
Regards,
John
I’m using:
http://processors.wiki.ti.com/index.php/AM335x_Linux_Power_Management_User_Guide
Regards,
John