4. PrettyOS Fehler-/Testthread

PrettyOS Fehler-/Testthread

  • 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
  • E
    Mod

    Beispielsweise kann die Ursache für den "Host System Error" auch ein völlig anderes PCI-Gerät gewesen sein.

    Das veretehe ich noch nicht ganz, wie wir durch eine "abgespeckte stabile Version" bei der EHCI-Entwicklung Fehler durch andere PCI-Geräte ausschließen können. An welche Geräte denkst Du da konkret und wie schließe ich deren Fehler sicher aus? Welche Module würdest Du hier konkret weg lassen?

    0
  • M

    alle, die nicht zwingend nötig sind fürs USB-Development.
    Z.B. braucht man dann keinen Netzwerkartentreiber

    0
  • E
    Mod

    Das könnte man aber möglicherweise auch über einen #define _TEST_EHCI_ Schalter bewirken. Wenn der gesetzt ist, dann wird z.B. Netzwerk, vielleicht auch Floppy usw. nicht aktiviert.

    0
  • M

    Das ist doch Unsinn, den ganzen Code von Makros zu durchsetzen...

    0
Anmelden zum Antworten