Thema: Eigene CPU

[erik.vikinger]

Hallo,

Ich sprach vom Augen öffnen.

Schon klar, ich hatte das auch nicht so ganz ernst gemeint.

Geschichte wiederholt sich. ...

Wohl war und Dein Beispiel ist sehr gut gewählt.

Die Interrupt-Nummer sollte dem Handler natürlich trotzdem (in einem System-Register) zur Verfügung stehen.

Wozu? Jeder sinnvoll genutzte Interrupt ist dem System bekannt, also brauchst du in Hardware nicht doppelt arbeiten, um der CPU einmal eine interruptspezifische Funktion und die Interruptnummer mitteilen zu können.

Es gibt heutzutage viele HW-Komponenten die sehr viele Interrupts auslösen können, schau dir mal dir Gründe für MSI(-X) an, da wird man nicht für jeden Interrupt einen eigenen Handler haben wollen aber der Handler muss wissen für welchen der vielen Interrupts seiner einen HW-Komponente er gerade tätig ist. Auch könnte die selbe HW mehrfach vorhanden sein und auch da möchte man den Code nicht unbedingt doppelt haben. Ich denke den geringen Aufpreis für das Silizium sollte man zahlen wenn man dafür die volle Flexibilität bekommt.

Feste Adressen (wie bei ARM oder Z80) finde ich persönlich doof weil man dann dafür sorgen muss das an dieser Stelle auch wirklich RAM ist und weil dort eh nur ein Sprung auf den tatsächlichen Handler steht.

Bei ARM weiß ich es grad nicht, aber beim Z80 sind die Adressen nicht fest. Sie liegen nur alle zusammen in einem (kleinen) Bereich.

Bei ARM gibt es ein paar Vectoren die alle in den ersten wimre 64Bytes drin sind, man kann diese Vectoren auch in die letzte 64kB-Page legen aber man muss dort trotzdem jeweils einen Sprung auf den eigentlichen Handler hin legen und das kostet vor allem Latenz aber auch etwas nutzlosen RAM den man auch noch an einer bestimmten Adresse benötigt. Da ja auf meiner Plattform der Kernel per default ohne Paging arbeitet würde das bedeuten das ich an einer bestimmten physischen Adresse RAM vorsehen muss (x86 definiert ja auch wo überall physischer RAM verfügbar sein muss) und genau das will ich nicht, ich will auf jeden Fall das die CPU absolut keine Bedingen an das physische Speicher-Layout richtet so das der Board-Designer dort absolute Freiheit hat. Auch der Reset-Einsprungspunkt ist auf meiner CPU nicht fest definiert sondern der wird mit einem speziellen Bus-Zyklus vom Chip-Satz (der sein Board ja kennt) an die CPU übermittelt, das heißt die CPU fängt nicht einfach das arbeiten an wenn das Reset-Signal deasserted wird sondern sie bleibt in einem Power-Down-Wartezustand und wartet darauf vom Chip-Satz gesagt zu bekommen wo es los geht.

Wenn IRQ-Handler in den unteren 4 GB des Speichers liegen müssen, sehe ich da kein Problem.

Das ist in meinen Augen schon ein Problem weil das bedeutet das Du in den ersten 4GB überhaupt RAM haben musst was auf einer 64Bit-Plattform eigentlich nicht unbedingt erforderlich ist (da könnte auch der HW-MMIO-Bereich liegen).

Also baust du ein NOR-Flash an eine Stelle im Adressraum, wo die CPU nach dem Reset die Ausführung beginnt und dort legst du einen Bootloader für z.B. NAND/IDE hin, der Prüfsumme berechnet und startet?

Nein, dort liegt gleich ein vollwertiges OS-Image mit allem was nötig ist damit das OS auf die Füße kommt. Als Flash erscheint mir das http://www.sst.com/products/?inode=42062 ziemlich interessant. Wenn man davon 8 Stück parallel schaltet hat man einen 32Bit-Datenbus mit 80MHz, nur ein paar Takte Initial-Latenz (bursten geht dann mit den vollen 80MHz also 320MByte/s und beliebig lang) und 32MByte Kapazität. Das macht schon ordentlich was her und kostet nur 34 Pins am FPGA, nur zum Schreiben von ganzen Blöcken muss man im FPGA einen speziellen Mechanismus einbauen aber das Lesen dürfte ziemlich simpel sein. In diesem Flash sollen mehrere OS-Images drin sein können und eines davon wird von einem Initial-Boot-Loader angesprungen, dieser Initial-Boot-Loader liegt in einem ROM-Bereich. Dazu gibt es noch etwas SRAM der dann als Stack benutzt wird weil das OS ja erst den richtigen DRAM finden und einrichten muss (der darf dann an einer beliebigen physischen Adresse liegen). Unmittelbar nach dem aufwachen aus dem Reset gibt es nur ein einziges Device das im physischen Adressraum vorhanden ist und das darf sich eine beliebige physische Adresse auswürfeln, okay ich (als Board-Designer) lege einfach mal Adresse 0 fest aber es könnte auch jede andere sein. Dieses Device enthält dann den ROM, SRAM und Flash und sendet daher die physische Adresse des ROM an die CPU zum aufwachen. Die PCI-Spezifikation macht extra bestimmte Zugeständnisse an "zum Booten benötigte Devices" die nach dem Reset bereits aktiv sind (also deren Bit 1 im Command-Register auf 1 steht was eigentlich nicht erlaubt ist).

Ein full-featured BIOS finde ich jedenfalls heutzutage übertrieben.

Full ACK. Außerdem macht das einen riesigen Haufen an zusätzlicher Programmier-Arbeit.

Das OS implementiert in der Regel alle Treiber selbst.

Eben. Das EFI-Konzept, mit den OS-unabhängigen Treibern die direkt bei der HW in einem Flash liegen, ist zwar ganz nett aber so ein interpretierter Treiber, der auch nicht wirklich zu den spezifischen OS-Konzepten passt, dürfte kaum anständige Performance bringen. Das EFI-Konzept taugt um beim OS-Booten überhaupt erst mal an Massenspeicher und Konsole kommen zu können aber zur richtigen Laufzeit vom OS ist das absolut uninteressant und dementsprechend dürftig ist die Unterstützung der HW-Komponenten-Hersteller für EFI. Einer der Gründe warum Intel sich überhaupt das EFI hat einfallen lassen war der das man mal dachte zwischen x86 und Itanium Sockel-Kompatibilität erreichen zu können (es sollte mal Boards geben auf die man einen großen x86-Prozi oder einen kleinen Itanium-Prozi stecken kann und das BIOS mit den rudimentären Treibern nicht als nativer Code doppelt vorliegen muss), der andere wichtige Grund ist natürlich das man das angestaubte RM-BIOS los werden will.


Grüße
Erik

[Svenska]

Moin,

Es gibt heutzutage viele HW-Komponenten die sehr viele Interrupts auslösen können, schau dir mal dir Gründe für MSI(-X) an, da wird man nicht für jeden Interrupt einen eigenen Handler haben wollen aber der Handler muss wissen für welchen der vielen Interrupts seiner einen HW-Komponente er gerade tätig ist. Auch könnte die selbe HW mehrfach vorhanden sein und auch da möchte man den Code nicht unbedingt doppelt haben. Ich denke den geringen Aufpreis für das Silizium sollte man zahlen wenn man dafür die volle Flexibilität bekommt.

Okay, daran hatte ich jetzt nicht gedacht. Wobei ein Interrupthandler meist extrem kurz ist, daher ist der RAM-Verbrauch sehr gering. Zumal ich es nicht mag, wenn ein Treiber mehrere identische Hardwarekomponenten verwaltet. Da sollte man (gefühlt) den Treiber mehrfach laden können; andererseits habe ich keine Ahnung, ob sich gewisse Hardware dagegen sperrt.

Was tut man eigentlich in so einem Interrupthandler, außer in der Hardware den Datenbereich zu blockieren (damit der Treiber später kopieren kann) und ein Flag für das OS zu setzen? Kopiert man die Daten aus der Hardware in den RAM auch noch im Interrupthandler?

Bei ARM gibt es ein paar Vectoren die alle in den ersten wimre 64Bytes drin sind, man kann diese Vectoren auch in die letzte 64kB-Page legen aber man muss dort trotzdem jeweils einen Sprung auf den eigentlichen Handler hin legen und das kostet vor allem Latenz aber auch etwas nutzlosen RAM den man auch noch an einer bestimmten Adresse benötigt.

Okay, das wusste ich nicht. Wobei ich die Restriktion auf fixe physische Bereiche nicht so problematisch finde, sofern dieser Bereich "hinreichend groß" ist. Schöner dehnbarer Begriff, aber wenn Interrupthandler mit einem 24-Bit-Pointer (auf einer 32-Bit-Architektur) oder 32-Bit-Pointer (bei 64 Bit) physisch erreichbar sein müssen, hab ich damit kein Problem. Die oberen Bits können ja vom Chipsatz kommen, dann verlangst du keinen RAM an einer bestimmten Stelle.

Wenn der Bereich für IRQ-Handler z.B. 16 MB groß ist, dann kann das OS ja erstmal nur Speicher alloziieren, der woanders liegt. Treiber werden ja meist nur beim Systemstart geladen oder wenn genügend Speicher frei ist. Und im schlimmsten Fall kopiert man halt den Interrupthandler woanders hin und ändert den Basiszeiger... das entspricht also einem ausgerichteten Segment für IRQ-Handler.

Nein, dort liegt gleich ein vollwertiges OS-Image mit allem was nötig ist damit das OS auf die Füße kommt. Als Flash erscheint mir das http://www.sst.com/products/?inode=42062 ziemlich interessant. Wenn man davon 8 Stück parallel schaltet hat man einen 32Bit-Datenbus mit 80MHz, nur ein paar Takte Initial-Latenz (bursten geht dann mit den vollen 80MHz also 320MByte/s und beliebig lang) und 32MByte Kapazität.

Okay, ich hätte eher daran gedacht, einen Flashbaustein als Speicher zu benutzen und die dann vorhandene Adresse als Resetvektor anzugeben... der Vorteil wäre, dass der Flashbaustein an den ganz normalen Speicherbus angeschlossen ist und du dort dann extern (initial) und intern (vom OS aus) flashen könntest und du dir den ROM sparst. Wenn im FPGA genug Platz übrig bleibt, kannst du ja dort ein bisschen RAM erzeugen, spart den Extrabaustein.

Direktes Booten von PCI-Geräten finde ich persönlich etwas übertrieben. Mikrocontroller und SoCs tun das ja auch nicht... beim Samsung S3C24xx hast entweder einen NOR-Baustein im Adressraum oder du schließt einen NAND-Baustein an, wo die CPU dann mit einem CPU-internen Mikrocode die ersten 4 KB in einen CPU-internen SRAM kopiert und davon bootet.

Das EFI-Konzept taugt um beim OS-Booten überhaupt erst mal an Massenspeicher und Konsole kommen zu können aber zur richtigen Laufzeit vom OS ist das absolut uninteressant und dementsprechend dürftig ist die Unterstützung der HW-Komponenten-Hersteller für EFI.

In der Firmware braucht man für normale Systeme (deine Entwicklung spielt eher in Richtung leistungsfähiger Mikrocontroller) nur Treiber für Konsole (Tastatur und Textmodusbildschirm) und Bootmedium (so Dinge wie PIO-IDE-Controller, NAND-Flashbaustein und Netzwerkkarte). Das Konzept der Option-ROMs ist eigentlich optimal.

Gruß,
Svenska

[erik.vikinger]

Hallo,

Okay, daran hatte ich jetzt nicht gedacht. Wobei ein Interrupthandler meist extrem kurz ist, daher ist der RAM-Verbrauch sehr gering.

Es geht mir nicht primär um den RAM-Verbrauch sondern darum dass das System keine Vorgaben machen sollte wo und wie die IRQ-Handler liegen sollten. Okay so ganz halte ich mich da selber nicht dran weil ich für alle HW-IRQs (und das können extrem viele sein) nur einen einzigen Handler ermögliche (mehr macht bei einem Micro-Kernel ja auch keinen Sinn), aber wenn man eine etwas allgemeinere Plattform entwickelt dann sollte man mehr Flexibilität bieten.

Zumal ich es nicht mag, wenn ein Treiber mehrere identische Hardwarekomponenten verwaltet. Da sollte man (gefühlt) den Treiber mehrfach laden können; andererseits habe ich keine Ahnung, ob sich gewisse Hardware dagegen sperrt.

Ich kann ehrlich gesagt Deine Bedenken nicht nachvollziehen. Unter Windows ist es wimre üblich das ein Treiber nur ein einziges mal existiert und die IRQ- und DPC-Handler immer eine Geräte-Individuelle Struktur als Parameter mit bekommen. Aber ich meinte eigentlich das es auch HW-Komponenten gibt die mit recht vielen IRQs umgehen. Da wären z.B. bessere Ethernet-Controller bei denen für einzelne (TCP-)Connections der Treiber einen eigenen IRQ anbindet und diesen IRQ auch auf eine bestimmte CPU fest klemmt damit die Pakete auch gleich auf der CPU im Cache landen wo dann auch der zugehörige Server-Thread läuft, das selbe erlauben auch die guten SAS-Controller welche z.B. 64 IRQs (für jede CPU einen) haben können und für jeden HDD-Zugriff kann individuell ausgewählt werden auf welcher CPU dann der zugehörige "Fertig"-IRQ kommt (das geht übrigens auch mit SATA im AHCI-Modus), auf den besseren Server-Systemen soll sowas auf jeden Fall gut funktionieren.

Was tut man eigentlich in so einem Interrupthandler ....

Also das hängt ja wohl stark von der betreffenden HW ab, zumindest simples Daten-Kopieren sollte heute kein IRQ-Handler mehr machen müssen schließlich gibt es dafür ja HW mit Busmasterfähigkeiten.

Wobei ich die Restriktion auf fixe physische Bereiche nicht so problematisch finde, sofern dieser Bereich "hinreichend groß" ist.

Also mMn ist dieser Bereich entweder so groß das er den gesamten physischen Adressraum unterstützt oder es ist eine Einschränkung. Auch der Zwang das alle IRQ-Handler in einem bestimmten Bereich drin sein müssen ist IMHO nicht akzeptabel. Was ist wenn eine HW per Hot-Pluging erst später in den PC hinzugefügt (oder eingeschaltet) wird?

Okay, ich hätte eher daran gedacht, einen Flashbaustein als Speicher zu benutzen und die dann vorhandene Adresse als Resetvektor anzugeben

Die NOR-Flash-Teile sind schon ganz toll aber eben nicht sonderlich schnell.

der Vorteil wäre, dass der Flashbaustein an den ganz normalen Speicherbus angeschlossen ist und du dort dann extern (initial) und intern (vom OS aus) flashen könntest und du dir den ROM sparst.

Ich habe keinen normalen Speicherbus, stell Dir mein System lieber wie ein Opteron-System vor, da hat zwar jede CPU etwas Speicher aber das ist dann DDR2 oder DDR3 Speicher und an deren Datenleitungen kann man keinen NOR-Flash mit ranhängen. Flaschen passiert entweder über den FPGA per JTAG oder bei laufendem System.

Direktes Booten von PCI-Geräten finde ich persönlich etwas übertrieben.

Ich nicht, ich denke das ist genau die richtige Lösung. Es gibt ein Boot-Device, das Bestandteil des Chipsatz ist, und dieses Device bietet z.B. einen 32MB-Speicherbereich an. Die Basis-Adresse dieses Bereichs ist hardcodiert im BAR0 und wird benutzt um eine CPU aufzuwecken. In diesem Speicherbereich ist dann vorne der ROM und danach etwas RAM, etwas FRAM (für die Konfiguration) und natürlich der Flash enthalten. So lange es keine anderen Speicherbereiche im System gibt gehen eh alle Speicherzugriffe von der CPU an den Chipsatz (der dieses Boot-Device kennen muss) und wenn dann das OS-Image den RAM (der direkt an den CPUs hängt) in Betrieb nimmt werden auch die Routing-Tabellen in den CPUs konfiguriert und ab dann gibt es erst den DRAM in den dann der eigentliche OS-Kernel entpackt wird. Sobald das OS zum Leben erwacht wird das Boot-Device nicht mehr benötigt, außer noch die Konfigurationsdaten aus dem FRAM. Erst im laufenden OS wird dann der PCI-Service gestartet der den restlichen PCI-Bus nach Geräten absucht und diesen Ressourcen zuweist und Treiber startet.

Mikrocontroller und SoCs tun das ja auch nicht... beim Samsung S3C24xx hast entweder einen NOR-Baustein im Adressraum oder du schließt einen NAND-Baustein an, wo die CPU dann mit einem CPU-internen Mikrocode die ersten 4 KB in einen CPU-internen SRAM kopiert und davon bootet.

Das sind aber alles Beispiele wo die CPU-Designer schon sehr viele Vorgaben für den System-Designer machen. Ich möchte das meine CPU von außen gesagt bekommt wo es los geht und der Rest liegt dann in der Verantwortung des System-Designers.

deine Entwicklung spielt eher in Richtung leistungsfähiger Mikrocontroller

Na horch mal, ich will einen full-featured General-Purpose-PC entwickeln! Zumindest von den prinzipiellen Möglichkeiten her soll meine Plattform in dieser Liga mitspielen. Außerdem hab ich mir vorgenommen das ich einem vergleichbar ausgestattetem System (also gleiche Menge RAM, gleiche CPU-Taktfrequenz, gleiche CPU-Anzahl) zumindest auf gleicher Augenhöhe Paroli bieten kann. Du hast doch mal geschrieben das Du so verschiedene Serversysteme hast, kannst mir ja mal ne kleine Auflistung (per PM) zukommen lassen und wenn ich soweit bin suche ich mir einen adäquaten Gegner aus und wir lassen mal von http://www.eembc.org/ den CoreMark und den MultiBench gegeneinander antreten. Du darfst auch Dein OS und Compiler selber wählen.


Grüße
Erik

[Svenska]

Hallo,

Wobei ich die Restriktion auf fixe physische Bereiche nicht so problematisch finde, sofern dieser Bereich "hinreichend groß" ist.

Also mMn ist dieser Bereich entweder so groß das er den gesamten physischen Adressraum unterstützt oder es ist eine Einschränkung. Auch der Zwang das alle IRQ-Handler in einem bestimmten Bereich drin sein müssen ist IMHO nicht akzeptabel. Was ist wenn eine HW per Hot-Pluging erst später in den PC hinzugefügt (oder eingeschaltet) wird?

Einschränkung ja, KO-Kriterium nein. Was das Hot-Plugging angeht, hatte ich dazu was geschrieben - der RAM im entsprechenden Bereich wird erst dann alloziiert, wenn der restliche RAM voll ist oder er wird komplett für IRQ-Handler reserviert (16 MB sind da für mich akzeptabel). Ist der entsprechende Bereich belegt und ein Treiber wird geladen, so werden alle IRQ-Handler in einen anderen Bereich umkopiert und der Zeiger mit den in der Adresse fehlenden Bits wird neu geladen (er muss nicht null sein) oder der Treiber kann dann eben nicht geladen werden.

Das Laden von Treibern ist ein seltener Prozess, der in den allermeisten Fällen mit dem Systemstart erfolgt (ein USB-Device nutzt den IRQ des Hostcontrollers, der ist beim Systemstart vorhanden) und wenn man diesen RAM-Bereich nicht direkt als erstes rausgibt, dann ist dort auch immer etwas frei, solange das System nicht an der Lastgrenze steht. Wieder: Einschränkung ja, KO-Kriterium nein.

Okay, ich hätte eher daran gedacht, einen Flashbaustein als Speicher zu benutzen und die dann vorhandene Adresse als Resetvektor anzugeben

Die NOR-Flash-Teile sind schon ganz toll aber eben nicht sonderlich schnell.

Ist das ein Problem? Der initiale Bootloader kann doch das OS erstmal in den RAM kopieren, ehe du deine Lebendgeburt vornimmst. Wenn du mit 32 MB für mehrere OS-Images rechnest, dann dürfte ein OS-Image vielleicht 8-12 MB haben... bei 1 GB RAM kannst du das nun wirklich locker verschmerzen.

Ich habe keinen normalen Speicherbus, stell Dir mein System lieber wie ein Opteron-System vor, da hat zwar jede CPU etwas Speicher aber das ist dann DDR2 oder DDR3 Speicher und an deren Datenleitungen kann man keinen NOR-Flash mit ranhängen. Flaschen passiert entweder über den FPGA per JTAG oder bei laufendem System.

Gut, das ist ein KO-Kriterium. Wobei du eine Art Speicherbus sicherlich haben wirst, um MMIO da ranzuhängen; wenn im physischen Adressraum Geräte auftauchen, kann das auch der Flashbaustein.

Direktes Booten von PCI-Geräten finde ich persönlich etwas übertrieben.

Ich nicht, ich denke das ist genau die richtige Lösung. Es gibt ein Boot-Device, das Bestandteil des Chipsatz ist, und dieses Device bietet z.B. einen 32MB-Speicherbereich an. [...]

Ich würde einfach ein Stück Adressraum mit dem ROM vorbelegen. Das ist einfacher. Und wenn einem der Adressraum wirklich zu knapp ist, dann kann das OS ja auch das Adressbit wieder in physischen RAM (oder MMIO-Bereiche) zeigen lassen, statt in den Bootcode.

Mikrocontroller und SoCs tun das ja auch nicht... beim Samsung S3C24xx hast entweder einen NOR-Baustein im Adressraum oder du schließt einen NAND-Baustein an, wo die CPU dann mit einem CPU-internen Mikrocode die ersten 4 KB in einen CPU-internen SRAM kopiert und davon bootet.

Das sind aber alles Beispiele wo die CPU-Designer schon sehr viele Vorgaben für den System-Designer machen. Ich möchte das meine CPU von außen gesagt bekommt wo es los geht und der Rest liegt dann in der Verantwortung des System-Designers.

Gut, ist eine Designentscheidung. Normalerweise willst du ein Board möglichst einfach stricken und wenn die passende Unterstützung in der CPU schon vorhanden ist, dann ist das halt einfacher und billiger. Je flexibler die CPU ist, umso komplizierter wird der Chipsatz.

deine Entwicklung spielt eher in Richtung leistungsfähiger Mikrocontroller

Na horch mal, ich will einen full-featured General-Purpose-PC entwickeln!

Ääh, das war nicht abwertend gemeint. Du kannst auch einen ARM9 mit VGA-Ausgang, USB-Tastatur/-Maus und einer IDE-Festplatte als General-Purpose-PC nutzen... und trotzdem ist der ARM ein Mikrocontroller. Definiere mir bitte mal den Unterschied, den es da für dich gibt.

Zumindest von den prinzipiellen Möglichkeiten her soll meine Plattform in dieser Liga mitspielen. Außerdem hab ich mir vorgenommen das ich einem vergleichbar ausgestattetem System (also gleiche Menge RAM, gleiche CPU-Taktfrequenz, gleiche CPU-Anzahl) zumindest auf gleicher Augenhöhe Paroli bieten kann. Du hast doch mal geschrieben das Du so verschiedene Serversysteme hast, kannst mir ja mal ne kleine Auflistung (per PM) zukommen lassen und wenn ich soweit bin suche ich mir einen adäquaten Gegner aus und wir lassen mal von http://www.eembc.org/ den CoreMark und den MultiBench gegeneinander antreten. Du darfst auch Dein OS und Compiler selber wählen.

Muss ich ablehnen. Mein 286er mit Xenix als Server-OS ist derzeit kaputt und die ganzen dicken Server gehören der Firma, bei der ich gerade Praktikum mache. Da hab ich keinen Shellzugang, ich hab da nur dutzende Festplatten reingeschraubt.

Du meinst aber so geschätzte 100 MHz? Ich hab noch ein Dell-System mit nem Pentium aus der Zeit rumstehen, den könnte man nochmal wiederbeleben... ansonsten hab ich nur sehr kleine (33/40/66 MHz) 486er-Systeme rumstehen. Die sind ungeeignet für Benchmarks. Und lagern auf dem Dachboden - Sommer 50°C, Winter -20°C. Für richtige Multi-CPU-Systeme musst du FlashBurn fragen, der hatte wohl sowas.

Wobei ein Bekannter eine Dual-386-Maschine hat. Die trickst wohl in Hardware soweit rum, dass auch Win95 davon Vorteile hat (er meinte, Anno 1602 lief flüssig). Gab schon seltsame Tiere damals.

Gruß,
Svenska

[erik.vikinger]

Hallo,

der RAM im entsprechenden Bereich wird erst dann alloziiert, wenn der restliche RAM voll ist oder er wird komplett für IRQ-Handler reserviert (16 MB sind da für mich akzeptabel).

Ich gehe jetzt mal von einem Monolithen aus: Du willst also alle IRQ-Handler von allen Treiber in einem bestimmten Speicherbereich zusammen haben? Virtuell oder physisch? Wie soll das eigentlich gehen? Der IRQ-Handler liegt doch irgendwo mitten im Code vom Treiber, für den Compiler ist das eine Funktion wie jede andere auch. Um das zu bewerkstelligen müsstest Du IMHO vom Compiler bis zum Datei-Format ne ganze Menge Zeugs anfassen. Und das nur um im IRQ-Controller ein paar Bits einzusparen. Das kann ich irgendwie nicht nach vollziehen. Ich verlange z.B. das die IRQ-Handler auf 256Bytes ausgerichtet sind um mir die untersten 8 Bits zu sparen aber die oberen Bits bleiben definitiv erhalten. Ich könnte jetzt überlegen das auf einem konkreten System wo der Bus nur 48Bit an physischen Adressen unterstützt (HyperTransport hat ja auch so eine Beschränkung) das ich mir da bei diesen Registern die oberen Bits sparen könnte, weil so eine Adresse eh nicht möglich ist, aber grundsätzlich finde ich ist das an der falschen Stelle gespart.

Einschränkung ja, KO-Kriterium nein.

Im Prinzip ja, aber zu welchem Preis?

Der initiale Bootloader kann doch das OS erstmal in den RAM kopieren, ehe du deine Lebendgeburt vornimmst.

Der initiale Boot-Loader soll nur das OS-Image anspringen und vorher noch den Stack vorbereiten, macht also ungefähr so viel wie eine minimale crt0.asm die mehrere main-Funktionen zur Auswahl hat. Dieser Initial-Boot-Loader soll keine Veränderungen am System vornehmen. Erst der Code im OS-Image initialisiert überhaupt die DRAM-Controller damit überhaupt normaler Speicher verfügbar ist. Der Code im OS-Image soll nur von den Ressourcen abhängen die das Boot-Device grundsätzlich zur Verfügung stellt, alles was er zusätzlich benötigt muss er selber erst vorbereiten.

dann dürfte ein OS-Image vielleicht 8-12 MB haben

Bis es wirklich so viel ist dürfte es ne Weile dauern, schließlich muss ich das ja alles auch selber programmieren.

Wobei du eine Art Speicherbus sicherlich haben wirst, um MMIO da ranzuhängen;

Ja natürlich, ich hab da an PCI oder gar PCI-Express gedacht. Damit kann ich dann ganz normale Standard-HW (wie z.B. SATA-Controller oder Ethernet-Karten) anbinden. Auf meiner Plattform soll jede Ressource (also Speicher) als PCI-Device verwaltet werden, sogar der normale RAM.

wenn im physischen Adressraum Geräte auftauchen, kann das auch der Flashbaustein.

Eben deshalb soll das Boot-Device ein PCI-Gerät sein, wenn auch nur logisch weil es ja integraler Bestandteil des Chipsatzes ist.

Ich würde einfach ein Stück Adressraum mit dem ROM vorbelegen. Das ist einfacher.

Welches Stück vom Adressraum? Das ist genau die Frage die bei mir nicht der CPU-Designer sondern der System-Designer klären soll. Klar ist es einfacher wenn der CPU-Designer sagt die CPU fängt an der physischen Adresse 0 an zu arbeiten wenn sie aus dem Reset kommt aber es zwingt dem System-Designer dazu dafür zu sorgen das genau dort auch wirklich der Initial-Boot-Loader liegt. Das zweite Problem ist: Was machen die anderen CPUs in einem SMP-System wenn diese auch aufwachen sollen? Ich denke man benötigt eh einem Mechanismus um eine CPU an einer flexiblen Adresse aufwachen zu lassen und da kann ich diesen Mechanismus auch gleich für die erste CPU benutzen und spare mir die CPU-Vorgaben für das physische Speicherlayout.

Ääh, das war nicht abwertend gemeint.

Schon klar.

Definiere mir bitte mal den Unterschied, den es da für dich gibt.

Da gibt es absolut keinen Unterschied. Was man aus einer CPU macht hängt in erster Linie vom System ab in dem sie verbaut ist.

Muss ich ablehnen.

Schade, nunja da muss ich mir eben jemand anderes suchen.

Du meinst aber so geschätzte 100 MHz?

Ja, das wäre so ungefähr die Gewichtsklasse die ich mit nem FPGA einigermaßen realistisch erreichen kann. Wobei wohl ein 486 kaum ein echter Gegner ist weil er doch eine recht simple Pipeline hat und einen recht schwachen Befehlssatz, mein erster FPGA-Versuch wird mit Sicherheit keine Bessere Pipeline haben aber auf jeden Fall einen deutlich leistungsfähigeren Befehlssatz und eben 64 Register. So lange ich keinen zu großen Mist baue müsste der 486 schon mit mindestens der doppelten Taktfrequenz wie mein FPGA kommen wenn er eine reelle Chance haben soll.

Für richtige Multi-CPU-Systeme musst du FlashBurn fragen, der hatte wohl sowas.

Also wenn ich doch in die Richtung um 100MHz hin komme dann wäre ein 4fach PentiumPro (mit kleinem Multiplikator) genau das was ich mir als herausfordernden Gegner vorstelle. Der hat zwar nach außen den schwachen x86-Befehlssatz aber intern kann er gut Parallelisieren, kann Out-of-Order-Execution und Register-Renaming. Wenn ich zumindest in gewissem Grad auch Parallelisieren kann dann sollte ein PentiumPro bei gleichem Takt tatsächlich zu schlagen sein weil all die restlichen Dinge die der PentiumPro in HW macht bei mir der Compiler tun kann.


Grüße
Erik

[Svenska]

Hallo,

Du willst also alle IRQ-Handler von allen Treiber in einem bestimmten Speicherbereich zusammen haben? Virtuell oder physisch? [...] Und das nur um im IRQ-Controller ein paar Bits einzusparen.

Das hängt davon ab, wie teuer die Bits im IRQ-Controller sind. Ansonsten hast du natürlich recht. Du tauschst Softwarekomplexität gegen Hardwarekomplexität ein.

Allerdings sehe ich kein Problem damit, wenn ein Treiber seinen IRQ-Handler im Betriebssystem registrieren muss (das OS kümmert sich dann um den IRQ-Controller) und dieser Code dann an einer bestimmten Stelle im RAM liegen muss. Das kann ja auch zur Laufzeit geschehen (wie TSR-Programme, die den residenten Teil ja auch erstmal irgendwohin kopieren, damit er nicht im Weg rumliegt).

aber grundsätzlich finde ich ist das an der falschen Stelle gespart.

Hast du recht.

Der initiale Boot-Loader soll nur das OS-Image anspringen und vorher noch den Stack vorbereiten, macht also ungefähr so viel wie eine minimale crt0.asm die mehrere main-Funktionen zur Auswahl hat. Dieser Initial-Boot-Loader soll keine Veränderungen am System vornehmen. Erst der Code im OS-Image initialisiert überhaupt die DRAM-Controller damit überhaupt normaler Speicher verfügbar ist.

Okay, das ist eine Designentscheidung. Der definitiv hardwareabhängige Teil (wie z.B. DRAM-Initialisierung) gehört für mich nicht ins OS, sondern in einen hardwareabhängigen Softwarebereich, d.h. die Firmware.

Auf meiner Plattform soll jede Ressource (also Speicher) als PCI-Device verwaltet werden, sogar der normale RAM.

Sehe ich als overkill an, aber OK.

Das ist genau die Frage die bei mir nicht der CPU-Designer sondern der System-Designer klären soll.

Gefühlt wird es genau einen einzigen Chipsatz für deine CPU geben, auf einem einzigen Boardtyp. Der Systemdesigner ist der CPU-Designer, also du. Mach es dir doch einfach.

Klar ist es einfacher wenn der CPU-Designer sagt die CPU fängt an der physischen Adresse 0 an zu arbeiten wenn sie aus dem Reset kommt aber es zwingt dem System-Designer dazu dafür zu sorgen das genau dort auch wirklich der Initial-Boot-Loader liegt. Das zweite Problem ist: Was machen die anderen CPUs in einem SMP-System wenn diese auch aufwachen sollen? Ich denke man benötigt eh einem Mechanismus um eine CPU an einer flexiblen Adresse aufwachen zu lassen und da kann ich diesen Mechanismus auch gleich für die erste CPU benutzen und spare mir die CPU-Vorgaben für das physische Speicherlayout.

Du kannst auch einfach sagen, dass die Startadresse auf dem Datenbus liegen muss, wenn CPURESET deaktiviert wird. Wenn du SYSTEMRESET aktivierst, dann wird der Datenbus statisch vorbelegt, wenn du sekundäre CPUs bootest, legt die primäre CPU halt ein Wort auf den Datenbus und löst das CPURESET der anderen CPU.

Du möchtest dem Systemdesigner maximale Freiheit lassen, implementierst aber den PCI-Hostcontroller direkt innerhalb der CPU. Damit legst du fest, dass selbst eine schnellere CPU niemals ein anderes (evtl. schnelleres) Bussystem nutzen kann. Außerdem ist deine Speicheradressierung bekanntermaßen so inkompatibel zum Rest der Welt, dass du schon das OS sehr tief mit der CPU verheiraten musst. Das sehe ich als Widerspruch an. Wenn du natürlich einfach Bussysteme einsparen möchtest, dann ist das verständlich.

Für richtige Multi-CPU-Systeme musst du FlashBurn fragen, der hatte wohl sowas.

Also wenn ich doch in die Richtung um 100MHz hin komme dann wäre ein 4fach PentiumPro (mit kleinem Multiplikator) genau das was ich mir als herausfordernden Gegner vorstelle.

Finde mal solche Systeme, ich habe jedenfalls keins. Was ich habe, können wir gerne als Vergleich benutzen.

Gruß,
Svenska

[erik.vikinger]

Hallo,

Das hängt davon ab, wie teuer die Bits im IRQ-Controller sind.

Wenn der IRQ-Controller tausende IRQs verwalten kann und jeder IRQ eine eigenen Adresse haben kann dann kommen da schon ein paar Transistoren zusammen aber da nimmt man dann eh SRAM o.ä. für. Da ich ja nur einen IRQ-Handler (im Micro-Kernel) für alle HW-IRQs hab benötige ich im IRQ-Controller auch nur ein einziges Register dafür, da ist der Preis auf jeden Fall sehr gering.

Allerdings sehe ich kein Problem damit, wenn ein Treiber seinen IRQ-Handler im Betriebssystem registrieren muss (das OS kümmert sich dann um den IRQ-Controller) und dieser Code dann an einer bestimmten Stelle im RAM liegen muss. Das kann ja auch zur Laufzeit geschehen (wie TSR-Programme, die den residenten Teil ja auch erstmal irgendwohin kopieren, damit er nicht im Weg rumliegt).

Klar meldet der Treiber seinen IRQ-Handler beim OS an aber er gibt dabei auch nur den Einsprungspunkt für seinen IRQ-Handler bekannt und nicht wie viele Code-Bytes der belegt und was für Funktionen dann sonst noch (von dieser Handler-Funktion) so alles aufgerufen werden können. Den IRQ-Handler aus einem Treiber heraus zu filetieren stelle ich mir extremst kompliziert vor. Bei den TSR (ich nehme mal an Du meinst das was zu DOS-Zeit so üblich war) ist die Sache ganz anders, war war der TSR-Teil quasi ein eigenständiges Programm das in das Haupt-Programm mit integriert wurde.

Der definitiv hardwareabhängige Teil (wie z.B. DRAM-Initialisierung) gehört für mich nicht ins OS, sondern in einen hardwareabhängigen Softwarebereich, d.h. die Firmware.

Da bleibt ja eigentlich nur die DRAM-Initialisierung, alles andere wird erst später im laufenden OS in Betrieb genommen. Aber so ein bisschen Recht hast Du schon, wenn ich die Möglichkeit habe in dem Flash mehrere Images zu haben dann könnte da auch eines mit system-spezifischen Funktionen sein. Das heißt das ich eine Art Firmware hätte die nicht per INT o.ä. benutzt wird sondern eine Tabelle mit den unterstützen Funktionen und den zugehörigen Einsprungspunkten am Anfang bietet. Da könnten z.B. Funktionen wie RAM-Größe ermitteln oder RAM initialisieren oder eventuell auch Anzahl der CPUs ermitteln und CPU in Betrieb nehmen drin sein. Diesen Gedanken muss ich mal notieren. So lange ich genau ein OS auf genau einem System habe ist das uninteressant aber wenn ich doch mal unterschiedliche HW-Implementierungen haben sollte könnte diese Idee sich als nützlich erweisen. Danke!

Auf meiner Plattform soll jede Ressource (also Speicher) als PCI-Device verwaltet werden, sogar der normale RAM.

Sehe ich als overkill an, aber OK.

Ich meine ja nicht das ich zur Verbindung der CPUs untereinander und mit dem Chipsatz PCI(e) einsetzen will sondern nur das alle physischen CPUs so einen PCI-Config-Space zur Verfügung stellen. Die CPUs wären dann alle im virtuellen PCI-Bus 0 und das Device 31 wäre der Chip-Satz in dem eine oder mehrere PCI-Funktionen dann als PCI2PCI-Bridges einen Root-Port nach draußen bieten.

Der Systemdesigner ist der CPU-Designer, also du. Mach es dir doch einfach.

Die Personalunion ist einfach ein Zwang der Umstände, mir hilft ja keiner. Und wenn ich drauf aus wäre es mir einfach zu machen wäre ich nicht intelligent geworden!

Du kannst auch einfach sagen, dass die Startadresse auf dem Datenbus liegen muss

Ich habe keinen Datenbus der alle CPUs verbindet, ich möchte Punkt-zu-Punkt-Verbindungen benutzen und dafür die tollen GBit-SERDES der aktuellen FPGAs benutzen. Ich muss das also eh alles mit Messages machen. Ich kann Dir nur empfehlen mal die Spezifikationen zu HyperTransport und PCI-Express zu lesen, die bauen beide auf die selben PCI-Konzepten (Management, Config-Space usw.) auf auch wenn die Realisierungen sich in vielen Details doch extrem unterscheiden (auch gegenüber dem klassischen parallelen Original).

Finde mal solche Systeme, ich habe jedenfalls keins.

Hab ich bereits bemerkt, man findet keine PentiumPro-Server-Systeme mehr bei ebay & co.

Was ich habe, können wir gerne als Vergleich benutzen.

Danke für Dein Angebot.


Grüße
Erik

[Svenska]

Hallo,

Der definitiv hardwareabhängige Teil (wie z.B. DRAM-Initialisierung) gehört für mich nicht ins OS, sondern in einen hardwareabhängigen Softwarebereich, d.h. die Firmware.

Da bleibt ja eigentlich nur die DRAM-Initialisierung, alles andere wird erst später im laufenden OS in Betrieb genommen.

Mir fallen da spontan noch die Bootmedien ein. Schließlich will man nicht immer ein vorgefertigtes OS booten können (was, wenn man es kaputtkonfiguriert hat?), sondern auch mal von so Dingen wie USB-Festplatten, Speicherkarten, TFTP-Server und so. Wenn du deinen Flashbaustein nur als "ein weiteres Bootmedium" betrachtest, dann hast du die Trennung von Firmware wieder drin.

Aber so ein bisschen Recht hast Du schon, wenn ich die Möglichkeit habe in dem Flash mehrere Images zu haben dann könnte da auch eines mit system-spezifischen Funktionen sein. Das heißt das ich eine Art Firmware hätte die nicht per INT o.ä. benutzt wird sondern eine Tabelle mit den unterstützen Funktionen und den zugehörigen Einsprungspunkten am Anfang bietet. Da könnten z.B. Funktionen wie RAM-Größe ermitteln oder RAM initialisieren oder eventuell auch Anzahl der CPUs ermitteln und CPU in Betrieb nehmen drin sein.

Du betrachtest also dein gesamtes Betriebssystem wie bei x86 das BIOS. Finde ich unpraktisch. Ich würde im Flash eine Firmware bauen, der hardwarespezifisch ist und DRAM, Console und Bootmedium initialisiert, dann eventuell eine Auswahl erlaubt. Das Bootmedium kann ja dein OS im gleichen Flash sein, das schließt sich nicht aus. Außerdem übergibt diese Firmware an dein OS die elementaren Informationen wie RAM-Größe, Adressräume und so weiter.

Das ist nicht nur sinnvoll, um ein zweites OS auf deine CPU zu bringen, sondern auch, um dein OS auf eine ähnliche CPU (Version 2) zu bringen.

Der Systemdesigner ist der CPU-Designer, also du. Mach es dir doch einfach.

Die Personalunion ist einfach ein Zwang der Umstände, mir hilft ja keiner. Und wenn ich drauf aus wäre es mir einfach zu machen wäre ich nicht intelligent geworden!

Ja, dank des kleinen Teams muss doch eine sinnvolle, gemeinsame, Zusammenarbeit möglich sein! Oder lebt ihr in verschiedenen Staaten ohne Internet?

Du kannst auch einfach sagen, dass die Startadresse auf dem Datenbus liegen muss

Ich habe keinen Datenbus der alle CPUs verbindet, ich möchte Punkt-zu-Punkt-Verbindungen benutzen und dafür die tollen GBit-SERDES der aktuellen FPGAs benutzen. Ich muss das also eh alles mit Messages machen. Ich kann Dir nur empfehlen mal die Spezifikationen zu HyperTransport und PCI-Express zu lesen, die bauen beide auf die selben PCI-Konzepten (Management, Config-Space usw.) auf auch wenn die Realisierungen sich in vielen Details doch extrem unterscheiden (auch gegenüber dem klassischen parallelen Original).

Mit HyperTransport hab ich mich mal am Rande befasst, aber da gibt es natürlich keinen klassischen Bus mehr. Okay.

Gruß,
Sebastian

[erik.vikinger]

Hallo,

Mir fallen da spontan noch die Bootmedien ein. Schließlich will man nicht immer ein vorgefertigtes OS booten können (was, wenn man es kaputtkonfiguriert hat?), sondern auch mal von so Dingen wie USB-Festplatten, Speicherkarten, TFTP-Server und so. Wenn du deinen Flashbaustein nur als "ein weiteres Bootmedium" betrachtest, dann hast du die Trennung von Firmware wieder drin.

So lange ich nur mein eines OS habe bin ich der Meinung das ich keine Firmware benötige aber für später hast Du grundsätzlich recht. Das Problem ist das die Firmware fast alles machen muss was das OS auch tut, also DRAM anschalten, PCI-Devices traversieren und mit Ressourcen versorgen (zumindest die nützlichen) und dann auch einige Devices in Betrieb nehmen (wie z.B. AHCI-SATA-Controller oder USB-Controller). Für den ersten Moment sehe ich da vor allem doppelte Arbeit (oder zumindest einen Mehraufwand) weil die selbe Funktionalität ja mehrfach vorhanden sein muss (sicher kann man in vielen Fällen auf den selben Quell-Code zurückgreifen). Diese zusätzliche Arbeit bringt mir aber im ersten Schritt keinen Nutzwert sondern verlängert nur die Boot-Zeit. Wenn ich irgendwann mal soweit bin das ich auch mal ein OS von woanders booten möchte kann ich dann immer noch ein Firmware-Image parallel zu dem festen OS-Image in den Flash packen. Ob ich dann versuche einen vorhandenen Boot-Loader (wie z.B. uboot) zu portieren oder mich am vorhandenen OS-Quell-Code schadlos halte steht noch in den Sternen aber möglich ist es auf jeden Fall. Schön wäre es auch wenn diese Firmware in der Lage ist eine GUI als Auswahlmenü für die vorhandenen Flasch-Images anzubieten.

Du betrachtest also dein gesamtes Betriebssystem wie bei x86 das BIOS.

Ja, eine Trennung macht IMHO für den ersten Anlauf absolut keinen Sinn.

Außerdem übergibt diese Firmware an dein OS die elementaren Informationen wie RAM-Größe, Adressräume und so weiter.

Genau da sehe ich ein Problem, ich möchte nicht das irgendeine Firmware dem OS sagt wo was ist sondern ich möchte dass das OS selber bestimmen kann wo was hinkommt. Die einzigste Ressource die da ist wenn das OS-Image angesprungen wird ist das Boot-Device selber und alles andere kann das OS so im physischen Adressraum verteilen wie es das möchte. Deshalb ja auch alles als PCI-Device damit das OS einen generischen Mechanismus hat mit dem jeder Ressource (selbst dem normalen RAM) eine Adresse zugewiesen werden kann.

Ja, dank des kleinen Teams muss doch eine sinnvolle, gemeinsame, Zusammenarbeit möglich sein! Oder lebt ihr in verschiedenen Staaten ohne Internet?

Ich denke dieses Team kann recht gut kooperieren und kommunizieren. Daher wurde beschlossen wer für was zuständig ist und einer dieser Beschlüsse lautet das die CPU absolut keine Vorgaben macht was den physischen Adressraum angeht, es gibt also absolut keine hartcodierten Adressen in der CPU. Ich denke dieser Beschluss ist zum Vorteil aller beteiligten Entwickler.


Grüße
Erik

[Svenska]

Hallo,

Das Problem ist das die Firmware fast alles machen muss was das OS auch tut, also DRAM anschalten, PCI-Devices traversieren und mit Ressourcen versorgen (zumindest die nützlichen) und dann auch einige Devices in Betrieb nehmen (wie z.B. AHCI-SATA-Controller oder USB-Controller).

Im einfachsten Fall wird der DRAM eingeschaltet und von einem fest vorgegebenen Bootdevice gestartet, welches von der Firmware aktiviert werden muss. Das OS sollte niemals den DRAM einschalten müssen - das wurde von der Firmware getan; keine doppelte Arbeit. Und das Bootdevice zu aktivieren muss ohnehin getan werden; wenn die Firmware im gleichen Flash liegt wie das OS-Image, dann ist das nichtmal nötig. Auch keine doppelte Arbeit.

Für den ersten Moment sehe ich da vor allem doppelte Arbeit (oder zumindest einen Mehraufwand) weil die selbe Funktionalität ja mehrfach vorhanden sein muss (sicher kann man in vielen Fällen auf den selben Quell-Code zurückgreifen). Diese zusätzliche Arbeit bringt mir aber im ersten Schritt keinen Nutzwert sondern verlängert nur die Boot-Zeit.

Ob nun eine Firmware den RAM aktiviert und dann ein OS mit Informationen darüber startet oder ob die Firmware "Code" ausführt, der den RAM aktiviert, Informationen darüber rauspult und dann zu einem OS mutiert, finde ich nicht als Unterschied.

Fass den Begriff "Firmware" nicht zu weitgreifend auf. Unter Firmware verstehe ich den Code, der die Initialisierung der Hardware in einen Zustand, in dem Code ohne tiefgreifende Kenntnis der Hardware ausgeführt werden kann, vornimmt. Mehr nicht. Alles, was darüber geht (also TUI/GUI, Bootmedienauswahl, ...) fällt für mich unter den Begriff BIOS.

Außerdem übergibt diese Firmware an dein OS die elementaren Informationen wie RAM-Größe, Adressräume und so weiter.

Genau da sehe ich ein Problem, ich möchte nicht das irgendeine Firmware dem OS sagt wo was ist sondern ich möchte dass das OS selber bestimmen kann wo was hinkommt.

Die Firmware gibt dem OS nicht vor, wo die OS-Bestandteile hingehören, sondern die Firmware verrät dem OS, wieviel RAM vorhanden ist und wo er sich (physisch) befindet. Mal abgesehen ist es nicht "irgendeine" Firmware, sondern genau die Firmware, die als einzige genaue Informationen über die Hardware weiß.

Theoretisch sollte ein OS einigermaßen agnostisch gegenüber der Plattform sein. Außerdem legt dein OS am Ende sowieso alles wesentliche an fixe Adressen, oder möchtest du die Position des RAMs bei jedem Neustart von einem Zufallsgenerator auswürfeln? Im Betrieb wirst du die physische Basisadresse des Speichers auch nicht ändern wollen.

Lass doch die Firmware einen vernünftigen Zustand herstellen, den das OS ohnehin herstellen würde.

Daher wurde beschlossen wer für was zuständig ist und einer dieser Beschlüsse lautet das die CPU absolut keine Vorgaben macht was den physischen Adressraum angeht, es gibt also absolut keine hartcodierten Adressen in der CPU. Ich denke dieser Beschluss ist zum Vorteil aller beteiligten Entwickler.

CPU != Chipsatz != OS.

An einer Stelle machst du definitiv Vorgaben über den physischen Adressraum. Meine Empfehlung wäre, diese Vorgabe dort zu machen, wo sie hingehört. Die Firmware wird mit dem Chipsatz getauscht, CPU und OS eher nicht. Also gehört genau sowas in die Firmware und nicht in die CPU und nicht in das OS.

Damit wär glaub ich alles gesagt.

Gruß,
Svenska

[erik.vikinger]

Hallo,

Das OS sollte niemals den DRAM einschalten müssen - das wurde von der Firmware getan

Ich möchte aber nicht das jemand anderes als das OS den RAM einschaltet und damit seine physische Adresse festlegt. Da ich im Kernel-Mode per Default keinen virtuellen Speicher hab arbeiten bei meinem OS alle Exception/Syscall/IRQ-Handler (also der gesamte Kernel-Code) direkt mit den physischen Adressen, deswegen sollte das OS da auch die Kontrolle darüber haben wo der RAM liegt. Ich weiß das ist eine merkwürdige Design-Entscheidung aber so ist es nun mal. Bei klassischen Flat-Memory-Systemen liegt der Kernel zur Laufzeit immer an der selben virtuellen Adresse egal was das für ein Rechner ist und egal wie viel RAM dort drin steckt und egal wie der RAM im physischen Adressraum verteilt ist. Diesen Luxus habe ich nicht.

keine doppelte Arbeit.

Es geht mir weniger darum das ich eventuell 2 mal Code für die selbe Sache erstellen muss sondern darum das ich 2 unabhängige Images erstellen müsste. Außerdem bräuchte ich dann auch 2 verschiedene Aufrufkonventionen, da das Firmware-Image ja nur mit funktionierenden Stack aber ohne irgendeine aktivierte HW aufgerufen wird müsste man das OS-Image mit anderen Informationen versorgen da dort ja zumindest schon mal der RAM aktiv ist. Das ist sicher alles nicht so viel Arbeit aber ich habe im ersten Anlauf davon definitiv keinen Nutzen also kann ich auch erst mal alles an einem Stück lassen. Wenn ich später z.B. mal 2 verschiedene HW-Revisionen unterstützen möchte und dafür eine Art BIOS mit system-spezifischen Funktionen (wie RAM aktivieren) anbieten möchte kann ich mir immer noch ein geeignetes Konzept überlegen und aus dem OS-Image etwas Code rauswerfen und dafür BIOS-Calls o.ä. einbauen.

Fass den Begriff "Firmware" nicht zu weitgreifend auf. Unter Firmware verstehe ich den Code, der die Initialisierung der Hardware in einen Zustand, in dem Code ohne tiefgreifende Kenntnis der Hardware ausgeführt werden kann, vornimmt. Mehr nicht. Alles, was darüber geht (also TUI/GUI, Bootmedienauswahl, ...) fällt für mich unter den Begriff BIOS.

Okay, dann haben wir gestern ein ganz klein wenig aneinander vorbei geschrieben. Im Endeffekt sind das aber alles nur Namen, was für mich erst mal wichtig ist sind die Funktionalitäten und die will ich erst mal ein einem Stück zusammenhalten. Dann habe ich halt ein OS-Image das ein klein wenig Firmware-Code, etwas Kernel-Geburtshelfer-Code und einen gepackten Kernel plus gepackter Personality enthält. Für den ersten Anlauf ist das sicher komplex genug da möchte ich mir nicht auch noch Gedanken darüber machen wie ich das über mehrere Images verteile und wie die sich gegenseitig benutzen.

Mal abgesehen ist es nicht "irgendeine" Firmware, sondern genau die Firmware, die als einzige genaue Informationen über die Hardware weiß.

Welche Informationen denn? Aus meiner Sicht ist der physische Adressraum absolut leer, vom Boot-Device einmal abgesehen, wenn das OS-Image gestartet wird. Selbst wenn der Kernel aktiviert wurde und das OS zum ersten mal 100% einsatzbereit ist ist da nur der RAM hinzugekommen. Alle anderen HW-Komponenten egal ob im Chipsatz integriert, als On-Board-Chip oder als Einsteckkarte sind zu diesem Zeitpunkt noch im Reset. Mit Ausnahme von der Methode mit der der RAM aktiviert werden muss (was ja von der konkreten HW abhängt) gibt es da IMHO keine Information die die Firmware haben könnte. Beim x86-PC wo das BIOS schon alles mögliche gemacht hat bevor auch nur mal ein Boot-Sektor von irgendeinem Massenspeicher geladen wird (und danach noch Unmengen an Services anbietet) ist das natürlich was völlig anderes. Wenn ich irgendwann später wirklich mal eine Art BIOS programmieren will das dann Dinge wie booten von TFTP oder USB-Stick anbieten soll dann muss dieses BIOS eben ein OS-Image von irgendwo laden und anschließend alle HW-Komponenten wieder deaktivieren (das entspricht auch dem Konzept von uboot) und danach dann dieses OS-Image anspringen. Auch dieses OS-Image würde das System so vorfinden wie ein OS-Image aus dem Flash. Wohin dieses Image dafür geladen werden müsste muss ich mir mal noch in Ruhe überlegen, da das Boot-Device nebem ROM, FRAM und Flash ja eh auch normalen RAM anbieten muss könnte ich auch einfach einen kleinen DRAM-Chip anstatt SRAM benutzen und einen simplen DRAM-Controller integrieren der nicht konfiguriert werden muss. Dann hätte ich genug RAM-Platz um so ein externes OS-Image auch im Boot-Device liegen zu haben.

Theoretisch sollte ein OS einigermaßen agnostisch gegenüber der Plattform sein.

Ein sehr guter Standpunkt, aber nur wenn es sich nur um schwachen Agnostizismus handelt (ich hab extra mal bei Wikipedia nachgelesen). Auch ein weiterer Grund warum ich jede Ressource als PCI-Device haben möchte, so braucht das OS (bzw. die Personality) am Anfang nichts zu wissen und kann trotzdem alles aus eigener Kraft in Erfahrung bringen.

oder möchtest du die Position des RAMs bei jedem Neustart von einem Zufallsgenerator auswürfeln?

Warum nicht? Das wäre doch mal was wirklich neues wenn ASLR sogar so weit geht.

Im Betrieb wirst du die physische Basisadresse des Speichers auch nicht ändern wollen.

Warum nicht? Vielleicht möchte ich ja auch beim RAM Hot-Pluging unterstützen.

Lass doch die Firmware einen vernünftigen Zustand herstellen, den das OS ohnehin herstellen würde.

Definiere Bitte "vernünftiger Zustand". Dazu müsste die Firmware aber Informationen über das OS haben und genau das will ich nicht. Es ist auf jeden Fall sinnvoll wenn die Firmware nötige Werkzeuge anbietet aber die führende Hand bleibt beim OS.

CPU != Chipsatz != OS.

Ganz genau, Teile und Herrsche! Jedes Teil hat ganz genau definierte Zuständigkeiten. CPU und Chipsatz bieten die Mittel und das OS hat das Konzept wie diese Mittel zu benutzen sind.

Meine Empfehlung wäre, diese Vorgabe dort zu machen, wo sie hingehört. Die Firmware wird mit dem Chipsatz getauscht, CPU und OS eher nicht. Also gehört genau sowas in die Firmware und nicht in die CPU und nicht in das OS.

Warum soll die Firmware Entscheidungen treffen mit deren Konsequenzen dann das OS leben muss? Nein, das finde ich nicht gut. Die Entscheidungen soll genau der treffen der auch die Konsequenzen tragen muss!

Das ist meine Meinung zu diesem Thema.


Grüße
Erik

[DeepDancer]

HI Ihrs alle,

ich hab da auch mal nen Fragchen dazu.

Gibt es irgendwo mal ne Logikschaltung für ne CPU?
Ich durchforste seit Tagen schon das Netz aber iwie will sich da nix passendes finden. Das MyCPU.eu-Projekt ist auch nicht ganz das was ich suche, denn dort wird ja ein (oder mehrere) EPROM genommen für den MicroCode, aber genau das will ich eben nicht sehen...

Versteht Ihr was ich meine?

Also falls mal noch jemand ne Idee hat wo ich weiterkommen könnte?

Grüße,
DeepDancer

[Programm Noob]

such mal nach 8081
Da finden sich Schaltpläne für

PNoob

[erik.vikinger]

Hallo,

Gibt es irgendwo mal ne Logikschaltung für ne CPU?

Auf http://opencores.org/projects gibt es den Unterpunkt "Processor", da sind von ganz Klein bis Mittelgroß ne Menge unterschiedlicher CPUs drin. Wenn Du mal was richtig Großes sehen willst dann musst Du bei SUN nach dem Quell-Code der letzten SPARC-CPUs schauen (da fällt mir jetzt leider nicht der Name ein). Für all das muss man aber VHDL oder Verilog können.

Als Logic-Schaltplan (so als würde man das wirklich mit TTL aufbauen) wirst Du CPUs kaum finden, selbst ziemlich kleine CPUs würden bei normaler Druck-Auflösung schon extrem viele Quadratmeter Papier belegen, diese Art der Hardware-Entwicklung ist heutzutage absolut nicht mehr praktikabel.


Grüße
Erik

[Svenska]

...wobei im Intel-Museum ein Intel 4004 (4bit-Prozessor), aus einzelnen Transitoren gebaut, an der Wand hängt. Allerdings in sehr groß.

[DeepDancer]

Im speziellen hab ich Interesse daran wie so ein Instructiondecode vor sich geht - und wie gesagt "hardwired"  

Gibbets da was?

Edit:
Ach ich hab mir mal die vom Intel 4004 runtergeladen und werd mir das mal zu Gemüte führen - is glaub genau das was ich suchte erst mal

[erik.vikinger]

Hallo,

Im speziellen hab ich Interesse daran wie so ein Instructiondecode vor sich geht - und wie gesagt "hardwired"

So ein Decoder ist quasi ein switch-case in Transistoren gegossen. Oft generiert man einfach entsprechend viele Signale von denen dann nur eines auf TRUE stehen darf und welches die entsprechende Verarbeitungsschaltung aktiviert. Bei einer CISC-CPU wo die Befehle aus unterschiedlich langen Byte-Sequenzen bestehen können muss davor noch eine State-Maschine kommen die so lange alle Bytes einließt bis der Befehl komplett ist, gerade bei x86 mit den vielen optionalen Präfixen und Adressierungsmodi ist das eine ziemlich komplexe Angelegenheit. Ein kleiner RISC, wie z.B. MIPS, hat einen signifikant einfacheren Decoder der wirklich nur aus einem simplen Demultiplexer besteht.


Grüße
Erik

[Dimension]

Nachdem ich mir sämtliche Posts zum Thema durchgelesen habe möchte ich zuallererst meinen Respekt zum Ausdruck bringen. Die Konzepte sind insgesamt sehr durchdacht und innovativ. Es ist wirklich gut zu erfahren, dass es noch andere Personen gibt, die sich intensiv mit der Materie auseinandersetzen.

Ab Seite 2 hat sich mir allerdings die Frage aufgedrängt, welcher Umstand zur Diskussion über die Defragmentierung des physikalischen Speichers geführt hat. Hat Paging nicht ursprünglich die essentielle Aufgabe externe Fragmentierung zu unterbinden?

Früher oder später werde ich ebenfalls mit der Fragestellung konfrontiert werden, wie der physikalische Speicher verwaltet werden soll. Aus diesem Grund habe ich mir überlegt, ob es sinnvoll wäre, pro Page jeweils nur Datentypen gleicher Größe zuzuordnen. Sowohl die Belegung innerhalb der Pages, als auch die Zuweisung der Pages würden in Tabellen festgehalten werden. Bei adäquater Implementierung in Hardware könnte freier Speicher in amortisiert konstanter Zeit zugewiesen werden. Dies würde auch die Implementierung eines Garbage Collectors in Hardware begünstigen, da der Speicher bei kurzlebigen Allokationen (zB Lokale Objekte immerhalb einer Funktion) nicht fragmentiert wird.

[kevin]

Erstmal vorneweg: Es heißt physischer Speicher, nicht physikalischer (auch wenn im Englischen beides zu physical wird).

Ich habe den Thread jetzt nicht nochmal durchgelesen, aber ich nehme an, dass der Kontext Eriks Architektur ist. Erik will sich den Overhead von Paging sparen, wenn möglich, und es daher den größten Teil der Zeit abgeschaltet lassen. Wenn man dann meistens nur noch Segmentierung zur Verfügung hat, um virtuellen Speicher zu implementieren, muss man das Fragmentierungsproblem natürlich anders lösen. Diesen Ansatz kann man für eine gute Idee halten, muss man aber nicht unbedingt.

Und damit zu deiner Frage: Wenn du nicht irgendwas genauso abgefahrenes wie Erik machst, sondern ganz normal Paging benutzt, dann sehe ich keinen Grund für deine physische Speicherverwaltung, überhaupt irgendwelche Objekte, die kleiner als eine Page sind, zu verwalten. Im Prinzip sehe ich auf x86 nur drei Größen, mit denen umzugehen sinnvoll sein könnte: 4k, 2 MB, 1 GB - also genau die möglichen Pagegrößen. Die virtuelle Speicherverwaltung ist dafür zuständig, das alles richtig zu mappen, evtl. Sachen wie Copy on Write zu implementieren und ähnliches. Auch das ist alles auf Pageebene.

Und erst darauf aufbauend, also in der dritten Ebene, ergibt es überhaupt Sinn, sich mit Allokatoren zu beschäftigen, die beliebige Objektgrößen berücksichtigen. Üblicherweise hat man da ein malloc mit Freispeicherlisten, das beliebige Objektgrößen verwalten kann. Wenn man will, kann man dann aber auch Speicherpools für Objekte gleicher Größe benutzen, die dann einfacher sind und performanter arbeiten. Die Kosten dafür sind unter Umständen, dass insgesamt mehr ungenutzter Speicher in den Pools verschwendet wird.

[Dimension]

Bei genauerem Hinsehen fiel mir auf, dass ich eine Seite vergessen hatte. Dort wurde Paging als Mittel gegen Fragmentierung ausführlich diskutiert.

Insgesamt hatte ich immer den Eindruck, dass sich sowohl Windows als auch Linux etwas schwer tun mit vielen kleineren malloc/free.