4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    Version 0.0.1.132 - Rev. 703

    - ipTcpStack.h/c umgebaut, damit ARP-Requests/Replies ausgewertet werden
    - struct ip in ipTcpStack.h überarbeitet

    screenshot: http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_132_arp-request.PNG 👍

    Bereits in der Vorgänger-Version (commit von MrX) ist (auf qemu und VMWare festgestellt) ein neuer mieser Bug drinnen, der zu #GPF und Reboot führen kann.
    Das stört die Netzwerkbemühungen leider. 🙄

    0
  • E
    Mod

    Version 0.0.1.133 - Rev. 704

    Problem: GPF stoppt mit quitTask die shell ohne restart ➡ action

    folgender HOTFIX in irq.c bewahrt vor dem Absturz:

    static void quitTask()
{
    printf("| <Severe Failure - Task Halted> Press key for exit! |");
    sti();
    // while(!keyboard_getChar());
    exit();
    for (;;);
}

    Damit wird das exit() ausgeführt ohne Abhängigkeit vom Keyboard, das evtl. nicht mehr durchdringt.

    Der Auslöser ist übrigens das quitTask() in irq.c, zeile 206, also in diesem Zweig:

    if (r->int_no < 32 && r->int_no != 7 && !(r->eflags & 0x20000)) // no VM bit

    Tests dieses HOTFIX:
    - VBox dreht völlig am Rad (#PF loop)
    - VMWare schmiert beim Laden eines User-Programms ab
    - Bochs läuft 👍
    - qemu läuft, shell kann aber auch zerstört werden
    - echter PC läuft, Laden/Ausführen eines User-Programms klappt, anschließend beim Rücksprung erfolgt Fehler mit exit(), anschließend ist die shell kaputt (Neustart fehlt! ⚠ )

    Problem seit Version 0.0.1.131: shell / Beenden User-Programm (Rücksprung zur shell).

    Auf jeden Fall haben wir jetzt eine Version, an der man die vbe-Aktivitäten und das Networking weiter untersuchen/ausbauen kann. 😉
    Falls der Fehler nicht aufgeklärt wird ➡ Roll-back zu 0.0.1.130

    Solche Situationen werden immer wieder auftauchen, weil unsere Test-Mechanismen nicht ausreichen, solche Commits wie 0.0.1.131 von MrX zu verhindern. ⚠

    0
  • I

    version 0.0.1.134 - Rev: 705

    http://www.rfc-editor.org/rfc/rfc793.txt <--- TRANSMISSION CONTROL PROTOCOL
    http://www.rfc-editor.org/rfc/rfc768.txt <--- USER DATAGRAM PROTOCOL

    - udp.c/h Dateien angelegt

    - Kommentare in rtl8139.c / ipTcpStack.c eingefügt

    Mir ist aufgefallen das der Kernel noch über keine Powermanagment Funktionen, wie APM oder ACPI verfügt!

    0
  • E
    Mod

    Version 0.0.1.135 - Rev: 706

    - userlib.h/c korrigiert (file-funktionen hatten falsche syscall-Nummern)

    0
  • E
    Mod

    Version 0.0.1.136 - Rev: 707

    - senden mittels rtl8139 Netzwerkkarte vorbereitet

    0
  • I

    version 0.0.1.137 - Rev: 708

    rtl8139_eeprom.c/.h Dateien Hinzugefügt

    - Lesen u. Schreiben von EPROMS/EEPROMS mit 28/32 Pin belegung.

    0
  • I

    version 0.0.1.137 - Rev: 708

    vbe.c/.h
    - getPixel() Funktion hinzugefügt
    - scaleBitmap() Funktion angefangen umzusetzen

    0
  • I

    version 0.0.1.137 - Rev: 710

    scaleBitmap(...), in ckernel.c eingefügt

    0
  • I

    version 0.0.1.138 - Rev: 711

    scaleBitmap(...), Funktioniert schon mal und Skaliert das Bild auf die Doppelte Größe, wird noch ausgearbeitet.

    0
  • I

    version 0.0.1.139 - Rev: 712

    - bootscr.bmp ausgetauscht nach ehenkes vorschlag.

    - scaleBitmap(...), aufgeräumt und weiter getestet.

    0
  • E
    Mod

    Danke an internet == somone für diese Funktionalität!

    screenshot: http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_139_bootscr_scaled.PNG 👍

    0
  • E
    Mod

    version 0.0.1.140 - Rev: 713

    erste Sendeversuche zum experimentieren 😃

    0
  • E
    Mod

    Version 0.0.1.141 - Rev: 714

    Korrektur bei MAC-Adresse bei Tx

    Klappt aber noch nicht

    0
  • E
    Mod

    Version 0.0.1.142 - Rev: 715

    Korrektur bei Tx: Interrupt TOK klappt jetzt 🙂

    qemu batch:

    qemu.exe  -fda FloppyImage.img -soundhw pcspk -net nic,model=rtl8139,addr=1A,macaddr=00:12:12:12:12:12 -net tap,ifname=TAP2 -net user -localtime -usb -usbdevice disk:format=raw:dummy.bin

    TAP2 mit IP 192.168.10.50 konfiguriert.

    Mit qemu kommt es auch an (Kontrolle mit wireshark):

    arp-request: "5","2.110467","52:55:0a:00:02:02","Broadcast","ARP","Who has 192.168.10.50?  Tell 10.0.2.2"

arp-reply: "6","2.110475","Plus_12:12:12","52:55:0a:00:02:02","ARP","192.168.10.50 is at 00:12:12:12:12:12"

    Ethernet II, Src: Plus_12:12:12 (00:12:12:12:12:12), Dst: 52:55:0a:00:02:02 (52:55:0a:00:02:02)
    Type: ARP (0x0806)
    Address Resolution Protocol (reply)
    Hardware type: Ethernet (0x0001)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (0x0002)
    Is gratuitous: False
    Sender MAC address: Plus_12:12:12 (00:12:12:12:12:12)
    Sender IP address: 192.168.10.50 (192.168.10.50)
    Target MAC address: 52:55:0a:00:02:02 (52:55:0a:00:02:02)
    Target IP address: 10.0.2.2 (10.0.2.2)

    0
  • E
    Mod

    Version 0.0.1.143 - Rev: 716

    HOTFIX: in task.c , zeile 305: den reboot verhindert

    if(currentTask == kernelTask) // TODO: Handle termination of shellTask
{
   // systemControl(REBOOT);
}

    Wenn ich das richtig sehe, sind die plötzlichen "reboots" weg, allerdings tauchen dennoch #GPF auf.

    Da kann zwar der pid 0 (also kernel task) "verschwinden" (siehe strg+t), aber dennoch läuft es stabiler. Seit Version 0.0.1.131 (MrX) spielen da einige Sachen leider "verrückt".

    Fazit: hat nicht geholfen, es müssen die cli/sti sein, die MrX "aufgeräumt" hat.

    0
  • E
    Mod

    0.0.1.144 - Rev: 717

    in task.c cli()/sti() wieder eingefügt, um den reboot zu überwinden!

    EDIT: #GPF (kernel) und #PF (user) tauchen immer noch auf. Richtig übel! Ich schlage einen Roll-back bei task.h/c (und damit zusammenhängende) vor.

    Ich schlage vor, dass wir ein abgestimmtes Test-Szenario entwicklen und für jeden developer vorgeben, das ein Commit im Regelfall durchlaufen muss, um solche Folgen wie bei 0.0.1.131 zu verhindern.

    0
  • E
    Mod

    0.0.1.145 - Rev: 718

    cli/sti noch etwas nachgebessert in task.c 🙄

    erneuter #GPF: error code: 0 (!), anschließend reboot

    es tauchen aber auch andere #GPF auf: GPF err code: 64912 eip: 113D50h
    (intel (june 2010) 3A, 6-13: EXT=0 IDT=1 segment selelctor index: 00100010 = 0x22 = 34)

    sieht immer noch nicht gut aus! 🙄

    0
  • E
    Mod

    Nun reicht es wirklich! 😉

    ➡ Roll-back bezüglich task.h/c (Version von 0.0.1.130 - Rev. 701 eingebaut, weitere Anpassungen waren glücklicherweise nicht notwendig)

    0.0.1.146 - Rev: 719

    qemu läuft. 👍
    VBox und VMware machen Probleme mit vbe (also 's'), VBox auch beim Überspringen von vbe noch GPF. Das konnten wir schon besser!

    0
  • I

    version 0.0.1.147 - Rev: 720

    vbe.c/.h

    typedef struct {
    uint16_t x, y;
} CursorPosition_t;

    Hinzugefügt und mit DrawChar(...) newline experimentiert.

    erstmal bewusst nicht aus video.h genommen um erstmal eine strikte trennen zwischen Textmodus und VESA zu halten.

    0
  • M

    Version 0.0.1.148:

    - Schäden behoben, cli/sti-Änderungen aus task.c wieder ausgebaut, andere Änderungen eingebaut. Funktioniert wohl nun wieder alles.
    - Patch für VM86.c von Ideenlos
    - Codeformatierungen

    0
Anmelden zum Antworten