Mit welchem Befehl bekomme ich den Status der LEDs angezeigt?

[eisbaerin]

Gibt es eine Möglichkeit sich auf der CLI anzeigen zu lassen, welche LEDs an oder aus sind?

 

[PeterPawn]

Ja und nein.

Bei einigen Modellen kann man das über die Abfrage des Status der GPIO-Pins bewerkstelligen, sofern AVM die notwendigen Interfaces in den Kernel eingebaut hat (pinctrl oder auch die GPIOLib über /sys/class/gpio).

Dann kann man darüber die LEDs sowohl steuern als auch auslesen ... aber es gibt kein einzelnes CLI-Tool und bei anderen Modellen, die ihrerseits die Pins per Multiplexer ansteuern (iirc gehören die GRX-Boxen alle dazu), gibt es m.W. bisher gar keine Möglichkeit ... oder besser formuliert: Dort habe ich bisher noch keine (sinnvolle) Möglichkeit gefunden. Es gibt noch ein paar LED-relevante Module vom jeweiligen Chipset-Hersteller (z.B. "ifx_gpio" bei den VR9-Boxen), aber die werden von AVM nur partiell implementiert und ein Setzen/Auslesen von LEDs ist mir darüber eher selten gelungen.

Eine andere Alternative, sofern die entsprechende Box MMIO (memory mapped I/O) für die GPIO-Pins verwendet (wo Schreiben in bestimmte Speicheradressen dann zu Änderungen des Zustands von GPIO-Pins führt), ist der Versuch mit dem "devmem"-Applet der BusyBox. Dazu muß man aber erst mal ermitteln, an welchem Pin welche LED hängt, wie sie angeschlossen ist (ob "high" (direct) oder "low" (inverted) zum Leuchten der LED führt) und welche Adresse (bis hin zum genauen Bit im Control-Wert) im Speicher für diesen Pin zuständig ist (diese Adressen sind i.d.R. nicht mal zusammenhängend, es gibt "Bänke" von Bits, die für die GPIO-Pins zuständig sind).

Das mit der MMIO funktioniert (iirc) bei der 7390 einwandfrei, inkl. Schreiben, weil das drei verschiedene "Register" im Speicher sind. Bei den VR9-Boxen ist das mit dem Schreiben nicht mehr ohne weiteres möglich (bzw. "riskant", weil es nicht atomar ist, da man den alten Wert lesen, das Bit ändern und den neuen zurückschreiben müßte), aber das Auslesen funktioniert: https://www.ip-phone-forum.de/threads/fritzbox-speziell-7270-die-leds-können-ja-auch-rot-leuchten.271934/post-2025914 ... mit einem eigenen Programm (also ohne "devmem"-Applet, weil das eigene Programm das Lesen, Ändern und Schreiben in einem Rutsch erledigen kann) ist das Schreiben aber auch da wieder machbar; am besten macht man das sogar mit einem eigenen LKM, weil man dann den Zugriff auch "locked" ausführen kann.

Ansonsten steuert AVM vom Rest des Codes aus die LEDs i.d.R. über "events" an ... welche LED dann für welches Event ein- oder ausgeschaltet wird bzw. ob und wie schnell blinkt, organisiert ein Kernel-Module (led_module.ko) und die anderen AVM-Programme kommunizieren mit dem wohl über eine Library im Userspace namens "libled.so(.2)".

Einerseits arbeitet das bei AVM halt als "Stack" (d.h. neuere Ereignisse überlagern die älteren und damit kann - nach dem "Abräumen" eines neueren Ereignisses - auch der vorherige Stand der Anzeige wiederhergestellt werden), was manches erleichtert und andererseits dürfte die Tatsache, daß AVM damals gegen Cybits in dem Punkt "falsche (LED-)Anzeigen" gewonnen hatte (und nur in diesem) sicherlich auch eine Rolle spielen bei der "Geheimniskrämerei", die AVM seit einigen Jahren um die Ansteuerung der LEDs betreibt.

In älteren Versionen gab es noch passende Gerätetreiber (u.a. "/dev/led" oder "/dev/new_led"), die auch ein passendes Interface boten (durch Schreiben bestimmter Werte), um vom Userspace aus mal eine LED ein- oder auszuschalten. Das geht heute nur noch über "led-ctrl", wozu man sich erst mal passende Events suchen muß für die LED, die man gerne ändern möchte und ein Auslesen der aktuellen Anzeige ist darüber auch nicht möglich.

Bei einigen Modellen gibt es auch noch einen AVM-Treiber für die GPIO-Pins, der ein "procfs" dafür bereitstellt (unter "/proc/avm/gpio") ... darüber kann man (wenn der Kernel das überhaupt enthält) auch den Zustand von Pins ändern, aber nichts auslesen (die "read"-Funktion ist schlicht nicht implementiert).

Um mal ein Beispiel zu machen ... nehmen wir mal die 6490. Da hat AVM das zuletzt erwähnte Interface (im "procfs") implementiert und man muß nur ermitteln, welcher Pin welche LED steuert. Das steht u.a. in der Hardware-Beschreibung:

vidar:/home/FritzBox/FB6490/ATOM/GPL/linux-2.6.39 $ grep -A 2 led arch/arm/mach-avalanche/puma6/avm_hw_config_hw199a.h
        .name   = "gpio_avm_led_power",
        .value  = 92,
        .param  = avm_hw_param_gpio_out_active_low,
--
        .name   = "gpio_avm_led_info_red",
        .value  = 93,
        .param  = avm_hw_param_gpio_out_active_low,
--
        .name   = "gpio_avm_led_internet",
        .value  = 101,
        .param  = avm_hw_param_gpio_out_active_low,
--
        .name   = "gpio_avm_led_dect",
        .value  = 91,
        .param  = avm_hw_param_gpio_out_active_low,
--
        .name   = "gpio_avm_led_wlan",
        .value  = 102,
        .param  = avm_hw_param_gpio_out_active_low,
--
        .name   = "gpio_avm_led_info",
        .value  = 104,
        .param  = avm_hw_param_gpio_out_active_low,
vidar:/home/FritzBox/FB6490/ATOM/GPL/linux-2.6.39 $

Wie man sieht (active_low), sind die LEDs über einen Inverter angeschlossen, man muß also zum Einschalten den Pin auf "0" setzen. Das geht hier (mit dem AVM-Treiber) auch wieder ganz simpel, indem man einfach ein "set <pin> <val>" an "/proc/avm/gpio" ausgibt. Das gibt keine weitere Quittung, nur die LED ändert ihren Zustand. Will man die nun blinken lassen, muß man das über die entsprechende Abfolge von Kommandos selbst organisieren.

Da die 6490 parallel auch noch das generelle Kernel-Interface für GPIO-Pins bietet (gpiolib), kann man den Zustand darüber allerdings auch abfragen (und auch setzen, wenn man will). Dazu braucht man auch nur die Pin-Nummer und muß diesen dann erst einmal "exportieren", damit die passenden Nodes im "sysfs" angelegt werden:

~ # ls -l /sys/class/gpio/
--w-------    1 root     root          4096 Jul 17 10:45 export
lrwxrwxrwx    1 root     root             0 Nov  7  2000 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx    1 root     root             0 Nov  7  2000 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx    1 root     root             0 Nov  7  2000 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx    1 root     root             0 Nov  7  2000 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w-------    1 root     root          4096 Jul 17 10:49 unexport
~ # echo 93 >/sys/class/gpio/export
~ # ls -l /sys/class/gpio/
--w-------    1 root     root          4096 Jul 17 10:49 export
lrwxrwxrwx    1 root     root             0 Jul 17 10:49 gpio93 -> ../../devices/virtual/gpio/gpio93
lrwxrwxrwx    1 root     root             0 Nov  7  2000 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx    1 root     root             0 Nov  7  2000 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx    1 root     root             0 Nov  7  2000 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx    1 root     root             0 Nov  7  2000 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w-------    1 root     root          4096 Jul 17 10:49 unexport
~ # ls -l /sys/class/gpio/gpio93/
-rw-r--r--    1 root     root          4096 Jul 17 10:50 active_low
-rw-r--r--    1 root     root          4096 Jul 17 10:50 direction
-rw-r--r--    1 root     root          4096 Jul 17 10:50 edge
-rw-r--r--    1 root     root          4096 Jul 17 10:50 multi
drwxr-xr-x    2 root     root             0 Jul 17 10:50 power
lrwxrwxrwx    1 root     root             0 Jul 17 10:49 subsystem -> ../../../../class/gpio
-rw-r--r--    1 root     root          4096 Jul 17 10:49 uevent
-rw-r--r--    1 root     root          4096 Jul 17 10:50 value
~ #

Mit dem "export" kommt also "gpio93" dazu und da kann man jetzt die Eigenschaften des GPIO-Pins auslesen/ändern. Ändern sollte man aber im Falle der FRITZ!Box nur "value" (der Rest stimmt auch nur, wenn man ihn zuvor selbst dort initialisiert hat) - beim Rest sollte man schon sehr, sehr genau wissen, was man da eigentlich macht. Wenn man auch über das "sysfs"-Interface schreiben will, muß man zuvor noch die korrekte Richtung über das "direction"-File einstellen (das wäre dann "out"), ansonsten kann man "value" nicht beschreiben. Diese "Verrenkung" kann man sich sparen, wenn man die Interfaces kombiniert und - sofern vorhanden - über das "procfs"-Interface des AVM-Treibers für die GPIO-Pins die Änderungen vornimmt.

Ich habe mal das Shell-Skript, mit dem ich schon länger die LEDs der 6490 auch ohne das AVM-Module kontrolliere (bei der 6490 sind die Interfaces dafür eben vorhanden) in mein Repo eingecheckt (im Unterverzeichnis "led") und es zuvor noch etwas "aufgehübscht" für potentielle Interessenten ... vielleicht kann es ja jemand nachnutzen. Dabei habe ich es gleich noch auf alle Puma6-Geräte von AVM erweitert, denn nach der Hardware-Beschreibung in den Kernel-Quellen nutzen die alle dieselben GPIO-Pins für die LEDs. Damit vereinfacht sich das wieder einigermaßen ... will man z.B. dreimal alle LEDs für jeweils 2 Sekunden blinken lassen, ginge das so:

#! /bin/sh
led=/var/media/ftp/pentest/led
org="$($led states)"
set -- $org
on=""
off=""
while [ -n "$1" ]; do
        on="${on}${on:+ }on"
        off="${off}${off:+ }off"
        shift
done
$led wyatt_earp
for i in 1 2 3; do
        $led restore $on
        sleep 2
        $led restore $off
        sleep 2
done
$led restore $org

Allerdings ist das nicht allzu schnell und daher sieht man bei diesem "Blinken" dann schon recht deutlich, daß die LEDs alle einzeln gesteuert werden ... daher ist ein "Laufband" fast besser zu organisieren (ich habe mal noch eine Angabe, welche LED sich wo befindet in der Reihe, dazugepackt).

Der Rest der Ansteuerlogik für die LEDs ist bei AVM halt "closed source" und darf deshalb nicht einfach weitergegeben werden (jedenfalls nicht einzeln) ... daher muß man von Box zu Box (bzw. Prozessor zu Prozessor) schauen, wie man die LEDs am besten ansteuert.

Meine Ansätze, das wieder in einem gemeinsamen Skript zusammenzufassen für mehrere Architekturen und Modelle, sind leider noch nicht "spruchreif".

 

[eisbaerin]

Ich danke dir für deine ausführliche Antwort! Die muß ich erst noch in Häppchen verdauen.
Das es so schwierig ist, hätte ich nicht gedacht.
Ist das auch der Grund, warum AVM die LEDs nicht in der GUI anzeigt, wie es bei anderen Geräten üblich ist?
Das wäre ein Wunsch von mir an AVM.

 

[PeterPawn]

Ist das auch der Grund, warum AVM die LEDs nicht in der GUI anzeigt, wie es bei anderen Geräten üblich ist?

Das weiß ich nicht ... eigentlich ist es ja auch nicht wirklich schwierig, nur dann, wenn man es bei verschiedenen Prozessoren "einheitlich" will. AVM könnte das problemlos regeln ... nur könnten andere dann solch eine Schnittstelle zur Abfrage der aktuellen Anzeige wohl auch nutzen und erst recht dann, wenn's auch ums Setzen von Anzeigen geht und das darüber möglich sein sollte.

Wie bereits angemerkt, hat AVM gegen Cybits genau in dem Punkt mit der falschen Anzeige "gewonnen" (https://fsfe.org/activities/ftf/lg-urteil-20111118.pdf):

[...] wird die Beklagte verurteilt, es [...] zu unterlassen, durch die Software „Surf-Sitter DSL" dergestalt auf die [...] DSL-Router [...] einzuwirken, dass auf der Konfigurationsoberfläche der Router der Klägerin nach Installation von Surf-Sitter DSL
a) das Nichtbestehen einer Internetverbindung auch dann angezeigt wird, wenn eine Internetverbindung besteht
und/oder
b) die nicht mehr aktive Kinderschutzfunktion der Router der Klägerin als aktiv angezeigt wird, [...]

Angesichts der Kostenteilung zu 1/5 für Cybits und 4/5 für AVM kann man zwar ermessen, wie "bedeutend" diese Punkte insgesamt waren, aber man kann seitdem auch konstatieren, daß ältere Versionen der Ansteuerung der LEDs von AVM konsequent aus der Software entfernt wurden (z.B. diese hier: https://web.archive.org/web/20130927055352/http://www.wehavemorefun.de/fritzbox/New_led) ... das kann man zwar auch mit neuen Möglichkeiten begründen, aber das erklärt ja noch nicht, warum andere, bereits existierende Interfaces parallel dazu verschwunden sind.

Auch der Zeitpunkt der Umbenennung der Firmware in "FRITZ!OS" (Anfang 2012) paßt irgendwie zum - wenn man ehrlich ist, ja in Wahrheit verlorenen - Prozess und logischerweise ist das meinerseits eine reine Vermutung, was AVM da wohl bewogen hat (und heute noch bewegt).

---------------------------------------------------------------------------------------------------------------------

So eine Anzeige "nachzurüsten", ist an manchen Stellen tatsächlich einfach ... ich hatte das in der alten Oberfläche mal realisiert bis inkl. 7390 (das war dann so 2014, also die Zeit, aus der der andere Thread zu den LEDs stammt). Für die 7490 habe ich das nie nachgezogen (die gab's noch nicht lange genug bzw. ich hatte damals die einzige von den Boxen, die ich "in Betreuung" hatte/habe, selbst und da konnte ich auch auf die Box schauen und brauchte die Anzeige im GUI nicht, im Gegensatz zu den entfernt aufgestellten Boxen.

Da diese Aufgabe ja auch aus zwei Teilen besteht (einmal das Auslesen, einmal die Anzeige), kann man das aber auch unabhängig voneinander entwickeln und muß sich nur auf ein definiertes Interface zwischen diesen Teilen "verständigen". Am einfachsten wäre wohl eine Lua-Library (aber eine vorkomplierte, wie z.B. die "libluadsl" von AVM), die könnte entweder selbst aus dem Userspace versuchen, irgendetwas auszulesen oder man stellt ihr noch ein kleines LKM beiseite, was direkt aus dem Kernel liest und das Ergebnis über ein procfs-Interface bereitstellt.

[ Ich muß mal suchen, ob ich die ersten Ansätze der Neuimplementierung nach dem AVM-Wechsel beim GUI - aus denen dann auch die andere Datei im "led"-Unterverzeichnis entstand - noch irgendwo finden kann. ]

Wichtig wäre halt, daß das Auslesen die Auslieferung der restlichen Daten nicht wesentlich verlangsamt (dauert bei meiner 7490 jetzt schon ~1,5 Sekunden) ... dann könnte man das sogar in deutlich kürzeren Intervallen aktualisieren, als die derzeit 20 Sekunden, die (iirc) vom AVM-GUI verwendet werden. Wenn da eine Antwort in 0,5 Sekunden oder so ähnlich erfolgt, kann man das auch alle fünf Sekunden auffrischen oder sogar noch öfter.

 

[koyaanisqatsi]

Moinsen

Bei einigen Modellen gibt es auch noch einen AVM-Treiber für die GPIO-Pins, der ein "procfs" dafür bereitstellt (unter "/proc/avm/gpio") ... darüber kann man (wenn der Kernel das überhaupt enthält) auch den Zustand von Pins ändern, aber nichts auslesen (die "read"-Funktion ist schlicht nicht implementiert).

Bei meiner 7590 mit FRITZ!OS 07.11-69922 Inhaus gibts in /proc/avm/gpio neben set auch list und bei list mit cat angezeigt kommt...

0: mux=0 gpio                          drive 2 mA OUT 1
1: mux=0 gpio                          drive 2 mA IN  1
2: mux=0 gpio                          drive 2 mA IN  1
3: mux=0 gpio                          drive 2 mA IN  1
4: mux=1 LED_ST                        drive 2 mA OUT 0
5: mux=1 LED_D                         drive 2 mA OUT 0
6: mux=1 LED_SH                        drive 2 mA OUT 0
7: mux=1 CLKOUT1                       drive 2 mA OUT 0
8: mux=0 gpio                          drive 2 mA OUT 1
9: mux=0 gpio                          drive 2 mA OUT 1
10: mux=0 gpio                          drive 2 mA IN  0
11: mux=0 gpio                          drive 2 mA IN  0
13: mux=1 NAND_ALE                      drive 2 mA OUT 0
14: mux=0 gpio                          drive 2 mA IN  1
15: mux=0 gpio                          drive 2 mA OUT 1
16: mux=0 gpio                          drive 12 mA OUT 1
17: mux=0 gpio                          drive 12 mA OUT 1
18: mux=0 gpio                          drive 12 mA OUT 1
19: mux=0 gpio                          drive 12 mA IN  1
21: mux=0 gpio                  PU      drive 12 mA IN  1
22: mux=0 gpio                  PU      drive 12 mA IN  1
23: mux=1 NAND_CS1                      drive 12 mA OUT 0
24: mux=1 NAND_CLE                      drive 12 mA OUT 0
28: mux=3 TDM_FSC               PU      drive 12 mA IN  0
29: mux=3 TDM_DO                PU      drive 12 mA OUT 0
30: mux=3 TDM_DI                PU      drive 2 mA IN  0
31: mux=3 TDM_DCL               PU      drive 2 mA IN  0
32: mux=0 gpio                          drive 2 mA IN  1
33: mux=1 MDC (PAE)       OD            drive 2 mA OUT 0
34: mux=0 gpio                          drive 2 mA OUT 1
35: mux=0 gpio                  PU      drive 2 mA IN  1
36: mux=0 gpio                          drive 2 mA IN  1
42: mux=1 MDIO (GSWIP-L)  OD            drive 2 mA OUT 0
43: mux=0 gpio            OD            drive 2 mA OUT 0
48: mux=1 NAND Ready_Busy               drive 2 mA IN  0
49: mux=1 NAND_RE                       drive 2 mA OUT 0
50: mux=1 NAND_D1                       drive 2 mA OUT 0
51: mux=1 NAND_D0                       drive 2 mA OUT 0
52: mux=1 NAND_D2                       drive 2 mA OUT 0
53: mux=1 NAND_D7                       drive 2 mA OUT 0
54: mux=1 NAND_D6                       drive 2 mA OUT 0
55: mux=1 NAND_D5                       drive 2 mA OUT 0
56: mux=1 NAND_D4                       drive 2 mA OUT 0
57: mux=1 NAND_D3                       drive 2 mA OUT 0
59: mux=1 NAND_WE                       drive 2 mA OUT 0
60: mux=1 NAND_WP                       drive 2 mA OUT 0
61: mux=1 NAND_SE                       drive 2 mA OUT 0

Ist hier zufällig der aktuelle Zustand erkennbar ?
...oder ist das nur der GPIO-Plan ?

 

[PeterPawn]

Bei der 7590 weiß ich gar nicht, wie die LEDs angesteuert werden ... da die ja wohl dimmbar sind, ist da noch mehr Elektronik verbaut, als nur ein Transistor, ein Widerstand (oder auch ein paar mehr, je nach Schaltung) und eben die LED, die an den GPIO-Pin angeschlossen sind.

Vermutlich wird die Helligkeit der LEDs mit Pulsweitenmodulation (PWM) beeinflußt - dabei ist das Signal nicht die gesamte Zeit "high" (oder "low" oder nennen wir es besser "sie leuchtet"), sondern wird nur einen Bruchteil der gesamten Zeit - quasi als Rechtecksignal mit meist kurzer Amplitude (high) und längerer Auszeit (low) - entsprechend gesetzt.

Solange man das nicht wirklich per Software und Timer überwachen will, gibt es dafür passende Ansteuer-Chips (z.B. den TL494 von TI) ... ich würde bei der 7590 daher eher erwarten, daß die gar nicht mehr ganz simpel per GPIO-Pin die LEDs ansteuert (höchstens noch als generelles "enable"-Signal für die LED), sondern eher über einen programmierbaren Wert, der u.a. die Helligkeit der LED regelt. Allerdings sprechen Teile der Hardware-Beschreibung auch dagegen ... kommt ich gleich noch mal zu.

Jedoch weiß ich ebenfalls nicht, ob die (auch intern) alle nur auf einem Schlag oder doch einzeln gedimmt werden können ... ich habe mich noch nicht mit dem PCB der 7590 befaßt. Müßte ich anhand der Kernel-Quellen raten, würde ich sagen, daß die nicht einzeln dimmbar sind.

Außerdem ist der GPIO-Treiber von AVM bei der 7590 (bei der 7580 ebenfalls) schon wieder ein anderer als bei der 6490 (und bei der 7490 gibt es diesen Treiber gar nicht erst, zumindest nicht im AVM-Kernel) ... bei der 6490 gibt es dort die zwei Pseudo-Files "set" und "list" gar nicht und der Treiber wird direkt über die Ausgabe von "set x y" als Text nach "/proc/avm/gpio" gesteuert (so, wie es halt im Shell-Skript steht) ... ein "list" ist da gar nicht verbaut und die "read"-Funktionen im "procfs"-Interface laufen auch nur auf ein "return NULL" hinaus.

Bei der 7590 sieht die Definition der LEDs im FDT (das ist die "Hardware-Beschreibung" der Box, die der Bootloader an den Kernel übergibt) dann normalerweise so aus:

    avm-gpio{
        /*--- SSO/Shiftregister-LEDs enumerated by gpiochip_add() as GPIO 248...255 (Reihenfolge 0...7 ist invertiert!) ---*/
        compatible = "avm,avm_gpio_generic";
        gpio_avm_led_pwm_duty_50{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
            value = <248>;
        };
        gpio_avm_led_power{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
            value = <255>;
        };
        gpio_avm_led_wlan{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_HIGH>;
            value = <252>;
        };
        gpio_avm_led_internet{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_HIGH>;
            value = <253>;
        };
        gpio_avm_led_connect{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_HIGH>;
            value = <254>;
        };
        gpio_avm_led_info_red{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_HIGH>;
            value = <251>;
        };
        gpio_avm_led_info{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_HIGH>;
            value = <250>;
        };
        gpio_avm_led_temp_ctrl_1{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_HIGH>;
            value = <249>;
        };
        gpio_avm_led_temp_ctrl_2{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_HIGH>;
            value = <248>;
        };
        gpio_avm_led_strobe{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
            function = <AVM_DEF_HW_FUNCTION_PINMUX1>;
            value = <4>;
        };
        gpio_avm_led_data{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
            function = <AVM_DEF_HW_FUNCTION_PINMUX1>;
            value = <5>;
        };
        gpio_avm_led_shift{
            param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
            function = <AVM_DEF_HW_FUNCTION_PINMUX1>;
            value = <6>;
        };
        gpio_avm_led_output_enable{
            function = <AVM_DEF_HW_FUNCTION_GPIO_PIN>;
            default_state = <1>;
            value = <43>;
        };
        gpio_avm_led_ambient_int{
            /*--- param = <AVM_DEF_HW_PARAM_GPIO_IN_ACTIVE_LOW>; ---*/
            value = <33>;
        };
        gpio_avm_button_dect{
            param = <AVM_DEF_HW_PARAM_GPIO_IN_ACTIVE_LOW>;
            value = <32>;
        };
        gpio_avm_button_wlan{
            param = <AVM_DEF_HW_PARAM_GPIO_IN_ACTIVE_LOW>;
            value = <2>;
        };
        gpio_avm_button_connect{
            param = <AVM_DEF_HW_PARAM_GPIO_IN_ACTIVE_LOW>;
            value = <1>;
        };
        gpio_avm_dect_reset{
            /*--- param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>; ---*/
            value = <0>;
        };
        gpio_avm_dect_rd{
            /* temporaer */
            /*--- param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>; ---*/
            value = <35>;
        };
        gpio_avm_pcmlink_fsc{
            /*--- param = <AVM_DEF_HW_PARAM_NO_PARAM>; ---*/
            value = <28>;
        };
        gpio_avm_pcmlink_do{
            /*--- param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>; ---*/
            value = <29>;
        };
        gpio_avm_pcmlink_di{
            /*--- param = <AVM_DEF_HW_PARAM_NO_PARAM>; ---*/
            value = <30>;
        };
        gpio_avm_pcmlink_dcl{
            /*--- param = <AVM_DEF_HW_PARAM_NO_PARAM>; ---*/
            value = <31>;
        };
                gpio_avm_piglet_noemif_prog{
                        /*--- param = <AVM_DEF_HW_PARAM_NO_PARAM>; ---*/
                        value = <17>;
                };
                gpio_avm_piglet_noemif_clk{
                        /*--- param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_HIGH>; ---*/
                        value = <15>;
                };
                gpio_avm_piglet_noemif_data{
                        /*--- param = <AVM_DEF_HW_PARAM_NO_PARAM>; ---*/
                        value = <18>;
                };
                gpio_avm_piglet_noemif_done{
                        /*--- param = <AVM_DEF_HW_PARAM_GPIO_IN_ACTIVE_LOW>; ---*/
                        value = <36>;
                };
                gpio_avm_piglet_noemif_40mhz{
                        /*--- param = <AVM_DEF_HW_PARAM_NO_PARAM>; ---*/
            function = <AVM_DEF_HW_FUNCTION_PINMUX1>;
                        value = <7>;
                };
        gpio_avm_piglet_noemif_te_found{
                        /*--- param = <AVM_DEF_HW_PARAM_NO_PARAM>; ---*/
                        value = <42>;
                };
        gpio_avm_usb_power_enable{
            /*--- param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_HIGH>; ---*/
            value = <34>;
        };
        gpio_avm_usb_fault_detect{
            /*--- param = <AVM_DEF_HW_PARAM_GPIO_IN_ACTIVE_LOW>; ---*/
            /*--- value = <4>; ---*/
        };

Das wirkt ja schon mal "vogelwild" ... die LEDs sind an den (wohl "virtuellen", da nur über einen zusätzlichen Multiplexer erreichbaren) Pins 248-255 angeschlossen und zu allem Überfluß wäre - wenn die Beschreibung stimmt - 248 auch noch doppelt belegt (1x als "gpio_avm_led_temp_ctrl_2" und 1x als "gpio_avm_led_pwm_duty_50". Schon da zweifele ich an der Richtigkeit der Angaben - zu allem Überfluß soll "Power" auch noch "low active" sein, während der Rest "high active" ist. Allerdings liegen wenigstens wieder "LED_STROBE", "LED_DATA" und "LED_SHIFT" (das dürfte irgendein Schieberegister für automatisches Blinken sein, wenn ich raten soll) auf den Pins 4, 5 und 6, wie es auch der "list"-Ausgabe des GPIO-Treibers entspricht.

Zumindest scheint auch der Großteil der Pins bei der Richtung noch zu stimmen ... hinter Pin 0 hängt wohl das RST-Signal für den DECT-Chip und das ist - zumindest nach der Beschreibung - wohl "low active", was darauf hindeuten könnte, daß die Ausgabe einer "0" an diesen Pin zum Reset für den DECT-Chip führt. Die "1" in der letzten Position in der Zeile für den Pin könnte dann tatsächlich der aktuelle Zustand sein ... das könnte man für den "connect"-Button (ist wohl "WPS") ja mal ausprobieren, denn dann müßte eigentlich (während der gedrückt ist) der Pin 1 von der derzeitigen "1" ebenfalls auf "0" gehen (auch der ist ja "low active").

Ich habe bisher noch keinen richtigen Bock gehabt, mich auch bei den GRX-Boxen eingehender mit der Frage zu befassen, wie das Multiplexing realisiert ist, daß die LEDs (eben auch bei der 7580 ohne Dimmen) auf diese Pin-Zuweisungen kommen. Vielleicht weiß es ja jemand anderes, der (a) die Box besitzt und (b) sich mit dem Thema befaßt hat. Immerhin sollte zumindest der GPIO-Treiber von AVM auch in den Kernel-Quellen enthalten sein ... denn der ist kein LKM und wird "fest verlinkt", soweit ich weiß - damit muß AVM den auch unter GPLv2 stellen und mitliefern. Aber grau ist bekanntlich alle Theorie, denn dasselbe gilt natürlich auch für den "avm_kernel_config"-Bereich und wie wir alle wissen, weigert sich AVM an dieser Stelle beharrlich, die vollständigen Quellen zu veröffentlichen.

 

[eisbaerin]

da die ja wohl dimmbar sind

Ja, und das sogar abhängig vom Umgebungslicht.
Da fällt mir ja gleich die nächste Frage ein:
Wo kann ich bei der 7590 die Umgebungshelligkeit auslesen?

 

[PeterPawn]

Wo kann ich bei der 7590 die Umgebungshelligkeit auslesen?

Es ist für mich nicht mal zwingend, daß der Wert tatsächlich ausgelesen werden kann. Wenn da einfach nur ein photoelektrisches Element (was auch immer das für eines sein mag, vom einfachen Widerstand über die Diode bis zum Transistor) die maximale Spannung bei 100% PWM-Tastverhältnis entsprechend verringert (halt nicht bis 0 V, aber eben analog zur Umgebung - meinetwegen zwischen 50% und 100%) oder auch das Tastverhältnis selbst, dann reicht für diese Regelschaltung am Ende auch ein einfaches "enable"-Signal (wenn das überhaupt konfigurierbar ist mit der Abhängigkeit?) ... irgendwie klingt für mich die Beschreibung des ersten GPIO-Pin (gpio_avm_led_pwm_duty_50) im FDT ein wenig in diese Richtung.

Aber das ist tatsächlich meinerseits alles Kaffeesatzlesen ... das basiert nur darauf, daß ich selbst halt so etwas mit Abhängigkeit vom Umgebungslicht nicht per Software steuern würde. Wie verhält sich die 7590 eigentlich beim Start? Der Bootloader wird vermutlich noch keine passende Ansteuerung bzw. keine Einstellmöglichkeiten haben ... sind die LEDs da immer bei 100%? Wenn ja, müßte das ja auch beim Start des Systems deutlich zu sehen sein ... wenn von 100% auf irgendetwas kleineres geregelt wird, sowie der LED-Treiber initialisiert ist (vorher wäre das halt "komisch"), sollte man diesen Zeitpunkt ja gut sehen können (immer vorausgesetzt, der Unterschied ist groß genug).

Wenn die Abhängigkeit vom Umgebungslicht wirklich per Elektronik realisiert ist und nicht per Software und bereits im Bootloader aktiviert ist (weil der die Pins passend setzt, notfalls kann man vielleicht mit dem "gpio"-Kommando auch noch nachhelfen von der Seriellen), müßte man das ja auch mit der Taschenlampe beeinflussen können, solange die Box in EVA herumsteht (und da blinkt die 7590 wohl ebenso vor sich hin, wie praktisch alle anderen Modelle).

 

[koyaanisqatsi]

Mit gültiger SID: data.lua?data=...&sid=...

( Es muss aber ein POST und darf kein GET sein )
Wobei wir letztens in Python einem Dictionary ( für data= ) für eine 7590 folgendes hinzufügen mussten...

# HTTP(S) Post request body content
datadict = {'xhr': 1,
        'led_brightness': options[4], #[int] 1 (dark), 2 (medium) and 3 (bright)
        'environment_light': options[5], #[str] 'on' or 'off'
        'led_display': options[3], #[int] 0 (activate) or 2 (deactivate)
        'apply': '',
        'sid': sid, #[str]
        'lang': 'de',
        'page': 'led'}

...es ist Rückwärtskompatibel zu anderen Modellen ohne Dimm/Umgebung Funktion, soll heissen: Der Parser ignoriert unbekannte Optionen, aber nicht zu Wenige
Konkret: Bei der 7590 ging zwar das Deaktivieren der LEDs ohne DIMM/Umgebungs Optionen, aber nicht das Aktivieren, da werden sie wohl zwingend benötigt.

Wie verhält sich die 7590 eigentlich beim Start? Der Bootloader wird vermutlich noch keine passende Ansteuerung bzw. keine Einstellmöglichkeiten haben ... sind die LEDs da immer bei 100%? Wenn ja, müßte das ja auch beim Start des Systems deutlich zu sehen sein

Ja, Umgebung/DIMM/Deaktiviert kommt nach EVA und vor dem Einschalten des WLAN

das könnte man für den "connect"-Button (ist wohl "WPS") ja mal ausprobieren, denn dann müßte eigentlich (während der gedrückt ist) der Pin 1 von der derzeitigen "1" ebenfalls auf "0" gehen (auch der ist ja "low active").

Mehrere 'diff's ergaben nach "Connect" leider nur eine 0.
Während der gesamten 2 Minuten geblinke.
...da hat sich nichts verändert.