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

Seiten: [1]
1
Lowlevel-Coding / Re:PS2-Keyboard identifizieren
« am: 29. August 2011, 12:34 »
Die Idee mit dem Mapping über setkeycodes in jedem Fall war super! Es gibt glücklicherweise keine Scancode-Überlappung.

Danke für die vielen Tipps.

Dennoch würde mich interessieren, ob das nicht doch irgendwie zu bewerkstelligen ist. Falls es jemand schafft, würde ich mich über die Lösung freuen. Ich bin jetzt erstmal happy mit dieser Lösung - bis irgendwann eine Tastatur kommt, bei der es eine Scancode-Überlappung gibt  :evil:
2
Lowlevel-Coding / PS2-Keyboard identifizieren
« am: 26. August 2011, 19:41 »
Hallo,

ich habe mich schon durch diverse Dokumente gewälzt, aber meine Versuche gehen irgendwie immer schief. Ich suche eine Möglichkeit, zu identifizieren, was für ein Keyboard am PS2-Port angeschlossen ist. Eins vornweg: Ich brauche die Möglichkeit für Linux, ich greife auf /dev/port zu und gehe mit lseek() an 0x64 oder 0x60 um Kommandos/Daten zu senden/empfangen oder den Status auszulesen.

Ich habe auf der Seite

http://www.computer-engineering.org/ps2keyboard/

ein gutes Dokument gefunden, in dem beschrieben steht, das man die Keyboard ID mit Command-Set 0xf2 abrufen kann. Ich vermute jetzt stark, das ich das falsch mache, denn je nach dem, welches Keyboard ich anschließe (ich habe drei verschiedene, die unterschieden werden müssen), bekomme ich entweder 0xfa (ACK) + 0xab + 0x41 (bei zwei der drei Keyboards) oder ein 0xfe zurück. Ich schreibe das Commando in den Input-Buffer (0x60) und lese dann auch wieder 0x60 aus.

Ist das Vorgehen soweit richtig? Ich finde kein Beispiel dafür. Ich habe auch schon versucht, die Keyboard-Controller-Firmware-Version auszulesen, was mich für die Identifikation des Keyboards wahrscheinlich nicht weiter bringt - auch dieses funktioniert nicht.

Zum Hintergrund:

Es gibt, wie schon erwähnt, 3 Tastaturen von unterschiedlichen Herstellern. Diese Tastaturen müssen irgendwie erkannt werden, da die Keyboards unterschiedliche Scancodes für bestimmte Tasten zurück liefern. Dies wäre kein Problem, ich kann das mit setkeycodes beheben, aber dafür muss ich wissen, was für eine Tastatur denn nun am Port hängt.

Um das ganze auf die Spitze zu treiben, muss die Erkennung auch mit verschiedenen Rechnern funktionieren, die unterschiedliche BIOSe haben - das scheint ja auch eine wichtige Information zu sein, wenn ich das Dokument so betrachte.

Hat jemand eine Idee, wie das zu lösen wäre? Ich fummel damit schon eine Woche rum und finde einfach keine zufriedenstellende Lösung.

Danke für eure Tipps.
3
Softwareentwicklung / Re:Symbol Table durchsuchen
« am: 15. January 2011, 17:51 »
Ok, ich versuch es noch mal:

Der Kernel selbst bekommt natürlich auch Pages, um das Mappen von virtuellen Adressen auf physikalische zu ermöglichen. Bei der Initialisierung wird vom Anfang (0) bis zum Ende des Kernels (dort Placement-Adresse genannt) in 4K-Blöcken geschleift. Dabei werden die Anfangs-Adressen der 4K-Blöcke in einem Paging-Directory (kernel_directory) eingetragen. Durch das setzen eines entsprechenden Bits innerhalb einer Bitmap (Frame) wird gekennzeichnet, das dieser physikalische Speicher einer Page zugeordnet wurde (reserviert). Ich gebe zu, dass das Wort sehr unglücklich gewählt ist, weil die CPU bereits reservieren kann (Bit 4 im error code bei einem Page fault), aber das hat mit unserem Begriff nichts zu tun - gemappt ist da viel besser.

Mit linken meine ich in diesem Falle, das die Adresse kopiert wird, anstatt der Inhalt - oder kurz, der Pointer auf die Page-Tables wird übernommen, sowie die physikalische Adresse der Page-Tables kopiert.

Ich hoffe, das war jetzt richtig ausgedrückt.

Aber ich lese mir bereits beide Artikel durch, um in Zukunft die richtigen Begrifflichkeiten zu verwenden, und natürlich um zu schauen, ob ich alles bisher richtig verstanden habe. Danke für das schonungslose korrigieren meiner Sicht auf diese Dinge - bitte weiter so :-)

Grüße
4
Softwareentwicklung / Re:Symbol Table durchsuchen
« am: 15. January 2011, 12:16 »
Ok, jetzt habe ich das verstanden:

Ja, das ist so. Bei der Inialisierung des Paging wird der Kernel-Code als reserviert in das Paging-Directory "kernel_directory" eingetragen. Davon wird ein Clone erzeugt und in "current_directory" eingetragen. Alle neuen Tasks linken das Kernel-Directory in ihren Adressraum und erzeugen einen für sie privaten Stack, bei dem alles aus current_directory gecloned wird, was <nicht> kernel_directory ist. So habe ich es aus dem Tutorial übernommen. Das ist prinzipiell auch das, was im LowLevel-Wiki zum Thema Multitasking umgesetzt werden sollte.

Grundsätzlich unterscheidet sich nur der Code, das Prinzip scheint für mich das gleiche zu sein.

Hier mal ein schönes Bild dazu (ich hoffe, ich darf das verlinken):


Warscheinlich habe ich irgendwo unachtsam Code übernommen, ohne darüber nachzudenken. Ich mach es jetzt so:

Ich stelle mein Backup vor der Implementierung des Multitasking wieder her (der lief mit Paging nämlich) und fange dort noch mal an. Grundsätzlich hätte mich trotzdem interessiert, was ich falsch gemacht habe.

Zum eigentlichen Thema des Threads:
Leider bin ich bei der Implementierung des Auslesens der Symbol-Tabelle noch nicht weiter gekommen, ist wohl noch etwas zu früh, da fehlt mir noch das entscheidende Wissen. Ich werde das aber noch versuchen umzusetzen. Wenn ich erfolgreich war, möchte ich den Code gern allen interessierten zur Verfügung stellen. Vielen Dank erstmal für eure Geduld einem Newbie gegenüber :-)

Grüße
5
Softwareentwicklung / Re:Symbol Table durchsuchen
« am: 14. January 2011, 18:32 »
Kannst du mir vielleicht anhand eines Code-Beispiels (Link genügt) zeigen, was du meinst? Ich habe nicht gewusst, das man den Kernel-Code irgendwo hin kopieren muss.
6
Softwareentwicklung / Re:Symbol Table durchsuchen
« am: 14. January 2011, 08:53 »
Ich hab noch nicht verstanden, was du mit deiner Frage meinst. Falls du meinst, ob jeder Prozess seinen eigenen Kernel-Heap hat, ja, aber das ist wie bei JM's Tutorial jeweils immer ein Zeiger auf das Paging-Directory des Kernels. Zusätzlich hat jeder Prozess noch seinen eigenen privaten Stack.

Der private Stack ist dann natürlich an unterschiedlichen Stellen gemappt. So wie hier beschrieben: http://www.jamesmolloy.co.uk/tutorial_html/9.-Multitasking.html.

Ich habe bisher nur einen Prozess laufen, der mit fork() erzeugt wurde.

Interessant ist vielleicht außerdem zu erwähnen, das wenn ich, vor der if-Condition noch ein kprintf() einfüge, dass das System dann läuft, also ohne Pagefault. Daher meine Vermutung, das der Stack der task_switch()-Funktion überschrieben wurde.
7
Softwareentwicklung / Re:Symbol Table durchsuchen
« am: 13. January 2011, 13:17 »
Vielen Dank für alle eure Anregungen und Erklärungen. Ich habe mein Problem mit dem Pagefault noch nicht lösen können. Es geht aber um das Taskswitching. Folgender ASM:

001035c1 <task_switch>:
  1035c1:       55                      push   %ebp
  1035c2:       89 e5                   mov    %esp,%ebp
  1035c4:       53                      push   %ebx
  1035c5:       83 ec 14                sub    $0x14,%esp
  1035c8:       a1 2c 8d 10 00          mov    0x108d2c,%eax
  1035cd:       85 c0                   test   %eax,%eax
  1035cf:       0f 84 b6 00 00 00       je     10368b <task_switch+0xca>
  1035d5:       89 e3                   mov    %esp,%ebx
  1035d7:       89 5d f4                mov    %ebx,-0xc(%ebp)
  1035da:       89 eb                   mov    %ebp,%ebx
  1035dc:       89 5d f0                mov    %ebx,-0x10(%ebp)
  1035df:       e8 84 cc ff ff          call   100268 <read_eip>
  1035e4:       89 45 ec                mov    %eax,-0x14(%ebp)
  1035e7:       81 7d ec 45 23 01 00    cmpl   $0x12345,-0x14(%ebp)
  1035ee:       0f 84 9a 00 00 00       je     10368e <task_switch+0xcd>
  1035f4:       a1 2c 8d 10 00          mov    0x108d2c,%eax
  1035f9:       8b 55 f4                mov    -0xc(%ebp),%edx
  1035fc:       89 50 04                mov    %edx,0x4(%eax)
  1035ff:       a1 2c 8d 10 00          mov    0x108d2c,%eax
  103604:       8b 55 f0                mov    -0x10(%ebp),%edx
  103607:       89 50 08                mov    %edx,0x8(%eax)
  10360a:       a1 2c 8d 10 00          mov    0x108d2c,%eax
  10360f:       8b 55 ec                mov    -0x14(%ebp),%edx
  103612:       89 50 0c                mov    %edx,0xc(%eax)
  103615:       a1 2c 8d 10 00          mov    0x108d2c,%eax
  10361a:       8b 40 14                mov    0x14(%eax),%eax
  10361d:       a3 2c 8d 10 00          mov    %eax,0x108d2c
  103622:       a1 2c 8d 10 00          mov    0x108d2c,%eax
  103627:       85 c0                   test   %eax,%eax
  103629:       75 0a                   jne    103635 <task_switch+0x74>
  10362b:       a1 28 8d 10 00          mov    0x108d28,%eax
  103630:       a3 2c 8d 10 00          mov    %eax,0x108d2c
  103635:       a1 2c 8d 10 00          mov    0x108d2c,%eax
  10363a:       8b 40 04                mov    0x4(%eax),%eax
  10363d:       89 45 f4                mov    %eax,-0xc(%ebp)
  103640:       a1 2c 8d 10 00          mov    0x108d2c,%eax
  103645:       8b 40 08                mov    0x8(%eax),%eax
  103648:       89 45 f0                mov    %eax,-0x10(%ebp)
  10364b:       a1 2c 8d 10 00          mov    0x108d2c,%eax
  103650:       8b 40 0c                mov    0xc(%eax),%eax
  103653:       89 45 ec                mov    %eax,-0x14(%ebp)
  103656:       a1 2c 8d 10 00          mov    0x108d2c,%eax
  10365b:       8b 40 10                mov    0x10(%eax),%eax
  10365e:       a3 10 70 10 00          mov    %eax,0x107010
  103663:       a1 10 70 10 00          mov    0x107010,%eax
  103668:       8b 98 00 20 00 00       mov    0x2000(%eax),%ebx
  10366e:       8b 45 ec                mov    -0x14(%ebp),%eax
  103671:       8b 55 f4                mov    -0xc(%ebp),%edx
  103674:       8b 4d f0                mov    -0x10(%ebp),%ecx
  103677:       fa                      cli   
  103678:       89 c1                   mov    %eax,%ecx
  10367a:       89 d4                   mov    %edx,%esp
  10367c:       89 cd                   mov    %ecx,%ebp
  10367e:       0f 22 db                mov    %ebx,%cr3
  103681:       b8 45 23 01 00          mov    $0x12345,%eax
  103686:       fb                      sti   
  103687:       ff e1                   jmp    *%ecx
  103689:       eb 04                   jmp    10368f <task_switch+0xce>
  10368b:       90                      nop
  10368c:       eb 01                   jmp    10368f <task_switch+0xce>
  10368e:       90                      nop
  10368f:       83 c4 14                add    $0x14,%esp
  103692:       5b                      pop    %ebx
  103693:       5d                      pop    %ebp
  103694:       c3                      ret   

Nun bekomme ich folgende Register in der PF:

Page fault at 0xF45D8A15! (present = 1, rw = 1, user = 0, reserved = 0, id = 0)
EDI = 0x57A17,  ESI = 0x57A20,  EBP = 0xDFFFFF78,       EBX = 0x30DCC
EDX = 0x3,      ECX = 0x32,     EAX = 0xC008100C,       ESP = 0x7DB
EIP = 0x1035D4, CS = 0x8,       DS = 0xC0080010,        SS = 0x0
INT = 14,       ERR = 0x2
EFLAGS = 0x10082, USRESP = 0x0

Wenn ich nun nach der EIP suche, stell ich fest, das es keine 0x1035D4 zu geben scheint. An besagter Stelle im C-Source ist nur eine if:

void task_switch()
{

  if(!current_task)
  {
    return;
  }

current_task selbst ist ein globaler volatile Pointer auf eine Struktur, und stellt immer den derzeit ausgeführten Task dar. Geh ich recht in der Annahme, das der Stack hier ziemlich kaputt ist und vermutlich sogar der Stack der Funktion task_switch überschrieben wurde? Wenn ja, wo könnte ich anfangen, den Fehler zu suchen? Ich bin vermutlich schon ein bisschen betriebsblind.
8
Softwareentwicklung / Re:Symbol Table durchsuchen
« am: 12. January 2011, 16:56 »
Ich will das machen, weil ich zu meiner Schande gestehen muss, dass ich das mit den Registern noch nicht so verinnerlicht habe. Ich verzweifel bspw. an dieser Ausnahme:

============================================================================
Unhandled Interrupt occured
EDI = 0x57A18, ESI = 0x57A20, EBP = 0x82CB, EBX = 0x57A24
EDX = 0xC0081038, ECX = 0x1035F4, EAX = 0x0, ESP = 0xDFFFFFD0
INT = 5, ERR = 0x0
EIP = 0x57A20, CS = 0x8, EFLAGS = 0x10206, USRESP = 0x57A20, SS = 0x67E5C
============================================================================
EDI = 0x57A18, ESI = 0x57A20, EBP = 0x82CB, EBX = 0x57A24
EDX = 0xC0081038, ECX = 0x1035F4, EAX = 0x0, ESP = 0xDFFFFFD0
INT = 13, ERR = 0x0
EIP = 0x57A20, CS = 0x8, EFLAGS = 0x10206, USRESP = 0x57A20, SS = 0x67E5C
kernel/isr.c(62): General Protection fault!

Ich weiß nicht, wieso EIP auf diesem Wert steht, offensichtlich hats den Stack zerbröselt und ich finde den Fehler noch nicht. Aber vielleicht kann mir einer auf die Sprünge helfen und den Weg deuten, wie ich zur Ursache des Problems nur anhand der Register komme. Ich kann nur so viel sagen, das die Funktionen nach objdump erst bei 0x100000 beginnen:

Disassembly of section .text:

00100000 <__code>:

Daher wollte ich einen Call-Stack haben, weil ich annahm, das der mich weiter bringt.

Ich weiß vom Exception-Wiki, das 5 Bound Rage ist und damit eine Array-Grenze überschritten wird. Aber welcher Array das ist, weiß ich nicht und habe auch keine Idee, wo ich anfangen soll, zu suchen.

EDIT: Das ESP Register hat in der Ausgabe gefehlt

Edit 2: Ok, ich hab jetzt verstanden, das es mit ESI - EDI zusammen hängt, also dort ist der Source/Destination Index (richtig?). Allerdings weiß ich noch nicht, wie man anhand dieser Informationen an den Array kommt.

Edit 3: Was mir grad noch auffällt, warum ist der ESI addressen-technisch weiter hinter angesiedelt als der EDI? Das ist doch schon etwas seltsam.

Edit 4: Ok, ich hab die Ursache dafür nun gefunden, bei der Rückkehr aus dem ISR-Handler habe ich versehentlich aus dem falschen Register (ax statt bx) zurück kopiert. Nun habe ich nur noch meinen Page-Fault, den werde ich aber auch noch finden.
9
Softwareentwicklung / Re:Symbol Table durchsuchen
« am: 11. January 2011, 21:09 »
Wenn du deinen Kernel mit Multiboot lädst, sind sie noch verfügbar. Der Eintrag shdr_addr im Multiboot-Header zeigt auf ein Array von Section-Headern, in dem du nach der Symbol Table durchsuchen kannst.

Vielen herzlichen Dank, ich denke, da komm ich erstmal weiter.
10
Softwareentwicklung / Re:Symbol Table durchsuchen
« am: 11. January 2011, 19:25 »
Hallo und vielen Dank für dein Feedback.

Es geht darum, das ich ein Call-Stack ausgeben will, wenn mein Kernel eine Exception geworfen hat. Ich dachte, es funktioniert irgendwie genauso, wie bei http://www.jamesmolloy.co.uk/tutorial_html/1.-Environment%20setup.html mit der Referenz auf die end-Section. Dort wird im Linker-Script definiert, das am Ende aller Sektionen die end-Sektion liegt. Innerhalb des Kernels kann man dann mit

extern unsigned int end;

darauf zugreifen, um die placement addresse festlegen zu können.

Ich habe mir nun eingebildet, das ich eine Struktur mit den Elf-Informationen baue, und mittels Struktur-Pointer auf die .symtab-Sektion zeigen lassen kann, um dort an die Informationen zu gelangen. Leider scheint das so aber nicht zu funktionieren.

Nun stelle ich mir die Frage, wie man das angehen könnte. Sprich, was benötige ich (Elf-Strukturen sollten kein Problem darstellen) um einen Menschen-Lesbaren Call-Stack zu kommen.

Trotzdem vielen Dank für die Info, ich wusste nicht, das die Sektionen zur Laufzeit teilweise nicht mehr verfügbar sind. Wieder was dazu gelernt.
11
Softwareentwicklung / Symbol Table durchsuchen
« am: 11. January 2011, 18:06 »
Hallo,

ich wollte mal fragen, ob jemand weiß, wie man an die Symbol-Tabelle des aktuell laufenden Prozesses kommt. Mein Vorhaben: Adressen eines Call-Stacks in Funktionsnamen und Lines auflösen. Ich weiß, wie man einen Call-Stack mit Adressen realisiert, und würde nun gern ein Mapping durchführen. Oder muss ich dafür die bfd.h in meinen Kernel einbauen? Oder geht es vielleicht auch "zu Fuss"? Ich würde ja auch gern verstehen, wie das funktioniert. Hat bestimmt was mit den Segmenten .text, .code und .bss zu tun, wenn ich mir objdump -t anschaue.

So habe ich meine Call-Stack-View gemacht.

void print_call_stack()
{
  void **ebp = 0;

  ASM("mov %%ebp, %0":"=a"(ebp));

  while(ebp)
  {
    kprintf("0x%x\n", ebp[1]); // The caller function address
    ebp = (void**)ebp[0]; // Get previous frame
  }
}

Grüße
12
Lowlevel-Coding / Re: C# als Sprache
« am: 17. May 2007, 20:42 »
Hmm, du hast recht, allerdings hab ich am Makefile geschraubt:

all:
gcc -c -ffreestanding -nostdinc -O3 -Wall loader.c
gmcs -unsafe+ core.cs
mkbundle2 --static -z -c -oo bundle.o core.exe -o core.c
gcc -static -Wall `pkg-config --cflags mono` core.c `pkg-config --libs-only-L mono` -lmono `pkg-config --libs-only-l mono | sed -e "s/\-lmono //"` -lz -lrt loader.o bundle.o -o sharpkernel

Nun bekomm ich folgendes hin:

ldd sharpkernel
       not a dynamic executable

Ausführbar is die Binary aber. Zugegeben das Teil is mörder-groß (3MB), funktioniert aber.


EDIT: Ok, ich seh, was du meinst, es genügt nicht, die Runtime in eine Binary zu embedden, man benötigt natürlich noch einen Kernel, der den Runtime-Code versteht. Das Henne-Ei-Problem. Mein Kernel hat die Runtime mit drin, kann sie aber nicht ausführen, weil er die Befehle nicht hat, die die Runtime benötigt... Man benötigt an dieser Stelle tatsächlich einen Compiler für native Binaries. MS hat so einen Compiler, aber sie geben ihn nicht raus. Er heißt Bartok.
13
Lowlevel-Coding / C# als Sprache
« am: 17. May 2007, 13:00 »
Hallo,

ich möchte hier Ideen austauschen und evtl eine Lösung für ein noch nicht diskutiertes Problem finden oder aber Gewissheit erhalten, dass es SO nicht funktioniert.

Nach dem ich sämtliche Videos über Singularity (http://research.microsoft.com/os/singularity/) gesehen hab, und im allgemeinen die Sprache C# sehr geeignet für jede Menge Projekte halte, machte ich mir Gedanken, wie man das wohl angehen kann. Da C# einen unsafe-Mode hat, kann man damit auch mit Pointern arbeiten, was für die OS-Entwicklung unerlässlich ist.

Das Hauptproblem ist, einen Compiler zu finden, der flache Binaries erzeugt, die statisch sind, also keine zusätzlichen Libs für die Ausführung benötigen. Der Grund wurde ja in den Low-Level-Ausgaben ausreichend erörtert.

Ich suchte nach einer Möglichkeit, Binaries so zu erstellen, das sie kein .Net-Framework bzw. Mono benötigen. Unter Windows wurde ich enttäuscht, mit Mono ist es aber möglich. Mit dem Tool mkbundle (Teil der mono-devel-Pakete) ist es möglich, sämtliche notwendige Libs in eine Binary zu übernehmen.

Darauf hin erstellte ich 2 Dateien und ein Makefile, welche hier hier gern zur Verfügung stellen will:

Makefile:
all:
gcc -c -ffreestanding -nostdinc -O3 -Wall loader.c
gmcs -unsafe+ core.cs
mkbundle2 --static -z -c -oo bundle.o core.exe -o core.c
gcc -Wall -c `pkg-config --clfags mono` core.c
ld `pkg-config --libs-only-L mono` -Wl,-Bstatic -lmono -Wl,-Bdynamic `pkg-config --libs-only-l mono | sed -e "s/-lmono //"` -lz loader.o bundle.o core.o -o kernel

clean:
rm -rf bundle.o core.exe loader.o core.o core.c kernel

core.cs:
namespace kernel
{
public unsafe class core
{
public static void Main(string[] args)
{
// Don't use Console.WriteLine, because we don't have a c#-Lib
}
}
}

loader.c:
extern int main( int argc, char* argv[]);

const unsigned MultibootHeader[12] __attribute__ ((section(".text"))) = {
0x1BADB002,
0x00000000,
0xE4524FFE,
(unsigned)MultibootHeader,
(unsigned)main,
0x00000000,
0x00000000,
(unsigned)main,
0x00000000,
0x00000050,
0x00000019,
0x00000000
};

Die loader.c existiert nur, weil ich mit C# keinen MB-Header erzeugen kann, der auch als solcher anerkannt wird. Vielleicht hat hier jemand ne andere Idee, würde das Thema ungemein vereinfachen.

Grundsätzlich kompiliert und linkt es gut, es gibt noch eine align-Warning für den mb-header in der .text-section, das habe ich aber erstmal ignoriert.

Das Vorgehen kann folgendermaßen erklärt werden:

1. Es wird ein simpler Loader in C erstellt, der dafür verwendet wird, das der Kernel mit Grub gebootet werden kann (dafür gibts mehrere Gründe)
2. Die C#-Sources (hier erstmal nur eine) werden in eine Assembly kompiliert
3. Die Assembly wird durch mkbundle (http://www.die.net/doc/linux/man/man1/mkbundle.1.html) gejagt, und daraus ein Bundle-Object (bundle.o) und ein C-Quelltext (core.c) erzeugt, der das Bundle lädt.
4. Der Bundle-Lader wird zu einem Object kompiliert
5. Alle Objects werden zu einer flachen Binary gelinkt

Das Resultat lässt sich direkt aufrufen, mit mbchk erhalte ich aber keine Meldung, das der MB-Header gefunden wurde.


Vielleicht gibts die/den eine(n) oder andere(n) hier, den das Thema ebenfalls interessiert und Ideen hat, wie das zu lösen wäre.

Grüße
BK
14
Lowlevel-Coding / GDT haut alles durcheinander
« am: 19. October 2005, 16:08 »
Danke, hat sich schon erledigt, ich hab ein genuöses Dokument gefunden:

http://www.osdever.net/bkerndev/Docs/basickernel.htm
15
Lowlevel-Coding / GDT haut alles durcheinander
« am: 19. October 2005, 15:45 »
Stimmt, ich mische anscheinend 16Bit mit 32Bit. Mein Verständnis-Problem liegt im PM-Tutorial.

Ich möchte den Teil des 16-Bit-Kernels als Object linken nicht als Binär-Datei ausgeben.

Ich hab das Assembler (von dem ich noch einiges lernen muss) um ein paar Sachen ergänzt und etwas raus genommen. Das END ist gegen start ausgetauscht worden und start global angelegt.

Im start-Teil wird _main, main und _atexit aufgerufen, so dass ich die Features von C++ nutzen kann - was aber anscheinend nicht zum laufen zu Bewegen ist.

Meine Frage nun an dieser Stelle:

1. Wie muss ich den Assembler anpassen, das es den 16Bit-Code des GDT nutzen kann, ohne ein Bin zu erstellen.
2. Kann ich GRUB dazu verwenden, einen GDT und evtl eine IDT zu laden? Weil Grub für sich ja schon den Protected Mode zur Verfügung stellt.

Grüße und danke für eure Antworten
Beat
16
Lowlevel-Coding / GDT haut alles durcheinander
« am: 27. July 2005, 16:36 »
Anscheinen hab ich ein kleineres Problem. Dummerweise weiß nicht nicht genau, ob es ein etwas größeres is, ich verlass mich da auf mein Gefühl.

Nachdem ich einen C++-Kernel Grub-Kompatible gebaut habe, wollte ich nun  GDT und IDT implementieren. Bleibe aber hängen, weil der nasm den .text-Part anscheinend an eine falsch Stelle schreibt:

Loader.o(.text+0x2c):Loader.o: relocation truncated to fit: 16 against `.text'
Loader.o(.text+0x2f):Loader.o: relocation truncated to fit: 16 against `.text'
Loader.o(.text+0x36):Loader.o: relocation truncated to fit: 16 against `.text'
Loader.o(.text+0x39):Loader.o: relocation truncated to fit: 16 against `.text'
Loader.o(.text+0x4a):Loader.o: relocation truncated to fit: 16 against `.text'
Loader.o(.text+0x4e):Loader.o: relocation truncated to fit: 16 against `.text'
Loader.o(.text+0x55):Loader.o: relocation truncated to fit: 16 against `.text'
Loader.o(.text+0x64):Loader.o: relocation truncated to fit: 16 against `.text'


Ich weiß nun nicht genau, was das zu bedeuten hat, und wie ich es löse. Kann mir da jemand auf die Sprünge helfen?
17
Lowlevel-Coding / LLC unter Linux
« am: 22. May 2004, 21:23 »
Das Low-Level-Coding unter Linux wird sich wohl am besten anbieten, da man hier alles notwendige schon hat, Compiler, Linker, Assembler...

Allerdings, und das ist mir aufgefallen, gehen die Tutorial-Schreiber nicht allzusehr darauf ein. Oder ist das Motto: "Wieso Linux? Da hat man doch nen Kernel zum abgucken..."? Wenn ich nen Blick auf den Source werfe, bin ich hoffnungslos überfordert. Ich will gerade damit anfangen ;-)

Ok, also der GNU CC macht KEINE wie von Teejay geschriebenen Underscores ("_") vor die Funktionen nach dem Compilen. Darum funktioniert das Linken auch per link.txt aus dem C-Tutorial nicht sondern bricht mit "undefined reference to _main" ab. Habe das ASM-File geändert:

##################
[Bits 32]
extern main
global start
global _EnableA20Gate

start:

call main

STOP:
        jmp STOP
##################

Damit geht dat!

Desweiteren ist ein kleiner Typo in der kernel.c. Wenn Du den Video-Speichern ansprechen willst, so muss das 0xB8000 statt 0xA8000 sein. Oder war das Deine Absicht? - Du kleiner Schelm ;-)

OK, zum 2. das Tutorial von Mastermesh. Vielleicht solltest Du in Teil 5 erwähnen, das wenn man einen GRUB verwendet, der den Bootsplash-vanilla-patch implementiert hat, das man das Splash-Image zum testen abschalten sollte. Ich hab 4 Stunden gebraucht, das rauszufinden.

BTW, kann man per C den GFX-Mode von GRUB nicht irgendwie abschalten? Soweit ich das weiß, sind das 640x480 bei 14 Farben (originell!!). Würde mit Assembler sicher irgendwie zu bewerkstellingen sein.

Ansonsten find ich eure Sache richtig genial! Damit bekommt man mal richtigen Kontakt mit dem OS!

Weiter so,
der Beatkiller
Seiten: [1]

Einloggen