Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: spaceemotion am 24. October 2010, 12:35
-
Hallo,
ich habe ein Probelm bei der ISR. Erstmal wollte ich eine einfache Implementierung und habe mich an http://www.lowlevel.eu/wiki/ISR#Einfache_Implementierung (http://www.lowlevel.eu/wiki/ISR#Einfache_Implementierung) gehalten. Sobald ich den Interrupt 0 mit
asm volatile("int $0x0");
aufrufe. Geht die mit QEMU visualisierte Maschine aus. Sämtliche Dateien finden sich hier:
sesdll1.se.funpic.de/lowlevel/ (http://sesdll1.se.funpic.de/lowlevel/)
Vielen Dank
-
Hi,
eine Sache, die mir auffällt, ist dass du in int.S die Segmentregister mit 0x20 lädst. Das ist bei dir allerdings ein Ring-3-Deskriptor. Du solltest 0x10 nehmen, weil das dein Ring 0 Datenselektor ist.
Nach dem Laden der GDT hast du außerdem die Segmentregister nicht neugeladen. Das solltest du tun, weil die Selektoren ungültig sein könnten.
Auch solltest du erstmal nicht die IRQs aktivieren, solange Softwareinterrupts nicht funktionieren. Es reicht erstmal nur eine mögliche Fehlerquelle zu haben.
-
Hi,
eine Sache, die mir auffällt, ist dass du in int.S die Segmentregister mit 0x20 lädst. Das ist bei dir allerdings ein Ring-3-Deskriptor. Du solltest 0x10 nehmen, weil das dein Ring 0 Datenselektor ist.
Nach dem Laden der GDT hast du außerdem die Segmentregister nicht neugeladen. Das solltest du tun, weil die Selektoren ungültig sein könnten.
Auch solltest du erstmal nicht die IRQs aktivieren, solange Softwareinterrupts nicht funktionieren. Es reicht erstmal nur eine mögliche Fehlerquelle zu haben.
Erstmal Vielen Dank für die schnelle Antwort.
Gut, ich habe jetzt aus 0x20 0x10 gemacht und die IRQ gelöscht. Aber wie lade ich die Segmentregister neu?
-
So wie im Artikel http://www.lowlevel.eu/wiki/GDT#Laden_der_GDT beschrieben. Das führst du einfach nach dem lgdt aus.
-
So wie im Artikel http://www.lowlevel.eu/wiki/GDT#Laden_der_GDT beschrieben. Das führst du einfach nach dem lgdt aus.
Ja, sorry, hab ich übersehen. Aber troztdem: Jetzt rebooted QEMU schon beim GDT. Der aktuelle Code ist wieder auf dem Link von oben zu finden.
-
Hi,
kann es sein, dass du irgendwas an der Methode geändert hast, mit der du den Kernel erstellst?
Der Kernel auf deiner Seite beginnt an der Adresse 0x080480ac. Das ist etwas über den 128 MB, die Qemu als RAM verwendet. Der Kernel passt also nicht mehr rein und Qemu springt ins Nirvana. Wenn ich qemu mit -m 256 starte, scheint dein Kernel zu funktionieren.
Vielleicht solltest du mal ein Linkerskript verwenden. Außerdem solltest du dich überhaupt mal mit dem Linker beschäftigen. Sowas wie #include "../main.c" führt langfristig nur zu Problemen. Ein Beispiel, wie man es besser machen kann haben wir im Artikel http://www.lowlevel.eu/wiki/Teil_4_-_Hello_World
-
Hi,
kann es sein, dass du irgendwas an der Methode geändert hast, mit der du den Kernel erstellst?
Der Kernel auf deiner Seite beginnt an der Adresse 0x080480ac. Das ist etwas über den 128 MB, die Qemu als RAM verwendet. Der Kernel passt also nicht mehr rein und Qemu springt ins Nirvana. Wenn ich qemu mit -m 256 starte, scheint dein Kernel zu funktionieren.
Vielleicht solltest du mal ein Linkerskript verwenden. Außerdem solltest du dich überhaupt mal mit dem Linker beschäftigen. Sowas wie #include "../main.c" führt langfristig nur zu Problemen. Ein Beispiel, wie man es besser machen kann haben wir im Artikel http://www.lowlevel.eu/wiki/Teil_4_-_Hello_World
Ja, ich hab einen Shell Skript geschrieben, der alles kompiliert. Ich habe, als ich QEMU eingebunden habe, gemerkt, dass ich QEMUs Speicher erweitern musste. Vielen Dank für den Tipp mit ld -Ttext=0x1000000 ... . Die Idee, das #include "../main.c" zuverhindern ist zwar schön, aber in diesem Fall, glaube ich, nicht funktionsfähig, weil es gegen das Prinzip des Kernels widerspricht.
Aber zurück zum GDT: Was habe ich falsch gemacht? Ich rufe folgenes auf: (krn1/Core/syscall.c)
set_entry(0, 0, 0, 0);
set_entry(1, 0, 0xfffff, GDT_FLAG_SEGMENT | GDT_FLAG_32_BIT |
GDT_FLAG_CODESEG | GDT_FLAG_4K_GRAN | GDT_FLAG_PRESENT);
set_entry(2, 0, 0xfffff, GDT_FLAG_SEGMENT | GDT_FLAG_32_BIT |
GDT_FLAG_DATASEG | GDT_FLAG_4K_GRAN | GDT_FLAG_PRESENT);
set_entry(3, 0, 0xfffff, GDT_FLAG_SEGMENT | GDT_FLAG_32_BIT |
GDT_FLAG_CODESEG | GDT_FLAG_4K_GRAN | GDT_FLAG_PRESENT | GDT_FLAG_RING3);
set_entry(4, 0, 0xfffff, GDT_FLAG_SEGMENT | GDT_FLAG_32_BIT |
GDT_FLAG_DATASEG | GDT_FLAG_4K_GRAN | GDT_FLAG_PRESENT | GDT_FLAG_RING3);
load_gdt();
asm("mov $0x10, %ax\t\n"
"mov %ax, %ds\t\n"
"mov %ax, %es\t\n"
"mov %ax, %fs\t\n"
"mov %ax, %gs\t\n"
"mov %ax, %ss\t\n"
"ljmp $0x8, $.1\t\n"
".1:\t\n");
Dabei sehen die Unterfunktionen so aus:
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));
}
static void 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;
}
So wie auf hier (http://www.lowlevel.eu/wiki/Teil_5_-_Interrupts#Global_Descriptor_Table (http://www.lowlevel.eu/wiki/Teil_5_-_Interrupts#Global_Descriptor_Table)) steht, stürtzt die Visualisierung ab, sobald die Segmente neugeladen sind. Laut Teil 5 bedeutet, dass das irgendwas falsch ist. Aber was?
PS: Ich hab jetzt mein ganzen Projekt Ordner auf den Link als *.zip hochgeladen. http://sesdll1.se.funpic.de/lowlevel/LionOS.zip (http://sesdll1.se.funpic.de/lowlevel/LionOS.zip)
-
Moin
Vielen Dank für den Tipp mit ld -Ttext=0x1000000 ... . Die Idee, das #include "../main.c" zuverhindern ist zwar schön, aber in diesem Fall, glaube ich, nicht funktionsfähig, weil es gegen das Prinzip des Kernels widerspricht.
So also wo wiederspricht hier was wem oder wo?
Jeder benutzt für seinen Kernel ein Linkerscript. Ich unteranderem auch und es geht alles super.
PNoob
-
Moin
Vielen Dank für den Tipp mit ld -Ttext=0x1000000 ... . Die Idee, das #include "../main.c" zuverhindern ist zwar schön, aber in diesem Fall, glaube ich, nicht funktionsfähig, weil es gegen das Prinzip des Kernels widerspricht.
So also wo wiederspricht hier was wem oder wo?
Jeder benutzt für seinen Kernel ein Linkerscript. Ich unteranderem auch und es geht alles super.
PNoob
Als ich sagte, dass sich da was widerspricht meinte ich, dass ich das
#include "../main.c"nicht entfernen kann. Natürlich kann ich einen Linker-Skript benutzen, was ich jetzt auch getan habe.
Allen in allem hat sich das Problem sowieso erledigt. Zum GDT hab ich auf http://forum.lowlevel.eu/index.php?topic=2007.0 (http://forum.lowlevel.eu/index.php?topic=2007.0) die Lösung gefunden. Aber trotzdem Danke für die Hilfe.
-
Warum kannst du das #include denn nicht entfernen? Das sieht so schon irgendwie sehr komisch aus.
-
OK dann hatte ich dich missverstanden. aber code Dateien includen ist sehr unsauber. es gibt teilweise auch lustige Probleme deswegen
PNoob