Sourcecode Fortschritt

Erhard Henkes

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

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

Erhard Henkes

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

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

Rev 105: Durchbruch bei Floppy/DMA
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

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.             /

Erhard Henkes

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

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:

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):

///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.net/forum/viewtopic-var-t-is-251851.html (unten)

EDIT: Sun Virtual Box, MS Virtual PC laufen

Erhard Henkes

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:

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

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

Erhard Henkes

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

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

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

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

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

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

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.

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)

Erhard Henkes

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

Habe ich nicht gemacht, wollte das nur beispielhaft zeigen.

Erhard Henkes

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

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.