Sourcecode Fortschritt
-
Rev. 501:
Name und Serial bei usb MSD
-
Rev. 502:
Zwischenschritt auf dem Weg zum Laden eines Files mittels device manager:
loadFile (vorher: testFAT) und analyzeBootsector nach devicemanager.c verlegt und mit entsprechenden Parametern versorgt.
In testMSD (letzter Schritt zur Erfassung von usb msd daten, siehe: http://www.c-plusplus.net/forum/viewtopic-var-t-is-253016-and-start-is-81.html) werden z.Z. beide Funktionen testweise angewendet. Dies muss entkoppelt werden. Die Funktion testMSD mit analyzeBootsector sollte nur der Feststellung aller notwendigen Daten (Partitionen, FAT-Typ) für den device manager dienen.
Der Ladevorgang sollte dann mittels loadFile separat erfolgen.
TODO:
in testMSD: usbMSDVolume allgemein verwendetzeile 32: partition_t usbMSDVolume;
zeile 633: usbRead(sector, usbMSDVolume.buffer);
zeile 637: int32_t retVal = analyzeBootSector((void*)DataQTDpage0, &usbMSDVolume);
zeile 651: loadFile("pqeq elf",&usbMSDVolume);
zeile 652: loadFile("ttt elf",&usbMSDVolume);Dieses allgemeine usbMSDVolume sollte durch das speziell angesprochene Volume gekoppelt an eine "Disk" (usb-Stick), wiederum gekoppelt an einen "Port" (EHCI-Port), ersetzt werden.
void testMSD(uint8_t devAddr, uint8_t config)
Die devAddr ist die angezeigte EHCI-Portnumber.testMSD(devAddr,config); wird in ehci.c, zeile 722, verwendet.
partition_t usbDevVolume[portNumber+1] in ehci.c und partition_t usbMSDVolume in usb2_msd.c sind somit zusammengehörig. Das muss noch "hingebogen" werden, dass die Daten von testMSD dort landen. Vielleicht muss man testMSD dies als Parameter mitgeben und usbMSDVolume (s.o.) entsprechend ersetzen.
Siehe ehci.c, zeile 694-710.
-
Rev. 503 (version wird falsch angezeigt):
testMSD umgebaut: void testMSD(uint8_t devAddr, partition_t* part)
-
Revision 504:
- Bugfix in Pfadparser
- execute-Funktion
- Syscall zum Dateienladen
- Shell kann keine Floppy-Dateien mehr laden, nur noch (derzeit fehlerhaft) durch den devicemanager. Floppy-Support wird natürlich bald wieder eingebaut...Hinweis: Erst testMSD durchlaufen lassen, dann USB-Zugriff versuchen. Zugriff via "X:/TTT ELF" (X ist Laufwerkszahl). Derzeit gibts ein Freeze, wenn man das versucht.
-
$> 3:\TTT ELF <-- Page Fault (page not present) at 01420000h - EIP: 0004192Fh err_code: 00000000h address(eip): 0004192Fh edi: 0141FF89h esi: 00059FFCh ebp: C020DF38h eax: 00059F01h ebx: 01420000h ecx: FFFFFFF2h edx: 00000000h cs: 00000008h ds: 00000010h es: 00000010h fs: 00000010h gs 00000010h ss 00000066 h int_no 14 eflags 00010017h useresp 0141FCC3h1420000h <---
// User Heap management #define USER_HEAP_START ((uint8_t*)0x1420000) // User Stack #define USER_STACK 0x1420000Problem dürfte der user-stack (hat doch bisher geklappt?) oder user-heap sein.
siehe auch: http://www.c-plusplus.net/forum/viewtopic-var-t-is-265757-and-highlight-is-userstack.html
und task.c, zeile 88:
paging_alloc(new_task->page_directory, (void*)(USER_STACK-10*PAGESIZE), 10*PAGESIZE, MEM_USER|MEM_WRITE);zeile 293:
paging_alloc(currentTask->page_directory, old_heap_top, increase, MEM_USER | MEM_WRITE)Erste Reparaturversuche scheiterten bisher.
Untersuchungen deuten auf den user-stack hin, da man den #PF Adresswert durch Veränderung von USER_STACK bzw. zeile 88, task.c, eindeutig beeinflussen kann.Die Wirkung der Funktion paging_alloc kann man leicht kontrollieren:
Folgende Zeile ergänzen im Anfang von paging_alloc, paging.c, zeile 229:printf("\npaging-alloc, virt addr: %X size: %X", virt_addr, size ); // TEST@all: bitte um Hilfe bei der Fehlersuche
@MrX: bitte Procedere im user-Programm untersuchen
-
Was genau soll ich bei der "User-Progamm-Prozedur" ansehen? Bzw., was ist für dich diese Prozedur? Das Programm selbst? Wie es geladen wird?
-
Der Fehler erfolgt auf der user-Seite, so wie es aussieht. Allerdings gibt es noch Ungereimtheiten:
- Du hast davon berichtet, dass der richtge Sektor geladen würde mit anschließendem "freeze".
- Schaltet man in os.h die "Diagnose-Schalter" zu, so taucht ein #PF > 0xF0000000 auf.
- Der #PF bei USER_STACK ist der dritte Fall, der wohl am meisten eintritt.
-
Hi,
ich denke der Fehler tritt im Kernel auf. Das sollte übrigens jeder an dem Wert in CS erkennen können. EIP gibt den Hinweis auf die Funktion, wo der Fehler auftritt, nämlich "execute".
Bei der weiteren Analyse sind mir mehrere Fehler aufgefallen:
void execute(const char* path) { ... while(*path != '/' && *path != '|' && *path != '\'')Die while-Schleife läuft über das Ende des Strings hinaus, wenn path weder \ noch | noch ' enthält. Es fehlt also ein Test auf den Nullterminator. Außerdem sieht man hier sofort, dass Pfade nicht mit "3:\" anfangen dürfen, wie in Erhards Beispiel. Diese beiden Sachverhalte kombiniert mit der Tatsache, dass der Wert von path knapp unter 01420000h sind die Ursache für den Fehler.
Lässt man übrigens 3:/TTT ELF ausführen, dann scheint das (zumindest bei mir) nicht zu klappen, weil das Laufwerk 3 oder was auch immer das ist nicht existiert. Das gibt wieder einen Page Fault (bei mir) an Adresse 0xf000ff7f, und bei dieser Adresse liegt sofort der Verdacht nahe, dass ein NULL-Pointer dereferenziert wurde. Ich denke mal es liegt an der Funktion getPartition, in denen weder die Variablen PortID, PartitionID und DiskID vollständig überprüft werden, noch die Werte der Zeiger auf NULL getestet werden, vor allem da in devicemanager.h dokumentiert ist, dass diese NULL sein können.
if(PortID != -1) { return(ports[PortID]->insertedDisk->partition[PartitionID]); } else { if(DiskID == 0) { return(systemPartition); } else { return(disks[DiskID-1]->partition[PartitionID]); } }
-
der Fehler tritt im Kernel auf. Das sollte übrigens jeder an dem Wert in CS erkennen können.
Ja stimmt, wird klar angezeigt. Der Wert des user-stacks hat mich irritiert. Danke für die Analyse, hilft uns weiter.
-
Ja, diese Prüfung auf 0 fehlt, das stimmt. Und, was noch schlimmer ist, auch die bei den Strings... Danke für den Hinweis.
Aber auch bei eigentlich existierenden Laufwerken klappts aber nicht, auch nicht nach Behebung der Fehler.
EDIT: Derzeit muss man auch noch "3:/TTT ELF" als Laufwerk angeben. Sonst klappt es derzeit erst recht nicht.
EDIT2: #PF-Grund gefunden: '\'' ist nich \, sondern ', daher gingen alle Pfade mit \ nicht.
-
Ehenkes und ich haben grade zusammen den Durchbruch erzielt. Danke Lüttmoor für die Hilfe dabei. Die von dir genannten Probleme sollten jetzt behoben sein. Das mit dem Pfadseparator hast Du ja auch angsprochen, Lüttmoor, aber ich habs in deinem Text garnicht realisiert/zu flüchtig überlesen.
Revision 505:
- Bugfix: Pfade mit \ gehen nun
- Bugfix: waitForKeyStroke sorgt nicht mehr für Freeze. STI eingefügt
- Bugfix: Nullpointer-Abfragen bei Strings und Partition in devicemanager.c ergänzt
-
Dank an Lüttmoor für den Schubs in die richtige Richtung. Auf jeden Fall klappt es nun.
-
Rev. 506:
Nicht-MSD (also nicht class
werden nicht in den msd device manager eingefügt.
-
Revision 507:
- Eingabe von normalen Dateinamen nun erlaubt, 8.3-Notation ("TTT ELF") nicht mehr nötig
- Shortcut für Disk/Port-Ausgabe: Strg+d
- Kleinigkeiten
-
Revision 508:
- Floppytreiber objektorientierter gemacht, basiert auf floppy_t
- flpydsk_refreshVolumeNames statt flpydsk_get_volumeName
- diskType_t mit Funktionspointern für Sector-Read/-Write für Abstraktion
- Vereinfachungen im Code
-
Revision 509:
Revision 510:Fehlerkorrekturen
- pointer cast
- partitionszeiger floppy
-
Revision 511:
- Laden von Floppy mit Devicemanager möglich
- floppy_load ausgebaut (file.c), syscall freigegeben
- Kleinigkeiten, BugfixesDer fat12-Treiber in fat.c ist schneller als der in fat12.c -> doppelt erfolgreich
-
Rev. 512:
Formale Kleinigkeiten:
- Abschließende '\0' hinter Floppy Dev 1 bzw. Floppy Dev 2 eingefügt
- Eine Zeile Abstand hinter "This is a volume formated with FAT12."PrettyOS "denkt" mit:
- Gibt man ttt.elf ein, so will man vielleicht wie bisher (.elf sollte sein) vereinfacht auf die Floppy zugreifen. Wir bauen bei Vorhandensein eines FDD1 den Pfad "1:/" probeweise davor und rufen rekursiv erneut execute(newPath) auf.$> ttt.elf <-- file is being searched... No valid path for partition found! Floppy found! PrettyOS now tries 1:/ttt.elf buffer: C0002000h type: 1 SecPerClus: 1 maxroot: 224 fatsize: 9 fatcopy: 2 firsts: 0 fat: 1 root: 19 data: 33 maxcls: 4294967263 mount: 1 serial #: 50h 52h 45h 54h - - - - - - - - - - - press key - - - - - - - - - - -void execute(const char* path) { partition_t* part = getPartition(path); if(part == NULL) { textColor(0x0C); printf("\nNo valid path for partition found!\n"); textColor(0x0F); if ((cmos_read(0x10)>>4) == 4 ) // first FDD implemented { if (path[0] == '1' && path[1]==':') { // do nothing } else { char newPath[40]; strcpy(newPath,"1:/"); strcat(newPath,path); textColor(0x0E); printf("\nFloppy found! PrettyOS now tries %s\n",newPath); textColor(0x0F); execute(newPath); } } return; } while(*path != '/' && *path != '|' && *path != '\\') { path++; if(*path == 0) { return; } } path++; loadFile(path, part); }maxcls: 4294967263 <--- etwas hoch
-
Rev. 513:
Zwei nicht mehr benötigte Funktionen zum Laden von Floppy in file.h/c entfernt
So stellt sich das momentan in VBox mit zwei Floppy Disk Devices dar:
Available ports: Type Number Name Inserted disk ---------------------------------------------------------------------- FDD A Floppy Dev 1 PRETTYOS FDD B Floppy Dev 2 RAM C RAM RAMDisk ---------------------------------------------------------------------- Attached disks: Type Number Name Part. Serial ---------------------------------------------------------------------- Floppy 1 PRETTYOS 0 PRETTYOS RAMdisk 3 RAMDisk 0 786436 ----------------------------------------------------------------------
-
Rev. 514:
Verbesserung der Darstellung der FAT-Descriptor-Daten in loadFile