fischertechnik community forum

Hallo zusammen,

ich mach hier mal auch einen eigenen Thread für das Thema aus viewtopic.php?f=8&t=3429&start=660#p27127 auf.

Kurze Zusammenfassung: Der TXT hat eine eingebaute Echtzeituhr, die auch weiterläuft wenn der TXT ausgeschaltet ist (sie läuft sogar weiter, wenn der TXT komplett von der Versorgungsspannung getrennt ist - dafür ist die Knopfzelle unter der Klappe im Boden vom TXT da). Und diese Echtzeituhr kann - wie Raphael herausgefunden hat - den TXT zu einem vorher festgelegten Zeitpunkt automatisch anschalten.

Leider hat(te) die Sache einen Haken: Wenn man das einfach so macht, dann kann man den TXT nicht mehr per Software abschalten (siehe ebenfalls viewtopic.php?f=8&t=3429&start=660#p27127) - zumindest so lange nicht, bis man ihn einmal nicht nur von der "normalen" Stromversorgung getrennt hat sondern auch die Knopfzelle unten im Boden entfernt hat (@Raphel: Falls Dein TXT noch "klemmt": Das hilft dann aber auch zuverlässig).

Das ist natürlich kein Zustand, den man auf Dauer dulden kann. Vor allem nicht, weil so ein Autostart eigentlich ein cooles Feature ist.

Und deswegen gibt es jetzt - nach knapp zwei Tagen Dokumentation, Schaltpläne, Datenblätter und Kenrel-Sourcen studieren (und einigem Nachgrübeln darüber, wieso Poweroff per Software auf dem TXT überhaupt funktionieren kann ) - mit https://github.com/ftCommunity/ftcommun ... 03e52dde86 den passenden Patch für die Community-Firmware. Damit klappt dann auch das Abschalten nach einem automatischen Start wieder so wie es soll

richard.kunze hat geschrieben: Und diese Echtzeituhr kann - wie Raphael herausgefunden hat - den TXT zu einem vorher festgelegten Zeitpunkt automatisch anschalten.

Das ist doch mal ein cooles Feature !

richard.kunze hat geschrieben: Damit klappt dann auch das Abschalten nach einem automatischen Start wieder so wie es soll

Super !

Torsten

Was war denn an dem Ausschalten knifflig? Der rtc zieht gegen den Pullup in der Selbsthaltung das Enable-Signal gegen Masse. Damit gehen die 5v aus. Oder ist da noch ein Trick dabei?

Aber sehr cooles Feature und prima, dass Raphael Dich gezwungen hat, die Detaols rauszufinden Jetzt muss der ftc-user noch Zugriff auf den rtc bekommen (wenn er's nicht eh schon hat) und dann waere die Frage, wie man das elegant nutzt. Waere ja toll, wenn dann z.B. die App, die das ausgeloest hat, auch beim automatischen reboot wieder aktiv wird.

richard.kunze hat geschrieben: Und deswegen gibt es jetzt überhaupt funktionieren kann ) - mit https://github.com/ftCommunity/ftcommun ... 03e52dde86 den passenden Patch für die Community-Firmware. Damit klappt dann auch das Abschalten nach einem automatischen Start wieder so wie es soll

Perfekt!!! Ich wäre ja dafür, dass wir ein CI-System nutzen, um jedem schnellstmögliche (ca. 6h) tests machen zu können. So könnte ich jetzt das neue Feature besser einbauen.

Ich würde für das RTC Zeugs schnell eine neue App schreiben, damit jeder das Feature nutzen kann.
In der RCs müssten wir mal noch die RTC1 schreiben, damit der TXT auch passend starten kann, weil out of WLAN ist die Uhrzeit falsch, wenn man sie nicht vorher eingestellt hat. Oh, generell: in der nächsten Version meiner Settings-App wird man auch die Zeit einstellen können. Kann man sudoers beibringen, dass alles (oder nur Bestimmtes), was von einem bestimmten Script gemacht wird, erlaubt ist?

Raphael

MasterOfGizmo hat geschrieben:Was war denn an dem Ausschalten knifflig? Der rtc zieht gegen den Pullup in der Selbsthaltung das Enable-Signal gegen Masse. Damit gehen die 5v aus. Oder ist da noch ein Trick dabei?

Hä? Meine Ansicht: Also Normal macht der Taster oder die RTC die 5v an, die sich dann selbst halten. Der Taster löst zudem noch den Bootvorgang aus. Das Abschalten erfolgt über den Pin, der vom CPU kommt, und dann via Transistor den Enable-Pin auf Masse zieht.

MasterOfGizmo hat geschrieben:prima, dass Raphael Dich gezwungen hat, die Detaols rauszufinden

Das mit dem Linux patch hätte ich nicht geschafft. Also Danke an Richard.

MasterOfGizmo hat geschrieben:Wäre ja toll, wenn dann z.B. die App, die das ausgelöst hat, auch beim automatischen reboot wieder aktiv wird.

Gute Idee. Allgemein würde ich einen Autostart gerne einbauen. Das kann man ja einfach mit einem Hintergrunddienst machen, der ne Telnetverbindung aufbaut.

Raphael

ski7777 hat geschrieben:Das Abschalten erfolgt über den Pin, der vom CPU kommt, und dann via Transistor den Enable-Pin auf Masse zieht.

Äh, ja, klar, das meinte ich auch. CPU, nicht RTC, Du hast Recht.

ski7777 hat geschrieben: Gute Idee. Allgemein würde ich einen Autostart gerne einbauen. Das kann man ja einfach mit einem Hintergrunddienst machen, der ne Telnetverbindung aufbaut.

Hab' ich nicht ganz verstanden und klintg auch recht aufwändig. Diejenige Komponente, die Programme startet ist ja der Launcher. Also ist das eigentlich dessen Aufgabe. Im Hintergrund muss da m.E. nichts laufen. Dementsprechend w#re es m.E. auch sinnvoll, wenn der Launcher auch den Wakeup setzt und den Powerdown einleitet. Das meiste davon kann er ja eh schon.

Wann geht denn das Wake-Signal zurück? Ich nehme an. dass man das im RTC quittieren muss, oder? Wenn man dessen aktuellen Zustand auch abfragen kann, dann könnte der Launcher (oder wer auch immer) daran erkennen, dass der Reboot vom RTC ausgelöst wurde. Denn mal angenommen, der TXT ist so programmiert, nach einer Stunde automatisch aufzuwachen, weil App XYZ das ausgelöst hat und jemand startet den TXT nach einer halben Stunden per Hand, dann soll ja die App XYZ nicht unbedingt automatisch gestartet werden. Richard, ich habe in Deinen Patch nicht im Detail reingechaut, aber kann es sein. dass Du genau diese Bestätigung gerade automatisiert hast? Hat eine App trotzdem eine Chance, die Tatsache zu erkennen, dass der RTC den Strom eingeschaltet hat?

Der zweite Spezialfall tritt auf, wenn der RTC das Wake-Signal betätigt, der TXT aber schon an ist. Das INT1-Singal des PMIC ist zusätzlich auf den SPI_CS1-Pin des Sitara gelegt. Wenn man über den Pin einen INterrupt auslösen kann, dann könnte man das Linux-seitig zu einem Input-Event machen, wie z.B. den Power-Button. Dann würde der Launcher das merken und könnte auch App XYZ starten, auch wenn der TXT an ist und ggf. sogar gerade eine andere App läuft.

Eine Abbruch-Funktion muss man auch einbauen, sonst hätte man ein Problem, wenn die Auto-Start-App kaputt ist und den TXT in irgendeiner Form unbedienbar macht.

Ein wenig druchdenken sollte man das gesamte Konzept dazu schon.

MasterOfGizmo hat geschrieben:Was war denn an dem Ausschalten knifflig? Der rtc zieht gegen den Pullup in der Selbsthaltung das Enable-Signal gegen Masse. Damit gehen die 5v aus.

Jein. Ja, die CPU (ich nehme an das meintest Du, "rtc" macht in dem Zusammenhang keinen Sinn) zieht bei Aktivierung des Abschalt-Pins die Leitung gegen den Pullup auf Masse.

Aber: Zum einen hängt die Leitung hängt gar nicht direkt am Enable-Signal, sondern nur über eine Diode (bzw. genauer: Über die eine Hälfte eines BAT54C) - d.h. die Leitung kann Enable direkt nur auf 1 ziehen, nicht auf 0. OK, dafür gibts hinter der Diode einen passenden Pull-Down Widerstand. Nur (und das ist der Knackpunkt): Die 5V gehen halt nicht aus, obwohl die CPU beim Shutdown natürlich wie üblich den Abschalt-Pin auf 1 legt.

Die Fehlermeldung, die Raphael bekommen hat, ist die direkte Folge davon. Beim Poweroff macht der Linux-Kernel das hier (nur der relevante Ausschnitt): Normalerweise geht irgendwo in kernel_power_off() der Strom aus (und damit ist dann Schicht im Schacht). Wenn nicht, dann läuft der Kernel weiter, d.h. kernel_power_off() kommt zurück und do_exit(0) wird ausgeführt. Das wiederum prüft, ob der aktuelle Thread noch irgendwelche Locks hält - und Bingo, reboot_mutex ist noch gesperrt. Kabumm. Kernel Panic.

Der Grund dafür, dass der Strom nicht ausgeht, ist die zweite Leitung, die zum Enable-Pin führt (ebenfalls über eine Diode, genauer gesagt über die andere Hälfte des oben erwähnten BAT54C). Und die hängt ziemlich direkt an INT1 vom tps65910 (da gibts noch einen Pullup gegen VRTC, aber den kann man hier ignorieren).

So weit, so gut - das ist halt ein Schutz davor, den Saft abzudrehen so lange noch Interrupts anhängig sind.

Allerdings: Laut Datenblatt vom TPS65910 ist INT1 "active low". Mit anderen Worten: Das zieht Enable auf 1, wenn gerade kein Interrupt anliegt - also quasi immer. Logische Folge: Abschalten per Software sollte eigentlich so gut wie nie funktionieren. Tut es aber prima, zumindest wenn man nicht an der RTC herumschraubt....

Da dran hab ich eine ganze Weile dran rumgeknapst. Bis ich irgendwann das Datenblatt vom tps65910 nicht nur quer- sondern durchgelesen habe und darüber gestolpert bin, dass man die Polarität von INT1 umschalten kann. Kurzer Blick ins Devcontrol-Register (Debugfs sei dank geht das ganz simpel) und siehe da: Im TXT ist INT1 auf "active high" konfiguriert Damit macht die Schaltung dann auch wieder Sinn: Solange am tps65910 ein unquittierter Interrupt anliegt, bleibt auch der Strom an.

Und damit war dann auch endlich klar was das Problem ist: Beim Aufwachen per RTC-Alarm signalisiert der tps65910 das brav per Interrupt, d.h. er setzt INT1 auf 1 und schreibt die passenden Flags in die entsprechenden Register. Linux läuft da noch nicht, kriegt das daher auch nicht mit, und quittiert den Interrupt dementsprechend nie. Also bleibt INT1 immer auf 1, und beim nächsten (und allen folgenden, zumindest solange der selbst tps65910 nicht durch herausnehmen der Knopfzelle neu gestartet wird) Shutdowns knallt es dann halt.

Und ja, der Treiber für den tps65910 (bzw. der für dessen RTC-Funktion) setzt natürlich bei der Initialisierung alle anstehenden Interrupt-Flags zurück. Nur muss man das halt ausgerechnet für den RTC-Alarm an zwei Stellen tun und nicht nur an einer.

Und genau das macht dann mein Patch...

MasterOfGizmo hat geschrieben:Jetzt muss der ftc-user noch Zugriff auf den rtc bekommen (wenn er's nicht eh schon hat)

Nein, hat er nicht - dafür reicht aber ein passendes chmod/chown auf /sys/class/rtc/rtc1/wakealarm aus.

MasterOfGizmo hat geschrieben: Richard, ich habe in Deinen Patch nicht im Detail reingechaut, aber kann es sein. dass Du genau diese Bestätigung gerade automatisiert hast?

Ja, der Patch macht genau die fehlende Bestätigung (bzw die noch fehlende Hälfte der Bestätigung - der ungepatchte Treiber setzt die Interrupt-Flags zwar im RTC-Statusregister zurück, aber ausgerechnet den Wakeup-Alarm (und nur den) muss man zusätzlich noch im allgemeinen Interrupt-Statusregister quittieren. Warum auch immer).

MasterOfGizmo hat geschrieben:Hat eine App trotzdem eine Chance, die Tatsache zu erkennen, dass der RTC den Strom eingeschaltet hat?

Nein, mit dem Patch geht das so direkt nicht mehr (und ohne auch nur, wenn man per Debugfs direkt in die passenden Register der RTC schaut - und das will man eigentlich nicht machen).

richard.kunze hat geschrieben: Nein, mit dem Patch geht das so direkt nicht mehr (und ohne auch nur, wenn man per Debugfs direkt in die passenden Register der RTC schaut - und das will man eigentlich nicht machen).

Hmm, zur Zeit quittierst Du das in rtc_probe, also beim Booten. Das macht die Sache sicher und ist wohl auch tatsächlich der einzige Moment, wo der Treiber mit Sicherheit angesprochen wird.

Aber irgendwie fände ich es doch cool. wenn das Register per sysfs oder ähnlich angesprochen werden könnte und wenn das quittieren dann explizit aus dem User-Space erfolgt. Ja, das hätte das Problem, dass Raphaels Problem immer dann auftritt, wenn dann doch keine Software so frendlich war, das zu quittieren. Aber es tritt ja eh erst auf, wenn aus dem User-Space irgendwer den RTC programmiert hat. Also sollte die nötige Infrastruktur zum Quittieren auch da sein.

Ich würde die nötigen Mechanismen auch in den Launcher einbauen. Ggf. als kleines Plugin, das dann auch per Icon meldet, dass der RTC den TXT geweckt hat und das dann auch die passende App wieder startet. Da fällt mir schon was ein, wenn ich die nötige Infrastruktur habe.

Um es mal für alle zusammen zu fassen:

Der gesamte TXT wird über einen schaltbaren 5V-Schaltregler ein- und ausgeschaltet. Alle anderen Spannungen werden mehr oder minder direkt davon abgleitet. Ergo: 5V an => TXT an. 5V aus => TXT aus

Der 5V-Regler hat einen Enable-Eingang. Wenn der suf 5v liegt ist der TXT an. Direkt am Regler ist ein Pull-Down. Also ist der TXT normalerweise aus. Es gibt drei Dinge, die das beeinflussen können: Der Power-Taster, ein Signal names OFF_VC vom Sitara (also der Linux-CPU) und der INT1 Ausgang des RTC im PMIC. Strom geht an, wenn entweder der Power-Knopf gedrückt wird oder aber das INT1-Signal des PMIC auf high ist oder die 5V bereits an sind. RTC und Taster müssen also nur kurz aktiv sein, sobald 5V da sind bleiben sie auch an (Selbsthaltung). Die einzige Möglchkeit, das wieder aus zu schalten ist das OFF-VC-Signal. Das hat Priorität über den Taster und die Selbsthaltung, aber nicht über den RTC. Der Sitara kann sich also nur dann selbst wieder ausschalten, wenn der PMIC das INT1-Signal seines RTC wieder deaktiviert hat. Das ist genau das, was Richards Patch nun immer direkt nach dem Booten erzwingt.

Zuästzlich gehen die Signale des Tasters und das INT1-Signal des RTC auch an den Sitara bzw den Motorcontroller (von dem es der Sitara dann abfragen kann). Auf die Weise kann man den Power-Taster dann auch zum Ausschalten nehmen, indem nämlich die CPU erfährt, dass der Taster drückt wurde. Die Stromversorung reagiert darauf nicht, denn der TXT ist ja schon an. Aber die CPU kann als Reaktion auf den Tastendruck OFF_VC aktivieren und sich selbst den Strom abschalten. Auf den RTC-INT1 reagieren zu können macht auch Sinn, denn dann kann die CPU a) feststellen, dass sie vom RTC eingeschaltet wurde und nicht vom Benutzer per Taster und b) sie kann auch bei eingeschaltetem TXT auf ein RTC-Ereignis reagieren.

Was mich irritiert ist, dass Richard erst nachrüsten musste, dass er den RTC-INT1 quittieren kann. Das schaue ich mir nochmal an. Interrupts nicht quittieren zu können gibt irgendwie keinen rechten Sinn ...

MasterOfGizmo hat geschrieben: Was mich irritiert ist, dass Richard erst nachrüsten musste, dass er den RTC-INT1 quittieren kann. Das schaue ich mir nochmal an. Interrupts nicht quittieren zu können gibt irgendwie keinen rechten Sinn ...

Stimmt eigentlich. Und nachdem INT1 nach dem Booten definitiv noch aktiv ist, sollte der Kernel das auch mitbekommen wenn er erst mal hochgefahren ist. Und tatsächlich ist das auch so. Zumindest dann, wenn man den Interrupt im DTS richtig "verdrahtet".

Das, was da bisher dazu drinstand war kompletter Quatsch - der TPS65910 ist eben selbst kein Interrupt- bzw. GPIO-Controller (und er redet auch nicht direkt mit dem internen Interrupt-Controller im SOC - das kann er als externern Chip auch gar nicht), sondern er ist lediglich an einen solchen (genauer: Den "gpio0"-Controller des SOC) angeschlossen. Um ganz genau zu sein über GPIO Nummer 6 (siehe auch den Pinmux-Eintrag im DTS). Sobald das richtig deklariert wird (https://github.com/ftCommunity/ftcommun ... dbc97362f8 macht das), klappt es mit dem Quittieren des IRQ auch ganz ohne krude Patcherei...

Edit: Zu früh gefreut - ich hätte zum Testen auch mal mit dem richtigen Kernel per Wakeup booten sollen Da muss ich dann wohl noch etwas weitersuchen wie man die Interrupts da richtig einstellt.

Update: OK, der TPS65910 ist (unter vielem anderen) doch ein Interrupt- und GPIO-Controller (der multiplexed die Intrerrupts für die enthaltenen Geräte). Aber er hängt definitv nicht direkt an intc (auch wenn die meisten Beispiele im Netz so ein Setup zeigen - beim TXT ist das anders aufgebaut) sodern an gpio0_6. Aber auch wenn man das so konfiguriert kommen die Interrupts nicht beim Kernel an...

Ist das bei der Original-Firmware auch schon falsch? Dann wäre das ja sicher eine nette Option für RoboPro 4.2.5.

Ich schaue mal, dass ich da eine Demo-App drum stricke. Sowas wie alle 5 Minuten aufwachen und einen Bimmelton ausgeben oder so.

Und ein kleines Reboot-Script nach der Art des powerdown-Scriptes wäre sicher auch nett. Jemand schlug schon vor, ab jetzt beim Ausschaltknopf-Druecken nach "shutdown or Reboot" zu fragen. Aber das bedeutet bei jedem Shutdown einen Extra-Klick. Ich mag's eigentlich nicht, wenn die Bedienung ohne triftigen Grund aufwändiger wird.

Allgemein fände ich einen reboot Toll. Leider mündet einin einer Fehlermeldung.
Meine Idee:

• Kurzes Drücken: App Schließen
• 2Sec.: Herunterfahren
• 5Sec.: Reboot
• 10Sec.: Zukunft: Screenshot machen und mit App-Logs zusammen in eine zip machen. Dann Hochladen auf einen Webserver (z.B. ftc) (Telemetrie). Am besten noch einmal bestätigen, dass man das wirklich will.

Raphael

MasterOfGizmo hat geschrieben:Ist das bei der Original-Firmware auch schon falsch? Dann wäre das ja sicher eine nette Option für RoboPro 4.2.5.

Weiß ich nicht - die hat ja noch einen älteren Kernel, und zwischen dem und unserem Kernel hat sich einiges am DTS geändert (sonst hätten wir den aus dem Original ja direkt übernehmen können). Eventuell hat das früher mal so funktioniert.

Edit: Ich hab eben mal nachgeschaut - die Original-Firmware in Version 4.2.4 hängt ebenfalls beim Runterfahren, wenn man den TXT per RTC-Alarm gestartet hat.

MasterOfGizmo hat geschrieben:Und ein kleines Reboot-Script nach der Art des powerdown-Scriptes wäre sicher auch nett. Jemand schlug schon vor, ab jetzt beim Ausschaltknopf-Druecken nach "shutdown or Reboot" zu fragen. Aber das bedeutet bei jedem Shutdown einen Extra-Klick. Ich mag's eigentlich nicht, wenn die Bedienung ohne triftigen Grund aufwändiger wird.

Reboot könnte knifflig werden. Zumindest als ich das zum letzten Mal probiert hatte (per "reboot"-Kommando auf der Konsole) ist der TXT danach im U-Boot hängen geblieben. Da scheint der Kernel irgendwas anders zu hinterlassen als es dem U-Boot gefällt.

richard.kunze hat geschrieben:Reboot könnte knifflig werden.

Genau deshalb erwähne ich es ja in diesem Thread: Timer auf "in X Sekunden" und dann ein normaler Shutdown. Dann geht der TXT nach X Sekunden wieder an -> Reboot

Hallo zusammen,

mit Commit https://github.com/ftCommunity/ftcommun ... acb994aa8a klappt alles jetzt auch sauber und ohne Patcherei. Da war im DTS für den CPU-PIN, an dem INT1 vom tps65910 landet, noch der falsche "Mux Mode" gesetzt. Sprich: Das Interrupt-Signal wurde als Chipselect für ein (ungenutztes) SPI-Interface interpretiert und ist dementsprechend nie beim Interrupt-Controller angekommen...

Jetzt sieht man auch (so wie es sein soll) die Alarm-Interrupts in /proc/interrupts - wenn da direkt nach dem Booten was anderes als 0 im Zähler für "tps65910-rtc" steht, dann wurde der TXT per RTC-Wakeup gestartet.

Habe ein kleines Plugin geschrieben, das Euch anzeigt, wenn RTC events aufgetreten sind. Keine Ahnung, ob ich das so lasse, aber jetzt für die ersten Tests ist es bestimmt ganz witzig.

Edit: Ich denke ich werde das Plugin mal zu einem einfachen RTC-Restart-Framework ausbauen. Sollte recht einfach sein ...