Sourcecode Fortschritt

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

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