Sourcecode Fortschritt

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!

Erhard Henkes

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

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

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

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