Brainstorming zum Administra-Loader

[drohne235]

Wie man an diversen Beiträgen im Forum sehen kann, stellt der Loader für Administra ein zentrales Problem dar, welches wir noch gemeinsam lösen müssen. Deshalb denke ich, ist es vielleicht an der Zeit diesem Hindernis jetzt ein wenig zu Leibe zu rücken.

Vielleicht an erster Stelle nochmal grundlegend: Warum ist der Administra-Loader so wichtig? Bisher haben wir für zwei der drei Propellerchips, für Regnatix und Bellatrix, schon einen funktionierenden Loader. Solch eine Struktur bietet für den Hive die maximale Flexibilität: Unabhängig von dem konkreten Code der beim Systemstart in die beiden Propeller geladen wird, kann jede Anwendung zur Laufzeit einen eigenen Code in die Propeller laden und somit eine komplette eigene Laufzeitumgebung schaffen. Es gibt dabei keine Inkompatibilitäten, wenn sich der normale Funktionsumfang, z.B. des Bildschirmtreibers vga.bin ändert, wenn jedes Programm seinen eigenen Treiber mitbringt und startet. Unabhängig von Kompatibilittsproblemen hat man durch diese Methode auch die Möglichkeit, alle Ressourcen wirklich selbst zu kontrollieren. Nehmen wir an, die eigene Anwendung benötigt weiter Ressourcen um die Performance zu steigern und in Regnatix sind schon alle Kerne in Verwendung, so können mit einem eigenen Code in Bellatrix evtl. dort freie Kerne in die Verarbeitung mit einbezogen werden.

Auch wird es sicher so sein, dass sich auf dem Hive vielleicht verschiedene experimentelle Systeme etablieren - ob Betriebssystem, Anwenderprogramm oder Game - schön wäre es für all diese Experimente, eine gemeinsame Basis zu besitzen, ohne die EEProms umzuflashen. Der kleinste gemeinsame Nenner für all diese Projekte ist eine universelle Loaderstruktur für alle drei Propellerchips. Bellatrix und Regnatix besitzen einen Loader, Administra fehlt noch in diesem heiligen Reigen.

So sieht der momentane Systemstart aus

- Administra startet ihr komplettes BIOS aus dem EEProm und stellt ihre Funktionen auf dem Bus zur Verfügung.
- Bellatrix startet ihren Loader aus dem EEProm und wartet auf die Übertragung einer BIN-Datei als Treibercode.
- Regnatix startet ihren Loader aus dem EEProm. Dieser öffnet über Administra die Datei "sys.bin" auf der SD-Card (eine ganz normale BIN-Datei), lädt diese in den HubRam und startet den Code. Der Loader in Regnatix bleibt dabei resident und wird vom IOS zum laden von Programmen benutzt.
- Diese gestartete BIN-Datei (sys.bin) in Regnatix öffnet die BIN-Datei für den Grafiktreiber (normalerweise vid.bin) und überträgt diese Datei zum Bellatrix-Chip. Bellatrix empfängt diese Datei, speichert sie im HubRam und startet sie danach - das Grafiksubsystem läuft an. So initialisiert Regnatix Bellatrix.
- Das Anwendersystem in "sys.bin" hat nun die Grafik initialisiert und damit stehen der Anwendung (meist die Kommandozeile "Regime" die sich in "sys.bin" befindet) alle Funktionen von Administra und Bellatrix zur Verfügung.

Kurz sieht das fogendermaßen aus:

EEProm --> Administra (Bios)
sd-card/sys.bin --> Regnatix (Anwendung)
sd-card/vid.bin --> Bellatrix (Grafiktreiber)

Aktuelle Struktur

Zwar wird der Programmcode von Administra und Bellatrix momentan noch in unterschiedlicher Weise beim Systemstart initialisiert, aber bei beiden Chips gleicht sich die grundlegende Struktur, denn beide Damen stellen Regnatix ihre Funktionen zur Verfügung. In beiden Chips ist eine COG als Funktions- und Buscontroller abgestellt: Dieser lauscht am Bus ob Regnatix eine Funktion abruft und steuert dabei den Ablauf der Funktionsausführung. Zu jeder Funktion gibt es in dem Objekt "ios.spin" eine Routine, welche die entsprechende Funktion in einem Programm abrufbar macht. Die entsprechende Routine im ios und in den Slaves müssen im Ablauf dabei genau aufeinander abgestimmt sein.

Momentan gibt es für Administra in TriOS zwei BIOS-Versionen:

os-1-adm-bios.spin Stack/Free ~1250 Longs
os-1-adm-biosw.spin Stack/Free ~550 Longs

Die "biosw"-Version enthält dabei eine noch nicht korrekt funktionierende Version von Routinen, um Wav-Dateien direkt von SD abspielen zu können. Das entsprechenden Kommandozeilentool "wplay" benutzt diese Funktionen. Es ist natürlich fraglich, ab man einen solchen Player unbedingt braucht - für mich war es ein interessantes Experiment. Zu beachten ist außerdem, dass es sich bei beiden Versionen bzgl. der verwendetetn Puffer wirklich nur um eine erste Näherung handelt. So wird aktuell 16384 KByte Puffer für HSS-Dateien reserviert, wenn ich die momentan verfügbaren Sounddateien anschaue finde ich aber nur wenige, welche größer 10 KByte sind und wahrscheinlich könnte man diese ebenso optimieren. Was ich damit sagen will ist folgendes: Hier ist noch viel Raum für Optimierungen.

Der TCP/IP-Socket aus dem PropTCP-Projekt von Harrison Pham ist 2186 Longs groß, da wird es also mächtig eng wenn man das übernehmen möchte.

Problem eines Administra-Loaders

Neben der verfügbaren Speichergröße gibt es aber noch ein anderes Problem bei der Realisierung eines Loaders für Administra. Betrachtet man die Loader für Regnatix und Bellatrix erkennt man folgendes: Beide Codes können sehr klein gehalten werden, da sie die fsrw-Routinen von Administra nutzen. Das ist für Administra selbst aber nicht möglich, ein Loader mit der gleichen Struktur müsste also selbst ein fsrw enthalten und somit wäre er auch wesentlich großer als bei den anderen beiden Propellerchips im Hive.

Realisierungsvarianten

Ich denke schon einige Zeit über dieses Problem nach, komme aber immer noch nicht auf ein einfaches Konzept. Was wäre eigentlich die Wunschvorstellung?

- Der Code von Administra sollte zur Laufzeit durch eine Anwendung ausgetauscht werden können.
- So könnte man verschiedene modulare Versionen mit speziellem Funktionsumfang realisieren.
- Struktur und Handhabung sollte so einfach wie möglich sein.
- Der Wechsel des Administracodes sollte in möglichst kurzer Zeit stattfinden.

Mir sind bisher folgende Varianten eingefallen:

1. Loader über Regnatix: Einfacher Loader wie in Bellatrix; der Code wird von Regnatix in den externen Ram geladen und danach findet ein upload zu Administra statt.
2. Loader enthält fsrw, startet restliche Funktionen im Heap und routet die geladenen fsrw-Funktionen zum geladenen Code (unübersichtlich/kompliziert)
3. Loader lädt Treiber in Heap, verschiebt danach den Code nach unten und startet ihn; restlicher Platz oberhalb wird universeller Puffer für Sound/LAN/Screens
4. Größerer EEProm und ein SPI-Loader, welcher die EEProm-Blöcke selektiv startet.
5. Administra-Funktionen zum flashen des EEProms und für Reset; Treiber wird zur Laufzeit umgeflasht und macht dann einen Reset.
6. Kombination aus 4. & 5.

Ansonsten bleibt natürlich auch noch die bisherige Variante: Der "perfekte" Administra-Code ohne Loader fest im EEProm. Ist zwar unflexibel, aber einfach und funktioniert. So richtig haut mich das alles noch nicht um, am einfachsten finde ich noch Version 4/5/6 - das ist recht einfach in der Handhabung und man müsste mal testen wie schnell das geht. Das könnte man mit ein oder zwei Routinen erledigen, wie groß der Codeumfang dabei ist muß ich mal recherchieren. Femto-Basic enthält entsprechende Routinen (sdspiFemto.spin), an denen man sich orientieren könnte, aber der ist mit 700 Longs auch recht fett. Mal schauen, vielleicht findet sich noch ein schlanker Code direkt in Spin der entsprechend kleiner ist.

Ok, hat noch jemand eine Eingebung?

[Rainer]

Größere EEPROMS usw. sind Harwareänderungen, die ich vermeiden würde. Ich habe zwar bald einen 1 MB FRAM drin, aber das ist mein persönlicher Spaß und kann ja nicht von jedem so einfach nachgebaut werden (oder überhaupt nachgebaut werden wollen).

Ich würde mir das viel einfacher machen.
Der Admin-Loader hat die Routinen enthalten, die auch die anderen Propeller haben + fsrw natürlich .. sonst geht ja gar nichts.

Jetzt gibt es 2 Möglichkeiten:

1) Administra lauert auf eine adm.bin auf der SD und lädt Zeug nach, daß da drin steht (schlechtere Lösung aber als "Miniconfig" (fsrw,einfacher sound, sonst nix) besser als nichts, falls man sein Anwenderprog nicht so aufblasen will).

2) Administra hat nur den Loader und fsrw, Reg lädt, Reg läd Bel, Reg läd Adm wenn Anwenderprogramm das vorsieht. Dabei würde ich alles außer dem Loader ersetzen können wollen durch mein Anwenderprogramm, also AUCH fsrw würde ersetzt .. wenn es sein muß mit genau der gleichen Version von fsrw.

Also noch mal in Kürze zu Version 2:
Mein Anwenderprogramm wird in Regnatix geladen (über den Minimal-loader in Admin), lädt dann u.U. Bel mit einem neuen Grafiktreiber, lädt dann z.B. MIDIplayer, FSRW und Ethernet in Admin.
Fertig.

Kombination aus 1) und 2) geht natürlich auch.

Drawbacks:
Macht Programme komplizierter, da ich ja irgendwie den neuen FSRW-Treiber puffern muß im ERAM, da ich mir ja zwischendrin selber den Ast absäge auf dem ich sitze


Gruß.
Rainer

[drohne235]

Was mir momentan halt noch ein wenig Mühe bereitet ist die Tatsache das es wohl nicht ohne PASM gehen wird - also eine COG die den neuen Code dann z.B. von Regnatix empfängt, in den hRam schreibt (den alten Loader überschreibt) und dann startet. Dafür muß ich halt erstmal die Busroutinen in PASM umsetzen, was wohl noch einen Augenblick dauern wird. Schön wäre ja ein Loader in Spin - schön klein und für jeden einsehbar - aber das scheint mir halt nicht möglich.

[DJLinux]

Langsam zum Mitschreiben "alter Mann ist doch kein D-Zug"

Warum heist es bei Dir immer DIE COG? das ist doch nur ein Kunstwort für "einen" "der" CPU "Kerne".

Egal also unabhängig vom aktuellem Funktionsumfang von Bel. und Adm. läuft in den Chips immer ein COG "der" auf dem Bus "horcht" ob z.B. Reg. einen Funktionsaufruf abgesetzt hat.

Habe ich das nun soweit schon mal verstanden oder Träume ich immer noch?

Adm. mit SD Zufriff muss also zuerst starten bzw nach einem gemeinsammen Reset muss der Loader von Reg. und Bel. auf die Bereitschaft von Adm. warten.

Ich würde es begrüssen wenn in allen drei EEProms (was für eine Verschwendung) nur der Code des jeweiligem Loaders stehen würde.

Dabei wäre es praktisch wenn nicht nach festen Dateien gesucht würde wie "sys.bin, vga.bin adm.bin" sondern das man in einer Datei angegeben kann welchen Satz an Startdateien geladen werden sollen.

Wenn z.B. ich Dir das super neue multicore Os geben würde.
Dann trägst du auf der SD in z.B. boot.txt den "Satz" Namen 'joshy' ein und
Adm. würde nach joshy.adm suchen
Reg. für Bel. über Adm. nach joshy.bel
Reg. über Adm, nach joshy.reg

Wenn es immer feste Datenamen wären dann müste man ja immer eine andere SD karte bereithalten.

Oder wenn man sein Tolles Spiel weiter geben möchte was aber Modifikationen an Adm. Bel. oder Reg. mitbringt dann bräuchte man in Boot.txt nur z.B. "game_xyz" eintragen und

Adm. würde nach einem Reset "game_xyz.adm" laden und wenn es diese Datei nicht gibt dann halt "HiVe.adm"
Reg. für Bel. über Adm würde "game_xyz.bel" laden und wenn es diese Datei nicht gibt dann halt "HiVe.bel"
Reg. über Adm. würde "game_xyz.reg" laden oder wenn nicht vorhanden "HiVe.reg"

Ein Spiel, Tool, Anwendung welche keine Modifikationen benötigt kann wie bisher als *.bin datei geladen werden.

Ich fände dieses Prinzip der Datei-Sätze mit gleichem Namen recht pracktisch.

Und wie schon angedeutet wenn die Datei "boot.txt" oder wie auch immer die heissen soll nicht existiert dann wird halt nach den Default Satznamen "HiVe" geschaut (HiVe.adm HiVe.bel und HiVe.reg)

Grüsse Joshy

[Rainer]

Warum heist es bei Dir immer DIE COG? das ist doch nur ein Kunstwort für "einen" "der" CPU "Kerne".

Nun, weil Parallax die Dinger nun mal so genannt hat ... wer's entwickelt, darf auch Namen vergeben
Könntest ja auch sagen "Das ist kein Propeller, sondern eine MCU"

Das mit der "Start-Config-Datei" ist eine gute Idee, Joshy
Leider brauchen wir immer noch eine Lösung, wenn das System schon läuft und ich ein Programm starte, das die Propeller neu "bestückt".
Das könnte schom Problematisch werden ... FSRW z.B. ist in dem "BIOS" von Administra ja reinkompiliert ... das müsste man erst mal "Modulfähig" machen, damit es bei Bedarf nachgeladen werden kann.

Eine Möglichkeit wäre natürlich, daß jedes Anwenderprogramm fsrw in dem eigenen Code für Administra mit reinkompiliert hätte .. dann würde das gehen. [EDIT] hmmm .. oder doch nicht ... hRAM ist ja u.U. schon zu voll [/EDIT]

[drohne235]

Vielleicht ist mit COG folgendes gemeint:

cog Nomen
Zahn
Zahnrad

[DJLinux]

Hallo Reiner
das heist doch DER CPU Kern also dann auch DER COG und nicht DIE COG!
Warum weiblich ?

Was meinst Du mit "Bestücken" ?

Eine Anwendung soll ohne Reset neue Task's von SD in die Chips laden und zur Ausführung bringen oder wie oder was?

Grüsse Joshy

UPS: drohne235 hat in der Zwischenzeit auch schon was geposted.

[Rainer]

Hallo Reiner
das heist doch DER CPU Kern also dann auch DER COG und nicht DIE COG!
Warum weiblich ?

Was meinst Du mit "Bestücken" ?

Eine Anwendung soll ohne Reset neue Task's von SD in die Chips laden und zur Ausführung bringen oder wie oder was?

Grüsse Joshy

UPS: drohne235 hat in der Zwischenzeit auch schon was geposted.

Ah, ok.
Da habe ich Dich mißverstanden .. dachte Du störst Dich an "COG", nicht am Geschlecht

"Eine Anwendung soll ohne Reset neue Task's von SD in die Chips laden und zur Ausführung bringen oder wie oder was?"

Nun, ganz so einfach wird das nicht funktionieren fürchte ich.
Du willst ja auch mit den jeweiligen "Modulen" kommunizieren was heißen würde, Du müsstest in JEDES Modul ios (oder Teile davon) mit reinkompilieren .. womit wir redundant zig mal den gleichen Code im hRAM haben ... der leider nicht im GB-Bereich angesiedelt ist und dementsprechend schnell volläuft.
Man müsste sich also einen "Protokoll-Cog" basteln, der "Vermittler" zwischen den Cog's und Modulen in "seinem" Propeller und den anderen Propellern spielt. Schon alleine deshalb, weil wir nicht jedem Modul erlauben können/sollten dauernd seine Daten/Ergebisse auf den Bus zu nageln.

Irgendwie sowas.

[laserjones]

Also, ich verstehe von all dem noch viel weniger als Joshy, wage aber trotzdem mal die Dummuser-Frage: fsrw (SD-Karte) wird doch so oder so benötigt, was ist also schlimm daran, wenn es im Administra-Loader fest enthalten ist und der dadurch etwas dicker ist als die anderen beiden? Wenn der Loader frsw in einem Cog laufen lässt (für mich war intuitiv immer klar, dass die Dinger männlich sind, auch wenn es das Zahnrad heißt), kann das doch einfach so bleiben, oder? Dann können andere Programme darauf zugreifen, und es muss einfach nur sichergestellt sein, dass dieser eine Cog dafür reserviert bleibt und nicht überschrieben wird (außer vielleicht wenn eine Anwendung geladen wird, die keine SD-Karte benötigt, aber dann kann man natürlich nur nach einem Reset wieder auf die Karte zugreifen).

Oder habe ich die ganze Architektur noch nicht verstanden?

[Rainer]

Stimmt schon. Die Idee des ladbaren SD-Kartentreibers entspringt bei mir eigentlich nur aus den Threads im Ami-Forum.
Die entwickeln da ständig dran rum .. so könnte man den halt einfacher austauschen.
Da die den aber wohl nicht wöchentlich ändern/verbessern, kann man dann zu gegener Zeit natürlich geausogut den Loader ändern.

Gruß
Rainer