Sourcecode Fortschritt

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

[Erhard Henkes]

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]

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]

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]

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]

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:

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;

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

[Badestrand]

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]

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]

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:

if(    (pciDev_Array[number].deviceID == 0x8139) && (pciDev_Array[number].vendorID == 0x10EC) )

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

[Badestrand]

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

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

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

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!