Sourcecode Fortschritt
-
Kommentar zu Rev. 493:
kernel.bin: 100.272 Bytes Wir haben die 100000 Byte Marke geknackt
Test mit real PC:
Attached Disks: Type Number Serial Part. Serial ---------------------------------------------------------------------- FDD 0 0 0 floppy1 RAMdisk 1 0 0 ramdisk USB MSD 2 0 0 8B6A0861 USB MSD 3 0 0 110 USB MSD 4 0 0 00000000729A USB MSD 5 0 0 0D09297675C0 ----------------------------------------------------------------------TODO:
Die Serials stehen momentan noch stellvertretend. Bei usb msd gehören die oben gezeigten Serials zum "Device", also zum usb-Stick. Zur Ermittlung des Partitions-Serial muss noch auf die FAT description zugegriffen werden. In der Regel haben Sticks aber nur eine Partition.
Bei der Floppy müssen die Serials sowohl für Disk (=Diskette) als auch für die Partition (identisch) von der FAT12-Partition gezogen werden (Volume ID).
Bei der RAMDisk verwenden wir momentan ein eigenes Filesystem. Alles ist feststehend, es gibt keine bewegliche "Disk" (wie bei Diskette oder usb-stick) und momentan(!) nur eine "Partition", die das eigene FS umfasst. Prinzipiell könnte man die RAMDisk auf FAT16 (max. 2GB) umstellen.
-
Rev. 494:
Kleine Korrekturen devicemanager.h/c
-
Rev. 495:
ports ebenfalls implementiert
-
Revision 496:
- ports nun "korrekt" aufgezählt
- Bugfix: Disk 0 wird freigehalten für SystemPartition
- Pfad-Parser
- atoi auch im Kernel verfügbar
-
Kommentar zu Rev. 496:
Zunächst mal ein herzliches Dankeschön an MrX für das hervorragende Teamwork bei der Umsetzung des Devicemanagers und für den Path-Parser.
Test auf VBox:
PrettyOS [Version 0.0.0.496] Console 2: EHCI Ports -------------------------------------------------------------------------------- --------------------------------------------------------------------- Number of interfaces: 1 --------------------------------------------------------------------- Interface 0 has 2 endpoints and belongs to class: Mass Storage, SCSI transparent command set, Bulk-Only Transport protocol. --------------------------------------------------------------------- endpoint 1: OUT, bulk data, mps: 512 byte --------------------------------------------------------------------- endpoint 2: IN , bulk data, mps: 512 byte languages: English Generic Mass Storage 8B6A0861 serial: 8B6A0861 Available Ports: Type number Media ---------------------------------------------------------------------- FDD A No floppy disk inserted FDD B No floppy disk inserted USB Port C MSD attached USB Port D No MSD attached USB Port E No MSD attached USB Port F No MSD attached USB Port G No MSD attached USB Port H No MSD attached USB Port I No MSD attached USB Port J No MSD attached ---------------------------------------------------------------------- Attached Disks: Type Number Serial Part. Serial ---------------------------------------------------------------------- Floppy 1 0 0 floppy1 Floppy 2 0 0 floppy2 RAMdisk 3 0 0 ramdisk USB MSD 4 0 0 8B6A0861 ---------------------------------------------------------------------- - - - - - - - - - - - press key - - - - - - - - - - - -------------------------------------------------------------------------------- Port: 1, device attached -------------------------------------------------------------------------------- Monday, June 07, 2010, 12:47:27 16 s runtime. CPU: 3731 MHz \Test auf real PC:
Available Ports: Type number Media ---------------------------------------------------------------------- FDD A No floppy disk inserted USB Port B MSD attached USB Port C No MSD attached USB Port D No MSD attached USB Port E MSD attached USB Port F No MSD attached USB Port G No MSD attached ---------------------------------------------------------------------- Attached Disks: Type Number Serial Part. Serial ---------------------------------------------------------------------- Floppy 1 0 0 floppy1 RAMdisk 2 0 0 ramdisk USB MSD 3 0 0 0D09297675C0 USB MSD 4 0 0 00000000729A ----------------------------------------------------------------------
Next Steps:
- "ports[...]->insertedDisk" Status bei dem FDD prüfen! (z.Z. in floppy_install mangels Informationen über eingelegte / nicht eingelegte Diskette auf NULL gesetzt)
- "MSD attached" bei usb-Ports sollte ersetzt werden durch eine sprechende usb-MSD ID (z.B. Vendor/Produkt/Revision)
- Serial bei der Disk-Liste gegen echte Partitions-Serial (aus FAT descriptor) ersetzen, die gezeigten usb-Serials passen zum Device, also zum Stick, nicht zur Partition, obwohl dies beim Stick das Gleiche bedeutet (nur eine Partition).Inzwischen ist es bei Tobiking gelungen, von einem mit FAT12 (durch Aufspielen von FloppyImage) "formatierten" usb-Stick pqeq.elf und ttt.elf zu laden. Der Lesevorgang im jeweiligen FAT12-Teil des neuen FAT12/16/32-Moduls funktioniert also auch bestens. Somit sollten wir das provisorische fat12.h/c bald durch ein in sich geschlossenes Modul fat.h/c ablösen können.
kernel.bin 104.492 Bytes
Hier kommen wir bald an die kritische Größe, bei der es mit Bootloader2 erneut Probleme geben sollte. Der Aufschlag erfolgt in ... Tagen.
Diesbezüglich müssen wir wohl eine SOKO "Own Bootloader vs GRUB" gründen.
-
Rev. 497:
zwischenschritt: check der Floppy disk im device manager und bei floppy_install
-
Revision 498:
- maximale Floppy-Laufwerkszahl auf 2 vereinheitlicht
- disk_t: Neuer Member name. Speichert den Trivialnamen der Disk/Partition. Bitte in Benutzung nehmen.
- ehci: pciDev_t* statt Index
- Kleinigkeiten
-
Rev. 499:
Portliste und Diskliste weiter verfeinert und implementiert.
RAMDisk wird als "Disk" im "Port" RAM angesehen und erhält ebenfalls einen Buchstaben (Port) und eine Zahl (Partition == Volume).Test auf real PC mit einem Floppy Disk Device und vier usb-Sticks:
Available Ports: Type Number Name Media (attached) ---------------------------------------------------------------------- FDD A Floppy Dev 1 PRETTYOS RAM B RAM RAMDisk usbPort C EHCI-Port 1 0D09297675C0 usbPort D EHCI-Port 2 8B6A0861 usbPort E EHCI-Port 3 00000000729A usbPort F EHCI-Port 4 110 usbPort G EHCI-Port 5 No MSD attached usbPort H EHCI-Port 6 No MSD attached ---------------------------------------------------------------------- Attached Disks: Type Number Name Part. Serial ---------------------------------------------------------------------- Floppy 1 PRETTYOS 0 PRETTYOS RAMdisk 2 RAMDisk 0 786434 USB MSD 3 0D09297675C0 0 0D09297675C0 USB MSD 4 8B6A0861 0 8B6A0861 USB MSD 5 110 0 110 USB MSD 6 00000000729A 0 00000000729ADie Portreihenfolge ist Floppys, RAMDisk, EHCI-Ports (1,2,...).
Die Diskreihenfolge entspricht der Reihenfolge der Installation (Floppys, RAMDisk, usb-sticks entsprechend dem Einsteckzeitpunkt). Frei werdende Disk-Nummern werden wiederverwendet.Der "Serial" 786434 der RAMDisk ist die (dezimal dargestellte) Speicheradresse (0xC0002000) geteilt durch PAGESIZE (4096 bytes).
-
Revision 500:
- settaskflag gelöscht. War gefährlich für User (Anhalten des gesamten OS) und nutzlos im Kernel.
- EHCI/Floppy/RamDisk-Flags direkt initialisiert
- Codevereinfachungen in devicemanager.c, Todos zur Vereinheitlichung der Disk/Port-Handhabung
- Kleinigkeiten, u.a. kleine Schönheitskorrektur in Shell
-
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