Sourcecode Fortschritt
-
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.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; }
-
Rev. 99:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=99Testversion, 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).
-
Rev. 100:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=100Es 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)
-
Rev. 101:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=101Floppy-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).
-
Rev. 102:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=102- Beschleunigungen in fat12.c und flpydsk.c <--- allerdings Erkennung verschlechtert!
- gets in der user/user_program_c/userlib.c korrigiert
- __asm__ volatile ("hlt"); in der while-loop des kernels eingebaut
-
Rev 103:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=103fat12.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).
-
Rev 104:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=104fat12.c: Vereinfachungen (sector/track) durch Zusammenlegen von Funktionen
irq.c: Ausgabe der Fehlermeldungen (#PF, #GPF) in hellrotDiese 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).
-
Rev 105:
Durchbruch bei Floppy/DMA
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=105Einige 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)!
-
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************* | | 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. /
-
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-InhalteEDIT: Sun Virtual Box, MS Virtual PC laufen
-
Rev. 108:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=108pci.c: Erkennen von Netzwerkkarte RTL 8139 eingebaut (thx to "tty")
Testen mit Qemu:
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 -localtimeWer den IRQ-Handler testen will, gibt nach dem PCI-Scan folgenden Code ein (qemu wählt bei mir IRQ 11):
///TEST printformat("Test with IRQ 32+11: "); settextcolor(14,0); __asm__ volatile( "int $43" : : "a"(0) ); settextcolor(15,0); ///TESTLeider ist es bisher nicht gelungen, den IRQ durch "anpingen" über das Netz auszulösen.
Siehe auch Links bei:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-251851.html (unten)EDIT: Sun Virtual Box, MS Virtual PC laufen
-
Rev. 109:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=109Den von tty erstellten Code auf die Vorgaben von http://lowlevel.brainsware.org/wiki/index.php/RTL8139 erweitert/angepasst:
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=109EDIT: Sun Virtual Box, MS Virtual PC laufen
-
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
/* 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
-
Rev. 111:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=111IRQ 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" kommtTODO: 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 ausAber 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
-
Rev. 112:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=112Einige 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
-
Rev. 113:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=113Netzwerk 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
-
Rev. 114:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=114Netzwerk 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
-
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
-
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.
-
Rev. 115:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=115Weitere 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.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/EthernetScreenshot:
http://www.henkessoft.de/OS_Dev/Bilder/rev115.pngEDIT: 22.feb.
Sun VB und MS VPC laufen mit dem FloppyImage (SVN)
