4. PrettyOS Fehler-/Testthread

PrettyOS Fehler-/Testthread

  • 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
  • ?

    Schade :(. Ich hätte gerne zum Treiber testen ein PrettyDD gehabt, wo die ckernel.c in etwa nur noch so aussieht:

    void init()
{
  gdt_install();
  idt_install();
  paging_install();
  heap_install();
}

int main()
{
  init();
  pciScan();
  startEHCI();
  while(1){}
}

    Hier nun eine mögliche Fehlerursache für den "Host System Error":

    // ehci.c

int32_t initEHCIHostController()
{
(...)
 irq_install_handler(32 + pciDev_Array[num].irq,   ehci_handler);
 irq_install_handler(32 + pciDev_Array[num].irq-1, ehci_handler);
(...)
}

    Laut pciScan() benutzen mehrere PCI-Geräte den selben irq. So läßt sich nicht herausfinden, welches Gerät den Handler via irq aufgerufen hat bzw. darf nur das EHCI-Gerät den Handler aufrufen. Allerdings wird auf meinem realen PC ein "Host System Error" auch ausgelöst, wenn versucht wird, statt EHCI OHCI (was heißt das falsche Gerät) zu initialisieren.

    0
  • M

    Das Wort "Unsinn" bezog sich nicht auf deinen Vorschlag, +gjm+, sondern auf ehenkes Makro-Idee.
    Ich denke, es wäre sinnvoller, einen Branch dafür anzulegen, anstatt den Codes mit Makros aufzublähen, die die meisten nicht bräuchten.

    0
  • E
    Mod

    +gjm+: leider nicht der Fehler

    ich werde an einem "bare bone" pretty operating system arbeiten, damit wir EHCI ohne ballast testen können, vielleicht hilft es.

    Der Host System Error tritt übrigens beim Einschalten der async-List für den USB-Transfer auf. All die EHCI-Vorbereitungen laufen also problemlos.

    0
  • E
    Mod

    Da Host System Error in PCI-Problem ist, habe ich nun folgendes hinzugefügt in pci.c, damit wir mit PCI/EHCI/USB2 weiter kommen:

    void analyzeHostSystemError(uint32_t num)
{
     uint8_t bus  = pciDev_Array[num].bus;
     uint8_t dev  = pciDev_Array[num].device;
     uint8_t func = pciDev_Array[num].func;

	 // check pci status register of the device
     uint32_t pciStatus = pci_config_read(bus, dev, func, PCI_STATUS);

	 settextcolor(12,0);
	 printf("pci status word: %x\n",pciStatus);

	 // bits 0...2 reserved
	 if(pciStatus & 1<< 3) printf("Interrupt Status\n");
	 if(pciStatus & 1<< 4) printf("Capabilities List\n");
	 if(pciStatus & 1<< 5) printf("66 MHz Capable\n");
	 // bit 6 reserved
	 if(pciStatus & 1<< 7) printf("Fast Back-to-Back Transactions Capable\n");
	 if(pciStatus & 1<< 8) printf("Master Data Parity Error\n");
	 // DEVSEL Timing: bits 10:9 	 
	 if(pciStatus & 1<<11) printf("Signalled Target-Abort\n");
	 if(pciStatus & 1<<12) printf("Received Target-Abort\n");
	 if(pciStatus & 1<<13) printf("Received Master-Abort\n");
	 if(pciStatus & 1<<14) printf("Signalled System Error\n");
	 if(pciStatus & 1<<15) printf("Detected Parity Error\n");

     settextcolor(15,0);
}

    das zeigt bei dem PC, der Host System Error alarmiert, folgendes:
    - capabilities list
    - fast back to back transaction
    - master abort

    für "fast back to back transaction" steht bei low level:

    Wenn diese Bit gesetzt ist bedeutet dasss dass das betreffende PCI-Gerät die minimal schnelleren Back-to-Back Transfers unterstützt. Als Target werden diese Transfers immer unterstützt, aber als Master dürfen diese Transfers nur benutzt werden falls das Bit 9 im Command-Register gesetzt ist.

    bezüglich master abort: nix 😃

    0
  • ?

    Revision 374

    // ehci.c 374

void resetPort(uint8_t j)
{
  pOpRegs->PORTSC[j] |=  PSTS_POWERON;
  /*
   http://www.intel.com/technology/usb/download/ehci-r10.pdf
  (...)
  */
  pOpRegs->PORTSC[j] &= ~PSTS_ENABLED;
}

    Der Kommentar aus dem Manual betrifft PSTS_PORT_RESET und nicht PSTS_POWERON. 😕

    Mein realer PC hat lt. Scan 10 USB-Ports. Davon sind aber nur 9 "von außen" verfügbar. Deshalb wird ein Port (jedesmal der gleiche) ständig als "power on, enabled, EHCI owned" angezeigt. Unabhängig davon ob nun ein USB-Gerät "eingeklinkt" ist/wird oder nicht. Dieser Port zeigt auch (ganz selten aber) mal "J-Status" an.

    Außerdem kann es ganz, ganz, ganz selten passieren, daß die untere Statuszeile nach > 200 Sekunden für eine Sekunde Unsinn anzeigt (z.B. 55:55:5555 als Uhrzeit). 😮

    0
  • ?

    Revision 391

    // ckernel.c rev 391

static void init()
{
//    kernel_console_init();
//    clear_screen();

    gdt_install();
    idt_install();

    kernel_console_init();
    clear_screen();

    Besser die Deskriptoren zu aller erst installieren und danach den "Rest". VMWARE hatte mal in früheren Revisionen in "kernel_console_init" Mist gemacht woraus dann ein Triplefault resultierte. USB rev 391 funktioniert auf meinem realen PC auch. 👍

    0
  • E
    Mod

    USB rev 391 funktioniert auf meinem realen PC auch. 👍

    Danke für den Hinweis! Diese Version sollten wir nun zu einer stabilen, brauchbaren Basis ausbauen, bevor wir neue Experimente aufsetzen.

    0
Anmelden zum Antworten