Ergebnis 1 bis 2 von 2

Thema: (u)efi

  1. #1
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.969
    Renommee
    283

    (u)efi

    Hallo zusammen,

    ich bin ein wenig auf osdev und lowlevel gewesen. ... aber bin noch nicht sehr viel schlauer ...

    Könnte mir jemand vielleicht einen Denkanstoß geben in Form eines Grundgerüsts und der Beantwortung
    meiner Frage, ob(/wie) ich nicht einfach ein erstes C-Script (mit "efi_main"-Einstiegspunkt) kompilieren und
    es so direkt zu boot()en, damit ich im Endeffekt ...

    .. (a) eine einfache Text-Konsole in einer zweiten C-Datei erhalte, um daraus eine eigene Shell zu machen;
    .. (b) ein HAL für Treiber erhalte, damit ich so einerseits extensibel, aber auch anfangs allein für nur eine
    einzige Netzwerk-/Sound-/Grafikkarte die ersten Treiber-Notwendigkeiten erfülle (bis zum Speicher-Zugriff
    auf Grafik(karte) etc., aber wichtiger noch einen Ort für den eigenen Netzwerk-Stack);
    .. (c) wie in Linux ein "Virtual File System" im HAL-Sinne entstehen kann (für eine eigene DB @ HDD-Zugriff);

    Vor allem eben die Sache, dass ich mir vorstelle, einfach nur den (U)EFI-Boot()-Prozess vom Mainboard zu
    verwenden habe, damit mein eigenes "INIT"-Script seinen Anfang findet und ich dann schrittweise und auch
    mit Hilfe der ersten Beispiel-Konsole(/-Shell) die ersten Treiber "entwickeln" kann (vielmehr abschauen, falls
    ich noch was im Netz finde - da gibt's ja schon was für RTL8139 bspw. auf einem der o.g. Sites/Wikis), ...

    Ich weiß, ich weiß, ... das sind Anfängerfragen usw. ... die Sache ist bloß, dass ich gerne den aktuellen Stand
    mit (U)EFI aufgreifen möchte - wo ich bspw. auf HDD-Partitionen und GRUB o.ä. verzichte - um eben einfach
    nur eine erste Konsole codieren zu können - wo ich dann vermute, mit Hilfe von UEFI evtl. auf die Hardware
    erstmals zugreifen zu können?! ... die Sache ist eben nur, dass ich kein großartiges OS einfach so in C auf
    die Beine stellen möchte - es geht eher so weit, dass ich eine Shell-Grundlage schaffen möchte und einige
    Beispiele für erste Konnektivität zur Hardware usw. brauche (hoffe, ich find' da genügend Beispiele); ... alles
    weitere kann ich, denke ich, auch schon selbst danach auflösen (mehr oder minder), was sich noch so für
    den Kernel ergibt (zwar noch wenig Ahnung von Speicherverwaltung einerseits, aber ich kann ein eigenes
    Threading-System mit allg. Prozess-Verwaltung (und Prioritäten etc. - so im Sinne von Zeitquanten ;-)´ &
    die Shell und was sich eben sonst noch ergibt schonmal selbst prinzipiell codieren; später dann); ...

    Die letzte Frage wäre noch, wie ich evtl. - noch ohne weiter gesucht zu haben, weil das später kommt - ein
    "Reverse Engineering" für eigene Hardware-Treiber o.ä. durchführen kann? Achja, ein Verständnis-Problem
    gibt sich für mich auch darin, dass ich früher mal in "Ralph Browns Interrupt List" gelesen habe - und jetzt
    denke ich mir, eine Art "IO-Ports"-System o.ä. sollte laut osdev/lowlevel für Hardware-Zugriffe sorgen usw.,
    während mir die Interrupt-Liste selbst sehr veraltet vorkam ... im Prinzip wäre es das beste ...

    Ja! Eine Abstraktion zur Speicher-Verwaltung hin - aus der Vermutung heraus, dass sämtliche (HW-)I/O
    auf einem Speicher-"Mapping" basiert, wo ich nur noch (gemäß welchen "Protokolls"?) Lesen und Schreiben muss, um hier
    diverse Hardware-/Firmware-Funktionalität *adressieren* zu können. Fragt sich nur, wie ich dann letztlich "Signale aktiviere"
    o.ä. - was dann ja fast zu ASM führte, worauf ich aber eher verzichten wollte. ...

    OffTopic:

    Wenn ich die Sache mit dem "Speicher-Mapping" verfolge, dann geht es erst recht zur Logik der Übersetzungs-Tabellen hin,
    was mir das aller-aller-aller-liebste wäre. Einfache Anwendbarkeit und eine Skalierbarkeit in die vielen denkbaren, weiteren
    Systeme (bis in meine K.I.) hinein. Sprich, ich führe Speicher-Abfragen aus, um daraus zu entscheiden, wohin ich *laut den
    Tabellen* wiederum welche Information zu schreiben habe, um dann irgendwie aus den sich dabei ergebenden(!??) Verän-
    derungen weitere Rückgabe-Information auszulesen usw. ...

    *Das* jedenfalls wäre die beste Abstraktion des Ganzen - die ich notfalls auch in einem Linux-System und sowas wie "ioctl"-
    Übersetzungs-Tabellen skalieren *könnte* (aber ungerne möchte, um nicht den ganzen kernel-Salat mit zu nehmen ^.^);

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  2. #2
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.969
    Renommee
    283

    AW: (u)efi

    Ich wollte noch anmerken, dass die Sache der Speicher-Mappings im Grunde genommen doch das wichtigste für mich ist. ..

    Meine gesamte Quantensystem-K.I. baut auf solchen Übersetzungs-Tabellen auf - und ich denke, auch eine Turing-Maschine
    bspw. arbeitet nach dem Prinzip (nur eben mit Bändern o.ä.); ... wenn jemand gerade dazu Ideen hat, sei es auch nur durch
    "ioctl" in Linux gelöst, gerne her damit! ... die Frage ist eben nur, wie ich welchen Zugriff auf welche Speicher und Adressen
    erhalte bspw. ...

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •