Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - rizor

Seiten: 1 2 [3] 4 5 ... 27
41
Lowlevel-Coding / Re: Eine Antwort UHCI Setup-Control
« am: 28. February 2012, 17:54 »
Ich habe mir deinen Frame jetzt nicht genau angeschaut, aber ich vermute mal, dass darin ein Fehler ist.
Du wirst mit den anderen Devices nur glück haben.
42
Lowlevel-Coding / Re: Eine Antwort UHCI Setup-Control
« am: 26. February 2012, 22:09 »
Und manche Devices melden sich nicht?
Dann fragst du sie nicht.

USB ist immer Ping-Pong, wobei der Traffic immer vom OS (Host-Controller) ausgeht.
Oder du fragst sie falsch und sie können nichts mit dem Request anfangen.

Ansonsten ist die Device-Enumeration ja nicht so schwer.
43
Lowlevel-Coding / Re: Eine Antwort UHCI Setup-Control
« am: 26. February 2012, 20:26 »
Was meinst du mit gemeldet?

Naja, die Device-Enumeration findest du ja über den Device-Descriptor raus.
Da wird dir ja sogar mitgeteilt, was für einen Treiber du verwenden musst.
Also, ob es ein Class-Driver sein kann oder ob du alle geladenen Treiber fragen musst.

Grüße,
rizor
44
Lowlevel-Coding / Re: Eine Antwort UHCI Setup-Control
« am: 26. February 2012, 15:31 »
Welche Devices hast du denn derzeit probiert?
Ich bezweifel, dass sich die meisten Devices so melden.

Normalerweise läuft das Init mit den Devices so ab,
dass die Devices gefragt werden und dann angeben was sie können.

z.B. Fragt das OS als erstes was es für ein Device ist, wie viele EPs das Device hat, etc.

Anhand der ersten Antwort kannst du schon erkennen, was für ein Device es ist.
Es muss angeben, ob es Vendor- oder Class-Specific ist.
Anhand dessen lässt sich schon viel ermitteln.

Kann auch nicht direkt dein Problem erkennen.

Grüße,
rizor
45
Lowlevel-Coding / Re: GDT-Alignment
« am: 07. January 2012, 17:03 »
Ich hatte bei den GDT-Tests noch kein aktives Paging.
Der Buffer-Overflow muesste an sich noch immer existieren, da ich an den Grenzen so nichts geandert habe.

Was macht LD denn noch, ausser die aktuellen Position der Zeiger zu veraendern, wenn man . = ALIGN(xxxx) macht?
46
Lowlevel-Coding / Re: GDT-Alignment
« am: 07. January 2012, 16:19 »
Hier liegt der Code: https://github.com/rizor/nerdy

Habe das Problem aber geloest.
Habe nun das Alignment auf 8-Byte gemacht, indem ich __attribute__((aligned(8))) verwende.

Wieso funktioniert es, wenn der Compiler die Entscheidung ueber das Alignment trifft, aber wenn der Linker es macht, dann klappt es nicht?
47
Lowlevel-Coding / Re: GDT-Alignment
« am: 07. January 2012, 15:56 »
Ich habe mir die GDT ausgegeben, nachdem alles initialisiert wurde (durch p gdt (siehe ersten Post)).
Da sieht alles gut aus.
Die Adressen, die in GDTR stehen, stimmen mit denen der GDT ueberein.
Wie kann es sein, dass die Teile verschoben werden?
48
Lowlevel-Coding / Re: GDT-Alignment
« am: 07. January 2012, 14:36 »
Ich habe mir das Layout angeschaut nachdem der GDT mit lgdt in das Register geladen wird.
Da sieht alles gut aus.
Danach kann ich nicht mehr nachschauen, da QEmu und Bochs dann aussteigen (Aktualisierung der Segment-Register).

Nein, ich befinde mich schon im PMode. Moechte nur die GDT von GRUB ueberschreiben.

Bei Bochs lasse ich mir die GDT direkt anzeigen.
Wenn die Deskriptoren gegen 0x1000 aligned sind, sieht alles perfekt aus (auch unter QEmu). Wenn es nicht aligned ist, erhalte ich bei bochs folgende Ausgabe:

Global Descriptor Table (base=0x001003c8, limit=39):
GDT[0x00]=??? descriptor hi=0x00000000, lo=0x00000000
GDT[0x01]=??? descriptor hi=0x00000000, lo=0x00000000
GDT[0x02]=??? descriptor hi=0x00000000, lo=0x00000000
GDT[0x03]=??? descriptor hi=0x00000000, lo=0x00000000
GDT[0x04]=Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, 32-bit
49
Lowlevel-Coding / Re: GDT-Alignment
« am: 07. January 2012, 13:46 »
Ja, der GDB sagt, dass alles gut aussieht (vom Speicherlayout her).
Allerdings kann Bochs das Ding nicht interpretieren, wenn es nicht an 0x1000 aligned ist.
Ansonsten kann er es.

Hier der Union:
struct gdt_mapping {
        uint64_t segment0 : 16;
        uint64_t base0 : 24;
        uint64_t accessed : 1;
        uint64_t segment_r_rw : 1;
        uint64_t direction : 1;
        uint64_t exec : 1;
        uint64_t segment : 1;
        uint64_t privilege : 2;
        uint64_t present : 1;
        uint64_t segment1 : 4;
        uint64_t zero : 2;
        uint64_t size : 1;
        uint64_t granularity : 1;
        uint64_t base1 : 8;
} packed;

union gdt_entry {
        uint64_t value;
        struct gdt_mapping mapping;
};

Der GDT wird nur ueber value beschrieben.
Der Rest soll nur zum Parsen dienen.
50
Lowlevel-Coding / Re: GDT-Alignment
« am: 07. January 2012, 12:44 »
Das ist an sich echt simpel.
Nur finde ich es sinnlos, extra jede Menge Speicher zu verschwenden damit der GDT laeuft, obwohl in der Intel-Spec. nichts ueber Pflichtalignment steht.

ENTRY(_start)
OUTPUT(elf32-i386)
OUTPUT_ARCH(i386:i386)

PAGE_SIZE = 0x1000;
PHYS_ADDR = 0x100000;
VIRT_ADDR = 0xC0000000;

SECTIONS
{
        . = PHYS_ADDR;

        __boot_start = .;
        .boot.text : AT(ADDR(.boot.text))
        {
                *(.multiboot)
                *(.boot.text)
                . = ALIGN(4096);
                *(.gdt)
        }
        .boot.data : AT(ADDR(.boot.data))
        {
                *(.boot.data);
                __export_start = .;
                *(.export)
                __export_end = .;
        }
        . = ALIGN(PAGE_SIZE);
        __boot_end = .;

        OFFSET = VIRT_ADDR - .;
        . = VIRT_ADDR;

        __rodata_pm_start = . - OFFSET;
        __rodata_vm_start = .;
        .text : AT(ADDR(.text) - OFFSET)
        {
                *(.text)
                *(.rodata)
        }
        . = ALIGN(PAGE_SIZE);
        __rodata_vm_end = .;
        __rodata_pm_end = . - OFFSET;

        __data_vm_start = .;
        __data_pm_start = . - OFFSET;
        .data : AT(ADDR(.data) - OFFSET)
        {
                __idt__ = . - OFFSET;
                *(.idt)
                *(.data)
                *(.bss)
        }
        . = ALIGN(PAGE_SIZE);
        __data_vm_end = .;
        __data_pm_end = . - OFFSET;

        /DISCARD/ :
         {
                *(.comment)
                *(.eh_frame)
         }
}

Momentan liegt die GDT zwar in der Boot-Sektion, das liegt aber daran, dass ich die GDT erst mal ohne MMU initialisieren moechte.

Hier noch der Code, der dafuer sorgt, dass die GDT an der richtigen Stelle liegt:

#define __gdt           __attribute__((section(".gdt")))
#define __idt           __attribute__((section(".idt")))

union gdt_entry __gdt gdt[GDT_SIZE] = {
        { .value = 0x0 },
        { .value = 0x0 },
        { .value = 0x0 },
        { .value = 0x0 },
        { .value = 0x0 }
};
51
Lowlevel-Coding / Re: GDT-Alignment
« am: 07. January 2012, 02:56 »
Achso, das wird durch den Linker entschieden.
Der sorgt fuer das Alignment
52
Lowlevel-Coding / Re: GDT-Alignment
« am: 07. January 2012, 01:57 »
QEmu meldet bei der der GPF als Error-Code 0x10und Bochs kann die GDT niht interpretieren.
Ich richte die GPF einmal an 0x1000 aus (dann klappt es) und dann an an 0x8 und dann klappt es nicht.
53
Lowlevel-Coding / GDT-Alignment
« am: 06. January 2012, 22:41 »
Nabend zusammen,

ich habe derzeit ein komisches Problem.
Meine GDT funktioniert nur, wenn ich die GDT an die Page-Size ausrichte.
Habe alle GDT-Eintraege ueberprueft und die sind korrekt.
Wenn ich die GDT an 8-Byte ausrichte (laut Intel die optimale Position), bekomme ich einen GPF.
Woran kann das liegen?

Hier mal die Eintraege aus der GDT:

{{value = 0, mapping = {segment0 = 0, base0 = 0, accessed = 0,
      segment_r_rw = 0, direction = 0, exec = 0, segment = 0, privilege = 0,
      present = 0, segment1 = 0, zero = 0, size = 0, granularity = 0, base1 = 0}},
  {value = 58434644969848831, mapping = {segment0 = 65535, base0 = 0,
      accessed = 0, segment_r_rw = 1, direction = 0, exec = 1, segment = 1,
      privilege = 0, present = 1, segment1 = 15, zero = 0, size = 1,
      granularity = 1, base1 = 0}}, {value = 58425848876826623, mapping = {
      segment0 = 65535, base0 = 0, accessed = 0, segment_r_rw = 1, direction = 0,
      exec = 0, segment = 1, privilege = 0, present = 1, segment1 = 15, zero = 0,
      size = 1, granularity = 1, base1 = 0}}, {value = 58540198086115327,
    mapping = {segment0 = 65535, base0 = 0, accessed = 0, segment_r_rw = 1,
      direction = 0, exec = 1, segment = 1, privilege = 3, present = 1,
      segment1 = 15, zero = 0, size = 1, granularity = 1, base1 = 0}}, {
    value = 58531401993093119, mapping = {segment0 = 65535, base0 = 0,
      accessed = 0, segment_r_rw = 1, direction = 0, exec = 0, segment = 1,
      privilege = 3, present = 1, segment1 = 15, zero = 0, size = 1,
      granularity = 1, base1 = 0}}}

Danke.

Gruss,
rizor
54
Lowlevel-Coding / Re: Frage zum Scheduling
« am: 29. December 2011, 21:26 »
Hi,

natuerlich macht das Sinn.
Wenn der Prozess auftaucht, wird er als Ready markiert (low-level).
Wenn du nicht nur die READY-/BLOCKED-States hast, sondern z.B. noch TERMINATED, hast du bei FCFS auch noch (medium-level).
Aber an high-level kommst du nicht vorbei, da die Prozesse trotzdem noch von READY nach RUNNING gelagert werden muessen.

Gruss,
rizor
55
Softwareentwicklung / Re: GCC veraendert den Stack nicht
« am: 28. December 2011, 07:09 »
Ich dachte auch erst, dass frame geschoben werden muss, aber beim setzen des Frames für die L1-Tabelle geht alles gut.
Da funktioniert auch das Eintragen der Flags richtig. (Frame-Adresse: 0x81000)
Habe das Problem weiter eingegrenzt.

Der Stack sieht doch gut aus, das ist ein Fehler im GDB.
Das Problem besteht darin, dass l1_tbl[l1].frame = ... nicht den Eintrag übernimmt.
Da soll ein 1MB-Frame (Adresse) eingetragen werden.
Das verstehe ich nicht, da 0x81000 ordentlich eingetragen wird.

Ich habe mir mal den ASM-Code angeschaut und was mir dabei aufgefallen ist, ist dass er die unteren 20-Bits behält und den Rest löscht (and $0xfffff, %eax).
Wieso tut der sowas?
Müsste er nicht einfach eher die unteren 12-Bit löschen und den Rest dann eintragen?

Wenn ich frame shifte, verliere ich doch Informationen, oder?
Momentan würde ich eher vermuten, dass ich Frame um 12 nach rechts shiften müsste.
56
Softwareentwicklung / GCC veraendert den Stack nicht
« am: 27. December 2011, 19:45 »
Hallo zusammen,

ich stosse momentan auf ein komisches Problem.
Bei Aufrufen von Funktionen veraendert der Kernel den Stack nicht.
Also mal ein wenig genauer:

Eine meiner Funktionen ruft eine andere auf und setzt den Stack richtig (Parameteruebergabe korrekt).
Nachdem die Funktion durchgelaufen ist, kehrt der Code zurueck und zeigt mir im GDB die Parameter der aufrufenden Funktion an.
Dabei faellt mir auf, dass der erste Parameter (der oberste auf dem Stack) der Ruecksprungadresse der aufgerufenen Funktion entspricht.
Woran liegt das?

Ich habe keine plausible Erklaerung dafuer, da der Code auch im Assembler nicht schlecht aussieht (call, ret).
Kann es sein, dass da QEmu was falsch macht und vergisst das Register zu veraendern?
Das kann ich aber fast nicht glauben, da ich auch schon ein Linux in QEmu gestartet habe und das funktioniert.


Gruss,
rizor

Edit:
Der erste Aufruf der Funktion geht aber gut und der Code laeuft ordentlich durch.

Hier mal der betroffene C-Code:
/*
 * this function sets the flags of one entry correctly
 */
static inline void __boot mmu_set_flags(vmm_space_p entry, char rw, char big) {
        entry->present = 0x1;
        entry->no_tlb_flush = 0x1;

        if (rw)
                entry->writable = 0x1;
        if (big)
                entry->big_page = 0x1;
}


/*
 * this function maps physical memory, while paging is inactive
 */
void __boot mmu_map_offline(vmm_space_p space, void* vmem,
                            void* pmem, size_t size, char rw) {
        vmm_space_p l1_tbl;
        uint32_t mapped;
        size_t alloc;
        void* frame;
        int l2, l1;

        while (size) {
                l2 = MMU_L2_INDEX(vmem);

                if (!space[l2].present &&
                    size >= MMU_PAGE_SIZE_BIG && pse_feature) {
                        space[l2].frame = (uint32_t)pmem;
                        mmu_set_flags(&space[l2], rw, 1);
                        mapped = MMU_PAGE_SIZE_BIG;
                }
                else {
                        l1 = MMU_L1_INDEX(vmem);

                        //generate a l1 table
                        if (!space[l2].present) {
                                alloc = 0x1000;
                                frame = boot_malloc(&alloc);
                                if (!alloc) {
                                        //TODO call panic
                                        while (1);
                                }
                                boot_memset(frame, 0x0, 0x1000);

                                space[l2].frame = (uint32_t)frame;
                                mmu_set_flags(&space[l2], 1, 0);
                        }
                        l1_tbl = (vmm_space_p)((uint32_t)space[l2].frame);

                        l1_tbl[l1].frame = (uint32_t)pmem;
                        mmu_set_flags(&l1_tbl[l1], rw, 0);

                        mapped = MMU_PAGE_SIZE_NORM;
                }

                vmem += mapped;
                pmem += mapped;
                size -= mapped;
        }
}

Die bearbeiteten Strukturen wurden wie folgt definiert:
struct l2_entry {
        uint32_t present : 1;
        uint32_t writable : 1;
        uint32_t userspace : 1;
        uint32_t write_through : 1;
        uint32_t no_cache : 1;
        uint32_t dirty : 1;
        uint32_t dirty_page : 1;
        uint32_t big_page : 1;
        uint32_t no_tlb_flush : 1;
        uint32_t free : 3;
        uint32_t frame: 20;
} packed;

struct l1_entry {
        uint32_t present : 1;
        uint32_t writable : 1;
        uint32_t userspace : 1;
        uint32_t write_through : 1;
        uint32_t no_cache : 1;
        uint32_t dirty : 1;
        uint32_t dirty_page : 1;
        uint32_t zero : 1;
        uint32_t no_tlb_flush : 1;
        uint32_t free : 3;
        uint32_t frame: 20;
} packed;
57
Lowlevel-Coding / Re: IDT mit einem Upper-Half-Kernel
« am: 18. December 2011, 18:51 »
Sorry, falscher Log.
Hier ist der Richtige. (etwas gekuerzt, da er 440 kB gross war, hat aber immer wieder die gleiche Exception geworfen)
58
Lowlevel-Coding / Re: IDT mit einem Upper-Half-Kernel
« am: 18. December 2011, 18:04 »
Hier ist der komplette log von qemu.
59
Lowlevel-Coding / Re: IDT mit einem Upper-Half-Kernel
« am: 18. December 2011, 17:26 »
Ja, bei mir ist das korrekt. (0x0 als Exception)
Danach folgt ein GPF, mit einem Error-Code von 0x0.
Also findet die CPU den Handler fuer die 0x0 Exception nicht.
Steht in der IDT aber korrekt drin (virtuelle Adressen, sowohl IDT als auch der ISR).

Muesste doch alles passen, oder?
60
Lowlevel-Coding / Re: IDT mit einem Upper-Half-Kernel
« am: 18. December 2011, 16:20 »
Ich sehe bei dir nichts fett gedrucktes.
Meinst du einfach die erste Zeile des neuen Dumps, direkt nach after RSM?
Seiten: 1 2 [3] 4 5 ... 27

Einloggen