Sourcecode Fortschritt
-
Wieso haust Du die Register des Ethernernet-Controllers in eine Struktur?
Habe ich nicht gemacht, wollte das nur beispielhaft zeigen.
-
Rev. 116:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=116Analyse des Receiving Buffer Contents
EDIT: Version läuft mit Sun VB und MS VPC.
-
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.
-
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 umgestelltEDIT: Version läuft mit Sun VB und MS VPC.
-
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.
-
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 TastatureingabenEDIT: nein, macht er nicht
-
Rev. 121:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=121Einige 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.3EDIT: Version läuft mit Sun VB und MS VPC.
-
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
-
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).
-
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.
-
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 ComputerBeim 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?
-
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
umX*Größe
weiterbewegt. Ein+= 1
wäre richtiger gewesen..
-
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!
-
Rev. 124:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=124pci.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 gefundenWie bekommt man das Thema "Tests mit Simulationen und realer Hardware" in den Griff?
-
Rev. 125:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=125- RTL8139.c: handler ausgelagert
- Adressen von IO komplett auf MMIO umgestelltRev. 126:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=126
install_RTL8139(uint32_t number) auch noch ausgelagertReal 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.
-
Rev. 127:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=127- Zwischenschritt in RTL8139.c
- neu: ipTcpStack.h/c
-
Rev. 128:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=128userlib.c: gets(char*) funktionsfähig gemacht, aber irgendwie merkwürdig.
char* gets(char* s) { int i=0,flag=0; char c; //settaskflag(0); do { c = getch(); if(c=='\b') // Backspace { if(i>0) { putch(c); s[i-1]='\0'; --i; } else { beep(50,20); if(flag==false) { putch('\n'); flag=true; } } } else { s[i] = c; putch(c); flag=false; i++; } } while(c!=10); // Linefeed s[i]='\0'; //settaskflag(1); return s; }
Vielleicht liegt es auch daran, das settaskflag ausgeschaltet wurde, bitte testen. Obiges gets ist nur work-around, aber auch gut zum Testen.
Die ausführliche Version ist hier: http://www.c-plusplus.net/forum/viewtopic-var-t-is-260731-and-start-is-50.htmlIch habe es am realen PC getestet: Da kommt man nicht mehr in die obere Zeile.
Bei qemu geht das ab und zu, also "unsauber".Das hat mit der Task-/Video-Steuerung zu tun.
ich hoffe, dass dieses gets zunächst die Wünsche von MrX und Cuervo befriedigen.
-
Rev. 129:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=129TCP/IP-Stack leicht verändert/korrigiert
-
Rev. 130:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=130TCP/IP-Stack leicht verändert
Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/rev130.PNG
-
Rev. 131:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=131Korrektur bei TCP/IP (zusätzlich im Screenshot oben: Erkennung von ARP)