4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    sorry, war 0x9FFFF 😃

    Wäre das korrekter? Läuft aber auch anders.

    mov ax,0xA000
    mov ss,ax      ; stack
    xor sp,sp      ; stackpointer: A0000h

    So sieht BL2 am Anfang zur Zeit aus:

    ;boot2.asm
[map symbols boot2.map]
[Bits 16]
org 0x500
jmp entry_point                  ; go to entry point

;*******************************************************
;	Includes and Defines
;*******************************************************
%include "gdt.inc"               ; GDT definition
%include "A20.inc"               ; A20 gate enabling
%include "Fat12.inc"             ; FAT12 driver
%include "GetMemoryMap.inc"      ; INT 0x15, eax = 0xE820

%define IMAGE_PMODE_BASE 0x100000 ; where the kernel is to be loaded to in protected mode
%define IMAGE_RMODE_BASE 0x3000  ; where the kernel is to be loaded to in real mode

ImageName     db "KERNEL  BIN"
ImageSize     dd 0

;*******************************************************
;	Data Section
;*******************************************************
msgLoading db 0x0D, 0x0A, "Jumping to OS Kernel...", 0
msgFailure db 0x0D, 0x0A, "Missing KERNEL.BIN", 0x0D, 0x0A, 0x0A, 0

entry_point:
    cli                 
    xor ax, ax           ; null segments
    mov ds, ax
    mov es, ax

 ;=====================================================HOTFIX===ehenkes====
    mov ax,0x9000 
    mov ss,ax            ; stack
    xor sp,sp
    dec sp               ; stackpointer: 9FFFFh 
 ;=====================================================HOTFIX===ehenkes====
    sti                  

A20:
    call EnableA20
    0
  • T

    Erhard Henkes schrieb:

    sorry, war 0x9FFFF 😃

    Okay. Ich hätte eher 0x9fc00 genommen, sonst macht ihr euch womöglich die EBDA kaputt. Solange ihr die nicht braucht, ist es aber eigentlich auch egal.

    Wäre das korrekter? Läuft aber auch anders.

    mov ax,0xA000
    mov ss,ax      ; stack
    xor sp,sp      ; stackpointer: A0000h

    Ist besser, weil das Alignment dann stimmt. Für die Korrektheit sollte das keine Rolle spielen, aber für Performance könnte es einen Unterschied machen. Nicht, dass das in einem Bootloader entscheidend wäre, aber solche Fehler macht man ja ganz gern konsequent überall...

    Edit: Nein, in Wirklichkeit ist es vollkomener Blödsinn. Als allererstes kriegt ihr einen Overflow in sp und schreibt dann den Videospeicher voll. 😉

    0
  • E
    Mod

    Ich hätte eher 0x9fc00 genommen

    mov ax,0x9000 
    mov ss,ax     ; stack
    mov sp,0xfc00 ; stackpointer: 9FC00h

    So besser? Läuft auch. 😃
    Hauptsache der Kernel überfährt beim Laden ab 0x3000 im RM den Stack nicht.

    0
  • E
    Mod

    Für Interessierte:
    http://wiki.osdev.org/Memory_Map_(x86)#Extended_BIOS_Data_Area_.28EBDA.29
    http://web.archive.org/web/20060508100419/http://heim.ifi.uio.no/~stanisls/helppc/ebda.html

    0
  • E
    Mod

    0.0.1.29 - Rev: 590

    - printf mit task_switching eingerahmt, um VBox und VMWare mit malloc/free/heap-Diagnose laufen zu lassen
    - Stack im BL2 noch etwas angepasst

    0
  • M

    Version 0.0.1.30 - Rev: 591:

    - Revision wird jetzt angegeben.
    - synchronisation.c/.h hinzugefügt, enthält Code für semaphores (noch fehlerhaft)
    -> zum testen: console.c z. 211 und 267 reinnehmen
    - getCurrentMilliseconds im Userspace ergänzt, entsprechende Funktionen im Kernel ergänzt und umbenannt
    - Kleinigkeiten

    0
  • E
    Mod

    Version 0.0.1.31 - Rev: 592:

    Lauffähige Version für weitere Versuche:

    1. semaphore reicht noch nicht zum Schutz bei printf in malloc/free-Diagnose, daher zunächst noch task_switching false/true; lock/unlock in console.c auskommentiert

    2. free konnten in usb2.c nicht angewendet werden ohne Absturz (daher auskommentiert für weitere Einzelversuche)

    0
  • E
    Mod

    Version 0.0.1.32 - Rev: 593:

    - Alignment bei malloc etwas sparsamer gehalten
    - kleine formale Anpassungen

    0
  • E
    Mod

    Version 0.0.1.33 - Rev: 594:

    Einführung von:
    void* malloc(uint32_t size, uint32_t alignment, char* comment)

    Tastenkombination ESC+H führt zu:
    void logHeapRegions()

    Test mit qemu:
    http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_33_heap_Logger.PNG

    Damit kann man die Verwendung der Regions auf dem Heap leicht kontrollieren. Fehlentwicklungen wie Memory Leaks und sonstige Ungereimtheiten, aber auch das korrekte Wirken auf dem Heap können somit einfach entdeckt werden.

    Damit bleiben wir unserem didaktischem Konzept treu. Welches OS lässt schon den Einblick in den Kernel Heap zu? 😉

    Vorsicht bei USB sticks:
    Während strg+u (screenshot auf stick) nicht ESC+H verwenden! Zerstört den FS-Aufbau. Hier muss ein Lock eingesetzt werden.

    0
  • E
    Mod

    Version 0.0.1.34 - Rev: 595:

    - usb-Transfer "befreit" nun den Heap auch wieder vollständig
    - malloc und free Diagnose nun auch sprechend
    - Heap-Regions-Ausgabe nur noch auf Esc+H (also nicht automatisch bei Heap-Erweiterung) und nur noch reservierte Regions (spalte res. könnte entfallen)

    Beispiel nach dem Start: http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_34_heap_Logger.PNG

    0
  • E
    Mod

    Version 0.0.1.35 - Rev. 596:

    vm86.h/c eingebaut, damit es mal los geht 😉

    0
  • E
    Mod

    Version 0.0.1.36 - Rev. 597:
    (Experimentalzustand bezüglich VM86)

    vm86 modul verankert in paging.c, task.c, irq.c und testweise umgesetzt in ckernel.c mit einem Programm vidswtch.com, das via incbin (data.asm) eingeschleust und im Speicher bei 0x100 zur Ausführung im VM86 positioniert wird.

    Screenshot: http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_36_vm86.PNG

    Startet man vidswtch.com unter Win XP: http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_36_vm86_windows.PNG

    vidswtch.asm:

    [bits 16]
[section .text]

mov ax, 0013h
int 10h
int 3

    INT 10h mit AH = 00h u. AL = 13h: Grafikmodus, 320 x 200 Pixel, 256 Farben (ab MCGA)

    0
  • M

    Version 0.0.1.37 - Rev. 598

    - Bugfixes&Ergänzungen bei semaphores
    - VM86-Dateien nach user/vm86 verlegt
    - makefile baut die o.g. Dateien
    - Projektfile aktualisiert

    0
  • E
    Mod

    0.0.1.38 - Rev. 599:

    r->... und ctx-> zurück gemappt

    0
  • E
    Mod

    rev. 600:

    neuer versuch mit kleinem asm-prog

    0
  • E
    Mod

    rev. 601:

    asm-prog ausgetauscht für tests problem: popf ??

    0
  • E
    Mod

    rev. 602:

    vm86.h in ordnung gebracht und fehlende opcodes (in/out) in vm86.c ergänzt, fehlen noch die Umsetzungen von echtem in/out.

    case 0xEF: // outw 
            printf("outportw(edx, eax) does not yet work\n");
            // outportw(edx, eax); 
            ctx->eip = (uint16_t) (ctx->eip + 1);
            return true;

        case 0xEE: // outb
            printf("outportb(edx, eax) does not yet work\n");
            // outportb(edx,eax);
            ctx->eip = (uint16_t) (ctx->eip + 1);
            return true;

        case 0xED: // inw
            printf("inportb(edx) does not yet work\n");
            // eax = inportb(edx);
            ctx->eip = (uint16_t) (ctx->eip + 1);
            return true;

        case 0xEC: // inb
            printf("inportw(edx) does not yet work\n");
            // eax = (eax & 0xFF00) + inportb(edx);
            ctx->eip = (uint16_t) (ctx->eip + 1);
            return true;

    ... muss context_v86_t erweitert werden. In registers_t ist das alles drinnen, evtl. gleich ganz ersetzen.

    0
  • E
    Mod

    0.0.1.39 - Rev. 603:

    irq.c und vm86.c: Korrekturen und in/out ergänzt
    task.c: create_vm86_ctask eingefügt

    0
  • E
    Mod

    0.0.1.40 - Rev. 604:

    Korrekturen im vm86 Modul (bezüglich useresp)

    0
  • E
    Mod

    0.0.1.41 - Rev. 605: 👍

    Korrekturen in vm86.c: ... noch weitere stack[0] und stack[2] vertauscht

    Folgendes machen, wer den neuen Video Mode (320*200, 16 Farben, ab 0xA0000) sehen will:
    irq.c, zeile 164: // waitForKeyStroke(); auskommentieren

    0
Anmelden zum Antworten