Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken
Gespeichert 
Hallo,
Grüße
Erik
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.
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.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.
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.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.
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
