Sourcecode Fortschritt

Erhard Henkes

0.0.1.196 - Rev: 775

types.h: #define BIT(n) (1<<(n))

Erhard Henkes

0.0.1.197 - Rev: 776

void* paging_acquire_pcimem(uint32_t phys_addr, uint32_t numberOfPages)

abgeändert wegen vbe.c: setVideoMemory
Diese Funktion ist nun deutlich bereinigt.

void setVideoMemory()
{
     uint32_t numberOfPages = vgaIB->TotalMemory * 0x10000 / PAGESIZE;
     SCREEN = (uint8_t*)paging_acquire_pcimem(mib->PhysBasePtr, numberOfPages);
     printf("\nSCREEN (phys): %X SCREEN (virt): %X\n",mib->PhysBasePtr, SCREEN);
     printf("\nVideo Ram %u MiB\n",vgaIB->TotalMemory/0x10);     
}

Mr X

ehenkes: Du hast vergessen zu erwähnen, dass Du dabei auch gleich den Verschiebungsfehler in VBE eliminiert hast.

Version 0.0.1.198:

- Cuervos Testergebnisse hochgeladen
- Besserer Skalierungsalgorithmus
- VBE läuft nun in separatem Thread - Zeitersparnis beim booten

Erhard Henkes

0.0.1.199 - Rev: 778

Probeweise zurückverlagert, bitte testen:

kheap.h:

#define PLACEMENT_BEGIN   ((uint8_t*) 0x1000000)     // 16 MiB
#define PLACEMENT_END     ((uint8_t*) 0x1400000)     // 20 MiB

Wegen Überschneidung mit Floppy beim DMA-Puffer (0x1000 - 0x33FF):

setVgaInfoBlock((VgaInfoBlock_t*)0x3400);
setModeInfoBlock((ModeInfoBlock_t*)0x3600);

Erhard Henkes

0.0.1.200 - Rev: 779
Kernel: 515.560 Bytes

http://www.pcidatabase.com/pci_c_header.php (nach Überarbeitung durch Erhard Henkes wegen massiver bugs in der Produkt-Liste, ca. 1h Aufwand) eingebaut zur Erkennung von Devices.

Noch nicht an pci-scan angeschlossen. Bitte erst testen.

bei mir: qemu und PC laufen noch.

Mr X

Diese Liste kostet ca. 300 KB. Ich weiß ja nicht, ob wir uns wirklich 20 % der Floppy damit vollstopfen wollen...

Erhard Henkes

0.0.1.201 - Rev: 780

pciVendProdList.h verwendet zur Auswertung in pciScan(...)

Beispiel qemu:

#0 0:0.0  IRQ:0  Intel   PCI & Memory                                              
#1 0:1.0  IRQ:0  Intel   PIIX3 PCI-to-ISA Bridge (Triton II)                       
#2 0:1.1  IRQ:0  Intel   PIIX3 IDE Interface (Triton II)                           
#3 0:1.2  IRQ:11 Intel   USB EHCI Controller USB EHCI F0000000h MMIO sz:4096       
#4 0:1.3  IRQ:9  Intel   PIIX4/4E/4M Power Management Controller                   
#5 0:2.0  IRQ:0  Cirrus  64-bit VisualMedia Accelerator                           
#6 0:26.0 IRQ:10 Realtek Realtek RTL8139 Family PCI Fast Ethernet NIC

Erhard Henkes

Diese Liste kostet ca. 300 KB. Ich weiß ja nicht, ob wir uns wirklich 20 % der Floppy damit vollstopfen wollen...

@MrX: man kann es ja weg lassen mittels #define _PCI_VEND_PROD_LIST_

Erhard Henkes

0.0.1.202 - Rev: 781

nur IRQ != 255 angezeigt

Aktuelle Liste von VBox:

#1 0:1.0 IRQ:0  Intel PIIX3 PCI-to-ISA Bridge (Triton II)                       
#2 0:1.1 IRQ:0  Intel PIIX4/4E/4M IDE Controller                                
#3 0:2.0 IRQ:11 vend:80EEh dev:BEEFh                                            
#4 0:3.0 IRQ:10 Intel Gigabit Ethernet Controller                               
#5 0:4.0 IRQ:9  vend:80EEh dev:CAFEh                                            
#6 0:5.0 IRQ:5  Intel Aureal (AD1881 SOUNDMAX) Placa Mãe Asaki P3-141           
#7 0:6.0 IRQ:11 vend:106Bh dev:003Fh USB OHCI F0804000h MMIO sz:4096            
#8 0:7.0 IRQ:9  Intel PIIX4/4E/4M Power Management Controller                   
#9 0:8.0 IRQ:9  AMD PCnet LANCE PCI Ethernet Controller                         
#10 0:11.0 IRQ:10 Intel USB 2.0 EHCI Controller USB EHCI F0900000h MMIO sz
:4096

das klingt komisch:
vend:80EEh dev:BEEFh <---- BEEF (vendor 80EEh gibt es nicht)
vend:80EEh dev:CAFEh <---- CAFE

vend:106Bh dev:003Fh <--- der Hersteller soll Apple sein, aber Device 003Fh gibt es nicht

Erhard Henkes

0.0.1.203 - Rev: 782

memory.h eingefügt

Paging.h/c formal überarbeitet

Erhard Henkes

0.0.1.203 - Rev: 783

memory.h nachgereicht

Erhard Henkes

0.0.1.204 - Rev: 784

ESC + p zeigt die Belegung der physischen Bittabelle (paging.c). Jedes Bit dort repräsentiert eine physische Page (auch Frame genannt):

0 = frei (grün),
1 = bereits belegt (grau)

Man sieht, dass PrettyOS 23 1/4 MiB für sich verwendet.

Test mit VBox und 24 MiB RAM eingestellt: Laden von mehreren User-Programmen (ca. 10) führt zum #PF mit error 6 (bit1: write access und bit2: user mode access)
http://www.c-plusplus.net/forum/viewtopic-var-t-is-264710.html

Mit obigem physicalMem-Logger kann man diesen Vorgang illustrativ verfolgen.

internet

version 0.0.1.204 - Rev: 785

vbe.c/h
- Kommentare entfernt, geändert u. hinzugefügt

other_userprogs/vgatest.c entfernt

internet

version 0.0.1.204 - Rev: 786

audio/sb16.c/.h
- Informationen für die Programmierung eines Audiotreibers zusammengelegt (Soundblaster16).

Mr X

Version 0.0.1.205:

- event_list in todo_list umbenannt. Verbessert/Verallgemeinert. Nutzung reduziert.
- memory.txt ergänzt
- Includes aufgeräumt
- Bootablauf verändert, Ausdruck verbessert.
- Sonstiges^^

Erhard Henkes

0.0.1.206 - Rev: 788

PCI_VEND_PROD_LIST_H weiter überarbeitet (teilweise echt übel, benötigt leider noch viel Arbeit)

Erhard Henkes

0.0.1.207 - Rev: 789

PCI_VEND_PROD_LIST_H weiter überarbeitet

Wenn wir da alle mithelfen, kann diese Liste wertvoll werden.
In der Urform ist sie nicht zu gebrauchen gewesen.

Erhard Henkes

0.0.1.208 - Rev: 790

Freigabe des Userstacks:

// free memory for user stack 
if (task->userStack != 0)
{
    paging_free (task->page_directory, task->userStack, task->userStackSize * PAGESIZE);
}

Test mit VBox und 24 MiB RAM:
Zweimal ttt starten, dann das zweite ttt beenden, anschließend das erste.
Man erkennt, dass zwei Pages noch nicht frei gegeben werden beim "kill".

Erhard Henkes

0.0.1.209 - Rev: 791

nach user-stack paging_free nun auch: user-PD und user-PT auf dem heap wird wieder freigegeben
zwei pages auf dem physischen speicher sind allerdings noch belegt nach user-task kill

// free memory for user stack 
if (task->userStack != 0)
{
    paging_free (task->page_directory, task->userStack, task->userStackSize * PAGESIZE);
    if (task->page_directory != kernel_pd)
    {
        free(task->page_directory); 
        free(task->userPT);
    }
}

So sieht das aus, wenn man 4 mal ttt startet und beendet:
http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_209_physMem.PNG

Man sieht, dass dieser Speicher vor dem user-stack (10 Pages) belegt wird. Die 10 Pages vom user-stack werden also sauber wieder frei gegeben.

Auf dem Heap fällt "ring-element" auf.

MrX im IRC:

hätte ring_DeleteFirst ein Memory Leak, müsste der Heap eigentlich platzen. Dann würde bei jedem Tastedruck Speicher verplempert.

Erhard Henkes

0.0.1.210 - Rev: 792

Speicher-Leck ( http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_209_physMem.PNG ) abgedichtet! In elf.c allokierter speicher für das user-programm wird nun auch frei gegeben. Damit ist der Speicher nach Beenden des Programms wieder wie vorher. Typisch sind momentan 2 Frames für das User-Programm (elf.c) und 10 Frames für den User-Stack (task.c).

task.c, void kill(task_t* task):

paging_free (task->page_directory, task->userStackAddr, task->userStackSize * PAGESIZE);
paging_free (task->page_directory, task->userProgAddr, task->userProgSize);

if (task->page_directory != kernel_pd)
{
    free(task->page_directory); 
    free(task->userPT);
}