Ich habe inzwischen noch etwas in den Kernel-Quellen gestöbert und dabei feststellen müssen, daß die Methode mit dem Speicherzugriff, die bei der 7390 - meines Erachtens - gefahrlos genutzt werden kann, um die GPIO-Pins der LEDs gezielt zu schalten, bei VR9-Boxen (7490, 736x) so nicht funktionieren kann.
Während die 7390 (Vx180) für das Setzen/Löschen eines einzelnen Pins getrennte Register verwendet und nur jeweils per 1-Bit adressierte Pins beeinflußt werden, wenn man eine Schreiboperation ausführt, finden die GPIO-Operationen bei VR9-Boxen nach dem Schema "32 Bit lesen, 1 Bit ändern und 32 Bit zurückschreiben" statt, das ganze soweit gelockt, daß es nicht unterbrochen werden kann (7490 ist ja auch noch Multicore).
In diesem Falle kann man natürlich auf der Kommandozeile mit 'devmem' keine atomaren Operationen nachbilden und in dem GPIO-Register für die LEDs bei der 7490 sind auch noch andere Output-Pins definiert, deren Wert man natürlich nicht mit ändern will (darf).
Dafür existiert auf diesen Boxen normalerweise ein Device 'ifx_gpio' (cat /proc/devices), für das zwar seitens der Firmware kein /dev-Eintrag eingerichtet wird (bei meiner 7490 ist die Major-ID 240), den kann man ja aber selbst mit 'mknod' erstellen. Anschließend müßte sich mit IOCTL-Aufrufen über das Device eigentlich der Zustand einer LED ändern lassen. Allerdings gibt es für IOCTLs nun meines Wissens wirklich mal kein "fertiges" Kommando (abgesehen von einen kleinen Tool unter Android). Man müßte bei diesen Boxen also doch zu einem kleinen Programm greifen, das die LEDs dann schalten kann. Ich denke im Moment darüber nach, das als Patch für ein zusätzliches optionales Applet für die Busybox zu bauen, dann spart man sich den ganzen Aufwand eines gesonderten Projekts.
Das Auslesen des aktuellen Zustands müßte sich allerdings auch mit 'devmem' bewältigen lassen. Je nach Box-Typ (entscheidend ist, wo die LEDs angeschlossen sind), ist dafür eine andere Adresse zu benutzen. Die Konfiguration der GPIO-Pins läßt sich (bei meiner 7490, 736x habe ich nicht und kann es nicht selbst testen) über /proc/driver/ifx_gpio/board auslesen, auch wenn dort nicht zu erkennen ist, welche LED an welchem Pin hängt.
Für die 7490 (HWRevision 185) wäre das der GPIO-Port 2 (Adresse 0x1E100B74 fürs Lesen), wo an Pin 1, 3, 4, 13, 14, 15 die LEDs info, wlan, festnetz, power, info_red, internet hängen (power_red gibt es wohl nicht). Da ich das so wie erwartet im Speicher gefunden habe, ist zumindest das 'get_led_state' für 7490 genauso per Script möglich.
Code:
#! /bin/sh
#
# usage: get_led_state <ledname>
# returns 0 for 'off' and 1 for 'on', 127 in case of an error
#
hwr_wanted="185"
leds="info/1 wlan/3 festnetz/4 power/13 info_red/14 internet/15"
hwr=$(sed -n -e '/^HWRevision/s/^HWRevision[ \t]*\(.*\)/\1/p' </proc/sys/urlader/environment)
if [ x"$hwr" != x"$hwr_wanted" ]; then
echo "Wrong hardware revision, that '$0' is only usable on a box with HWRevision $hwr_wanted." 1>&2
exit 127
fi
if [ ${#1} -eq 0 ]; then
echo "Missing LED name." 1>&2
exit 127
fi
led=$1
set -- $leds
unset pin
while [ ${#1} -gt 0 ]; do
if [ "${1%/*}" == "$led" ]; then
pin=${1##*/}
break
fi
shift
done
if [ ${#pin} -eq 0 ]; then
echo "Unknown LED name '$led'." 1>&2
exit 127
fi
dm="busybox devmem"
$dm 2>&1 | grep -q "applet not found"
if [ $? -eq 0 ]; then
echo "Please check your busybox binary and it's 'devmem' applet support." 1>&2
exit 127
fi
ma=$(( 0x1E100B74 ))
sz=32
msk=$(( 1 << $pin ))
val=$($dm $ma $sz)
if [ "${val:0:2}" != "0x" -o ${#val} -ne 10 ]; then
echo "Unexpected value '$val' returned from 'devmem'." 1>&2
exit 127
fi
v=$(( $val & $msk ))
[ $v -eq 0 ] && r=1 || r=0
exit $r
Wenn es wirklich zum o.a. Applet für das Setzen kommen sollte, macht es natürlich auch Sinn, das Lesen per IOCTL da dann gleich mit einzubauen. Ansonsten kann man - wenn man die notwendigen Angaben sammelt - ja auch für sich und seine Boxen (die das Auslesen per devmem unterstützen) ein "persönliches" Script bauen, das anhand der HWRevision die richtigen Pins und Adressen/Größen für devmem auswählt.
Für die 7360 (HWRevision 183) sollte vermutlich die folgende Belegung der GPIO-Pins für die LEDs gelten:
power/32 power_red/33 info_red/34 festnetz/35 wlan/36 internet/38 info/47
Von den Pin-Nummern ist dann jeweils 32 zu subtrahieren (die ersten beiden Ports haben je 16 Pins) und damit ist dann die Power-LED der Pin 0 an Port 2. Daraus ergibt sich dann auch bei der 7360 die Adresse 0x1E100B74 (GPIO-Port 2) für das Auslesen aller LEDs. Da man die LEDs ja testweise mit 'led-ctrl' schalten kann, findet sich vielleicht jemand, der das Auslesen auf einer 7360 mal testet und meine theoretischen Überlegungen bestätigt oder auch widerlegt. Einfach das Script ein wenig modifizieren ...
