4. real-mode kernel

real-mode kernel

  • L

    Hi Leute 🙂

    bastle letztens so ein bisschen an eigenen kerneln rum.
    Natürlich nur im real-mode. Hierzu hab ich einige Fragen:

    *)Kann ich zum Anlegen von Segmenten (DS,ES,SS,CS) belibig im speicher rumhüpfen,
    oder muss ich mich auf einen bestimmten Addressbereich beschränken?
    Schliesslich will ich nicht in den BIOS Datenbereich kommen.
    Gibts da einen Addressbereich VON - BIS den ich frei nutzen kann?

    Für Eure Antwort wäre ich da sehr dankbar 🙂
    mfg 🙂

    0
  • R

    Du kannst von 0x00400 bis 0x9ffff verwenden.

    0
  • L

    thx

    gut zu wissen 🙂

    Noch eine Frage zu fat12

    1.)also ich habe eine fat12 diskette, nun pack ich mit rawrite meinen bootloader und kernel drauf. Wird da der orginale bootsector
    (mit dieser tabelle ueber sectoren usw)zerstört? Oder wird der Bootloader
    hinter der besagten sectoren-tabele des sectors 0 geschrieben?
    2.)wo wird denn der kernel hingeschrieben? Doch nicht etwa in den 2ten sector
    wo ne fat tabele ist?

    0
  • R

    Alles wird überschrieben mit rawrite. Du musst also einen eigenen Bootsektor ins Image einbauen.

    0
  • N

    Hi.

    Wenn du nicht vor hast, alle RealMode BIOS-IRQ-Handler abzuschalten, bzw. noch BIOS-Funktionen verwenden willst, gelten den Speicher betreffend noch weitere Einschraenkungen:
    Sicherheitshalber solltest du den Speicherbereich von 00000h - 007FFh meiden, da das BIOS direkt hinter der IVT noch zB. den Tastaturpuffer, einige Zeitzaehler uvm. stehen hat.

    0
  • L

    thx für Eure antworten 🙂

    Ringding schrieb:

    Alles wird überschrieben mit rawrite. Du musst also einen eigenen Bootsektor ins Image einbauen.

    hm... also:
    1.) bootsector einlesen, hinter diese fat12-infos (offset 62 bytes) den eigenen bootloader platzieren, da bleiben noch 512-62 bytes für den bootloader
    2.)erste 2 bytes des bootsectors mit nem jmpbefehl auf den Bereich nach diesen
    62bytes überschreiben. Und anschliessend wider alles in den Bootsector schreiben.
    3.)kernel in ein sector packen welcher hinter all den fat-tabellen platziert ist.
    4.)der bootloader soll nun diesen sector in den speicher einlesen und ausführen.
    5.)diesen sector (cluster) als datei irgendwie in der fattabelle markieren, dammit
    er auch als normalle Datei lesbar ist...
    6.)Sich die frage stellen, ob es doch nicht sinvoler wäre ein eigenes Dateisystem zu entwerfen 😉

    @Nobuo T

    thx
    Noch mal eine Frage:
    1.)Kernelspace: Es wäre doch am sinnvollsten für einen kleinen kernel den
    CS auf einen bestimmte groesse zu beschränken (wie? -> KA), und ES sowie DS
    auf den gleichen zeigen zu lassen (ausser natürlich für bestimmte Zugriffe)
    2.)Userspace: Hinter dieser Kernelspace-groesse kommt der Speicherbereich für PROGRAMM-code egal ob dieser ihn selbst irgendwie segmentiert oder aber CS,DS,ES ales auf den gleichen Bereich zeigt
    3.)Über dem Kernelspace kommt das SS (stack wächst ja in die andere Richtung)
    dieser wird sowohl vom kernel wie aber auch von Userspaceprogrammen genutzt.
    Daher bräuchte sich der Anwendungsprogrammierer nicht mehr um diesen zu kümmern
    (wie bei .com Dateien).

    Ist diese Segmentierungsidee sinvoll ?

    0
  • N

    linu(x)bie schrieb:

    1.)Kernelspace: Es wäre doch am sinnvollsten für einen kleinen kernel den
    CS auf einen bestimmte groesse zu beschränken (wie? -> KA), und ES sowie DS
    auf den gleichen zeigen zu lassen (ausser natürlich für bestimmte Zugriffe)

    Im RM ist ein Segment immer 64KByte gross. Mit Begrenzen ist da also nichts (wozu auch?).
    Ansonsten ist ein solchen .com-artiges Speichermodell fuer die ersten Bootloader/Kernel-Codes IMHO durchaus naheliegend.

    linu(x)bie schrieb:

    2.)Userspace: Hinter dieser Kernelspace-groesse kommt der Speicherbereich für PROGRAMM-code egal ob dieser ihn selbst irgendwie segmentiert oder aber CS,DS,ES ales auf den gleichen Bereich zeigt

    3.)Über dem Kernelspace kommt das SS (stack wächst ja in die andere Richtung)
    dieser wird sowohl vom kernel wie aber auch von Userspaceprogrammen genutzt.
    Daher bräuchte sich der Anwendungsprogrammierer nicht mehr um diesen zu kümmern
    (wie bei .com Dateien).

    😕 Offenbar unterscheidest du zwischen "Kernelspace-groesse" (2.)und "Kernelspace" (3. - beide als Vorgaenger zu "PROGRAMM-code" und "SS" genannt), wobei ich nun nicht ganz verstanden habe, was mit "Kernelspace-groesse" gemeint ist.

    Wie auch immer - wenn du schon fuer alle laufenden Programme einen gemeinsamen Stack zur Verfuegung stellen willst, waere es IMHO sinnvoll, dafuer ein eigenes Segment mit dem Stack zu belegen und dieses vielleicht ganz nach oben (9FFFE => ss=9000; sp=0000 => beim ersten push wird zuerst sp decrementiert!) zu packen.

    Ansonsten finde ich das Konzept von DOS mit den .com-Programmen auch recht sinnvoll...

    0
Anmelden zum Antworten