FritzBox, speziell 7270, die LEDs können ja auch rot leuchten!

Ich weiß nicht, wie die LEDs angesteuert werden, aber ich würde strace auf das Programm led-ctrl laufen lassen. Irgendwie muss das Programm ja mit dem Kernel kommunizieren, um die LEDs zu steuern. Von da aus sollte sich die passende Stelle im Kernel finden lassen.
Danke für den Tipp, aber da ist m.W. (ich habe meine letzte 7270v3 leider im Moment extern stehen und kann da ohnehin keine LEDs ablesen) noch ein Kernel-Module (led_module.ko) dazwischen, das u.a. auch das "neue" /dev/led implementiert, das im Gegensatz zu früheren Zeiten nur noch IOCTL-Aufrufe und kein direktes Lesen/Schreiben mehr unterstützt.

Aber für das liegen ja (GPL sei Dank) die Quellen vor ... ich finde da bloß (dank der "monolithischen Struktur" der AVM-Software mit allem Code mit zig DEFINEs und Unterstützung von 7050 bis zur 7490) die richtigen Stellen bei der UR8-Architektur irgendwie nicht.

Ansonsten erfolgt die (abstrahierte) Ansteuerung der LEDs seitens der Firmware immer mit diesen ominösen "LED-Events", dabei greifen AVM-Binaries auf libewnwled und libled2 zurück, um darüber mit /dev/led zu kommunizieren. led-ctrl wird von AVM m.W. eigentlich nur noch zum An- und Abschalten der Firmware-Update-Events benutzt, auch wenn die anderen Events - soweit in der Liste von led-ctrl implementiert - damit auch ausgelöst werden können.
 
PeterPawn schrieb:
Zumindest bei den Buttons sollte es "ordentlich" zugehen ...
Die Taster schalten nach Masse (0.0V).

PeterPawn schrieb:
@scolopender: Kannst Du verifizieren, ob es sich bei den "bunten" LEDs (sicherlich die SMD-Variante, oder ?) um zwei getrennte Bauteile oder eine Duo-LED handelt ?
Das sind zwei unabgängige LEDs in einem gemeinsamen SMD-Gehäuse (vier Anschlüsse). Das sieht man hier recht gut.

G., -#####o:
 
Die Taster schalten nach Masse (0.0V).
Ja, das habe ich dann später auch noch gesehen. Im folgenden wird bei der 7390 aus einem auf 1 gesetzten GPIO-Bit nämlich der Wert "avm_event_push_button_gpio_low" und aus einer 0 der "..._high"-Wert (register_address ist bei der 7390 NULL), anders als im "else"-Zweig. Der "..._high"-Wert wird in der Folge dann als "button pressed" interpretiert.
Code:
        if(P->register_address == NULL) {
            state = avm_gpio_in_bit(P->gpio) ? avm_event_push_button_gpio_low : avm_event_push_button_gpio_high;
            /*--- DBG_TRC("X%s%uX", P->name, state); ---*/
        } else {
            state = ((*P->register_address >> P->gpio) & 1) ? avm_event_push_button_gpio_high : avm_event_push_button_gpio_low;
        }
Und eine Änderung der Polarität für die Pins mit den Buttons (29+31) habe ich nicht gefunden, damit sind die Buttons doch "low active". Ich finde die passenden 1-Bits aber ohnehin nicht an der entsprechenden Adresse ... dabei würde mich gerade das besonders interessieren, da ich einige Anwendungsfälle für "beide Buttons kurz drücken" in petto hätte und die "Tastensperre" von AVM ja nicht die GPIO-Bits an sich still legt, sondern nur die Auswertung derselben.

Die nicht mit LEDs verbundenen Pins zwischen 16 und 31, die beim Lesen eine 1 liefern, sind 16 (CS1 für NAND-Flash), 20 (WP für NAND-Flash) und 30 (keine Ahnung, was da dran hängt). Das ergibt einen Wert von 0x4011, wenn alle LEDs an sind. Inwieweit es sich bei WP eigentlich um !WP handelt bzw. ob nicht auch das low-active ist, kann man ja mal bei Gelegenheit probieren, aber das ist eine andere Baustelle.

Die Abfrage der Pins für die Buttons erfolgt - nach meinem Verständnis - jedenfalls durch Polling, da wird kein IRQ ausgelöst o.ä. ... insofern verstehe ich es da gerade nicht wirklich, warum ich die gedrückten Buttons in den Werten nicht sehen kann. Eigentlich würde ich einen Wert von 0xE011 erwarten, solange kein Taster gedrückt ist und alle LEDs leuchten. Die Tasten bewirken aber gar keine Änderung des Wertes, also auch keinen 0=>1-Übergang anstelle des erwarteten 1=>0.

Das sind zwei unabgängige LEDs in einem gemeinsamen SMD-Gehäuse (vier Anschlüsse). Das sieht man hier recht gut.
Stimmt, danke für den Tipp. Damit dürfte der Hitzetod durch zu großen Stromfluß über die gemeinsame Kathode eher unwahrscheinlich sein und man kann auch 4 Zustände mit den LEDs signalisieren. Auch wenn die grüne wirklich stark überstrahlt wird von der roten, sieht man im Vergleich zur "rein roten" am anderen Ende der Reihe doch einen Unterschied. Und das Blinken zwischen Rot und Orange (mit "steady red" and "blinking green") ist auch ganz gut zu erkennen ...

Jetzt hätte ich gerne noch eine PWM-Ansteuerung für die LEDs, damit ich die Helligkeit regeln kann. :mrgreen:

EDIT: Wieder daneben gelegen ... die Taster-Pins sind doch beide "IRQ enabled" und zwar an beiden Flanken des Signals, die Polarität steht auch für beide Pins auf "active low". Damit sollte beim Drücken und Loslassen eines Tasters jeweils ein IRQ (Nr. 4) ausgelöst werden und wahrscheinlich komme ich deshalb nicht an die Werte, weil der Handler da vorher dran herumspielt. Also heißt es erst einmal die IRQ-Behandlung zu finden. :)
 
Zuletzt bearbeitet:
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 ...
 
Zuletzt bearbeitet:
Hi

7360SL /proc/devices
240 ifx_gpio

Ich würds ja testen, aber schnallen tu ichs noch nicht.
 
Ich würds ja testen
Script nehmen, oben dann 'hwr_wanted' und 'leds' anpassen (entweder die Pins dort gleich um 32 verringern oder in 'msk=...' die 32 vor dem Shiften abziehen) und einfach testen. Beim Lesen kann nichts passieren ... und Deine Busybox hat ja devmem, wie Du schon geschrieben hast.

Die Belegung für HWRevision 183 habe ich ja oben schon geschrieben. Wenn Deine Box eine andere Revision ist, muß man erst die korrekten Pins raussuchen.
 
Moin

Hab die:
HWRevision 181

Verrat mir bitte dann noch wo ich die Pinbelegung in den Kernel-Quellen finde.
 
HWRevision 181
...
Verrat mir bitte dann noch wo ich die Pinbelegung in den Kernel-Quellen finde.

In einem Freetz-SVN-Baum hier:

source/kernel/ref-vr9-7490_06.10/linux/arch/mips/mach-infineon/vr9/avm_hw_config_hw181.h

Wie die dritte Ebene bei der 7360 SL korrekt heißt, kriegst Du selbst raus ...

EDIT: Sieht bei 181 genauso aus, wie bei 183 ... nur der Name an der LED (Festnetz => DECT) ist wohl anders.
 
Zuletzt bearbeitet:
Gefunden!

/freetz-devel/source/kernel/ref-vr9-7490_06.01/linux-2.6.32/arch/mips/mach-infineon/vr9$ more avm_hw_config_hw181.h
Code:
struct _avm_hw_config AVM_HARDWARE_CONFIG[] = {


    /****************************************************************************************\
     *
     * GPIO Config
     *
    \****************************************************************************************/


    /*------------------------------------------------------------------------------------------*\
     * LEDs / Taster
    \*------------------------------------------------------------------------------------------*/
    {
        .name   = "gpio_avm_led_power",
        .value  = 32,
        .param  = avm_hw_param_gpio_out_active_low,
        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
            .module_id = IFX_GPIO_MODULE_LED,
            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET
        }
    },
    {
        .name   = "gpio_avm_led_power_red",
        .value  = 33,
        .param  = avm_hw_param_gpio_out_active_low,
        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
            .module_id = IFX_GPIO_MODULE_LED,
            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET
        }
    },
    {
        .name   = "gpio_avm_led_internet",
        .value  = 38,
        .param  = avm_hw_param_gpio_out_active_low,
        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
            .module_id = IFX_GPIO_MODULE_LED,
            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET
        }
    },
    {
        .name   = "gpio_avm_led_dect",
        .value  = 35,
        .param  = avm_hw_param_gpio_out_active_low,
        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
            .module_id = IFX_GPIO_MODULE_LED,
            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET
        }
    },
{
        .name   = "gpio_avm_led_wlan",
        .value  = 36,
        .param  = avm_hw_param_gpio_out_active_low,
        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
            .module_id = IFX_GPIO_MODULE_LED,
            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET
        }
    },
    {
        .name   = "gpio_avm_led_info",
        .value  = 47,
        .param  = avm_hw_param_gpio_out_active_low,
        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
            .module_id = IFX_GPIO_MODULE_LED,
            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET
        }
    },
    {
        .name   = "gpio_avm_led_info_red",
        .value  = 34,
        .param  = avm_hw_param_gpio_out_active_low,
        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
            .module_id = IFX_GPIO_MODULE_LED,
            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR | IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET
        }
    },

    /*--- DECT button connected to EXTIN 1 ---*/
    {
        .name   = "gpio_avm_button_dect",
        .value  = 1,
        .param  = avm_hw_param_gpio_in_active_low,
        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
            .module_id = IFX_GPIO_MODULE_LED,
            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN  | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET   | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR
        }
    },
    /*--- WLAN button connected to EXTIN 0 ---*/
    {
        .name   = "gpio_avm_button_wlan",
        .value  = 29,
        .param  = avm_hw_param_gpio_in_active_low,
        .manufactor_hw_config.manufactor_lantiq_gpio_config = {
            .module_id = IFX_GPIO_MODULE_LED,
            .config    = IFX_GPIO_IOCTL_PIN_CONFIG_DIR_IN  | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_SET   | IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_SET
        }
    },
....
Hat wohl die selben Kernel-Sourcen wie die 7490 !?
 
Zuletzt bearbeitet:
Geht! :D

get_led_state.sh (Fritz!Box 7360SL Variante)
Code:
#!/bin/sh
#
# usage: get_led_state <ledname>
# returns 0 for 'off' and 1 for 'on', 127 in case of an error
#
hwr_wanted="181"
leds="power/0 power_red/1 info_red/2 dect/3 wlan/4 internet/6 info/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
#EOF

Test...
Code:
root@deepbase # all_off
root@deepbase # get_led_state.sh wlan;echo $?
0
root@deepbase # all_on
root@deepbase # get_led_state.sh dect;echo $?
1
root@deepbase # get_led_state.sh internet;echo $?
1
root@deepbase # get_led_state.sh info;echo $?
1
root@deepbase # get_led_state.sh internet;echo $?
1
root@deepbase # get_led_state.sh power;echo $?
1
root@deepbase # get_led_state.sh power_red;echo $?
0
root@deepbase # get_led_state.sh info_red;echo $?
0
root@deepbase # led-ctrl filesystem_mount_failure
root@deepbase # get_led_state.sh info_red;echo $?
1
Bei blinkenden LEDs bekommt man mal 1 oder 0, je nachdem ob die LED gerade an oder aus ist.

EDIT: Hab 32 von jeden Wert abgezogen, es funktioniert immer noch.
 
Zuletzt bearbeitet:
Schön ...

Da ich schon seit einiger Zeit mit den LEDs der 7390 und der 7490 den Zustand diverser VPN-Verbindungen signalisiere (ob ich darüber telefoniere, merke ich i.d.R. daran, ob ich ein Telefon in der Hand halte, dafür brauche ich keine LED und auch meine Kunden habe ich inzwischen soweit "erzogen", daß sie den Zustand an den LEDs ablesen können ;)), stelle ich das gerade bei mir so um, daß ich die LED-Anzeige durch die AVM-Software komplett abschalte
Code:
ctlmgr_ctl w box settings/led_display 1
und anschließend die LEDs - quasi "low level" - selbst setze. Somit fummelt mir wenigstens die AVM-Firmware da nicht mehr dazwischen ... bisher habe ich auch immer 'led-ctrl' verwendet, um damit und mit einem passenden Event die LEDs ein- und auszuschalten. Spätestens beim Telefonieren brachte mir die Firmware dann die LEDs meist durcheinander ... damit ist jetzt Schluß. Bei der 7390 bin ich im Prinzip schon fertig, anschließend mache ich mich an das beschriebene Busybox-Applet für VR9-Boxen (erst mal für 7490, aber das dürfte leicht anzupassen sein).

Allerdings würde ich diesen Thread dann verlassen und eher nach "Modifikationen" umziehen wollen, sorry an regn für das "Kapern" ...

EDIT:
koyaanisqatsi schrieb:
#leds="info/1 wlan/3 festnetz/4 power/13 info_red/14 internet/15"
leds="power/32 power_red/33 info_red/34 dect/35 wlan/36 internet/38 info/47"
Das dürfte falsch sein ... oder ? Das sind 32 zuviel pro Wert ... wenn nicht zufällig Deine Shell nur 32-Bit-Zahlen verwendet und auch noch "rotiert" (also die links herausgeschobenen Bits rechts wieder reinholt) oder nur modulo 32 shifted, kann das so eigentlich nicht funktionieren.
Wenn ja, korrigiere bitte, falls jemand später mal Deine Version für die 7360 SL übernehmen will ...
 
Zuletzt bearbeitet:
Yo, sorry regn. ;)

Dieser Thread ist bestimmt eine "schwere" Lektüre geworden.

Die LEDs lassen sich auch so in den Suspend Modus bringen.

Radikal...
Code:
led-ctrl display_suspend
(anscheinend gilt das auch nicht unbedingt für die Info LED)

Lässt noch nachkommende Signalisierungen zu...
Code:
led-ctrl display_suspend_on_idle

Normaler Modus...
Code:
led-ctrl display_wakeup
 
Zuletzt bearbeitet:
Yo, sorry regn. ;)

Dieser Thread ist bestimmt eine "schwere" Lektüre geworden.
Nicht so sehr, ich bin Dipl.Inf und Linux-Fachmann :)
Aber die Antworten gehen an meiner Frage vorbei. Ich wollte nicht "fröhlicher Weihnachtsbaum im Fritz!OS" spielen, sondern wissen, was der Adam2 mit den LED melden will, sofern es da einen Code gibt.
 
was der Adam2 mit den LED melden will, sofern es da einen Code gibt.
Ich behaupte mal kühn (ich habe direkt im ADAM2 aber auch noch keine besonderen Anzeigen - auch nicht bei der 7270v{1,3} - gesehen), daß da nur nach dem Motto "LED funktioniert" einfach mal alle LEDs kurz eingeschaltet werden, auch die rote und grüne parallel bei doppelt ausgestatteten "Slots" im Gehäuse.

In den ersten 5 Sekunden (das ist die EVA-Wartezeit auf FTP-Connects) ist bei mir jedenfalls absolut nichts besonderes zu sehen, speziell auch keine interpretierbaren Anzeigen für das Initialisieren von Komponenten oder ähnliches.
Eine Quelle für weitere Infos (abseits des Disassemblierens der EVA) kenne ich auch nicht, wenn man davon ausgeht, daß das nicht mehr wie beim originalen TI-Loader ist ... aber seitdem back2roots.org down ist, ist es nur noch mit einigen Umwegen möglich, an den Server unter 129.241.210.43 heranzukommen und somit ist auch der Zugriff auf die alten TI-Quellen eher problematisch, wenn man sie nicht "gebunkert" hat. Bei LinkSys ist da wohl noch etwas zu holen und die früheren Versuche der GPL-Firmware für AR7, die auf berlios lagen, sind m.W. jetzt auf Sourceforge zu finden.
Aber da ja auch das GPIO-Kommando auf der seriellen Konsole wohl eine AVM-Erweiterung ist, würde ich nicht einmal darauf wetten, daß da überhaupt gezielt auf die LEDs zugegriffen wird und das Blinken nicht nur durch das Initialisieren der GPIO-Register verursacht wird (obwohl es dafür natürlich zu lange sichtbar ist).

Ansonsten wäre es natürlich nett, wenn AVM der EVA einfach einige Kunststücke mit den LEDs beibringen würde, z.B. mit den grünen LEDs (die meisten Boxen haben ja mind. fünf davon) eine "Restzeit"-Anzeige für möglichen FTP-Connect.
 

Statistik des Forums

Themen
244,695
Beiträge
2,216,692
Mitglieder
371,315
Neuestes Mitglied
jack-mack
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.