Nachrichten

21

Lowlevel-Coding / Re: QEmu greift auf falschen Speicher zu

« am: 22. February 2010, 09:16 »

Es ging mir darum. Sobald ich vom Assemblerstub aus C/C++ Code ausführe, tritt bei mir genau der gleiche Fehler auf. Wenn ich ihn behoben habe, schreiben ich, wie ich das gemacht habe...

22

Lowlevel-Coding / Re: Erkennen ob ein Programm beendet wurde.

« am: 22. February 2010, 09:13 »

Naja...
du hast ja bestimmt eine "Startup" Funktion geschrieben, die deine main-Funktion aufruft. Dort könnte man den Kernel dann per System Call anweisen, das Programm aus dem Speicher zu entfernen.
Bsp.:

Code: [Auswählen]

.global _start
.extern main
_start:

# main aufrufen
call main
# kernel anweisen, das Programm zu beenden
movl $0,%eax
int $0x80

Das ist zumindest die Vorgehensweise, die ich für mein OS geplant habe...

23

Lowlevel-Coding / Re: QEmu greift auf falschen Speicher zu

« am: 22. February 2010, 09:09 »

Bei mir tritt ein ganz ähnlicher Fehler auf, wenn nicht genau der gleiche Fehler auf...
Ich habe allerdings noch nicht herausgefunden, wie ich diesen beheben kann. Alles, was ich bisher herausgefunden habe ist, dass der Fehler nicht auftritt, wenn ich den Aufruf der C Funktion "KernelInit" aus dem GRUB Assemblerstub entfernt habe...

24

Lowlevel-Coding / Re: GRUB VESA wie aktivieren?

« am: 19. February 2010, 08:23 »

mmmhhh...
Welchen Patch hast du denn bei dem von dir kompilierten GRUB genutzt?

25

Lowlevel-Coding / Re: GRUB VESA wie aktivieren?

« am: 16. February 2010, 09:21 »

Laut Spezifikation muss das Bit 2 gesetzt werden:

Code: [Auswählen]

If bit 2 in the ‘flags’ word is set, information about the video mode table (see Boot information format) must be available to the kernel. Anhand von Bit 11 kann man im Kernel später testen, ob die vbe_* variablen in der multiboot struktur gültig sind.
 
Also sollte der Part mit den Flags 0x7 (Page align, memory info und video mode) sein. Dem entsprechend musst du dann auch deine Checksum ändern...
 
 
Hier kann man eine gepatchte und anscheinend funktionierende Version von GRUB herunterladen. Versuch mal damit ein Image zu erstellen und deinen Kernel zu laden, falls deine Version nicht funktioniert:
http://www.ninj4.net/kinetic/

26

Lowlevel-Coding / Re: GRUB VESA wie aktivieren?

« am: 15. February 2010, 15:14 »

Naja war nicht ganz der Fehler, den ich hatte...
Bei mir kam immer und überall (sogar im Emulator (qemu & bochs)) der Fehler, dass VBE 2.0 nicht unterstützt werde... Vielleicht habe ich da auch irgendwas anderes falsch gemacht... 
Ich schaue mir das mal an und probiere auch nochmal selbst GRUB zu patchen und zu kompilieren. Vielleicht funktioniert es ja dieses mal. ..

27

Lowlevel-Coding / Re: GRUB VESA wie aktivieren?

« am: 15. February 2010, 14:34 »

Wenn dein gepatchter GRUB funktioniert, kannst du diesen ja mal irgendwo hochladen. Bei mir hat das Patchen und kompilieren zwar funktioniert, nur bei der Verwendung des neu erstellten GRUBs kam immer wieder irgendeine blöde Fehlermeldung... 

28

Offtopic / Shellscript

« am: 11. February 2010, 11:42 »

Hallo,
 
ich habe mich daran gemacht, ein kleines Shellscript zu bauen. Nun frage ich mittels "Dialog" ab, für welche Architektur der Kernel gebaut werden soll, welcher compiler genutzt werden soll (momentan nur gcc) und wo der Kernel abgelegt werden soll.
 
Nun muss ich prüfen, ob der Compiler auch installiert ist. Wie macht man das am besten? Bisher bin ich nur darauf gekommen, 'gcc -v' aufzurufen und die Ausgabe entsprechend auszuwerten... kann man das nicht auch irgendwie anders (schöner) machen?
 
Gruß Christian

29

Lowlevel-Coding / Re: Verständnisfragen

« am: 10. February 2010, 10:50 »

Hiho
 
Ich habe mich vor kurzem dazu entschlossen von nasm auf den GNU Assembler umzusteigen. Unter nasm musste ich immer die "Architektur"  angeben, z.B. [BITS 32]. Muss ich das bei dem Assembler von GNU auch so ähnlich machen, oder reicht es, wenn da einfach die Option "-melf32" gesetzt wird?

30

Lowlevel-Coding / Re: Initialisieren der Bitmap will nicht

« am: 10. February 2010, 10:45 »

Dann dürfte wohl kein freier Speicher mehr da sein. 
 
Was hast du an dem Code alles verändert? Es wäre für mich einfacher, wenn du deinen Code mit den Änderungen in Form eines Zip-Archivs o.ä. mal hochlädst.

31

Lowlevel-Coding / Re: Initialisieren der Bitmap will nicht

« am: 09. February 2010, 21:44 »

Die Multibootflags dürften falsch sein.
Wenn du die Memory Map von GRUB oder zumindest mem_lower und mem_upper nutzen willst, musst du Bit 1 in den Flags setzen. Und wenn ich jetzt nicht völlig daneben liege, sollte das funktionieren, wenn du das wie folgt abänderst:

Code: [Auswählen]

#define MB_FLAGS (1<<1)

Ich hoffe, dass ich dir damit weiterhelfen konnte.

32

Lowlevel-Coding / Re: Initialisieren der Bitmap will nicht

« am: 09. February 2010, 12:17 »

Warum konvertierst du denn die Adresse in einen void-pointer? Wenn, dann sollte das in einen Zeiger der Struktur umgewandelt werden.
 
Weiterhin würde ich beim Vergleichen der beiden Variablen (mmap und mmap_end) diese jeweils in Ganzzahlen konvertieren, zumindest mache ich das so.

btw. Man kann das auch in einer for-Schleife lösen...

33

OS-Design / Re: Kernelparts in Modulen unterbringen

« am: 23. January 2010, 13:47 »

Eigentlich war das Modul nicht als eigenständiger Prozess gedacht.
 
Ich dachte mir das so, dass ich den Microkernel modularisiere, sprich es gibt ein Speichermanagementmodul. Über den Kernel springe ich bei Bedarf in den Code des Moduls und führe die entsprechend definierten funktionen aus.
 
Was ich mir gedacht habe, war einfach nur das Auslagern von Code aus dem Kernel, aber halt als Code, der vom Kernel aufrufbar ist und nicht als eigenständige Treiber.

34

OS-Design / Kernelparts in Modulen unterbringen

« am: 22. January 2010, 08:53 »

Hallo Lowlevel-Community,
mir ist soeben eine fix Idee gekommen.
 
Und zwar möchte ich die Kernelaufgaben meines Microkernels in mehrere Module aufteilen. So hätte ich dann z.B. ein HAL-Modul, in dem Paging usw. definiert wird. Des Weiteren hätte ich noch eine Reihe von Einzelmodulen, wie z.B. eines für die physikalische Speicherverwaltung.
 
Ist so etwas praktikabel, oder sollte man das besser im Kernel belassen?
 
Gruß Christian

35

Lowlevel-Coding / Re: Verständnisfragen

« am: 18. December 2009, 12:22 »

Da es im entfernten Sinne auch eine Verständnisfrage ist, poste ich einfach hier. 
 
Ich habe das Thema APIC und I/O APIC mal nach hinten verschoben, auch wenn mein Testrechner nen local APIC hat...
 
Und zwar bin ich ja immer noch am aufteilen/neuschreiben meines Codes. Nun habe ich einfach mal im GIT-Repository geschaut. An und für sich ist die physische Speicherverwaltung ja schnell gelöst (Bitmap). Nun ist es ja so, dass die Seitengröße von 4K Plattformabhängig ist, aber der ganze Rest (die eigentlichen Funktionen) ja nicht.
 
So weit kein Problem. Da ich aber nun einfach mal bei tyndur geschaut habe, habe ich den mmc-Funktionssatz gesehen. Ich vermute einfach mal, dass das für "Memory Management Context" steht. Was für ein Sinn steckt dahinter? Wofür werden solche Funktionen gebraucht?

36

Lowlevel-Coding / Re: CPUID hilfe!!!

« am: 20. November 2009, 08:03 »

Wenn mich nicht alles täuscht, dürfte dein Fehler beim Inline Assembler sein, quasi hier:

Code: [Auswählen]

__asm__("pushfd" : "pushfd" : "pop ecx" : "mov eax, ecx" : "xor eax, 0x200000" : "push eax" : "popfd" : "pushfd" : "pop eax" : "=a"(EAX), "=c"(ECX));
Wenn du mehrere Assembleranweisungen aneinander hängen möchtest, dann geht das so nicht. Was möglcih wäre, wäre ein Konstrukt der folgenden Art:

Code: [Auswählen]

__asm__("pushfd; pushfd; pop ecx ..." : "=a"(EAX), "=c"(ECX));
// Alternativ auch so:
__asm__("pushfd\npushfd\npop ecx ..." : "=a"(EAX), "=c"(ECX));
Die Instruktionen müssen also entweder per Semikolon oder per Newline von einander getrennt werden...

37

Lowlevel-Coding / Re: CPUID hilfe!!!

« am: 19. November 2009, 09:02 »

Als kleine Verbesserung noch könnte man folgendes im cpuid_check ändern...
 
Lass das "else if" weg, EAX und ECX können ja entweder nur gleich oder ungleich sein (kleiner gleich würde z.B. keinen Sinn machen). Alternativ kannst du auch das gesetzte eflags-bit extrahieren und einmal vorher und einmal nachher vergleichen.
Somit würde auch das else in der anderen Funktion wegfallen.

38

Lowlevel-Coding / Re: CPUID hilfe!!!

« am: 19. November 2009, 08:46 »

Ich gehe einfach mal davon aus, dass das C ist, evtl. C++.
 
Was sollen die ganzen '%%' in den IF-Abfragen? Sollten das denn nicht auch '&&' sein? Des Weiteren würde ich mal sagen, dass man in C Strings nicht per "==" vergleichen kann.
Was du machen könntest, wäre alles zu einem String zusammen zu kopieren, damit quase "AuthenticAMD" an einem Stück ist.
 
Bei den Variablen bin ich mir nicht ganz sicher, aber diese müssten (denke ich mir mal so) alles Arrays mit 4 Feldern sein, da EAX, EBX sowie ECX immer 4 Buchstaben enthalten. (*EDIT* Bsp.: char EAX[4]; *EDIT*)
 
Gruß Christian
PS: Es würde helfen, wenn du Grob sagen kannst, was funktioniert und was nicht. z.B. cpuid_check funktioniert oder so...

39

Lowlevel-Coding / Re: Verständnisfragen

« am: 17. November 2009, 08:37 »

Ich will ja keinem dazwischenpfuschen oder so, aber ich hab da noch mal ne Frage zum ersten Beitrag am Anfang. dieses align, was bewirkt dass, ich habs nicht ganz verstanden. im multiboot header, wird align 4 verwendet, und was genau verändert dieses macro?
das hab ich nicht so ganz verstanden. sry

Dafür ist der Thread doch da.

So bin ich mal wieder ein bisschen schlauer geworden. 
Ich beschäftige ja mich immer noch mit dem local APIC und hier gibt es "feste Events" (mir fällt kein besserer Begriff ein), wie den APIC Timer, LINT0, LINT1 usw.
Diese werden immer vom installierten I/O APIC ausgelöst. Folglich gibt es immer einen I/O APIC, wenn es einen local APIC gibt. Gibt es keinen local APIC, ist kein I/O APIC da und man muss den normalen PIC nehmen.
 
Sollte sich jemand bereits etwas mehr damit beschäftigt haben (local APIC, I/O APIC), und ich habe was falsches geschrieben, dann korrigiert mich bitte... 

40

Lowlevel-Coding / Re: Verständnisfragen

« am: 13. November 2009, 13:15 »

Doppel-Posts sind böse, aber beim Editieren besteht die Möglichkeit, dass das niemand liest...
 
Ich habe mich etwas weiter eingelesen in den Local APIC. Nun heißt es, dass bei einem System mit nur einem Prozessor kein I/O APIC vorhanden ist, weshalb der PIC für Hardware Interrupts genutzt wird. Muss ich also nach der Initialisierung des local APIC den PIC zusätzlich initialisieren, oder übernimmt das der local APIC während der Initialisierung?