4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    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       00000000729A

    Die 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). 😉

    0
  • M

    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

    0
  • E
    Mod

    Rev. 501:

    Name und Serial bei usb MSD

    0
  • E
    Mod

    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 verwendet

    zeile 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.

    0
  • E
    Mod

    Rev. 503 (version wird falsch angezeigt):

    testMSD umgebaut: void testMSD(uint8_t devAddr, partition_t* part)

    0
  • M

    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.

    0
  • E
    Mod 

    $> 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 0141FCC3h

    1420000h <---

    // User Heap management
#define USER_HEAP_START   ((uint8_t*)0x1420000)   

// User Stack
#define USER_STACK 0x1420000

    Problem 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

    0
  • M

    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?

    0
  • E
    Mod

    Der Fehler erfolgt auf der user-Seite, so wie es aussieht. Allerdings gibt es noch Ungereimtheiten:

    1. Du hast davon berichtet, dass der richtge Sektor geladen würde mit anschließendem "freeze".
    2. Schaltet man in os.h die "Diagnose-Schalter" zu, so taucht ein #PF > 0xF0000000 auf.
    3. Der #PF bei USER_STACK ist der dritte Fall, der wohl am meisten eintritt.
    0
  • L

    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]);
        }
    }
    0
  • E
    Mod

    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.

    0
  • M

    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.

    0
  • M

    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

    0
  • E
    Mod

    Dank an Lüttmoor für den Schubs in die richtige Richtung. Auf jeden Fall klappt es nun. 🙂

    0
  • E
    Mod

    Rev. 506:

    Nicht-MSD (also nicht class 😎 werden nicht in den msd device manager eingefügt.

    0
  • M

    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

    0
  • M

    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

    0
  • E
    Mod

    Revision 509:
    Revision 510:

    Fehlerkorrekturen

    1. pointer cast
    2. partitionszeiger floppy
    0
  • M

    Revision 511:

    - Laden von Floppy mit Devicemanager möglich
    - floppy_load ausgebaut (file.c), syscall freigegeben
    - Kleinigkeiten, Bugfixes

    Der fat12-Treiber in fat.c ist schneller als der in fat12.c -> doppelt erfolgreich 😉

    0
  • E
    Mod

    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 😉

    0
Anmelden zum Antworten