C/C++ Forum :: Sourcecode Fortschritt

Badestrand Mitglied 22:52:17 22.11.2009 Titel:

Ich würde diesen Thread gerne nutzen, um die Fortschritte festzuhalten.

Prä-Geschehenes:
Badestrand hat das Paging-Modul und Heap überarbeitet (*klick*)
Erhard hat Uhrzeit und Datum (von Cuervo und Erhard) eingebaut (*klick*)

Badestrand Mitglied 22:56:31 22.11.2009 Titel:

Version 26: Hauptsächlich ELF-Loader, sonst einige kleine Sachen:

- Simpler (!) ELF-Loader setzt bei User-Programm Einstiegsadresse bei 0x01400000 (20 MB) voraus, lädt den Source dahin und erstellt den Task.
- Die Build.bat-Datei angepasst, dass sie auch den stage1- und stage2- bootloader miterstellt.
- Interrupt-Krams zusammengefasst, bitte um Rückmeldung. Ich wollte es vor allem übersichtlicher machen, sind auch zwei Dateien rausgeflogen.
- Key-Queue aus der ODA-Struktur nach keyboard.c verlegt
- Ausgabe der Memory Map in paging.c, wenn der Diagnose-Schalter an ist
- Zur Memory Map wird nicht mehr die Anzahl der Einträge gespeichert, die Liste endet mit einem Eintrag der Größe 0.

Erhard Henkes Mitglied 02:27:29 23.11.2009 Titel:

Version 27: Kleine Korrektur in flpydsk.c
with real floppy: qemu runs 'fdir' correctly, bochs runs fdir now until return values (rev 17 works, but I do not know why), problems on real hardware still ongoing

Version 28:
changes in cmos.c for weekday (there have been problems at some hardware)
switch_context (syscall) uses 0x7E as interrupt no.
task switch now works with 0x20 or 0x7E

Erhard Henkes Mitglied 22:30:06 24.11.2009 Titel:

Version 29:
Floppy disk driver a little bit improved (qemu, virtualBox runs smoothly)

But still problems with bochs, virtualPC and real hardware.
On real hardware there are time critical steps (now transfer repeated until size=2 (512K sectors size) is returned), and there is a read-sector stop at track limit ( stops at C H S 0 1 18 (LBA 35), does not go to 1 0 2 (LBA 37) ).

Version 30:
Little bug fixes
rotating asterisk got green color

SchnippeSchnapp Mitglied 19:30:29 25.11.2009 Titel:

Verzeih die kurze Frage hier - aber weswegen denn auf einmal Englisch in nem eher deutschen Forum wo doch auch all die anderen Diskussionen auf Deutsch geführt werden?

Is das ned eher Sinnfrei?

(Und wenn die Frage hier ner reinpasst büdde abspalten oder so

)

Erhard Henkes Mitglied 23:07:08 25.11.2009 Titel:

Sorry, bei mir Gewohnheit. Merke das manchmal garnicht mehr. Hier ist übrigens Englisch und Deutsch akzeptiert.

http://www.c-plusplus.de/forum/viewtopic-var-t-is-252232.html

Zitat:

Sprachen in diesem Subforum: Deutsch und Englisch
Languages at this sub-forum: German and English

Erhard Henkes Mitglied 02:09:02 26.11.2009 Titel:

Version 31:
Floppy-Treiber etwas optimiert,
Problem in timer.c behoben (war Ursache für das fdir Problem)

Nun läuft fdir auf Bochs, VirtualBox, qemu und 2 von 3 PCs (also noch Verbesserungsbedarf); VirtualPC geht auch noch nicht

Erhard Henkes Mitglied 23:28:09 27.11.2009 Titel:

Version 32:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=32

- getCurrentSeconds() eingebaut: liefert Zeit in Sekunden seit PrettyOS-Start (allerdings ticks-abhängig, funktioniert nicht zwischen cli/sti)
- Statusleiste (status bar) implementiert; Scrolling, Cursor- und Tasksteuerung angepasst
- Floppy-Treiber beim Warten auf Interrupt und auf Read/Write-Transfer um einen Timeout (5 sec) erweitert, damit Kernel hier nicht mehr dauerhaft bei ausbleibendem Interrupt o.ä. hängen bleibt (auf 2 von 3 PCs wird das root directory mit fdir gelesen, ansonsten geht es nach 5 sec weiter im Code mit Fehlermeldung "timeout"). VirtualPC bleibt jetzt auch nicht mehr hängen, funktioniert aber noch nicht richtig bezüglich root dir Ausgabe.
Auf VMWare läuft PrettyOS auch (Aussage Cuervo).

Erhard Henkes Mitglied 20:24:42 28.11.2009 Titel:

Version 33:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=33

Auf mancher Hardware klappt das Auslesen von Floppy-Inhalten nur jedes zweite Mal (Grund noch nicht klar). Work-around:
- User-Funktion floppy_dir() und Kernel-Funktion flpydsk_read_directory() erhielten einen Rückgabewert. fdir liest nun noch ein zweites Mal, wenn der Rückgabewert keine Inhalte anzeigt.
- DMA-Puffer wird vor dem Auslesen der root dir gelöscht, damit man die echten gelesenen Inhalte und keine alten Daten sieht.
- Timeout wurde von 5 auf 2 Sekunden verkürzt.

Erhard Henkes Mitglied 05:26:10 29.11.2009 Titel:

Version 34:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=34

- time.h/time.c ergänzt, Datum/Zeit aus cmos.h/c in dieses Modul überführt
- Statusleiste: Datum und Zeit, zusätzlich vergangene Sekunden seit dem Start
- aktuelles FloppyImage.bin
- einiges wurde ausgeblendet (Ausdruck nach 'Diagnose' verlagert)

FloppyImage (im Verzeichnis 'kernel') wurde mitgeliefert, damit man die neuesten Features sofort ansehen kann, z.B. mit Qemu (batch-Datei für Windows):

Code:
qemu-system-x86_64.exe -usbdevice mouse -fda FloppyImage.bin -boot a -localtime

Code:
qemu-system-x86_64.exe -usbdevice mouse -fda FloppyImage.bin -boot a -localtime

Code:
qemu-system-x86_64.exe -usbdevice mouse -fda FloppyImage.bin -boot a -localtime

Erhard Henkes Mitglied 16:02:36 29.11.2009 Titel:

Version 35:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=35

- NULL als (void*) 0 redefiniert, wie in C üblich (vorher nur 0)
- NULL in paging.c ausgetauscht gegen 0 (wegen error: cast pointer to integer)
- itoa und reverse von K&R (siehe wikipedia), strcpy von wikipedia
- Rotierender ASCII Stern wurde umgefärbt und nach unten rechts in Statusleiste verschoben
- 2-Klausel-BSD-Lizenz und Disclaimer in os.h und ckernel.c für weitere Diskussionen erstmalig eingefügt, aber ganz unten wie abgesprochen (einmalig!)

Offenes Problem:
In char* getCurrentDateAndTime(char* pStr) muss wie folgt

C/C++ Code:
int i; for(i=0;i<80;++i){pStr[i] = 0;}

C/C++ Code:
int i; for(i=0;i<80;++i){pStr[i] = 0;}

C/C++ Code:
int i; for(i=0;i<80;++i){pStr[i] = 0;}

der als Zeiger übergebene DateAndTime-String gelöscht werden. Ansonsten geht die Ausgabe schief und das OS stürzt wegen buffer overflow ab. Der Fehler liegt nicht in strcpy oder itoa, soweit ich das bisher sehe, also entweder in der Funktion selbst oder in strcat.

Der work-around funktioniert aber gut.

Erhard Henkes Mitglied 18:41:07 29.11.2009 Titel:

Version 36:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=36

- Kleiner Bug beim Auslesen von Root Dir behoben (Punkt zwischen Name und Extension wurde immer beim ersten Mal nicht gesetzt, jetzt dann, wenn Eintrag nicht Volume Label ist)

Lob an unseren Chef-Tester Cuervo, dem aufgefallen ist, dass da BOOT2SYS steht anstelle BOOT2.SYS, wenn das Label leer war

Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/PrettyOS_rev36.PNG

Erhard Henkes Mitglied 19:30:12 29.11.2009 Titel:

Version 37:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=37

- Fehlerhaftes strcat ausgetauscht gegen Variante aus wikipedia, die strcpy und strlen einsetzt. Nun kann die for-Schleife am Anfang von getCurrentDateAndTime entfallen, die den ganzen String auf 0 setzte.

Erhard Henkes Mitglied 21:31:58 30.11.2009 Titel:

Version 38:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=38

Heute ist mal wieder Spaß angesagt:
- Modul gags.h/c mit fahrendem Zug (aus wikipedia) <--- unbedingt ansehen!

Dass dieses Modul nichts in einem "bare bone" Kernel zu suchen hat, ist mir selbstverständlich klar! Das war nur ein Test für das Feature Laufband. Ich habe eine einfache Idee - ohne großen API-Aufwand - gesucht für ein Programm, das man von der Floppy Disk laden und im User-Space laufen lassen kann. Das kam dabei heraus.

Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/FahrenderZug.PNG

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	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	#include "os.h" #include "gags.h" // Zug als Beispiel übernommen aus // http://de.wikipedia.org/wiki/ASCII-Art#Allgemeine_Beispiele // TODO: eigene ASCII-Art erzeugen char* line1 = " _______ _______ <>_<> " ; char* line2 = " (_______) \|_\|_\|_\|_\|_\|_\|\| [] [] \| .---\|'\"`\|---. " ; char* line3 = "`-oo---oo-'`-oo-----oo-'`-o---o-'`o\"O-OO-OO-O\"o' " ; void showTrain(int8_t val) { int i; char temp1,temp2,temp3; switch(val) { case 1: temp1 = line1[79]; temp2 = line2[79]; temp3 = line3[79]; for(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; k_printf(line1,46,0xE); k_printf(line2,47,0xE); k_printf(line3,48,0xE); break; default: break; } }

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	#include "os.h" #include "gags.h" // Zug als Beispiel übernommen aus // http://de.wikipedia.org/wiki/ASCII-Art#Allgemeine_Beispiele // TODO: eigene ASCII-Art erzeugen char* line1 = " _______ _______ <>_<> " ; char* line2 = " (_______) \|_\|_\|_\|_\|_\|_\|\| [] [] \| .---\|'\"`\|---. " ; char* line3 = "`-oo---oo-'`-oo-----oo-'`-o---o-'`o\"O-OO-OO-O\"o' " ; void showTrain(int8_t val) { int i; char temp1,temp2,temp3; switch(val) { case 1: temp1 = line1[79]; temp2 = line2[79]; temp3 = line3[79]; for(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; k_printf(line1,46,0xE); k_printf(line2,47,0xE); k_printf(line3,48,0xE); break; default: break; } }

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	#include "os.h" #include "gags.h" // Zug als Beispiel übernommen aus // http://de.wikipedia.org/wiki/ASCII-Art#Allgemeine_Beispiele // TODO: eigene ASCII-Art erzeugen char* line1 = " _______ _______ <>_<> " ; char* line2 = " (_______) \|_\|_\|_\|_\|_\|_\|\| [] [] \| .---\|'\"`\|---. " ; char* line3 = "`-oo---oo-'`-oo-----oo-'`-o---o-'`o\"O-OO-OO-O\"o' " ; void showTrain(int8_t val) { int i; char temp1,temp2,temp3; switch(val) { case 1: temp1 = line1[79]; temp2 = line2[79]; temp3 = line3[79]; for(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; k_printf(line1,46,0xE); k_printf(line2,47,0xE); k_printf(line3,48,0xE); break; default: break; } }

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

Version 39:

http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=39

- Laufband ("fahrender Zug") im Kernel aus Effizienzgründen entfernt (auskommentiert) :xmas1:

C/C++ Code:
// showTrain(1); // TODO: transfer to user space as elf exec format; k_printf as syscall

C/C++ Code:
// showTrain(1); // TODO: transfer to user space as elf exec format; k_printf as syscall

C/C++ Code:
// showTrain(1); // TODO: transfer to user space as elf exec format; k_printf as syscall

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

Version 40:

http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=40

- gags.h/c im Kernel entfernt
- syscalls ergänzt
- showInfo(val) testweise im User-Bereich eingebaut; Laufband-Funktion noch nicht vorhanden (TODO: separate Task)
- makefile korrigiert im User-Bereich

Badestrand Mitglied 16:54:14 12.12.2009 Titel:

Der Zug ist mega cool!

Version 41: Unterstriche in den Ordnernamen und das Präfix "k_" in Funktionsnamen entfernt.

Erhard Henkes Mitglied 16:04:01 13.12.2009 Titel:

Version 42:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=42

- getCurrentSeconds() in userlib.h/c nachgerüstet (program.c wird jetzt kompiliert) <--- Dank an Cuervo für das Auffinden dieses Fehlers
- gags.h/c im Kernel gelöscht (Funktion ist in program.c)

Zitat:

Der Zug ist mega cool!

Thanks!

Badestrand Mitglied 17:43:38 13.12.2009 Titel:

Version 43:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=43

- In start.asm aus user/user_program_c das Ausnullen der BSS entfernt, ist afaik sowieso schon auf 0 und ergab bei mir wegen Integer-Underflow in ecx 'nen fiesen Fehler.

- Noch zwei oder drei Funktionen mit "k_"-Präfix gefunden und korrigiert.

- kernel/gdt.inc gelöscht, da anscheinend ungenutzt (dann auch stage2_bootloader/gdt2.inc wieder in gdt.inc umbenannt)

- mingw32-make.exe, nasmw.exe, CreateFloppyImage.exe, BootDisk2BootStick.exe, dd.exe und bochs.bxrc in Ordner "tools"

- Das Erstellen des Images, Entfernen aller .o-Dateien jetzt in globalem makefile

- Aufrufen von Bochs, Qemu oder das Bauen der Diskette in Batch-File. Die Batch-Datei kann "einfach so" aufgerufen werden, dann kompiliert alles. Wird als Parameter "bochs" übergeben, wird das Image in Bochs ausgeführt. Wird (evtl zusätzlich) "disc" übergeben, wird alles auf die Diskette geschrieben. Für Qemu und anderes können wir auch noch was basteln. Und das ganze noch als Shellskript für die Linuxer schreiben, ist bisher nur als Stub vorhanden.

TODO:
Der Stack der User-Prozesse muss vom Kernel gesetzt werden, jeder braucht auch seinen eigenen Stack. In unserem User-Programm zumindest wird der Stack händisch auf 0x60000 gesetzt. Erhard, du kennst dich in dem Tasking-Modul doch aus, magst du mal probieren, jedem Prozess seinen eigenen Stack zu geben? Irgendwo unter 0xC0000000 oder so..

@Erhard: Wird "quickformat_Floppy_A.bat" noch gebraucht?

Badestrand Mitglied 17:58:39 13.12.2009 Titel:

Version 44 & 45: Minimale Änderungen. U.a. die Linux-Version von CreateFloppyImage hinzugefügt. Ging aber nicht so einfach, weil einmal ein Ordner mit demselben Namen existiert hatte, schien SVN zu stören. Egal, es heißt jetzt CreateFloppyImage2.

Erhard Henkes Mitglied 18:52:57 13.12.2009 Titel:

Version 45 baut so nicht auf:

Zitat:

G:\OSDev\PrettyOS\trunk\Source>tools\mingw32-make OS=WINDOWS
nasmw -f bin stage1_bootloader/boot.asm -Istage1_bootloader/ -o stage1_bootloader/boot.bin
nasmw -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage1_bootloader/boot2.bin
rm *.o -f
i586-elf-gcc user/user_program_c/*.c -c -Iuser/user_program_c -Werror -Wall -O -ffreestanding -fleading-underscore -nostdlib -nostdinc -fno-builtin
i586-elf-ld *.o -T user/user_program_c/user.ld -Map user/user_program_c/kernel.map -nostdinc -o user/user_program_c/program.elf
c:\crosstools\bin\i586-elf-ld.exe: warning: cannot find entry symbol _start; defaulting to 01400000
rm *.o -f
tools/make_initrd user/init_rd_img/test1.txt file1 user/init_rd_img/test2.txt file2 user/init_rd_img/test3.txt file3 user/user_program_c/program.elf shell
writing file user/init_rd_img/test1.txt->file1 at 0x1304
writing file user/init_rd_img/test2.txt->file2 at 0x1327
writing file user/init_rd_img/test3.txt->file3 at 0x134a
writing file user/user_program_c/program.elf->shell at 0x1910
mv initrd.dat kernel/initrd.dat
rm *.o -f
i586-elf-gcc kernel/*.c -c -Ikernel/include -std=c99 -march=i386 -mtune=i386 -Werror -Wall -O -ffreestanding -fleading-underscore -nostdlib -nostdinc -fno-builtin -fno-stack-protector -Iinclude
nasmw -O32 -f elf kernel/data.asm -Ikernel/ -o data.o
nasmw -O32 -f elf kernel/flush.asm -Ikernel/ -o flush.o
nasmw -O32 -f elf kernel/interrupts.asm -Ikernel/ -o interrupts.o
nasmw -O32 -f elf kernel/kernel.asm -Ikernel/ -o kernel.o
nasmw -O32 -f elf kernel/process.asm -Ikernel/ -o process.o
i586-elf-ld *.o -T kernel/kernel.ld -Map kernel/kernel.map -nostdinc -o kernel/kernel.bin
rm *.o -f
tools/CreateFloppyImage2 PrettyOS FloppyImage.bin stage1_bootloader/boot.bin stage2_bootloader/boot2.bin kernel/kernel.bin
Cannot open the file 'stage2_bootloader/boot2.bin'
mingw32-make: *** [ckernel] Error -1

Wenn ich build.bat disc in der Konsole eingebe, wird boot2.sys nicht kopiert.

boot2.bin landet in stage1_bootloader :xmas2:

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

Notwendige Korrektur:

makefile, , Zeile 26/27:

Code:
boot2: $(wildcard $(STAGE2DIR)/.asm $(STAGE2DIR)/.inc) $(NASM) -f bin $(STAGE2DIR)/boot2.asm -I$(STAGE2DIR)/ -o $(STAGE2DIR)/boot2.bin

Code:
boot2: $(wildcard $(STAGE2DIR)/.asm $(STAGE2DIR)/.inc) $(NASM) -f bin $(STAGE2DIR)/boot2.asm -I$(STAGE2DIR)/ -o $(STAGE2DIR)/boot2.bin

Code:
boot2: $(wildcard $(STAGE2DIR)/.asm $(STAGE2DIR)/.inc) $(NASM) -f bin $(STAGE2DIR)/boot2.asm -I$(STAGE2DIR)/ -o $(STAGE2DIR)/boot2.bin

boot.asm, Zeile 264:

Assembler Code:
ImageName db "BOOT2 BIN'

Assembler Code:
ImageName db "BOOT2 BIN'

Assembler Code:
ImageName db "BOOT2 BIN'

boot.asm, Zeile 268:

Assembler Code:
msgFailure db 0x0D, 0x0A, "BOOT2.BIN MISSING', 0x0D, 0x0A, 0

Assembler Code:
msgFailure db 0x0D, 0x0A, "BOOT2.BIN MISSING', 0x0D, 0x0A, 0

Assembler Code:
msgFailure db 0x0D, 0x0A, "BOOT2.BIN MISSING', 0x0D, 0x0A, 0

boot2.asm, Zeile 26:

Assembler Code:
msgFailure db 0x0D, 0x0A, "Missing KERNEL.BIN', 0x0D, 0x0A, 0x0A, 0

Assembler Code:
msgFailure db 0x0D, 0x0A, "Missing KERNEL.BIN', 0x0D, 0x0A, 0x0A, 0

Assembler Code:
msgFailure db 0x0D, 0x0A, "Missing KERNEL.BIN', 0x0D, 0x0A, 0x0A, 0

Dann startet aber der Kernel immer noch nicht! :confused:

Erhard Henkes Mitglied 20:03:34 13.12.2009 Titel:

Version 46:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=46

Die neuen Bezeichnungen boot2.bin und kernel.bin wurden überall eingebaut und der Fehler im Makefile behoben.

Der Kernel wird aber noch nicht gestartet! :confused:

Erhard Henkes Mitglied 20:45:26 13.12.2009 Titel:

Version 47:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=47

Nun überall Großschrift in den asm für die Dateinamen (BL1, BL2)
Alles auf BIN gesetzt (nicht mehr SYS)
Fehler im makefile berichtigt: start.asm (user) wurde nicht assembliert

Nun gibt es einen ASSERTION Fehler:
ASSERTION FAILED((const void*)(header->entry) == USERCODE_VADDR) at kernel/elf.c
:153OPERATING SYSTEM HALTED

Badestrand Mitglied 21:18:42 13.12.2009 Titel:

Sorry für die Verwirrung! Bin auch gerade online gegangen weil ich die Fehler bemerkt hatte, beim Übertragen auf den INet-Rechner ist wohl was schief gelaufen.

Die meisten Sachen hast du ja erfolgreich behoben, die start.asm aus dem User-Prozess muss noch mitkompiliert werden (ist irgendwie aus dem Makefile rausgeflutscht) und ein assert muss aus elf.c raus:
ASSERT( (const void*)(header->entry) == USERCODE_VADDR );
Das User-Programm startet nämlich nicht bei 0x01400000, sondern 0x200 Bytes später. Warum auch immer. Funktioniert aber trotzdem.
=> Version 48

Erhard Henkes Mitglied 21:25:20 13.12.2009 Titel:

Folgendes geht bei mir lokal:

- ASSERTION in Zeile 153 auskommentiert, damit die shell startet (Grund für diese Maßnahme momentan unklar)
- readelf und batch-Datei in User
- floppy_build.bat für direktes Starten des Build-Prozesses im Explorers

Momentan kann ich nicht committen wegen Konflikt

Super! Badestrand und ich haben das gleiche gemacht. Ich schieb mal meine Luxusklasse-Ausführung für faule Windows-Anwender hinterher:

Version 49
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=49

In bochs bevorzuge ich übrigens

Zitat:

floppya: 1_44=a:, status=inserted

Vielleicht sollte man auf Dauer zwei verschiedene versionen anbieten.

Erhard Henkes Mitglied 20:24:19 14.12.2009 Titel:

Version 50:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=50

Nun ist BOOT2.BIN und KERNEL.BIN im makefile groß geschrieben, damit es auch unter Linux problemlos läuft.

elf.c:
Zeile 129: ASSERT( header->phnum == 1 );
Zeile 152: ASSERT( (const void*)(ph->vaddr) == USERCODE_VADDR );
müssen evtl. unter Linux noch auskommentiert werden.

In Windows klappt das mit dem Cross-Compiler auch mit den ASSERTs.

Erhard Henkes Mitglied 02:09:56 23.12.2009 Titel:

Version 51: (badestrand)
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=51
- Run the build.bat file with qemufloppy or qemuimage as parameter to start qemu.

Version 52: (Erhard Henkes)
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=52
- Systemfrequenz auf 1000 Hz erhöht
- getCurrentMilliseconds() ergänzt (syscall)
- "Zug" bewegt sich alle 20 Millisekunden flüssig nach vorne

Es war mir ein Bedürfnis den "Zug" (Beispielanwendung für das dreizeilige Laufband) zu :xmas1: Weihnachten :xmas2: betriebsbereit zu haben. Er läuft im User-Bereich (z.Z. noch in der Shell) lässt sich durch den neuen Millisekunden-Timer und die neue System-Frequenz von 1000 Hz ziemlich rasant über den Bildschirm bewegen. Leider ist er noch keine eigene Task. Daher kann man ihn z.B. mit langwierigen Aktionen wie 'fdir' ausstoppen.

Anstelle des Zuges könnte auch Ihre Werbung stehen.

Erhard Henkes Mitglied 19:41:35 23.12.2009 Titel:

Version 53:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=53

- Folgendes auskommentiert in elf.c:
Zeile 11: static const void* USERCODE_VADDR = (void*)0x01400000;
Zeile 129: ASSERT( header->phnum == 1 );
Zeile 152: ASSERT( (const void*)(ph->vaddr) == USERCODE_VADDR );

- Folgendes ergänzt:
Zu den CFLAGS noch "-m32" hinzufügen
In die Linkerscripte (kernel.ld, user.ld) "OUTPUT_ARCH(i386)" hinzufügen

Nun sollte es von Seiten Linux und 64-Bit keine Barrieren geben. Erste Tests bestätigen dies!

http://www.cyberciti.biz/tips/compile-32bit-application-using-gcc-64-bit-linux.html

Erhard Henkes Mitglied 12:23:04 24.12.2009 Titel:

Version 54:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=54

- build.sh für Linux ergänzt
- tools/bochsrc ergänzt
- Zug auf vielfachen Wunsch etwas ausgebremst (40 Zeichen/sec) :xmas1:

Der "Zug" steht nur stellvertretend für das zukünftige Informationsband, in dem Diagnosedaten angegeben werden. Wir wollen ja ein Lehr-OS schaffen.

Erhard Henkes Mitglied 13:38:50 25.12.2009 Titel:

Version 55:

http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=55

-fno-pic im makefile ergänzt
in userlib.c __asm__ anstelle asm

Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/Rev55.PNG

Erhard Henkes Mitglied 11:50:56 16.01.2010 Titel:

Version 56:

http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=56

- flpydsk_read_directory() nach fat12.c ausgelagert, da spezifisch für Dateisystem FAT12

in fat12.h/c sollen die FAT12-spezifischen Funktionen zur Dateiverwaltung auf Floppy Disk abgelegt werden.

Erhard Henkes Mitglied 20:50:22 24.01.2010 Titel:

Rev. 57:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=57

- fat12.h/.c: Quickformat für die FloppyDisk implementiert ("fformat")
läuft noch nicht fehlerfrei (FAT2 wird nicht analog zu FAT1 geschrieben), funktioniert aber bereits. Kann auch mit FloppyImage.bin getestet werden. Als Hex-Editor empfehle ich für die echte Floppy den Hex-Editor Neo, da dieser direkt Volumes auslesen kann.

Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/Rev57.PNG

Leider fehlte in dieser Version (vielleicht auch schon vorher in 56) die fat12.c!

Erhard Henkes Mitglied 20:58:51 24.01.2010 Titel:

Rev. 57a:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=58

- fat12.h/.c: Quickformat für die FloppyDisk implementiert ("fformat")
läuft noch nicht fehlerfrei (FAT2 wird nicht analog zu FAT1 geschrieben), funktioniert aber bereits. Kann auch mit FloppyImage.bin getestet werden. Als Hex-Editor empfehle ich für die echte Floppy den Hex-Editor Neo, da dieser direkt Volumes auslesen kann.

Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/Rev57.PNG

Diese Version sollte komplett sein.

Erhard Henkes Mitglied 23:45:25 24.01.2010 Titel:

Rev. 59:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=59

fat.c: FAT2 nun analog FAT1

- Noch eine Menge Optimierungspotential
- date/time fehlt noch

Erhard Henkes Mitglied 00:55:31 25.01.2010 Titel:

Rev. 60:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=60

In fat12.c - testweise - noch ein "Preformat" eingefügt, das die ersten 32 Sektoren komplett auf eine Zahl (0xAA) setzt, bevor die eigentliche Fortmatierung startet.
Die Routine muss noch auf das Track-weise Schreiben (18 Sektoren auf einmal) angepasst werden.

EDIT: das fformat ist bisher leider nur qemu-fähig. Auf echten PCs wird bisher nicht formatiert. Fehler wird durch Debuggen (ohne Preformat) gesucht. Die Funktion steigt bereits ganz vorne aus:

C/C++ Code:
/// write bootsector retVal = flpydsk_write_boot_sector(&b); if(retVal != 0) { printformat("E_Disk - flpydsk_write_boot_sector"); return E_DISK; }

C/C++ Code:
/// write bootsector retVal = flpydsk_write_boot_sector(&b); if(retVal != 0) { printformat("E_Disk - flpydsk_write_boot_sector"); return E_DISK; }

C/C++ Code:
/// write bootsector retVal = flpydsk_write_boot_sector(&b); if(retVal != 0) { printformat("E_Disk - flpydsk_write_boot_sector"); return E_DISK; }

Problem liegt hier (um timeout-Routine ergänzt für Fehlersuche):

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	int32_t flpydsk_write_sector_ia( int32_t i, void* a) { memcpy((void)DMA_BUFFER, a , 0x200); uint32_t timeout = 2; // limit* int32_t retVal = 0; while( flpydsk_write_sector(i) != 0 ) { retVal = -1; timeout--; printformat("error write_sector. left: %d\n",timeout); if(timeout<=0) { printformat("timeout\n"); break; } } if(retVal==0) { printformat("success write_sector.\n"); } return retVal; }

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	int32_t flpydsk_write_sector_ia( int32_t i, void* a) { memcpy((void)DMA_BUFFER, a , 0x200); uint32_t timeout = 2; // limit* int32_t retVal = 0; while( flpydsk_write_sector(i) != 0 ) { retVal = -1; timeout--; printformat("error write_sector. left: %d\n",timeout); if(timeout<=0) { printformat("timeout\n"); break; } } if(retVal==0) { printformat("success write_sector.\n"); } return retVal; }

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	int32_t flpydsk_write_sector_ia( int32_t i, void* a) { memcpy((void)DMA_BUFFER, a , 0x200); uint32_t timeout = 2; // limit* int32_t retVal = 0; while( flpydsk_write_sector(i) != 0 ) { retVal = -1; timeout--; printformat("error write_sector. left: %d\n",timeout); if(timeout<=0) { printformat("timeout\n"); break; } } if(retVal==0) { printformat("success write_sector.\n"); } return retVal; }

Das Problem mit echter Hardware liegt also in flpydsk_write_sector(i).
qemu läuft anstandslos.

Ich lade diese Version mit Fehlerroutine hoch. Vielleicht findet jemand die Lösung für flpydsk_write_sector(i).

Rev. 61:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=61

Erhard Henkes Mitglied 02:04:06 27.01.2010 Titel:

Rev. 62:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=62

Der seek-Vorgang auf realer Hardware läuft nun so ab, dass man die Analyse des Schreibvorgangs auf realer Hardware starten kann (Meldungen sind noch merkwürdig).
Während auf qemu mit echter Floppy alles perfekt läuft, sieht das auf realer Hardware noch sehr verwirrend aus. Das Format-Ergebnis ist ebenfalls nicht ok.
Da stimmt noch etwas beim 'seek' nicht.
Siehe: http://www.c-plusplus.de/forum/viewtopic-var-t-is-253791-and-start-is-10.html

Erhard Henkes Mitglied 10:04:27 27.01.2010 Titel:

Rev. 63:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=63

Noch einige Änderungen in flpydsk.c (seek, ...), allerdings läuft der Cylinder-Seek-Prozess auf echter Hardware beim Schreiben nicht ordnungsgemäß.

Hat jemand eine Idee? :confused:

Erhard Henkes Mitglied 05:38:48 29.01.2010 Titel:

Rev. 64:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=64

In flpydsk.c wurde in das seek ein calibrate (setzen auf cyl. 0) eingeschoben. Nun funktioniert das Sektor-Schreiben auf Floppy Disk auch mit echter Hardware. Die Vorgänge müssen allerdings noch massiv bezüglich Effizienz (zu langsam, Motor on/off optimieren) und Effektivität (viele seltsame Zeichen bei fdir) optimiert werden. Aber der seek-Fehler ist nun hoffentlich behoben.

Rev. 65:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=65
calibrate ohne motor on/off

Rev. 66:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=66
motor on/off beim Schreiben in Format ausgeschaltet, dadurch verläuft die Formatierung deutlich schneller.

Erhard Henkes Mitglied 18:07:35 30.01.2010 Titel:

Rev 67:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=67
timeout in read_sector von 2 Sekunden auf 2 mal umgestellt (für langsame Rechner)

Danke an Cuervo für die Tests mit dem "lahmen" Schulrechner.

Erhard Henkes Mitglied 04:19:16 31.01.2010 Titel:

Rev.68:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=68

fformat: Änderung im Algorithmus von "sectorenweisem" Schreiben auf Schreiben von ganzen Tracks. Nun ist das Quickformat (Bootsector, FAT1 u. FAT2, RootDir) viel schneller. Bei manchen Disketten gibt es die Fehlermeldung: No ID address mark
Ursache bisher nicht klar (hat vielleicht etwas mit quickformat zu schaffen).
Frage: was muss man machen, damit die Diskette als brauchbar/lesbar akzeptiert wird (nur wichtig für Lesen mit Hex-Editor via Windows-Laufwerk a: )

Links:
http://technet.microsoft.com/en-us/library/cc776720%28WS.10%29.aspx
http://www.microsofttranslator.com/BV.aspx?ref=CSS ....... =http://support.microsoft.com/kb/130627/en-us?fr=1

Zitat:

When you quick format an unformatted floppy disk, correct data structures are placed; however, no media test and verification of cluster usability are performed.

Was ist der "media test"?
Wie wird die "verification of cluster usability" durchgeführt?
Vor allem: wie wird dies auf der Diskette dargestellt? (dies könnte man ja antäuschen.
Die normale Kennung für Format im Datenbereich seit MSDOS ist 0xF6.

Erhard Henkes Mitglied 12:35:28 31.01.2010 Titel:

Die Frage von erik.vikinger bezüglich Floppy vs USB wurde wegen der Grundsätzlichkeit für die weitere Entwicklung abgetrennt: http://www.c-plusplus.de/forum/viewtopic-var-t-is-260047.html

Erhard Henkes Mitglied 17:09:19 31.01.2010 Titel:

Rev. 69:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=69

- Nur noch wichtige Meldungen beim Formatieren
- kleine Verbesserungen in fat12.c

Erhard Henkes Mitglied 22:50:23 31.01.2010 Titel:

Rev. 70:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=70

Vor und nach dem Formatieren wird der Inhalt des Root Directories testweise gezeigt (jeweils 2 Sekunden Pause zwischen zwei Einträgen).

Anmerkung: Test von Funktionen als Vorbereitung auf den Ladevorgang.

Erhard Henkes Mitglied 00:53:32 02.02.2010 Titel:

Rev. 71:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=71

Zwischenschritte:
1) name.ext (8+3) in ROOT DIRECTORY finden (Bsp. 'KERNEL.BIN'), TODO: variabel via shell machen
2) FAT1 parsen (TODO: durch motor on/off beim read_sector(...) noch zu langsam, dadurch aber sehr gut verfolgbar)
vgl. mit http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId839021

Der Einfachheit halber wurde dies als ///TEST ... ///TEST in 'fformat' vor dem eigentlichen Quickformatvorgang eingehängt.

Erhard Henkes Mitglied 02:04:56 03.02.2010 Titel:

Rev. 72:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=72

Erkennung von Filename/extension stabilisiert (bei einigen Versuchen hatte es Probleme gegeben. strncpy ok?)

FAT parsen beschleunigt.

Später soll man z.B. 'kernel.bin' in der shell eingeben. Dann wird zunächst in der shell selbst nach dem Befehl gesucht und falls nicht vorhanden, das File auf der Floppy Disk gesucht und entweder geladen/ausgeführt (z.B. xxx.elf) oder nach dem Finden als nicht ausführbar dargestellt (z.B. bin oder sys oder ...).

Erhard Henkes Mitglied 07:56:50 04.02.2010 Titel:

Rev. 73:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=73

Zwischenschritt: File wird probeweise mittels FirstCluster und zugehöriger FAT-Chain in einem Array file[...] aufgebaut.

Der Algorithmus ist allerdings nicht brauchbar, da der zweite Cluster via FAT-entry[i] gefunden wird (siehe Rev.74).

Erhard Henkes Mitglied 01:42:30 05.02.2010 Titel:

Rev. 74:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=74

Zwischenschritt:
Algorithmus zum Auffinden der Cluster-Kette mittels 2nd_Cluster = FAT[1st_Cluster] als Start.

1) File 'program.elf' auf die Diskette kopieren, da dieses File gesucht wird
2) Testet den Algo mittels 'fformat'

Erhard Henkes Mitglied 01:52:56 05.02.2010 Titel:

Rev. 75:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=75

Zwischenschritt:
Suche nach 'kernel.bin' und "Laden" in ein Array file[...].
Noch immer in den fformat-Befehl eingebunden.

Nächster Schritt: Auslagern in eigene Load-Funktion und Start via Eingabe des Filenamens in der Shell.

Erhard Henkes Mitglied 19:28:07 05.02.2010 Titel:

Rev. 76:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=76

fdir: file ohne Extension nun auch ohne Punkt
makefile: rm -f .o
fat12.c: algorithmus korrigiert, FAT-Clusterkette wird zu langsam gelesen

Problem: Unterschiedliche Inhalte in File-Array bei real PC (1./2. Cluster identisch eingelesen) und qemu (klappt gut). Lesevorgang? DMA?

Anmerkung:
noch bei 'fformat' testweise untergebracht, bis es richtig läuft, dann separate Load-Funktion mit Start durch die shell.

Erhard Henkes Mitglied 00:10:33 06.02.2010 Titel:

Rev. 77:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=77

Meilenstein: (noch eingebettet in 'fformat')
Separate Load-Funktion: flpydsk_load(char* name, char* ext):

In dieser Version gelingt erstmalig das Laden und Ausführen einer Datei (hello.elf, 3 Cluster) von Floppy Disk!

Screenshot:

http://www.henkessoft.de/OS_Dev/Bilder/Load_Process_from_Floppy.PNG
(Anmerkung: Der dritte Cluster besteht nicht nur aus lauter Nullen, sondern enthält genau ab Byte 21 Daten unterschieldich zu 0x00. Es werden allerdings jeweils die ersten 20 Byte eines Clusters zur Kontrolle angezeigt. Der beste Beweis, dass der Vorgang klappt, ist selbstverständlich, wenn ein Programm ordnungsgemäß startet.)

Erhard Henkes Mitglied 03:14:46 06.02.2010 Titel:

Rev. 78:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=78

Nun kann man den Dateinamen, z.B. "hello.elf" oder einfach "hello", auch "hello." direkt in der Shell eingeben.

Läuft allerdings noch nicht völlig rund - Zeichendarstellung verschoben, ab und zu #PF(beim Ausführen des Programms?) - aber es ist unser Einstieg in die bunte Landschaft der User-Programme, mal abgesehen von der im Kernel mittels "incbin" mitgelieferten Shell.

Zur Zeit kann nur das elf-Format "seziert" werden. Ideen für kleine Programme sind bereits genügend vorhanden.

Die hoffentlich ausgeführte Datei befindet sich übrigens hier:
...\PrettyOS\trunk\Source\user\user_test_c\
Sourcecode:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	1 2 3 4 5 6 7 8 9 10	#include "userlib.h" int main() { settextcolor(12,0); puts("Hello, Pretty Operating System World!\n"); puts("This piece of software was loaded by PrettyOS from your floppy disk.\n"); settextcolor(15,0); return 0; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	#include "userlib.h" int main() { settextcolor(12,0); puts("Hello, Pretty Operating System World!\n"); puts("This piece of software was loaded by PrettyOS from your floppy disk.\n"); settextcolor(15,0); return 0; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	#include "userlib.h" int main() { settextcolor(12,0); puts("Hello, Pretty Operating System World!\n"); puts("This piece of software was loaded by PrettyOS from your floppy disk.\n"); settextcolor(15,0); return 0; }

Nun können wir entsprechende User-Programmideen umsetzen (makefile und Umgebung muss noch entsprechend erweitert werden. Ich habe das Programm hello.elf einfach durch Substitution von program.c und anschließendem Rücktausch erzeugt, denn wir müssen ja start.asm und das passende Linkerskript beim Compilieren/Linken verwenden.). Damit lenkt sich der Blick auch auf die vorhandene und noch zu erweiternde API (syscalls) und die magere/fehlende C-Bibliothek im User-Bereich.

Vielleicht findet jemand die Gründe, warum es manchmal zu #PF kommt und warum echte Hardware in einigen Fällen (auf meinem Entwicklungsrechner von ca. 2004 funktioniert es) noch Lese-Probleme macht, während es dagegen mit qemu problemlos funktioniert.

Am besten mit qemu probieren (FloppyImage.bin wird ja mitgeliefert bzw. beim Compilieren erzeugt), da es auf echter Hardware noch eindeutig zu wenig performant abläuft (im 5-10 Minuten-Bereich).

Erhard Henkes Mitglied 14:28:28 06.02.2010 Titel:

Rev. 79:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=79

Verbesserungen bei der Eingabe in der Shell

Erhard Henkes Mitglied 15:28:34 06.02.2010 Titel:

Rev. 80:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=80

Verbesserungen in fat12.c

Erhard Henkes Mitglied 00:01:28 07.02.2010 Titel:

Rev. 81:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=81

shell (program.c): Leereingabe abgefangen (!)
flpydsk.c: delay von 50 ms bei Lese-/Schreibvorgängen auf null reduziert

Simulation mit FloppyImage und qemu läuft nun rapide.
Echte Floppy mit qemu etwas beschleunigt.

Erhard Henkes Mitglied 01:29:16 07.02.2010 Titel:

Rev. 82:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=82

timer.c: Systemfrequenz reduziert von 1000 Hz (wie bei Linux) auf 100 Hz (wie früher; führt wieder zu geordneter Bildschirm-Darstellung)
fat.c: log_task_list() vor und nach dem auszuführenden Programm dargestellt, damit die Tasks demonstriert werden

Screenshot:
http://www.henkessoft.de/OS_Dev/Bilder/Rev82.PNG

Rev. 83:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=83

Zwischenversion nur für Fehlersuche (Probleme in neuestem Sun Virtual Box und einigen qemu-Versionen)

Rev. 84:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=84
Zusätzlich Erstellungswerkzeuge für HELLO.ELF im Unterordner für eigene Experimente. TODO: alles abändern auf übergeordnet Ordner (nasm, make, userlib, ...).

Erhard Henkes Mitglied 03:25:32 08.02.2010 Titel:

Rev. 85:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=85

Veränderungen in program.c

Läuft bei mir absturzfrei mit qemu, Sun Virtual Box, MS Virtual PC (dort allerdings Leseprobleme von Floppy)

Bitte prüfen!

Die roten Punkte stellen die Durchläufe durch die innere Schleife der shell dar.
Hier kann man das abstellen:

C/C++ Code:
1 2 3 4 5 6 7 8	1 2 3 4 5 6 7 8	while(true) { ///TEST settextcolor(4,0); puts("."); settextcolor(15,0); ///TEST ...

C/C++ Code:
1 2 3 4 5 6 7 8	while(true) { ///TEST settextcolor(4,0); puts("."); settextcolor(15,0); ///TEST ...

C/C++ Code:
1 2 3 4 5 6 7 8	while(true) { ///TEST settextcolor(4,0); puts("."); settextcolor(15,0); ///TEST ...

TODO: Gibt man "kernel.bin" ein, so wird nur ".bin" gesucht (geht nur mit "kernel .bin")

Die Systemfrequenz wurde wieder auf 1000 Hz eingestellt, da dies anfänglich Vorteile mit Sun VB brachte.

Cuervo Mitglied 08:40:24 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^^

Erhard Henkes Mitglied 20:55:05 08.02.2010 Titel:

Rev. 86:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=86

- getch() in user.c umgebaut, so dass auf eine Eingabe gewartet wird.

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	1 2 3 4 5 6 7 8 9 10	unsigned char getch() { unsigned char ret; do { __asm__ volatile( "int $0x7F" : "=a"(ret): "a"(6) ); } while(ret==0); return ret; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	unsigned char getch() { unsigned char ret; do { __asm__ volatile( "int $0x7F" : "=a"(ret): "a"(6) ); } while(ret==0); return ret; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	unsigned char getch() { unsigned char ret; do { __asm__ volatile( "int $0x7F" : "=a"(ret): "a"(6) ); } while(ret==0); return ret; }

- DEBUG-Ausgaben entfernt (motor on/off; rote Punkte)

@Cuervo: bei meinen PCs läuft es

anubis2k5 Mitglied 21:19:08 08.02.2010 Titel:

Revision 86: bei Eingabe von HELLO.ELF wird -->.ELF<-- nicht gefunden.
Bei Eingabe von "hello" hingegen funktioniert es - gewollt?!

Nachtrag: Besteht die Möglichkeit einen extra Threat zum Testen der Revisionen zu öffnen? Ich glaube hier wird's langsam voll...

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:30:41 08.02.2010 Titel:

Im Unterverzeichnis ...\PrettyOS\trunk\Source\user\user_test_c build.bat ausführen.

Code:
mingw32-make main

Code:
mingw32-make main

Code:
mingw32-make main

==> HELLO.ELF

Erhard Henkes Mitglied 22:17:55 09.02.2010 Titel:

Rev. 87:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=87

Zwischenschritt (leider noch Fehler enthalten) mit Bitte um Fehlersuche.

task.c: exit als syscall eingebaut (beendet Prozess)
user.c: gets eingefügt

User-Programm mit gets (altes Programm in "zzz_alternative_User-Programme", falls die Fehler nerven, das sollte wiederholbarer laufen)

Systemfrequenz: 100 Hz

Diese Version sollten wir nun erstmal stabilisieren, da ich an mehreren Stellen kleine Ungenauigkeiten vermute, die nun zuschlagen.

Bei MT kann es auch zu races kommen, sodass wir noch einiges gegeneinander abschotten müssen.

Erhard Henkes Mitglied 00:22:43 11.02.2010 Titel:

Rev 88:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=88

Zwischenschritt mit Bitte um Fehlersuche / Ideen.

Diagnose aktiviert (PID der tasks werden angezeigt)

Absturz bei Überschreiten von exit (wird durch test-Funktion angezeigt) in start.asm verhindert durch jmp $

User-Programm mit gets <--- richtig schlimm, lange namen eingeben

Systemfrequenz: 10 Hz

Was muss durch cli/sti abgeschottet werden?
Wo sind kritische Abschnitte notwendig?

Erhard Henkes Mitglied 02:07:17 11.02.2010 Titel:

Rev. 89:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=89

Fehler gefunden! Wie erwartet im Multitasking.

Während der Ausführung von gets wurde der task gewechselt. Damit fing die shell Zeicheneingaben und vor allem das ENTER (Line Feed: 10) des User-Programms ab, das dann auf das Ende des Strings wartete.

Abhilfe: Das Taskswitching wurde während gets(...) deaktiviert (wohl keine dauerhafte Lösung). Hierzu wurde ein syscall settaskflag geschaffen.

siehe: task.c, syscall.c, userlib.c

Wenn man das nachvollziehen will:
Diagnose in os.h aktivieren, dann sieht man die PID der Tasks. Einfach in gets das taskswitching zulassen.

Erhard Henkes Mitglied 22:31:02 11.02.2010 Titel:

Rev. 90:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=90

Fehlerbeseitigungen:
task.c: in exit() sofort task-switch nach sti(), damit der Prozess nicht hinter exit gelangen kann.
interrupts.asm: 0x7E war dort nicht eingetragen in die IDT (--> #GP)! Danke an XanClic für diesen Hinweis!

Erhard Henkes Mitglied 23:45:58 11.02.2010 Titel:

Rev. 91
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=90

userlib.h/c: itoa, atoi
Beispielprogramm hello.elf mit Collatz-Folge (3n+1)

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	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	#include "userlib.h" int main() { char s[1000]; unsigned long start; // Beginn der Berechnung bei 'start' unsigned long end; // Ende der Berechnung bei 'end' unsigned long zahl; // Element der Folge unsigned long i,j; // Zählvariable für die Folgenlänge settextcolor(11,0); puts("--------------------------------------------------------------------\n"); puts("Bitte geben Sie ihren Namen ein:\n"); gets(s); puts("This piece of software was loaded by PrettyOS from the floppy disk of "); puts(s); putch('\n'); puts("--------------------------------------------------------------------\n"); puts("--- Collatz-Folge 3n+1 ---\n"); puts("--------------------------------------------------------------------\n"); /************************* Eingabebereich *************************/ puts("Erste Zahl: "); gets(s); start = atoi(s); puts("Letzte Zahl: "); gets(s); end = atoi(s); /************************* Eingabebereich *************************/ for(j=start; j<end+1; j++) { zahl=j; i=1; putch('\n'); itoa(j,s); // begin value puts(s); putch(' '); while(zahl != 1) // test on cycle 4-2-1 { if( zahl % 2 == 0 ) zahl /= 2 ; // Collatz else zahl = 3 * zahl + 1 ; // Collatz itoa(zahl,s); puts(s); // element of the series putch(' '); i++ ; } if(zahl == 1) { puts("\tH(n): "); itoa(i,s); puts(s); // H(n) length of the series putch('\n'); } } settextcolor(15,0); return 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 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	#include "userlib.h" int main() { char s[1000]; unsigned long start; // Beginn der Berechnung bei 'start' unsigned long end; // Ende der Berechnung bei 'end' unsigned long zahl; // Element der Folge unsigned long i,j; // Zählvariable für die Folgenlänge settextcolor(11,0); puts("--------------------------------------------------------------------\n"); puts("Bitte geben Sie ihren Namen ein:\n"); gets(s); puts("This piece of software was loaded by PrettyOS from the floppy disk of "); puts(s); putch('\n'); puts("--------------------------------------------------------------------\n"); puts("--- Collatz-Folge 3n+1 ---\n"); puts("--------------------------------------------------------------------\n"); /************************* Eingabebereich *************************/ puts("Erste Zahl: "); gets(s); start = atoi(s); puts("Letzte Zahl: "); gets(s); end = atoi(s); /************************* Eingabebereich *************************/ for(j=start; j<end+1; j++) { zahl=j; i=1; putch('\n'); itoa(j,s); // begin value puts(s); putch(' '); while(zahl != 1) // test on cycle 4-2-1 { if( zahl % 2 == 0 ) zahl /= 2 ; // Collatz else zahl = 3 * zahl + 1 ; // Collatz itoa(zahl,s); puts(s); // element of the series putch(' '); i++ ; } if(zahl == 1) { puts("\tH(n): "); itoa(i,s); puts(s); // H(n) length of the series putch('\n'); } } settextcolor(15,0); return 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 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	#include "userlib.h" int main() { char s[1000]; unsigned long start; // Beginn der Berechnung bei 'start' unsigned long end; // Ende der Berechnung bei 'end' unsigned long zahl; // Element der Folge unsigned long i,j; // Zählvariable für die Folgenlänge settextcolor(11,0); puts("--------------------------------------------------------------------\n"); puts("Bitte geben Sie ihren Namen ein:\n"); gets(s); puts("This piece of software was loaded by PrettyOS from the floppy disk of "); puts(s); putch('\n'); puts("--------------------------------------------------------------------\n"); puts("--- Collatz-Folge 3n+1 ---\n"); puts("--------------------------------------------------------------------\n"); /************************* Eingabebereich *************************/ puts("Erste Zahl: "); gets(s); start = atoi(s); puts("Letzte Zahl: "); gets(s); end = atoi(s); /************************* Eingabebereich *************************/ for(j=start; j<end+1; j++) { zahl=j; i=1; putch('\n'); itoa(j,s); // begin value puts(s); putch(' '); while(zahl != 1) // test on cycle 4-2-1 { if( zahl % 2 == 0 ) zahl /= 2 ; // Collatz else zahl = 3 * zahl + 1 ; // Collatz itoa(zahl,s); puts(s); // element of the series putch(' '); i++ ; } if(zahl == 1) { puts("\tH(n): "); itoa(i,s); puts(s); // H(n) length of the series putch('\n'); } } settextcolor(15,0); return 0; }

Jede Start-Zahl endet in der Folge auf 4-2-1. Das ist die Behauptung.
siehe:
http://www.ericr.nl/wondrous/index.html
http://www.henkessoft.de/C++/C++/cpp_konsole.htm (Kap. 1.5)

Ein kleiner Meilenstein.

Erhard Henkes Mitglied 20:44:22 12.02.2010 Titel:

Rev. 92:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=92

fat.h/c: FAT-Lesen/nach 12-Bit transferieren signifikant beschleunigt
(FATMAXINDEX testweise auf 300 eingestellt; das muss noch umgestellt werden)

Cuervo stellt Probleme beim Lesen von echter Floppy fest.

Bei mir klappt es auf einem PC mit der FAT, dann allerdings #PF, d.h. die gelesenen/errechneten FAT-Einträge stimmen nicht;
auf dem anderen stimmen die FAT-Einträge nicht (alles 0).
Da das bisher geklappt hat, liegt das an der Code-Änderung in fat12.c (Beschleunigung durch trackweises Lesen in ein Array).

Also leider noch nicht in Ordnung bei realer Hardware
==> Debuggen auf echter Hardware :rolleyes:

Erhard Henkes Mitglied 20:55:21 12.02.2010 Titel:

Rev. 93:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=93

Fehler bei der Analyse der Eingabe von Filenamen in der shell behoben (Eingabe von hello.elf usw. funktioniert nun).
Dank an XanClic für den Hinweis auf die Lösung. :live:

Bis zur Lösung der Probleme mit echter Hardware bitte auf Simulationen testen (MS Virtual PC liest nicht, aber Bochs, Qemu, Sun Virtual Box funktionieren gut).

Erhard Henkes Mitglied 10:18:19 13.02.2010 Titel:

Rev. 94:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=94

fat12.c: Verbesserungen bezüglich echter Hardware
hello.c: Eingabe von 0 als erste Zahl wird abgefangen (auf 1 gesetzt)

Erhard Henkes Mitglied 12:20:22 13.02.2010 Titel:

Rev. 95:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=95

fat12.c: verbesserte Fehlerabfrage bei file_ia(...) - timeout eingebaut

Erhard Henkes Mitglied 13:13:08 13.02.2010 Titel:

Rev. 96:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=96

Verbesserte Fehlermeldungen zur Fehlersuche bei echter Hardware.

Erhard Henkes Mitglied 15:54:08 13.02.2010 Titel:

Rev. 97:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=97

Neu: beep(frequ, duration) als syscall und in userlib

Nun kann das Spielhallen-feeling starten
für qemu: -soundhw pcspk (als Parameter)

fat12.c: read überarbeitet

Erhard Henkes Mitglied 20:03:43 13.02.2010 Titel:

Rev. 98:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=98

- Testversion for correctness of int32_t flpydsk_read_sector_ia( int32_t i, void* a) at real hardware
Currently, only each second time the read procedure to the DMA Buffer really overwrites the contents (manipulated from us to AAAA...) there.

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	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22	int32_t flpydsk_read_sector_ia( int32_t i, void* a) { /// TEST: change DMA before write/read printformat("DMA manipulation\n"); memset((void)DMA_BUFFER, 0x41, 0x200); // 0x41 is in ASCII the 'A' /// TEST: motor on/off flpydsk_control_motor(true); int32_t n, retVal; for(n=0;n<2;n++) // two times should be enough to overwrite the AAAA...* { retVal = flpydsk_read_sector(i,0); if(retVal!=0) { printformat("\nread error: %d\n",retVal); } } memcpy( a, (void)DMA_BUFFER, 0x200); return* retVal; }

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	int32_t flpydsk_read_sector_ia( int32_t i, void* a) { /// TEST: change DMA before write/read printformat("DMA manipulation\n"); memset((void)DMA_BUFFER, 0x41, 0x200); // 0x41 is in ASCII the 'A' /// TEST: motor on/off flpydsk_control_motor(true); int32_t n, retVal; for(n=0;n<2;n++) // two times should be enough to overwrite the AAAA...* { retVal = flpydsk_read_sector(i,0); if(retVal!=0) { printformat("\nread error: %d\n",retVal); } } memcpy( a, (void)DMA_BUFFER, 0x200); return* retVal; }

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	int32_t flpydsk_read_sector_ia( int32_t i, void* a) { /// TEST: change DMA before write/read printformat("DMA manipulation\n"); memset((void)DMA_BUFFER, 0x41, 0x200); // 0x41 is in ASCII the 'A' /// TEST: motor on/off flpydsk_control_motor(true); int32_t n, retVal; for(n=0;n<2;n++) // two times should be enough to overwrite the AAAA...* { retVal = flpydsk_read_sector(i,0); if(retVal!=0) { printformat("\nread error: %d\n",retVal); } } memcpy( a, (void)DMA_BUFFER, 0x200); return* retVal; }

Erhard Henkes Mitglied 21:35:40 13.02.2010 Titel:

Rev. 99:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=99

Testversion, die die Schwachstelle Floppy --> DMA_BUFFER aufdeckt und mindestens 10 mal probiert, meldet Erfolg oder Misserfolg.

Kann noch beschleunigt werden, indem man den Motor nicht anschaltet (noch Sicherheitsmaßnahme).

Erhard Henkes Mitglied 01:20:11 14.02.2010 Titel:

Rev. 100:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=100

Es wurde versuchsweise ein User-TaskCounter (exit in task.c, load in fat12.c, syscall.c) eingeführt, um die shell steuern zu können. Die Shell geht nur dann in die Eingabeschleife ($>), wenn keine User-Tasks laufen.

Die Userlib wurde mit weiteren Funktionen (bereits im Kernel vorhanden) bestückt.

TODO: das Durchsuchen der rootdir muss beschleunigt werden (z.Z. sehr lahm wegen motor on und Diagnose)

Erhard Henkes Mitglied 15:35:30 14.02.2010 Titel:

Rev. 101:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=101

Floppy-Motor-Steuerung verbessert (siehe flag in ODA, os.h)

Sun VB "unterbricht" nach ca. 20 mal Task 2 (shell); real PCs und qemu laufen.

Fragen:
warum bricht Sun VB ab?
warum läuft Floppy ---> DMA nicht zuverlässig (teilweise zwischen 1 bis 16 fails, gerade bei höheren Sektoren)?

Zur Zeit kann nur ein zusätzlicher Task durch Eingabe in die Shell gestartet werden, weil diese solange wartet, bis dieser wieder beendet ist (Task-Zähler).

Erhard Henkes Mitglied 20:24:53 14.02.2010 Titel:

Rev. 102:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=102

- Beschleunigungen in fat12.c und flpydsk.c <--- allerdings Erkennung verschlechtert! :confused:

- gets in der user/user_program_c/userlib.c korrigiert
- __asm__ volatile ("hlt"); in der while-loop des kernels eingebaut

Erhard Henkes Mitglied 02:09:54 15.02.2010 Titel:

Rev 103:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=103

fat12.c: kleine Veränderungen
video.c: printformat um %y erweitert (gibt hexadezimal nur 2 Stellen aus, ideal für die Byte-orientierte Ausgabe von Dateiinhalten )

Diese Version läuft mit Sun Virtual Box 3.1.2, Qemu, Bochs 2.4.2 und auf realer Hardware, prinzipiell auch mit MS Virtual PC, dort jedoch mit unüberwindlichem read error (liegt angeblich an DMA autoinit).

Erhard Henkes Mitglied 20:51:38 15.02.2010 Titel:

Rev 104:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=104

fat12.c: Vereinfachungen (sector/track) durch Zusammenlegen von Funktionen
irq.c: Ausgabe der Fehlermeldungen (#PF, #GPF) in hellrot

Diese Version läuft mit:

Sun Virtual Box 3.1.2,
Qemu 0.11.50,
Bochs 2.4.2,
realem PC mit Floppy Disk.

MS VPC macht noch Probleme (läuft nicht mit autoinit von DMA).

Erhard Henkes Mitglied 23:13:25 15.02.2010 Titel:

Rev 105:

Durchbruch bei Floppy/DMA :live:

http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=105

Einige wesentlich Verbesserungen im Bereich Floppy/DMA/FAT12:

DMA nun ohne autoinit bit (wird von osdev.org für floppy mit autoinit empfohlen!), dafür jeweils ein erneutes DMA-Init vor dem Lesen von Floppy:
Funktioniert nun endlich sicher (Hardware unterstützt autoinit offensichtlich nicht ausreichend) und erlaubt nun auch den Einsatz von MS Virtual PC (bug: simuliert autoinit nicht).

Beim Schreiben ist autoinit noch aktiv. Das stellen wir ebenfalls um, wenn sich das Lesen von Floppy via DMA auf diese Art bewährt.

Die Motor-Steuerung wurde nun auch optimiert, sodass es nun wirklich schneller läuft.

Der Floppy-Motor wird bei #PF und #GPF nun auch ausgeschaltet (Hinweis von Cuervo).

TODO: Schreibvorgang checken (z.B. fformat)!

Erhard Henkes Mitglied 00:18:15 16.02.2010 Titel:

Rev 106:

http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=106

- Read and Write Floppy via DMA ohne autoinit läuft nun zuverlässig
- Läuft auf realer Hardware und zumindest mit folgenden PC-Simulationen: Bochs, Qemu, Sun Virtual Box, MS Virtual PC.
- Solide Basis für Weiterentwicklung

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	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	*********** \| \| X \| O \| ********* \| X \| O \| X \| ********* \| \| \| \| ********* ********* \| 0 \| 1 \| 2 \| ********* \| 3 \| 4 \| 5 \| ********* \| 6 \| 7 \| 8 \| ********* 6 ********* \| \| X \| O \| ********* \| X \| O \| X \| ********* \| O \| \| \| *********** Spieler 2 hat gewonnen! GAME OVER $> fdir <-- <Floppy Disc Directory> PrettyOS 0 byte (vol) 1st sector: 31 BOOT2.BIN 922 byte (arc) 1st sector: 33 KERNEL.BIN 45816 byte (arc) 1st sector: 35 HELLO.ELF 5564 byte (arc) 1st sector: 125 $> - _______ _______ <>_<> (_______) \|_\|_\|_\|_\|_\|_\|\| [] [] \| .---\|'"`\|---. `-oo---oo-'`-oo-----oo-'`-o---o-'`o"O-OO-OO-O"o' Wednesday, February 17, 2010, 00:13:51 69 seconds since start. /

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	*********** \| \| X \| O \| ********* \| X \| O \| X \| ********* \| \| \| \| ********* ********* \| 0 \| 1 \| 2 \| ********* \| 3 \| 4 \| 5 \| ********* \| 6 \| 7 \| 8 \| ********* 6 ********* \| \| X \| O \| ********* \| X \| O \| X \| ********* \| O \| \| \| *********** Spieler 2 hat gewonnen! GAME OVER $> fdir <-- <Floppy Disc Directory> PrettyOS 0 byte (vol) 1st sector: 31 BOOT2.BIN 922 byte (arc) 1st sector: 33 KERNEL.BIN 45816 byte (arc) 1st sector: 35 HELLO.ELF 5564 byte (arc) 1st sector: 125 $> - _______ _______ <>_<> (_______) \|_\|_\|_\|_\|_\|_\|\| [] [] \| .---\|'"`\|---. `-oo---oo-'`-oo-----oo-'`-o---o-'`o"O-OO-OO-O"o' Wednesday, February 17, 2010, 00:13:51 69 seconds since start. /

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	*********** \| \| X \| O \| ********* \| X \| O \| X \| ********* \| \| \| \| ********* ********* \| 0 \| 1 \| 2 \| ********* \| 3 \| 4 \| 5 \| ********* \| 6 \| 7 \| 8 \| ********* 6 ********* \| \| X \| O \| ********* \| X \| O \| X \| ********* \| O \| \| \| *********** Spieler 2 hat gewonnen! GAME OVER $> fdir <-- <Floppy Disc Directory> PrettyOS 0 byte (vol) 1st sector: 31 BOOT2.BIN 922 byte (arc) 1st sector: 33 KERNEL.BIN 45816 byte (arc) 1st sector: 35 HELLO.ELF 5564 byte (arc) 1st sector: 125 $> - _______ _______ <>_<> (_______) \|_\|_\|_\|_\|_\|_\|\| [] [] \| .---\|'"`\|---. `-oo---oo-'`-oo-----oo-'`-o---o-'`o"O-OO-OO-O"o' Wednesday, February 17, 2010, 00:13:51 69 seconds since start. /

Erhard Henkes Mitglied 00:34:05 18.02.2010 Titel:

Rev. 107:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=107

- Einsparung von Lesezugriffen durch Cache von Track0 und Track1
- Verbesserung der Darstellung der RootDir-Inhalte

EDIT: Sun Virtual Box, MS Virtual PC laufen

Erhard Henkes Mitglied 02:11:28 19.02.2010 Titel:

Rev. 108:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=108

pci.c: Erkennen von Netzwerkkarte RTL 8139 eingebaut (thx to "tty")

Testen mit Qemu:

Code:
qemu-system-x86_64.exe -soundhw pcspk -usbdevice mouse -net nic,model=rtl8139,macaddr=00:12:12:12:12:12 -fda FloppyImage.bin -boot a -localtime

Code:
qemu-system-x86_64.exe -soundhw pcspk -usbdevice mouse -net nic,model=rtl8139,macaddr=00:12:12:12:12:12 -fda FloppyImage.bin -boot a -localtime

Code:
qemu-system-x86_64.exe -soundhw pcspk -usbdevice mouse -net nic,model=rtl8139,macaddr=00:12:12:12:12:12 -fda FloppyImage.bin -boot a -localtime

Wer den IRQ-Handler testen will, gibt nach dem PCI-Scan folgenden Code ein (qemu wählt bei mir IRQ 11):

C/C++ Code:
///TEST printformat("Test with IRQ 32+11: "); settextcolor(14,0); __asm__ volatile( "int $43" : : "a"(0) ); settextcolor(15,0); ///TEST

C/C++ Code:
///TEST printformat("Test with IRQ 32+11: "); settextcolor(14,0); __asm__ volatile( "int $43" : : "a"(0) ); settextcolor(15,0); ///TEST

C/C++ Code:
///TEST printformat("Test with IRQ 32+11: "); settextcolor(14,0); __asm__ volatile( "int $43" : : "a"(0) ); settextcolor(15,0); ///TEST

Leider ist es bisher nicht gelungen, den IRQ durch "anpingen" über das Netz auszulösen.

Siehe auch Links bei:
http://www.c-plusplus.de/forum/viewtopic-var-t-is-251851.html (unten)

EDIT: Sun Virtual Box, MS Virtual PC laufen

Erhard Henkes Mitglied 03:28:04 20.02.2010 Titel:

Rev. 109:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=109

Den von tty erstellten Code auf die Vorgaben von http://lowlevel.brainsware.org/wiki/index.php/RTL8139 erweitert/angepasst:

Zitat:

1. Vom PCI-Treiber den IRQ und die I/O-Ports holen
2. IRQ-Handler und ggf. I/O-Ports registrieren
3. Einen Reset der Karte durchführen: Bit 4 im Befehlsregister (0x37, 1 Byte) setzen. Wenn ich hier Portnummern von Registern angebe, ist damit der Offset zum ersten Port der Karte gemeint, der durch die PCI-Funktionen ermittelt werden muss.
4. Aktivieren des Transmitters und des Receivers: Setze Bits 2 und 3 (TE bzw. RE) im Befehlsregister (0x37, 1 Byte). Dies darf angeblich nicht erst später geschehen, da die folgenden Befehle ansonsten ignoriert würden.
5. TCR (Transmit Configuration Register, 0x40, 4 Bytes) und RCR (Receive Configuration Register, 0x44, 4 Bytes) setzen. An dieser Stelle nicht weiter kommentierter Vorschlag: TCR = 0x03000700, RCR = 0x0000070a
6. Puffer für den Empfang (evtl auch zum Senden, das kann aber auch später passieren) initialisieren. Wir brauchen für bei den vorgeschlagenen Werten 8K + 16 Bytes für den Empfangspuffer und einen ausreichend großen Sendepuffer. Was ausreichend bedeutet, ist dabei davon abhängig, welche Menge wir auf einmal absenden wollen. Anschließend muss die physische (!) Adresse des Empfangspuffers nach RBSTART (0x30, 4 Bytes) geschrieben werden.
7. Interruptmaske setzen (0x3C, 2 Bytes). In diesem Register können die Ereignisse ausgewählt werden, die einen IRQ auslösen sollen. Wir nehmen der Einfachkeit halber alle und setzen 0xffff.

umgesetzt in pci.c

IRQ konnte aber bisher nicht über Netzwerk ausgelöst werden.

Bisheriger Versuch: Mac-Adresse ermittelt von der Netzwerkkarte mit RTL 8139, statisch in den Router (LAN, DHCP) eingetragen und IP 192.168.10.97 vergeben, dann ein "ping". Kein Erfolg, weder durch IRQ in PrettyOS noch durch erfolgreiche Rückmeldung des Pings ("Zeitüberschreitung der Anforderung", alle Pakete verloren). arp -a zeigt die IP ebenfalls nicht.

Was fehlt hier noch für diesen ersten Schritt des Auslösens des Interrupts via Netzwerk?

http://prettyos.svn.sourceforge.net/viewvc/prettyos/trunk/Source/kernel/pci.c?view=markup&pathrev=109

EDIT: Sun Virtual Box, MS Virtual PC laufen

Erhard Henkes Mitglied 11:03:57 20.02.2010 Titel:

Rev. 110:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=110

Überarbeiteter Zwischenschritt:
- bleibt in qemu hängen (keine Zurücksetzung des Reset-Bit)
- mac address wird nicht korrekt ausgegeben ?

wie kommt man korrekt an folgende Strukturen:
http://www.digitale-elektronik.de/shopsystem/rtl8139d-datasheet.pdf (S.14/15)

http://svn.rot13.org/index.cgi/pearpc/view/src/io/rtl8139/rtl8139.cc?rev=1

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	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	/ registers / struct Registers { uint8 id0; // 0x00 (mac address) uint8 id1; uint8 id2; uint8 id3; uint8 id4; uint8 id5; uint16 rsvd0; // 0x06-0x07 uint8 mar0; uint8 mar1; uint8 mar2; uint8 mar3; uint8 mar4; uint8 mar5; uint8 mar6; uint8 mar7; uint32 TxStatusD0; // 0x10 uint32 TxStatusD1; // 0x14 uint32 TxStatusD2; // 0x18 uint32 TxStatusD3; // 0x1c uint32 TxStartAddrD0; // 0x20 uint32 TxStartAddrD1; // 0x24 uint32 TxStartAddrD2; // 0x28 uint32 TxStartAddrD3; // 0x2c uint32 RxBufferStartAddr; // 0x30 uint16 EarlyRxByteCount; // 0x34 uint8 EarlyRxStatus; // 0x36 uint8 CommandRegister; // 0x37 uint16 CAPR; // 0x38 initial 0xfff0 uint16 CBA; // 0x3a initial 0x0000 uint16 InterruptMask; // 0x3c uint16 InterruptStatus; // 0x3e uint32 TxConfiguration; // 0x40 uint32 RxConfiguration; // 0x44 uint32 TimerCount; // 0x48 uint32 MissedPacketCounter; // 0x4c uint8 Command93C46; //0x50 uint8 Config0; // 0x51 uint8 Config1; // 0x52 uint8 rsvd1 ; // 0x53 uint32 TimerInterrupt; // 0x54 uint8 MediaStatus; // 0x58 uint8 Config3; // 0x59 uint8 Config4; // 0x5a uint8 rsvd2; // 0x5b uint16 MultipleInterruptSelect; // 0x5c uint8 PCIRevisionID; // 0x5e should be 0x10 uint8 rsvd3; // 0x5f uint16 TSAD; // 0x60 Transmit Status of All Descriptors uint16 BMCR; // 0x62 Basic Mode Control uint16 BMSR; // 0x64 Basic Mode Status uint16 ANAR; // 0x66 Auto-Negotiation Advertisement uint16 ANLPAR; // 0x68 "" Link Partner uint16 ANER; // 0x6a "" Expansion uint16 DisconnectCounter; // 0x6c uint16 FalseCarrierSenseCounter; // 0x6e uint16 NWayTest; // 0x70 uint16 RX_ER_Counter; //0x72 uint16 CSConfiguration; // 0x74 uint16 rsvd4; uint32 PHY1; //0x78 uint32 Twister; // 0x7c uint8 PHY2; // 0x80 } PACKED;

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	/ registers / struct Registers { uint8 id0; // 0x00 (mac address) uint8 id1; uint8 id2; uint8 id3; uint8 id4; uint8 id5; uint16 rsvd0; // 0x06-0x07 uint8 mar0; uint8 mar1; uint8 mar2; uint8 mar3; uint8 mar4; uint8 mar5; uint8 mar6; uint8 mar7; uint32 TxStatusD0; // 0x10 uint32 TxStatusD1; // 0x14 uint32 TxStatusD2; // 0x18 uint32 TxStatusD3; // 0x1c uint32 TxStartAddrD0; // 0x20 uint32 TxStartAddrD1; // 0x24 uint32 TxStartAddrD2; // 0x28 uint32 TxStartAddrD3; // 0x2c uint32 RxBufferStartAddr; // 0x30 uint16 EarlyRxByteCount; // 0x34 uint8 EarlyRxStatus; // 0x36 uint8 CommandRegister; // 0x37 uint16 CAPR; // 0x38 initial 0xfff0 uint16 CBA; // 0x3a initial 0x0000 uint16 InterruptMask; // 0x3c uint16 InterruptStatus; // 0x3e uint32 TxConfiguration; // 0x40 uint32 RxConfiguration; // 0x44 uint32 TimerCount; // 0x48 uint32 MissedPacketCounter; // 0x4c uint8 Command93C46; //0x50 uint8 Config0; // 0x51 uint8 Config1; // 0x52 uint8 rsvd1 ; // 0x53 uint32 TimerInterrupt; // 0x54 uint8 MediaStatus; // 0x58 uint8 Config3; // 0x59 uint8 Config4; // 0x5a uint8 rsvd2; // 0x5b uint16 MultipleInterruptSelect; // 0x5c uint8 PCIRevisionID; // 0x5e should be 0x10 uint8 rsvd3; // 0x5f uint16 TSAD; // 0x60 Transmit Status of All Descriptors uint16 BMCR; // 0x62 Basic Mode Control uint16 BMSR; // 0x64 Basic Mode Status uint16 ANAR; // 0x66 Auto-Negotiation Advertisement uint16 ANLPAR; // 0x68 "" Link Partner uint16 ANER; // 0x6a "" Expansion uint16 DisconnectCounter; // 0x6c uint16 FalseCarrierSenseCounter; // 0x6e uint16 NWayTest; // 0x70 uint16 RX_ER_Counter; //0x72 uint16 CSConfiguration; // 0x74 uint16 rsvd4; uint32 PHY1; //0x78 uint32 Twister; // 0x7c uint8 PHY2; // 0x80 } PACKED;

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	/ registers / struct Registers { uint8 id0; // 0x00 (mac address) uint8 id1; uint8 id2; uint8 id3; uint8 id4; uint8 id5; uint16 rsvd0; // 0x06-0x07 uint8 mar0; uint8 mar1; uint8 mar2; uint8 mar3; uint8 mar4; uint8 mar5; uint8 mar6; uint8 mar7; uint32 TxStatusD0; // 0x10 uint32 TxStatusD1; // 0x14 uint32 TxStatusD2; // 0x18 uint32 TxStatusD3; // 0x1c uint32 TxStartAddrD0; // 0x20 uint32 TxStartAddrD1; // 0x24 uint32 TxStartAddrD2; // 0x28 uint32 TxStartAddrD3; // 0x2c uint32 RxBufferStartAddr; // 0x30 uint16 EarlyRxByteCount; // 0x34 uint8 EarlyRxStatus; // 0x36 uint8 CommandRegister; // 0x37 uint16 CAPR; // 0x38 initial 0xfff0 uint16 CBA; // 0x3a initial 0x0000 uint16 InterruptMask; // 0x3c uint16 InterruptStatus; // 0x3e uint32 TxConfiguration; // 0x40 uint32 RxConfiguration; // 0x44 uint32 TimerCount; // 0x48 uint32 MissedPacketCounter; // 0x4c uint8 Command93C46; //0x50 uint8 Config0; // 0x51 uint8 Config1; // 0x52 uint8 rsvd1 ; // 0x53 uint32 TimerInterrupt; // 0x54 uint8 MediaStatus; // 0x58 uint8 Config3; // 0x59 uint8 Config4; // 0x5a uint8 rsvd2; // 0x5b uint16 MultipleInterruptSelect; // 0x5c uint8 PCIRevisionID; // 0x5e should be 0x10 uint8 rsvd3; // 0x5f uint16 TSAD; // 0x60 Transmit Status of All Descriptors uint16 BMCR; // 0x62 Basic Mode Control uint16 BMSR; // 0x64 Basic Mode Status uint16 ANAR; // 0x66 Auto-Negotiation Advertisement uint16 ANLPAR; // 0x68 "" Link Partner uint16 ANER; // 0x6a "" Expansion uint16 DisconnectCounter; // 0x6c uint16 FalseCarrierSenseCounter; // 0x6e uint16 NWayTest; // 0x70 uint16 RX_ER_Counter; //0x72 uint16 CSConfiguration; // 0x74 uint16 rsvd4; uint32 PHY1; //0x78 uint32 Twister; // 0x7c uint8 PHY2; // 0x80 } PACKED;

EDIT: Sun Virtual Box, MS Virtual PC laufen

Erhard Henkes Mitglied 11:42:32 20.02.2010 Titel:

Rev. 111:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=111

IRQ kann jetzt über Netz ausgelöst werden!

BAR[1].baseAddress ist die richtige! (MMIO anstelle I/O)

Ich habe folgendes gemacht:
- im Router bei DHCP die mac-Adresse fest an eine IP gekoppelt (statisch)
- PING geschickt, "RTL8139 IRQ" kommt

TODO: hängt komplett da fest (da fehlt: 16 bit von 003Eh bis 003Fh lesen und genauso wieder zurück schreiben. "writing a 1 to any bit will reset that bit")
TODO: Basis-Adresse noch mit & 0xFFFC bearbeitet werden (analog USB-Treiber)
TODO: Ping wird nicht sauber bearbeitet, löst nur IRQ aus

Aber immerhin, Netzwerkkarte wurde erkannt und angesprochen.

(thx to tty and homix)

Warum geht das mit qemu nicht?

Beim real PC gibt es jetzt ständig IRQ-Alarm
http://www.digitale-elektronik.de/shopsystem/rtl8139d-datasheet.pdf (S. 19 von 67)?

EDIT: Sun Virtual Box, MS Virtual PC laufen

Erhard Henkes Mitglied 13:04:57 20.02.2010 Titel:

Rev. 112:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=112

Einige Verbesserungen in pci.c

Der IRQ muss im Handler noch zurück gesetzt werden. Dazu brauchen wir aber eine Funktion: phys. Addr. ---> virt. Addr. (gilt auch für USB)

Wir verwenden momentan die MMIO-Adresse der RTL8139 Netzwerkkarte. Mit der IO-Adresse klappt es nicht (warum? sollte gehen!).

EDIT: Sun Virtual Box, MS Virtual PC laufen

Erhard Henkes Mitglied 16:42:48 20.02.2010 Titel:

Rev. 113:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=113

Netzwerk IRQ bei RTL8139 funktioniert, der Install-Handler wurde aber wieder deaktiviert, weil wir momentan den Interrupt nicht wieder abstellen können (Paging-Problem). Erst, wenn das Design stimmt, wird daran weiter entwickelt.

EDIT: Sun Virtual Box, MS Virtual PC laufen

Erhard Henkes Mitglied 00:05:22 21.02.2010 Titel:

Rev. 114:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=114

Netzwerk IRQ bei RTL8139 funktioniert, der Install-Handler wurde wieder aktiviert, nachdem wir den Interrupt abstellen können, geht über out(...,data) also über den IO anstelle MMIO. Wir fahren momentan zweigleisig.

User-Lib: auf Wunsch von tty wurde strchr(...) hinzu gefügt (bitte testen)

EDIT: Sun Virtual Box, MS Virtual PC laufen

Baba Yaga Mitglied 00:31:10 21.02.2010 Titel:

Erhard Henkes schrieb:

wie kommt man korrekt an folgende Strukturen:
http://www.digitale-elektronik.de/shopsystem/rtl8139d-datasheet.pdf (S.14/15)

http://svn.rot13.org/index.cgi/pearpc/view/src/io/rtl8139/rtl8139.cc?rev=1
[cpp]/* registers */
struct Registers {
uint8 id0; // 0x00 (mac address)
...
uint8 PHY2; // 0x80
} PACKED;

Wieso haust Du die Register des Ethernernet-Controllers in eine Struktur? Das ist doch Blödsinn. Mach Dir Makros dafür

XanClic Mitglied 01:20:10 21.02.2010 Titel:

Baba Yaga schrieb:

Wieso haust Du die Register des Ethernernet-Controllers in eine Struktur? Das ist doch Blödsinn. Mach Dir Makros dafür

Für MMIO ist das kein Blödsinn, für I/O-Space dann schon eher. Aber bis jetzt wird MMIO ja noch fleißig benutzt.

Erhard Henkes Mitglied 01:34:52 21.02.2010 Titel:

Rev. 115:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=115

Weitere Verbesserungen in pci.c bezüglich RTL8139.
Die gelesenen Inhalte (receiving buffer) werden angezeigt (Länge der Eingangsdaten (Bit 2 u.3), auf max. 300 Byte begrenzt).

Realer PC, Bochs, Qemu laufen.

MS VPC und Sun VB brechen nach dem Start der Shell ab. :confused:

Analyse der Daten im Receiving Buffer:
"Bytes 0-1: Paketheader (Bit 0 = ROK)"
"Bytes 2-3: Länge des Pakets"
Dann geht es mit der MAC-Adresse des Empfängers weiter (Präambel, SFD ignorieren):
http://lowlevel.brainsware.org/wiki/index.php/RTL8139#Empfangen
http://lowlevel.brainsware.org/wiki/index.php/Ethernet

Screenshot:
http://www.henkessoft.de/OS_Dev/Bilder/rev115.png

EDIT: 22.feb.

Sun VB und MS VPC laufen mit dem FloppyImage (SVN) :confused:

Erhard Henkes Mitglied 02:04:16 21.02.2010 Titel:

Zitat:

Wieso haust Du die Register des Ethernernet-Controllers in eine Struktur?

Habe ich nicht gemacht, wollte das nur beispielhaft zeigen.

Erhard Henkes Mitglied 11:24:39 21.02.2010 Titel:

Rev. 116:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=116

Analyse des Receiving Buffer Contents

EDIT: Version läuft mit Sun VB und MS VPC.

Erhard Henkes Mitglied 13:46:12 21.02.2010 Titel:

Rev. 117:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=117

Übersichtlichere Analyse/Darstellung des Receiving Buffers

EDIT: Version läuft mit Sun VB und MS VPC.

Erhard Henkes Mitglied 16:35:10 21.02.2010 Titel:

Rev. 118:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=118

- in/out-Funktionen optimiert (util.c)
- neues TicTacToe
- einige Strukturen auf packed umgestellt

EDIT: Version läuft mit Sun VB und MS VPC.

Badestrand Mitglied 18:13:28 21.02.2010 Titel:

Rev. 119:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=119

- Funktion eingebaut um Speicher bei 0xF...... zu ID-mappen:
bool paging_do_idmapping( uint32_t phys_addr )
- Einige kleinere syntaktische Sachen, weil's sonst (bei mir) nicht kompiliert hat.

Badestrand Mitglied 20:01:51 21.02.2010 Titel:

Rev. 120:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=120

- Funktion "testch", um zu checken ob eine Taste gedrückt wurde und abholbereit ist
- Zug fährt jetzt unabhängig von Tastatureingaben

EDIT: nein, macht er nicht

Erhard Henkes Mitglied 21:29:47 21.02.2010 Titel:

Rev. 121:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=121

Einige Korrekturen:
- in kernel.ld stand noch shared.o
- user/user_test_c/userlib..h/c und user/user_program_c/... waren verschieden (muss leider immer von Hand von user_program nach user_test kopiert werden.
- hello.c ist nun TTT 0.3

EDIT: Version läuft mit Sun VB und MS VPC.

Erhard Henkes Mitglied 22:49:34 21.02.2010 Titel:

Problem: stellt man in ckernel.c pciScan nach Installation von Paging und versucht in pci.c

paging_do_idmapping( BaseAddressRTL8139_MMIO );

dann erhält man einen #PF.

Debugging ergibt folgendes:

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	bool paging_do_idmapping( uint32_t phys_addr ) { // TODO: Ensure that the physical memory is not used otherwise // TODO: The page table entry may point to a different address // TODO: Create solution for addreses != 0xF... // Adress must be a 0xF...-address if ( (phys_addr & 0xF0000000) != 0xF0000000 ) return false; printformat("\tDEBUG: phys addr OK\n"); const uint32_t pagenr = phys_addr/PAGESIZE; const uint32_t aligned = phys_addr & ~4095; // Setup the page page_table_t* pt = kernel_pd->tables[pagenr/1024]; printformat("DEBUG: behind page_table_t* pt = kernel_pd->tables[pagenr/1024];\n"); ASSERT( pt ); printformat("DEBUG: behind ASSERT. pt = %X\n", &pt); printformat("DEBUG: pt->pages[pagenr%1024] = %X\n", &(pt->pages[pagenr%1024])); pt->pages[pagenr%1024] = aligned \| MEM_PRESENT \| MEM_WRITE \| MEM_KERNEL; //<--- #PF entsteht hier printformat("DEBUG: behind pt->pages[pagenr%1024] = aligned \| MEM_PRESENT \| MEM_WRITE \| MEM_KERNEL;\n"); // Reserve the physical memory phys_set_bits( aligned, aligned+PAGESIZE, true ); printformat("DEBUG: behind phys_set_bits( aligned, aligned+PAGESIZE, true );\n"); return true; }

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	bool paging_do_idmapping( uint32_t phys_addr ) { // TODO: Ensure that the physical memory is not used otherwise // TODO: The page table entry may point to a different address // TODO: Create solution for addreses != 0xF... // Adress must be a 0xF...-address if ( (phys_addr & 0xF0000000) != 0xF0000000 ) return false; printformat("\tDEBUG: phys addr OK\n"); const uint32_t pagenr = phys_addr/PAGESIZE; const uint32_t aligned = phys_addr & ~4095; // Setup the page page_table_t* pt = kernel_pd->tables[pagenr/1024]; printformat("DEBUG: behind page_table_t* pt = kernel_pd->tables[pagenr/1024];\n"); ASSERT( pt ); printformat("DEBUG: behind ASSERT. pt = %X\n", &pt); printformat("DEBUG: pt->pages[pagenr%1024] = %X\n", &(pt->pages[pagenr%1024])); pt->pages[pagenr%1024] = aligned \| MEM_PRESENT \| MEM_WRITE \| MEM_KERNEL; //<--- #PF entsteht hier printformat("DEBUG: behind pt->pages[pagenr%1024] = aligned \| MEM_PRESENT \| MEM_WRITE \| MEM_KERNEL;\n"); // Reserve the physical memory phys_set_bits( aligned, aligned+PAGESIZE, true ); printformat("DEBUG: behind phys_set_bits( aligned, aligned+PAGESIZE, true );\n"); return true; }

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	bool paging_do_idmapping( uint32_t phys_addr ) { // TODO: Ensure that the physical memory is not used otherwise // TODO: The page table entry may point to a different address // TODO: Create solution for addreses != 0xF... // Adress must be a 0xF...-address if ( (phys_addr & 0xF0000000) != 0xF0000000 ) return false; printformat("\tDEBUG: phys addr OK\n"); const uint32_t pagenr = phys_addr/PAGESIZE; const uint32_t aligned = phys_addr & ~4095; // Setup the page page_table_t* pt = kernel_pd->tables[pagenr/1024]; printformat("DEBUG: behind page_table_t* pt = kernel_pd->tables[pagenr/1024];\n"); ASSERT( pt ); printformat("DEBUG: behind ASSERT. pt = %X\n", &pt); printformat("DEBUG: pt->pages[pagenr%1024] = %X\n", &(pt->pages[pagenr%1024])); pt->pages[pagenr%1024] = aligned \| MEM_PRESENT \| MEM_WRITE \| MEM_KERNEL; //<--- #PF entsteht hier printformat("DEBUG: behind pt->pages[pagenr%1024] = aligned \| MEM_PRESENT \| MEM_WRITE \| MEM_KERNEL;\n"); // Reserve the physical memory phys_set_bits( aligned, aligned+PAGESIZE, true ); printformat("DEBUG: behind phys_set_bits( aligned, aligned+PAGESIZE, true );\n"); return true; }

Problematische Zeile: pt->pages[pagenr%1024] = aligned | MEM_PRESENT | MEM_WRITE | MEM_KERNEL; :confused:

Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/rev121a_PF.JPG :confused:

Badestrand Mitglied 23:53:12 21.02.2010 Titel:

Das ist wirklich merkwürdig, die Pages für 3 GB bis 4 GB sind alle von vornherein gemappt; hier dürfte es eigentlich keinen Page Fault geben (siehe Funktion paging_install).

Badestrand Mitglied 23:55:14 21.02.2010 Titel:

Also, die Page Table Einträge sind nicht auf physische Adressen gemappt, die Page Tables an sich haben aber ihren Platz. 0xC9028004 erscheint mir aber auch ein wenig hoch.

Erhard Henkes Mitglied 00:01:01 22.02.2010 Titel:

Ich habe es auch unter Sun VB mit EHCI versucht (0xF08.....), gleiches Resultat.

Wir haben noch zwei Probleme (rev 121):
Sun VB: VERR_REM_VIRTUAL_CPU_ERROR
MS VPC: Interner Fehler auf virtuellem Computer

Beim Start der Shell (versteht momentan keiner, hat irgendwas mit dem Task-Wechsel zu tun)

Adressen mit #PF:
Adresse MMIO: in http://www.henkessoft.de/OS_Dev/Bilder/rev121a_PF.JPG zu sehen: 0xF2001000
Bei EHCI hatte ich 0xF1800000, dort knallte es auch.

pci.c line 285, falls vendor verschieden:

C/C++ Code:
if( (pciDev_Array[number].deviceID == 0x8139) && (pciDev_Array[number].vendorID == 0x10EC) )

C/C++ Code:
if( (pciDev_Array[number].deviceID == 0x8139) && (pciDev_Array[number].vendorID == 0x10EC) )

C/C++ Code:
if( (pciDev_Array[number].deviceID == 0x8139) && (pciDev_Array[number].vendorID == 0x10EC) )

können wir den vendorID-Zweig da raus nehmen?

Badestrand Mitglied 00:09:57 22.02.2010 Titel:

Ok, hab den Fehler ausfindig gemacht. Sorry, war mein Bug. Hab's eingecheckt

Edit: Rev 124
- Einen Bug gefixt, läuft bei mir jetzt unter Bochs und Qemu.

Edit2: Das war ja ein wirklich bescheuerter Fehler. Und merkwürdig/schade, dass er sich nicht früher bemerkbar gemacht hat. Ich hatte

C/C++ Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	// Setup the page tables for the kernel heap (3GB-4GB), unmapped page_table_t* heap_pts = malloc( 256*sizeof(page_table_t), PAGESIZE ); memset( heap_pts, 0, 256*sizeof(page_table_t) ); for ( uint32_t i=0; i<256; ++i ) { kernel_pd->tables[768+i] = heap_pts; kernel_pd->codes[768+i] = (uint32_t)kernel_pd->tables[768+i] \| MEM_PRESENT \| MEM_WRITE; heap_pts += sizeof(page_table_t); //<----- }

C/C++ Code:
1 2 3 4 5 6 7 8 9	// Setup the page tables for the kernel heap (3GB-4GB), unmapped page_table_t* heap_pts = malloc( 256*sizeof(page_table_t), PAGESIZE ); memset( heap_pts, 0, 256*sizeof(page_table_t) ); for ( uint32_t i=0; i<256; ++i ) { kernel_pd->tables[768+i] = heap_pts; kernel_pd->codes[768+i] = (uint32_t)kernel_pd->tables[768+i] \| MEM_PRESENT \| MEM_WRITE; heap_pts += sizeof(page_table_t); //<----- }

C/C++ Code:
1 2 3 4 5 6 7 8 9	// Setup the page tables for the kernel heap (3GB-4GB), unmapped page_table_t* heap_pts = malloc( 256*sizeof(page_table_t), PAGESIZE ); memset( heap_pts, 0, 256*sizeof(page_table_t) ); for ( uint32_t i=0; i<256; ++i ) { kernel_pd->tables[768+i] = heap_pts; kernel_pd->codes[768+i] = (uint32_t)kernel_pd->tables[768+i] \| MEM_PRESENT \| MEM_WRITE; heap_pts += sizeof(page_table_t); //<----- }

An der Stelle mit dem Pfeil wurde der Zeiger natürlich um das Quadrat der Größe weiterbewegt - ich hatte "heap_pts" wie einen char-Pointer behandelt. Natürlich wird der Zeiger bei +X um X*Größe weiterbewegt. Ein += 1 wäre richtiger gewesen..

Erhard Henkes Mitglied 00:24:18 22.02.2010 Titel:

bei mir ist bisher nur rev 123 verfügbar? (in ckernel.c: rev. 124)

Zitat:

Das war ja ein wirklich bescheuerter Fehler.

Fehler sind immer bescheuert.

Super! Rev. 123 läuft schon gut. Nun können wir endlich den pciScan hinter Paging und Heap ausführen. Danke!

Erhard Henkes Mitglied 00:48:37 22.02.2010 Titel:

Rev. 124:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=124

pci.c: EHCI (USB) MMIO ebenfalls in das ID mapping eingebunden

Revisions-Nr. wieder identisch!

Real Hardware läuft (von Cuervo kommen da allerdings Problemmeldungen, sollten verschwinden, sobald das MS VPC u. Sun VB Problem gelöst wird).

Status bei den Simulationen:
Bochs 2.4.2: läuft
Qemu: läuft
MS VPC 6.0.192.0: läuft!

Sun VB 3.1.2 und 3.1.4: läuft!

@Badestrand: was hast Du da genau gerade gebogen? (wichtig, weil wir immer wieder in diese Grube fallen, ohne es zu merken)
EDIT: Ich denke, Du bist unschuldig an dieser Sache mit MS VPC und Sun VB.

EDIT (aus IRC):
- bei 115 hatte ich notiert, MS VPC und Sun VB brechen nach dem Start der Shell ab.
- test mit dem FloppyImage aus dem SVN: ok
- da soll man nicht durchknallen
- Die Probleme mit Sun VB und MS VPC lassen sich nicht nachvollziehen!
- alles geht plötzlich
- so liest sich das auch oft im Internet: "durch Neuinstallation von VB behoben"
- das würde ich wirklich gerne verstehen
- XanClic hat beim Suchen und Vergleichen auch nie was gefunden

Wie bekommt man das Thema "Tests mit Simulationen und realer Hardware" in den Griff?

Erhard Henkes Mitglied 20:04:37 22.02.2010 Titel:

Rev. 125:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=125

- RTL8139.c: handler ausgelagert
- Adressen von IO komplett auf MMIO umgestellt

Rev. 126:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=126
install_RTL8139(uint32_t number) auch noch ausgelagert

Real Hardware läuft

Status bei den Simulationen:
Bochs 2.4.2: läuft
Qemu 0.11.50: läuft
MS VPC 6.0.192.0: läuft.
Sun VB 3.1.2 und 3.1.4: läuft.

Erhard Henkes Mitglied 21:42:26 22.02.2010 Titel:

Rev. 127:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=127

- Zwischenschritt in RTL8139.c
- neu: ipTcpStack.h/c

Erhard Henkes Mitglied 01:25:32 23.02.2010 Titel:

Rev. 128:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=128

userlib.c: gets(char*) funktionsfähig gemacht, aber irgendwie merkwürdig.

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	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	char* gets(char* s) { int i=0,flag=0; char c; //settaskflag(0); do { c = getch(); 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'; //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	char* gets(char* s) { int i=0,flag=0; char c; //settaskflag(0); do { c = getch(); 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'; //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	char* gets(char* s) { int i=0,flag=0; char c; //settaskflag(0); do { c = getch(); 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'; //settaskflag(1); return s; }

Vielleicht liegt es auch daran, das settaskflag ausgeschaltet wurde, bitte testen. Obiges gets ist nur work-around, aber auch gut zum Testen.
Die ausführliche Version ist hier: http://www.c-plusplus.de/forum/viewtopic-var-t-is-260731-and-start-is-50.html

Ich habe es am realen PC getestet: Da kommt man nicht mehr in die obere Zeile.
Bei qemu geht das ab und zu, also "unsauber".

Das hat mit der Task-/Video-Steuerung zu tun.
ich hoffe, dass dieses gets zunächst die Wünsche von MrX und Cuervo befriedigen.

Erhard Henkes Mitglied 20:53:45 23.02.2010 Titel:

Rev. 129:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=129

TCP/IP-Stack leicht verändert/korrigiert

Erhard Henkes Mitglied 22:51:30 23.02.2010 Titel:

Rev. 130:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=130

TCP/IP-Stack leicht verändert

Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/rev130.PNG

Erhard Henkes Mitglied 23:25:42 23.02.2010 Titel:

Rev. 131:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=131

Korrektur bei TCP/IP (zusätzlich im Screenshot oben: Erkennung von ARP)

Erhard Henkes Mitglied 01:19:04 24.02.2010 Titel:

Rev. 132:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=132

pci.c: USB EHCI: Einstieg in Daten-Ermittlung (z.B. OpRegs Adresse, siehe: http://www.c-plusplus.de/forum/viewtopic-var-t-is-253016-and-start-is-39.html)

Erhard Henkes Mitglied 23:59:19 24.02.2010 Titel:

Rev. 133:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=133

- paging.c: bool paging_do_idmapping( uint32_t phys_addr ) versuchsweise ab 0xC0000000 (Grund: manche MMIO beginnen ab 0xD....... oder 0xE.......)
- ckernel.c:

C/C++ Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	int main() { init(); pODA->Memory_Size = paging_install(); printformat( "\n\nMemory size: %d KB\n", pODA->Memory_Size/1024 ); heap_install(); pciScan(); // scan of pci bus; results go to: pciDev_t pciDev_Array[50]; (cf. pci.h) tasking_install(); sti();

C/C++ Code:
1 2 3 4 5 6 7 8 9	int main() { init(); pODA->Memory_Size = paging_install(); printformat( "\n\nMemory size: %d KB\n", pODA->Memory_Size/1024 ); heap_install(); pciScan(); // scan of pci bus; results go to: pciDev_t pciDev_Array[50]; (cf. pci.h) tasking_install(); sti();

C/C++ Code:
1 2 3 4 5 6 7 8 9	int main() { init(); pODA->Memory_Size = paging_install(); printformat( "\n\nMemory size: %d KB\n", pODA->Memory_Size/1024 ); heap_install(); pciScan(); // scan of pci bus; results go to: pciDev_t pciDev_Array[50]; (cf. pci.h) tasking_install(); sti();

pciScan direkt hinter heap_install(). In pciScan() werden MMIO (USB EHCI, Netzwerkarte ID-gemappt.

Mal sehen, ob es klappt oder #PF hagelt? :leak:

Erhard Henkes Mitglied 19:31:46 25.02.2010 Titel:

Rev. 134:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=134

Für unsere verehrten User:
void clear_screen() <--- TODO: nur oberen Bildschirmbereich löschen.
void gotoxy(unsigned char x, unsigned char y)

Erhard Henkes Mitglied 07:39:41 26.02.2010 Titel:

Rev. 135:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=135

userlib.h/c: clear_screen() umgestellt auf Löschen der ersten 46 Zeilen (User-Bereich).

Erhard Henkes Mitglied 21:07:07 26.02.2010 Titel:

Rev. 136:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=136

- kleine Verbesserungen nach cppcheck
- c99 im makefile bei user ergänzt

Rev. 137:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=137

ext in paging.c wieder eingefügt, ansonsten Error-Meldung.

Erhard Henkes Mitglied 22:33:04 26.02.2010 Titel:

Rev. 138:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=138

neu: ehci.c (als Keimzelle für den USB 2.0 Host Controller) vergessen worden!
userlib.h/.c: clearScreen(backcolor)
flpydsk.c: Zählervariable versuchsweise im Schleifenkopf definiert (c99 style)

Erhard Henkes Mitglied 22:59:03 26.02.2010 Titel:

Rev. 139:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=139

- ehci.c war vergessen worden, jetzt dabei
- fat12.c auf c99 umgestellt

Erhard Henkes Mitglied 23:21:56 26.02.2010 Titel:

Rev. 140:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=140

pci.c und initrd.c auf c99 umgestellt (Zähler im Schleifenkopf)

Erhard Henkes Mitglied 23:42:28 26.02.2010 Titel:

Rev. 141
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=141

rtl8139.c, util.c und userlib.c auf c99 umgestellt

Erhard Henkes Mitglied 23:53:09 26.02.2010 Titel:

Rev. 142:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=142

Fehler in clear_userscreen (video.c) korrigiert

Erhard Henkes Mitglied 02:56:50 27.02.2010 Titel:

Rev. 144:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=144

ehci.h/c: initEHCIHostController() TEST-Version (erste Gehversuche

)

pci.c, Zeilen 187/188:

C/C++ Code:
analyzeEHCI(bar); initEHCIHostController();

C/C++ Code:
analyzeEHCI(bar); initEHCIHostController();

C/C++ Code:
analyzeEHCI(bar); initEHCIHostController();

siehe EHCI Spec Rev. 1.0, Kap. 4 "Operational Model"

Ideal: Sun VB oder reale Hardware mit EHCI USB und Netzwerkkarte 8139

(Anm:: rev. 141-143 war fehlerhaft bezüglich rtl8139.c)

Erhard Henkes Mitglied 22:32:36 27.02.2010 Titel:

Rev. 145:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=145

- Korrektur in RTL8139.c (reset abwarten)
- TTT 0.4 von MrX eingespielt (Sehr schön gemacht! Macht aber Probleme, wenn auf echter Hardware eine RTL8139 vorhanden ist und diese Interrupts und Prints sendet)

Z Mitglied 00:24:40 28.02.2010 Titel:

Erhard Henkes schrieb:

Rev. 145:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=145

Jede Quellcodedatei die ich bisher von euch gesehen habe (diese z.B.) sieht so furchtbar unvollständig aus. ihr arbeitet wohl an 100 Baustellen gleichzeitig.

Mr X Mitglied 00:33:20 28.02.2010 Titel:

Es gibt derzeit auch viele Baustellen... Vlt. hast Du konkrete Vorschläge, wo man was verbessern könnte? :-)

Z Mitglied 00:50:51 28.02.2010 Titel:

Mr X schrieb:

Es gibt derzeit auch viele Baustellen... Vlt. hast Du konkrete Vorschläge, wo man was verbessern könnte? :-)

Mir fällt z.B. auf, dass der Netzwerktreiber keine Sendefunktion hat, dass er direkt TCP aufruft, dass TCP nur eine Empfangsfunktion hat, die noch nicht mal TCP kann.

dass TCP irgendwie auch ARP teilweise behandelt, dass alles mit printformat und settextcolor durchsetzt ist, usw.

Nicht dass ich euch reinreden will, aber das sieht für mich alles sehr nach unkoordinierter Bastelei aus.

Mr X Mitglied 00:57:03 28.02.2010 Titel:

Der Netzwerktreiber wird grad erst geschrieben; Dass der nicht besonders "schön"/funktiosfähig ist ist daher wohl eher nicht verwunderlich. Wenn Du dich damit auszukennst, wärst Du sicher eine große Hilfe bei der Entwicklung dieses Treibers...

Das settextcolor und printformat wird wohl der Übersichtlichkeit dienen.

Zitat:

Nicht dass ich euch reinreden will

Was heißt reinreden... Du kannst gerne mitmachen

Schau doch mal im IRC vorbei...

Z Mitglied 01:21:54 28.02.2010 Titel:

Mr X schrieb:

Der Netzwerktreiber wird grad erst geschrieben; Dass der nicht besonders "schön"/funktiosfähig ist ist daher wohl eher nicht verwunderlich. Wenn Du dich damit auszukennst, wärst Du sicher eine große Hilfe bei der Entwicklung dieses Treibers...

Ich kenne mich ein wenig damit aus, zwar nicht mit dem RTL, aber Netzwerk-Treiber funktionieren nach oben hin alle ähnlich: sie haben alle eine Init, eine Send und eine Receive Funktion. Interrupt-Handling und das Weiterreichen von Paketen sollte der Treiber besser nicht selbst übernehmen. In diesem Sinne vermisse ich auch Modularität in eurem Projekt, ohne die ihr irgenwann den Überblick verlieren werdet. Gleiches gilt für Protokollstacks. Hier wird Modularität und Layering extrem wichtig, weil z.B. IP/TCP auch von WLAN, PPP, und anderen Paketdiensten "gefüttert" werden kann. Üblich für sowas sind Dispatcher-Module, also Code der dynamisch Protokolle an die Netzwerkinterfaces ankoppelt.

Mr X schrieb:

Das settextcolor und printformat wird wohl der Übersichtlichkeit dienen.

Nicht der Übersichtlichkeit des Codes

Debug-Ausgaben könnt ihr z.B. über define oder Flags steuern. So wie es jetzt ist, müsst ihr später alles auskommentieren.

Mr X schrieb:

Zitat:

Nicht dass ich euch reinreden will

Was heißt reinreden... Du kannst gerne mitmachen

Schau doch mal im IRC vorbei...

Danke für die Einladung, aber ich bin kein IRC-Fan und ausserdem ein sehr schlechter Teamplayer. Ich beschränke mich darauf, euch zu kritisieren, wenn mir etwas auffällt.

Edit: die schlimmsten Typos beseitigt

Erhard Henkes Mitglied 09:26:27 28.02.2010 Titel:

@Z: Wir schätzen konstruktive Kritik. Daher bitte weiter machen. Zuständig für den Bereich Netzwerktreiber ist momentan übrigens 'tty'.

Wenn Du die Übersicht hast, könntest Du deine Kraft auf den USB-EHCI-Treiber lenken (ehci.c). Da schätze ich jede konkrete Unterstützung.

Zitat:

Debug-Ausgaben könnt ihr z.B. über define oder Flags steuern. So wie es jetzt ist, müsst ihr später alles auskommentieren.

Das ist richtig. Dafür verwenden wir folgenden Mechanismus:

C/C++ Code:
1 2 3 4 5 6 7 8	1 2 3 4 5 6 7 8	#ifdef _DIAGNOSIS_ settextcolor(2,0); printformat("%X dev: %x vend: %x\t", ( pciDev_t)element, ((pciDev_t)element)->deviceID, ((pciDev_t)element)->vendorID); settextcolor(15,0); #endif*

C/C++ Code:
1 2 3 4 5 6 7 8	#ifdef _DIAGNOSIS_ settextcolor(2,0); printformat("%X dev: %x vend: %x\t", ( pciDev_t)element, ((pciDev_t)element)->deviceID, ((pciDev_t)element)->vendorID); settextcolor(15,0); #endif*

C/C++ Code:
1 2 3 4 5 6 7 8	#ifdef _DIAGNOSIS_ settextcolor(2,0); printformat("%X dev: %x vend: %x\t", ( pciDev_t)element, ((pciDev_t)element)->deviceID, ((pciDev_t)element)->vendorID); settextcolor(15,0); #endif*

_DIAGNOSIS_ wird momentan in os.h gesetzt.

Erhard Henkes Mitglied 12:36:39 28.02.2010 Titel:

Rev. 146:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=146

in ehci.c und paging Änderungen.

Dieses merkwürdige Phänomen, das MS VPC und Sun VB nach einigen Taskwechseln stoppen, obwohl real hardware tapfer läuft, ist wieder da! Bitte suchen helfen.

Ich habe den Diagnosis-Modus angeschaltet (kann man in os.h abschalten).

Mr X Mitglied 13:42:23 28.02.2010 Titel:

So... Nachdem ich heute in das Projekt bei Sourceforge aufgenommen wurde gibts hiermit:

Rev. 147
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=147

zzz_alternative_User-Programme entfernt
user/user_test_c/build.bat geändert
user/user_test_c/mingw32-make.exe entfernt

Mr X Mitglied 14:18:06 28.02.2010 Titel:

Rev. 148
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=148

user/user_test_c/makefile geändert, sodass es ohne msys funktioniert und die userlib nicht mehr im gleichen Ordner liegen muss
user/user_test_c/userlib.c/.h gelöscht, da nicht mehr nötig

EDIT: Das makefile macht auf manchen Systemen derzeit noch Probleme...

Mr X Mitglied 15:30:09 28.02.2010 Titel:

Rev. 149
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=149

Diagnosis-Ausgabe deaktiviert
user/user_test_c/makefile korrigiert
kernel/task.c und kernel/fat12.c geändert, damit man mit -Wshadow kompilieren kann

Mr X Mitglied 15:39:55 28.02.2010 Titel:

Rev. 150
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=150

neues makefile: geht (nur) ohne msys

MSYS unbedingt aus dem PATH nehmen! :warning:

Erhard Henkes Mitglied 16:40:25 28.02.2010 Titel:

Rev. 151:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=151

- kernel_pd in task.c verwendet (bisher war dort NULL verwendet worden für das kernel PD)

Mr X Mitglied 20:12:45 28.02.2010 Titel:

Rev. 152:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=152

TTT 0.41: Macht Gebrauch von der Compileroption -Wshadow, entsprechende Änderungen am Code

Badestrand Mitglied 20:32:50 28.02.2010 Titel:

Erhard Henkes schrieb:

- kernel_pd in task.c verwendet (bisher war dort NULL verwendet worden für das kernel PD)

War aber kein Bug, sondern ein Feature..

Ne im Ernst, wollte das Kernel-PD private lassen. Ist aber irgendwie doch doof, ich ändere es die Tage mal, macht auch den Code ein bissl kürzer.

Erhard Henkes Mitglied 21:24:40 28.02.2010 Titel:

Rev. 153:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=153

Dank des Hinweises von +gjm+ wurde endlich das Sun VB / MS VPC Problem gefunden.
Ich habe Datum/Zeit auskommentiert, bis die Funktion in Ordnung gebracht ist.

InitEHCI habe ich ebenfalls auskommentiert, da ich dies für meine Tests benötige.
Wenn jemand da mithelfen will, in pci.c aktivieren.

Mr X Mitglied 22:12:23 28.02.2010 Titel:

Rev. 154:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=154

makefile aufgeräumt
user_tools ausgelagert nach user/user_tools und makefiles darauf angepasst

Anmerkung (ehenkes): Super! Nun muss man nicht nach jeder Änderung die userlib.h/c kopieren. Arbeitserleichterung und eine Fehlerquelle weniger. :live:

Erhard Henkes Mitglied 23:49:08 28.02.2010 Titel:

Rev. 155:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=155

- Fehler in time.c in Fkt. getCurrentDateAndTime behoben.

Damit ist ein wichtiger Fehler (buffer overflow) verschwunden, der von Sun VB und MS VPC sensibel detektiert wurde.

Dank an +gjm+ für den Fehlerhinweis! :live:

Erhard Henkes Mitglied 01:15:06 01.03.2010 Titel:

Rev. 156:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=156

- Fehler in ehci.c behoben
- ehci.c: die 6 Interrupt-Bits in USBINTR auf 0 gesetzt (wenn alle 6 gesetzt sind, kommen keine Tastenanschläge mehr durch)

Tests auf realem PC und Sun VB bezüglich USB EHCI: ok

Rev. 157:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=157
Zwischenschritt bei ehci.c

Rev. 158:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=158
Zwischenschritt bei ehci.c

Rev. 159:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=159
Zwischenschritt bei ehci.c

Erhard Henkes Mitglied 01:47:25 02.03.2010 Titel:

Rev. 160:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=160

EHCI USB- und Port-Status ausgewertet

Erhard Henkes Mitglied 02:30:05 02.03.2010 Titel:

Rev. 161:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=161

ehci.c Korrekturen

Erhard Henkes Mitglied 10:48:57 02.03.2010 Titel:

Rev. 162:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=162

- Veränderungen ehci.c (hängt allerdings noch bei Einstecken von USB-Devices ??)
- util.c: memsetl (32-Bit-Werte)

Erhard Henkes Mitglied 20:14:10 02.03.2010 Titel:

Rev. 163:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=163

ehci.c Zwischenschritt Port enablen (VBox klappt (leider nicht sicher), real PC noch nicht)

Erhard Henkes Mitglied 21:41:27 02.03.2010 Titel:

Rev. 164:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=164

timer.c: Hinweis von +gjm+ umgesetzt, damit Sun VirtualBox die richtige Zeit seit Start anzeigt.

Erhard Henkes Mitglied 00:31:02 03.03.2010 Titel:

Rev. 165:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=165

ehci.c: PortStatus 1005h (EHCI-owned, PowerOn, Enabled, DeviceOnPort)

Erhard Henkes Mitglied 01:20:20 03.03.2010 Titel:

Rev. 166:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=166

ehci.c
Folgendes wurde vor dem HC Init eingebaut:
stoppen - warten - resetbit auf 1 setzen - warten bis resetbit 0 wird - weiter

Erhard Henkes Mitglied 02:09:01 03.03.2010 Titel:

Rev. 167:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=167

Port Changes werden nun korrekt behandelt.

(Die Interrupts sind noch lahm gelegt, wir pollen)

Bitte heftig USB-Sticks und sonstige USB 2.0 Devices rein/raus.

Erhard Henkes Mitglied 02:37:30 03.03.2010 Titel:

Rev. 168:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=168

ehci.c Korrekturen??

Erhard Henkes Mitglied 23:43:58 03.03.2010 Titel:

Rev. 169:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=169

ehci.c

Ports: (zusätzlich: wait und set reset bit to 0)

C/C++ Code:
1 2 3 4 5 6 7 8	1 2 3 4 5 6 7 8	for(uint8_t j=1; j<=numPorts; j++) { pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<12)); // power on pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<2)); // set bit2 to 0 pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<8)); // set reset bit to 1 sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<8)); // set reset bit to 0 }

C/C++ Code:
1 2 3 4 5 6 7 8	for(uint8_t j=1; j<=numPorts; j++) { pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<12)); // power on pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<2)); // set bit2 to 0 pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<8)); // set reset bit to 1 sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<8)); // set reset bit to 0 }

C/C++ Code:
1 2 3 4 5 6 7 8	for(uint8_t j=1; j<=numPorts; j++) { pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<12)); // power on pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<2)); // set bit2 to 0 pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<8)); // set reset bit to 1 sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<8)); // set reset bit to 0 }

Z Mitglied 00:40:38 04.03.2010 Titel:

Erhard Henkes schrieb:

C/C++ Code:
1 2 3 4 5 6 7 8	1 2 3 4 5 6 7 8	for(uint8_t j=1; j<=numPorts; j++) { pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<12)); // power on pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<2)); // set bit2 to 0 pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<8)); // set reset bit to 1 sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<8)); // set reset bit to 0 }

C/C++ Code:
1 2 3 4 5 6 7 8	for(uint8_t j=1; j<=numPorts; j++) { pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<12)); // power on pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<2)); // set bit2 to 0 pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<8)); // set reset bit to 1 sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<8)); // set reset bit to 0 }

C/C++ Code:
1 2 3 4 5 6 7 8	for(uint8_t j=1; j<=numPorts; j++) { pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<12)); // power on pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<2)); // set bit2 to 0 pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<8)); // set reset bit to 1 sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<8)); // set reset bit to 0 }

Kleiner Verbesserungsvorschlag um den Code "schöner" zu machen (ungetestet)

C/C++ Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	for(uint8_t j=1; j<=numPorts; j++) { volatile uint32_t p = (volatile* uint32_t)(opregs + 0x44 + 4(j-1)) pOpRegs->PORTSC[j] = (p \|= (1<<12)); // power on* pOpRegs->PORTSC[j] = (p &= ~(1<<2)); // set bit2 to 0 Schlechter Kommentar. Was macht dieses Bit? * pOpRegs->PORTSC[j] = (p \|= (1<<8)); // set reset bit to 1* sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (p &= ~(1<<8)); // set reset bit to 0* }

C/C++ Code:
1 2 3 4 5 6 7 8 9	for(uint8_t j=1; j<=numPorts; j++) { volatile uint32_t p = (volatile* uint32_t)(opregs + 0x44 + 4(j-1)) pOpRegs->PORTSC[j] = (p \|= (1<<12)); // power on* pOpRegs->PORTSC[j] = (p &= ~(1<<2)); // set bit2 to 0 Schlechter Kommentar. Was macht dieses Bit? * pOpRegs->PORTSC[j] = (p \|= (1<<8)); // set reset bit to 1* sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (p &= ~(1<<8)); // set reset bit to 0* }

C/C++ Code:
1 2 3 4 5 6 7 8 9	for(uint8_t j=1; j<=numPorts; j++) { volatile uint32_t p = (volatile* uint32_t)(opregs + 0x44 + 4(j-1)) pOpRegs->PORTSC[j] = (p \|= (1<<12)); // power on* pOpRegs->PORTSC[j] = (p &= ~(1<<2)); // set bit2 to 0 Schlechter Kommentar. Was macht dieses Bit? * pOpRegs->PORTSC[j] = (p \|= (1<<8)); // set reset bit to 1* sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (p &= ~(1<<8)); // set reset bit to 0* }

Spart das mehrfache und fehleranfällige Hinschreiben dieses langen Ausdrucks.

Nachtrag: Um 1-Bit Werte lesbarer zu machen, könntest Du folgendes tun und zu den System-Headers hinzufügen...

C/C++ Code:
#define BIT0 (1<<1) #define BIT1 (1<<2) #define BIT2 (1<<3) / usw /

C/C++ Code:
#define BIT0 (1<<1) #define BIT1 (1<<2) #define BIT2 (1<<3) / usw /

C/C++ Code:
#define BIT0 (1<<1) #define BIT1 (1<<2) #define BIT2 (1<<3) / usw /

XanClic Mitglied 16:43:53 04.03.2010 Titel:

Z schrieb:

Nachtrag: Um 1-Bit Werte lesbarer zu machen, könntest Du folgendes tun und zu den System-Headers hinzufügen...

C/C++ Code:
#define BIT0 (1<<1) #define BIT1 (1<<2) #define BIT2 (1<<3) / usw /

C/C++ Code:
#define BIT0 (1<<1) #define BIT1 (1<<2) #define BIT2 (1<<3) / usw /

C/C++ Code:
#define BIT0 (1<<1) #define BIT1 (1<<2) #define BIT2 (1<<3) / usw /

Bit 0 ist aber (1<<0), wenn ich dich richtig verstehe, und Bit 1 wäre (1<<1) usw..

Erhard Henkes schrieb:

C/C++ Code:
1 2 3 4 5 6 7 8	1 2 3 4 5 6 7 8	for(uint8_t j=1; j<=numPorts; j++) { pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<12)); // power on pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<2)); // set bit2 to 0 pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<8)); // set reset bit to 1 sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<8)); // set reset bit to 0 }

C/C++ Code:
1 2 3 4 5 6 7 8	for(uint8_t j=1; j<=numPorts; j++) { pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<12)); // power on pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<2)); // set bit2 to 0 pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<8)); // set reset bit to 1 sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<8)); // set reset bit to 0 }

C/C++ Code:
1 2 3 4 5 6 7 8	for(uint8_t j=1; j<=numPorts; j++) { pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<12)); // power on pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<2)); // set bit2 to 0 pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) \|= (1<<8)); // set reset bit to 1 sleepMilliSeconds(50); // wait pOpRegs->PORTSC[j] = (((volatile* uint32_t)(opregs + 0x44 + 4(j-1))) &= ~(1<<8)); // set reset bit to 0 }

Sieht übrigens kaputt aus. Ich wage einfach mal zu bezweifeln, dass der erste Rootport nicht genommen werden darf, denn du fängst ja hier mit dem zweiten an, wie es aussieht...

Mr X Mitglied 19:12:00 04.03.2010 Titel:

Rev. 170:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=170

video.c/os.h und userlib.c/.h: puts nimmt nun const char* statt char* (puts sollte den String nicht verändern und const char* ist besser für C++-Userprogs)
user/user_test_cpp: Skeleton für C++-Userprogs
user/user_tools/userlib.hpp: userlib-Header für C++

mfg
Mr. X

Mr X Mitglied 20:40:32 04.03.2010 Titel:

Rev. 171:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=171

Diverse Änderungen bezüglich const char* statt char*
u.a. Anpassung der "Deklaration" der Syscalls (nicht sicher, ob richtig (compiliert aber); Wurde jedenfalls in 170 vergessen)

Diese Revision nimmt keine Änderungen am OS vor, es handelt sich eher um "Schönheitskorrekturen"

mfg
Mr. X

Erhard Henkes Mitglied 23:22:10 04.03.2010 Titel:

Rev. 172:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=172

ehci.h/.c: Konstanten (define) eingebaut, Port-Nummerierung korrigiert

Z Mitglied 00:05:18 05.03.2010 Titel:

XanClic schrieb:

Z schrieb:

Nachtrag: Um 1-Bit Werte lesbarer zu machen, könntest Du folgendes tun und zu den System-Headers hinzufügen...

C/C++ Code:
#define BIT0 (1<<1) #define BIT1 (1<<2) #define BIT2 (1<<3) / usw /

C/C++ Code:
#define BIT0 (1<<1) #define BIT1 (1<<2) #define BIT2 (1<<3) / usw /

C/C++ Code:
#define BIT0 (1<<1) #define BIT1 (1<<2) #define BIT2 (1<<3) / usw /

Bit 0 ist aber (1<<0), wenn ich dich richtig verstehe, und Bit 1 wäre (1<<1) usw..

Oh

Ja, Du hast natürlich recht.

Erhard Henkes Mitglied 03:09:12 05.03.2010 Titel:

Rev. 173:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=173

- ehci.c Zwischenschritt (INT-Handler implementiert, Problem: INT aktivieren: Absturz)

Erhard Henkes Mitglied 04:04:33 05.03.2010 Titel:

Rev. 174:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=174

- ehci.c Zwischenschritt (Code vereinfacht: Strukturen direkt aufgesetzt. Thx to Tobiking)

Real PC geht

Falls sich dies bewährt, wird der überflüssige Code entfernt.

Erhard Henkes Mitglied 19:09:35 05.03.2010 Titel:

Rev. 175
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=175

- Kernel verkleinert (weniger Files in initrd.dat: nur noch "info.txt")
- ehci.c bereinigt
- makefile bei initrd angepasst

kernel.bin: 50.624 Bytes
siehe: http://www.c-plusplus.de/forum/viewtopic-var-t-is-260731-and-start-is-68.html (thx to +gjm+)

Erhard Henkes Mitglied 21:08:03 05.03.2010 Titel:

Rev. 176
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=176

PortStatus wird bei Änderungen in Zeile 46-48 "Info-Bereich" ausgegeben.

Test auf Real PC i.O., VBox hängt bei mir.

Erhard Henkes Mitglied 22:04:13 05.03.2010 Titel:

Rev. 177
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=177

Wie 176, nur notdürftig via Polling (in kernel-schleife den handler aufrufen)

PortStatus wird bei Änderungen in Zeile 46-48 "Info-Bereich" ausgegeben.

Test auf Real PC i.O., VBox läuft.

Mr X Mitglied 22:23:08 05.03.2010 Titel:

Rev. 178
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=178

math.c: power "überarbeitet"
keyboard.c: Einsatz von memset
nasmw.exe/nasm.exe: nasm statt nasmw, zugleich auf 2.08rc10 aktualisiert
makefiles auf nasm.exe angepasst
userlib.hpp: Einrückungen korrigiert

http://www.henkessoft.de/OS_Dev/Bilder/rev178.PNG <--- mit Sun VBox (funktioniert aber einfach nicht zuverlässig, geht immer wieder verloren an den Host)

Erhard Henkes Mitglied 02:00:09 06.03.2010 Titel:

Rev. 179
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=179

ehci.c: wieder zurück gebaut auf Interrupt-Technik, also kein Poliing mehr in der Kernel-Loop!

Dank VMWare. :live:

Erhard Henkes Mitglied 17:22:51 06.03.2010 Titel:

Rev. 180
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=180

ehci.c: DeactivateLegacySupport eingebaut

Erhard Henkes Mitglied 17:52:19 06.03.2010 Titel:

Rev. 181
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=181

ehci.c: bei eecp == 0xFF wird die Schleife verlassen

Bei meinem real PC ist z.B. eecp == 0x70 und das nächste Byte dann 0xFF.

Mr X Mitglied 18:36:58 06.03.2010 Titel:

Rev. 182
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=182

Shell (user_program_c) umgebaut: u.a. jetzt mit Eingabecache
Überflüßige Variable im makefile für userprogs entfernt

Erhard Henkes Mitglied 19:15:34 06.03.2010 Titel:

Rev. 183:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=183

Experimenteller Zwischenschritt bei ehci.c:
Wenn mehr als 2 EHCI Devices da sind, wird nur das erste genomme

Erhard Henkes Mitglied 19:43:43 06.03.2010 Titel:

Rev. 184:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=184

ehci.c: Korrektur (eecp und eecp_id)

jetzt kommt bei mir: eecp = 0070h, eecp_id = 0001h

Bei Cuervo und Tobiking gehen nun real PCs endlich!

Hier noch ein work-around für MM-Probleme:
http://www.c-plusplus.de/forum/viewtopic-var-t-is-260731-and-start-is-67.html

Sind mehrere EHCI-Host-Controller vorhanden, kann momentan nur der erste beim PCI-Scan initialisiert werden. :eek:

pci.c, line 202-206

C/C++ Code:
if(!EHCIflag) { analyzeEHCI(bar); initEHCIHostController(number); }

C/C++ Code:
if(!EHCIflag) { analyzeEHCI(bar); initEHCIHostController(number); }

C/C++ Code:
if(!EHCIflag) { analyzeEHCI(bar); initEHCIHostController(number); }

Sun VirtualBox geht auch nicht! (seit Interrupts, Polling aus USBSTS ging leidlich) :rolleyes:

Qemu, Bochs und MS VPC bieten uns momentan kein USB EHCI. :confused:

Mr X Mitglied 22:51:26 06.03.2010 Titel:

Rev. 185:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=185

Intelligenteres Caching der Eingaben: Wiedergenutzte Einträge werden nach vorne geholt
Scope von Variablen verkleinert
Länge der Strings für die Eingabe auf 70+1 reduziert von 70+10
Kommentare nun alle auf English (Ich hatte ausversehen Teile auf Deutsch kommentiert)
Tabs durch Space ersetzt (Noch ein Versehen von mir aus dem letzten Update der Shell)
Uralte User-Prog Versionen aktualisiert

Erhard Henkes Mitglied 01:00:42 07.03.2010 Titel:

Rev. 186:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=186

- kleine Verbesserungen
- Hotfix von +gjm+ implementiert (root dir entries)

Erhard Henkes Mitglied 03:15:58 07.03.2010 Titel:

Rev. 187:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=187

ehci.c: Gesamter Port-Status nach SE0, J- u. K-State im Handler dargestellt

Erhard Henkes Mitglied 12:16:09 07.03.2010 Titel:

Rev. 188:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=188

- ehci.c: high speed test ergänzt

Erhard Henkes Mitglied 16:08:35 07.03.2010 Titel:

Rev. 189:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=189

- ehci.c: Port Reset in Funktion gepackt und im Handler ergänzt

Erhard Henkes Mitglied 16:56:40 07.03.2010 Titel:

Rev. 190:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=190

resetPort im IRQ-handler aktiviert, aber ohne sleepMilliSeconds

VMWare: perfekt! http://www.henkessoft.de/OS_Dev/Bilder/rev190.PNG

bei realPC:
- mal highspeed, mal J-state bei mir.
- bei Cuervo klappt es.

Mr X Mitglied 19:39:05 07.03.2010 Titel:

Rev. 191:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=191

Shell überarbeitet:
- Del, Pos1, End, Pfeiltasten und Insert funktionieren nun
- Kleinere Vereinfachungen (Löschen sinnlosen Codes)

Rev. 192:
behebt nun auch den Fehler beim Ändern gecachter Einträge und entfernt einen überflüssigen Pointer in userlib.c (strncpy)
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=192

Erhard Henkes Mitglied 21:11:44 07.03.2010 Titel:

Rev. 193:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=193

ehci.c: Transfer Zwischenschritt

Erhard Henkes Mitglied 01:21:04 08.03.2010 Titel:

Rev. 194:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=194

ehci.c: Zwischenschritt USB 2.0 EHCI Async-Transfer

Ein großes Lob an Tobiking für die Ausdauer bei diesem schwierigen Thema und an Max Reitz (XanClic) für seine hervorragende Dokumentation - eigentlich ein Opus - im LowLevel wiki: http://lowlevel.brainsware.org/wiki/index.php/USB

Man ist in PrettyOS bei USB 2.0 an einem Punkt angekommen, wo das ergänzende Heranziehen der USB Specification Rev. 2.0, April 27, 2000 (622 Seiten) notwendig wird. XanClic legt gesteigerten Wert darauf, dass jeder der an USB 2.0 arbeitet, sich hier ebenfalls vertieft.

Zur Zeit befinden wir uns nach meiner Abschätzung dort im Abschnitt 9.4.

Mr X Mitglied 10:36:24 08.03.2010 Titel:

Rev. 195:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=195

Shell:
- Überflüssige Fkt. entfernt (hatte ich nach einem Versuch vergessen)
- Schreibcursor nun in jeder Stellung sichtbar
- Insert-Mode verbessert; Kann nun auch volle Zeilen editieren
- Optimierungen bei Nutzung von settextcolor; Selbes Ergebnis, kleinerer Kernel

Erhard Henkes Mitglied 19:26:29 08.03.2010 Titel:

Rev. 196:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=196

ehci.h/.c: Zwischenschritt bezüglich USB-Transfer

Erhard Henkes Mitglied 20:35:26 08.03.2010 Titel:

Rev. 197:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=197

- boot2.asm und fat12.inc "hot" gefixt
- Änderungen in der shell

Mr X Mitglied 20:46:46 08.03.2010 Titel:

Ich möchte noch den Dank an +gjm+ für den Hotfix ergänzen...

Erhard Henkes Mitglied 20:59:21 08.03.2010 Titel:

Ja, echt klasse! +gjm+ lebe hoch! :live:

Erhard Henkes Mitglied 23:38:49 08.03.2010 Titel:

Rev. 198:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=198

ehci.c: USB-Transfer-Test (leider noch nicht erfolgreich)

Erhard Henkes Mitglied 00:15:01 09.03.2010 Titel:

Rev. 199:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=199

ehci.c: USB-Transfer-Test (leider noch nicht erfolgreich, aber ein Fehler in Struktur qtd_token korrigiert)

Erhard Henkes Mitglied 21:32:37 09.03.2010 Titel:

Rev. 200:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=200

ehci.c: Fehler im MM bei EHCI/USB behoben, funktioniert aber noch nicht wie erwartet. Bitte um Mithilfe bei der Fehlersuche.

Erhard Henkes Mitglied 00:45:11 10.03.2010 Titel:

Rev. 201:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=201

ehci.c: Zwischenschritt

Erhard Henkes Mitglied 01:19:20 10.03.2010 Titel:

Rev. 202:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=202

ehci.c: Zwischenschritt
Zirkuläre Async-List

Erhard Henkes Mitglied 02:10:43 10.03.2010 Titel:

Rev. 203:

ehci.c Analyse-Zwischenschritt

Erhard Henkes Mitglied 18:18:12 10.03.2010 Titel:

Rev. 204:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=204

ehci.c: Analyse der Inhalte von QH, QTD und Buffer-Pointer verbessert, damit die erwünschte Wirkung gezielter herbei geführt werden kann.

Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/rev205.PNG

Z Mitglied 20:50:11 10.03.2010 Titel:

Du hast ja ziemliche Mühe damit. Hier mal ein Beispiel: http://research.microsoft.com/en-us/um/redmond/pro ....... ible/src/drivers/serial/usb/master/ehci/ehci.c.htm

Mr X Mitglied 21:42:49 10.03.2010 Titel:

Rev. 205:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=205

time.c: mehrfacher Code (5x fast identisch) in Funktion ausgelagert

Erhard Henkes Mitglied 23:32:16 10.03.2010 Titel:

@Z: Tobiking und ich quälen uns momentan etwas herum, aber wir kommen vorwärts.

Diesen MS-Code kennen wir schon, bringt mich aber nicht wirklich weiter.
Was soll ich z.B. damit?

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	/* Initialize the aperiodic list * NB: This is the endpoint #0 used during configuration, we only * initialize here only the fields that will not change. */ EhciWriteRegister(&Qhead->Ed.Next, VirtualToPhysical(Qhead) \| EHCI_POINTER_TYPE_QH); EhciWriteRegister(&Qhead->Ed.EndpointCaps, (1 << EHCI_QH_RL_SHIFT) \| (8 << EHCI_QH_MPS_SHIFT) \| EHCI_QH_H \| EHCI_QH_DTC \| EHCI_QH_480Mbps ); EhciWriteRegister(&Qhead->Ed.TransferOverlay.Next, EHCI_POINTER_TYPE_TERMINATOR); EhciWriteRegister(&Qhead->Ed.TransferOverlay.Alternate, EHCI_POINTER_TYPE_TERMINATOR);

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	/* Initialize the aperiodic list * NB: This is the endpoint #0 used during configuration, we only * initialize here only the fields that will not change. */ EhciWriteRegister(&Qhead->Ed.Next, VirtualToPhysical(Qhead) \| EHCI_POINTER_TYPE_QH); EhciWriteRegister(&Qhead->Ed.EndpointCaps, (1 << EHCI_QH_RL_SHIFT) \| (8 << EHCI_QH_MPS_SHIFT) \| EHCI_QH_H \| EHCI_QH_DTC \| EHCI_QH_480Mbps ); EhciWriteRegister(&Qhead->Ed.TransferOverlay.Next, EHCI_POINTER_TYPE_TERMINATOR); EhciWriteRegister(&Qhead->Ed.TransferOverlay.Alternate, EHCI_POINTER_TYPE_TERMINATOR);

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	/* Initialize the aperiodic list * NB: This is the endpoint #0 used during configuration, we only * initialize here only the fields that will not change. */ EhciWriteRegister(&Qhead->Ed.Next, VirtualToPhysical(Qhead) \| EHCI_POINTER_TYPE_QH); EhciWriteRegister(&Qhead->Ed.EndpointCaps, (1 << EHCI_QH_RL_SHIFT) \| (8 << EHCI_QH_MPS_SHIFT) \| EHCI_QH_H \| EHCI_QH_DTC \| EHCI_QH_480Mbps ); EhciWriteRegister(&Qhead->Ed.TransferOverlay.Next, EHCI_POINTER_TYPE_TERMINATOR); EhciWriteRegister(&Qhead->Ed.TransferOverlay.Alternate, EHCI_POINTER_TYPE_TERMINATOR);

Z Mitglied 00:11:06 11.03.2010 Titel:

Erhard Henkes schrieb:

Was soll ich z.B. damit?

Als Beispiel verwenden, analysieren und verstehen.
Sonst seid ihr nächstes Jahr noch nicht fertig.

Erhard Henkes Mitglied 00:15:11 11.03.2010 Titel:

Ich zitiere mal Tobiking aus dem IRC:

Zitat:

Gerade MS Code würde ich nicht nehmen ^^

Dennoch, wenn es hakt, schauen wir da schon rein. ehci.h fand ich dort ganz gut, weil man ein Gefühl für die notwendigen Strukturen und Defines bekommt. Sind aber auch Fehler drinnen, die ich bereits gesehen habe.

Wir wühlen uns durch die Specs von EHCI und USB 2.0. Das reicht erstmal an Infos. Eher zuviel als zu wenig.

Erhard Henkes Mitglied 02:01:22 11.03.2010 Titel:

Rev. 206:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=206

EHCI /USB Zwischenschritt

Transaktionen funktionieren noch nicht. :rolleyes:

XanClic Mitglied 17:32:04 11.03.2010 Titel:

Ich möchte ja kein Spielverderber oder Schwarzseher sein, aber vom Microsoftcode würde ich wirklich die Finger lassen. Inwieweit Linuxcode ansehen und den als Anleitung für ein BSD-OS zu nehmen schlimm ist, weiß ich nicht (denke nicht allzu schlimm), aber der MS-Code ist mit einem "All rights reserved" gekennzeichnet. Ich denke zwar nicht, dass MS euch deshalb verfolgen wird, aber trotzdem ist es rechtlich eher problematisch, sich den vorzunehmen, könnte ich mir vorstellen...

Erhard Henkes Mitglied 19:04:11 11.03.2010 Titel:

Wir möchten das ja auch selbst verstehen und lösen. Bei EHCI und USB 2.0 kommt es echt auf den Durchblick und das Verstehen der Abläufe an. Irgendwo haben wir einen Mechanismus - vermutlich bei EHCI - noch nicht verstanden.

Einer meiner PCs zeigt ja auch noch J-State anstelle 0x1004 oder 0x1005 (high speed enabled). VBox läuft nicht richtig.

Ich hoffe nur, dass die physikalische Adresse, die VMM zurück gibt, ok ist.

Erhard Henkes Mitglied 19:11:09 11.03.2010 Titel:

Rev. 207:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=207

ehci.c:
die allokierten Bereiche auf dem Heap werden mit memset(...) durchgängig auf 0 gesetzt.

EHCI /USB Zwischenschritt, Transaktion läuft noch nicht. :rolleyes:

Mr X Mitglied 19:54:07 11.03.2010 Titel:

Rev. 208:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=208

Wochentage werden nun (aufgrund unterschiedlicher zählweisen unterschiedlicher cmos) berechnet statt ausgelesen.

Z Mitglied 23:14:02 11.03.2010 Titel:

XanClic schrieb:

Ich möchte ja kein Spielverderber oder Schwarzseher sein, aber vom Microsoftcode würde ich wirklich die Finger lassen. Inwieweit Linuxcode ansehen und den als Anleitung für ein BSD-OS zu nehmen schlimm ist, weiß ich nicht (denke nicht allzu schlimm), aber der MS-Code ist mit einem "All rights reserved" gekennzeichnet. Ich denke zwar nicht, dass MS euch deshalb verfolgen wird, aber trotzdem ist es rechtlich eher problematisch, sich den vorzunehmen, könnte ich mir vorstellen...

Du sollst ihn auch nicht kopieren, sondern davon lernen.

XanClic Mitglied 23:14:43 11.03.2010 Titel:

Z schrieb:

XanClic schrieb:

Ich möchte ja kein Spielverderber oder Schwarzseher sein, aber vom Microsoftcode würde ich wirklich die Finger lassen. Inwieweit Linuxcode ansehen und den als Anleitung für ein BSD-OS zu nehmen schlimm ist, weiß ich nicht (denke nicht allzu schlimm), aber der MS-Code ist mit einem "All rights reserved" gekennzeichnet. Ich denke zwar nicht, dass MS euch deshalb verfolgen wird, aber trotzdem ist es rechtlich eher problematisch, sich den vorzunehmen, könnte ich mir vorstellen...

Du sollst ihn auch nicht kopieren, sondern davon lernen.

Ich weiß nicht, ob es das besser macht.