Nachrichten

21

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 02. February 2014, 18:52 »

Dann heißt es weitersuchen. Wenn der Kernel hängt, kannst du Qemu nach EIP fragen, um zu erfahren, wo genau er hängt. Da sollte sich eine Endlosschleife befinden, möglicherweise ausgeführt als Denkfehler.

Debug-Ausgaben sind sehr hilfreich. Je nachdem, wie aussagekräftig dein Exception-Handler ist, kannst es nützlich sein, den #NM-Handler zu missbrauchen. Einen NMI kann man in der Qemu-Konsole auslösen. Da Paging ebenfalls ein regelmäßig wiederkehrender unerschöpflicher Quell der Freude ist, solltest du deinem VMM-Code viel Aufmerksamkeit widmen und dessen Ergebnisse mit "info mem" und "info tlb" auf Korrektheit prüfen.

Wie kann ich Qemu nach EIP fragen?
Debug-Ausgabe habe ich mit kprintf(); gemacht und dabei ist mir aufgefallen, dass er bei dem zuvor geposteten Codeabschnitt hängt. Exeption wird von Qemu nicht ausgelöst. Bei richtiger Hardware kommt es wohl zum Triple Fault und somit kann keine Exeption ausgelesen werden!
Um das Paging brauch ich mich im Moment auch nicht zu kümmern, da Paging noch nicht aktiv ist, wenn Qemu einfach so stehen bleibt ohne weitere Aktion. Wenn ich into mem oder tlb abrufe sagt mir Qemu nur, das PG noch nicht aktiv ist.

22

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 01. February 2014, 22:33 »

ok, ist bearbeitet. Fehler bleibt.

23

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 01. February 2014, 15:52 »

Code: [Auswählen]

void pmm_free(void* page)
{
 uintptr_t index = (uintptr_t) page / 4096;
 bitmap[index / 32] |= (1 << (index / 32));
}

Mehr steht da nicht drinnen.

24

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 31. January 2014, 17:04 »

Vielleicht indem du den Code mit ordentlich Debug-Ausgaben spickst.

Diese habe ich auch Probiert und unter Qemu bleibt er bei diesem Codeabschnitt (pmm_init()) stehen:

Code: [Auswählen]

while (mmap < mmap_end) {
 if (mmap->type == 1) {
uintptr_t addr = mmap->base;
uintptr_t end_addr = addr + mmap->length;

while (addr < end_addr) {
pmm_free ((void*) addr);
addr += 0x1000;
}
}
mmap++;
}


Vielleicht kann man damit etwas anfang...

25

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 30. January 2014, 17:23 »

ok, ich habe etwas am PG gebastelt und das hat die Exeption ausgelöst. Ich habe nun den standart vom Tutorial hergestellt. Die Exeption ist zwar weg, das Problem mit dem CPU-Reset bleibt.

Qemu läuft zwar jetzt wieder aber es kommt ca. zwischen jedem 10ten und 15ten Startversuch zum Anhalten (ohne Exeption!) bei pmm_init() bzw. vmm_init().

26

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 23. January 2014, 20:54 »

Jetzt gibt er mir eine Exception 14 aus.

Page Fault:
eip=1058309
ERROR:00000101

27

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 23. January 2014, 20:33 »

Also es muss doch ein Problem mit dem Paging vom Tutorial geben, dann wenn ich PG nicht aktiviere es nicht vom CPU-Reset kommt und es auch kein Anhalten von Qemu gibt!!!

Sobald PG aktiv ==>> CPU-RESET

28

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 23. January 2014, 18:40 »

Und die Probleme bestehen leider immer noch! Zum testen auf echter Hardware lade ich noch nicht mal ein Modul, sondern nur den Kernel selbst.

29

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 23. January 2014, 18:36 »

Außerdem habe ich jetzt mmap->base und mmap->length auf max. 4GB begrenzt.

30

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 23. January 2014, 15:46 »

kernel_start & end Linker:

Code: [Auswählen]

SECTIONS
{
 . = 0x100000; //Kernel an 1MB laden
 kernel_start = .;
 .text : {
     *(multiboot)
     *(.text)
  }
 .data ALIGN(4096) : {
     *(.data)
  }
 .rodata ALIGN(4096) : {
     *(.rodata)
  }
  .bss ALIGN(4096) : {
  *(.bss)
  }

. = ALIGN(4096);
kernel_end = .;



31

Lowlevel-Coding / Re: Floppy Kabel für 5'25 Zoll gesucht

« am: 23. January 2014, 15:03 »

Welches Problem?

32

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 23. January 2014, 15:02 »

Manschmal bleibt er beim PMM stehen aber liegt wohl am Qemu, denn bei neustart läuft er weiter.

Das wäre mein erster Ansatzpunkt für das Problem. Ein Unterschied zwischen echter Maschine und Qemu sind Details des Speicherlayouts und die Belegung des Speichers durch Datenstrukturen (z.B. Multiboot-Header). Wenn die Speicherverwaltung in QEMU komische Sachen macht, dann könnte sie auf der echten Maschine noch mehr Probleme machen. Ich würde einmal versuchen herauszufinden, warum sie in QEMU nicht zuverlässig funktioniert, und überprüfen, ob sie auf der echten Maschine funktioniert.

Wie finde ich herrauß wieso Qemu manschmal bei pmm_init() stehen bleibt?

33

Lowlevel-Coding / Re: Bandlaufwerk (Floppy-Streamer)

« am: 15. January 2014, 08:33 »

Es ist kein SCSI Laufwerk, sonder ein Floppystreamer.
Ich glaube es nennt sich QIC-80.

34

Lowlevel-Coding / Bandlaufwerk (Floppy-Streamer)

« am: 14. January 2014, 20:45 »

Hallo,

ich möchte gerne Daten für ein altes Bandlaufwerk auslesen und natürlich das Bandlaufwerk danach ansteuern. Die Frage ist nur wie?

Ich finde sogut wie keine Dokumentation dafür! Die alten Bandlaufwerke nennen sich ja auch Floppy-Streamer, somit vermute ich, dass ich es irgendwie über den FDC auslesen kann bzw. steuern kann. Hat jemand Daten dazu?

L.G.

35

Lowlevel-Coding / Re: Floppy Kabel für 5'25 Zoll gesucht

« am: 14. January 2014, 20:22 »

Du brauchst ein Floppy-Kabel für ein 5,25" Laufwerk. Die alten Kabel in alten PC hatten an dem 3,5" Laufwerksdatenkabel auch ein Stecker für das 5,25", dies war nicht gedreht!

Es ist 36polig. und hängt nicht an dem IDE Steckplätze für Festplatten oder CD-Laufwerke!

36

OS-Design / Gerade herausgefunden...

« am: 14. January 2014, 16:13 »

Also Qemu bleibt auch bei pmm_init() stehen, wenn ich weit hintem im Code den Timer setze.
Vermutlich kommt Qemu nicht so schnell mit der Ausgabe hinterher, als wie es den Code verarbeitet. Somit könnte es doch etwas mit der Speicherverwaltung zu tun haben, dass er manschmal ohne am Timer zu fummeln stehen bleibt. Evtl. auch Ursache für CPU-Reset bei echter Hardware!

Mein pmm_init():

Code: [Auswählen]

void pmm_init(struct multiboot_info* mb_info)
{ /*  inititalisiert die Speicherverwaltung. Alle Speicherbereiche,
      die beim Start des Systems frei sind, müssen als frei markiert werden, der Rest als belegt.
  */     
    struct multiboot_mmap* mmap = mb_info->mbs_mmap_addr;
    struct multiboot_mmap* mmap_end = (void*)
        ((uintptr_t) mb_info->mbs_mmap_addr + mb_info->mbs_mmap_length);

    /* Per Default ist erst einmal alles reserviert */
    memset(bitmap, 0, sizeof(bitmap));

    /*
     * Nur, was die BIOS-Memory-Map als frei bezeichnet, wird wieder als frei
     * markiert
     */
    while (mmap < mmap_end) {
        if (mmap->type == 1) {
            /* Der Speicherbereich ist frei, entsprechend markieren */
            uintptr_t addr = mmap->base;
            uintptr_t end_addr = addr + mmap->length;

            while (addr < end_addr) {
                pmm_free((void*) addr);
                addr += 0x1000;
            }
        }
        mmap++;
    }

    /* Den Kernel wieder als belegt kennzeichnen */
    uintptr_t addr = (uintptr_t) &kernel_start;
    while (addr < (uintptr_t) &kernel_end) {
        pmm_mark_used((void*) addr);
        addr += 0x1000;
    }

    /*
     * Die Multibootstruktur auch, genauso wie die Liste von Multibootmodulen.
     * Wir gehen bei beiden davon aus, dass sie maximal 4k gross werden
     */
    struct multiboot_module* modules = mb_info->mbs_mods_addr;

    pmm_mark_used(mb_info);
    pmm_mark_used(modules);

    /* Und die Multibootmodule selber sind auch belegt */
    int i;
    for (i = 0; i < mb_info->mbs_mods_count; i++) {
        addr = modules[i].mod_start;
        while (addr < modules[i].mod_end) {
            pmm_mark_used((void*) addr);
            addr += 0x1000; //DEC: 4096 (4k)
        }
    }
}
Der Timer:

Code: [Auswählen]

int counter = 1193182 / 100;// FREQUENZ
outb(0x43, 0x32);
outb(0x40, counter & 0xFF);
outb(0x40, counter >> 8);
Das zu noch kurz die Anmerkung, dass der eigentliche Fehler, wie im 1.Post beschieben vorher auftratt, bevor ich den Timer gesetzt habe. Ich habe nämlich zuvor die Standartfrequenz unverändern gelassen und einfach nur den IRQ0 bzw. 32 benutz! Das Problem, dass Qemu manschmal bei pmm_init(); (jedefalls laut Textausgabe!) stehen bleibt bestand dort aber auch.

Mit vmm_map_page() mappe ich in der Funktion vmm_init() die direkt nach pmm_init() aufgerufen wird die erst 8MB Speicher virtuell gleich physischer! Vielleicht liegt auch dort der Fehler.

Vielleicht hilft dieser Post etwas dem Problem auf das Bit zu kommen!

37

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 14. January 2014, 14:37 »

Leider konnte ich den Fehler noch nicht finden. Jemand ne Idee ?

38

OS-Design / Re: Paging - Segen oder Fluch?

« am: 13. January 2014, 02:18 »

Also ich würde das Bios gerne direkt danach fragen! Allerdings wo?

In der BiosDataArea gibt es so etwas bei Offset 0x13. Leider lese ich unter Qemu nur 32000 aus, egal wieviel RAM ich einstelle. Bei einer echten Maschine konnte ich das noch nicht testen.

39

OS-Design / Re: Paging - Segen oder Fluch?

« am: 12. January 2014, 21:12 »

aber dafür hast du ja die physische Speicherverwaltung.

Ja die gibt mir im Moment ja Speicher mit pmm_alloc() zurück, aber woher weiß ich wenn der Speicher aufgebraucht ist, oder besser wo finde ich herraus wieviel physischen Speicher es gibt?

40

OS-Design / Re: Qemu = ok, echt Hardware = Auaa... ;(

« am: 12. January 2014, 18:26 »

Hmm... Auf echter Hardware läuft der Speicher. Wie gesagt, der CPU-RESET kommt erst sobald ein Task ausgeführt wird, egal ob Multiboot-Module oder "virtueller Task" im Kernel.

Qemu bleib manschmal bei dem Befehl pmm_init() stehen. Das ist der erste Befehl im Kernel, danach wird das Paging aktiviert. Aber das hat bis jetzt noch nie Probleme auf echter Hardware gemacht.