Hallo. Ich möchte eine sichere Methode für ein Linux-Firmware update einsetzen. Mein Konzept bis jetzt besteht aus 3 Komponenten: Linux-Firmware : Das eigentliche System. Dieses soll hin und wieder upgedated werden. Linux-Fail-Save-Firmware : Ein minimales Linux-System, welches einen SSH-Zugriff erlaubt bzw. ein Update des normalen Systems vornimmt. Eigener Kernel und eigenes Initramfs, welches nie verändert werden soll. U-Boot : Startet in abhängigkeit der Umgebungsvariablen eines der beiden Linuxe. Meine Frage ist jetzt. Wie bemerke ich, dass die normale Linux-Firmware kaputt ist? Angenommen das System kann aus irgendeinen Grund nicht mehr starten, wie kann ich U-Boot dazu bringen, die Fail-Safe Firmware zu booten? lgw
Hi, -> irgendein Flag durch U-Boot löschen und durch dein Linux setzen wenn es vollständig funktionsfähig ist. Beim nächsten Bootvorgang prüfst du ob das Flag da ist oder nicht. -> Checksumme über wichtigste Teile -> Taster mit dem du das eine oder das andere startest
hallo Die Idee mit dem Flag hatte ich auch schon. Aber bleibt Linux z.B. mit einen Kernel-Panic hängen, brauche ich irgendeinen Watchdog, der das System resetiert. Kann ich in U-Boot einen watchdog starten? Wäre es besser, die Fail-Save-Firmware als eine art 2nd-Stage Bootloader zu verwenden? Taster ist nicht gut, da das Gerät eine Art Wetterstation sein soll, welches nicht ohne weiteres erreichbar ist. Die Updates werden dann über mobiles Internet eingespielt. Mirco Controller schrieb: > -> Checksumme über wichtigste Teile Meinst du über den Kernel oder wie kann ich mir das vorstellen?
Hi, die Idee mit dem Watchdog ist gut, du kannst ja z.B. einen kleinen µC nehmen über den du das ganze machst. -> U-Boot setzt Ausgang, Linux setzt zurück -> wenn nach Zeit t nicht zurückgesetzt wurde --> hauptreset und hinweis an U-Boot Checksumme über den komprimieten Kernel und die anderen wichtigen Teile. Vill das Rootfs nochmal splitten in Systemprogramme und deine Anwendung dann könnte man das readonly machen und dadrüber nochmal eine Checksumme (da bin ich mir aber nicht so sicher)
Eine Wetterstation mit fern-updatebarem Linux... wow. Aus Angst die Wetterstation wird gehackt, muss das update drauf? Was ist denn die erwartete Lebensdauer des Geraetes? Falls das Geraet kein Modefurz sein soll, dh von ueber 10 Jahren ausgegangen werden soll, wuerd ich mir das update schenken, denn nach 3,4 Jahren gibt es eh kein update mehr. Wenn dasupdate feature einfah dabei ist,nimmt man's natuerlich.
LFU schrieb: > Es gibt immer wieder Personen deren Meinung einfach NICHT gefragt ist! In deinem Post stand nichts darüber, dass nur bestimmte Personen antworten dürfen und wer das sein soll. Fast hätte ich auch was geantwortet, deine Warnung kam gerade noch rechtzeitig. Gruss Reinhard
Einige Sun-Server hatten ein sogenanntes Lights-Out-Management (LOM) Modul. Das war ein separater Prozessor, der das Hauptsystem resetten, an- und ausschalten, Errorlogs lesen und vieles mehr steuern konnte. Mit einer Escape-Sequenz (.~. oder so) kam man auf die Console des Hauptsystems und wieder zurück. Für wichtige ("missionskritische") Server war das genau das richtige, und auch für Maschinen, die einige 100km weiter in einem RZ stehen, ist das sehr nützlich, wenn mal was passiert. Das LOM funktioniert ja unter allen Umständen, unabhängig vom Zustand des Hauptsystems. Ich weiß ja nicht, was das jetzt für eine Hardware ist, aber rein theoretisch könnte man über das LOM auch das Flash beschreiben. Wenn die Kiste von einem SPI-Flash oder einer SD-Karte bootet, wäre das überhaupt kein Problem. fchk
Was irgendwie nicht durchkam ist weshalb das System ueberhaupt runtergefahren werden soll. eingebettete System laufen sonst eigentlich durch. Ein Hibernate liegt ja drin.
Frank K. schrieb: > Das war ein separater Prozessor, der das Hauptsystem resetten, > an- und ausschalten Im Prinzip kommt man nicht um Folgendes herum, wenn es immer funktionieren muss: 1. Ein unabhängiges System, also wie beschreiben ein Zusatzprozessor. 2. ein unabhängiger Zugang - man muss das System nach Punkt 1 bedienen können, egal in welchem Zustand sich das überwachte System befindet. Punkt 2 dürfte schwer zu garantieren sein, wenn nur ein Netzwerkzugang besteht und den beide Systeme gemeinsam benutzen müssen. Gruss Reinhard
Reinhard Kern schrieb: > Punkt 2 dürfte schwer zu garantieren sein, wenn nur ein Netzwerkzugang > besteht und den beide Systeme gemeinsam benutzen müssen. Intels AMT kann es.
> Wie bemerke ich, dass die normale Linux-Firmware kaputt ist? > Angenommen das System kann aus irgendeinen Grund nicht mehr starten, wie > kann ich U-Boot dazu bringen, die Fail-Safe Firmware zu booten? Du kannst die Probleme aufteilen. Ist der Image in Flash kaputt ? Dann merkt U-Boot einen CRC-Fehler beim laden des Kernels. In U-Boot kannst du einen Skript schreiben, der den zweite System in diesem Fall startet. Ist rootfs kaputt ? Dann wird rootfs hochwahrscheinlich nicht gemountet. Der kernel Parameter "panic" lässt dein System wieder starten. Aber watchdog muss auch sein. In U-Boot findest du mehrere Treiber, um den Watchdog für den spezifischen Prozessor einzuschalten. Es gibt noch den Fall, wenn kernel+rootfs laufen, aber deine Applikation nicht richtig gestartet werden kann. In U-Boot gibt es den "boot counter" feature: wenn der Bootcounter nicht von Applikation zurückgesetzt wird, startet U-Boot automatisch einen anderen Skript ("altbootcmd" statt "bootcmd"). Übrigens habe ich einen OSS Projekt gestartet, um ein Update für Embedded System gewährzuleisten. Falls du noch brauchst und einen Blick werfen möchtest, ist der link https://github.com/sbabic/swupdate Gruss, Stefano
Hallo, ich habe eine Kombination aus Bootcounter und Watchdog verwendet. Hab mir gerade deine Seite angesehen - sehr interessant muss ich sagen. Vielen dank für den Link. lg
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.