Eigenes OS?



  • "frames" ist seltsamerweise zu klein, was heißt, daß der Aufruf von

    k_memset(frames, 0, INDEX_FROM_BIT(nframes));
    

    wohl einen Teil des Kernels überschrieben hat. Lt. Quelltext hätte "frames" aber nach Aufruf von

    frames = (ULONG*)kmalloc(INDEX_FROM_BIT(nframes));
    

    0x300000 sein müssen:

    //kheap.c
    
    ULONG kmalloc(ULONG sz)
    {
     return kmalloc_int(sz, 0, 0);
    }
    
    ULONG kmalloc_int(ULONG sz, int align, ULONG *phys)
    {
      if (kheap != 0) // "kheap" ist Null beim ersten Aufruf
      {
    (...)
      }
      else
      {               // "align" ist auch Null
       if (align == 1 && (placement_address & 0xFFFFF000) )
       {
    (...)
       }
       if (phys)      // "phys" auch
       {
       *phys = placement_address;
       }
    // somit wird "placement_address" zurückgegeben
       ULONG tmp = placement_address;
       placement_address += sz;
       return tmp;
      }
    }
    

    Und "placement_address" ist:

    //kheap.h
    (...)
    heap_t* kheap = 0;
    (...)
    ULONG end               = 0x300000;    // 3 MB TODO???
    ULONG placement_address = (ULONG)&end; // <- die Adresse von "end"?????
    

    Hoffentlich hilft das weiter.


  • Mod

    @+gjm+: Danke für die Analyse, kannst Du Dir den aktuellen Code nochmals anschauen?

    Da waren leider doch noch einige plötzlich aufpoppende Fehler mit memset() anstelle k_memset in ordered_array usw., aber dennoch klappt es noch nicht richtig. Habe auch in den headern os.h, ... noch etwas Ordnung (hoffentlich) geschafft.

    Ich schiebe den aktuellen Code mal hoch, vielleicht hat jemand die entscheidende Idee zum Durchblick. Vor lauter blöden Adressen blicke ich nicht mehr durch.
    create_heap() hilft auch noch nicht. Bin nicht völlig sicher, ob das in ckernel.c sein muss. Keine Ahnung, wo der heap momentan erzeugt wird.

    Sehe vor lauter Wald die Bäume nicht mehr, aber den Code dürfte ich jetzt soweit funktionsfähig haben. Könnte sich das bitte mal jemand anschauen (fehlen nur noch die richtigen Parameter, sicher bin ich aber noch nicht)? 🙄
    http://www.henkessoft.de/OS_Dev/Downloads/20_analyze_failure.zip

    EDIT1: hier sieht die frames Anzahl (mit createheap(0x300000,...) z.B. 3674124) nun besser aus.
    es läuft ohne sti() durch bis zum Umschalten auf Paging, dann kommt der reset, kann noch an falschen Parametern liegen:
    http://www.henkessoft.de/OS_Dev/Bilder/Fehlersuche_PAGING_HEAP.PNG

    EDIT2: das Problem liegt in create_heap(...)
    Da ist etwas im hinteren Teil instabil. Auch mit Kontroll-Prints passieren da merkwürdige Sachen auf dem Bildschirm, noch dazu nicht gleich reproduzierbar.
    ..

    heap in create_heap(...) 0000B1D0h
    heap->index in create_heap(...) 00200000h
    header_t_less_than in create_heap(...) 0000A90Ch
    start in create_heap(...) 00280000h
    start ... after alignment check 00281000h

    Absturz?

    Manchmal kommt auch noch die nächste Zeile. ???
    Nach der letzten Ausgabe springt der Cursor nach (0,0)! keine Ahnung warum?
    Dann erfolgt Reset.

    Ohne sti() bekommt man mehr Infos (s.u. seaprater Post)

    Bitte um weitere Unterstützung, damit wir das Thema didaktisch angehen können.

    Ich werde mich mal zur Ablenkung auf die Key Queue als nächste Aufgabe konzentrieren.

    Diesen Paging/Heap Mist werde ich etwas schieben. Dieser verschachtelte Code mit den kreuz und quer verteilten Parametern nervt mich langsam.

    Der Code müsste für ein Tutorial entflochten und klar strukturiert werden.
    Vielleicht kennt/hat jemand etwas Besseres?

    Problemliste:
    - Beep() geht nicht (speaker)
    - Paging/Heap zum Laufen bringen

    Kurzfristige Taskliste:
    - KeyQueue aufbauen (als ersten Schritt kann man die Daten ja über eine Auswerte-Funktion in ckernel.c abholen und darstellen)
    - Paging/Heap entflechten (erst Heap und Demo, dann Paging für Multitasking)

    Auf jeden Fall danke an alle, die mich unterstützen.


  • Mod

    Letzter Stand:
    http://www.henkessoft.de/OS_Dev/Downloads/20_analyze_failure.zip ( ohne sti() )

    #include "os.h"
    
    int main()
    {
        //...
        //sti(); //ansonsten Absturz im hinteren Teil von create_heap(...)
        kheap = create_heap(0x200000, 0x400000, 0x500000, 0, 0);
        paging_install(); //TEST
    

    Bildschirmausdruck:
    http://www.henkessoft.de/OS_Dev/Bilder/Fehlersuche_PAGING_HEAP_1.PNG

    Please help. 😕


  • Mod

    - deleted -


  • Mod

    Fehler gefunden, ein kleines & zuviel vor 'end'. Man sucht immer an der falschen Stelle. Naja, zumindest beschäftigt man sich intensiv mit dem Code. Das hat seine Vorteile. 😉

    Nun endlich lauffähig: die vereinfachte Paging-Version ohne create_heap(...):
    http://www.henkessoft.de/OS_Dev/Downloads/22.zip

    Mit Bitte um Vorschläge zur Vereinfachung und Demo-Nutzung des Codes,
    z.B. Page Fault ...
    Bezüglich Didaktik denke ich darüber nach:
    *Wie kann man Paging zum Anfassen/Experimentieren darstellen?
    Welche Vorteile haben wir nun davon?
    ...
    *


  • Mod

    So nun habe ich auch die komplexe Variante mit create_heap() zum Laufen gebracht.
    @abc.w: bringt sogar eine echte page_fault_exception 😃

    http://www.henkessoft.de/OS_Dev/Downloads/20_Paging_Heap.zip

    So, nun geht's mir wieder besser. 🙂
    ... und den Blick nach vorne:

    Problemliste:
    - Beep() geht nicht (speaker)
    - Scroll in video.c schneidet erstes Zeichen in neuer Zeile ab (??)

    Kurzfristige Taskliste:
    - Paging optimieren (für Tutorial)
    - Was macht man nun mit dem Heap? - Einfache Anwendungssteuerung? (was zuerst?)
    - KeyQueue aufbauen
    - Anwendung auf KeyQueue zugreifen lassen
    - Multitasking


  • Mod

    da gibt's doch 'ne funktion 'create_heap'. die musste natürlich vorher aufrufen.

    @+fricky: Wie Du siehst ist Paging und Heap hier entkoppelt, geht also zum Glück ohne dieses create_heap(...) via kmalloc(...). 🙂



  • Erhard Henkes schrieb:

    da gibt's doch 'ne funktion 'create_heap'. die musste natürlich vorher aufrufen.

    @+fricky: Wie Du siehst ist Paging und Heap hier entkoppelt, geht also zum Glück ohne dieses create_heap(...) via kmalloc(...).

    ok, aber irgendwie musste dem heap ja sagen, wo sein speicher ist.

    Erhard Henkes schrieb:

    - Was macht man nun mit dem Heap? - Einfache Anwendungssteuerung? (was zuerst?)

    na, den user-programmen (und dem kernel, also z.b. treibern usw) die funktionen malloc(), realloc() und free() zur verfügung stellen.

    Erhard Henkes schrieb:

    - Anwendung auf KeyQueue zugreifen lassen

    hier haste für sowas einen lock-free FIFO: http://svn.akop.org/psp/tags/fuse/0.9.0.1/sound/sfifo.c
    so'n FIFO kann z.b. von einer interrupt-routine (oder anderen task) gefüllt und während des lesens müssen keine interrupts gesperrt werden. ich hab' ihn schon mal benutzt: funzt perfekt.
    🙂


  • Mod

    Danke für den Link, aber ich möchte es mit einer Datenstruktur analog BDA probieren, sieht momentan so aus:
    os.h:

    /* This defines the operatings system common data area */
    
    #define KQSIZE    100 // size of key queue
    
    typedef struct oda
    {
        // Hardware Data
        //...
    
        // Key Queue
        UCHAR  KEYQUEUE[KQSIZE];   // circular queue buffer
        UCHAR* pHeadKQ;            // pointer to the head of valid data
        UCHAR* pTailKQ;            // pointer to the tail of valid data
        UCHAR  KQ_count_read;      // number of data read from queue buffer
        UCHAR  KQ_count_write;     // number of data put into queue buffer
    }oda_t;
    
    // operatings system common data area
    oda_t ODA;
    extern oda_t* pODA;
    

    util.c (später vielleicht os.c):

    oda_t* pODA = &ODA;
    
    void initODA()
    {
        int i;
        for(i=0;i<KQSIZE;++i)
           pODA->KEYQUEUE[i]=0;          // circular queue buffer
        pODA->pHeadKQ = pODA->KEYQUEUE;  // pointer to the head of valid data
        pODA->pTailKQ = pODA->KEYQUEUE;  // pointer to the tail of valid data
        pODA->KQ_count_read  = 0;        // number of data read from queue buffer
        pODA->KQ_count_write = 0;        // number of data put into queue buffer
    }
    

    keyboard.c

    void keyboard_handler(struct regs* r)
    {
       UCHAR KEY = ScanToASCII();
       if(KEY)
       {
         *(pODA->pTailKQ) = KEY;
         ++(pODA->KQ_count_write);
    
           if(pODA->pTailKQ > pODA->KEYQUEUE)
           {
               --pODA->pTailKQ;
           }
           if(pODA->pTailKQ == pODA->KEYQUEUE)
           {
               pODA->pTailKQ = (pODA->KEYQUEUE)+KQSIZE-1;
           }
       }
       //...
    }
    

    Test in ckernel.c:

    //...
        initODA();
        printformat("KQ: %x TAIL: %x HEAD: %x", pODA->KEYQUEUE, pODA->pTailKQ, pODA->pHeadKQ);
    
        settextcolor(2,0);
    
    	int y=6;
    	while(TRUE)
    	{
    	    sleepSeconds(10);
    	    if(y>24) y=24;
    	    set_cursor(0,++y);
    	    printformat(" 10 sec: ");
    	    printformat("TAIL: %x HEAD: %x WRITE: %i ", pODA->pTailKQ, pODA->pHeadKQ, pODA->KQ_count_write);
    	    printformat("TAILCONTENT: %c %i HEADCONTENT: %c %i\n", *(pODA->pTailKQ),*(pODA->pTailKQ),*(pODA->pHeadKQ),*(pODA->pHeadKQ));
    	};
    

    ************************************************
    * Welcome to PrettyOS 0.06 *
    * Paging is activated *
    ************************************************
    KQ: 0000A1A4h TAIL: 0000A1A4h HEAD: 0000A1A4h

    10 sec: TAIL: A1A4h HEAD: A1A4h WRITE: 0 TAILCONTENT: 0 HEADCONTENT:
    10 sec: TAIL: A207h HEAD: A1A4h WRITE: 1 TAILCONTENT: 0 HEADCONTENT: a
    10 sec: TAIL: A206h HEAD: A1A4h WRITE: 2 TAILCONTENT: 0 HEADCONTENT: a
    10 sec: TAIL: A205h HEAD: A1A4h WRITE: 3 TAILCONTENT: 0 HEADCONTENT: a
    10 sec: TAIL: A204h HEAD: A1A4h WRITE: 4 TAILCONTENT: 0 HEADCONTENT: a
    10 sec: TAIL: A1FEh HEAD: A1A4h WRITE: 109 TAILCONTENT: g 103 HEADCONTE
    NT: a 97

    0xA207 = 0xA1A4 + 0x64 (KQSIZE) - 1
    passt also alles. Den Tasten-Release (KEY == 0) habe ich unterdrückt, so dass nur ein Zeichen pro Tastenanschlag in die KQ gelangt.

    Ich möchte diesen Mechanismus komplett selbst durchziehen, weil ich das derart low-level noch nicht gemacht habe, bin durch die Standard Template Library verhätschelt. 😃

    Über Lesen aus der KQ und Interrupts habe ich mir noch keine Gedanken gemacht.
    Wie geht man mit einem buffer full, also (pODA->KQ_count_write - pODA->KQ_count_read)>100 um. Da ich die Zähler momentan leichtsinnig in UCHAR definiert habe, kommt es auch noch zu einem Überlauf. 😃 Das lässt sich sicher durch ULONG in den Griff bekommen, aber prinzipiell ist das Problem dadurch nur in die weite Ferne geschoben. Es soll ja Leute geben, die ihren Rechner nie ausschalten. Bei PrettyOS ist das fast garantiert. 😉

    Wo sollte das Lese-Programm, also das alte:

    restore_cursor();
       switch(KEY)
       {
           case KINS:
               break;
           case KDEL:
               move_cursor_right();
               putch('\b'); //BACKSPACE
               break;
           case KHOME:
               move_cursor_home();
               break;
           case KEND:
               move_cursor_end();
               break;
           case KPGUP:
               break;
           case KPGDN:
               break;
           case KLEFT:
               move_cursor_left();
               break;
           case KUP:
               break;
           case KDOWN:
               break;
           case KRIGHT:
               move_cursor_right();
               break;
           default:
               printformat("%c",KEY); // the ASCII character
               break;
       }
       save_cursor();
    

    nun eigentlich hin? Der User will doch Zahlen und Buchstaben sehen, wenn er tippt. 😃 Zumindest als Demo.
    Soll ich das als getchar() in keyboard.c realisieren und in ckernel.c mal als demo in der while-Schleife (klares "Polling") laufen lassen oder habt ihr bessere Ideen?


  • Mod

    Ich habe das zunächst als k_checkKQ_and_print_char() umgesetzt, um didaktisch an unsere bisherige - von Nobuo T kritisierte - "Schreibmaschine" in keyboard_handler(...) anzuknüpfen.

    Test in ckernel:

    UINT c=0;
    	while(TRUE)
    	{
    	  if( k_checkKQ_and_print_char() )
    	  {
    	    ++c;
    	    if(c>79)
    	    {
    	      c=0;
    	      settextcolor(4,0);
    	      printformat("\nT: %x H: %x WRITE: %i Read: %i ", pODA->pTailKQ, pODA->pHeadKQ, pODA->KQ_count_write, pODA->KQ_count_read);
              printformat("*T: %c %i *H: %c %i\n", *(pODA->pTailKQ),*(pODA->pTailKQ),*(pODA->pHeadKQ),*(pODA->pHeadKQ));
              settextcolor(2,0);
    	    }
    	  }
    	}
    
    jkdfhsdjkhgksjhkjdhkjdfshjkdsfhgjkhjghdfjkghjkdfhgdjkfhkdjfhgkdjfhgkjdfhjkdfhgjk
    dfhgjkdfhksdfhksdahfksdajhfkjsdhfksdjhfksdajhfasdkhfjkasdhfkasjdfhkjasdhfksladjh
    faskdjlhfkjhsadkjfhkjasdhfjkasdfhkajsdhfjkasdfhkjasdhfjkasdhfjkasdhfjkasdhfjkasd
    hfjkhfjkasdhfjksdhfkjahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
    hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
    hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
    hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
    jjjjjjjjjjjjjjjjjjjjjjjjjjjjkkkkkkkkkkkkkkkkkkkKKKKKKKKKKKKKLAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    T: 0000A2DAh H: 0000A2DAh WRITE: 640 Read: 640 *T: j 106 *H: j 106
    T: 0000A2EDh H: 0000A2EDh WRITE: 720 Read: 720 *T: A 65 *H: A 65
    

    Test und Reaktion (welche?) auf BufferFull/Overrun fehlt noch.
    Die Pfeiltasten links/rechts kommen nicht mehr durch.
    Was man wirklich mit den Infos in der KeyQueue machen will, hängt sehr von der konkreten Anwendung ab. Ich frage mich momentan, wie man mit den Sondertasten sinnvoll umgehen sollte. Als Flags in der ODA wie bei der BDA machen sie keinen Sinn, weil man nicht weiß, zu welchem Zeichen sie gehören. Aber das lässt sich alles leicht anpassen. Vielleicht hat jemand eine glänzende Idee oder gute Erfahrungen mit eigenen OS.

    Ich schieb das Programm oben mal hoch, wenn jemand mit dem Code spielen will:
    http://www.henkessoft.de/OS_Dev/Downloads/22a.zip

    Baut man eine Verzögerungsschleife ein, so kommt Schreiben/Lesen so ab 100 Millisekunden (Warteschleife für ms habe ich nun in timer.c ergänzt) aus dem Gleichklang: http://www.henkessoft.de/OS_Dev/Downloads/22b.zip

    jksdghkdfjhgkskdfjhgkjsdfhgkjsdfhgskjdfhkhjhgdfjkhgdfkjhgkjdfhgkjdfhgkdfjhgkjdfh
    gkfdhgkdfhgkdfhgkdfhgkdfhgkdfjhgkdfhgkdfhgkfhkjdshgkjsdfjjjjjjjjjjjjjjjjjjjjjjjj
    jjjjJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAh WRITE: 662 Read: 640 *T: A 65 *H: A 65
    T: 0000A2E0h H: 0000A30Dh WRITE: 765 Read: 720 *T: A 65 *H: A 65
    

    Bleiben die Fragen, wie groß muss KQ sein und wie geht man mit einem Overrun um? (früher hat es da gepiepst 😃 ).


  • Mod

    Bezüglich der Interpretation von Scancodes habe ich folgende interessante Gliederung gefunden:
    http://www.toasteros.net/
    ..



  • Erhard Henkes schrieb:

    Bleiben die Fragen, wie groß muss KQ sein und wie geht man mit einem Overrun um?

    einfach das älteste zeichen überschreiben (overrun ignorieren). daten von der tastatur kannste als veraltet ansehen, wenn lange keiner drauf zugegriffen hat. der buffer kann auch ziemlich klein sein.
    🙂



  • +fricky schrieb:

    der buffer kann auch ziemlich klein sein.

    jup. afair nur 10 zeichen bei MS-DOS. und keiner hats gemerkt.


  • Mod

    Ja, ich denke auch, dass ein Puffer für Tastatureingaben eher max. 20 Zeichen haben sollte, denn es wirkt - siehe Beispiel mit Warteschleife oben - extrem komisch, wenn da nach dem Tippen noch fast 100 Zeichen aus der Queue auf dem Bildschirm eintrudeln. 😃



  • Erhard Henkes schrieb:

    ...extrem komisch, wenn da nach dem Tippen noch fast 100 Zeichen aus der Queue auf dem Bildschirm eintrudeln.

    vor allem brauchste dir keine gedanken darum zu machen, wie du den fall handlest, wenn die queue voll ist und neue daten eintrudeln. das problem kriegste erst bei datenquellen, wo nix verloren gehen darf.
    🙂


  • Mod

    Noch ein Nachtrag zum Thema C vs C++:
    Lowlevel Magazin ( http://lowlevel.brainsware.org/old/files/lowlevel_4.pdf ):
    ..



  • ^^objective-c bringts auch nicht so: http://kerneltrap.org/mailarchive/linux-kernel/2007/11/30/463283
    aber es gibt auch das: http://de.wikipedia.org/wiki/Singularity
    (wobei der low-level code aber in C geschrieben wurde).
    🙂


  • Mod

    ..


  • Mod

    ..



  • Erhard Henkes schrieb:

    Diese Funktion ist ebenfalls ein merkwürdiges Konstrukt:

    page_t* get_page(ULONG address, UCHAR make, page_directory_t* dir)
    {
        address /= PAGESIZE;                // address ==> index.
        ULONG table_index = address / 1024; // ==> page table containing this address
    
        if (dir->tables[table_index])       // table already assigned
        {
            return &dir->tables[table_index]->pages[address%1024];
        }
        else if(make)
        {
            ULONG phys;
            dir->tables[table_index] = (page_table_t*) k_malloc( sizeof(page_table_t), 1, &phys );
            k_memset(dir->tables[table_index], 0, PAGESIZE);
            dir->tablesPhysical[table_index] = phys | 0x7; // 111b meaning: PRESENT=1, RW=1, USER=1
            return &dir->tables[table_index]->pages[address%1024];
        }
        else
            return 0;
    }
    

    hier ist eigentlich nur das letzte 'else' überflüssig.
    🙂


Anmelden zum Antworten