4. PrettyOS Fehler-/Testthread

PrettyOS Fehler-/Testthread

  • ?

    Revision 303

    Kleiner Fehler in der console.c. Betrifft zwei Stellen:

    // console.c 303

void console_init(console_t* console, const char* name)
{
(...)
//    memsetw (console->vidmem, 0x20 | (console->attrib << 8), COLUMNS * USER_LINES * 2);
memsetw (console->vidmem, 0x20 | (console->attrib << 8), COLUMNS * USER_LINES );
(...)
}

void clear_console(uint8_t backcolor)
{
(...)
//    memsetw (current_console->vidmem, 0x20 | (current_console->attrib << 8), COLUMNS * USER_LINES * 2);
memsetw (current_console->vidmem, 0x20 | (current_console->attrib << 8), COLUMNS * USER_LINES);
(...)
}

    memsetw! Das "* 2" bewirkt, daß doppelt soviel Speicher überschrieben wird wie eigentlich gedacht. Das könnte auch der Fehler sein, warum TTT auf dem realen PC nicht läuft. VMs schummeln ja immer. 🙂

    0
  • E
    Mod

    danke, wurde umgesetzt. 🙂

    0
  • E
    Mod

    Für den anstehenden Code Review schlage ich folgende Reihenfolge vor (analog Start):

    Bootloader 1
Bootloader 2
Kernel:
    gdt_install();
    idt_install();
    timer_install();
    keyboard_install();
    mouse_install(); <--- neu  :live: 
    syscall_install();
    setup_x87_fpu();
    paging_install();
    heap_install();
    tasking_install();
    pciScan();
    ...

    Damit decken wir die wesentlichen Elemente von PrettyOS ab.

    0
  • ?

    Revision 309
    Wenn schon, denn schon: 🙂

    //memset((void*)tictactoe, 0, 18); // tictactoe has two bytes!
memset((void*)tictactoe, 0, sizeof(tictactoe));

    Aber folgendes stört weiterhin:

    memset((void *)ph->vaddr, 0, ph->memsz); // to set the bss (Block Started by Symbol) to zero

    Sollte das den Absturz auf dem realen PC verhindern, dann wird irgendwo im Quellcode auf nicht initialisierte Variablen zugegriffen.
    Das wiederum wird der tatsächliche Grund für den Absturz sein.

    0
  • E
    Mod 

    program_header_t* ph = (program_header_t*)header_pos;

    elf.c, line 138
    Hier wird ein Pointer auf die Instanz ph vom Typ struct program_header_t auf konkrete Werte gesetzt, wenn ich mich nicht täusche, oder?

    Es stürzt nichts mehr ab, alles läuft gut. Nur einige alte PC von Cuervo machen unverständliche Probleme mit Floppy/DMA beim Laden.

    memset((void*)tictactoe, 0, sizeof(tictactoe));

    Danke, wird so eingebaut.

    0
  • ?

    Revision 313
    Um das TS bit in CR0 zu löschen geht auch CLTS:

    // set TS in cr0 to zero
// uint32_t cr0;
// __asm__ volatile("mov %%cr0, %0": "=r"(cr0)); // read cr0
// cr0 &= ~0x8; // reset the TS bit (no. 3) in CR0 to disable #NM
// __asm__ volatile("mov %0, %%cr0":: "r"(cr0)); // write cr0

__asm__ ("CLTS"); // CLearTS
    0
  • E
    Mod

    Hey, so einfach geht das? 😃

    Gibt es dauch den entsprechenden befehl zum Setzen?

    0
  • ?

    Den gibt es nicht. Aber könnte es sein, daß das TS bit in der "task_switch" sowieso schon von der CPU gesetzt wurde?

    0
  • E
    Mod

    Da wir software task switching durchführen eher nicht. 🙂

    0
  • ?

    Revision 341
    "vidmem" ist ein uint16_t*. Deshalb kopiert "2*i" nur jedes zweite Zeichen vom screenshot:

    // video.c
static void catchVidmem()
{
uint16_t* vidmem = (uint16_t*) 0xB8000;
(...)
// videoscreen[j] = *(uint8_t*)(vidmem + 2*i);
videoscreen[j] = *(uint8_t*)(vidmem + i);
(...)
}
    0
  • E
    Mod

    @+gjm+: Vielen Dank! Keine Ahnung, bei welcher "Aufräumaktion" das passiert ist, sieht einfacher aus und funktioniert, daher sofort implementiert. 🙂 👍

    0
  • E
    Mod

    In Rev. 342 korrigiert: ctrl+s: process, ctrl+t: thread

    0
  • C

    Fehler in 344:

    Bei "hello.elf":
    http://prettyos.fanofblitzbasic.de/error.png QEMU
    http://prettyos.fanofblitzbasic.de/error2.png VirtualBox
    wenn man scrollt.. sieht aber witzig aus^^

    0
  • ?
     

    // os.h

//static const uint8_t USER_LINES = 46;
static const uint8_t USER_LINES = 42;

    Sonst fährt der Zug zeilenweise mit nach oben. 🙂

    0
  • M

    Die Lösung (aber nicht deine 😉 ) Ist bereits in Arbeit 🙂

    0
  • ?

    Kleine Unlogik in der keyboard.c, aber offenbar ohne Auswirkungen:

    // keyboard.c

uint8_t checkKQ_and_return_char()
{
 cli();       // 1. interrupts verbieten

 if (...)
 {
  (...)
  return KEY; // <- ! hier kann die funktion auch verlassen werden !
 }

 sti();       // 2. interrupts wieder zulassen
 return 0;    // 3. funktion verlassen
}
    0
  • ?

    (setScrollField(), syscall, hm, naja. 🙂 )

    Revision 362

    Die VMs haben es mal wieder voll drauf. VMWARE initialisiert das eingestellte RAM bei Start nicht mit Null. Das hat zur Folge, daß die BSS-Sektion der KERNEL.BIN nicht mit Null, sondern mit Speichermüll (bzw. eigentlich überhaupt nicht) initialisiert wird. Darum läuft VMWARE z.Zt. nicht. Ein übler Hack könnte das Problem beseitigen:

    // ckernel.c 362

int main()
{
//.bss          0x00052de0     0x26b24 -> steht so in der KERNEL.MAP und kann jedesmal anders sein
 memset((void *)0x00052de0, 0, 0x26b24); //  :open_mouth: 

 init();

(...)
}

    Hoffentlich fällt Euch was besseres ein, da das auch die realen PCs betrifft.

    0
  • E
    Mod 

    memset(&_bss_start,0x0,(uintptr_t)&_kernel_end - (uintptr_t)&_bss_start);

    Danke für den Hinweis! Wir hatten das früher schon mal in kernel.asm, wurde offenbar entfernt, weil der Kernel keine elf-Datei ist, sondern binär. Das passt aber auch gut zu Beginn von init() in main().

    0
  • E
    Mod

    @ +gjm* et.al.: wir könnten mal jemand brauchen, der uns bei EHCI noch einige Tipps gibt, was da bei real Hardware noch schief läuft. Manchmal haben wir J-State anstelle Hi-Speed (könnte ein Zeitproblem sein), und bei modernen PCs mit ext. capabilities noch Host System Error, den wir nicht verstehen. Da hängen wir noch, was den USB-Fortschritt hemmt. Da wäre konkrete Hilfe durch Spürnasen sehr viel wert. Zum Glück läuft das Ganze bei qemu. Da kann man unter Win aber keine USB-devices vom Host durchreichen, soweit ich weiß.

    0
  • ?

    Bei der Entwicklung des USB-Treibers gibt es mittlerweile zuviele mögliche Fehlerursachen. Beispielsweise kann die Ursache für den "Host System Error" auch ein völlig anderes PCI-Gerät gewesen sein.

    Um die möglichen Fehlerursachen drastisch einzuschränken, stelle ich mal zur Diskussion, den USB-Treiber unabhängig von PrettyOS zu entwickeln.

    Dazu müsste eine Version von PrettyOS aufs wesentliche reduziert werden (PM, ev. Paging, Eingabe, Ausgabe). Diese Version könnte dann umbennant werden in PrettyDD (Pretty Driver Development 🙂 ) und soll einzig und alleine nur für die Entwicklung von Treibern dienen. Auf/mit PrettyDD entwickelte Treiber sollten dann problemlos ins (one and only) PrettyOS integriert werden können.

    0
Anmelden zum Antworten