Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Well,

Some questions come to mind as you have a couple of isses.

- Is your application writing anything to the filesystem (assuming a NAND based implementation) and what filesystem are you using (JFFS2)? If it's not writing anything then perhaps the filesystem should be mounted read-only? If you application is logging data, perhaps you could configure 2 partitions (one with the filesystem and application, a second with logged data, etc.).

- How big is your root filesystem, could you implement a ram disk instead of NAND for your application (e.g., initrd or initramfs)?

- Would it make sense to use AUFS? Our most recent 3.2 kernel supports an AUFS configuration that uses a RAM temporary filesystem on top of the NAND to keep the underlying filesystem consistent from boot to boot.

- If you still need to perform the shutdowns gracefully (sounds like you do, at least for the battery draw case), then you might consider using the /dev/watchdog feature and have your application hit that periodically. Though off hand I'm not certain if the watchdog will politely sync the filesystem before it resets (I think it will try).

- If you are concerned about your application dying, you might want to make it a daemon to ensure that it get's started back up again (coding).

A "reboot" or "poweroff" command will cause the kernel to unmount all filesystems. "sync" will ensure that posted filesystem writes are committed to your device.

Not sure if this helps....

-Mike

Helmut
I would think you could use the linux power management features to do this. Much like you can push a button on your laptop or PC to have it turn off.
See https://wiki.archlinux.org/index.php/Power_Management for an example. You may need to recompile the kernel and/or add some packages to do this.

Come to think of it, an easier way may be a simple shell script that does the following:
o Export the GPIO
o Set it as an input
o Make sure the "polarity" is correct
o Wait for activity on the GPIO
o issue the "poweroff" command, which will gracefully shutdown the kernel.

This will not shut down the power to the module/system, but will cleanly shut down the OS.
That said, I think you would be well advised to take steps to deal with a non-graceful shutdown. I don't know the particulars of your system, but most embedded devices get the power yanked from underneath them more often than not.

Michael & Tim:

I sincerely appreciate your advice and want to follow through as best that I can. While I am ultimately experienced at microelectronics and embedded programming, my linux expertise is limited mostly to regular user use. While I've done a little driver modification and kernel compilation, ALL of your advice is a bit of a stretch for me.

I would greatly appreciate a little hand holding from each of your personally, if you can provide it, including links with more detailed advice.

Here's the strategy I would like to pursue. Partitioning and Read Only come later, if project time and funds allow. Perhaps AUFS. For now, I need to try to get a graceful shutdown working. I could make my application a daemon, as Michael suggests, which gets me out of kernel programming. Or I could do the shell script, as Tim suggests. Both these hit a PROBLEM very quickly, however. So I believe I need to resolve this problem FIRST.

PROBLEM: Either my application or the shell script could issue the "poweroff" command, which leads to unmounting the local file system. But I must also send a KILL voltage out the SoM pin 28 GP0_5 in order to turn off the power supply. How can I make this happen AFTER the "poweroff", or at least after the unmount? There seems to be a catch-22 that the script either must finished first or is killed by the "poweroff" (or "shutdown 0"), and thus can't follow-up by asserting the KILL output, whose hardware response is unfortunately immediate.

Thanks again,
Helmut

Helmut,

You could try adding the KILL voltage script to /etc/rc0.d. If you look there you can see that the filesystem is umounted around S60 so if you put your script after that say S80KillPower then it would run after most of the shutdown was complete.

Jonathan,

In fact I just got that half working a moment before seeing your post, and completely working now. I put notes below for others.

*QUESTION: Now I would like to make my application a daemon, so that it will reload if it crashes. Then I'll remove pollpowerbutton.sh and do this power button polling in a separate thread of my application instead. In addition, this thread will check a voltage level monitor to watch for the batteries going dead as well. Since the program is a daemon, it should always be running and thus always lead to a graceful shutdown on low batteries. *

Thanks once again,
Helmut

NOTES:

file /etc/init.d/hgfshutdown99.sh contains:
echo "========== KILL POWER SUPPLY =========="
sleep 2s
echo 5 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio5/direction
#Note that "out" direction immediate sends out default pin value,
#which is correct for power supply KILL
echo "========== Should power off before seeing this echo =========="

file /etc/rc0.d/S99hgfshutdown created via "cd /etc/rc0.d" and "cp ../init.d/hgfshutdown99.sh S99hgfshutdown"

now any time "poweroff" or "shutdown -h 0" run, power will get killed at very last step. Note that simply "shutdown 0" doesn't do it because it doesn't actually halt.

file in application folder pollpowerbutton.sh contains (intend to later replace this with application code as daemon):
echo 14 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio14/direction
while [ "$(cat /sys/class/gpio/gpio14/value)" = 1 ]
do
echo "=POLL="
sleep 1s
done
#If we've reached this point, then GPIO 14 was a zero, so power off
poweroff

existing file in application folder autorun.sh updated to contain (intend to later remove pollpowerbutton.sh since application will do this job):
./pollpowerbutton.sh &
./applicationscript.sh

CORRECTION: Notes should do symbolic link copy: file /etc/rc0.d/S99hgfshutdown created via "cd /etc/rc0.d" and "cp -s ../init.d/hgfshutdown99.sh S99hgfshutdown"

I'm not aware of any specific process monitoring programs that we use. I know that system-D has the ability to do it but we haven't switched over to that on the am335x boards and its probably more work than your looking for. The simplest method i can think of would be to have a cron job that ran every few seconds and just checked that your process was still running. Alternatively there are quite a few resources on google about monitoring processes like apache.