C/C++ Forum :: PrettyOS Fehler-/Testthread

Cuervo Mitglied 22:09:40 08.02.2010 Titel:

PrettyOS Fehler-/Testthread

Dieser Thread dient der Sammlung aller Fehler, die in PrettyOS gefunden werden und nicht im Tracker landen.

PrettyOS Tracker:
http://sourceforge.net/tracker/?group_id=282954

Cuervo

Cuervo Mitglied 22:10:42 08.02.2010 Titel:

Revision 85 geht bei mir nur auf einem einzigen Computer fehlerfrei, und zwar PC 2.
PC 1 gibt einen GPF in der PCI-Liste aus und PC 3 startet neu (das ist der, der früher IMMER ging aber kaputt war und ich gestern wieder zusammengebaut habe).
In qemu läuft es, in VirtualBox auch, MS VPC hab ich nicht. In VitualBox läuft es allerdings SEHR langsam... da kann man die roten Punkte mitzählen^^

Cuervo Mitglied 22:12:02 08.02.2010 Titel:

anubis2k5 schrieb:

Revision 86: bei Eingabe von HELLO.ELF wird -->.ELF<-- nicht gefunden.
Bei Eingabe von "hello" hingegen funktioniert es - gewollt?! (Steht bereits auf der To-Do Liste, Nachtrag von Cuervo)

Nachtrag: Besteht die Möglichkeit einen extra Threat zum Testen der Revisionen zu öffnen? Ich glaube hier wird's langsam voll... (Danke für den Hinweis)

Nachtrag 2: Nachdem ich alle *.bin;*.map;*.elf - Dateien gelöscht habe, um ein "sauberes" System zu bekommen, musste ich feststellen, dass die Datei "HELLO.ELF" nicht gefunden wird. Wirklich aussagekräftige Fehlermeldung erhalte ich nicht. Habt ihr eine Idee?

Code:
tools/CreateFloppyImage2 PrettyOS FloppyImage.bin stage1_bootloader/boot.bin sta ge2_bootloader/BOOT2.BIN kernel/KERNEL.BIN user/user_test_c/HELLO.ELF Cannot open the file 'user/user_test_c/HELLO.ELF' mingw32-make: *** [ckernel] Error -1

Code:
tools/CreateFloppyImage2 PrettyOS FloppyImage.bin stage1_bootloader/boot.bin sta ge2_bootloader/BOOT2.BIN kernel/KERNEL.BIN user/user_test_c/HELLO.ELF Cannot open the file 'user/user_test_c/HELLO.ELF' mingw32-make: *** [ckernel] Error -1

Code:
tools/CreateFloppyImage2 PrettyOS FloppyImage.bin stage1_bootloader/boot.bin sta ge2_bootloader/BOOT2.BIN kernel/KERNEL.BIN user/user_test_c/HELLO.ELF Cannot open the file 'user/user_test_c/HELLO.ELF' mingw32-make: *** [ckernel] Error -1

Erhard Henkes Mitglied 22:28:12 08.02.2010 Titel:

HELLO.ELF unbedingt in Großschrift liefern.

anubis2k5 Mitglied 18:09:28 09.02.2010 Titel:

Ist es so gedacht, dass sich die externen Dateien nur ohne die Eingabe der Endung aufrufen lassen? Bsp: hello - funktioniert; hello.elf funktioniert nicht?!

Erhard Henkes Mitglied 19:05:58 09.02.2010 Titel:

Zitat:

Ist es so gedacht, dass sich die externen Dateien nur ohne die Eingabe der Endung aufrufen lassen? Bsp: hello - funktioniert; hello.elf funktioniert nicht?!

Beides sollte funktionieren. Da ist was durch die Veränderungen durcheinander geraten. Gib bitte solange

Code:
HELLO .ELF

Code:
HELLO .ELF

Code:
HELLO .ELF

ein, bis es wieder geht.

anubis2k5 Mitglied 20:55:07 09.02.2010 Titel:

OK...

Nächste Meldung: Habe unter Bochs Probleme PrettyOS zum laufen zu bringen. Bochs kann scheinbar nicht vom Image booten - Pfadanpassung in der entsprechenden Config brachte leider keine Erfolge.

Zitat:

Meldung:
00020932447p[BIOS ] >>PANIC<< No bootable device.

Erhard Henkes Mitglied 22:24:54 09.02.2010 Titel:

Ich verwende momentan bochs überhaupt nicht mehr, sondern nur noch qemu, weil es deutlich schneller ist.

Ich habe es gerade mal wieder mit Bochs getestet, geht bestens vom Image:

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45	romimage: file=$BXSHARE/BIOS-bochs-latest cpu: count=1, ips=10000000, reset_on_triple_fault=1 megs: 1024 vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest vga: extension=vbe floppya: 1_44=G:\OSDev\PrettyOS\trunk\Source\FloppyImage.bin, status=inserted ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15 ata2: enabled=0, ioaddr1=0x1e8, ioaddr2=0x3e0, irq=11 ata3: enabled=0, ioaddr1=0x168, ioaddr2=0x360, irq=9 boot: floppy floppy_bootsig_check: disabled=0 log: bochsout.txt panic: action=ask error: action=report info: action=report debug: action=ignore debugger_log: - parport1: enabled=1, file="parport.out" vga_update_interval: 300000 keyboard_serial_delay: 250 keyboard_paste_delay: 100000 mouse: enabled=0 private_colormap: enabled=0 keyboard_mapping: enabled=0, map= i440fxsupport: enabled=0

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45	romimage: file=$BXSHARE/BIOS-bochs-latest cpu: count=1, ips=10000000, reset_on_triple_fault=1 megs: 1024 vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest vga: extension=vbe floppya: 1_44=G:\OSDev\PrettyOS\trunk\Source\FloppyImage.bin, status=inserted ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15 ata2: enabled=0, ioaddr1=0x1e8, ioaddr2=0x3e0, irq=11 ata3: enabled=0, ioaddr1=0x168, ioaddr2=0x360, irq=9 boot: floppy floppy_bootsig_check: disabled=0 log: bochsout.txt panic: action=ask error: action=report info: action=report debug: action=ignore debugger_log: - parport1: enabled=1, file="parport.out" vga_update_interval: 300000 keyboard_serial_delay: 250 keyboard_paste_delay: 100000 mouse: enabled=0 private_colormap: enabled=0 keyboard_mapping: enabled=0, map= i440fxsupport: enabled=0

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45	romimage: file=$BXSHARE/BIOS-bochs-latest cpu: count=1, ips=10000000, reset_on_triple_fault=1 megs: 1024 vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest vga: extension=vbe floppya: 1_44=G:\OSDev\PrettyOS\trunk\Source\FloppyImage.bin, status=inserted ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15 ata2: enabled=0, ioaddr1=0x1e8, ioaddr2=0x3e0, irq=11 ata3: enabled=0, ioaddr1=0x168, ioaddr2=0x360, irq=9 boot: floppy floppy_bootsig_check: disabled=0 log: bochsout.txt panic: action=ask error: action=report info: action=report debug: action=ignore debugger_log: - parport1: enabled=1, file="parport.out" vga_update_interval: 300000 keyboard_serial_delay: 250 keyboard_paste_delay: 100000 mouse: enabled=0 private_colormap: enabled=0 keyboard_mapping: enabled=0, map= i440fxsupport: enabled=0

Mr X Mitglied 18:52:55 10.02.2010 Titel:

So, ich meld mich hier auch mal...

Mein Problem:
Texteingabe funktioniert in user-programmen nicht. ich bekomme nicht die möglichkeit (weder selbstgeschriebene noch hello.elf) einen Text einzugeben; das Programm beendet sich in dem Moment, wo man etwas eingeben müsste. (Wenn man den Text ausgeben lässt, nachdem man getch() genutzt hat, wird der Text nicht angezeigt, andernfalls jedoch schon).

EDIT: ich hätt wohl noch auf die Revision und die Umgebung eingehen sollen: Das Problem besteht mindestens seit Revision 86. 87 enthält es auch. Verwendetes System: Sun Virtual Box 3.1.2

anubis2k5 Mitglied 21:07:47 10.02.2010 Titel:

Hast du irgendwo eine Test-File im Repository liegen?

Erhard Henkes Mitglied 00:24:01 11.02.2010 Titel:

Bitte mal http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=88 testen (den Absturz des user-program habe ich hoffentlich verhindert, denn ab und zu läuft das einfach über exit hinaus! :confused:

Erhard Henkes Mitglied 02:09:08 11.02.2010 Titel:

http://www.c-plusplus.de/forum/viewtopic-var-p-is-1853944.html#1853944

Rev. 89 hat das Problem nun endlich im Griff. Während gets wurde der Task gewechselt. Die shell hat dem User-Programm die Eingaben gestohlen.

Was ist hier die beste Lösung?

Cuervo Mitglied 07:57:55 11.02.2010 Titel:

Beste Lösung: Der Kernel verwaltet die Tastatureingaben und gibt sie an das aktuelle Programm weiter (das, das sichtbar (oder so) ist), oder an das, das gemeldet hat, dass es eine Eingabe will. Dann müsste die Shell solange "anhalten".

Ausserdem kommen die Farben beim Multitasking durcheinander, also sollte jedes Programm seine Farbe merken und wieder aktivieren, wenn es dran ist...

anubis2k5 Mitglied 17:36:57 11.02.2010 Titel:

Rev. 89 läuft bei mir Fehlerfrei. Auch das mehrfache ausführen von hello.elf funktioniert tatellos!

Mr X Mitglied 19:13:00 11.02.2010 Titel:

eigentlich funktioniert alles soweit, aber ich hab noch etwas (nicht so wichtig, eigentlich) gefunden: Die Sekunden seit dem Start laufen viel! zu schnell.

Mr X Mitglied 19:32:54 11.02.2010 Titel:

Noch ein (erheblich größeres) Problem.
Es kommt mglw. durch das Multithreading.

Die Konsolenausgabe läuft nicht geordnet. Das äußert sich wie folgt:
Textfarbe ändert sich ohne zutun meinerseits mitten im user-programm und es werden Zeilen vertauscht. Dies tritt insbesondere nach Benutzereingabe auf.

EDIT: hälfte vergessen ;-)
getch funktioniert garnicht; selbe problem wie gehabt (falls das eigentlich hätte behoben sein sollen)

Erhard Henkes Mitglied 21:03:46 11.02.2010 Titel:

Zitat:

getch funktioniert garnicht; selbe problem wie gehabt

Hast Du den Stack-Pointer auch gegenüber program.c verändert für das weitere Programm hello.c (oder test.c oder was auch immer)? Ist offenbar notwendig. Darüber müssen wir noch diskutieren.
start.asm:

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	; start.asm [BITS 32] extern __bss_start extern __end extern _main extern _exit extern _test global _start _start: mov esp, 0x500000 ; stackpointer call _main call _exit call _test jmp $

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	; start.asm [BITS 32] extern __bss_start extern __end extern _main extern _exit extern _test global _start _start: mov esp, 0x500000 ; stackpointer call _main call _exit call _test jmp $

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	; start.asm [BITS 32] extern __bss_start extern __end extern _main extern _exit extern _test global _start _start: mov esp, 0x500000 ; stackpointer call _main call _exit call _test jmp $

Mr X Mitglied 21:05:50 11.02.2010 Titel:

ich hab die neue start.asm verwendet...

Erhard Henkes Mitglied 21:07:01 11.02.2010 Titel:

OK, dann wundert mich das schon etwas. Kannst Du genau ausführen oder testen, was nicht geht? Mit was testest Du (real, simulation)?

Mr X Mitglied 21:13:37 11.02.2010 Titel:

ich teste mit Virtual Box 3.1.2

Hab übrigens da gleich mal virtualPC gestartet: Kann keine User-progs laden. Lesefehler von der Disk

Erhard Henkes Mitglied 21:57:10 11.02.2010 Titel:

Ja, das ist mir auch schon aufgefallen, dass Virtual PC nicht von Floppy liest. Real geht es aber, zumindest bei meinen Test-PC.

anubis2k5 Mitglied 22:18:43 11.02.2010 Titel:

Ich weiß nicht ob das schon irgendwo aufgenommen wurde: Nach dem Programmstart (hello.elf, clear.elf) wird der Prompt nicht wieder neu gezeichnet. Habs jetzt auch nochmal in VirtualBox getestet, wo's auch perfekt läuft.

Erhard Henkes Mitglied 22:32:44 11.02.2010 Titel:

Ja, bei mir läuft es auch in Sun VB. In der Rev. 90 wurden noch zwei Fehler im Kernel beseitigt.

Erhard Henkes Mitglied 05:01:21 12.02.2010 Titel:

Anmerkungen zu Rev. 91:

mit echter Floppy: (klappt offenbar nicht überall lt. Cuervo)
- FAT lesen zu langsam (umbauen auf einmaliges Lesen der gesamten FAT in ein Array, dann evtl. nur die Blöcke von 12 Bit entziffern, die wirklich für ein File beim Laden gebraucht werden)
- #define FATMAXINDEX 150 ///TEST <--- nur als Test brauchbar, denn der Wert kann überschritten werden (momentaner work-around: floppy disk vor dem Aufspielen der Files formatieren), dann #PF als Ergebnis

Allgemein:
- Zeichenausgaben (incl. Farbe) geraten beim Taskwechsel noch allgemein durcheinander (Kritische Ressourcen während Benutzung allokieren für eine Task --> "critical section")

- shell: Eingabe "hello.elf" --> sucht nach ".elf" (Eingabe-Algo überarbeiten)

Simulationen:
- MS Virtual PC liest nicht von Floppy

anubis2k5 Mitglied 15:09:33 12.02.2010 Titel:

Rev. 91 läuft stabil in VirtualBox und Qemu.

Wer schreibt eigentlich an der Shell? Würde mich da gern einbringen und unterstützend wirken. Ebenso was externe Programme betrifft.

Erhard Henkes Mitglied 19:42:33 12.02.2010 Titel:

Zitat:

Wer schreibt eigentlich an der Shell? Würde mich da gern einbringen und unterstützend wirken.

Ich schreibe an der shell. Vielleicht findet jemand heraus, wie man die Abfrage der shell so umbauen kann, dass sowohl

Code:
"hello", "hello.elf", "hello .elf", "hello .elf", "hello .elf"

Code:
"hello", "hello.elf", "hello .elf", "hello .elf", "hello .elf"

Code:
"hello", "hello.elf", "hello .elf", "hello .elf", "hello .elf"

(1,4,5 geht, wenn ich das richtig sehe; 2 u. 3 werden als ".ELF" gewertet) als

Code:
"HELLO ELF"

Code:
"HELLO ELF"

Code:
"HELLO ELF"

interpretiert wird. Da habe ich mich irgendwie verhaspelt, das ging sogar schon.

Zitat:

Ebenso was externe Programme betrifft.

Das machen wohl einige momentan. Gute Ideen werden hier gerne gesehen. Man muss ja nur hello.c austauschen gegen eigenen Code. Allerdings sind die userlib.h/c und die syscalls noch ziemlich rudimentär. Anregungen werden gerne entgegen genommen.

XanClic Mitglied 20:15:05 12.02.2010 Titel:

Erhard Henkes schrieb:

Vielleicht findet jemand heraus, wie man die Abfrage der shell so umbauen kann, dass sowohl

Code:
"hello", "hello.elf", "hello .elf", "hello .elf", "hello .elf"

Code:
"hello", "hello.elf", "hello .elf", "hello .elf", "hello .elf"

Code:
"hello", "hello.elf", "hello .elf", "hello .elf", "hello .elf"

(1,4,5 geht, wenn ich das richtig sehe; 2 u. 3 werden als ".ELF" gewertet) als

Code:
"HELLO ELF"

Code:
"HELLO ELF"

Code:
"HELLO ELF"

interpretiert wird.

Mit einem svn diff von

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	1 2 3 4 5 6 7 8 9 10 11 12 13	Index: user/user_program_c/program.c =================================================================== --- user/user_program_c/program.c (Revision 91) +++ user/user_program_c/program.c (Arbeitskopie) @@ -149,7 +149,7 @@ } } - for(i=posPoint+1;i<12;i++) + for(i=posPoint+1;i<posPoint+4;i++) { ext[i-posPoint-1]=entry[i]; }

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	Index: user/user_program_c/program.c =================================================================== --- user/user_program_c/program.c (Revision 91) +++ user/user_program_c/program.c (Arbeitskopie) @@ -149,7 +149,7 @@ } } - for(i=posPoint+1;i<12;i++) + for(i=posPoint+1;i<posPoint+4;i++) { ext[i-posPoint-1]=entry[i]; }

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	Index: user/user_program_c/program.c =================================================================== --- user/user_program_c/program.c (Revision 91) +++ user/user_program_c/program.c (Arbeitskopie) @@ -149,7 +149,7 @@ } } - for(i=posPoint+1;i<12;i++) + for(i=posPoint+1;i<posPoint+4;i++) { ext[i-posPoint-1]=entry[i]; }

funktioniert es, also eine Ersetzung in Zeile 152 der benannten Datei.

Ohne diese Änderung gibt es einen Pufferüberlauf auf dem Stack, somit wird "name" überschrieben und am Ende kommt ".ELF" raus ("name" beginnt mit '\0').

Erhard Henkes Mitglied 23:20:10 12.02.2010 Titel:

Merkwürdig, ich wusste doch, dass das schon geklappt hat. Danke nochmals.

XanClic Mitglied 23:58:56 12.02.2010 Titel:

Du schreibst auch vieles, was du im IRC sagst, nochmal ins Forum.

Erhard Henkes Mitglied 07:12:22 13.02.2010 Titel:

Wir loggen das IRC nicht zentral mit, daher ist das "Forum" ein wichtiges Kommunikationsmedium, in dem der Fortschritt und die Wirren von PrettyOS festgehalten werden sollten. Daher die Bitte, alle wichtigen Beiträge hier ebenfalls einzupflegen.

Cuervo Mitglied 08:12:10 15.02.2010 Titel:

Rev. 103:

PrettyOS erkennt nur großgeschriebene Dateien, ein Fehler, den ich sehr spät bemerkt habe..-.- Ist etwas ungünstig, da ich aus Gewohnheit immer kleine Buchstaben verwende.

Mr X Mitglied 10:59:21 15.02.2010 Titel:

Das kann ich nicht bestätigen, Cuervo...

XanClic Mitglied 14:18:54 15.02.2010 Titel:

Ich auch nicht...

Aber ich habe ein anderes Problem: Wenn ich hello.elf starte und weiter Backspace mache, als eigentlich möglich ist (und danach dann normal weiterspiele), bekomme ich beim Beenden einen Pagefault:

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16	page not present at user-mode (errcode = 0x00000004) CR2 = 0x08080804 CS:EIP = 0x001B:0x0140050D SS:ESP = 0x0023:0x08080804 EFLAGS = 0x00000212 EAX = 0x00000000 EBX = 0x08080808 ECX = 0x08080808 EDX = 0x00000000 ESI = 0x08080808 EDI = 0x08081B08 EBP = 0x08080808 DS = 0x0023 ES = 0x0023 FS = 0x0023 GS = 0x0023

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16	page not present at user-mode (errcode = 0x00000004) CR2 = 0x08080804 CS:EIP = 0x001B:0x0140050D SS:ESP = 0x0023:0x08080804 EFLAGS = 0x00000212 EAX = 0x00000000 EBX = 0x08080808 ECX = 0x08080808 EDX = 0x00000000 ESI = 0x08080808 EDI = 0x08081B08 EBP = 0x08080808 DS = 0x0023 ES = 0x0023 FS = 0x0023 GS = 0x0023

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16	page not present at user-mode (errcode = 0x00000004) CR2 = 0x08080804 CS:EIP = 0x001B:0x0140050D SS:ESP = 0x0023:0x08080804 EFLAGS = 0x00000212 EAX = 0x00000000 EBX = 0x08080808 ECX = 0x08080808 EDX = 0x00000000 ESI = 0x08080808 EDI = 0x08081B08 EBP = 0x08080808 DS = 0x0023 ES = 0x0023 FS = 0x0023 GS = 0x0023

Ohne in den Code gesehen zu haben würde ich raten, dass da ein Stackoverflow geschieht: Vermutlich wird die Eingabe des Benutzers in einem Array auf dem Stack gespeichert. Wenn man zu oft Backspace drückt, dann wird der ganze Stack mit \b (also 0x08) überschrieben und dann werden am Ende des Programms die gespeicherten Register vom Stack geholt (so entstehen 0x08080808 in EBX, ECX, ESI, (EDI) und EBP). Dahinter steht dann wohl noch eine C-Funktion, die am Ende den Stackframe mit "mov esp,ebp" und "pop ebp" aufzulösen versucht. Erstere Funktion führt dazu, dass 0x08080808 in ESP geladen wird und die zweite zieht zuerst 4 von ESP ab (sodass 0x08080804 drinsteht) und versucht dann, einen Wert von dieser Adresse zu laden. Diese ist offensichtlich nicht gemappt und das führt dann zum PF an dieser Adresse.

q.e.d.

EDIT: PS, bitte mal die Vordergrundfarbe bei Panics ändern. Dieses Dunkelrot ist echt nicht zu erkennen, da macht man sich die Augen kaputt. Hellrot wäre besser.

Cuervo Mitglied 18:03:53 15.02.2010 Titel:

komisch, also wenn ich z.B. hello eingebe, wird daraus HELLO .ELF und hello.elf wird nur gefunden, wenn es groß geschrieben ist (auf der Diskette)...

XanClic Mitglied 18:42:23 15.02.2010 Titel:

Cuervo schrieb:

komisch, also wenn ich z.B. hello eingebe, wird daraus HELLO .ELF und hello.elf wird nur gefunden, wenn es groß geschrieben ist (auf der Diskette)...

Natürlich wird daraus HELLO.ELF, auf FAT wird Groß- und Kleinschreibung nicht unterschieden und es ist vorgeschrieben, dass Dateinamen als Großbuchstaben (zumindest ohne VFAT) gespeichert werden.

Cuervo Mitglied 18:56:38 15.02.2010 Titel:

mag sein, PrettyOS zeigt jedenfalls hello.elf unter fdir an statt HELLO.ELF und findet es nicht, vermutlich weil die Eingabe in Großbuchstaben umgewandelt wird.

XanClic Mitglied 19:39:31 15.02.2010 Titel:

Wenn du in den Quellcode der Shell sehen würdest, könntest du sehen, dass das tatsächlich so ist.

Cuervo Mitglied 19:49:11 15.02.2010 Titel:

Dann hatte ich ja Recht^^

C/C++ Code:
else { puts("file is being searched.\n"); settextcolor(2,0); toupper(entry);

C/C++ Code:
else { puts("file is being searched.\n"); settextcolor(2,0); toupper(entry);

C/C++ Code:
else { puts("file is being searched.\n"); settextcolor(2,0); toupper(entry);

Also ist das ein Fehler, weil die Datei ja hello.elf und nicht HELLO.ELF heißt.

Erhard Henkes Mitglied 20:08:17 15.02.2010 Titel:

Zitat:

vermutlich weil die Eingabe in Großbuchstaben umgewandelt wird

Wie gesehen, machen wir das FAT12-gerecht. Kleinschreibung ist nicht vorgesehen für Filename und Extension. Wenn also von anderen Sytemnen auf die Diskette geschrieben wird, bitte nur Großschreibung verwenden.

Wenn es dich momentan stört, nimmst Du das toupper(entry); eben raus.

Damit haben wir den üblichen Konflikt zwischen Windows Client und Linux Server, wenn ich das richtig sehe.

Wie wird das allgemein im OSDEV-Bereich gehandhabt?

XanClic Mitglied 20:55:41 15.02.2010 Titel:

Cuervo schrieb:

Also ist das ein Fehler, weil die Datei ja hello.elf und nicht HELLO.ELF heißt.

Bei FAT ist es (ohne VFAT) halt einfach vorgeschrieben, dass der Dateiname großgeschrieben wird. Deshalb gibt es keinen Unterschied zwischen "hello.elf" und "HELLO.ELF".

EDIT: vgl. http://en.wikipedia.org/wiki/8.3_filename#Overview: "File and directory names are uppercase, although systems that use the 8.3 standard are usually case-insensitive."
oder auch http://en.wikipedia.org/wiki/File_Allocation_Table#Directory_table: "Legal characters for DOS file names include the following: Upper case letters A–Z [...]" -- "This excludes the following ASCII characters: [...] Lower case letters a–z; Stored as A–Z. [...]"

Erhard Henkes Mitglied 20:59:02 15.02.2010 Titel:

Weiß eigentlich jemand, warum man das damals so entschieden hat? Linux ist ja im Gegensatz dazu case-sensitive.

Badestrand Mitglied 19:22:27 21.02.2010 Titel:

Der Zug bewegt sich bei mir immer unter Bochs nur weiter, wenn ich eine Taste drücke (oder ist das Absicht?).

Mr X Mitglied 19:24:50 21.02.2010 Titel:

Das ist überall so und liegt nicht an Bochs...

Erhard Henkes Mitglied 20:55:50 21.02.2010 Titel:

Zitat:

Der Zug bewegt sich bei mir immer unter Bochs nur weiter, wenn ich eine Taste drücke (oder ist das Absicht?).

Ja, das hat sich so ergeben, weil wir den inneren Loop nun nicht in der gesamten Shell, sondern nur in getch drehen (siehe Definition von getch in user-Lib). Wir fangen die vom Kernel zurück gegebene 0 dort ab.

anubis2k5 Mitglied 22:06:16 21.02.2010 Titel:

Unter VirtualBox v3.1.4 r57640 stürtz PrettyOS Rev. 120 ab. Scheinbar geschieht dies, nachdem das Datum ausgegeben wird. Falls jemand interesse an der Log-Datei von VBox hat, ist diese hier zu finden: http://anubis2k5.bplaced.net/VBox.log

Unter Qemu läuft das OS normal.

Mr X Mitglied 22:54:27 21.02.2010 Titel:

Das Problem ist bekannt und auch mit Microsoft Virtual PC läuft PrettyOS derzeit nicht, anscheinend gibt es auch Probleme mit einigen echten PCs, die damit vlt. zusammenhängen.

Erhard Henkes Mitglied 23:33:01 21.02.2010 Titel:

Zitat:

00:00:03.394 PIT: mode=3 count=0x2e9b (11931) - 100.00 Hz (ch=0)
00:00:05.612 fatal error in recompiler cpu: triple fault
00:00:05.612 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
00:00:05.612 !!
00:00:05.612 !! Guru Meditation -2301 (VERR_REM_VIRTUAL_CPU_ERROR)

Leider versteht niemand bisher diesen "fatal error".

Mr X Mitglied 20:58:09 22.02.2010 Titel:

Sooo... Ich hab auch Fehler im Angebot

1. Page-Fault unter Qemu 0.12.2. Screenshot: http://kloke-witten.dyndns.org/~philipp/Temp/Fehler_Rev125.png

2. Uhr läuft ca. 2x zu schnell unter Virtual Box 3.1.4

3. Dieser Fehler ist etwas komplizierter zu beschreiben und ich hab ihn auch schon geschildert, wobei Erhard und ich nicht zu einer Lösung gekommen sind (Im IRC). Bevor das in Vergessenheit gerät, kommt hier die Fehlerbeschreibung (Ich hab das Verhalten auch noch etwas genauer Analysiert):
Das Problem tritt in Userprogrammen bei der Texteingabe auf. Die Backspace-Taste funktioniert nicht richtig, wenn man versucht, das erste Zeichen der Zeile zu löschen: Es wird das erste Zeichen dieser Zeile und das letzte Zeichen der vorigen Zeile gelöscht. Der Schreibcursor springt dann auch in die vorige Zeile. Testsystem: Virtual Box 3.1.4; Der Fehler tritt meines Wissens nach auch mit anderen Simulationen auf, komischerweise hab aber bislang nur ich ihn reproduzieren können :confused:

.

mfg und in der Hoffnung, das die Fehler gefunden und behoben werden

Mr X

Erhard Henkes Mitglied 21:55:36 22.02.2010 Titel:

zu 3)
Das ist der Code von gets:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29	char* gets(char* s) { int i=0; char c; //settaskflag(0); do { c = getch(); putch(c); if(c==8) // Backspace { if(i>0) { s[i-1]='\0'; --i; } } s[i] = c; i++; } while(c!=10); // Linefeed s[i]='\0'; //settaskflag(1); return s; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29	char* gets(char* s) { int i=0; char c; //settaskflag(0); do { c = getch(); putch(c); if(c==8) // Backspace { if(i>0) { s[i-1]='\0'; --i; } } s[i] = c; i++; } while(c!=10); // Linefeed s[i]='\0'; //settaskflag(1); return s; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29	char* gets(char* s) { int i=0; char c; //settaskflag(0); do { c = getch(); putch(c); if(c==8) // Backspace { if(i>0) { s[i-1]='\0'; --i; } } s[i] = c; i++; } while(c!=10); // Linefeed s[i]='\0'; //settaskflag(1); return s; }

Vielleicht fällt jemand da etwas auf? MrX und Cuervo mäkeln daran herum.

//settaskflag(0); <--- warum auskommentiert?

Mr X Mitglied 22:14:57 22.02.2010 Titel:

Nachdem ich mir gets() näher beguckt hab, bin ich zu dem Schluss gekommen, das der Fehler mglw. eher in getch() o.ä. zu suchen ist.

Abgesehen davon denke ich, das z.20 und 21 von einem else-Block umschlossen werden sollten; Es ist imho wohl eher nicht sinnvoll, Die Felder, wo gelöscht wurde mit dem Wert 8 zu füllen, nachdem man sie grad zuvor mit 0 gefüllt hat.

Erhard Henkes Mitglied 01:20:32 23.02.2010 Titel:

Damit geht es nun:

Testversion:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67	char* gets(char* s) { int i=0,flag=0; char c; //settaskflag(0); do { c = getch(); //settextcolor(i,0);///TEST if(c=='\b') // Backspace { if(i>0) { putch(c); s[i-1]='\0'; --i; } else { beep(50,20); if(flag==false) { putch('\n'); flag=true; } } } else { s[i] = c; putch(c); flag=false; i++; } } while(c!=10); // Linefeed s[i]='\0'; settextcolor(15,0); int j; for(j=0;j<15;j++) { if(s[j]=='\b') { puts("backspace"); } else if(s[j]=='\0') { puts("EOS"); putch('\n'); break; } else if(s[j]=='\n') { puts("NL"); } else { putch(s[j]); } putch('\n'); } //settaskflag(1); return s; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67	char* gets(char* s) { int i=0,flag=0; char c; //settaskflag(0); do { c = getch(); //settextcolor(i,0);///TEST if(c=='\b') // Backspace { if(i>0) { putch(c); s[i-1]='\0'; --i; } else { beep(50,20); if(flag==false) { putch('\n'); flag=true; } } } else { s[i] = c; putch(c); flag=false; i++; } } while(c!=10); // Linefeed s[i]='\0'; settextcolor(15,0); int j; for(j=0;j<15;j++) { if(s[j]=='\b') { puts("backspace"); } else if(s[j]=='\0') { puts("EOS"); putch('\n'); break; } else if(s[j]=='\n') { puts("NL"); } else { putch(s[j]); } putch('\n'); } //settaskflag(1); return s; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67	char* gets(char* s) { int i=0,flag=0; char c; //settaskflag(0); do { c = getch(); //settextcolor(i,0);///TEST if(c=='\b') // Backspace { if(i>0) { putch(c); s[i-1]='\0'; --i; } else { beep(50,20); if(flag==false) { putch('\n'); flag=true; } } } else { s[i] = c; putch(c); flag=false; i++; } } while(c!=10); // Linefeed s[i]='\0'; settextcolor(15,0); int j; for(j=0;j<15;j++) { if(s[j]=='\b') { puts("backspace"); } else if(s[j]=='\0') { puts("EOS"); putch('\n'); break; } else if(s[j]=='\n') { puts("NL"); } else { putch(s[j]); } putch('\n'); } //settaskflag(1); return s; }

Ich kommentiere das aus und stelle es hoch. Liegt nicht am TTT, habe es separat mit einem anderen Programm getestet:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	#include "userlib.h" int main() { puts("*******************************************************************************\n"); puts(" Eingabe-Test \n"); puts("*****************************************************************************\n"); char str[100]; for(int i = 0; i < 5; ++i) { puts("Bitte Eingabe:\n"); gets(str); puts(str); } return** 0; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	#include "userlib.h" int main() { puts("*******************************************************************************\n"); puts(" Eingabe-Test \n"); puts("*****************************************************************************\n"); char str[100]; for(int i = 0; i < 5; ++i) { puts("Bitte Eingabe:\n"); gets(str); puts(str); } return** 0; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	#include "userlib.h" int main() { puts("*******************************************************************************\n"); puts(" Eingabe-Test \n"); puts("*****************************************************************************\n"); char str[100]; for(int i = 0; i < 5; ++i) { puts("Bitte Eingabe:\n"); gets(str); puts(str); } return** 0; }

Erhard Henkes Mitglied 01:50:22 23.02.2010 Titel:

zu 1) das liegt an der in Paging neu eingebauten Funktion, die momentan nur ab 0xF0000000 funktioniert. Badestrand untersucht diesen Punkt bereits.

zu 3) MS VPC läuft ok; Sun VB wirklich merkwürdig mit den Sekunden.

Man schafft es auch eher, bei Sun VB durch heftiges Drücken der Backspace-Taste in die obere Zeile zu geraten. Bei MS VPC gelingt mir das nicht.

MS VPC ist für Tests offenbar gar nicht so schlecht geeignet.

Erhard Henkes Mitglied 21:28:15 23.02.2010 Titel:

An gets(...) wird immer noch herum gemeckert. :rolleyes:

Bei mir klappt es soweit. Grund für Probleme liegt vermutlich an anderer Stelle. Eingegebener String kommt sauber an. Rücksprung auf obere Zeile nur selten (muss mit dem Taskwechsel zusammen hängen, den man ja ausschalten kann in der Funktion <--- wurde von MrX getestet: brachte nichts). Mysteriös.

Mr X Mitglied 20:32:44 26.02.2010 Titel:

Ich hab PrettyOS mal durch cppcheck gejagt. Folgendes Ergebnis kam raus (Irrelevantes à la "use fgets instead of gets" entfernt):

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34	[elf.c:74]: (style) struct or union member 'elf_header_t::shoff' is never used [elf.c:75]: (style) struct or union member 'elf_header_t::flags' is never used [elf.c:76]: (style) struct or union member 'elf_header_t::ehsize' is never used [elf.c:79]: (style) struct or union member 'elf_header_t::shentrysize' is never used [elf.c:80]: (style) struct or union member 'elf_header_t::shnum' is never used [elf.c:81]: (style) struct or union member 'elf_header_t::shstrndx' is never used [elf.c:101]: (style) struct or union member 'program_header_t::paddr' is never used [elf.c:104]: (style) struct or union member 'program_header_t::flags' is never used [elf.c:105]: (style) struct or union member 'program_header_t::align' is never used [fat12.c:676]: (style) The scope of the variable j can be reduced [paging.c:33]: (style) struct or union member '__attribute__::ext' is never used [video.c:177]: (style) The scope of the variable temp can be reduced [../tools/src/CreateFloppyImage.cpp:30]: (style) struct or union member 'BootSector::ignore1' is never used [../tools/src/CreateFloppyImage.cpp:31]: (style) struct or union member 'BootSector::oem_name' is never used [../tools/src/CreateFloppyImage.cpp:38]: (style) struct or union member 'BootSector::media_destriptor_byte' is never used [../tools/src/CreateFloppyImage.cpp:40]: (style) struct or union member 'BootSector::sectors_per_track' is never used [../tools/src/CreateFloppyImage.cpp:41]: (style) struct or union member 'BootSector::head_count' is never used [../tools/src/CreateFloppyImage.cpp:42]: (style) struct or union member 'BootSector::hidden_sectors' is never used [../tools/src/CreateFloppyImage.cpp:43]: (style) struct or union member 'BootSector::sector_count_ex' is never used [../tools/src/CreateFloppyImage.cpp:44]: (style) struct or union member 'BootSector::drive_number' is never used [../tools/src/CreateFloppyImage.cpp:45]: (style) struct or union member 'BootSector::ignore2' is never used [../tools/src/CreateFloppyImage.cpp:46]: (style) struct or union member 'BootSector::boot_signature' is never used [../tools/src/CreateFloppyImage.cpp:47]: (style) struct or union member 'BootSector::volume_serial' is never used [../tools/src/CreateFloppyImage.cpp:48]: (style) struct or union member 'BootSector::fs_name' is never used [../tools/src/CreateFloppyImage.cpp:50]: (style) struct or union member 'BootSector::bootloader' is never used [../tools/src/CreateFloppyImage.cpp:51]: (style) struct or union member 'BootSector::bootloader_sig' is never used [../user/user_program_c/userlib.c:418]: (style) The scope of the variable i can be reduced [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp1 can be reduced [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp2 can be reduced [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp3 can be reduced [../user/user_test_c/userlib.c:418]: (style) The scope of the variable i can be reduced [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp1 can be reduced [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp2 can be reduced [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp3 can be reduced

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34	[elf.c:74]: (style) struct or union member 'elf_header_t::shoff' is never used [elf.c:75]: (style) struct or union member 'elf_header_t::flags' is never used [elf.c:76]: (style) struct or union member 'elf_header_t::ehsize' is never used [elf.c:79]: (style) struct or union member 'elf_header_t::shentrysize' is never used [elf.c:80]: (style) struct or union member 'elf_header_t::shnum' is never used [elf.c:81]: (style) struct or union member 'elf_header_t::shstrndx' is never used [elf.c:101]: (style) struct or union member 'program_header_t::paddr' is never used [elf.c:104]: (style) struct or union member 'program_header_t::flags' is never used [elf.c:105]: (style) struct or union member 'program_header_t::align' is never used [fat12.c:676]: (style) The scope of the variable j can be reduced [paging.c:33]: (style) struct or union member '__attribute__::ext' is never used [video.c:177]: (style) The scope of the variable temp can be reduced [../tools/src/CreateFloppyImage.cpp:30]: (style) struct or union member 'BootSector::ignore1' is never used [../tools/src/CreateFloppyImage.cpp:31]: (style) struct or union member 'BootSector::oem_name' is never used [../tools/src/CreateFloppyImage.cpp:38]: (style) struct or union member 'BootSector::media_destriptor_byte' is never used [../tools/src/CreateFloppyImage.cpp:40]: (style) struct or union member 'BootSector::sectors_per_track' is never used [../tools/src/CreateFloppyImage.cpp:41]: (style) struct or union member 'BootSector::head_count' is never used [../tools/src/CreateFloppyImage.cpp:42]: (style) struct or union member 'BootSector::hidden_sectors' is never used [../tools/src/CreateFloppyImage.cpp:43]: (style) struct or union member 'BootSector::sector_count_ex' is never used [../tools/src/CreateFloppyImage.cpp:44]: (style) struct or union member 'BootSector::drive_number' is never used [../tools/src/CreateFloppyImage.cpp:45]: (style) struct or union member 'BootSector::ignore2' is never used [../tools/src/CreateFloppyImage.cpp:46]: (style) struct or union member 'BootSector::boot_signature' is never used [../tools/src/CreateFloppyImage.cpp:47]: (style) struct or union member 'BootSector::volume_serial' is never used [../tools/src/CreateFloppyImage.cpp:48]: (style) struct or union member 'BootSector::fs_name' is never used [../tools/src/CreateFloppyImage.cpp:50]: (style) struct or union member 'BootSector::bootloader' is never used [../tools/src/CreateFloppyImage.cpp:51]: (style) struct or union member 'BootSector::bootloader_sig' is never used [../user/user_program_c/userlib.c:418]: (style) The scope of the variable i can be reduced [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp1 can be reduced [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp2 can be reduced [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp3 can be reduced [../user/user_test_c/userlib.c:418]: (style) The scope of the variable i can be reduced [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp1 can be reduced [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp2 can be reduced [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp3 can be reduced

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34	[elf.c:74]: (style) struct or union member 'elf_header_t::shoff' is never used [elf.c:75]: (style) struct or union member 'elf_header_t::flags' is never used [elf.c:76]: (style) struct or union member 'elf_header_t::ehsize' is never used [elf.c:79]: (style) struct or union member 'elf_header_t::shentrysize' is never used [elf.c:80]: (style) struct or union member 'elf_header_t::shnum' is never used [elf.c:81]: (style) struct or union member 'elf_header_t::shstrndx' is never used [elf.c:101]: (style) struct or union member 'program_header_t::paddr' is never used [elf.c:104]: (style) struct or union member 'program_header_t::flags' is never used [elf.c:105]: (style) struct or union member 'program_header_t::align' is never used [fat12.c:676]: (style) The scope of the variable j can be reduced [paging.c:33]: (style) struct or union member '__attribute__::ext' is never used [video.c:177]: (style) The scope of the variable temp can be reduced [../tools/src/CreateFloppyImage.cpp:30]: (style) struct or union member 'BootSector::ignore1' is never used [../tools/src/CreateFloppyImage.cpp:31]: (style) struct or union member 'BootSector::oem_name' is never used [../tools/src/CreateFloppyImage.cpp:38]: (style) struct or union member 'BootSector::media_destriptor_byte' is never used [../tools/src/CreateFloppyImage.cpp:40]: (style) struct or union member 'BootSector::sectors_per_track' is never used [../tools/src/CreateFloppyImage.cpp:41]: (style) struct or union member 'BootSector::head_count' is never used [../tools/src/CreateFloppyImage.cpp:42]: (style) struct or union member 'BootSector::hidden_sectors' is never used [../tools/src/CreateFloppyImage.cpp:43]: (style) struct or union member 'BootSector::sector_count_ex' is never used [../tools/src/CreateFloppyImage.cpp:44]: (style) struct or union member 'BootSector::drive_number' is never used [../tools/src/CreateFloppyImage.cpp:45]: (style) struct or union member 'BootSector::ignore2' is never used [../tools/src/CreateFloppyImage.cpp:46]: (style) struct or union member 'BootSector::boot_signature' is never used [../tools/src/CreateFloppyImage.cpp:47]: (style) struct or union member 'BootSector::volume_serial' is never used [../tools/src/CreateFloppyImage.cpp:48]: (style) struct or union member 'BootSector::fs_name' is never used [../tools/src/CreateFloppyImage.cpp:50]: (style) struct or union member 'BootSector::bootloader' is never used [../tools/src/CreateFloppyImage.cpp:51]: (style) struct or union member 'BootSector::bootloader_sig' is never used [../user/user_program_c/userlib.c:418]: (style) The scope of the variable i can be reduced [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp1 can be reduced [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp2 can be reduced [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp3 can be reduced [../user/user_test_c/userlib.c:418]: (style) The scope of the variable i can be reduced [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp1 can be reduced [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp2 can be reduced [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp3 can be reduced

Die Scope-Warnungen hab ich schonmal gefixt:
fat12.c:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	1 2 3 4 5 6 7 8 9 10 11 12 13	void parse_dir(uint8_t* a, int32_t in, struct dir_entry* rs) { int32_t i = (in %DIR_ENTRIES) * 32; for(int32_t j=0;j<8;j++,i++) { rs->Filename[j] = a[i]; } for(int32_t j=0;j<3;j++,i++) { rs->Extension[j] = a[i]; } //...

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	void parse_dir(uint8_t* a, int32_t in, struct dir_entry* rs) { int32_t i = (in %DIR_ENTRIES) * 32; for(int32_t j=0;j<8;j++,i++) { rs->Filename[j] = a[i]; } for(int32_t j=0;j<3;j++,i++) { rs->Extension[j] = a[i]; } //...

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	void parse_dir(uint8_t* a, int32_t in, struct dir_entry* rs) { int32_t i = (in %DIR_ENTRIES) * 32; for(int32_t j=0;j<8;j++,i++) { rs->Filename[j] = a[i]; } for(int32_t j=0;j<3;j++,i++) { rs->Extension[j] = a[i]; } //...

video.c:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	1 2 3 4 5 6 7 8 9 10 11	void scroll() { uint32_t blank = 0x20 \| (attrib << 8); if(csr_y >= SCROLL_LINE) { uint32_t temp = csr_y - SCROLL_LINE + 1; memcpy (vidmem, vidmem + temp * COLUMNS, (SCROLL_LINE - temp) * COLUMNS * 2); memsetw (vidmem + (SCROLL_LINE - temp) * COLUMNS, blank, COLUMNS); csr_y = SCROLL_LINE - 1; } }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	void scroll() { uint32_t blank = 0x20 \| (attrib << 8); if(csr_y >= SCROLL_LINE) { uint32_t temp = csr_y - SCROLL_LINE + 1; memcpy (vidmem, vidmem + temp * COLUMNS, (SCROLL_LINE - temp) * COLUMNS * 2); memsetw (vidmem + (SCROLL_LINE - temp) * COLUMNS, blank, COLUMNS); csr_y = SCROLL_LINE - 1; } }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	void scroll() { uint32_t blank = 0x20 \| (attrib << 8); if(csr_y >= SCROLL_LINE) { uint32_t temp = csr_y - SCROLL_LINE + 1; memcpy (vidmem, vidmem + temp * COLUMNS, (SCROLL_LINE - temp) * COLUMNS * 2); memsetw (vidmem + (SCROLL_LINE - temp) * COLUMNS, blank, COLUMNS); csr_y = SCROLL_LINE - 1; } }

userlib.c:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26	void showInfo(signed char val) { static char* line1 = " _______ _______ <>_<> " ; static char* line2 = " (_______) \|_\|_\|_\|_\|_\|_\|\| [] [] \| .---\|'\"`\|---. " ; static char* line3 = " `-oo---oo-'`-oo-----oo-'`-o---o-'`o\"O-OO-OO-O\"o' " ; if(val==1) { char temp1 = line1[79]; char temp2 = line2[79]; char temp3 = line3[79]; for(int i=79;i>0;--i) { line1[i] = line1[i-1]; line2[i] = line2[i-1]; line3[i] = line3[i-1]; } line1[0] = temp1; line2[0] = temp2; line3[0] = temp3; printLine(line1,46,0xE); printLine(line2,47,0xE); printLine(line3,48,0xE); } }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26	void showInfo(signed char val) { static char* line1 = " _______ _______ <>_<> " ; static char* line2 = " (_______) \|_\|_\|_\|_\|_\|_\|\| [] [] \| .---\|'\"`\|---. " ; static char* line3 = " `-oo---oo-'`-oo-----oo-'`-o---o-'`o\"O-OO-OO-O\"o' " ; if(val==1) { char temp1 = line1[79]; char temp2 = line2[79]; char temp3 = line3[79]; for(int i=79;i>0;--i) { line1[i] = line1[i-1]; line2[i] = line2[i-1]; line3[i] = line3[i-1]; } line1[0] = temp1; line2[0] = temp2; line3[0] = temp3; printLine(line1,46,0xE); printLine(line2,47,0xE); printLine(line3,48,0xE); } }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26	void showInfo(signed char val) { static char* line1 = " _______ _______ <>_<> " ; static char* line2 = " (_______) \|_\|_\|_\|_\|_\|_\|\| [] [] \| .---\|'\"`\|---. " ; static char* line3 = " `-oo---oo-'`-oo-----oo-'`-o---o-'`o\"O-OO-OO-O\"o' " ; if(val==1) { char temp1 = line1[79]; char temp2 = line2[79]; char temp3 = line3[79]; for(int i=79;i>0;--i) { line1[i] = line1[i-1]; line2[i] = line2[i-1]; line3[i] = line3[i-1]; } line1[0] = temp1; line2[0] = temp2; line3[0] = temp3; printLine(line1,46,0xE); printLine(line2,47,0xE); printLine(line3,48,0xE); } }

Erhard Henkes Mitglied 20:39:22 26.02.2010 Titel:

Danke! Wird demnächst implementiert.

Zitat:

Irrelevantes à la "use fgets instead of gets" entfernt

Ist schon berechtigt, denn momentan kann man locker über den Puffer hinaus schreiben. Damit kann man sich in unser OS "hinein hacken". Das gets sollten wir wirklich implizit in ein "fgets" mit stdin als file verwandeln.

Unregistrierter 20:20:01 28.02.2010 Titel:

Revision 151

Ja, hallo erstmal!

Die "FloppyImage.bin" funktioniert unter/auf "MS Virtual-PC" einigermaßen perfekt. Allerdings gibt es ein Problem in der "ckernel.c" bzw. in der "time.c":

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	1 2 3 4 5 6 7 8 9 10 11 12 13	// ckernel.c Revision 151 if (CurrentSeconds!=CurrentSecondsOld) { itoa(CurrentSeconds, timeBuffer); getCurrentDateAndTime(DateAndTime); // <- arbeitet nicht korrekt strcat(DateAndTime, " "); strcat(DateAndTime, timeBuffer); strcat(DateAndTime, " seconds since start."); // output in status bar printf(DateAndTime, 49, 0xC); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	// ckernel.c Revision 151 if (CurrentSeconds!=CurrentSecondsOld) { itoa(CurrentSeconds, timeBuffer); getCurrentDateAndTime(DateAndTime); // <- arbeitet nicht korrekt strcat(DateAndTime, " "); strcat(DateAndTime, timeBuffer); strcat(DateAndTime, " seconds since start."); // output in status bar printf(DateAndTime, 49, 0xC); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	// ckernel.c Revision 151 if (CurrentSeconds!=CurrentSecondsOld) { itoa(CurrentSeconds, timeBuffer); getCurrentDateAndTime(DateAndTime); // <- arbeitet nicht korrekt strcat(DateAndTime, " "); strcat(DateAndTime, timeBuffer); strcat(DateAndTime, " seconds since start."); // output in status bar printf(DateAndTime, 49, 0xC); }

"getCurrentDateAndTime" arbeitet wie ein "strcat". Darum wird der String pro Aufruf immer länger. Nach spätestens drei Aufrufen blockiert die VM, was heißt, daß "nichts mehr geht".

Leider bin ich zu doof dafür um mir ein PrettyOS selbst zu kompilieren. Deshalb mußte ich die "FloppyImage.bin" reversen.

Badestrand Mitglied 20:29:58 28.02.2010 Titel:

+gjm+ schrieb:

Leider bin ich zu doof dafür um mir ein PrettyOS selbst zu kompilieren. Deshalb mußte ich die "FloppyImage.bin" reversen.

Woran hapert's denn? Wir können da bestimmt helfen

Mr X Mitglied 20:37:42 28.02.2010 Titel:

Das könnte inzwischen auch einfacher geworden sein: Wir haben ein neues makefile. Das hilft, wenn Du es unter Windows versuchst, da msys nicht mehr nötig ist.

Erhard Henkes Mitglied 20:46:03 28.02.2010 Titel:

Zitat:

"getCurrentDateAndTime" arbeitet wie ein "strcat". Darum wird der String pro Aufruf immer länger. Nach spätestens drei Aufrufen blockiert die VM, was heißt, daß "nichts mehr geht".

Danke für den Hinweis. Sehr wichtig, da wir Sun VB für USB EHCI Tests brauchen!

Unregistrierter 21:12:03 28.02.2010 Titel:

"doof" ist bei mir ein Synonym für "faul". Außerdem bin ich als "Windowser" nun mal verwöhnt (und verweichlicht).

Revision 146

Die Revision 146 läuft unter/auf "MS Virtual-PC" auch, sofern man die o.g. if-Abfrage in der ckernel.c "rauswirft":

Code:
1 2 3 4 5 6 7 8	1 2 3 4 5 6 7 8	// FloppyImage.bin Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 000049B0 00 00 89 C3 39 C7 74 62 83 EC 08 8D 45 D4 50 53 Offset 49B6: 74 (JE) ersetzen durch EB (JMP)

Code:
1 2 3 4 5 6 7 8	// FloppyImage.bin Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 000049B0 00 00 89 C3 39 C7 7462 83 EC 08 8D 45 D4 50 53 Offset 49B6: 74 (JE) ersetzen durch EB (JMP)

Code:
1 2 3 4 5 6 7 8	// FloppyImage.bin Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 000049B0 00 00 89 C3 39 C7 74 62 83 EC 08 8D 45 D4 50 53 Offset 49B6: 74 (JE) ersetzen durch EB (JMP)

Allerdings wundert es mich, warum die Revision 146 auf "realen" PCs gelaufen sein soll. Eigentlich hätte es eine Art "Buffer Overflow" geben müssen.

Mr X Mitglied 00:00:01 01.03.2010 Titel:

Das kompilieren unter Windows sollte eig. auch nicht mehr so schwer sein ;-)

Das Problem mit dem Absturz unter VPC und VB hat ehenkes übrigens soeben behoben.

Dafür hab ich folgendes entdeckt:
Wir haben einen Schreibcursor. Dies hab ich erst jetzt gemerkt, da er bei mir nur unter Microsoft Virtual PC funktioniert (Nutze ich selten). Qemu und Virtual Box zeigen ihn schlichtweg nicht an.
Das dürfte ein Fehler sein.

Die zu schnelle Uhr unter Virtual Box besteht auch weiterhin.

Cuervo Mitglied 21:30:28 01.03.2010 Titel:

So, hier alle meine Test-PCs für PrettyOS:

http://prettyos.fanofblitzbasic.de/Computers/

anubis2k5 Mitglied 20:35:15 02.03.2010 Titel:

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	D:\PrettyOS\trunk\Source>tools\mingw32-make OS=WINDOWS nasmw -f bin stage1_bootloader/boot.asm -Istage1_bootloader/ -o stage1_bootloade r/boot.bin nasmw -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage2_bootload er/BOOT2.BIN del .o nasmw -O32 -f elf user/user_program_c/start.asm -Iuser/user_program_c/ -o start. o i586-elf-gcc user/user_tools/userlib.c -c -Iuser/user_tools -m32 -std=c99 -Wshad ow -march=i386 -mtune=i386 -m32 -fno-pic -Werror -Wall -O -ffreestanding -fleadi ng-underscore -nostdlib -nostdinc -fno-builtin -fno-stack-protector -Iinclude process_begin: CreateProcess(NULL, i586-elf-gcc user/user_tools/userlib.c -c -Iu ser/user_tools -m32 -std=c99 -Wshadow -march=i386 -mtune=i386 -m32 -fno-pic -Wer ror -Wall -O -ffreestanding -fleading-underscore -nostdlib -nostdinc -fno-builti n -fno-stack-protector -Iinclude, ...) failed. make (e=2): Das System kann die angegebene Datei nicht finden. mingw32-make: ** [initrd] Error 2

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	D:\PrettyOS\trunk\Source>tools\mingw32-make OS=WINDOWS nasmw -f bin stage1_bootloader/boot.asm -Istage1_bootloader/ -o stage1_bootloade r/boot.bin nasmw -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage2_bootload er/BOOT2.BIN del .o nasmw -O32 -f elf user/user_program_c/start.asm -Iuser/user_program_c/ -o start. o i586-elf-gcc user/user_tools/userlib.c -c -Iuser/user_tools -m32 -std=c99 -Wshad ow -march=i386 -mtune=i386 -m32 -fno-pic -Werror -Wall -O -ffreestanding -fleadi ng-underscore -nostdlib -nostdinc -fno-builtin -fno-stack-protector -Iinclude process_begin: CreateProcess(NULL, i586-elf-gcc user/user_tools/userlib.c -c -Iu ser/user_tools -m32 -std=c99 -Wshadow -march=i386 -mtune=i386 -m32 -fno-pic -Wer ror -Wall -O -ffreestanding -fleading-underscore -nostdlib -nostdinc -fno-builti n -fno-stack-protector -Iinclude, ...) failed. make (e=2): Das System kann die angegebene Datei nicht finden. mingw32-make: ** [initrd] Error 2

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	D:\PrettyOS\trunk\Source>tools\mingw32-make OS=WINDOWS nasmw -f bin stage1_bootloader/boot.asm -Istage1_bootloader/ -o stage1_bootloade r/boot.bin nasmw -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage2_bootload er/BOOT2.BIN del .o nasmw -O32 -f elf user/user_program_c/start.asm -Iuser/user_program_c/ -o start. o i586-elf-gcc user/user_tools/userlib.c -c -Iuser/user_tools -m32 -std=c99 -Wshad ow -march=i386 -mtune=i386 -m32 -fno-pic -Werror -Wall -O -ffreestanding -fleadi ng-underscore -nostdlib -nostdinc -fno-builtin -fno-stack-protector -Iinclude process_begin: CreateProcess(NULL, i586-elf-gcc user/user_tools/userlib.c -c -Iu ser/user_tools -m32 -std=c99 -Wshadow -march=i386 -mtune=i386 -m32 -fno-pic -Wer ror -Wall -O -ffreestanding -fleading-underscore -nostdlib -nostdinc -fno-builti n -fno-stack-protector -Iinclude, ...) failed. make (e=2): Das System kann die angegebene Datei nicht finden. mingw32-make: ** [initrd] Error 2

Kann jemand damit was anfangen???

Cygwin ist aus dem Pfad herausgenommen.

anubis2k5 Mitglied 20:42:55 02.03.2010 Titel:

Nochmal ich: Revision 163 läuft unter VBox mehr oder wenige in einer Endlosschleife. Ständig wiederholt sich der USB-Status. Befehle scheinen aber abgearbeitet zu werden. Unter Qemu hingegen läuft das System normal.

Erhard Henkes Mitglied 21:27:04 02.03.2010 Titel:

Ständig wiederholt sich der USB-Status. <--- wenn dich das stört, hier abschalten:

initEHCIHostController(); // used only for first tests
Zeile 188 pci.c auskommentieren

oder:
in Sun VBox einfach unter Änderungen / USB / USB 2.0 checkbox deaktivieren

Unregistrierter 21:28:18 02.03.2010 Titel:

Revision 162

anubis2k5 schrieb:

Kann jemand damit was anfangen???

Ja, Das Problem hatte ich auch.

"mingw32-make.exe" findet die "i586-elf-gcc.exe" nicht. Versuch mal die "Umgebungsvariablen" korrekt zu setzen, so wie Cuervo es hier im ersten Beitrag beschrieben hat ( -> pdf).

Mr X schrieb:

Die zu schnelle Uhr unter Virtual Box besteht auch weiterhin.

Das liegt an der "systemTimer_setFrequency" aus der "timer.c" Das "command byte" sollte besser auf "Mode 2" gesetzt werden:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	1 2 3 4 5 6 7 8 9 10	// timer.c Revision 162 void systemTimer_setFrequency( uint32_t freq ) { (...) // Send the command byte // outportb(0x43, 0x36); // 0x36 -> Mode 3 : Square Wave Generator outportb(0x43, 0x34); // 0x34 -> Mode 2 : Rate Generator (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	// timer.c Revision 162 void systemTimer_setFrequency( uint32_t freq ) { (...) // Send the command byte // outportb(0x43, 0x36); // 0x36 -> Mode 3 : Square Wave Generator outportb(0x43, 0x34); // 0x34 -> Mode 2 : Rate Generator (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	// timer.c Revision 162 void systemTimer_setFrequency( uint32_t freq ) { (...) // Send the command byte // outportb(0x43, 0x36); // 0x36 -> Mode 3 : Square Wave Generator outportb(0x43, 0x34); // 0x34 -> Mode 2 : Rate Generator (...) }

Mr X schrieb:

Wir haben einen Schreibcursor. Dies hab ich erst jetzt gemerkt, da er bei mir nur unter Microsoft Virtual PC funktioniert (Nutze ich selten).
Qemu und Virtual Box zeigen ihn schlichtweg nicht an. Das dürfte ein Fehler sein.

Der "Schreibcursor" ist ein Feature von "Virtual-PC". Wenn die "update_cursor" aus der "video.c" so hier verändert wird:

C/C++ Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	// video.c Revision 162 void update_cursor() { (...) position = 0; outportb(0x3D4, 0x0E); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9	// video.c Revision 162 void update_cursor() { (...) position = 0; outportb(0x3D4, 0x0E); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9	// video.c Revision 162 void update_cursor() { (...) position = 0; outportb(0x3D4, 0x0E); (...) }

dann erscheint der Schreibcursor immer an Position (0,0) obwohl die Eingaben stets an der korrekten Position sind.

Gamepower Mitglied 20:10:34 03.03.2010 Titel:

Cuervo schrieb:

So, hier alle meine Test-PCs für PrettyOS:

http://prettyos.fanofblitzbasic.de/Computers/

Bei Deiner Sammlung fühle ich mich richtig heimisch

Tobiking2 Mitglied 05:00:37 05.03.2010 Titel:

Zum Fehler gerade warum sich VirtualBox bei mir mit einem Fehler verabschiedet:

Es sieht so aus als wenn nach dem Aktiveren von Paging in den Bereich zwischen 0 und 20 mb geschrieben wird. Dieser Bereich ist zwar gemappt, aber (Außer 0xB8000) nicht zum schreiben freigegeben. Setze ich in paging.c in Zeile 252 noch MEM_WRITE läuft es. Wo das passiert und warum das scheinbar nur bei mir auftritt hab ich noch nicht überprüft.

Unregistrierter 14:56:35 05.03.2010 Titel:

Revision 169 (und folgende)

Wenn die KERNEL.BIN nach dem Kompilieren größer 52.732 Bytes ist, dann bleiben VPC und VB schon beim Booten stecken.

Das Problem ist in der "Fat12.inc" und dort ab Label "LoadFile:".

Kurz gesagt, wenn BX ein "Wrap-Around" macht (was heißt von z.B. 0xFF00 + 0x0200 auf 0x0100 kommt), dann muß das Segmentregister ES entsprechend aktualisiert werden (i.e. ES = ES + 0x0100).

Anderenfalls überschreibt "ReadSectors" via [es:bx] etwas und/oder bleibt einfach im "int 0x13" stecken.

Erhard Henkes Mitglied 19:23:19 05.03.2010 Titel:

Danke für den Hinweis. Ich habe die kernel.bin zunächst auf ca. 50 KB verkleinert (ab Rev. 175), damit wir da nicht anstoßen. Aber da muss uns was einfallen.

Unregistrierter 22:53:20 06.03.2010 Titel:

Revision 175

Zunächst einmal, entschuldigt bitte, daß ich noch bei Revision 175 bin. Aber ich schreibe gerade an einem Userprogramm, welches auf Festplatten zugreifen kann. Dazu mussten einige Dateien geändert werden und ich habe keine Lust, sie bei jeder neuen Revision wieder zu ändern.

_{Eigentlich soll das ja ein Kerneltreiber werden. Aber die großzügigen Debugausgaben und ein kleines Menü zur bequemeren Bedienung beim Testen (typisch Windowser) haben leider den Umfang der KERNEL.BIN gesprengt.}

Nun zum Thema:

Wenn man in der Shell versehentlich eine falsche Eingabe macht, dann werden auch "leere" Einträge angezeigt. Das stört etwas beim Testen. Bislang löse ich das Problem via "Hotfix":

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	// fat12.c Revision 175 uint32_t search_file_first_cluster(const char* name, const char* ext, struct file* f) { (...) for(uint8_t i=0;i<224;i++) { read_dir(&entry, i, 19, false); if ((&entry)->Filename[0] == 0) { break; } // <- wenn der eintrag leer ist, dann kommen auch keine mehr. also raus hier :) (...) } (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	// fat12.c Revision 175 uint32_t search_file_first_cluster(const char* name, const char* ext, struct file* f) { (...) for(uint8_t i=0;i<224;i++) { read_dir(&entry, i, 19, false); if ((&entry)->Filename[0] == 0) { break; } // <- wenn der eintrag leer ist, dann kommen auch keine mehr. also raus hier :) (...) } (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	// fat12.c Revision 175 uint32_t search_file_first_cluster(const char* name, const char* ext, struct file* f) { (...) for(uint8_t i=0;i<224;i++) { read_dir(&entry, i, 19, false); if ((&entry)->Filename[0] == 0) { break; } // <- wenn der eintrag leer ist, dann kommen auch keine mehr. also raus hier :) (...) } (...) }

Eventuell könnte der Hotfix mal verschwinden?

Btw.:
Ihr seid ja beim Thema USB ganz schön am ackern. :live:

Hoffentlich kommt dabei der Spaß nicht zu kurz!

Erhard Henkes Mitglied 00:56:30 07.03.2010 Titel:

Zitat:

wenn der eintrag leer ist, dann kommen auch keine mehr. also raus hier

Danke für den Hotfix, ist jetzt ab Rev. 186 eingebaut.

Erhard Henkes Mitglied 00:58:12 07.03.2010 Titel:

Zitat:

Ihr seid ja beim Thema USB ganz schön am ackern. :live:

Hoffentlich kommt dabei der Spaß nicht zu kurz!

Kein leichtes Thema, aber es macht Spaß im Verbund mit anderen Mitstreitern an diesem anspruchsvollen Thema "arbeiten" zu dürfen.

Erhard Henkes Mitglied 18:21:33 07.03.2010 Titel:

@+gjm+: was genau würdest du ändern im assembler programm fat12.inc?
Hier der von dir angesprochene Bereich, der nun versagt:

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88	;****************************************************************************** ; LoadFile () ; ES:SI File to load ; EBX:BP Buffer to load file to ; AX Return value: success 0, error -1 ;**************************************************************************** LoadFile: xor ecx, ecx** ; size of file in sectors push ecx .FIND_FILE: push bx ; BX=>BP points to buffer to write to; store it for later push bp call FindFile ; find our file. ES:SI contains our filename cmp ax, -1 jne .LOAD_IMAGE_PRE pop bp pop bx pop ecx mov ax, -1 ret .LOAD_IMAGE_PRE: sub edi, ROOT_OFFSET sub eax, ROOT_OFFSET ; get starting cluster push word ROOT_SEG ;root segment loc pop es mov dx, WORD [es:di + 0x001A] ; DI points to file entry in root directory table. Refrence the table... mov WORD [cluster], dx ; file's first cluster pop bx ; get location to write to so we dont screw up the stack pop es push bx ; store location for later again push es call LoadFAT .LOAD_IMAGE: ; load the cluster mov ax, WORD [cluster] ; cluster to read pop es ; bx:bp=es:bx pop bx call Convert_Cluster_to_LBA xor cx, cx mov cl, BYTE [SecPerClus] call ReadSectors pop ecx inc ecx push ecx push bx push es mov ax, FAT_SEG ;start reading from fat mov es, ax xor bx, bx ; get next cluster mov ax, WORD [cluster] ; identify current cluster mov cx, ax ; copy current cluster mov dx, ax ; copy current cluster shr dx, 1 ; divide by two add cx, dx ; sum for (3/2) mov bx, 0 ;location of fat in memory add bx, cx mov dx, WORD [es:bx] test ax, 1 ; test for odd or even cluster jnz .ODD_CLUSTER .EVEN_CLUSTER: and dx, 0000111111111111b ; take low 12 bits jmp .DONE .ODD_CLUSTER: shr dx, 4 ; take high 12 bits .DONE: mov WORD [cluster], dx cmp dx, 0x0ff0 ; test for EOF jb .LOAD_IMAGE .SUCCESS: pop es pop bx pop ecx xor ax, ax ret %endif

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88	;****************************************************************************** ; LoadFile () ; ES:SI File to load ; EBX:BP Buffer to load file to ; AX Return value: success 0, error -1 ;**************************************************************************** LoadFile: xor ecx, ecx** ; size of file in sectors push ecx .FIND_FILE: push bx ; BX=>BP points to buffer to write to; store it for later push bp call FindFile ; find our file. ES:SI contains our filename cmp ax, -1 jne .LOAD_IMAGE_PRE pop bp pop bx pop ecx mov ax, -1 ret .LOAD_IMAGE_PRE: sub edi, ROOT_OFFSET sub eax, ROOT_OFFSET ; get starting cluster push word ROOT_SEG ;root segment loc pop es mov dx, WORD [es:di + 0x001A] ; DI points to file entry in root directory table. Refrence the table... mov WORD [cluster], dx ; file's first cluster pop bx ; get location to write to so we dont screw up the stack pop es push bx ; store location for later again push es call LoadFAT .LOAD_IMAGE: ; load the cluster mov ax, WORD [cluster] ; cluster to read pop es ; bx:bp=es:bx pop bx call Convert_Cluster_to_LBA xor cx, cx mov cl, BYTE [SecPerClus] call ReadSectors pop ecx inc ecx push ecx push bx push es mov ax, FAT_SEG ;start reading from fat mov es, ax xor bx, bx ; get next cluster mov ax, WORD [cluster] ; identify current cluster mov cx, ax ; copy current cluster mov dx, ax ; copy current cluster shr dx, 1 ; divide by two add cx, dx ; sum for (3/2) mov bx, 0 ;location of fat in memory add bx, cx mov dx, WORD [es:bx] test ax, 1 ; test for odd or even cluster jnz .ODD_CLUSTER .EVEN_CLUSTER: and dx, 0000111111111111b ; take low 12 bits jmp .DONE .ODD_CLUSTER: shr dx, 4 ; take high 12 bits .DONE: mov WORD [cluster], dx cmp dx, 0x0ff0 ; test for EOF jb .LOAD_IMAGE .SUCCESS: pop es pop bx pop ecx xor ax, ax ret %endif

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88	;****************************************************************************** ; LoadFile () ; ES:SI File to load ; EBX:BP Buffer to load file to ; AX Return value: success 0, error -1 ;**************************************************************************** LoadFile: xor ecx, ecx** ; size of file in sectors push ecx .FIND_FILE: push bx ; BX=>BP points to buffer to write to; store it for later push bp call FindFile ; find our file. ES:SI contains our filename cmp ax, -1 jne .LOAD_IMAGE_PRE pop bp pop bx pop ecx mov ax, -1 ret .LOAD_IMAGE_PRE: sub edi, ROOT_OFFSET sub eax, ROOT_OFFSET ; get starting cluster push word ROOT_SEG ;root segment loc pop es mov dx, WORD [es:di + 0x001A] ; DI points to file entry in root directory table. Refrence the table... mov WORD [cluster], dx ; file's first cluster pop bx ; get location to write to so we dont screw up the stack pop es push bx ; store location for later again push es call LoadFAT .LOAD_IMAGE: ; load the cluster mov ax, WORD [cluster] ; cluster to read pop es ; bx:bp=es:bx pop bx call Convert_Cluster_to_LBA xor cx, cx mov cl, BYTE [SecPerClus] call ReadSectors pop ecx inc ecx push ecx push bx push es mov ax, FAT_SEG ;start reading from fat mov es, ax xor bx, bx ; get next cluster mov ax, WORD [cluster] ; identify current cluster mov cx, ax ; copy current cluster mov dx, ax ; copy current cluster shr dx, 1 ; divide by two add cx, dx ; sum for (3/2) mov bx, 0 ;location of fat in memory add bx, cx mov dx, WORD [es:bx] test ax, 1 ; test for odd or even cluster jnz .ODD_CLUSTER .EVEN_CLUSTER: and dx, 0000111111111111b ; take low 12 bits jmp .DONE .ODD_CLUSTER: shr dx, 4 ; take high 12 bits .DONE: mov WORD [cluster], dx cmp dx, 0x0ff0 ; test for EOF jb .LOAD_IMAGE .SUCCESS: pop es pop bx pop ecx xor ax, ax ret %endif

Unregistrierter 19:38:14 07.03.2010 Titel:

Kurz gesagt, das Problem tritt genau hier auf:

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	1 2 3 4 5 6 7 8 9 10 11 12 13	.LOAD_IMAGE: ; load the cluster mov ax, WORD [cluster] pop es pop bx ;-------genau hier----- ; falls bx == 0xFE00 dann bleibt ReadSectors hängen ;-------genau hier----- call Convert_Cluster_to_LBA xor cx, cx mov cl, BYTE [SecPerClus] call ReadSectors (...)

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	.LOAD_IMAGE: ; load the cluster mov ax, WORD [cluster] pop es pop bx ;-------genau hier----- ; falls bx == 0xFE00 dann bleibt ReadSectors hängen ;-------genau hier----- call Convert_Cluster_to_LBA xor cx, cx mov cl, BYTE [SecPerClus] call ReadSectors (...)

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	.LOAD_IMAGE: ; load the cluster mov ax, WORD [cluster] pop es pop bx ;-------genau hier----- ; falls bx == 0xFE00 dann bleibt ReadSectors hängen ;-------genau hier----- call Convert_Cluster_to_LBA xor cx, cx mov cl, BYTE [SecPerClus] call ReadSectors (...)

Wenn ReadSectors im "int 0x13" stecken bleibt, dann mag es sein, daß der Puffer [ES:BX] ungültig ist. Aber das kann ja nicht sein. 0xFE00 + 0x0200 (BytesPerSec) wäre dann genau die "Kante", also eigentlich ok. :confused:

Zumindest sitze ich grade dran.

Erhard Henkes Mitglied 20:00:53 07.03.2010 Titel:

aktueller Kernel: 52.560 Bytes

Cuervo Mitglied 20:04:23 07.03.2010 Titel:

aktueller Kernel (mit Mac erstellt): 52.432 Byte

Unregistrierter 10:42:25 08.03.2010 Titel:

Die Sache ist schwieriger als gedacht. Einen Hotfix hätte ich schon, aber den poste ich lieber nicht weil der die Denkweise von angehenden Programmierern bis in alle Ewigkeit versauen würde.

Probiert jetzt mal, falls Zeit und Spaß vorhanden, soviele Userprogramme wie möglich zu schreiben und bindet sie alle gleichzeitig mit ein. Die Userprogramme sollten möglichst "fett" und "verschwenderisch" sein, z.B. ein Menü, welches nur etwas anzeigt und sonst "nichts" macht.

Code:
// makefile: tools/CreateFloppyImage2 PrettyOS FloppyImage.bin (...) $(KERNELDIR)/KERNEL.BIN $(USERTEST)/HELLO.ELF $(USERTEST)/PROG01.ELF $(USERTEST)/PROG02.ELF (usw.)

Code:
// makefile: tools/CreateFloppyImage2 PrettyOS FloppyImage.bin (...) $(KERNELDIR)/KERNEL.BIN $(USERTEST)/HELLO.ELF $(USERTEST)/PROG01.ELF $(USERTEST)/PROG02.ELF (usw.)

Code:
// makefile: tools/CreateFloppyImage2 PrettyOS FloppyImage.bin (...) $(KERNELDIR)/KERNEL.BIN $(USERTEST)/HELLO.ELF $(USERTEST)/PROG01.ELF $(USERTEST)/PROG02.ELF (usw.)

Möglicherweise gibt es noch ein "Folgeproblem" in der fat12.c.

Mr X Mitglied 11:06:57 08.03.2010 Titel:

ich hab jetzt mal 5 Progs eingebunden, je 4-7 Kb... Alles funktioniert noch.
Worin sollte denn das Folgeproblem bestehen?

EDIT: Einen Schönheitsfehler hab ich gefunden: Bei fdir verrutscht bei Dateinamen kleiner 3 Zeichen die Ausgabe...

FlashBurn Mitglied 17:55:53 08.03.2010 Titel:

Falls ihr das Problem noch nicht gelöst habt, es macht mehr Sinn bei einem Pointer ES:BX, BX immer "0" zu lassen und 0x20 (512bytes bei einem Segment-Register um 8 bits nach rechts geshiftet) auf es zu addieren, so umgeht ihr das 64kb Problem.

Nur mal so als Denkanstoß!

Erhard Henkes Mitglied 18:57:29 08.03.2010 Titel:

Programme in die kernel.bin einbinden läuft über initrd.exe und incbin ..., nicht via FloppyImage ( ist wie kopieren der elf-Files nach Laufwerk A: ).

Unregistrierter 19:10:02 08.03.2010 Titel:

Das Hauptproblem beim Laden der KERNEL.BIN lag lustigerweise in der "boot2.asm". Dort wird der Stack bei Label "entry_point:" wieder auf 0000:FFFF gesetzt. Dadurch gerät er in Konflikt mit allem, was ab 0000:0500 bereits geladen wurde (und noch wird).

In der "Fat12.inc" gibt es einen "Denkfehler". BP ist kein Segmentregister. [BP:BX] geht nicht, aber [BP+BX] geht.

Hier die sehr grob "gefixten" Versionen der boot2.asm und der Fat12.inc, damit der Spaß beim Programmieren weitergehen kann.

Änderungen sind mit "==HOTFIX==" gekennzeichnet. Zumindest sollte damit jetzt eine KERNEL.BIN > 57 KB problemlos geladen werden.

Erhard Henkes Mitglied 20:00:19 08.03.2010 Titel:

Danke! Du hast uns vor raschem GRUB bewahrt.

Unregistrierter 21:10:51 08.03.2010 Titel:

Wie gesagt, ist nur sehr grob gefixt. Ab ca. 118 KB ist der Spaß wieder vorbei. Offenbar kommt sich da noch mehr ins Gehege. Ist zu erwarten, daß in nächster Zeit die KERNEL.BIN 118 KB erreicht? Eigentlich wollte ich an meinem Userprogramm weiterbasteln.

Mr X Mitglied 21:37:24 08.03.2010 Titel:

Eig. ist das nicht zu erwarten... Zumindest nicht in den nächsten paar Wochen. (Wenn Du Zeit&Lust hättest wär es natürlich schon schön, wenn Du auch die 118KB-Grenze beheben könntest, aber das ist nicht so eilig

).

Mach ruhig erstmal an Deinem Userprog weiter. wir haben ja grad mal 52 KB erreicht.

Erhard Henkes Mitglied 23:07:27 08.03.2010 Titel:

Erstmal dickes Dankeschön!

Unregistrierter 23:12:30 08.03.2010 Titel:

Via Hotfix sind ca. 250 KB möglich. Unangenehmerweise enthält der Bootloader fest vergebene Adressen, die sich langsam ins Gehege kommen. Aber darum kann man sich auch später noch kümmern.

Hier mal ein Screenshot von meinem Userprogramm. PrettyOS lernt grade, was eine "Festplatte" ist.

Btw. der 08. März 2010 ist bei mir ein Montag.

FlashBurn Mitglied 23:40:18 08.03.2010 Titel:

Ohne mir den Source-Code jetzt angeguckt zu haben, werfe ich einfach mal UnrealMode ein (kann sein das ihr das schon nutzt).

Wie ladet ihr denn den Kernel, wird er erst komplett geladen und dann an eine andere Position verschoben/kopiert, wenn ja, dann kann man das immer gleich machen braucht so nur nen Buffer der so groß ist wie ein Cluster und kann (UnrealMode vorausgesetzt) Dateien beliebiger Größe laden.

Mr X Mitglied 23:45:17 08.03.2010 Titel:

+gjm+: Dein Treiber sieht Klasse aus!

Unregistrierter 23:30:59 10.03.2010 Titel:

Vielen Dank!

Nun gibt es aber ein Problem in der "time.c" mit dem Wochentag. Der Grund dafür ist, einfach gesagt, daß es zwei verschiedene "Arten" vom CMOS gibt:

1. Register 0x06 zählt von 1 bis 7,
2. Register 0x06 zählt von 0 bis 6.

Per Software kann man nicht herausfinden, ob Register 0x06 von 1 bis 7 oder von 0 bis 6 zählt. Deshalb wäre es besser wenn der Wochentag anhand des Datums ausgerechnet wird. Dazu muß man nur von einem bekannten Datum bis heute die Anzahl vergangener Tage ausrechnen und dann einfach modulo 7.

Der 01.01.1900 ist immer eine gute Idee. Der ist zufälligerweise ein Montag.

Erhard Henkes Mitglied 23:36:05 10.03.2010 Titel:

Zitat:

1. Register 0x06 zählt von 1 bis 7,
2. Register 0x06 zählt von 0 bis 6.

Wirklich bekloppt so was.

Mr X Mitglied 23:36:57 10.03.2010 Titel:

Theoretisch wär ja wohl sogar noch mehr Mist denkbar... Rückwärts zählen z.B.

Unregistrierter 11:12:09 12.03.2010 Titel:

Revision 210

Bochs kommt mit folgendem "Fliesskomma-Ausdruck" nicht zurecht und rechnet "falsch":

C/C++ Code:
1 2 3 4 5 6 7 8	1 2 3 4 5 6 7 8	// time.c Revision 210 unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) { day += 6; //1.1.2000 was Saturday day += (year-2000)365.25; // <- hier* (...) }

C/C++ Code:
1 2 3 4 5 6 7 8	// time.c Revision 210 unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) { day += 6; //1.1.2000 was Saturday day += (year-2000)365.25; // <- hier* (...) }

C/C++ Code:
1 2 3 4 5 6 7 8	// time.c Revision 210 unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) { day += 6; //1.1.2000 was Saturday day += (year-2000)365.25; // <- hier* (...) }

VB und VPC schlucken ihn aber und rechnen korrekt. Vielleicht könnte die Routine so umgeschrieben werden, daß man auf eine "365.25" verzichten kann?

Mr X Mitglied 12:03:28 12.03.2010 Titel:

Ohja, stimmt, da gabs ja ein Problem mit Bochs+Fließkommazahlen...
Ich werde ein Workaround erzeugen, kommt bald!

EDIT: Ich hab mir mal Bochs runtergeladen und PrettyOS damit gestartet: Ich konnte keinen Fehler feststellen... :confused:

Bochs-Version: 2.4.2
PrettyOS: Rev. 210

Unregistrierter 12:44:40 12.03.2010 Titel:

Tatsächlich! Lag an der Version von Bochs:

C/C++ Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) { day += 6; //1.1.2000 was Saturday day += (year-2000)365.25; printformat("\n day : %X",day); // <- debug :)* (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9	unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) { day += 6; //1.1.2000 was Saturday day += (year-2000)365.25; printformat("\n day : %X",day); // <- debug :)* (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9	unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) { day += 6; //1.1.2000 was Saturday day += (year-2000)365.25; printformat("\n day : %X",day); // <- debug :)* (...) }

Nun geben Bochs (2-4-2), VB und VPC die gleiche Zahl aus. Hatte noch eine alte Version von Bochs. Also keine Revision notwendig. :live:

Unregistrierter 20:35:20 15.03.2010 Titel:

Revision 239

Bin grade über folgenden Workaround gestolpert:

C/C++ Code:
1 2 3 4 5 6 7 8	1 2 3 4 5 6 7 8	// ehci.c Revision 239 void initEHCIHostController(uint32_t number) { initEHCIFlag = false; irq_install_handler(32 + pciDev_Array[number].irq, ehci_handler); irq_install_handler(32 + pciDev_Array[number].irq-1, ehci_handler); /// work-around for VirtualBox Bug! (...) }

C/C++ Code:
1 2 3 4 5 6 7 8	// ehci.c Revision 239 void initEHCIHostController(uint32_t number) { initEHCIFlag = false; irq_install_handler(32 + pciDev_Array[number].irq, ehci_handler); irq_install_handler(32 + pciDev_Array[number].irq-1, ehci_handler); /// work-around for VirtualBox Bug! (...) }

C/C++ Code:
1 2 3 4 5 6 7 8	// ehci.c Revision 239 void initEHCIHostController(uint32_t number) { initEHCIFlag = false; irq_install_handler(32 + pciDev_Array[number].irq, ehci_handler); irq_install_handler(32 + pciDev_Array[number].irq-1, ehci_handler); /// work-around for VirtualBox Bug! (...) }

Offenbar scheint die Sun VirtualBox "gewisse" Problemchen mit dem USB-Support unter "gewissen" Host-Betriebssystemen zu haben.

Wenn man folgendes macht:

1. VM starten,
2. im Menü der VM (Geräte->USB-Geräte) ein "USB-Gerät" auswählen (möglichst das richtige

),
3. die VM "neu starten" (Maschine->Zurücksetzen)

dann ist ein Workaround nicht notwendig.

Erhard Henkes Mitglied 20:42:09 15.03.2010 Titel:

Danke für den Hinweis!

Erhard Henkes Mitglied 00:24:09 17.03.2010 Titel:

Zwei Sachen, die immer wieder erfolgen, wenn man neu aufbaut:

1) del wird nicht gefunden, weil msys oder wie jetzt bei mir auf einem alternativen PC Win-AVR mit den entsprechden Pfaden auf der Platte hängen. Da muss man die entsprechenden Pfade eliminieren. Wir verwenden daher auch kein msys mehr.

2) Das makfile bleibt hier bei [initrd] hängen:

Code:
1 2 3 4 5 6 7 8 9 10 11	1 2 3 4 5 6 7 8 9 10 11	E:\PrettyOS\trunk\Source>del FloppyImage.bin E:\PrettyOS\trunk\Source\FloppyImage.bin konnte nicht gefunden werden E:\PrettyOS\trunk\Source>tools\mingw32-make OS=WINDOWS nasm -f bin stage1_bootloader/boot.asm -Istage1_bootloader/ -o stage1_bootloader /boot.bin nasm -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage2_bootloade r/BOOT2.BIN del .o E:\PrettyOS\trunk\Source\.o konnte nicht gefunden werden mingw32-make: *** [initrd] Error 1

Code:
1 2 3 4 5 6 7 8 9 10 11	E:\PrettyOS\trunk\Source>del FloppyImage.bin E:\PrettyOS\trunk\Source\FloppyImage.bin konnte nicht gefunden werden E:\PrettyOS\trunk\Source>tools\mingw32-make OS=WINDOWS nasm -f bin stage1_bootloader/boot.asm -Istage1_bootloader/ -o stage1_bootloader /boot.bin nasm -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage2_bootloade r/BOOT2.BIN del .o E:\PrettyOS\trunk\Source\.o konnte nicht gefunden werden mingw32-make: *** [initrd] Error 1

Code:
1 2 3 4 5 6 7 8 9 10 11	E:\PrettyOS\trunk\Source>del FloppyImage.bin E:\PrettyOS\trunk\Source\FloppyImage.bin konnte nicht gefunden werden E:\PrettyOS\trunk\Source>tools\mingw32-make OS=WINDOWS nasm -f bin stage1_bootloader/boot.asm -Istage1_bootloader/ -o stage1_bootloader /boot.bin nasm -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage2_bootloade r/BOOT2.BIN del .o E:\PrettyOS\trunk\Source\.o konnte nicht gefunden werden mingw32-make: *** [initrd] Error 1

Dieser Fehler ist hässlich, weil man die Lösung nicht leicht findet, zumindest geht es mir immer so.
Es liegt an den beiden "delete *.o", die in den targets ckernel und initrd nichts finden, make-fehler produzieren und deshalb blockieren. Diese beiden kommen nun einfach weg! Könnte dann nur einen Linker Error geben.

Diese beiden Punkte sind die typischen Probleme, denen man beim Einstieg in den Build-Prozess seitens Windows evtl. begegnen kann.

Vorschlag mastamind im IRC: mit den wildcards nur die source dateien auflisten (nicht zwei mal)

anubis2k5 Mitglied 20:29:47 17.03.2010 Titel:

Ich kann mich an alte DOS Zeiten nur schwer erinnern, aber bestand nicht die Möglichkeit mittels Errorleveln die Rückgabewerte eben von "Del" abzufangen und darauf zu reagieren? Helft mir wenn ich falsch liege...

Nachtrag: Del liefert den Errorlevel 1 zurück, wenns nicht erfolgreich war. Alternativ kann man mittels "exist" vielleicht probieren, ob die entsprechende Datei existiert - mit etwas aufwand ist damit vielleicht auch eine Prüfung von mehreren Datein möglich.

Erhard Henkes Mitglied 21:33:30 17.03.2010 Titel:

Zitat:

Del liefert den Errorlevel 1 zurück

Ja, genau so wurde make ausgestoppt. Daher habe ich die beiden del *.o ab Rev. 245 erstmal gestrichen, damit sie auf diese Weise niemand beim Einstieg behindern.

Danke für deinen Hinweis. Vielleicht schafft das jemand.

Unregistrierter 13:19:58 19.03.2010 Titel:

Revision 252

VMWARE, VPC, VB und mein "realer" PC zeigen in der Statuszeile ca. 2400 MHz an. (In etwa auch korrekt). BOCHS allerdings nur 49 MHz

. Liegt aber daran, daß BOCHS bei rdtsc einen "eigenen" Zähler zurückgibt.

Worauf soll eigentlich beim USB-Treiber geachtet werden? Zumindest auf dem "realen" PC reagiert er auf ein "PSTS_CONNECTED_CHANGE" und zeigt dabei äußerst wortreich viele bunte Zahlen an.

Unregistrierter 19:33:44 20.03.2010 Titel:

Revision 256

C/C++ Code:
// pci.h revision 256 #define PCIARRAYSIZE 1024

C/C++ Code:
// pci.h revision 256 #define PCIARRAYSIZE 1024

C/C++ Code:
// pci.h revision 256 #define PCIARRAYSIZE 1024

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	1 2 3 4 5 6 7 8 9 10 11 12 13	// pci.c revision 256 (...) pciDev_t pciDev_Array[50]; // <- nur 50 elemente ! (...) void pciScan() { // array of devices, PCIARRAYSIZE for first tests for(uint32_t i=0;i<PCIARRAYSIZE;++i) { pciDev_Array[i].number = i; } (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	// pci.c revision 256 (...) pciDev_t pciDev_Array[50]; // <- nur 50 elemente ! (...) void pciScan() { // array of devices, PCIARRAYSIZE for first tests for(uint32_t i=0;i<PCIARRAYSIZE;++i) { pciDev_Array[i].number = i; } (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	// pci.c revision 256 (...) pciDev_t pciDev_Array[50]; // <- nur 50 elemente ! (...) void pciScan() { // array of devices, PCIARRAYSIZE for first tests for(uint32_t i=0;i<PCIARRAYSIZE;++i) { pciDev_Array[i].number = i; } (...) }

Diese for-Schleifen (auch in der ckernel.c) gehen ziemlich heftig über die "Arraygrenze" hinaus.

Dadurch zeigt z.B. VMWARE im "_DIAGNOSIS_"-Mode in der ckernel.c mehr Geräte an als "tatsächlich" vorhanden sind.

Allerdings könnte das nur durch einen unglaublichen Zufall ein Grund für einen (bei mir bislang nicht) vorhandenen "Host System Error" sein.

abc.w Mitglied 20:05:12 20.03.2010 Titel:

+gjm+ schrieb:

... Diese for-Schleifen (auch in der ckernel.c) gehen ziemlich heftig über die "Arraygrenze" hinaus.

Mit C++ hätte sowas nicht passieren können...

Erhard Henkes Mitglied 20:55:21 20.03.2010 Titel:

@+gjm+: Danke für den Hinweis! Dies war aber leider nicht die Fehlerursache.

Wir schaffen es einfach nicht, bei extended capabilities im EHCI dem BIOS die Herrschaft zu entreißen! :rolleyes:

Siehe Rev. 258, da habe ich endlich mal richtig gecheckt, ob das überhaupt klappt. Vorher hatten wir da eine Fehlauswertung im Sinne von if(failed){print: alles ok}. Bei mir ergibt sich BIOS: 1 und OS: 0. Es macht auch keinen Sinn beides auf 1 zu zwingen, sonst hat man einen Gladiatorenkampf.

XanClic sieht momentan keinen logischen Fehler im Code. Vielleicht ist mit einer Funktion (pci read/write) was falsch, oder wir kapieren etwas noch nicht.

Wer mithelfen will: EHCI 1.0 spec, Kap. 5

Problem ist hier (EDIT: gelöst, war bei PCI):

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112	void DeactivateLegacySupport(uint32_t num) { delay(2000000);settextcolor(9,0); printformat("\n>>> >>> function: DeactivateLegacySupport\n"); settextcolor(15,0); bool failed = false; // pci bus data uint8_t bus = pciDev_Array[num].bus; uint8_t dev = pciDev_Array[num].device; uint8_t func = pciDev_Array[num].func; eecp = BYTE2(pCapRegs->HCCPARAMS); printformat("\nDeactivateLegacySupport: eecp = %x\n",eecp); /* cf. EHCI 1.0 spec, 2.2.4 HCCPARAMS - Capability Parameters, Bit 15:8 (BYTE2) EHCI Extended Capabilities Pointer (EECP). Default = Implementation Dependent. This optional field indicates the existence of a capabilities list. A value of 00h indicates no extended capabilities are implemented. A non-zero value in this register indicates the offset in PCI configuration space of the first EHCI extended capability. The pointer value must be 40h or greater if implemented to maintain the consistency of the PCI header defined for this class of device. / // cf. http://wiki.osdev.org/PCI#PCI_Device_Structure // eecp // RO - This field identifies the extended capability. // 01h identifies the capability as Legacy Support. uint32_t NextEHCIExtCapPtr = eecp + 1; // RO - 00h indicates end of the ext. cap. list.* uint32_t BIOSownedSemaphore = eecp + 2; // R/W - only Bit 16 (Bit 23:17 Reserved, must be set to zero) uint32_t OSownedSemaphore = eecp + 3; // R/W - only Bit 24 (Bit 31:25 Reserved, must be set to zero) uint32_t USBLEGCTLSTS = eecp + 4; // USB Legacy Support Control/Status (DWORD, cf. EHCI 1.0 spec, 2.1.8) if (eecp >= 0x40) { int32_t eecp_id=0; while(eecp) { printformat("eecp = %x, ",eecp); eecp_id = pci_config_read( bus, dev, func, 0x0100/length 1 byte/ \| (eecp + 0) ); printformat("eecp_id = %x\n",eecp_id); if(eecp_id == 1) break; eecp = pci_config_read( bus, dev, func, 0x0100 \| NextEHCIExtCapPtr ); if(eecp == 0xFF) break; } // Legacy-Support-EC found? BIOS-Semaphore set? if( (eecp_id == 1) && ( pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ) & 0x01) ) { printformat("set OS-Semaphore.\n"); pci_config_write_byte( bus, dev, func, OSownedSemaphore, 0x01 ); failed = true; int32_t timeout=200; // Wait for BIOS-Semaphore being not set while( ( pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ) & 0x01 ) && ( timeout>0 ) ) { printformat("."); timeout--; delay(20000); } if( !( pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ) & 0x01) ) // not set { printformat("BIOS-Semaphore being not set.\n"); timeout=200; while( !( pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) & 0x01) && (timeout>0) ) { printformat("."); timeout--; delay(20000); } } if( pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) & 0x01 ) { failed = false; printformat("OS-Semaphore being set.\n"); } if(failed==false) { /* USB SMI Enable R/W. 0=Default. When this bit is a one, and the SMI on USB Complete bit (above) in this register is a one, the host controller will issue an SMI immediately. / pci_config_write_dword( bus, dev, func, USBLEGCTLSTS, 0x0 ); // USB SMI disabled* printformat("BIOSownedSemaphore: %d OSownedSemaphore: %d\n", pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ), pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) ); settextcolor(2,0); printformat("Legacy Support Deactivated.\n"); settextcolor(15,0); } else { settextcolor(4,0); printformat("Legacy Support Deactivated failed.\n"); printformat("BIOSownedSemaphore: %d OSownedSemaphore: %d\n", pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ), pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) ); settextcolor(15,0); } } } else { printformat("No valid eecp found.\n"); } }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112	void DeactivateLegacySupport(uint32_t num) { delay(2000000);settextcolor(9,0); printformat("\n>>> >>> function: DeactivateLegacySupport\n"); settextcolor(15,0); bool failed = false; // pci bus data uint8_t bus = pciDev_Array[num].bus; uint8_t dev = pciDev_Array[num].device; uint8_t func = pciDev_Array[num].func; eecp = BYTE2(pCapRegs->HCCPARAMS); printformat("\nDeactivateLegacySupport: eecp = %x\n",eecp); /* cf. EHCI 1.0 spec, 2.2.4 HCCPARAMS - Capability Parameters, Bit 15:8 (BYTE2) EHCI Extended Capabilities Pointer (EECP). Default = Implementation Dependent. This optional field indicates the existence of a capabilities list. A value of 00h indicates no extended capabilities are implemented. A non-zero value in this register indicates the offset in PCI configuration space of the first EHCI extended capability. The pointer value must be 40h or greater if implemented to maintain the consistency of the PCI header defined for this class of device. / // cf. http://wiki.osdev.org/PCI#PCI_Device_Structure // eecp // RO - This field identifies the extended capability. // 01h identifies the capability as Legacy Support. uint32_t NextEHCIExtCapPtr = eecp + 1; // RO - 00h indicates end of the ext. cap. list.* uint32_t BIOSownedSemaphore = eecp + 2; // R/W - only Bit 16 (Bit 23:17 Reserved, must be set to zero) uint32_t OSownedSemaphore = eecp + 3; // R/W - only Bit 24 (Bit 31:25 Reserved, must be set to zero) uint32_t USBLEGCTLSTS = eecp + 4; // USB Legacy Support Control/Status (DWORD, cf. EHCI 1.0 spec, 2.1.8) if (eecp >= 0x40) { int32_t eecp_id=0; while(eecp) { printformat("eecp = %x, ",eecp); eecp_id = pci_config_read( bus, dev, func, 0x0100/length 1 byte/ \| (eecp + 0) ); printformat("eecp_id = %x\n",eecp_id); if(eecp_id == 1) break; eecp = pci_config_read( bus, dev, func, 0x0100 \| NextEHCIExtCapPtr ); if(eecp == 0xFF) break; } // Legacy-Support-EC found? BIOS-Semaphore set? if( (eecp_id == 1) && ( pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ) & 0x01) ) { printformat("set OS-Semaphore.\n"); pci_config_write_byte( bus, dev, func, OSownedSemaphore, 0x01 ); failed = true; int32_t timeout=200; // Wait for BIOS-Semaphore being not set while( ( pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ) & 0x01 ) && ( timeout>0 ) ) { printformat("."); timeout--; delay(20000); } if( !( pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ) & 0x01) ) // not set { printformat("BIOS-Semaphore being not set.\n"); timeout=200; while( !( pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) & 0x01) && (timeout>0) ) { printformat("."); timeout--; delay(20000); } } if( pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) & 0x01 ) { failed = false; printformat("OS-Semaphore being set.\n"); } if(failed==false) { /* USB SMI Enable R/W. 0=Default. When this bit is a one, and the SMI on USB Complete bit (above) in this register is a one, the host controller will issue an SMI immediately. / pci_config_write_dword( bus, dev, func, USBLEGCTLSTS, 0x0 ); // USB SMI disabled* printformat("BIOSownedSemaphore: %d OSownedSemaphore: %d\n", pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ), pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) ); settextcolor(2,0); printformat("Legacy Support Deactivated.\n"); settextcolor(15,0); } else { settextcolor(4,0); printformat("Legacy Support Deactivated failed.\n"); printformat("BIOSownedSemaphore: %d OSownedSemaphore: %d\n", pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ), pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) ); settextcolor(15,0); } } } else { printformat("No valid eecp found.\n"); } }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112	void DeactivateLegacySupport(uint32_t num) { delay(2000000);settextcolor(9,0); printformat("\n>>> >>> function: DeactivateLegacySupport\n"); settextcolor(15,0); bool failed = false; // pci bus data uint8_t bus = pciDev_Array[num].bus; uint8_t dev = pciDev_Array[num].device; uint8_t func = pciDev_Array[num].func; eecp = BYTE2(pCapRegs->HCCPARAMS); printformat("\nDeactivateLegacySupport: eecp = %x\n",eecp); /* cf. EHCI 1.0 spec, 2.2.4 HCCPARAMS - Capability Parameters, Bit 15:8 (BYTE2) EHCI Extended Capabilities Pointer (EECP). Default = Implementation Dependent. This optional field indicates the existence of a capabilities list. A value of 00h indicates no extended capabilities are implemented. A non-zero value in this register indicates the offset in PCI configuration space of the first EHCI extended capability. The pointer value must be 40h or greater if implemented to maintain the consistency of the PCI header defined for this class of device. / // cf. http://wiki.osdev.org/PCI#PCI_Device_Structure // eecp // RO - This field identifies the extended capability. // 01h identifies the capability as Legacy Support. uint32_t NextEHCIExtCapPtr = eecp + 1; // RO - 00h indicates end of the ext. cap. list.* uint32_t BIOSownedSemaphore = eecp + 2; // R/W - only Bit 16 (Bit 23:17 Reserved, must be set to zero) uint32_t OSownedSemaphore = eecp + 3; // R/W - only Bit 24 (Bit 31:25 Reserved, must be set to zero) uint32_t USBLEGCTLSTS = eecp + 4; // USB Legacy Support Control/Status (DWORD, cf. EHCI 1.0 spec, 2.1.8) if (eecp >= 0x40) { int32_t eecp_id=0; while(eecp) { printformat("eecp = %x, ",eecp); eecp_id = pci_config_read( bus, dev, func, 0x0100/length 1 byte/ \| (eecp + 0) ); printformat("eecp_id = %x\n",eecp_id); if(eecp_id == 1) break; eecp = pci_config_read( bus, dev, func, 0x0100 \| NextEHCIExtCapPtr ); if(eecp == 0xFF) break; } // Legacy-Support-EC found? BIOS-Semaphore set? if( (eecp_id == 1) && ( pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ) & 0x01) ) { printformat("set OS-Semaphore.\n"); pci_config_write_byte( bus, dev, func, OSownedSemaphore, 0x01 ); failed = true; int32_t timeout=200; // Wait for BIOS-Semaphore being not set while( ( pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ) & 0x01 ) && ( timeout>0 ) ) { printformat("."); timeout--; delay(20000); } if( !( pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ) & 0x01) ) // not set { printformat("BIOS-Semaphore being not set.\n"); timeout=200; while( !( pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) & 0x01) && (timeout>0) ) { printformat("."); timeout--; delay(20000); } } if( pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) & 0x01 ) { failed = false; printformat("OS-Semaphore being set.\n"); } if(failed==false) { /* USB SMI Enable R/W. 0=Default. When this bit is a one, and the SMI on USB Complete bit (above) in this register is a one, the host controller will issue an SMI immediately. / pci_config_write_dword( bus, dev, func, USBLEGCTLSTS, 0x0 ); // USB SMI disabled* printformat("BIOSownedSemaphore: %d OSownedSemaphore: %d\n", pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ), pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) ); settextcolor(2,0); printformat("Legacy Support Deactivated.\n"); settextcolor(15,0); } else { settextcolor(4,0); printformat("Legacy Support Deactivated failed.\n"); printformat("BIOSownedSemaphore: %d OSownedSemaphore: %d\n", pci_config_read( bus, dev, func, 0x0100 \| BIOSownedSemaphore ), pci_config_read( bus, dev, func, 0x0100 \| OSownedSemaphore ) ); settextcolor(15,0); } } } else { printformat("No valid eecp found.\n"); } }

Bei manchen PC gibt es dennoch Host System Error beim Einschalten der Async.List

Erhard Henkes Mitglied 21:43:06 20.03.2010 Titel:

Fehler war in der pci_write_byte-Fkt.

Tobiking2 Mitglied 03:21:49 21.03.2010 Titel:

Also bei mir wird richtig BIOS owned 0 und OS owned 1 angezeigt, der Host System Error bleibt allerdings.

Unregistrierter 12:34:23 23.03.2010 Titel:

Revision 271

Solange KERNEL und USER den gleichen "Videobereich" (0xB8000) für Ausgaben nutzen, sollte KERNEL nach erfolgreicher Ausführung von "elf_exec" auf eigene Ausgaben verzichten. Sonst gerät die Ausgabe vom USER u.U. völlig durcheinander:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14	1 2 3 4 5 6 7 8 9 10 11 12 13 14	// file.c revision 271 int32_t flpydsk_load(const char* name, const char* ext) { (...) if( elf_exec( file, f.size ) ) // <- falls erfolgreich ... { } (...) // printf("\n\n"); // <- ... sollte auf ausgaben ab hier verzichtet werden flpydsk_control_motor(false); // <- hier drin dann auch sleepSeconds(3); return 0; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14	// file.c revision 271 int32_t flpydsk_load(const char* name, const char* ext) { (...) if( elf_exec( file, f.size ) ) // <- falls erfolgreich ... { } (...) // printf("\n\n"); // <- ... sollte auf ausgaben ab hier verzichtet werden flpydsk_control_motor(false); // <- hier drin dann auch sleepSeconds(3); return 0; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14	// file.c revision 271 int32_t flpydsk_load(const char* name, const char* ext) { (...) if( elf_exec( file, f.size ) ) // <- falls erfolgreich ... { } (...) // printf("\n\n"); // <- ... sollte auf ausgaben ab hier verzichtet werden flpydsk_control_motor(false); // <- hier drin dann auch sleepSeconds(3); return 0; }

(Betrifft aber nicht die Statuszeilen).

Die Wirksamkeit des VirtualBox-Workaround kann ich nicht bestätigen. Bei mir hat VB ein Problem mit dem Host. Manchmal kann VB der gestarteten VM USB zur Verfügung stellen, manchmal aber auch nicht. Das hängt wahrscheinlich vom Wetter ab. Aber es liegt garantiert nicht am IRQ in der VM von VB. (Wäre ja erschreckend, wenn es so wäre).

Erhard Henkes Mitglied 23:17:29 23.03.2010 Titel:

Danke für den Hinweis, wurde umgesetzt.

VBox und Qemu (Version mit EHCI) laufen momentan am besten. Bei Bochs und VPC fehlen EHCI, und bei VMWare kommt leider nur 00h zurück im IN qTD anstelle 12h etc. Bei realer Hardware klappt es entweder gut oder erst nach einigen Anläufen. Bei Tobikings Laptop macht das BIOS Anstalten und gibt den Staffelstab nicht an den EHCI-Treiber ab, obwohl wir alles brav nach Lehrbuch (Intel PRM) durchführen.

Erhard Henkes Mitglied 23:18:44 23.03.2010 Titel:

Zitat:

Solange KERNEL und USER den gleichen "Videobereich" (0xB8000) für Ausgaben nutzen

Denkst Du man sollte hier einen umschaltbaren Bildschirm schaffen für verschiedene Tasks?

Mr X Mitglied 23:30:04 23.03.2010 Titel:

Du hast mich zwar nicht direkt gefragt, sag aber, wo Du es ansprichst, auch mal was dazu, ehenkes

Ich denke, wir brauchen langfristig mehrere Konsolen.
Daher schlage ich vor: Eine Log-Konsole, wo alle Ausgabe außer der Statusleiste hinkommt.
Plus n User-Konsolen, wo man Programme ausführen kann.

Vlt. kann die Log-Konsole auch eine Steuerungskonsole sein, von der aus zusätzlich zur Log-Funktion Befehle ausgeführt werden, wobei Programme dabei in andere Konsolen umgeleitet werden, in die man dann umschalten kann.

Unregistrierter 13:25:57 25.03.2010 Titel:

Hoffentlich habe ich etwas im Quelltext von PrettyOS übersehen (oder nur nicht verstanden). Dann diesen Beitrag einfach ignorieren.

Revision 277

KERNEL und USER nutzen für die Ausgabe putch() in der video.c. KERNEL "direkt" und USER via syscall.

:warning:

Innerhalb von putch() ist es aber nicht möglich herauszufinden, wer putch() aufgerufen hat. :warning:

Somit kann man auch nicht festlegen, ob putch() direkt in den Videospeicher schreiben soll oder vorerst in einen Puffer (Array).

Sollte das korrekt sein, dann sind umschaltbare Bildschirme (und somit mehrere Konsolen) z.Zt. nicht realisierbar.

Mr X Mitglied 16:26:29 25.03.2010 Titel:

Ich wär dafür, das auch der Kernel nicht unkontrolliert seine Nachrichten absetzt, sondern das Kernel-Output in einer separaten Konsole abläuft.

Ich werde mal an etwas entsprechendem arbeiten und das dann vorzeigen.

Unregistrierter 20:05:00 26.03.2010 Titel:

Revision 281

Code:
1 2 3 4 5 6 7 8	1 2 3 4 5 6 7 8	// FloppyImage.bin (Rootdir nach dem Schreiben) 00002660 48 45 4C 4C 4F\|20 20 20\|45 4C 46 20 00 01 BA A2 HELLO ELF ..º¢ 00002670 1E 3B 5A 3B 00 00 3C 86 5A 3B 82 00 62 1C 00 00 .;Z;..<†Z;‚.b... 00002680 34 30\|00 00 00 00 00 00\|54 58 54 20 00 00 00 00 40......TXT .... 00002690 00 00 00 00 00 00 00 00 00 00 91 00 04 10 00 00 ..........‘..... 000026A0 38 30\|00 00 00 00 00 00\|54 58 54 20 00 00 00 00 80......TXT .... 000026B0 00 00 00 00 00 00 00 00 00 00 9A 00 04 10 00 00 ..........š.....

Code:
1 2 3 4 5 6 7 8	// FloppyImage.bin (Rootdir nach dem Schreiben) 00002660 48 45 4C 4C 4F\|20 20 20\|45 4C 46 20 00 01 BA A2 HELLO ELF ..º¢ 00002670 1E 3B 5A 3B 00 00 3C 86 5A 3B 82 00 62 1C 00 00 .;Z;..<†Z;‚.b... 00002680 34 30\|00 00 00 00 00 00\|54 58 54 20 00 00 00 00 40......TXT .... 00002690 00 00 00 00 00 00 00 00 00 00 91 00 04 10 00 00 ..........‘..... 000026A0 38 30\|00 00 00 00 00 00\|54 58 54 20 00 00 00 00 80......TXT .... 000026B0 00 00 00 00 00 00 00 00 00 00 9A 00 04 10 00 00 ..........š.....

Code:
1 2 3 4 5 6 7 8	// FloppyImage.bin (Rootdir nach dem Schreiben) 00002660 48 45 4C 4C 4F\|20 20 20\|45 4C 46 20 00 01 BA A2 HELLO ELF ..º¢ 00002670 1E 3B 5A 3B 00 00 3C 86 5A 3B 82 00 62 1C 00 00 .;Z;..<†Z;‚.b... 00002680 34 30\|00 00 00 00 00 00\|54 58 54 20 00 00 00 00 40......TXT .... 00002690 00 00 00 00 00 00 00 00 00 00 91 00 04 10 00 00 ..........‘..... 000026A0 38 30\|00 00 00 00 00 00\|54 58 54 20 00 00 00 00 80......TXT .... 000026B0 00 00 00 00 00 00 00 00 00 00 9A 00 04 10 00 00 ..........š.....

Da fehlen noch die nachfolgenden Leerzeichen um auf "8" zu kommen. Seltsamerweise haben VMs damit keine Schwierigkeiten.

FlashBurn Mitglied 20:53:03 26.03.2010 Titel:

Zitat:

Seltsamerweise haben VMs damit keine Schwierigkeiten.

Die VM hat damit gar nichts zu tun, nur der Code der die Daten liest!

Unregistrierter 21:36:49 26.03.2010 Titel:

VMs reagieren unterschiedlich auf gleichen Code. Wenn bei PrettyOS irgendwas auf Anhieb nicht funktioniert, ist bei mir erstmal die/eine VM dran schuld. Danach erst eventuelle geringfügige Programmierfehler im Quellcode.

Zum Thema:
Eine VM mit MS-DOS als "Gast" (oder wie das sonst heißt) kann die "neuen" Dateien auf der FloppyImage.bin nicht lesen, da ... siehe oben.

Unregistrierter 11:22:57 29.03.2010 Titel:

Revision 293

Die Shell sieht nun aus wie eine bunte Kuh

. Aber sie ist nun um etliches besser als in vorherigen Revisionen.

Sehr gute userfriendly Arbeit! :live:

Aber wie starte ich nun eine zweite (und dritte ...) Shell?

Mr X Mitglied 21:07:58 29.03.2010 Titel:

Danke für das Lob, +gjm+

Mehr Programme gehen bald (vmtl. rev 294). Derzeit gibts noch eine Blockade in der Shell, die das verhindert (Mit Absicht, sonst stören sich die Progs alle gegenseitig)

EDIT: Seit Rev. 294 gehts.

Erhard Henkes Mitglied 00:31:33 30.03.2010 Titel:

Erst ab Rev. 295 läuft das Multikonsolen-System von MrX sehr gut. Wir mussten die shell auf einen anderen Stackpointer setzen als die restlichen User-Programme. Das verstehen wir nicht wirklich. Hier das start.asm:

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	; start.asm [BITS 32] extern __bss_start extern __end extern _main extern _exit extern _test global _start _start: mov esp, 0x500000 ; stackpointer call _main call _exit call _test jmp $

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	; start.asm [BITS 32] extern __bss_start extern __end extern _main extern _exit extern _test global _start _start: mov esp, 0x500000 ; stackpointer call _main call _exit call _test jmp $

Assembler Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	; start.asm [BITS 32] extern __bss_start extern __end extern _main extern _exit extern _test global _start _start: mov esp, 0x500000 ; stackpointer call _main call _exit call _test jmp $

Bei den User-Programmen nehmen wir 0x600000.

Setzt man Shell und die anderen Programme auf 0x500000, dann erlebt man so etwas:

Zitat:

Page Fault ( user-mode) at 00000000h - EIP: 00000000h err_code: 00000005h address(eip): 00000000h edi: 00000001h esi: 01401688h ebp: 000000C8h eax: 004FFFAFh ebx: 004FFFAFh ecx: 00000000h edx: 00000006h cs: 0000001Bh ds: 00000023h es: 00000023h fs: 00000023h gs 00000023h ss 00000023h int_no 14 eflags 00000246h useresp 004FFF90h

Ich hoffe auf die geniale "Spürnase" +gjm+

Jarvix (im IRC) meint, dass es am User-Stack liegt, den wir nicht richtig für jede User-App allokieren. Die Methode in start.asm sei falsch für viele Programme.

Unregistrierter 23:09:59 30.03.2010 Titel:

Revision 295
Es gibt tatsächlich ein Paging-Problem:

Assembler Code:
; user\user_tools\start.asm 295 _start: ; mov esp, 0x600000 ; stackpointer mov esp, 0x01402000 ; <- solange das problem nicht beseitigt ist

Assembler Code:
; user\user_tools\start.asm 295 _start: ; mov esp, 0x600000 ; stackpointer mov esp, 0x01402000 ; <- solange das problem nicht beseitigt ist

Assembler Code:
; user\user_tools\start.asm 295 _start: ; mov esp, 0x600000 ; stackpointer mov esp, 0x01402000 ; <- solange das problem nicht beseitigt ist

Wenn der Stack der USER mit Adresse 0x600000 inititialisiert wird, benutzen sämtliche USER einen identischen Stack (und somit auch identische lokale Variablen (was heißt Adresse und Wert sämtlicher lokalen Variablen sind bei sämtlichen USERN identisch (sofern man ein Programm mehrmals startet). ( <- Hoffentlich kam das verständlich rüber

.).

Irgendwie wird Adresse 0x600000 (und KERNELs 0x500000) nicht korrekt "gepaged".

Wenn KERNEL (Shell) und alle USER die 0x01402000 benutzen, gibt es keine Probleme. Ein (dann neues) Problem gäbe es erst, wenn die Shell und/oder die Userprogramme > 0x2000 Bytes wären.

Erhard Henkes Mitglied 23:40:48 30.03.2010 Titel:

Zitat:

Irgendwie wird Adresse 0x600000 (und KERNELs 0x500000) nicht korrekt "gepaged".

Das passiert hier in paging.c, line 262, in paging_install:

C/C++ Code:
// Setup 0x00400000 to 0x00600000 as writeable userspace kernel_pd->codes[1] \|= MEM_USER \| MEM_WRITE; for (int i=0; i<512; ++i) kernel_pd->tables[1]->pages[i] \|= MEM_USER \| MEM_WRITE;

C/C++ Code:
// Setup 0x00400000 to 0x00600000 as writeable userspace kernel_pd->codes[1] \|= MEM_USER \| MEM_WRITE; for (int i=0; i<512; ++i) kernel_pd->tables[1]->pages[i] \|= MEM_USER \| MEM_WRITE;

C/C++ Code:
// Setup 0x00400000 to 0x00600000 as writeable userspace kernel_pd->codes[1] \|= MEM_USER \| MEM_WRITE; for (int i=0; i<512; ++i) kernel_pd->tables[1]->pages[i] \|= MEM_USER \| MEM_WRITE;

wobei wir nicht 0x600000, sondern 0x5fffff nehmen sollten.

Die shell ist übrigens ein User_Programm und wird auch genauso gestartet.

XanClic Mitglied 11:28:53 31.03.2010 Titel:

Erhard Henkes schrieb:

wobei wir nicht 0x600000, sondern 0x5fffff nehmen sollten.

Nein, da ein PUSH zuerst ESP um vier verringert und dann den Wert auf den Stack legt. Somit führt ESP==0x600000 dazu, dass das erste PUSH den Wert nach 0x5FFFFC legt (im Übrigen sollte man wohl besser keinen unalignten Stack benutzen, der Wert sollte IMO besser immer an vier ausgerichtet sein).

Erhard Henkes Mitglied 18:24:03 31.03.2010 Titel:

@XanClic: ja, ist richtig. Sorry, da hat Jarvix mich irritiert.

@+gjm+: danke, wir nehmen nun 0x1420000 als gemeinsame virtuelle Stackadresse, allokieren aber für jedes User-Programm in create_task und nicht nur einmal in paging_install. Damit sind die physikalischen Speicheradressen wirklich verschieden.

XanClic Mitglied 18:49:05 31.03.2010 Titel:

Wie bereits im IRC gesagt, bekomme ich direkt nach dem Start einen Pagefault:

PrettyOS schrieb:

<RAM Disk at C0005000h DIR> dev
35 info
13104 shell

Page Fault ( read-only - write operation user-mode) at 004FFFFCh - EIP: 014013F5h
err_code: 00000007h address(eip): 014013F5h
edi: 00000000h esi: 00000000h ebp: 00000000h eax: 00000000h ebx: 00000000h ecx: 00000000h edx: 00000000h
cs: 0000001Bh ds: 00000023h es: 00000023h fs: 00000023h gs 00000023h ss 00000023h
int_no 14 eflags 00000202h useresp 00500000h

Page Fault >>> Exception. System Halted! <<<

Offensichtlich wird da wohl versucht, was auf den Stack zu legen, das klappt aber nicht (warum auch immer, ob die Page jetzt wirklich Read-Only ist, wie es angezeigt wird, oder ob sie nicht für den Usermode ist) und das Programm verabschiedet sich mit einer Protection Violation.

EDIT: OK, das Problem bestand darin, dass man offensichtlich erstmal make clean ausführen muss, was ich nicht getan habe. Jetzt läuft es.

Erhard Henkes Mitglied 22:32:16 31.03.2010 Titel:

Lag offenbar daran, dass immer noch 0x500000 vorgegeben wurde durch alte Dateien, jetzt aber 0x1420000. Nach Update auch bei XanClic: "Na ja, es scheint zu funktionieren".

Bei mir läuft es aber auf real PC noch nicht, stürzt bei Eingabe in TTT ab.

Unregistrierter 10:53:03 01.04.2010 Titel:

Revision 303

Kleiner Fehler in der console.c. Betrifft zwei Stellen:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	// console.c 303 void console_init(console_t* console, const char* name) { (...) // memsetw (console->vidmem, 0x20 \| (console->attrib << 8), COLUMNS USER_LINES * 2);* memsetw (console->vidmem, 0x20 \| (console->attrib << 8), COLUMNS * USER_LINES ); (...) } void clear_console(uint8_t backcolor) { (...) // memsetw (current_console->vidmem, 0x20 \| (current_console->attrib << 8), COLUMNS USER_LINES * 2);* memsetw (current_console->vidmem, 0x20 \| (current_console->attrib << 8), COLUMNS * USER_LINES); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	// console.c 303 void console_init(console_t* console, const char* name) { (...) // memsetw (console->vidmem, 0x20 \| (console->attrib << 8), COLUMNS USER_LINES * 2);* memsetw (console->vidmem, 0x20 \| (console->attrib << 8), COLUMNS * USER_LINES ); (...) } void clear_console(uint8_t backcolor) { (...) // memsetw (current_console->vidmem, 0x20 \| (current_console->attrib << 8), COLUMNS USER_LINES * 2);* memsetw (current_console->vidmem, 0x20 \| (current_console->attrib << 8), COLUMNS * USER_LINES); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	// console.c 303 void console_init(console_t* console, const char* name) { (...) // memsetw (console->vidmem, 0x20 \| (console->attrib << 8), COLUMNS USER_LINES * 2);* memsetw (console->vidmem, 0x20 \| (console->attrib << 8), COLUMNS * USER_LINES ); (...) } void clear_console(uint8_t backcolor) { (...) // memsetw (current_console->vidmem, 0x20 \| (current_console->attrib << 8), COLUMNS USER_LINES * 2);* memsetw (current_console->vidmem, 0x20 \| (current_console->attrib << 8), COLUMNS * USER_LINES); (...) }

memsetw! Das "* 2" bewirkt, daß doppelt soviel Speicher überschrieben wird wie eigentlich gedacht. Das könnte auch der Fehler sein, warum TTT auf dem realen PC nicht läuft. VMs schummeln ja immer.

Erhard Henkes Mitglied 22:10:26 01.04.2010 Titel:

danke, wurde umgesetzt.

Erhard Henkes Mitglied 03:26:07 02.04.2010 Titel:

Für den anstehenden Code Review schlage ich folgende Reihenfolge vor (analog Start):

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	Bootloader 1 Bootloader 2 Kernel: gdt_install(); idt_install(); timer_install(); keyboard_install(); mouse_install(); <--- neu syscall_install(); setup_x87_fpu(); paging_install(); heap_install(); tasking_install(); pciScan(); ...

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	Bootloader 1 Bootloader 2 Kernel: gdt_install(); idt_install(); timer_install(); keyboard_install(); mouse_install(); <--- neu syscall_install(); setup_x87_fpu(); paging_install(); heap_install(); tasking_install(); pciScan(); ...

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	Bootloader 1 Bootloader 2 Kernel: gdt_install(); idt_install(); timer_install(); keyboard_install(); mouse_install(); <--- neu syscall_install(); setup_x87_fpu(); paging_install(); heap_install(); tasking_install(); pciScan(); ...

Damit decken wir die wesentlichen Elemente von PrettyOS ab.

Unregistrierter 15:06:23 02.04.2010 Titel:

Revision 309
Wenn schon, denn schon:

C/C++ Code:
//memset((void)tictactoe, 0, 18); // tictactoe has two bytes!* memset((void)tictactoe, 0, sizeof*(tictactoe));

C/C++ Code:
//memset((void)tictactoe, 0, 18); // tictactoe has two bytes!* memset((void)tictactoe, 0, sizeof*(tictactoe));

C/C++ Code:
//memset((void)tictactoe, 0, 18); // tictactoe has two bytes!* memset((void)tictactoe, 0, sizeof*(tictactoe));

Aber folgendes stört weiterhin:

C/C++ Code:
memset((void )ph->vaddr, 0, ph->memsz); // to set the bss (Block Started by Symbol) to zero*

C/C++ Code:
memset((void )ph->vaddr, 0, ph->memsz); // to set the bss (Block Started by Symbol) to zero*

C/C++ Code:
memset((void )ph->vaddr, 0, ph->memsz); // to set the bss (Block Started by Symbol) to zero*

Sollte das den Absturz auf dem realen PC verhindern, dann wird irgendwo im Quellcode auf nicht initialisierte Variablen zugegriffen.
Das wiederum wird der tatsächliche Grund für den Absturz sein.

Erhard Henkes Mitglied 17:06:51 02.04.2010 Titel:

C/C++ Code:
program_header_t* ph = (program_header_t*)header_pos;

C/C++ Code:
program_header_t* ph = (program_header_t*)header_pos;

C/C++ Code:
program_header_t* ph = (program_header_t*)header_pos;

elf.c, line 138
Hier wird ein Pointer auf die Instanz ph vom Typ struct program_header_t auf konkrete Werte gesetzt, wenn ich mich nicht täusche, oder?

Es stürzt nichts mehr ab, alles läuft gut. Nur einige alte PC von Cuervo machen unverständliche Probleme mit Floppy/DMA beim Laden.

C/C++ Code:
memset((void)tictactoe, 0, sizeof*(tictactoe));

C/C++ Code:
memset((void)tictactoe, 0, sizeof*(tictactoe));

C/C++ Code:
memset((void)tictactoe, 0, sizeof*(tictactoe));

Danke, wird so eingebaut.

Unregistrierter 10:57:23 03.04.2010 Titel:

Revision 313
Um das TS bit in CR0 zu löschen geht auch CLTS:

C/C++ Code:
// set TS in cr0 to zero // uint32_t cr0; // __asm__ volatile("mov %%cr0, %0": "=r"(cr0)); // read cr0 // cr0 &= ~0x8; // reset the TS bit (no. 3) in CR0 to disable #NM // __asm__ volatile("mov %0, %%cr0":: "r"(cr0)); // write cr0 __asm__ ("CLTS"); // CLearTS

C/C++ Code:
// set TS in cr0 to zero // uint32_t cr0; // __asm__ volatile("mov %%cr0, %0": "=r"(cr0)); // read cr0 // cr0 &= ~0x8; // reset the TS bit (no. 3) in CR0 to disable #NM // __asm__ volatile("mov %0, %%cr0":: "r"(cr0)); // write cr0 __asm__ ("CLTS"); // CLearTS

C/C++ Code:
// set TS in cr0 to zero // uint32_t cr0; // __asm__ volatile("mov %%cr0, %0": "=r"(cr0)); // read cr0 // cr0 &= ~0x8; // reset the TS bit (no. 3) in CR0 to disable #NM // __asm__ volatile("mov %0, %%cr0":: "r"(cr0)); // write cr0 __asm__ ("CLTS"); // CLearTS

Erhard Henkes Mitglied 11:20:45 03.04.2010 Titel:

Hey, so einfach geht das?

Gibt es dauch den entsprechenden befehl zum Setzen?

Unregistrierter 12:59:28 03.04.2010 Titel:

Den gibt es nicht. Aber könnte es sein, daß das TS bit in der "task_switch" sowieso schon von der CPU gesetzt wurde?

Erhard Henkes Mitglied 13:19:39 03.04.2010 Titel:

Da wir software task switching durchführen eher nicht.

Unregistrierter 09:24:06 10.04.2010 Titel:

Revision 341
"vidmem" ist ein uint16_t*. Deshalb kopiert "2*i" nur jedes zweite Zeichen vom screenshot:

C/C++ Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	// video.c static void catchVidmem() { uint16_t* vidmem = (uint16_t) 0xB8000; (...) // videoscreen[j] = (uint8_t)(vidmem + 2i); videoscreen[j] = (uint8_t)(vidmem + i); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9	// video.c static void catchVidmem() { uint16_t* vidmem = (uint16_t) 0xB8000; (...) // videoscreen[j] = (uint8_t)(vidmem + 2i); videoscreen[j] = (uint8_t)(vidmem + i); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9	// video.c static void catchVidmem() { uint16_t* vidmem = (uint16_t) 0xB8000; (...) // videoscreen[j] = (uint8_t)(vidmem + 2i); videoscreen[j] = (uint8_t)(vidmem + i); (...) }

Erhard Henkes Mitglied 10:54:32 10.04.2010 Titel:

@+gjm+: Vielen Dank! Keine Ahnung, bei welcher "Aufräumaktion" das passiert ist, sieht einfacher aus und funktioniert, daher sofort implementiert.

Erhard Henkes Mitglied 10:54:57 10.04.2010 Titel:

In Rev. 342 korrigiert: ctrl+s: process, ctrl+t: thread

Cuervo Mitglied 16:33:56 10.04.2010 Titel:

Fehler in 344:

Bei "hello.elf":
http://prettyos.fanofblitzbasic.de/error.png QEMU
http://prettyos.fanofblitzbasic.de/error2.png VirtualBox
wenn man scrollt.. sieht aber witzig aus^^

Unregistrierter 18:22:36 10.04.2010 Titel:

C/C++ Code:
// os.h //static const uint8_t USER_LINES = 46; static const uint8_t USER_LINES = 42;

C/C++ Code:
// os.h //static const uint8_t USER_LINES = 46; static const uint8_t USER_LINES = 42;

C/C++ Code:
// os.h //static const uint8_t USER_LINES = 46; static const uint8_t USER_LINES = 42;

Sonst fährt der Zug zeilenweise mit nach oben.

Mr X Mitglied 18:37:37 10.04.2010 Titel:

Die Lösung (aber nicht deine

) Ist bereits in Arbeit

Unregistrierter 21:56:06 10.04.2010 Titel:

Kleine Unlogik in der keyboard.c, aber offenbar ohne Auswirkungen:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	// keyboard.c uint8_t checkKQ_and_return_char() { cli(); // 1. interrupts verbieten if (...) { (...) return KEY; // <- ! hier kann die funktion auch verlassen werden ! } sti(); // 2. interrupts wieder zulassen return 0; // 3. funktion verlassen }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	// keyboard.c uint8_t checkKQ_and_return_char() { cli(); // 1. interrupts verbieten if (...) { (...) return KEY; // <- ! hier kann die funktion auch verlassen werden ! } sti(); // 2. interrupts wieder zulassen return 0; // 3. funktion verlassen }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	// keyboard.c uint8_t checkKQ_and_return_char() { cli(); // 1. interrupts verbieten if (...) { (...) return KEY; // <- ! hier kann die funktion auch verlassen werden ! } sti(); // 2. interrupts wieder zulassen return 0; // 3. funktion verlassen }

Unregistrierter 20:36:24 13.04.2010 Titel:

(setScrollField(), syscall, hm, naja.

)

Revision 362

Die VMs haben es mal wieder voll drauf. VMWARE initialisiert das eingestellte RAM bei Start nicht mit Null. Das hat zur Folge, daß die BSS-Sektion der KERNEL.BIN nicht mit Null, sondern mit Speichermüll (bzw. eigentlich überhaupt nicht) initialisiert wird. Darum läuft VMWARE z.Zt. nicht. Ein übler Hack könnte das Problem beseitigen:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	1 2 3 4 5 6 7 8 9 10 11	// ckernel.c 362 int main() { //.bss 0x00052de0 0x26b24 -> steht so in der KERNEL.MAP und kann jedesmal anders sein memset((void *)0x00052de0, 0, 0x26b24); // init(); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	// ckernel.c 362 int main() { //.bss 0x00052de0 0x26b24 -> steht so in der KERNEL.MAP und kann jedesmal anders sein memset((void *)0x00052de0, 0, 0x26b24); // init(); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	// ckernel.c 362 int main() { //.bss 0x00052de0 0x26b24 -> steht so in der KERNEL.MAP und kann jedesmal anders sein memset((void *)0x00052de0, 0, 0x26b24); // init(); (...) }

Hoffentlich fällt Euch was besseres ein, da das auch die realen PCs betrifft.

Erhard Henkes Mitglied 18:35:57 14.04.2010 Titel:

C/C++ Code:
memset(&_bss_start,0x0,(uintptr_t)&_kernel_end - (uintptr_t)&_bss_start);

C/C++ Code:
memset(&_bss_start,0x0,(uintptr_t)&_kernel_end - (uintptr_t)&_bss_start);

C/C++ Code:
memset(&_bss_start,0x0,(uintptr_t)&_kernel_end - (uintptr_t)&_bss_start);

Danke für den Hinweis! Wir hatten das früher schon mal in kernel.asm, wurde offenbar entfernt, weil der Kernel keine elf-Datei ist, sondern binär. Das passt aber auch gut zu Beginn von init() in main().

Erhard Henkes Mitglied 11:11:14 15.04.2010 Titel:

@ +gjm* et.al.: wir könnten mal jemand brauchen, der uns bei EHCI noch einige Tipps gibt, was da bei real Hardware noch schief läuft. Manchmal haben wir J-State anstelle Hi-Speed (könnte ein Zeitproblem sein), und bei modernen PCs mit ext. capabilities noch Host System Error, den wir nicht verstehen. Da hängen wir noch, was den USB-Fortschritt hemmt. Da wäre konkrete Hilfe durch Spürnasen sehr viel wert. Zum Glück läuft das Ganze bei qemu. Da kann man unter Win aber keine USB-devices vom Host durchreichen, soweit ich weiß.

Unregistrierter 21:10:44 15.04.2010 Titel:

Bei der Entwicklung des USB-Treibers gibt es mittlerweile zuviele mögliche Fehlerursachen. Beispielsweise kann die Ursache für den "Host System Error" auch ein völlig anderes PCI-Gerät gewesen sein.

Um die möglichen Fehlerursachen drastisch einzuschränken, stelle ich mal zur Diskussion, den USB-Treiber unabhängig von PrettyOS zu entwickeln.

Dazu müsste eine Version von PrettyOS aufs wesentliche reduziert werden (PM, ev. Paging, Eingabe, Ausgabe). Diese Version könnte dann umbennant werden in PrettyDD (Pretty Driver Development

) und soll einzig und alleine nur für die Entwicklung von Treibern dienen. Auf/mit PrettyDD entwickelte Treiber sollten dann problemlos ins (one and only) PrettyOS integriert werden können.

Erhard Henkes Mitglied 01:29:38 16.04.2010 Titel:

Zitat:

Beispielsweise kann die Ursache für den "Host System Error" auch ein völlig anderes PCI-Gerät gewesen sein.

Das veretehe ich noch nicht ganz, wie wir durch eine "abgespeckte stabile Version" bei der EHCI-Entwicklung Fehler durch andere PCI-Geräte ausschließen können. An welche Geräte denkst Du da konkret und wie schließe ich deren Fehler sicher aus? Welche Module würdest Du hier konkret weg lassen?

Mr X Mitglied 15:58:24 16.04.2010 Titel:

alle, die nicht zwingend nötig sind fürs USB-Development.
Z.B. braucht man dann keinen Netzwerkartentreiber

Erhard Henkes Mitglied 17:54:13 16.04.2010 Titel:

Das könnte man aber möglicherweise auch über einen #define _TEST_EHCI_ Schalter bewirken. Wenn der gesetzt ist, dann wird z.B. Netzwerk, vielleicht auch Floppy usw. nicht aktiviert.

Mr X Mitglied 18:11:16 16.04.2010 Titel:

Das ist doch Unsinn, den ganzen Code von Makros zu durchsetzen...

Unregistrierter 22:42:59 16.04.2010 Titel:

Schade

. Ich hätte gerne zum Treiber testen ein PrettyDD gehabt, wo die ckernel.c in etwa nur noch so aussieht:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	void init() { gdt_install(); idt_install(); paging_install(); heap_install(); } int main() { init(); pciScan(); startEHCI(); while(1){} }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	void init() { gdt_install(); idt_install(); paging_install(); heap_install(); } int main() { init(); pciScan(); startEHCI(); while(1){} }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	void init() { gdt_install(); idt_install(); paging_install(); heap_install(); } int main() { init(); pciScan(); startEHCI(); while(1){} }

Hier nun eine mögliche Fehlerursache für den "Host System Error":

C/C++ Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	// ehci.c int32_t initEHCIHostController() { (...) irq_install_handler(32 + pciDev_Array[num].irq, ehci_handler); irq_install_handler(32 + pciDev_Array[num].irq-1, ehci_handler); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9	// ehci.c int32_t initEHCIHostController() { (...) irq_install_handler(32 + pciDev_Array[num].irq, ehci_handler); irq_install_handler(32 + pciDev_Array[num].irq-1, ehci_handler); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9	// ehci.c int32_t initEHCIHostController() { (...) irq_install_handler(32 + pciDev_Array[num].irq, ehci_handler); irq_install_handler(32 + pciDev_Array[num].irq-1, ehci_handler); (...) }

Laut pciScan() benutzen mehrere PCI-Geräte den selben irq. So läßt sich nicht herausfinden, welches Gerät den Handler via irq aufgerufen hat bzw. darf nur das EHCI-Gerät den Handler aufrufen. Allerdings wird auf meinem realen PC ein "Host System Error" auch ausgelöst, wenn versucht wird, statt EHCI OHCI (was heißt das falsche Gerät) zu initialisieren.

Mr X Mitglied 23:12:45 16.04.2010 Titel:

Das Wort "Unsinn" bezog sich nicht auf deinen Vorschlag, +gjm+, sondern auf ehenkes Makro-Idee.
Ich denke, es wäre sinnvoller, einen Branch dafür anzulegen, anstatt den Codes mit Makros aufzublähen, die die meisten nicht bräuchten.

Erhard Henkes Mitglied 00:32:26 17.04.2010 Titel:

+gjm+: leider nicht der Fehler

ich werde an einem "bare bone" pretty operating system arbeiten, damit wir EHCI ohne ballast testen können, vielleicht hilft es.

Der Host System Error tritt übrigens beim Einschalten der async-List für den USB-Transfer auf. All die EHCI-Vorbereitungen laufen also problemlos.

Erhard Henkes Mitglied 10:41:03 17.04.2010 Titel:

Da Host System Error in PCI-Problem ist, habe ich nun folgendes hinzugefügt in pci.c, damit wir mit PCI/EHCI/USB2 weiter kommen:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28	void analyzeHostSystemError(uint32_t num) { uint8_t bus = pciDev_Array[num].bus; uint8_t dev = pciDev_Array[num].device; uint8_t func = pciDev_Array[num].func; // check pci status register of the device uint32_t pciStatus = pci_config_read(bus, dev, func, PCI_STATUS); settextcolor(12,0); printf("pci status word: %x\n",pciStatus); // bits 0...2 reserved if(pciStatus & 1<< 3) printf("Interrupt Status\n"); if(pciStatus & 1<< 4) printf("Capabilities List\n"); if(pciStatus & 1<< 5) printf("66 MHz Capable\n"); // bit 6 reserved if(pciStatus & 1<< 7) printf("Fast Back-to-Back Transactions Capable\n"); if(pciStatus & 1<< 8) printf("Master Data Parity Error\n"); // DEVSEL Timing: bits 10:9 if(pciStatus & 1<<11) printf("Signalled Target-Abort\n"); if(pciStatus & 1<<12) printf("Received Target-Abort\n"); if(pciStatus & 1<<13) printf("Received Master-Abort\n"); if(pciStatus & 1<<14) printf("Signalled System Error\n"); if(pciStatus & 1<<15) printf("Detected Parity Error\n"); settextcolor(15,0); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28	void analyzeHostSystemError(uint32_t num) { uint8_t bus = pciDev_Array[num].bus; uint8_t dev = pciDev_Array[num].device; uint8_t func = pciDev_Array[num].func; // check pci status register of the device uint32_t pciStatus = pci_config_read(bus, dev, func, PCI_STATUS); settextcolor(12,0); printf("pci status word: %x\n",pciStatus); // bits 0...2 reserved if(pciStatus & 1<< 3) printf("Interrupt Status\n"); if(pciStatus & 1<< 4) printf("Capabilities List\n"); if(pciStatus & 1<< 5) printf("66 MHz Capable\n"); // bit 6 reserved if(pciStatus & 1<< 7) printf("Fast Back-to-Back Transactions Capable\n"); if(pciStatus & 1<< 8) printf("Master Data Parity Error\n"); // DEVSEL Timing: bits 10:9 if(pciStatus & 1<<11) printf("Signalled Target-Abort\n"); if(pciStatus & 1<<12) printf("Received Target-Abort\n"); if(pciStatus & 1<<13) printf("Received Master-Abort\n"); if(pciStatus & 1<<14) printf("Signalled System Error\n"); if(pciStatus & 1<<15) printf("Detected Parity Error\n"); settextcolor(15,0); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28	void analyzeHostSystemError(uint32_t num) { uint8_t bus = pciDev_Array[num].bus; uint8_t dev = pciDev_Array[num].device; uint8_t func = pciDev_Array[num].func; // check pci status register of the device uint32_t pciStatus = pci_config_read(bus, dev, func, PCI_STATUS); settextcolor(12,0); printf("pci status word: %x\n",pciStatus); // bits 0...2 reserved if(pciStatus & 1<< 3) printf("Interrupt Status\n"); if(pciStatus & 1<< 4) printf("Capabilities List\n"); if(pciStatus & 1<< 5) printf("66 MHz Capable\n"); // bit 6 reserved if(pciStatus & 1<< 7) printf("Fast Back-to-Back Transactions Capable\n"); if(pciStatus & 1<< 8) printf("Master Data Parity Error\n"); // DEVSEL Timing: bits 10:9 if(pciStatus & 1<<11) printf("Signalled Target-Abort\n"); if(pciStatus & 1<<12) printf("Received Target-Abort\n"); if(pciStatus & 1<<13) printf("Received Master-Abort\n"); if(pciStatus & 1<<14) printf("Signalled System Error\n"); if(pciStatus & 1<<15) printf("Detected Parity Error\n"); settextcolor(15,0); }

das zeigt bei dem PC, der Host System Error alarmiert, folgendes:
- capabilities list
- fast back to back transaction
- master abort

für "fast back to back transaction" steht bei low level:

Zitat:

Wenn diese Bit gesetzt ist bedeutet dasss dass das betreffende PCI-Gerät die minimal schnelleren Back-to-Back Transfers unterstützt. Als Target werden diese Transfers immer unterstützt, aber als Master dürfen diese Transfers nur benutzt werden falls das Bit 9 im Command-Register gesetzt ist.

bezüglich master abort: nix

Unregistrierter 15:25:24 17.04.2010 Titel:

Revision 374

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	1 2 3 4 5 6 7 8 9 10 11	// ehci.c 374 void resetPort(uint8_t j) { pOpRegs->PORTSC[j] \|= PSTS_POWERON; /* http://www.intel.com/technology/usb/download/ehci-r10.pdf (...) */ pOpRegs->PORTSC[j] &= ~PSTS_ENABLED; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	// ehci.c 374 void resetPort(uint8_t j) { pOpRegs->PORTSC[j] \|= PSTS_POWERON; /* http://www.intel.com/technology/usb/download/ehci-r10.pdf (...) */ pOpRegs->PORTSC[j] &= ~PSTS_ENABLED; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11	// ehci.c 374 void resetPort(uint8_t j) { pOpRegs->PORTSC[j] \|= PSTS_POWERON; /* http://www.intel.com/technology/usb/download/ehci-r10.pdf (...) */ pOpRegs->PORTSC[j] &= ~PSTS_ENABLED; }

Der Kommentar aus dem Manual betrifft PSTS_PORT_RESET und nicht PSTS_POWERON. :confused:

Mein realer PC hat lt. Scan 10 USB-Ports. Davon sind aber nur 9 "von außen" verfügbar. Deshalb wird ein Port (jedesmal der gleiche) ständig als "power on, enabled, EHCI owned" angezeigt. Unabhängig davon ob nun ein USB-Gerät "eingeklinkt" ist/wird oder nicht. Dieser Port zeigt auch (ganz selten aber) mal "J-Status" an.

Außerdem kann es ganz, ganz, ganz selten passieren, daß die untere Statuszeile nach > 200 Sekunden für eine Sekunde Unsinn anzeigt (z.B. 55:55:5555 als Uhrzeit). :eek:

Unregistrierter 17:53:35 21.04.2010 Titel:

Revision 391

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	1 2 3 4 5 6 7 8 9 10 11 12	// ckernel.c rev 391 static void init() { // kernel_console_init(); // clear_screen(); gdt_install(); idt_install(); kernel_console_init(); clear_screen();

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	// ckernel.c rev 391 static void init() { // kernel_console_init(); // clear_screen(); gdt_install(); idt_install(); kernel_console_init(); clear_screen();

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	// ckernel.c rev 391 static void init() { // kernel_console_init(); // clear_screen(); gdt_install(); idt_install(); kernel_console_init(); clear_screen();

Besser die Deskriptoren zu aller erst installieren und danach den "Rest". VMWARE hatte mal in früheren Revisionen in "kernel_console_init" Mist gemacht woraus dann ein Triplefault resultierte. USB rev 391 funktioniert auf meinem realen PC auch. :live:

Erhard Henkes Mitglied 18:13:59 21.04.2010 Titel:

Zitat:

USB rev 391 funktioniert auf meinem realen PC auch. :live:

Danke für den Hinweis! Diese Version sollten wir nun zu einer stabilen, brauchbaren Basis ausbauen, bevor wir neue Experimente aufsetzen.

Unregistrierter 10:10:23 24.04.2010 Titel:

Revision 398
Hm, einmal würde reichen.

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	// ckernel.c 398 static void init() { (...) // descriptors gdt_install(); idt_install(); // cf. interrupts.asm // descriptors gdt_install(); idt_install(); // cf. interrupts.asm // video kernel_console_init(); clear_screen(); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	// ckernel.c 398 static void init() { (...) // descriptors gdt_install(); idt_install(); // cf. interrupts.asm // descriptors gdt_install(); idt_install(); // cf. interrupts.asm // video kernel_console_init(); clear_screen(); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18	// ckernel.c 398 static void init() { (...) // descriptors gdt_install(); idt_install(); // cf. interrupts.asm // descriptors gdt_install(); idt_install(); // cf. interrupts.asm // video kernel_console_init(); clear_screen(); (...) }

Mr X Mitglied 10:12:51 24.04.2010 Titel:

oh, das stimmt natürlich, wird geändert.
Danke

Unregistrierter 13:38:34 24.04.2010 Titel:

Revision 401
Da haben sich einige "Rechtschreibfehler" eingeschlichen:

C/C++ Code:
// usb2.c 401 void showConfigurationDesriptor(struct usb2_configurationDescriptor* d) (...)

C/C++ Code:
// usb2.c 401 void showConfigurationDesriptor(struct usb2_configurationDescriptor* d) (...)

C/C++ Code:
// usb2.c 401 void showConfigurationDesriptor(struct usb2_configurationDescriptor* d) (...)

Desriptor -> Descriptor

(Btw.: Wollt ihr den CDI-Kram auch mal einsetzen?)

Mr X Mitglied 14:03:05 24.04.2010 Titel:

Ja, wir würden ihn gerne einsetzen, aber das setzt Einsatzbereitschaft voraus: Die Implementation ist nichtmal ansatzweise fertig.

Erhard Henkes Mitglied 18:12:08 24.04.2010 Titel:

Zitat:

Da haben sich einige "Rechtschreibfehler" eingeschlichen

Danke!

Bevor wir noch beim Raptor enden, haben wir es korrigiert.

Erhard Henkes Mitglied 00:29:15 03.05.2010 Titel:

Zitat:

Wollt ihr den CDI-Kram auch mal einsetzen?

Wenn Du uns beim USB bulk transfer bei der Fehlersuche hilfst, kommen wir schneller daran.

Unregistrierter 21:32:34 05.05.2010 Titel:

Revision 434

Auf meinem realen PC funktioniert eine stark zusammengestrichene testMSD() perfekt:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	1 2 3 4 5 6 7 8 9 10 11 12	// usb2_msd.c 434 void testMSD(uint8_t devAddr) { // maxLUN (0 for USB-sticks) usbDevices[devAddr].maxLUN = 0; usbTransferBulkOnlyMassStorageReset(devAddr, usbDevices[devAddr].numInterfaceMSD); // Reset Interface ///////// step 7: send SCSI comamnd "read(10)", read one block (512 byte) from LBA ..., get Status textColor(0x09); printf("\n>>> SCSI: read(10)"); textColor(0x0F); usbSendSCSIcmd(devAddr, usbDevices[devAddr].numEndpointOutMSD, usbDevices[devAddr].numEndpointInMSD, 0x28, 0, 1, true); waitForKeyStroke(); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	// usb2_msd.c 434 void testMSD(uint8_t devAddr) { // maxLUN (0 for USB-sticks) usbDevices[devAddr].maxLUN = 0; usbTransferBulkOnlyMassStorageReset(devAddr, usbDevices[devAddr].numInterfaceMSD); // Reset Interface ///////// step 7: send SCSI comamnd "read(10)", read one block (512 byte) from LBA ..., get Status textColor(0x09); printf("\n>>> SCSI: read(10)"); textColor(0x0F); usbSendSCSIcmd(devAddr, usbDevices[devAddr].numEndpointOutMSD, usbDevices[devAddr].numEndpointInMSD, 0x28, 0, 1, true); waitForKeyStroke(); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	// usb2_msd.c 434 void testMSD(uint8_t devAddr) { // maxLUN (0 for USB-sticks) usbDevices[devAddr].maxLUN = 0; usbTransferBulkOnlyMassStorageReset(devAddr, usbDevices[devAddr].numInterfaceMSD); // Reset Interface ///////// step 7: send SCSI comamnd "read(10)", read one block (512 byte) from LBA ..., get Status textColor(0x09); printf("\n>>> SCSI: read(10)"); textColor(0x0F); usbSendSCSIcmd(devAddr, usbDevices[devAddr].numEndpointOutMSD, usbDevices[devAddr].numEndpointInMSD, 0x28, 0, 1, true); waitForKeyStroke(); }

Aber ein zweiter Aufruf von usbSendSCSIcmd() innerhalb von testMSD() geht regelmäßig schief. Irgendwas stimmt mit den blöden Adressen noch nicht.

VMs schummeln ja immer in dieser Hinsicht. :mad:

Erhard Henkes Mitglied 22:10:13 05.05.2010 Titel:

stimmt, der einmalige Aufruf einer Funktion ging bisher immer recht gut, nur die Abfolge macht Probleme. Schau dir bitte mal die rev. 435 an.

Noch besser: die Version 436 mit aktiviertem #define _USB_DIAGNOSIS_ (ging vorher nicht fehlerfrei)

Ich habe noch ein "test unit ready" vor "inquiry" gesetzt, dann hakt es beim IN-endpoint bei "inquiry" aus, was zuvor an Platz eins bestens lief. Der QH/qTD-Code ist also prinzipiell ok.

Nimmt man zweimal inquiry hintereinander:
- erstes läuft gut
- beim zweiten "inquiry" wird der IN-QueueHead nicht mehr ausgeführt

Zitat:

dev: 3 interface: 0 endpOUT: 2 endpIN: 1
USB2: usbTransferBulkOnlyMassStorageReset, dev: 3 interface: 0#
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>>> SCSI: inquiry
OUT part#
IN part transfer>0#
virtAddrBuf0 C024D000h : 00h 80h 02h 02h 1Fh 00h 00h 00h 6Dh 65h 6Dh 6Fh 72h 79h
00h 00h 55h 53h 42h 32h 2Eh 30h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 31h 2Eh
30h 30h
virtAddrBuf0 C024D000h : memoryUSB2.01.00

virtAddrBuf0 C024C000h : 55h 53h 42h 53h 12h 42h 42h 42h 00h 00h 00h 00h 00h

Command Passed ("good status")
qTD Status: 00h OK (no bit set)<-- data
qTD Status: 00h OK (no bit set)<-- status

Command Block Status Values in "good status"

>>> Press key <<<
>>> SCSI: inquiry
OUT part#
IN part transfer>0###################
timeout - no STS_USBINT set!
virtAddrBuf0 C0253000h : 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h
00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h
00h 00h
virtAddrBuf0 C0253000h :

virtAddrBuf0 C0252000h : 55h 53h 42h 53h AAh AAh AAh AAh AAh AAh AAh AAh AAh

qTD Status: 80h Active - HC transactions enabled<-- data
qTD Status: 80h Active - HC transactions enabled<-- status

Beide an den IN-QH angehängten qTD werden nicht ausgeführt, obwohl es beim ersten Durchgang problemlos abgearbeitet wird. :confused:

Erhard Henkes Mitglied 23:51:53 07.05.2010 Titel:

Zitat:

Irgendwas stimmt mit den blöden Adressen noch nicht.

@+gjm*: kannst du das genauer spezifizieren? Ich sehe beim speicher kein problem.

Die neue Rev. 437 ist etwas besser geeignet für Versuche.

Erhard Henkes Mitglied 19:17:29 08.05.2010 Titel:

Rev. 439 bietet nun den besten Überblick über den Transfer im qTD-Bereich.

Erhard Henkes Mitglied 10:02:53 09.05.2010 Titel:

Mit Rev. 441 haben wir eine erste stabile Plattform bei USB Mass Storage Device erzielt. Wenn sich dies stabilisiert können wir die Floppy bald in "Rente" schicken.

Erhard Henkes Mitglied 10:05:58 09.05.2010 Titel:

Code:
<RAM Disk at C0002000h DIR> dev 35 infošºíÆ×íí-îùÌ¬Åîí^Àì?¬ÎNèTÝUÅË 9796 shell¤¼ìŽž„œššDþ„TôÁŽÅÞŽHÚÎÌŸË.[

Code:
<RAM Disk at C0002000h DIR> dev 35 infošºíÆ×íí-îùÌ¬Åîí^Àì?¬ÎNèTÝUÅË 9796 shell¤¼ìŽž„œššDþ„TôÁŽÅÞŽHÚÎÌŸË.[

Code:
<RAM Disk at C0002000h DIR> dev 35 infošºíÆ×íí-îùÌ¬Åîí^Àì?¬ÎNèTÝUÅË 9796 shell¤¼ìŽž„œššDþ„TôÁŽÅÞŽHÚÎÌŸË.[

Hier wurde offenbar etwas "kaputt" optimiert. Da fehlt das abschließende '\0'.

EDIT: wurde inzwischen repariert (neues strncpy)

Erhard Henkes Mitglied 20:58:43 09.05.2010 Titel:

Rev. 444 zeigt den oberflächlichen Grund, warum Transfers nicht laufen (qTD Status 0x80 (= active bit7) wird nicht zurück gesetzt und qTD nicht ausgeführt):
Es liegt am NAK counter. Setzt man RL (reload Nak Counter) auf 15 (4-bit-value), dann findet man bei manchen Devices NAK counter = 0, also 15 mal NAK. Dann bleibt der EHCI hilflos stehen.

http://www.lowlevel.eu/wiki/USB (von XanClic):

Zitat:

Hier schickt der Host zuerst einmal das Datenpaket, kann das Gerät dieses nicht annehmen, antwortet es mit NAK. Wenn es das Paket empfangen kann, antwortet es mit ACK, wenn das Gerät danach noch ein Paket aufnehmen kann oder mit NYET, wenn nicht. Hat der Host ACK empfangen, so sendet er das nächste Paket. Hat er allerdings ein NYET oder ein NAK erhalten, dann beginnt er nun mit PING-Paketen. Das Gerät muss mit NAK antworten, wenn es immer noch kein Paket empfangen kann, oder mit ACK, wenn es nun bereit ist. Dies verringert die Anzahl an sinnlos gesendeten Daten natürlich erheblich. Das Gerät kann hierbei sogar angegeben, wann das nächste PING-Paket gesendet werden soll (der Host muss dies aber nicht befolgen).

Der NAK counter zählt auch NYET, wenn ich das richtig verstanden habe.

Unregistrierter 20:20:58 11.05.2010 Titel:

Revision 447

Sherlock Holmes schrieb:

Wenn man alles Unmögliche ausgeschlossen hat, muss in dem, was noch übrigbleibt, so unwahrscheinlich es auch scheinen mag, die Wahrheit zu finden sein.

^^ In diesem Sinne:

Nach jedem Aufruf von usbSendSCSIcmd (usb2_msd.c) geht das verloren, was der Aufruf von usbTransferSetConfiguration (usb2.c) in checkPortLineStatus (ehci.c) bewirkt hatte.

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32	// usb2_msd.c 447 void testMSD(uint8_t devAddr) { (...) ///////// step 1: send SCSI comamnd "inquiry (opcode: 0x12)" textColor(0x09); printf("\n>>> SCSI: inquiry"); textColor(0x0F); //=====================================DEBUG============================ usbTransferSetConfiguration(devAddr,1); // usbTransferBulkOnlyMassStorageReset(devAddr, usbDevices[devAddr].numInterfaceMSD); // Reset Interface //=====================================DEBUG============================ usbSendSCSIcmd(...); ///////// step 2: send SCSI comamnd "test unit ready(6)" textColor(0x09); printf("\n>>> SCSI: test unit ready"); textColor(0x0F); //=====================================DEBUG============================ usbTransferSetConfiguration(devAddr,1); // usbTransferBulkOnlyMassStorageReset(devAddr, usbDevices[devAddr].numInterfaceMSD); // Reset Interface //=====================================DEBUG============================ usbSendSCSIcmd(...); // (usw.) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32	// usb2_msd.c 447 void testMSD(uint8_t devAddr) { (...) ///////// step 1: send SCSI comamnd "inquiry (opcode: 0x12)" textColor(0x09); printf("\n>>> SCSI: inquiry"); textColor(0x0F); //=====================================DEBUG============================ usbTransferSetConfiguration(devAddr,1); // usbTransferBulkOnlyMassStorageReset(devAddr, usbDevices[devAddr].numInterfaceMSD); // Reset Interface //=====================================DEBUG============================ usbSendSCSIcmd(...); ///////// step 2: send SCSI comamnd "test unit ready(6)" textColor(0x09); printf("\n>>> SCSI: test unit ready"); textColor(0x0F); //=====================================DEBUG============================ usbTransferSetConfiguration(devAddr,1); // usbTransferBulkOnlyMassStorageReset(devAddr, usbDevices[devAddr].numInterfaceMSD); // Reset Interface //=====================================DEBUG============================ usbSendSCSIcmd(...); // (usw.) }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32	// usb2_msd.c 447 void testMSD(uint8_t devAddr) { (...) ///////// step 1: send SCSI comamnd "inquiry (opcode: 0x12)" textColor(0x09); printf("\n>>> SCSI: inquiry"); textColor(0x0F); //=====================================DEBUG============================ usbTransferSetConfiguration(devAddr,1); // usbTransferBulkOnlyMassStorageReset(devAddr, usbDevices[devAddr].numInterfaceMSD); // Reset Interface //=====================================DEBUG============================ usbSendSCSIcmd(...); ///////// step 2: send SCSI comamnd "test unit ready(6)" textColor(0x09); printf("\n>>> SCSI: test unit ready"); textColor(0x0F); //=====================================DEBUG============================ usbTransferSetConfiguration(devAddr,1); // usbTransferBulkOnlyMassStorageReset(devAddr, usbDevices[devAddr].numInterfaceMSD); // Reset Interface //=====================================DEBUG============================ usbSendSCSIcmd(...); // (usw.) }

^^ So läufts auf meinem realen PC.

Erhard Henkes Mitglied 21:09:27 11.05.2010 Titel:

Danke für den Tipp! :live:

Erhard Henkes Mitglied 22:06:36 11.05.2010 Titel:

Ich habe das jetzt objektiv getestet:
1) lief auch schon vorher auf real PC
2) es gibt in der Tat usb-sticks, die die configuration zurück auf 0 setzen! Kann man mit getConfig ja vorher testen
3) aber jetzt kommt es:

Zitat:

PrettyOS [Version 0.0.0.449] Console 1: EHCI Ports
--------------------------------------------------------------------------------
USB2: SET_CONFIGURATION 1>!
USB2: GET_CONFIGURATION>! 1
OUT part
asyncList: 01667000h <-- QH_Out CommandQTD: 01669000h
before aS:
curr QH: 01667000h next QH: 01667000h
curr qTD: 00000000h next qTD: 01669000h
NAK counter: 0>!
after aS:
curr QH: 01667000h next QH: 01667000h
curr qTD: 01669000h next qTD: 00000000h
NAK counter: 15
IN part
asyncList: 01668000h <-- QH_In
handshakeQTD: 0166B000h StatusQTD: 0166D000h DataQTD: 0166F000h
before aS:
curr QH: 01668000h next QH: 01668000h
curr qTD: 00000000h next qTD: 0166F000h
NAK counter: 0>!
after aS:
curr QH: 01668000h next QH: 01668000h
curr qTD: 0166B000h next qTD: 00000000h
NAK counter: 15
00h 80h 02h 02h 1Fh 00h 00h 00h 6Dh 65h 6Dh 6Fh 72h 79h 00h 00h 55h 53h 42h 32h
2Eh 30h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 31h 2Eh 30h 30h
memoryUSB2.01.00

55h 53h 42h 53h 12h 42h 42h 42h 00h 00h 00h 00h 00h

Command Passed ("good status")
qTD Status: 01h Do Ping<-- command
qTD Status: 00h OK (no bit set)<-- data
qTD Status: 00h OK (no bit set)<-- status
USB2: GET_CONFIGURATION>! 0
USB2: SET_CONFIGURATION 1>!
USB2: GET_CONFIGURATION>! 0

Command Block Status Values in "good status"

USB status: 00002000h
Reclamation
>>> Press key <<<
--------------------------------------------------------------------------------
Port: 1, device attached

Vor "inquiry" ist alles ok.
Nach "inquiry" sitzt die configuration auf 0 (bedeutet unkonfiguriert) und lässt sich aber auch nicht mehr gerade biegen auf 1. :warning:

@+gjm+: Echt Superklasse dein Fund! Wie machst du das bloß?

Erhard Henkes Mitglied 23:21:39 11.05.2010 Titel:

Der Grund ist gefunden: ein falscher handshake nach dem CSW

Dieses Bild hat mich irre geleitet: http://www.beyondlogic.org/usbnutshell/contdata.gif in http://www.beyondlogic.org/usbnutshell/usb4.htm bei bulk transfer

Ich sehe drei Fälle:
1) MSD device ist unempfindlich gegen falschen handshake (bei mir zwei 16 GB sticks und der 512 MB stick)
2) MSD device ist empfindlich gegen handshake, man kann aber die config wieder setzen (das war der Fund von +gjm+)
3) empfindlich, nicht reaparierbar, also trotz "setzen" kommt die config nicht mehr (mein 1 GB stick und Tobiking's Laptop mit seinem stick)

Der Fund von +gjm+, mein 1 GB stick und der Beweis bei Tobiking's Laptop, das waren wichtige Puzzleteile.

Der Meilenstein wurde erreicht! :live:

Ein gewaltiger Dank gebührt +gjm+. Er begleitet PrettyOS seit den Anfängen in absolut konstruktiver Weise. Ihm gebührt ein Platz in der "Hall of Fame" unserer kleinen OS-Community. :live:

Erhard Henkes Mitglied 00:08:55 13.05.2010 Titel:

siehe: http://www.c-plusplus.de/forum/viewtopic-var-p-is-1896489.html#1896489

Handshake --> Konfiguration von 1 auf 0 ---> set_config(1) (+gjm+) ---> Nebeneffekt: setzt die toggles der device endpoints auf 0 --> mehrfach fehlerhaftes Programm läuft.

Nun wurde im bulk-Transfer der Handshake entfernt, und es wird sauber getogglet.

Erhard Henkes Mitglied 08:11:06 10.06.2010 Titel:

Bitte um Hilfe bezüglich User-Stack/-Heap:
http://www.c-plusplus.de/forum/viewtopic-var-p-is-1909791.html#1909791

Erhard Henkes Mitglied 19:39:42 16.06.2010 Titel:

http://www.c-plusplus.de/forum/viewtopic-var-t-is-254893-and-start-is-550.html

BL2 hatte im Fat12.inc offenbar mit dem kernel-Laden nach 0x3000 bis ... seinen eigenen Stack bei 0x1FFFF überschrieben, was wir durch Versetzen des Stacks nach 0x3FFFF beseitigen konnten. Allerdings bietet dieses Fat12.inc noch Optimierungspotential, weil sich dort bugs und hotfixes irgendwie die Waage halten.

Erhard Henkes Mitglied 01:09:26 21.06.2010 Titel:

Wenn sich jemand mit Assembler und FAT12 richtig gut auskennt, könnte er uns vielleicht helfen beim Optimieren dieses Tools. Ansonsten droht GRUB.

Erhard Henkes Mitglied 19:50:06 28.06.2010 Titel:

Das Assembler-Forum unterstützt uns dankenswerterweise mit einigen Ratschlägen:
http://www.c-plusplus.de/forum/viewtopic-var-p-is-1918524.html#1918524

Gamepower Mitglied 17:58:47 02.07.2010 Titel:

hallo ihr,

ich habe mit "bochs" ein problem mit dem laden des images. mir scheint, als ob der bootloader stage1 geladen wird, danach aber ein abbruch kommt. die version von prettyos habe ich nun nicht im kopf, weis aber das ckernel.c die version "0.0.0.530" hat.

hier mal meine bochsrc.bxrc:

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46	############################################################### # bochsrc.txt file for DLX Linux disk image. ############################################################### # how much memory the emulated machine will have megs: 32 # filename of ROM images romimage: file="C:\Program Files\Bochs-2.4.5\BIOS-bochs-latest" vgaromimage: file="C:\Program Files\Bochs-2.4.5\VGABIOS-lgpl-latest" # what disk images will be used floppya: 1_44="C:\prettyos\trunk\Source\FloppyImage.img", status=inserted #floppyb: 1_44=floppyb.img, status=inserted # hard disk #ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 #ata0-master: type=disk, path="hd10meg.img", cylinders=306, heads=4, spt=17 # choose the boot disk. boot: a # default config interface is textconfig. #config_interface: textconfig #config_interface: wx #display_library: x # other choices: win32 sdl wx carbon amigaos beos macintosh nogui rfb term svga # where do we send log messages? log: C:\prettyos\trunk\Source\bochsout.txt # disable the mouse, since DLX is text only mouse: enabled=0 # enable key mapping, using US layout as default. # # NOTE: In Bochs 1.4, keyboard mapping is only 100% implemented on X windows. # However, the key mapping tables are used in the paste function, so # in the DLX Linux example I'm enabling keyboard_mapping so that paste # will work. Cut&Paste is currently implemented on win32 and X windows only. #keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-us.map #keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-fr.map keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-de.map #keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-es.map

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46	############################################################### # bochsrc.txt file for DLX Linux disk image. ############################################################### # how much memory the emulated machine will have megs: 32 # filename of ROM images romimage: file="C:\Program Files\Bochs-2.4.5\BIOS-bochs-latest" vgaromimage: file="C:\Program Files\Bochs-2.4.5\VGABIOS-lgpl-latest" # what disk images will be used floppya: 1_44="C:\prettyos\trunk\Source\FloppyImage.img", status=inserted #floppyb: 1_44=floppyb.img, status=inserted # hard disk #ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 #ata0-master: type=disk, path="hd10meg.img", cylinders=306, heads=4, spt=17 # choose the boot disk. boot: a # default config interface is textconfig. #config_interface: textconfig #config_interface: wx #display_library: x # other choices: win32 sdl wx carbon amigaos beos macintosh nogui rfb term svga # where do we send log messages? log: C:\prettyos\trunk\Source\bochsout.txt # disable the mouse, since DLX is text only mouse: enabled=0 # enable key mapping, using US layout as default. # # NOTE: In Bochs 1.4, keyboard mapping is only 100% implemented on X windows. # However, the key mapping tables are used in the paste function, so # in the DLX Linux example I'm enabling keyboard_mapping so that paste # will work. Cut&Paste is currently implemented on win32 and X windows only. #keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-us.map #keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-fr.map keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-de.map #keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-es.map

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46	############################################################### # bochsrc.txt file for DLX Linux disk image. ############################################################### # how much memory the emulated machine will have megs: 32 # filename of ROM images romimage: file="C:\Program Files\Bochs-2.4.5\BIOS-bochs-latest" vgaromimage: file="C:\Program Files\Bochs-2.4.5\VGABIOS-lgpl-latest" # what disk images will be used floppya: 1_44="C:\prettyos\trunk\Source\FloppyImage.img", status=inserted #floppyb: 1_44=floppyb.img, status=inserted # hard disk #ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 #ata0-master: type=disk, path="hd10meg.img", cylinders=306, heads=4, spt=17 # choose the boot disk. boot: a # default config interface is textconfig. #config_interface: textconfig #config_interface: wx #display_library: x # other choices: win32 sdl wx carbon amigaos beos macintosh nogui rfb term svga # where do we send log messages? log: C:\prettyos\trunk\Source\bochsout.txt # disable the mouse, since DLX is text only mouse: enabled=0 # enable key mapping, using US layout as default. # # NOTE: In Bochs 1.4, keyboard mapping is only 100% implemented on X windows. # However, the key mapping tables are used in the paste function, so # in the DLX Linux example I'm enabling keyboard_mapping so that paste # will work. Cut&Paste is currently implemented on win32 and X windows only. #keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-us.map #keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-fr.map keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-de.map #keyboard_mapping: enabled=1, map=$BXSHARE/keymaps/x11-pc-es.map

hier noch das output der bochsout.txt:

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188	00000000000i[ ] Bochs x86 Emulator 2.4.5 00000000000i[ ] Build from CVS snapshot, on April 25, 2010 00000000000i[ ] System configuration 00000000000i[ ] processors: 1 (cores=1, HT threads=1) 00000000000i[ ] A20 line support: yes 00000000000i[ ] CPU configuration 00000000000i[ ] level: 6 00000000000i[ ] SMP support: no 00000000000i[ ] APIC support: yes 00000000000i[ ] FPU support: yes 00000000000i[ ] MMX support: yes 00000000000i[ ] 3dnow! support: no 00000000000i[ ] SEP support: yes 00000000000i[ ] SSE support: sse2 00000000000i[ ] XSAVE support: no 00000000000i[ ] AES support: no 00000000000i[ ] MOVBE support: no 00000000000i[ ] x86-64 support: yes 00000000000i[ ] 1G paging support: no 00000000000i[ ] MWAIT support: no 00000000000i[ ] VMX support: no 00000000000i[ ] Optimization configuration 00000000000i[ ] RepeatSpeedups support: yes 00000000000i[ ] Trace cache support: yes 00000000000i[ ] Fast function calls: yes 00000000000i[ ] Devices configuration 00000000000i[ ] ACPI support: yes 00000000000i[ ] NE2000 support: yes 00000000000i[ ] PCI support: yes, enabled=yes 00000000000i[ ] SB16 support: yes 00000000000i[ ] USB support: yes 00000000000i[ ] VGA extension support: vbe cirrus 00000000000i[MEM0 ] allocated memory at 02D80020. after alignment, vector=02D81000 00000000000i[MEM0 ] 32,00MB 00000000000i[MEM0 ] mem block size = 0x00100000, blocks=32 00000000000i[MEM0 ] rom at 0xfffe0000/131072 ('C:\Program Files\Bochs-2.4.5\BIOS-bochs-latest') 00000000000i[MEM0 ] rom at 0xc0000/40448 ('C:\Program Files\Bochs-2.4.5\VGABIOS-lgpl-latest') 00000000000i[CMOS ] Using local time for initial clock 00000000000i[CMOS ] Setting initial clock to: Fri Jul 02 17:55:29 2010 (time0=1278086129) 00000000000i[DMA ] channel 4 used by cascade 00000000000i[DMA ] channel 2 used by Floppy Drive 00000000000i[FDD ] fd0: 'C:\prettyos\trunk\Source\FloppyImage.img' ro=0, h=2,t=80,spt=18 00000000000i[PCI ] 440FX Host bridge present at device 0, function 0 00000000000i[PCI ] PIIX3 PCI-to-ISA bridge present at device 1, function 0 00000000000i[MEM0 ] Register memory access handlers: 0x000a0000 - 0x000bffff 00000000000i[WGUI ] Desktop Window dimensions: 1280 x 800 00000000000i[WGUI ] Number of Mouse Buttons = 5 00000000000i[WGUI ] IME disabled 00000000000i[KMAP ] Loading keymap from 'C:\Program Files\Bochs-2.4.5/keymaps/x11-pc-de.map' 00000000000i[KMAP ] Loaded 212 symbols 00000000000i[MEM0 ] Register memory access handlers: 0xe0000000 - 0xe0ffffff 00000000000i[CLVGA] VBE Bochs Display Extension Enabled 00000000000i[CLVGA] interval=50000 00000000000i[ ] init_dev of 'unmapped' plugin device by virtual method 00000000000i[ ] init_dev of 'biosdev' plugin device by virtual method 00000000000i[ ] init_dev of 'speaker' plugin device by virtual method 00000000000i[ ] init_dev of 'extfpuirq' plugin device by virtual method 00000000000i[ ] init_dev of 'gameport' plugin device by virtual method 00000000000i[ ] init_dev of 'pci_ide' plugin device by virtual method 00000000000i[PCI ] PIIX3 PCI IDE controller present at device 1, function 1 00000000000i[ ] init_dev of 'acpi' plugin device by virtual method 00000000000i[PCI ] ACPI Controller present at device 1, function 3 00000000000i[ ] init_dev of 'ioapic' plugin device by virtual method 00000000000i[IOAP ] initializing I/O APIC 00000000000i[MEM0 ] Register memory access handlers: 0xfec00000 - 0xfec00fff 00000000000i[ ] init_dev of 'keyboard' plugin device by virtual method 00000000000i[KBD ] will paste characters every 1000 keyboard ticks 00000000000i[ ] init_dev of 'harddrv' plugin device by virtual method 00000000000i[HD ] Using boot sequence floppy, none, none 00000000000i[HD ] Floppy boot signature check is enabled 00000000000i[ ] init_dev of 'serial' plugin device by virtual method 00000000000i[SER ] com1 at 0x03f8 irq 4 00000000000i[ ] init_dev of 'parallel' plugin device by virtual method 00000000000i[PAR ] parallel port 1 at 0x0378 irq 7 00000000000i[ ] register state of 'unmapped' plugin device by virtual method 00000000000i[ ] register state of 'biosdev' plugin device by virtual method 00000000000i[ ] register state of 'speaker' plugin device by virtual method 00000000000i[ ] register state of 'extfpuirq' plugin device by virtual method 00000000000i[ ] register state of 'gameport' plugin device by virtual method 00000000000i[ ] register state of 'pci_ide' plugin device by virtual method 00000000000i[ ] register state of 'acpi' plugin device by virtual method 00000000000i[ ] register state of 'ioapic' plugin device by virtual method 00000000000i[ ] register state of 'keyboard' plugin device by virtual method 00000000000i[ ] register state of 'harddrv' plugin device by virtual method 00000000000i[ ] register state of 'serial' plugin device by virtual method 00000000000i[ ] register state of 'parallel' plugin device by virtual method 00000000000i[SYS ] bx_pc_system_c::Reset(HARDWARE) called 00000000000i[CPU0 ] cpu hardware reset 00000000000i[APIC0] allocate APIC id=0 (MMIO enabled) to 0xfee00000 00000000000i[CPU0 ] CPUID[0x00000000]: 00000003 756e6547 6c65746e 49656e69 00000000000i[CPU0 ] CPUID[0x00000001]: 00000f20 00000800 00002000 078bfbff 00000000000i[CPU0 ] CPUID[0x00000002]: 00410601 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x00000003]: 00000000 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x00000004]: 00000000 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x80000000]: 80000008 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x80000001]: 00000000 00000000 00000101 2a100800 00000000000i[CPU0 ] CPUID[0x80000002]: 20202020 20202020 20202020 6e492020 00000000000i[CPU0 ] CPUID[0x80000003]: 286c6574 50202952 69746e65 52286d75 00000000000i[CPU0 ] CPUID[0x80000004]: 20342029 20555043 20202020 00202020 00000000000i[CPU0 ] CPUID[0x80000006]: 00000000 42004200 02008140 00000000 00000000000i[CPU0 ] CPUID[0x80000007]: 00000000 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x80000008]: 00003020 00000000 00000000 00000000 00000000000i[ ] reset of 'unmapped' plugin device by virtual method 00000000000i[ ] reset of 'biosdev' plugin device by virtual method 00000000000i[ ] reset of 'speaker' plugin device by virtual method 00000000000i[ ] reset of 'extfpuirq' plugin device by virtual method 00000000000i[ ] reset of 'gameport' plugin device by virtual method 00000000000i[ ] reset of 'pci_ide' plugin device by virtual method 00000000000i[ ] reset of 'acpi' plugin device by virtual method 00000000000i[ ] reset of 'ioapic' plugin device by virtual method 00000000000i[ ] reset of 'keyboard' plugin device by virtual method 00000000000i[ ] reset of 'harddrv' plugin device by virtual method 00000000000i[ ] reset of 'serial' plugin device by virtual method 00000000000i[ ] reset of 'parallel' plugin device by virtual method 00000003305i[BIOS ] $Revision: 1.247 $ $Date: 2010/04/04 19:33:50 $ 00000200000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8 00000318042i[KBD ] reset-disable command received 00000444800i[VBIOS] VGABios $Id: vgabios.c,v 1.69 2009/04/07 18:18:20 vruppert Exp $ 00000444871i[CLVGA] VBE known Display Interface b0c0 00000444903i[CLVGA] VBE known Display Interface b0c5 00000447828i[VBIOS] VBE Bios $Id: vbe.c,v 1.62 2009/01/25 15:46:25 vruppert Exp $ 00000760517i[BIOS ] Starting rombios32 00000761014i[BIOS ] Shutdown flag 0 00000761695i[BIOS ] ram_size=0x02000000 00000762173i[BIOS ] ram_end=32MB 00000802745i[BIOS ] Found 1 cpu(s) 00000822014i[BIOS ] bios_table_addr: 0x000fbc18 end=0x000fcc00 00000822117i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush) 00001149814i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush) 00001477742i[P2I ] PCI IRQ routing: PIRQA# set to 0x0b 00001477763i[P2I ] PCI IRQ routing: PIRQB# set to 0x09 00001477784i[P2I ] PCI IRQ routing: PIRQC# set to 0x0b 00001477805i[P2I ] PCI IRQ routing: PIRQD# set to 0x09 00001477815i[P2I ] write: ELCR2 = 0x0a 00001478700i[BIOS ] PIIX3/PIIX4 init: elcr=00 0a 00001486658i[BIOS ] PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 class=0x0600 00001489220i[BIOS ] PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 class=0x0601 00001491621i[BIOS ] PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 class=0x0101 00001491851i[PIDE ] new BM-DMA address: 0xc000 00001492555i[BIOS ] region 4: 0x0000c000 00001494865i[BIOS ] PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 class=0x0680 00001495103i[ACPI ] new irq line = 11 00001495117i[ACPI ] new irq line = 9 00001495147i[ACPI ] new PM base address: 0xb000 00001495161i[ACPI ] new SM base address: 0xb100 00001495189i[PCI ] setting SMRAM control register to 0x4a 00001659283i[CPU0 ] Enter to System Management Mode 00001659293i[CPU0 ] RSM: Resuming from System Management Mode 00001823313i[PCI ] setting SMRAM control register to 0x0a 00001832484i[BIOS ] MP table addr=0x000fbcf0 MPC table addr=0x000fbc20 size=0xd0 00001834543i[BIOS ] SMBIOS table addr=0x000fbd00 00001836931i[BIOS ] ACPI tables: RSDP addr=0x000fbe20 ACPI DATA addr=0x01ff0000 size=0x988 00001840169i[BIOS ] Firmware waking vector 0x1ff00cc 00001851282i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush) 00001852126i[BIOS ] bios_table_cur_addr: 0x000fbe44 00014041543i[BIOS ] Booting from 0000:7c00 00037968000p[WGUI ] >>PANIC<< Window closed, exiting! 00037968000i[CPU0 ] CPU is in real mode (active) 00037968000i[CPU0 ] CS.d_b = 16 bit 00037968000i[CPU0 ] SS.d_b = 16 bit 00037968000i[CPU0 ] EFER = 0x00000000 00037968000i[CPU0 ] \| RAX=0000000000000000 RBX=0000000000000000 00037968000i[CPU0 ] \| RCX=0000000000000000 RDX=0000000000000000 00037968000i[CPU0 ] \| RSP=000000000000fffa RBP=0000000000000000 00037968000i[CPU0 ] \| RSI=00000000000e2b02 RDI=000000000000ffac 00037968000i[CPU0 ] \| R8=0000000000000000 R9=0000000000000000 00037968000i[CPU0 ] \| R10=0000000000000000 R11=0000000000000000 00037968000i[CPU0 ] \| R12=0000000000000000 R13=0000000000000000 00037968000i[CPU0 ] \| R14=0000000000000000 R15=0000000000000000 00037968000i[CPU0 ] \| IOPL=0 id vip vif ac vm rf nt of df if tf sf ZF af PF cf 00037968000i[CPU0 ] \| SEG selector base limit G D 00037968000i[CPU0 ] \| SEG sltr(index\|ti\|rpl) base limit G D 00037968000i[CPU0 ] \| CS:f000( 0004\| 0\| 0) 000f0000 0000ffff 0 0 00037968000i[CPU0 ] \| DS:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| SS:7c00( 0005\| 0\| 0) 0007c000 0000ffff 0 0 00037968000i[CPU0 ] \| ES:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| FS:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| GS:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| MSR_FS_BASE:0000000000000000 00037968000i[CPU0 ] \| MSR_GS_BASE:0000000000000000 00037968000i[CPU0 ] \| RIP=000000000000ff53 (0000000000007c6b) 00037968000i[CPU0 ] \| CR0=0x60000010 CR2=0x0000000000000000 00037968000i[CPU0 ] \| CR3=0x00000000 CR4=0x00000000 00037968000i[CPU0 ] 0x0000000000007c6b>> mov ax, 0x0004 : B80400 00037968000i[CMOS ] Last time is 1278086138 (Fri Jul 02 17:55:38 2010) 00037968000i[ ] restoring default signal behavior 00037968000i[CTRL ] quit_sim called with exit code 1

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188	00000000000i[ ] Bochs x86 Emulator 2.4.5 00000000000i[ ] Build from CVS snapshot, on April 25, 2010 00000000000i[ ] System configuration 00000000000i[ ] processors: 1 (cores=1, HT threads=1) 00000000000i[ ] A20 line support: yes 00000000000i[ ] CPU configuration 00000000000i[ ] level: 6 00000000000i[ ] SMP support: no 00000000000i[ ] APIC support: yes 00000000000i[ ] FPU support: yes 00000000000i[ ] MMX support: yes 00000000000i[ ] 3dnow! support: no 00000000000i[ ] SEP support: yes 00000000000i[ ] SSE support: sse2 00000000000i[ ] XSAVE support: no 00000000000i[ ] AES support: no 00000000000i[ ] MOVBE support: no 00000000000i[ ] x86-64 support: yes 00000000000i[ ] 1G paging support: no 00000000000i[ ] MWAIT support: no 00000000000i[ ] VMX support: no 00000000000i[ ] Optimization configuration 00000000000i[ ] RepeatSpeedups support: yes 00000000000i[ ] Trace cache support: yes 00000000000i[ ] Fast function calls: yes 00000000000i[ ] Devices configuration 00000000000i[ ] ACPI support: yes 00000000000i[ ] NE2000 support: yes 00000000000i[ ] PCI support: yes, enabled=yes 00000000000i[ ] SB16 support: yes 00000000000i[ ] USB support: yes 00000000000i[ ] VGA extension support: vbe cirrus 00000000000i[MEM0 ] allocated memory at 02D80020. after alignment, vector=02D81000 00000000000i[MEM0 ] 32,00MB 00000000000i[MEM0 ] mem block size = 0x00100000, blocks=32 00000000000i[MEM0 ] rom at 0xfffe0000/131072 ('C:\Program Files\Bochs-2.4.5\BIOS-bochs-latest') 00000000000i[MEM0 ] rom at 0xc0000/40448 ('C:\Program Files\Bochs-2.4.5\VGABIOS-lgpl-latest') 00000000000i[CMOS ] Using local time for initial clock 00000000000i[CMOS ] Setting initial clock to: Fri Jul 02 17:55:29 2010 (time0=1278086129) 00000000000i[DMA ] channel 4 used by cascade 00000000000i[DMA ] channel 2 used by Floppy Drive 00000000000i[FDD ] fd0: 'C:\prettyos\trunk\Source\FloppyImage.img' ro=0, h=2,t=80,spt=18 00000000000i[PCI ] 440FX Host bridge present at device 0, function 0 00000000000i[PCI ] PIIX3 PCI-to-ISA bridge present at device 1, function 0 00000000000i[MEM0 ] Register memory access handlers: 0x000a0000 - 0x000bffff 00000000000i[WGUI ] Desktop Window dimensions: 1280 x 800 00000000000i[WGUI ] Number of Mouse Buttons = 5 00000000000i[WGUI ] IME disabled 00000000000i[KMAP ] Loading keymap from 'C:\Program Files\Bochs-2.4.5/keymaps/x11-pc-de.map' 00000000000i[KMAP ] Loaded 212 symbols 00000000000i[MEM0 ] Register memory access handlers: 0xe0000000 - 0xe0ffffff 00000000000i[CLVGA] VBE Bochs Display Extension Enabled 00000000000i[CLVGA] interval=50000 00000000000i[ ] init_dev of 'unmapped' plugin device by virtual method 00000000000i[ ] init_dev of 'biosdev' plugin device by virtual method 00000000000i[ ] init_dev of 'speaker' plugin device by virtual method 00000000000i[ ] init_dev of 'extfpuirq' plugin device by virtual method 00000000000i[ ] init_dev of 'gameport' plugin device by virtual method 00000000000i[ ] init_dev of 'pci_ide' plugin device by virtual method 00000000000i[PCI ] PIIX3 PCI IDE controller present at device 1, function 1 00000000000i[ ] init_dev of 'acpi' plugin device by virtual method 00000000000i[PCI ] ACPI Controller present at device 1, function 3 00000000000i[ ] init_dev of 'ioapic' plugin device by virtual method 00000000000i[IOAP ] initializing I/O APIC 00000000000i[MEM0 ] Register memory access handlers: 0xfec00000 - 0xfec00fff 00000000000i[ ] init_dev of 'keyboard' plugin device by virtual method 00000000000i[KBD ] will paste characters every 1000 keyboard ticks 00000000000i[ ] init_dev of 'harddrv' plugin device by virtual method 00000000000i[HD ] Using boot sequence floppy, none, none 00000000000i[HD ] Floppy boot signature check is enabled 00000000000i[ ] init_dev of 'serial' plugin device by virtual method 00000000000i[SER ] com1 at 0x03f8 irq 4 00000000000i[ ] init_dev of 'parallel' plugin device by virtual method 00000000000i[PAR ] parallel port 1 at 0x0378 irq 7 00000000000i[ ] register state of 'unmapped' plugin device by virtual method 00000000000i[ ] register state of 'biosdev' plugin device by virtual method 00000000000i[ ] register state of 'speaker' plugin device by virtual method 00000000000i[ ] register state of 'extfpuirq' plugin device by virtual method 00000000000i[ ] register state of 'gameport' plugin device by virtual method 00000000000i[ ] register state of 'pci_ide' plugin device by virtual method 00000000000i[ ] register state of 'acpi' plugin device by virtual method 00000000000i[ ] register state of 'ioapic' plugin device by virtual method 00000000000i[ ] register state of 'keyboard' plugin device by virtual method 00000000000i[ ] register state of 'harddrv' plugin device by virtual method 00000000000i[ ] register state of 'serial' plugin device by virtual method 00000000000i[ ] register state of 'parallel' plugin device by virtual method 00000000000i[SYS ] bx_pc_system_c::Reset(HARDWARE) called 00000000000i[CPU0 ] cpu hardware reset 00000000000i[APIC0] allocate APIC id=0 (MMIO enabled) to 0xfee00000 00000000000i[CPU0 ] CPUID[0x00000000]: 00000003 756e6547 6c65746e 49656e69 00000000000i[CPU0 ] CPUID[0x00000001]: 00000f20 00000800 00002000 078bfbff 00000000000i[CPU0 ] CPUID[0x00000002]: 00410601 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x00000003]: 00000000 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x00000004]: 00000000 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x80000000]: 80000008 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x80000001]: 00000000 00000000 00000101 2a100800 00000000000i[CPU0 ] CPUID[0x80000002]: 20202020 20202020 20202020 6e492020 00000000000i[CPU0 ] CPUID[0x80000003]: 286c6574 50202952 69746e65 52286d75 00000000000i[CPU0 ] CPUID[0x80000004]: 20342029 20555043 20202020 00202020 00000000000i[CPU0 ] CPUID[0x80000006]: 00000000 42004200 02008140 00000000 00000000000i[CPU0 ] CPUID[0x80000007]: 00000000 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x80000008]: 00003020 00000000 00000000 00000000 00000000000i[ ] reset of 'unmapped' plugin device by virtual method 00000000000i[ ] reset of 'biosdev' plugin device by virtual method 00000000000i[ ] reset of 'speaker' plugin device by virtual method 00000000000i[ ] reset of 'extfpuirq' plugin device by virtual method 00000000000i[ ] reset of 'gameport' plugin device by virtual method 00000000000i[ ] reset of 'pci_ide' plugin device by virtual method 00000000000i[ ] reset of 'acpi' plugin device by virtual method 00000000000i[ ] reset of 'ioapic' plugin device by virtual method 00000000000i[ ] reset of 'keyboard' plugin device by virtual method 00000000000i[ ] reset of 'harddrv' plugin device by virtual method 00000000000i[ ] reset of 'serial' plugin device by virtual method 00000000000i[ ] reset of 'parallel' plugin device by virtual method 00000003305i[BIOS ] $Revision: 1.247 $ $Date: 2010/04/04 19:33:50 $ 00000200000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8 00000318042i[KBD ] reset-disable command received 00000444800i[VBIOS] VGABios $Id: vgabios.c,v 1.69 2009/04/07 18:18:20 vruppert Exp $ 00000444871i[CLVGA] VBE known Display Interface b0c0 00000444903i[CLVGA] VBE known Display Interface b0c5 00000447828i[VBIOS] VBE Bios $Id: vbe.c,v 1.62 2009/01/25 15:46:25 vruppert Exp $ 00000760517i[BIOS ] Starting rombios32 00000761014i[BIOS ] Shutdown flag 0 00000761695i[BIOS ] ram_size=0x02000000 00000762173i[BIOS ] ram_end=32MB 00000802745i[BIOS ] Found 1 cpu(s) 00000822014i[BIOS ] bios_table_addr: 0x000fbc18 end=0x000fcc00 00000822117i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush) 00001149814i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush) 00001477742i[P2I ] PCI IRQ routing: PIRQA# set to 0x0b 00001477763i[P2I ] PCI IRQ routing: PIRQB# set to 0x09 00001477784i[P2I ] PCI IRQ routing: PIRQC# set to 0x0b 00001477805i[P2I ] PCI IRQ routing: PIRQD# set to 0x09 00001477815i[P2I ] write: ELCR2 = 0x0a 00001478700i[BIOS ] PIIX3/PIIX4 init: elcr=00 0a 00001486658i[BIOS ] PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 class=0x0600 00001489220i[BIOS ] PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 class=0x0601 00001491621i[BIOS ] PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 class=0x0101 00001491851i[PIDE ] new BM-DMA address: 0xc000 00001492555i[BIOS ] region 4: 0x0000c000 00001494865i[BIOS ] PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 class=0x0680 00001495103i[ACPI ] new irq line = 11 00001495117i[ACPI ] new irq line = 9 00001495147i[ACPI ] new PM base address: 0xb000 00001495161i[ACPI ] new SM base address: 0xb100 00001495189i[PCI ] setting SMRAM control register to 0x4a 00001659283i[CPU0 ] Enter to System Management Mode 00001659293i[CPU0 ] RSM: Resuming from System Management Mode 00001823313i[PCI ] setting SMRAM control register to 0x0a 00001832484i[BIOS ] MP table addr=0x000fbcf0 MPC table addr=0x000fbc20 size=0xd0 00001834543i[BIOS ] SMBIOS table addr=0x000fbd00 00001836931i[BIOS ] ACPI tables: RSDP addr=0x000fbe20 ACPI DATA addr=0x01ff0000 size=0x988 00001840169i[BIOS ] Firmware waking vector 0x1ff00cc 00001851282i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush) 00001852126i[BIOS ] bios_table_cur_addr: 0x000fbe44 00014041543i[BIOS ] Booting from 0000:7c00 00037968000p[WGUI ] >>PANIC<< Window closed, exiting! 00037968000i[CPU0 ] CPU is in real mode (active) 00037968000i[CPU0 ] CS.d_b = 16 bit 00037968000i[CPU0 ] SS.d_b = 16 bit 00037968000i[CPU0 ] EFER = 0x00000000 00037968000i[CPU0 ] \| RAX=0000000000000000 RBX=0000000000000000 00037968000i[CPU0 ] \| RCX=0000000000000000 RDX=0000000000000000 00037968000i[CPU0 ] \| RSP=000000000000fffa RBP=0000000000000000 00037968000i[CPU0 ] \| RSI=00000000000e2b02 RDI=000000000000ffac 00037968000i[CPU0 ] \| R8=0000000000000000 R9=0000000000000000 00037968000i[CPU0 ] \| R10=0000000000000000 R11=0000000000000000 00037968000i[CPU0 ] \| R12=0000000000000000 R13=0000000000000000 00037968000i[CPU0 ] \| R14=0000000000000000 R15=0000000000000000 00037968000i[CPU0 ] \| IOPL=0 id vip vif ac vm rf nt of df if tf sf ZF af PF cf 00037968000i[CPU0 ] \| SEG selector base limit G D 00037968000i[CPU0 ] \| SEG sltr(index\|ti\|rpl) base limit G D 00037968000i[CPU0 ] \| CS:f000( 0004\| 0\| 0) 000f0000 0000ffff 0 0 00037968000i[CPU0 ] \| DS:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| SS:7c00( 0005\| 0\| 0) 0007c000 0000ffff 0 0 00037968000i[CPU0 ] \| ES:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| FS:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| GS:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| MSR_FS_BASE:0000000000000000 00037968000i[CPU0 ] \| MSR_GS_BASE:0000000000000000 00037968000i[CPU0 ] \| RIP=000000000000ff53 (0000000000007c6b) 00037968000i[CPU0 ] \| CR0=0x60000010 CR2=0x0000000000000000 00037968000i[CPU0 ] \| CR3=0x00000000 CR4=0x00000000 00037968000i[CPU0 ] 0x0000000000007c6b>> mov ax, 0x0004 : B80400 00037968000i[CMOS ] Last time is 1278086138 (Fri Jul 02 17:55:38 2010) 00037968000i[ ] restoring default signal behavior 00037968000i[CTRL ] quit_sim called with exit code 1

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188	00000000000i[ ] Bochs x86 Emulator 2.4.5 00000000000i[ ] Build from CVS snapshot, on April 25, 2010 00000000000i[ ] System configuration 00000000000i[ ] processors: 1 (cores=1, HT threads=1) 00000000000i[ ] A20 line support: yes 00000000000i[ ] CPU configuration 00000000000i[ ] level: 6 00000000000i[ ] SMP support: no 00000000000i[ ] APIC support: yes 00000000000i[ ] FPU support: yes 00000000000i[ ] MMX support: yes 00000000000i[ ] 3dnow! support: no 00000000000i[ ] SEP support: yes 00000000000i[ ] SSE support: sse2 00000000000i[ ] XSAVE support: no 00000000000i[ ] AES support: no 00000000000i[ ] MOVBE support: no 00000000000i[ ] x86-64 support: yes 00000000000i[ ] 1G paging support: no 00000000000i[ ] MWAIT support: no 00000000000i[ ] VMX support: no 00000000000i[ ] Optimization configuration 00000000000i[ ] RepeatSpeedups support: yes 00000000000i[ ] Trace cache support: yes 00000000000i[ ] Fast function calls: yes 00000000000i[ ] Devices configuration 00000000000i[ ] ACPI support: yes 00000000000i[ ] NE2000 support: yes 00000000000i[ ] PCI support: yes, enabled=yes 00000000000i[ ] SB16 support: yes 00000000000i[ ] USB support: yes 00000000000i[ ] VGA extension support: vbe cirrus 00000000000i[MEM0 ] allocated memory at 02D80020. after alignment, vector=02D81000 00000000000i[MEM0 ] 32,00MB 00000000000i[MEM0 ] mem block size = 0x00100000, blocks=32 00000000000i[MEM0 ] rom at 0xfffe0000/131072 ('C:\Program Files\Bochs-2.4.5\BIOS-bochs-latest') 00000000000i[MEM0 ] rom at 0xc0000/40448 ('C:\Program Files\Bochs-2.4.5\VGABIOS-lgpl-latest') 00000000000i[CMOS ] Using local time for initial clock 00000000000i[CMOS ] Setting initial clock to: Fri Jul 02 17:55:29 2010 (time0=1278086129) 00000000000i[DMA ] channel 4 used by cascade 00000000000i[DMA ] channel 2 used by Floppy Drive 00000000000i[FDD ] fd0: 'C:\prettyos\trunk\Source\FloppyImage.img' ro=0, h=2,t=80,spt=18 00000000000i[PCI ] 440FX Host bridge present at device 0, function 0 00000000000i[PCI ] PIIX3 PCI-to-ISA bridge present at device 1, function 0 00000000000i[MEM0 ] Register memory access handlers: 0x000a0000 - 0x000bffff 00000000000i[WGUI ] Desktop Window dimensions: 1280 x 800 00000000000i[WGUI ] Number of Mouse Buttons = 5 00000000000i[WGUI ] IME disabled 00000000000i[KMAP ] Loading keymap from 'C:\Program Files\Bochs-2.4.5/keymaps/x11-pc-de.map' 00000000000i[KMAP ] Loaded 212 symbols 00000000000i[MEM0 ] Register memory access handlers: 0xe0000000 - 0xe0ffffff 00000000000i[CLVGA] VBE Bochs Display Extension Enabled 00000000000i[CLVGA] interval=50000 00000000000i[ ] init_dev of 'unmapped' plugin device by virtual method 00000000000i[ ] init_dev of 'biosdev' plugin device by virtual method 00000000000i[ ] init_dev of 'speaker' plugin device by virtual method 00000000000i[ ] init_dev of 'extfpuirq' plugin device by virtual method 00000000000i[ ] init_dev of 'gameport' plugin device by virtual method 00000000000i[ ] init_dev of 'pci_ide' plugin device by virtual method 00000000000i[PCI ] PIIX3 PCI IDE controller present at device 1, function 1 00000000000i[ ] init_dev of 'acpi' plugin device by virtual method 00000000000i[PCI ] ACPI Controller present at device 1, function 3 00000000000i[ ] init_dev of 'ioapic' plugin device by virtual method 00000000000i[IOAP ] initializing I/O APIC 00000000000i[MEM0 ] Register memory access handlers: 0xfec00000 - 0xfec00fff 00000000000i[ ] init_dev of 'keyboard' plugin device by virtual method 00000000000i[KBD ] will paste characters every 1000 keyboard ticks 00000000000i[ ] init_dev of 'harddrv' plugin device by virtual method 00000000000i[HD ] Using boot sequence floppy, none, none 00000000000i[HD ] Floppy boot signature check is enabled 00000000000i[ ] init_dev of 'serial' plugin device by virtual method 00000000000i[SER ] com1 at 0x03f8 irq 4 00000000000i[ ] init_dev of 'parallel' plugin device by virtual method 00000000000i[PAR ] parallel port 1 at 0x0378 irq 7 00000000000i[ ] register state of 'unmapped' plugin device by virtual method 00000000000i[ ] register state of 'biosdev' plugin device by virtual method 00000000000i[ ] register state of 'speaker' plugin device by virtual method 00000000000i[ ] register state of 'extfpuirq' plugin device by virtual method 00000000000i[ ] register state of 'gameport' plugin device by virtual method 00000000000i[ ] register state of 'pci_ide' plugin device by virtual method 00000000000i[ ] register state of 'acpi' plugin device by virtual method 00000000000i[ ] register state of 'ioapic' plugin device by virtual method 00000000000i[ ] register state of 'keyboard' plugin device by virtual method 00000000000i[ ] register state of 'harddrv' plugin device by virtual method 00000000000i[ ] register state of 'serial' plugin device by virtual method 00000000000i[ ] register state of 'parallel' plugin device by virtual method 00000000000i[SYS ] bx_pc_system_c::Reset(HARDWARE) called 00000000000i[CPU0 ] cpu hardware reset 00000000000i[APIC0] allocate APIC id=0 (MMIO enabled) to 0xfee00000 00000000000i[CPU0 ] CPUID[0x00000000]: 00000003 756e6547 6c65746e 49656e69 00000000000i[CPU0 ] CPUID[0x00000001]: 00000f20 00000800 00002000 078bfbff 00000000000i[CPU0 ] CPUID[0x00000002]: 00410601 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x00000003]: 00000000 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x00000004]: 00000000 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x80000000]: 80000008 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x80000001]: 00000000 00000000 00000101 2a100800 00000000000i[CPU0 ] CPUID[0x80000002]: 20202020 20202020 20202020 6e492020 00000000000i[CPU0 ] CPUID[0x80000003]: 286c6574 50202952 69746e65 52286d75 00000000000i[CPU0 ] CPUID[0x80000004]: 20342029 20555043 20202020 00202020 00000000000i[CPU0 ] CPUID[0x80000006]: 00000000 42004200 02008140 00000000 00000000000i[CPU0 ] CPUID[0x80000007]: 00000000 00000000 00000000 00000000 00000000000i[CPU0 ] CPUID[0x80000008]: 00003020 00000000 00000000 00000000 00000000000i[ ] reset of 'unmapped' plugin device by virtual method 00000000000i[ ] reset of 'biosdev' plugin device by virtual method 00000000000i[ ] reset of 'speaker' plugin device by virtual method 00000000000i[ ] reset of 'extfpuirq' plugin device by virtual method 00000000000i[ ] reset of 'gameport' plugin device by virtual method 00000000000i[ ] reset of 'pci_ide' plugin device by virtual method 00000000000i[ ] reset of 'acpi' plugin device by virtual method 00000000000i[ ] reset of 'ioapic' plugin device by virtual method 00000000000i[ ] reset of 'keyboard' plugin device by virtual method 00000000000i[ ] reset of 'harddrv' plugin device by virtual method 00000000000i[ ] reset of 'serial' plugin device by virtual method 00000000000i[ ] reset of 'parallel' plugin device by virtual method 00000003305i[BIOS ] $Revision: 1.247 $ $Date: 2010/04/04 19:33:50 $ 00000200000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8 00000318042i[KBD ] reset-disable command received 00000444800i[VBIOS] VGABios $Id: vgabios.c,v 1.69 2009/04/07 18:18:20 vruppert Exp $ 00000444871i[CLVGA] VBE known Display Interface b0c0 00000444903i[CLVGA] VBE known Display Interface b0c5 00000447828i[VBIOS] VBE Bios $Id: vbe.c,v 1.62 2009/01/25 15:46:25 vruppert Exp $ 00000760517i[BIOS ] Starting rombios32 00000761014i[BIOS ] Shutdown flag 0 00000761695i[BIOS ] ram_size=0x02000000 00000762173i[BIOS ] ram_end=32MB 00000802745i[BIOS ] Found 1 cpu(s) 00000822014i[BIOS ] bios_table_addr: 0x000fbc18 end=0x000fcc00 00000822117i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush) 00001149814i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush) 00001477742i[P2I ] PCI IRQ routing: PIRQA# set to 0x0b 00001477763i[P2I ] PCI IRQ routing: PIRQB# set to 0x09 00001477784i[P2I ] PCI IRQ routing: PIRQC# set to 0x0b 00001477805i[P2I ] PCI IRQ routing: PIRQD# set to 0x09 00001477815i[P2I ] write: ELCR2 = 0x0a 00001478700i[BIOS ] PIIX3/PIIX4 init: elcr=00 0a 00001486658i[BIOS ] PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 class=0x0600 00001489220i[BIOS ] PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 class=0x0601 00001491621i[BIOS ] PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 class=0x0101 00001491851i[PIDE ] new BM-DMA address: 0xc000 00001492555i[BIOS ] region 4: 0x0000c000 00001494865i[BIOS ] PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 class=0x0680 00001495103i[ACPI ] new irq line = 11 00001495117i[ACPI ] new irq line = 9 00001495147i[ACPI ] new PM base address: 0xb000 00001495161i[ACPI ] new SM base address: 0xb100 00001495189i[PCI ] setting SMRAM control register to 0x4a 00001659283i[CPU0 ] Enter to System Management Mode 00001659293i[CPU0 ] RSM: Resuming from System Management Mode 00001823313i[PCI ] setting SMRAM control register to 0x0a 00001832484i[BIOS ] MP table addr=0x000fbcf0 MPC table addr=0x000fbc20 size=0xd0 00001834543i[BIOS ] SMBIOS table addr=0x000fbd00 00001836931i[BIOS ] ACPI tables: RSDP addr=0x000fbe20 ACPI DATA addr=0x01ff0000 size=0x988 00001840169i[BIOS ] Firmware waking vector 0x1ff00cc 00001851282i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush) 00001852126i[BIOS ] bios_table_cur_addr: 0x000fbe44 00014041543i[BIOS ] Booting from 0000:7c00 00037968000p[WGUI ] >>PANIC<< Window closed, exiting! 00037968000i[CPU0 ] CPU is in real mode (active) 00037968000i[CPU0 ] CS.d_b = 16 bit 00037968000i[CPU0 ] SS.d_b = 16 bit 00037968000i[CPU0 ] EFER = 0x00000000 00037968000i[CPU0 ] \| RAX=0000000000000000 RBX=0000000000000000 00037968000i[CPU0 ] \| RCX=0000000000000000 RDX=0000000000000000 00037968000i[CPU0 ] \| RSP=000000000000fffa RBP=0000000000000000 00037968000i[CPU0 ] \| RSI=00000000000e2b02 RDI=000000000000ffac 00037968000i[CPU0 ] \| R8=0000000000000000 R9=0000000000000000 00037968000i[CPU0 ] \| R10=0000000000000000 R11=0000000000000000 00037968000i[CPU0 ] \| R12=0000000000000000 R13=0000000000000000 00037968000i[CPU0 ] \| R14=0000000000000000 R15=0000000000000000 00037968000i[CPU0 ] \| IOPL=0 id vip vif ac vm rf nt of df if tf sf ZF af PF cf 00037968000i[CPU0 ] \| SEG selector base limit G D 00037968000i[CPU0 ] \| SEG sltr(index\|ti\|rpl) base limit G D 00037968000i[CPU0 ] \| CS:f000( 0004\| 0\| 0) 000f0000 0000ffff 0 0 00037968000i[CPU0 ] \| DS:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| SS:7c00( 0005\| 0\| 0) 0007c000 0000ffff 0 0 00037968000i[CPU0 ] \| ES:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| FS:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| GS:0000( 0005\| 0\| 0) 00000000 0000ffff 0 0 00037968000i[CPU0 ] \| MSR_FS_BASE:0000000000000000 00037968000i[CPU0 ] \| MSR_GS_BASE:0000000000000000 00037968000i[CPU0 ] \| RIP=000000000000ff53 (0000000000007c6b) 00037968000i[CPU0 ] \| CR0=0x60000010 CR2=0x0000000000000000 00037968000i[CPU0 ] \| CR3=0x00000000 CR4=0x00000000 00037968000i[CPU0 ] 0x0000000000007c6b>> mov ax, 0x0004 : B80400 00037968000i[CMOS ] Last time is 1278086138 (Fri Jul 02 17:55:38 2010) 00037968000i[ ] restoring default signal behavior 00037968000i[CTRL ] quit_sim called with exit code 1

Mr X Mitglied 18:18:22 02.07.2010 Titel:

Zitat:

die version von prettyos habe ich nun nicht im kopf, weis aber das ckernel.c die version "0.0.0.530"

0.0.0.530 ist die Version

Vielleicht hilft als erste Maßnahme ein Update auf 0.0.1.9, es kann sein, das Du eine Version hast, die Fehler enthält. Bei mir zumindest funktioniert Version 0.0.1.9 unter Bochs.

Kommen irgendwelche Fehlermeldungen? Es gab mal Probleme mit Bochs, das einen Fehler in der KeyQueue gefunden haben wollte, und deshalb panisch wurde. Da kam dann eine Fehlermeldung. Der scheint aber inzwischen weg zu sein, "panic: action=ignore" ist nicht mehr nötig im brxc-File um PrettyOS auszuführen.

Gamepower Mitglied 22:41:04 02.07.2010 Titel:

danke dir

mir scheint aber eher, als ob meine bochs installation kapput ist... auf realer hardware laufen beide versionen... na, darum kümmere ich mich gleich mal...

Erhard Henkes Mitglied 23:46:16 02.07.2010 Titel:

Steige lieber um auf Qemu, VBox oder VMWare.

Erhard Henkes Mitglied 19:44:09 16.07.2010 Titel:

Aktueller Problemstatus bei 0.0.1.43 - Rev: 607: :rolleyes:

1) vm86 Testcode (ckernel.c, Zeilen 104 - 112) macht Probleme auf real PC
2) fdir bleibt hängen (schon länger beobachtet)

Erhard Henkes Mitglied 14:19:49 20.07.2010 Titel:

Aktueller Problemstatus bei 0.0.1.66 - Rev: 635: :rolleyes:

1) strg + t (ruft scheduler_log() auf) führt zum #PF --> Absturz
2) fdir bleibt hängen (schon länger beobachtet) --> Absturz

EDIT: alles erledigt :live:

Erhard Henkes Mitglied 15:36:28 31.07.2010 Titel:

im IRC:
<somone>MrX: ich habe mal versucht ein userprogramm zu schreiben mit, fgets u. fputc, aber qemu bringt fehlermeldungen, das ich nicht schreiben oder lesen kann...
<somone>FLOPPY ERROR: fdctrl_write_data: can't write data in status mode
<somone>FLOPPY ERROR: fdctrl_read_data: can't read data in CMD state

EDIT: ich habe die syscall-Nr. korrigiert

Erhard Henkes Mitglied 11:35:06 07.08.2010 Titel:

seit 0.0.1.131 werden "reboots" verzeichnet, die im Ablauf - nicht reproduzierbar - eintreten (qemu, PC). MrX: action please.

general protection fault: err_code: 65276 adress(eip): 00113d10h...

tev Mitglied 23:32:25 11.08.2010 Titel:

Da dies der Testthread von PrettyOS ist ,wollte ich meinen Test wiedergeben.
Also ich habe das Image des .tar.gz Archives verwendet ,welches ich von ehenkes bekommen habe.
Dies habe ich natürlich prompt mit meiner Sun VirtualBox unter meinem Ubuntu getestet.
Die Hardwareerkennung schien gut zu laufen zumindest ,wenn es nach der Ausgabe von PrettyOS ging.
Dann bin ich in der ,für meine Verhältnisse unübersichtlichen, Shell gelandet.
Sie ist deswegen unübersichtlich ,weil unter und über der Eingabe ,in der die eingegebenen Zeichen erscheinen, Text beziehungsweise ein Zug zu sehen ist und man erst suchen muss.
Als ich damit zurecht gekommen bin habe ich help eingeben und die implementierten Funktionen/Befehle getestet.
Alles hat funktioniert außer reboot.
Und noch etwas ,was aber wahrscheinlich so gehört, ist ,dass mit dem Befehl fformat das Floppyimage nicht mehr PrettyOS gebootet hat.
Also in diesem Sinne einen Gruß von mir und hoffentlich hilft euch mein Rückblick.
tev

Erhard Henkes Mitglied 23:41:39 11.08.2010 Titel:

vielen dank für das feedback. wir sind auch an weitergehenden tests aller art interessiert.

tastenkombis
strg+t (screenshot ==> floppy),
strg+u (screenshot ==> usb-stick),
ESC+h (Heap regions anzeigen)

Erhard Henkes Mitglied 12:31:47 12.08.2010 Titel:

PrettyOS 0.0.1.166 - Rev: 744
wenn ich hello starte und in konsole m strg+t ausführe, landet der ausdruck bei konsole 0, also bei hello (unerwartetes verhalten)

Erhard Henkes Mitglied 09:42:29 13.08.2010 Titel:

ein übler fehler wurde entdeckt:

zwischen svn rev. 579 und 580 ging das strg+s "kaputt". Test: img in qemu starten, strg+s, fdir (directory zerstört)

Der erste Screenshot (strg+s) überschreibt boot2.bin (cluster #2 u. #3) und den ersten cluster (#4) von kernel.bin. Damit kann qemu PrettyOS nicht mehr starten.

Dass dies über eine lange Strecke nicht entdeckt wurde, zeigt, wir brauchen einen vorgeschriebenen Testablauf, zumindest alle 10 commits, damit wir zeitnah Fehler entdecken. Hier bitte ich um Vorschläge.

Erhard Henkes Mitglied 12:56:11 13.08.2010 Titel:

Ich versuche zunächst zur Fehlerbehebung den genauen Fehler einzugrenzen:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23	FS_ERROR FAT_fputc(file_t* file, char c) { uint32_t retVal = FAT_fwrite(&c, 1, 1, file->data); /// TEST static uint32_t i=0; i++; printf("\tfputc %u ",i); /// TEST if (retVal == 1) { /// TEST printf("OK "); if (i==4098) { waitForKeyStroke(); } /// TEST return(CE_GOOD); } return CE_WRITE_ERROR; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23	FS_ERROR FAT_fputc(file_t* file, char c) { uint32_t retVal = FAT_fwrite(&c, 1, 1, file->data); /// TEST static uint32_t i=0; i++; printf("\tfputc %u ",i); /// TEST if (retVal == 1) { /// TEST printf("OK "); if (i==4098) { waitForKeyStroke(); } /// TEST return(CE_GOOD); } return CE_WRITE_ERROR; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23	FS_ERROR FAT_fputc(file_t* file, char c) { uint32_t retVal = FAT_fwrite(&c, 1, 1, file->data); /// TEST static uint32_t i=0; i++; printf("\tfputc %u ",i); /// TEST if (retVal == 1) { /// TEST printf("OK "); if (i==4098) { waitForKeyStroke(); } /// TEST return(CE_GOOD); } return CE_WRITE_ERROR; }

Damit kann man den FAT_putc verfolgen. Nach dem 4098ten (video screen + zeilenumbruch) FAT_fputc wird qemu gestoppt und abgebrochen. Schaut man sich dann per EDITDISK boot2.bin und kernel.bin mit dem hex-editor an, so stellt man fest, dass diese Dateien unbeschädigt sind. screen.txt ist angelegt mit Größe 0 byte. Es fehlt also noch der dir-entry-Eintrag.

Lässt man das waitForKeyStroke() durch Bestätigung in qemu weiter laufen, so wird boot.bin komplett mit 0 überschrieben und kernel.bin im ersten Sector genullt.

Fazit: FAT_putc richtet hier keinen direkten Schaden an.

---------------

Nächster Versuch:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	1 2 3 4 5 6 7 8 9 10	static uint32_t cluster2sector(FAT_partition_t* volume, uint32_t cluster) { //..... // #ifdef _FAT_DIAGNOSIS_ printf("\n>>>>> cluster2sector<<<<< cluster: %u sector %u", cluster, sector); if (sector < 100) waitForKeyStroke(); // #endif return (sector); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	static uint32_t cluster2sector(FAT_partition_t* volume, uint32_t cluster) { //..... // #ifdef _FAT_DIAGNOSIS_ printf("\n>>>>> cluster2sector<<<<< cluster: %u sector %u", cluster, sector); if (sector < 100) waitForKeyStroke(); // #endif return (sector); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	static uint32_t cluster2sector(FAT_partition_t* volume, uint32_t cluster) { //..... // #ifdef _FAT_DIAGNOSIS_ printf("\n>>>>> cluster2sector<<<<< cluster: %u sector %u", cluster, sector); if (sector < 100) waitForKeyStroke(); // #endif return (sector); }

Hierbei fällt bei strg+s im unteren Bereich nur die Zahl "sector 19" an. Die Daten des Screenshots werden beginnend ab 0x51000 (sector 648 = 617+31) abgelegt. Dies führt auch nicht weiter.

Die Daten, die z.Z. überschrieben werden, beginnen ab sector 33.

---------------

... und weiter gehts:

C/C++ Code:
static uint32_t fatWrite (FAT_partition_t* volume, uint32_t currCluster, uint32_t value, bool forceWrite) { /// TEST printf("\nfatWrite: currCluster %u value %X", currCluster, value); /// TEST

C/C++ Code:
static uint32_t fatWrite (FAT_partition_t* volume, uint32_t currCluster, uint32_t value, bool forceWrite) { /// TEST printf("\nfatWrite: currCluster %u value %X", currCluster, value); /// TEST

C/C++ Code:
static uint32_t fatWrite (FAT_partition_t* volume, uint32_t currCluster, uint32_t value, bool forceWrite) { /// TEST printf("\nfatWrite: currCluster %u value %X", currCluster, value); /// TEST

fat.h

C/C++ Code:
#define LAST_CLUSTER_FAT12 0xFF8

C/C++ Code:
#define LAST_CLUSTER_FAT12 0xFF8

C/C++ Code:
#define LAST_CLUSTER_FAT12 0xFF8

http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_168_Analyzing_Bug_Screenshot.PNG

Im Ergebnis sieht das aber gut aus: :confused:

http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_168_Analyzing_Bug_Screenshot_a.PNG

Erhard Henkes Mitglied 16:59:57 13.08.2010 Titel:

Im irc:

Zitat:

<DerHartmut>
Testen: Jede sinnvolle Plattform, sprich: Mindestens 3 Virtuelle Maschinen und 2 Real-PCs (wenn nicht möglich dann halt nicht möglich), Funktion der Änderung testen, ggf. Testcode einbauen (bei Commit wieder entfernen), eventuelle Wechselwirkungen beachten und andere Stellen testen, falls Wechselwirkungen vorhanden.

Also ich persönlich <DerHartmut> mache das so
1. Code schreiben
2. Compillieren, bis er sauber durchbaut
3. Testcode schreiben (falls nötig), mit printf() mögliche Ausgaben ausgeben
4. Ist vom Code noch anderer Code betroffen?
5. Rekursion!
6. Alles klappt? Testcode entfernen, nochmal durchbauen
7. Committen

Erhard Henkes Mitglied 18:04:36 13.08.2010 Titel:

Ich habe nun alle Schreibvorgänge protokolliert:
http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_168_Analyzing_Bug_Screenshot_b.PNG

Code:
2: FAT1 11: FAT2 19: Root Directory 648 ff.: Data

Code:
2: FAT1 11: FAT2 19: Root Directory 648 ff.: Data

Code:
2: FAT1 11: FAT2 19: Root Directory 648 ff.: Data

Da sieht man keinen "Angriff" auf Sektor 33-35 (0x4200 ff.)
Da würde dort ja auch etwas anderes stehen als lauter Nullen. :rolleyes:

Erhard Henkes Mitglied 18:33:01 13.08.2010 Titel:

Es liegt am Readcache. Der genaue Fehler muss noch gefunden und beseitigt werden.

Erhard Henkes Mitglied 15:10:31 14.08.2010 Titel:

Vorbemerkung: Unerkannte Bugs sind ein echtes Problem, weil sie an unpassender Stelle zuschlagen können, vor allem in Kombination, und Verwirrung stiften.
Bugs müssen zeitnah erkannt werden, da man so am besten reagieren kann. Daher wird hier ein systematischer Test vorgeschlagen.
Dinge, die man ständig beim Ausführen von PrettyOS implizit testet, werden ausgelassen, z.B. Boot-Verhalten.

Zitat:

Test für PrettyOS (sollte alle 10 commits durchgeführt und dokumentiert werden):
---------------------------------------------------------------------------------

CPU:
FPU-Test (should be implemented at ESC+f)

Memory:
recognized correctly? (should be implemented at ESC+m)

Keyboard:
Are AltGr keys recognized? Test known combinations of strg+key or ESC+key?

Video/Monitor:
Physical Address of grafics card?
Which vbe modes are shown?
Does vbe grafics work properly?

Tasking/Scheduler:
Start different programs in their own consoles. Check with strg+t.
Change freqency at timer_install(100). Try 1000 Hz.

Floppy Disk Device:
Please test the sequence strg+s, fdir, strg+s, fdir.
Load "arrow" two times.

USB mass storage devices:
Try FAT16 and FAT32 (and FAT12 if possible):
Please test the sequence strg+u, strg+u, strg+u. Test the Directory and the content of screenshot (3 texts in "screen.txt").

Networking:
Describe environment. Test ARP reply, PING reply. All incoming packets recognized?

User Library:
Load program "test" (to be developed).

Bitte um Mithilfe, diesen Test weiter auszuarbeiten.

Erhard Henkes Mitglied 15:09:28 21.08.2010 Titel:

Neben der Optimierung des äußeren Testens (eigentlich Overhead) gilt es, folgende Strategie verstärkt zu beachten:
1) Loggen/Visualisieren
2) Internes Testen durch PrettyOS selbst
3) Verstärkte Kommunikation bezüglich Änderungen bei Memory und Prozess Management (hier sind ausführliches Loggen und Tests bei mehreren Umgebungen unerlässlich, um Fehler möglichst früh zu detektieren und zu debuggen)

Erhard Henkes Mitglied 12:20:28 04.09.2010 Titel:

problem im task management:

Zitat:

0.0.1.223 - Rev: 807
...
current task: pid: 6
running tasks:
pid: 5 esp: C020CEB0h eip: 001150DEh PD: 01021000h k_stack: C020D000h
parent: 0
pid: 0 esp: 0018FF00h eip: 00000000h PD: 01021000h k_stack: 00000000h
child-threads: 5
pid: 6 esp: C02055C0h eip: 001150DEh PD: 01021000h k_stack: C0205720h
parent: 0
blocked tasks:
pid: 3 esp: C0002F70h eip: 001150DEh PD: C0208000h k_stack: C0003120h
freetime task:
pid: 1 esp: C0001054h eip: 001150DEh PD: 01021000h k_stack: C00010A8h

pid0 hat 2 kinder, verleugnet aber eines davon

Erhard Henkes Mitglied 22:52:21 05.09.2010 Titel:

http://www.c-plusplus.de/forum/viewtopic-var-p-is-1948598.html#1948598
Der neue beschleunigte Lesevorgang bewirkt massive Kollateralschäden. strg+s zerschlägt z.B. so einiges. Um Analyse / Behebung wird gebeten, damit wir das beschleunigte Lesen beibehalten können.

Mr X Mitglied 23:04:06 05.09.2010 Titel:

Wir tappen bei dem Fehler bislang im dunkeln. Ich fasse mal hier kurz zusammen, was ich festgestellt habe (auch um selbst den Überblick zu behalten):

Das bloße abstellen des neuen Cachings (z. 616 auskommentieren) bewirkt keine Besserung (aber natürlich eine Lese-Verlangsamung, weil für jeden Sektor der Track neu gelesen wird (trackweise!)).
-> Am Caching liegt es nicht.

Eine Umstellung auf sektorweises Lesen bewirkt keine Fehler bei strg+s.
-> Es hat was mit dem trackweisen Lesen zu tun

Leert man den DMA_BUFFER, bevor man schreibt (und schreibt anschließend das rein, was man schreiben will), verändert dies den Zustand des Floppyimages nach strg+s. Korrekt wäre, wenn sich nichts ändern würde am Verhalten.
-> Es scheint, als würde fälschlicherweise ein ganzer Track (oder zumindest mehr aus dem DMA_BUFFER als nötig) geschrieben.

Erhard Henkes Mitglied 00:41:19 06.09.2010 Titel:

Zitat:

Es scheint, als würde fälschlicherweise ein ganzer Track (oder zumindest mehr aus dem DMA_BUFFER als nötig) geschrieben.

Hier liegt der Hebel. Das passiert auch, wenn man Zeile 616 auskommentiert und Zeilen 625 und 655 (anstelle 624 u. 654) verwendet!

Mr X Mitglied 16:26:58 06.09.2010 Titel:

Das Rätsel ist gelüftet.

Erklärung: Die meisten Floppy-Treiber, die ich bislang gesehen habe (z.B. Tyndur und CDI), inklusive zahlreicher Seiten zum FDC (lowlevel-wiki, osdev.org) sind fehlerhaft. Wir merken es nur, weil unsere DMA-Implementation marode ist.

Der Schlüssel ist Bit 7 des Kommandos an den FDC beim lesen/schreiben eines Sektors. lowlevel war (ist jetzt korrigiert) der Meinung, dort müsste die Anzahl der Sektoren pro Track stehen.
Osdev.org behauptete, dort müsste die Anzahl der zu lesenden Sektoren stehen.
Die Treiber, die ich auch zu Rate gezogen habe folgten dem lowlevel-Vorschlag.

Nachdem ich auf einen Kommentar im CDI-Treiber gestoßen bin (der die richtige Info enthielt, sie aber nicht anwendete im Code) wurde mir das Problem klar. Kwolf/taljeth und ich haben in #lost dann darüber diskutiert, wer Recht hat und letztlich fanden wir auch in der offiziellen Spec den Hinweis, das dort der letzte zu bearbeitende Sektor stehen muss. Steht dort 18, wird bis zum letzten Sektor des Tracks gearbeitet (Also trackweise, wenn man von 1 an liest^^). (Beim lesen ists ja ohnehin egal, ob zuviel gelesen wird.)

Bei uns wurde durch die falsche Angabe zuviel geschrieben, bei tyndur aber nicht. Das liegt am DMA-Treiber. Die zweite Begrenzung für die geschriebene Datenmenge ist die Datenmenge, die DMA dem FDC gibt. Das ist bei uns falsch eingestellt (immer Trackgröße), bei tyndur hingegen richtig (Sektorgröße, wenn nur ein Sektor gelesen/geschrieben wird)