Jo, Rainer hat es in wenigen Worten schon geschrieben.
Da ich aber jetzt schon einen ellenlangen Text geschrieben hab muß ich euch damit noch ein wenig quälen. Vielleicht beleuchtet er die Sache nochmal genauer.
> Funktionen, wie Sound, Video, VGA, SD-Card zurgiff und Netzwerkzugriff würde ich aus dem Kernlen
> in eigenen kleinen Treibermodulen auslagern und nur bei bedarf starten. Wobei nichts dagegen spricht,
> eine art Autostart- Prozedur aufzusetzen, die beim einschalten schonmal den SD- Treiber startet und sich
> auf der SD- Card z.B. sowas wie eine "Autoexec.Bat" sucht und ggf. ausführt. Ob dann ein
> Windowsbasiertes System startet, oder eine einfache Dosshell wäre dann von den vorlieben des
> Anwenders abhängig und seiner autoexec.
Zumindest für Bellatrix und Regnatix ist das ja momentan schon so realisiert: Beide Chips laden nur einen minimalen Loader aus dem EEProm. Der Regnatix-Loader lädt dann von SD-Card die Datei sys.bin, welche quasi das OS beinhaltet, startet diese Anwendung in der zweiten Cog, bleibt aber selbst resident um auf Befehl andere Anwendungen starten zu können. Was ihr in die Datei sys.bin packt ist euer Bier - bei mir ist es momentan die Kommandozeile "Regime" (geiler Name
, aber ihr könnt dort auch eure Aquariensteuerung oder den Code für einen Melodiegong bunkern - einfach einen (fast) normale Spin-Code compilieren und als Binärdatei auf der SD-Card als sys.bin abspeichern.
Der Administra-Loader startet auch aus dem EEProm, wartet aber auf ein Image (auch eine normale BIN-Datei), welches das gebootete OS in Regnatix ihm sendet (bei meiner CLI momentan die Datei vga.bin), startet diesen Treiber, beendet sich dann aber, so dass für den Treiber in Bellatrix alle Cogs zur Verfügung stehen. Der Treiber selbst kann aber über eine Funktion einen Reset von Bellatrix auslösen und somit wird der Miniloader wieder aus dem EEProm geladen und wartet auf ein neues Treiberimage - so kann jede Anwendung den Code in Bellatrix austauschen.
In Administra ist das ganze aber ein wenig komplizierter: Der Regnatix- und der Bellatrix-Loader konnten direkt oder indirekt auf die FAT16-Routinen in Administra zugreifen um eine Anwendung bzw. einen Treiber zu laden. Administra selbst kann aber nicht auf die eigenen FAT16-Routinen zugreifen und sich selbst an den Haaren aus dem Sumpf ziehen - sofern man nicht einen Administra-Loader realisiert, welcher schon FAT16 beherrscht. Hmm, keine Ahnung ob das jetzt irgendwie rüber kommt...
Man könnte aber wie bei Bellatrix einen Resetmechanismus realisieren, wobei Regnatix den Treiber aber im eRam zwischen puffern muß, da ja nach dem Reset erstmal keine FAT16-Funktionalitten in Administra zur Verfügung stehen. Das hat Rainer ganz richtig erkannt und das ist auch ein wenig der Grund warum ich es bisher nicht realisiert ahb - es erscheint mir irgenwie noch nicht "einfach" genug, kann aber sein das es die einfachste Variante ist.
Vielleicht ist es auch gut sich den momentanen Bootmechanismus vorzustellen , indem man seine Evolution betrachtet. Als ich mit dem Hive angefangen hab, hatte ich die SD-Card noch nicht verwendet. Jeder Chip hatte sein Programm als eine Art Bios in seinen Flash bekommen. Man kann das auch jetzt noch problemlos nachstellen: Administra hat ja eh noch sein festes Bios im Flash, in den Flash von Regnatix könnte man die Datei sys.bin flashen (welche im Formalfall die Kommandozeile aber auch ein anderes beliebiges Programm enthalten kann) und in den Regnatix-Flash brennt man nicht den Loader, sondern einfach diregt den Treiber. Nach dem Einschalten wird in jeden Propeller der Flash geladen und aktiviert.
Das war anfänglich zum Testen ok, aber bald wollte ich ja flexibel Tools und Anwendungen von SD-Card starten können. Also habe ich den Regnatix-Loader geschrieben: Ein winziges Programm, welches beim Einschalten aus dem Flash gestartet wird, ein System (sys.bin) über Administra von SD-Card bootet und sich dann resident schlafen legt. Man beachte: Der Regnatix-Loader wird nicht beendet, sondern er wartet nach dem laden und starten der datei sys.bin auf Kommandos von ebend dieser Anwendung. Tippe ich in der Kommandozeile dann ein Kommando ein und es ist kein internes Kommando, wird geprüft ob es eine entsprechende Datei auf dem Datenträger gibt. Ist das der Fall sendet die CLI ein Kommando an den Loader, welcher ja noch in der ersten Cog resident lauert, damit dieser die CLI killt und die entsprechende neue Datei in den Ram lädt und startet. Wird eine normale Anwendung wieder beendet gibt es über eine ios-Funktion wieder ein Kommando an den Loader, er killt das Anwenderprogramm und startet wieder sys.bin.
Das war schon ein toller Fortschritt, aber bald sah ich, dass es sehr unflexibel ist, wenn in Bellatrix nur ein Code möglich ist. Die Gründe kann wohl jeder nachvollziehen. Also habe ich auch einen Loader für Bellatrix programmiert. Wie bei Regnatix wird auch dieser Loader beim starten des Systems geladen, lädt aber nicht aktiv seinen Code von Administra (da ich persönlich Bellatrix als Slave ansehe), sondern wartet auf ein Image, welches Regnatix sendet! Nun mußte ich nur noch das OS bzw. die Kommandozeile (quasi sys.bin) anpassen, damit diese nach dem starten ein Image von Administra lädt und an Bellatrix sendet - der Grafiktreiber (momentan verwendet die Kommandozeile die Datei vga.bin dafür). Im Gegensatz zu Ragnatix dachte ich mir aber, dass dieser Treiber nicht unbedingt resident sein muß und lasse ihn nach dem Laden des Treiberimages einfach beende, wodurch eine Cog für den Treiber selbst frei wird. Der Treiber kann aber über eine Funktion, welche von Regnatix aufgerufen wird, ein Reboot von Bellatrix ausführen, wodurch dieser Vorgang neu gestartet werden kann. Das Kommando (und die gleichlautende ios-Funktion) bload macht genau dies: Es sendet zum aktuellen Bellatrix-Treiber ein Reset-Kommando, wodurch dieser wieder seinen Loader aus dem EEProm startet und auf ein neues Image warte, welches bload gleich darauf sendet. Mit "bload tv.bin" kann man so den TV-Texttreiber einfach in der CLI aktivieren.
Jo, so funktioniert das momentan. Wenn wir jetzt auch noch für Administra solch einen Treiber realisieren, könnte man drei Dateien (z.B. adm.bin, bel.bin und reg.bin - ein Vorschlag) definieren, welche beim Einschalten/Reset automatisch geladen werden und das Bootsystem repräsentieren. Ein Austausch dieser Dateien, oder ein anderer Datenträger mit anderem Inhalt der Dateien würde auch ein anderes System starten. Man bräuchte wirklich nur diese drei universellen Treiber und wäre maximal flexibel. Auch ein Kommando (z.B. "sysload osx
wäre denkbar, mit welchem man einfach ein neues system bootet.
