Nachrichten

21

OS-Design / Re: Multiboot Information Structure

« am: 28. November 2012, 20:36 »

Was für eine Qemu-Version nutzt du?

Bei mir (QEMU emulator version 1.0.1) gibt es 0x4f für die Flags aus. (Und ich habe nur #include <stdio.h> auskommentiert damit es über Haupt Compiler, weil ich da keine 32-Bit Version von habe).

Das hört sich auf jedenfall sehr gut an. Ich habe einfach qemu in den Packetmanager eingegeben und runtergeladen. Hast du zufälligerweise einen Link zur der 1.0.1?  Ich finde da nur die Sourcecodes. (oder muss man die erst komplett kompilieren?)

22

OS-Design / Re: Multiboot Information Structure

« am: 28. November 2012, 20:04 »

Irgendwie ist der Link falsch: Hier ist der richtige:

http://www.file-upload.net/download-6866209/kernel.tar.gz.html

 

23

OS-Design / Re: Multiboot Information Structure

« am: 28. November 2012, 19:54 »

Ich habe das Ganze mal hochgeladen. Lasst euch nicht von dem pmm verwirren, der wird noch gar nicht aufgerufen, es geht dabei erstmal nur um den ersten Aufruf in der init.c. 

http://www.file-upload.net/download-68651/kernel.tar.gz.html

24

OS-Design / Re: Multiboot Information Structure

« am: 28. November 2012, 14:06 »

Hat keiner ne Idee, was da noch falsch sein könnte. 

Ich werde gleich mal ausprobieren, den Kernel als GRUB-Image zu starten.

25

OS-Design / Re: Multiboot Information Structure

« am: 27. November 2012, 15:16 »

Ich geh dann mal alle Ideen durch.

Dann geht das spekulieren weiter. Lass dir mal die übergebene Multiboot-Magic (eax) ausgeben, bzw. prüf den Wert, ob er korrekt ist.

Der ist korrekt.

Ja, das mit den Flags hast du richtig verstanden.

Ich fange dann jetzt auch mal an zu Spekulieren:
- Paging, und GDT hast du noch nicht angefasst?
- Du löschst den Bildschirm mit 0x00, statt mit grauen Leerzeichen (0x20 0x07) ?, evtl. läuft da was schief und du überschreibst die struktur
- dann sind MB_Magic(eax), MB_Info(ebx), mb_info->flags interresant
- Interrupts sind aus ?
- sind wirklich alle Felder 0, oder hast du nur stichprobenartig überprüft?
- du könntest mal eine cmdline angeben: qeum -kernel foo -append "cmdline"
  und gucken ob die korrekt übergeben wird.

-Paging habe ich noch nicht, aber GDT schon. (aber zu dem Zeitpunkt sind sie noch nicht initialisiert
-Ich lösche den Bildschirm zwar mit 0x0, aber ich habe schon ausprobiert, die clear Funktion rauszunehmen.
-MB_Magic ist ganz normal 0x1BADB002, MB_Info hat die Adresse 0x9500, mb_info->flags ist wie gesagt 0x0
-Interrupts sind zu dem Zeitpunkt aus.
-Ich habe ein Großteil der Felder überprüft.
-Was passiert denn durch die cmdline?

Hallo,

wenn du "qemu -kernel" benutzt, dann hat nach dem Start des Kernel EBX (und damit der Zeiger auf die Multiboot-Informationsstruktur) den Wert 0x9500. Die Memory Map liegt bei 0x9000 und endet bei 0x9078. Prüf mal, ob du diese Werte bestätigen kannst.

Schau mal nach, ob du bei 0x9000 die Memory Map trotzdem findest, evtl. überschreibst du dein mb_info. Möglicherweise ist auch das Linkerscript seltsam, aber vorstellen kann ich mir das nicht...

Gruß,
Svenska

Ich kriege die richtige Adresse (0x9500) übergeben, allerdings ist dort eben alles leer, deswegen kann ich auch nicht die Adresse der Memory Map beziehen. 0x9000 scheint aber auch leer zu sein.

BTW: 5000 Beitrag in diesem Forum   

26

OS-Design / Re: Multiboot Information Structure

« am: 26. November 2012, 23:04 »

Wenn du dem Bootloader nicht sagst das du die mem_map gerne hättest gibt er die dir auch nicht.

Du must das flag bit 1(also 0x2) setzen : MB_FLAGS

Das macht bei mir leider keinen Unterschied. (Zumindest wenn ich das so richtig verstanden habe):

Code: [Auswählen]

#define MB_MAGIC 0x1badb002
#define MB_FLAGS 0x2
#define MB_CHECKSUM -(MB_MAGIC + MB_FLAGS)

27

OS-Design / Re: Multiboot Information Structure

« am: 26. November 2012, 22:41 »

Also kprintf funktioniert soweit.
vor dem kprintf leere ich nur den Bildschirm, was damit auch nichts zu tun hat.
Wie kann man denn sehen ob kernel_stack kaputt ist?
Gleiches gilt für die Multiboot-Kompabilität, hier kann ich aber sagen, dass ich den Kernel immer mit qemu -kernel starte, was so weit ich weiß Multiboot vorraussetzt.
Das Linker-Script müsste eigentlich auch mit dem Tutorial übereinstimmen.

28

OS-Design / Re: Multiboot Information Structure

« am: 26. November 2012, 22:11 »

Vermutlich geht was bei der Parameterübergabe an init schief. Kannst du den Code zeigen der init aufruft? Am besten auch das was vorher kommt. Sollte ja nicht viel sein, oder?

Code: [Auswählen]

.section multiboot
 
#define MB_MAGIC 0x1badb002
#define MB_FLAGS 0x0
#define MB_CHECKSUM -(MB_MAGIC + MB_FLAGS)
 
// Der Multiboot-Header
.align 4
.int    MB_MAGIC
.int    MB_FLAGS
.int    MB_CHECKSUM

.section .text

.extern init //init.c
 
.global _start
_start:
    mov $kernel_stack, %esp
    push %ebx
    call init
Das ist eigentlich so ziemlich das selbe wie im Wiki.

29

OS-Design / Multiboot Information Structure

« am: 26. November 2012, 21:34 »

Irgendwie ist bei mir das Multiboot Information Structure leer. Ich kriege zwar eine Adresse übergeben, aber alles enthält nur 0x0.

So sieht meine Struktur dafür aus:

Code: [Auswählen]

struct multiboot_info {
  uint32_t flags;
  uint32_t mem_lower;
  uint32_t mem_upper;
  uint32_t bootdevice;
  uint32_t cmdline;
  uint32_t mods_count;
  uint32_t mods_addr;
 
  uint32_t syms_num;
  uint32_t syms_size;
  uint32_t syms_addr;
  uint32_t syms_shndx;
 
  uint32_t mmap_length;
  uint32_t mmap_addr;
  uint32_t drives_length;
  uint32_t drives_addr;
  uint32_t config_table;
  uint32_t boot_loader_name;
  uint32_t apm_table;
  uint32_t vbe_control_info;
  uint32_t vbe_mode_info;
  uint16_t vbe_mode;
  uint16_t vbe_interface_seg;
  uint16_t vbe_intferface_off;
  uint16_t vbe_interface_len;
}__attribute((packed));
Und so soll das zum Test ausgegeben werden:

Code: [Auswählen]

void init(struct multiboot_info * mb_info)
{
  ...
  kprintf("%x\n", mb_info->mmap_addr);
  ...
}
Nur funktioniert das eben nicht. 

Es scheint so, als würde eine Adresse von einer leeren Struktur übergeben werden.

30

OS-Design / Re: Multitasking im Usermode

« am: 24. November 2012, 18:36 »

Der Wert ESP=ffffff84 in dem Dump lässt vermuten, dass ESP irgendwo auf 0 gesetzt wurde. Vermutlich funktioniert die schedule-Funktion nicht richtig.

Ok. Es lag wohl daran, dass ich das tss Array falsch deklariert habe. Jetzt funktioniert es soweit. Allerdings kriege ich keine normale Exception, wenn ich asm("cli; hlt");  in einem der Tasks eingebe, sondern QEMU startet einfach neu...

/e: Das Problem lag am Interrupt Handler. Jetzt kriege ich zwar den Bluescreen, aber auch wenn die Tasks überhaupt nichts böses machen.
/e2: Ah ich habe nur dem cs einen falschen Wert mitgegeben. Jetzt klappt es.

31

OS-Design / Re: Multitasking im Usermode

« am: 24. November 2012, 14:56 »

http://pastebin.com/3eHU8170

Ich finde irgendwie nicht die Stelle, wo die CPU auf diese Adresse springt...

32

OS-Design / Re: Multitasking im Usermode

« am: 24. November 2012, 09:43 »

Die CPU springt an eine Adresse, wo kein RAM mehr ist (0x66671058 ist bei etwa 1,6 GB). Das deutet auf einen kaputten Stack hin.

Jop den Fehler hatte ich schon beim Multitasking im Ring0. Da lag es aber daran, dass ich noch keine Scrollfunktion hatte und der ganze Speicher und darüber hinaus mit a und b zu gemüllt wurden. 
Dann werde ich gleich mal auf die Fehlerjagd begeben.

33

OS-Design / Re: Multitasking im Usermode

« am: 23. November 2012, 22:33 »

Falls ihr noch irgendwelche QEMU Logs braucht, lasst es mich hören. 

Normalerweise immer das Log (ggf. auf Pastebin) posten.

Aber dein Problem hatten kürzlich erst ein paar andere: GDT_ENTRIES muss den Wert 6 haben.

Oh verdammt. Das ist natürlich ein dummer Fehler.

Jetzt kriege ich folgenden Fehler:

qemu: fatal: Trying to execute code outside RAM or ROM at 0x66671058

EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000065
ESI=00000000 EDI=00000000 EBP=8b66670c ESP=ffffff84
EIP=66671058 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0000 00000000 00000000 00000000
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 001022c0 00000080 0000e910 DPL=3 TSS32-avl
GDT=     0010a040 0000002f
IDT=     0010a080 000007ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=000007cf CCD=08708397 CCO=SUBL   
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000

Ich werde später noch die Logdatei posten.

34

OS-Design / Multitasking im Usermode

« am: 23. November 2012, 21:25 »

Ok, ich komme mal wieder nicht weiter^^

Ich habe in meinen Kernel Multitasking integriert, was nach einigen Hürden auch gut geklappt hat.
Seitdem ich aber in den Ring3 umgestiegen bin, startet QEMU einfach die ganze Zeit neu. 

Das sind die Quellcodes:

Code: [Auswählen]

#include "includes.h"

#define GDT_FLAG_DATASEGM 0x02
#define GDT_FLAG_CODESEGM 0x0a
#define GDT_FLAG_TSS 0x09

#define GDT_FLAG_SEGMENT 0x10
#define GDT_FLAG_RING0 0x00
#define GDT_FLAG_RING3 0x60
#define GDT_FLAG_PRESENT 0x80

#define GDT_FLAG_4K_GRAN 0x800
#define GDT_FLAG_32_BIT 0x400

#define GDT_ENTRIES 0x5

static uint64_t gdt[GDT_ENTRIES];

void init_gdt() 
{
  gdt_set_entry(0, 0, 0, 0);
  gdt_set_entry(1, 0, 0xfffff, GDT_FLAG_SEGMENT | GDT_FLAG_32_BIT | GDT_FLAG_CODESEGM | GDT_FLAG_4K_GRAN | GDT_FLAG_PRESENT);
  gdt_set_entry(2, 0, 0xfffff, GDT_FLAG_SEGMENT | GDT_FLAG_32_BIT | GDT_FLAG_DATASEGM | GDT_FLAG_4K_GRAN | GDT_FLAG_PRESENT);
  gdt_set_entry(3, 0, 0xfffff, GDT_FLAG_SEGMENT | GDT_FLAG_32_BIT | GDT_FLAG_CODESEGM | GDT_FLAG_4K_GRAN | GDT_FLAG_PRESENT | GDT_FLAG_RING3);
  gdt_set_entry(4, 0, 0xfffff, GDT_FLAG_SEGMENT | GDT_FLAG_32_BIT | GDT_FLAG_DATASEGM | GDT_FLAG_4K_GRAN | GDT_FLAG_PRESENT | GDT_FLAG_RING3);
  gdt_set_entry(5, (uint32_t)tss, sizeof(tss), GDT_FLAG_TSS | GDT_FLAG_PRESENT | GDT_FLAG_RING3);
 
  load_gdt();
  kprintf(P_GDT_LOADED);
}
 
void gdt_set_entry(int i, unsigned int base, unsigned int limit, int flags)
{
  gdt[i] = limit & 0xffffLL;
  gdt[i] |= (base & 0xffffffLL) << 16;
  gdt[i] |= (flags & 0xffLL) << 40;
  gdt[i] |= ((limit >> 16) & 0xfLL) << 48;
  gdt[i] |= ((flags >> 8) & 0xffLL) << 52;
  gdt[i] |= ((base >> 24) &  0xffLL) << 56;
}


void load_gdt()
{
  struct {
    uint16_t limit;
    void * pointer;
  } __attribute__((packed)) gdtp = {
    .limit = GDT_ENTRIES * 8 - 1,
    .pointer = gdt,
  };
  asm volatile("lgdt %0" : : "m" (gdtp));
  asm volatile("ltr %%ax" : : "a" (5 << 3));
 
  asm volatile("mov $0x10, %ax;"
"mov %ax, %ds;"
"mov %ax, %es;"
     "mov %ax, %ss;"
     "ljmp $0x8, $.1;"
     ".1:");
}



Code: [Auswählen]

static uint8_t stack_a[4096];
static uint8_t stack_b[4096];
static uint8_t user_stack_a[4096];
static uint8_t user_stack_b[4096];

static int current_task = -1;
static int num_tasks = 2;
static struct cpu_state* task_states[2];


void init_taskmanager()
{
  task_states[0] = init_task(stack_a, user_stack_a, task_a);
  task_states[1] = init_task(stack_b, user_stack_b, task_b);
  kprintf("Der Taskmanager wurde initialisiert\n");
}

struct cpu_state * init_task(uint8_t* stack, uint8_t* userstack, void* entry)
{
  struct cpu_state task_cpu_state = {
    .eax = 0,
    .ebx = 0,
    .ecx = 0,
    .edx = 0,
    .esi = 0,
    .edi = 0,
    .ebp = 0,
    .esp = (uint32_t)userstack + 4096,
    .eip = (uint32_t)entry,
    .cs = 0x18 | 0x03,
    .ss = 0x20 | 0x03,
    .eflags = 0x202,
  };
   
  struct cpu_state* state = (void*) (stack + 4096 - sizeof(task_cpu_state));
  *state = task_cpu_state;
  kprintf("%x\n", state->eip);
  return state;
}

struct cpu_state * schedule(struct cpu_state * cpu)
{
  if(current_task >= 0) {
    task_states[current_task] = cpu;

Code: [Auswählen]

intr_common_handler:
    //CPU-Stand sichern 
    push %ebp
    push %edi
    push %esi
    push %edx
    push %ecx
    push %ebx
    push %eax

    mov $0x10, %ax
    mov %ax, %ds
    mov %ax, %es

    push %esp
    call handle_interrupts
    mov %eax, %esp

    mov $0x23, %ax
    mov %ax, %ds
    mov %ax, %es

    pop %eax
    pop %ebx
    pop %ecx
    pop %edx
    pop %esi
    pop %edi
    pop %ebp

    add $8, %esp
    iret

Code: [Auswählen]

#include "includes.h" 

struct cpu_state * handle_interrupts(struct cpu_state * cpu)
{
  struct cpu_state * new_cpu = cpu;
 
  if(cpu->intr <= 0x1f) {
    clear();
    changeColor(0x1f);
    kprintf("\n Das Betriebssystem hat ein Problem festgestellt und muss beendet werden.\n\n");
   
    kprintf(" Interrupt:%v %d (Exception)\n", 15, (int)cpu->intr);
    kprintf(" Fehlercode:%v %x\n\n", 15, cpu->error);
       
    kprintf(" CPU zum Zeitpunkt des Interrupts:\n\n");
   
    kprintf("\teax:%v %x%vebx:%v%x\n", 10, cpu->eax, 25, 32, cpu->ebx);
    kprintf("\tecx:%v %x%vedx:%v%x\n", 10, cpu->ecx, 25, 32, cpu->edx);
    kprintf("\tesi:%v %x%vedi:%v%x\n", 10, cpu->esi, 25, 32, cpu->edi);
    kprintf("\tebp:%v %x%veip:%v%x\n", 10, cpu->ebp, 25, 32, cpu->eip);
    kprintf("\tesp:%v %x\n", 10, cpu->esp);
    kprintf("\tcs:%v %x%vss:%v%x\n", 10, cpu->cs, 25, 32, cpu->ss);
    kprintf("\tFlags:%v %x\n", 10, cpu->eflags);

    kprintf("\n Taste druecken um einen CPU-Reset auszufuehren...\n Mach dir keine Hoffnungen, ich komme wieder. :madcat:");
    outb(0x64, 0xFE);
   
    while(1) asm volatile("cli; hlt");
   
  } else {
    if(cpu->intr >= 0x20 && cpu->intr <= 0x2f) {
if(cpu->intr >= 0x28) {
   outb(0xa0, 0x20);
} else {
   outb(0x20, 0x20);
}
if(cpu->intr == 0x20) {
   new_cpu = schedule(cpu);
   tss[1] = (uint32_t)(new_cpu+1);
}
if(cpu->intr == 0x21) kb_irq_handler(cpu->intr);
    }
  }
 
  return new_cpu;
}
Falls ihr noch irgendwelche QEMU Logs braucht, lasst es mich hören. 

35

OS-Design / Re: QEMU + Tastaturtreiber

« am: 18. November 2012, 17:51 »

1. Warum muss e0_code am Anfang auf 1 stehen? Bei mir werden dann nur Nullen als Keycode ausgegeben.
2. Warum wird bei der Breakcodesache die Funktion verlassen. Man will doch auch wissen wovon es der Breakcode ist.
3. Warum steht nach dem if(e0_code) e0_code = 1. Das ändert doch garnichts

Jo, da hat wohl wer beim Abtippen ins Wiki unfug gemacht. Das Original stimmt mit dir in diesen Punkten überein:
http://git.tyndur.org/?p=tyndur.git;a=blob;f=src/modules/kbc/keyboard.c;h=4fdaadcd8fbc92e518e7788fb53157c1b806a9ec;hb=HEAD#l131

4. Muss das if(scancode==0xE0) nicht nach oben? Ansonsten wird doch einfach die Funktion verlassen und beim nächsten Einstieg werden die Werte wieder auf den Standard gesetzt.

Ah ok. So wie es in Tyndur ist, sieht meine Funktion auch aus.

Das mit dem static wusste ich noch gar nicht, gut zu wissen.
Ich weiß nicht, ob sich das mit den obigen Punkten erledigt hat, aber zu dem Punkt, dass die Werte auf den Standard gesetzt werden: Die Variablen, die als static deklariert wurden, behalten ihre alten Werte zwischen den Funktionsaufrufen und werden nur einmal beim ersten Aufruf der Funktion initialisiert.

36

OS-Design / Re: QEMU + Tastaturtreiber

« am: 18. November 2012, 11:25 »

Code: [Auswählen]

Ich habe mal ein paar Fragen zu dieser Funktion aus dem Wiki:
 
void irq_handler(uint8_t irq) {
    uint8_t scancode;
    uint8_t keycode = 0;
    int break_code = 1;
 
    // Status-Variablen fuer das Behandeln von e0- und e1-Scancodes
    static int     e0_code = 1;
    // Wird auf 1 gesetzt, sobald e1 gelesen wurde, und auf 2, sobald das erste
    // Datenbyte gelesen wurde
    static int      e1_code = 0;
    static uint16_t  e1_prev = 0;
 
    scancode = inb(0x60);
 
    // Um einen Breakcode handelt es sich, wenn das oberste Bit gesetzt ist und
    // es kein e0 oder e1 fuer einen Extended-scancode ist
    if ((scancode & 0x80) &&
        (e1_code || (scancode != 0xE1)) &&
        (e0_code || (scancode != 0xE0)))
    {
        break_code = 0;
        scancode &= ~0x80;
return;
    }
 
    if (e0_code) {
        // Fake shift abfangen und ignorieren
        if ((scancode == 0x2A) || (scancode == 0x36)) {
            e0_code = 1;
            return;
        }
 
        keycode = translate_scancode(1, scancode);
        e0_code = 1;
    } else if (e1_code == 2) {
        // Fertiger e1-Scancode
        // Zweiten Scancode in hoeherwertiges Byte packen
        e1_prev |= ((uint16_t) scancode << 8);
        keycode = translate_scancode(2, e1_prev);
        e1_code = 0;
    } else if (e1_code == 1) {
        // Erstes Byte fuer e1-Scancode
        e1_prev = scancode;
        e1_code++;
    } else if (scancode == 0xE0) {
        // Anfang eines e0-Codes
        e0_code = 0;
    } else if (scancode == 0xE1) {
        // Anfang eines e1-Codes
        e1_code = 1;
    } else {
        // Normaler Scancode
        keycode = translate_scancode(0, scancode);
    }
        // Zum Testen sollte folgendes verwendet werden:
kprintf("%c", keycode);
        //Nach erfolgreichen Tests, könnte eine send_key_event Funtkion wie bei Týndur verwendet werden
}
1. Warum muss e0_code am Anfang auf 1 stehen? Bei mir werden dann nur Nullen als Keycode ausgegeben.
2. Warum wird bei der Breakcodesache die Funktion verlassen. Man will doch auch wissen wovon es der Breakcode ist.
3. Warum steht nach dem if(e0_code) e0_code = 1. Das ändert doch garnichts
4. Muss das if(scancode==0xE0) nicht nach oben? Ansonsten wird doch einfach die Funktion verlassen und beim nächsten Einstieg werden die Werte wieder auf den Standard gesetzt.

37

OS-Design / Re: QEMU + Tastaturtreiber

« am: 17. November 2012, 13:33 »

Du musst ein EOI senden (End of Interrupt)
Hier: http://www.lowlevel.eu/wiki/PIC_Tutorial steht wie's geht

Ja so etwas ähnliches habe ich im IRQ Handler eingebaut. (So stands auch im Wiki):

Code: [Auswählen]

    if(cpu->intr >= 0x20 && cpu->intr <= 0x2f) {
kprintf("IRQ %x\n", cpu->intr);
if(cpu->intr == 0x21) kb_irq_handler(cpu->intr);
if(cpu->intr >= 0x28) {
   outb(0xa0, 0x20);
}
outb(0x20, 0x20);
    }
/e: Das hat mir weitergeholfen. http://forum.lowlevel.eu/index.php?topic=2999.msg35127#msg35127

38

OS-Design / Re: QEMU + Tastaturtreiber

« am: 16. November 2012, 17:53 »

Was genau muss man eigentlich machen, damit ein IRQ als behandelt gilt? Ich habe den Treiber nähmlich soweit wie es im Artikel beschrieben ist, allerdings empfange ich einmal den Scancode 0xFA und das wars. Danach passiert nichts mehr, außer man sendet einen IRQ mit int.

39

OS-Design / Re: QEMU + Tastaturtreiber

« am: 16. November 2012, 07:07 »

Hallo,

Qemu emuliert eine PS/2-Tastatur, unabhängig davon, ob dein Host-Rechner nun eine USB-Tastatur oder einen Touchscreen hat. Die Fehlermeldung deutet darauf hin, dass dein Tastaturtreiber komische (unspezifizierte) Dinge mit der Tastatur macht.

Installier mal ein Windows im Qemu, schau dir den Gerätemanager an und vergleiche mit der Hardware des Computers, auf dem du Qemu gestartet hast. Da dürfte eigentlich nix übereinstimmen.

Gruß,
Svenska

Es ist schonmal gut zu wissen, dass es an mir liegt. Jetzt muss ich nur noch den Fehler finden...

40

OS-Design / QEMU + Tastaturtreiber

« am: 15. November 2012, 22:17 »

Ich bins mal wieder 

Ich habe damit eingefangen einen kleinen Keyboard-Treiber zu programmieren. Wenn ich aber mein makefile ausführe kriege ich die Meldung "qemu: unsupported keyboard cmd=0xf4". (Ich starte dabei qemu mit qemu -kernel kernel)
Wahrscheinlich klappt das nicht, weil ich eine USB-Tastatur habe. Allerdings wird das ja normalerweise vom BIOS emuliert. Gibt es irgendeine Möglichkeit, dass ich das auch mit qemu hinkriege? Ich fände es blöd, wenn ich nach jedem Build er das GRUB-Image machen müsste.^^