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 - jgraef

Seiten: 1 [2] 3 4
21
Lowlevel-Coding / Re: GDT Deskriptor wird falsch gesetzt
« am: 01. November 2008, 00:02 »
Danke erstmal!
Ich bin auf einen anderen Compiler umgestiegen!
Mein alter Compiler hat da anscheinend nicht aligned!

Wieso ich den structs namen gebe?
Das habe ich noch von der zeit uebernommen als ich noch nicht mit typedef gearbeitet habe!

Jetzt bekomme ich allerdings eine Exception beim neuladen der Segment-Register:
Zitat
00012122274i[CPU0 ] >> mov ds, ax : 8ED8
00012122274e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting

Da ist irgendein Fehler im Deskriptor und du bist an dem Punkt wo man so gut wie gar nicht debuggen kann. Viel Spaß beim suchen ;)
22
Lowlevel-Coding / Re: GDT Deskriptor wird falsch gesetzt
« am: 30. October 2008, 16:59 »
typedef struct gdt_entry{
WORD size0_15;
WORD base0_15;
BYTE base16_23;
BYTE access;
BYTE size16_19;
BYTE base24_31;
} __attribute__ ((packed)) gdt_entry;

typedef struct gdt_ptr{
WORD limit;
DWORD base;
} __attribute__ ((packed)) gdt_ptr;

Ersetz mal deine Structs damit. Bei deinen wird eventuell aligned und dann funktioniert das natürlich nicht mehr.

Ich frage mich außerdem wieso du den structs einen Namen gibst, wenn du ihnen sowieso einen Typnamen zuweist.
23
OS-Design / Re: GRUB - Bootloader bootfaehig machen
« am: 27. October 2008, 15:43 »
Du musst die Dateien auf das FS (wahrscheinlich FAT12) machen und dann mit grub auf die Diskette schreiben. Ob es das auch für Windows gibt, weiß ich nicht.
24
Lowlevel-Coding / Re: ganz einfacher kernel + multiboot mit grub
« am: 28. September 2008, 17:08 »
Der normale Grub kann keinen 64Bit-Code laden. Eine Möglichkeit wäre mit Grub einen 32bit-Kernel zu laden, der dann 64bit initialisiert. AFAIK gibt es aber auch 64Bit-Grub.
26
Lowlevel-Coding / Re: standardfarbe 0x07 ändern bei int 0x10
« am: 31. August 2008, 12:45 »
Hi,

Sieht so aus als würdet ihr eure Strings mit BIOS-Interrupts auf den Bildschirm bringen. Das geht natürlich nur im Realmode und früher oder später müsst ihr in den Protected Mode, wenn ihr ein OS haben wollt. Mit ein wenig Suche hättet ihr auch sicher den Artikel "Textausgabe" in dem Wiki gefunden. Da steht dann erklärt, wie man im PMode Text ausgibt und auch mit Farbe ;)
27
Lowlevel-Coding / Re: iret problem (triple fault)
« am: 23. August 2008, 18:38 »
Hi,

Wenn du das iret testweise ausführts, tust du das auch während eines Interrupts?

Außerdem solltest du eigentlich funktionierende Exceptionhandler haben.
28
Das Wiki / Re: Neuauflage des Lowlevel Magazins
« am: 14. August 2008, 19:10 »
Hi,

Also Betalesen kann ich auf jeden Fall übernehmen. Ich würde auch einen Artikel schreiben, wenn mir ein interessantes Thema einfallen würde.
29
Offtopic / Re: Euer größter OS Hype
« am: 04. August 2008, 20:52 »
Hi,

Bei mir gibt's da eigentlich mehrere Dinge.
Einmal mein malloc(). Implementiert und hat sofort funktioniert.
Dann noch meine neue Speicherverwaltung: jetzt kann mein Kernel richtig dynamisch Speicher anfordern und sogar Linked Lists benutzen. Außerdem, wenn ein Prozess eine Page haben will, bekommt er diese jetzt nicht sofort. Nur wenn er sie dann auch benutzt. Außerdem habe ich schon ein Interface für Swapping, nur wie man das in einem Mikrokernel implementiert...
Und dann noch mein SysV/IPC. Bis auf die Semaphoren hat alles sofort super geklappt. Sogar Shared Memory, ich hatte mir das immer so schwierig vorgestellt.
30
tyndur / CDI - Generic
« am: 01. August 2008, 23:25 »
Hi,

So, das ist der erste Entwurf, für den CDI-Teil (oder -Modul, wie man es nennen will) für allgemeine Treiber. Wie z.B Tastatur, Maus, Lautsprecher, usw. Jedes Device hat einen Datenstream und mehrere Steuerfunktionen. Der Datenstream überträgt z.B die Keycodes einer Tastatur. Mit den Steuerfunktionen kann man z.B NumLock usw. steuern, oder dem Gerät ein anderes Tastaturlayout zuordnen.

PS: Wie ich im IRC schon angemerkt hatte, hätte ich nichts gegen eine Kooperation beim Schreiben eines CDI-Tastatur-Treibers.

EDIT: Jeder Stream-Typ bekommt eine eigene Struktur. Als Beispiel habe ich die eines Joystick-Streams angelegt. Ob man für Character-Streams ein Struct braucht ist fraglich.

#ifndef _CDI_GENERIC_H_
#define _CDI_GENERIC_H_

#include <sys/types.h>

#include "cdi.h"
#include "cdi/lists.h"

/// Struktur fuer Stream-Objekt fuer Joystick
struct cdi_generic_stream_joystick {
  int axis_raw[2];
  int axis_cal[2];
  int buttons[2];
};

/**
 * Struktur fuer CDI Generic Driver
 */
struct cdi_generic_driver {
  /// Allgemeine CDI-Treiber-Struktur
  struct cdi_driver drv;
};

struct cdi_generic_stream;

/**
 * Struktur fuer CDI Generic Devices
 */
struct cdi_generic_device {
  /// Allgemeine CDI-Geraete-Struktur
  struct cdi_device dev;

  /// Datenstream des Geraets
  struct cdi_generic_stream *stream;

  /// Steuerfunktionen des Geraets
  cdi_list_t functions;
};

/**
 * Struktur eines Streams
 * Wie die Daten des Streams verarbeitet werden haengt vom Treiber ab.
 * Gebraeuchlich ist die Arbeitsweise FIFO
 *  - read() wird von der Implementation aufgerufen, wenn ein Programm Daten
 *    vom Stream lesen will.
 *  - write() wird von der Implementation aufgerufen, wenn ein Programm Daten
 *    in den Stream schreiben will.
 */
struct cdi_generic_stream {
  /// Groesse eines Objekts
  size_t objsz;
  /// Liest ein Objekt vom Stream
  int (*read)(struct cdi_generic_device *dev,void *obj,size_t count);
  /// Schreibt ein Objekt in den Stream
  int (*write)(struct cdi_generic_device *dev,void *obj,size_t count);
};

/**
 * Struktur einer Steuerfunktion
 * Steuerfunktionen werden vom Treiber zur Verfuegung gestellt um erweiterten
 * Zugriff auf das Geraet zu haben. Jede Funktion hat ein Objekt, dass der
 * Funktion vom Aufrufer uebergeben wird und ein Objekt, dass die Funktion
 * an den Aufrufer zurueck gibt.
 */
struct cdi_generic_function {
  /**
   * Referenz zur Steuerfunktion
   *  @param dev CDI-Geraet
   *  @param data Datenobjekt
   *  @param datasz Groesse von data
   *  @param ret Rueckgabeobjekt
   *  @param retsz Groesse von data
   *  @return Rueckgabewert
   */
  int (*func)(struct cdi_generic_device *dev,void *data,size_t datasz,void *ret,size_t retsz);

  // meinOS specific
  /// Nummer der Funktion
  int cmd;
};

/**
 * Initialisiert einen CDI-Generic-Treiber
 *  @param driver CDI-Generic-Treiber
 */
void cdi_generic_driver_init(struct cdi_generic_driver* driver);

/**
 * Zerstoert einen CDI-Generic-Treiber
 *  @param driver CDI-Generic-Treiber
 */
void cdi_generic_driver_destroy(struct cdi_generic_driver* driver);

/**
 * Registriert einen CDI-Generic-Treiber
 *  @param driver CDI-Generic-Treiber
 */
void cdi_generic_driver_register(struct cdi_generic_driver* driver);

#endif
31
Lowlevel-Coding / Re: IDT laden
« am: 23. July 2008, 21:19 »
Hi,

Sieht eigentlich super aus. Wahrscheinlich ist das irgendein fieser kleiner Fehler. Der Triple-Fault bedeutet, dass die Exceptions nicht aufgelöst werden können, d.h was mit deiner IDT/ISRs nicht stimmt. Das Problem bei solchen Fehlern ist, dass man sie schlecht debuggen kann. Du musst wohl oder übel noch mal alles genau durchgehen.

PS: Damit man nicht immer die ganzen externen Funktionen in den Sourcen einzeln deklarieren muss, baut man sich Header. Du hast z.B memset in isr.c "per Hand" deklariert.

EDIT: Dein Allgemeiner ISR-Handler addiert am Ende 8 zu ESP, wobei du ja nicht immer einen Dummy-Errorcode auf den Stack legst. Da wo von der CPU ein Errorcode auf den Stack gelegt wird, musst du diesen auch nicht wieder vom Stack "löschen". Außerdem ist das CLI am Anfang aller ISRs unnötig, da während eines Interrupts, Interrupts ausgeschaltet sind.
32
Lowlevel-Coding / Re: Problem mit GDT - Kernel stürtzt ab
« am: 21. July 2008, 09:03 »
Hi,

Was soll das hier machen?
mov  eax, cs   ; Daten-, Stack und Extrasegment mit Datensegmentdesktriptor laden
shl eax, 4
add eax, gdt
mov ds, ax
mov ss, ax
mov es, ax
mov eax, 0 ; FS und GS mit Null-Deskriptor laden
mov fs, ax
mov gs, ax

Du musst einfach DS, ES,FS, GS, SS mit 0x10 und CS mit 0x8 laden. Wobei CS schwieriger ist, da du dafür einen Jump durchfürhen musst. So in etwa
mov ax,0x10
mov ds,ax
mov es,ax
mov fs,ax
mov gs,ax
mov ss,ax
jmp 0x8:.newcs
.newcs:
ret

Außerdem fehlt das ret in load_gdt und er versucht deine GDT auszuführen.

BTW: GDT (IDT usw auch) kannst du auch von deinem C-Teil aus laden (was  einfacher sein könnte). Grub lädt ja beim Start auch eine GDT, die du für den Anfang benutzen kannst. Man sollte trotzdem nachher eine eigene laden, da nicht feststeht welchen Index Code- und Daten-Segment haben.
33
Hi,

Ich hatte im ersten Kernel von meinOS eine Port-Abstraktion. D.h es lag eine feste Zuordnung von Dienst=>Port vor und wenn der Treiber nun startet wird mithilfe des Ports die PID ermittelt. Das ist aber im Prinzip das gleiche wie ihr verwendet und ergibt auch die gleichen Probleme.

Mein neuer Kernel benutzt die IPC Methoden der XSI-Erweiterung des ISO-C-Standards. Dabei ist die Kommunikation nicht mit der PID gebunden. Im Falle des Grafiktreibers, erstellt dieser eine Messagequeue mit dem Key ftok("/dev/screen",'S') (wichtig ist nur dass der Key immer gleich ist). Um nun ein Zeichen auf den Bildschirm auszugeben muss der Client-Prozess die Messagequeue öffnen (dafür muss er natürlich den Key wissen, oder wie er mit ftok gebaut wird). Nun kann er Nachrichten an den Treiber schicken. Empfangen wäre ja sinnlos und um dies zu verhindern (damit Clients nicht die Messages aus der Queue klauen) kann man einfach die Zugriffsrechte ändern.

Der Vorteil ist, dass sich die Messagequeue nicht ändert, wenn der Grafiktreiber neugestartet wird. D.h der Client-Prozess kann weiterschreiben.
34
Lowlevel-Coding / Re: Multitasking
« am: 04. July 2008, 15:43 »
Hi,

Der Heap ist etwas zu klein. Und außerdem würde ich die Task/Thread-Daten, IPC-Daten und sämtliche andere Daten des Kernels in den Kernelheap reinmachen, denn dafür ist er ja da.
35
OS-Design / Re: Speicherverwaltung
« am: 03. July 2008, 15:06 »
Wie ich das dann mache, wenn aufeinanderfolgender Speicher überhalb des DMA-Bereichs reserviert werden soll, werde ich zu gegebener Zeit nachschauen, was so wie ich das gelesen habe recht schwer ist mit einem Stack

Wenn ein Programm "normalen" zusammenhängenden Speicher haben will, ist es doch egal ob dieser physisch zusammenhängt. Er muss nur virtuell zusammenhängen.
36
Lowlevel-Coding / Re: ld findet _start nicht
« am: 03. June 2008, 20:14 »
Hi,

Ich benutze einen Crosscompiler und -nostdlib bringt auch keine Besserung.
37
Lowlevel-Coding / Re: ld findet _start nicht
« am: 03. June 2008, 19:27 »
Weder:
$ ld -o init init.o -T../link.ld -L../lib --start-group -lc -lmeinos -lgcc --end-groupnoch:
$ ld -o init init.o -lc -T../link.ld -L../lib -lc -lmeinos -lgccoder:
$ ld -o init init.o -lc -T../link.ld -L../lib --start-group -lc -lmeinos -lgcc --end-groupoder:
$ ld -o init init.o --start-group -lc -lmeinos -lgcc --end-group -T../link.ld -L../libbringt etwas. Immer noch gleiche Fehlermeldung.
38
Lowlevel-Coding / ld findet _start nicht
« am: 03. June 2008, 16:12 »
Hi,

Um Programme für meinOS zu linken benutze ich folgenden Befehl:
$ ld -o init init.o -T../link.ld -L../lib -lc -lmeinos -lgccDabei bekomme ich folgende Fehlermeldung:
Zitat
ld: warning: cannot find entry symbol _start; defaulting to 0000000000002000

Mein Problem ist nun, dass ich nicht weiß warum er _start nicht findet obwohl ich die entsprechende Datei dazulinke (ist in libc enthalten). Hier der Beweis:
$ nm libc.a | grep _start
00000000 T _start
39
Hi,

Ich denke die Ausschmückungen sind eher nebensächlich, den Kram kann man auch nachher machen. Außerdem kannst du auch Grub als Bootloader benutzen. Du solltest dir am besten mal ein paar Tutorials dazu in der Wiki durchlesen.
40
Hi,

Ich habe dir einen Vorschlag gemacht. Wenn du den Kernel selber machen willst, musst du erstmal einen normalen Kernel machen um übehraupt genug Ahnung zu haben, also dann kannst du nochmal 4-5 Jahre Zeit investieren. Ich denke dass das mit dem Linux-Kernel aber wirklich eine gute Idee für dich ist.

BTW: Niemand hier liest Bildzeitung, hoffe ich.
Seiten: 1 [2] 3 4

Einloggen