4. PrettyOS Fehler-/Testthread

PrettyOS Fehler-/Testthread

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

    Revision 398
    Hm, einmal würde reichen. 🙂

    // ckernel.c 398

static void init()
{
(...)
    // descriptors
    gdt_install();
    idt_install();      // cf. interrupts.asm

    // descriptors
    gdt_install();
    idt_install();      // cf. interrupts.asm

    // video
    kernel_console_init();
    clear_screen();
(...)
}
    0
  • M

    oh, das stimmt natürlich, wird geändert.
    Danke

    0
  • ?

    Revision 401
    Da haben sich einige "Rechtschreibfehler" eingeschlichen:

    // usb2.c 401
void showConfigurationDesriptor(struct usb2_configurationDescriptor* d)
(...)

    Desriptor -> Descriptor 🙂 (Btw.: Wollt ihr den CDI-Kram auch mal einsetzen?)

    0
  • M

    Ja, wir würden ihn gerne einsetzen, aber das setzt Einsatzbereitschaft voraus: Die Implementation ist nichtmal ansatzweise fertig.

    0
  • E
    Mod

    Da haben sich einige "Rechtschreibfehler" eingeschlichen

    Danke! 🙂 Bevor wir noch beim Raptor enden, haben wir es korrigiert.

    0
  • E
    Mod

    Wollt ihr den CDI-Kram auch mal einsetzen?

    Wenn Du uns beim USB bulk transfer bei der Fehlersuche hilfst, kommen wir schneller daran. 🙂

    0
  • ?

    Revision 434

    Auf meinem realen PC funktioniert eine stark zusammengestrichene testMSD() perfekt:

    // usb2_msd.c 434

void testMSD(uint8_t devAddr)
{
    // maxLUN (0 for USB-sticks)
    usbDevices[devAddr].maxLUN = 0;
    usbTransferBulkOnlyMassStorageReset(devAddr, usbDevices[devAddr].numInterfaceMSD); // Reset Interface
    ///////// step 7: send SCSI comamnd "read(10)", read one block (512 byte) from LBA ..., get Status
    textColor(0x09); printf("\n>>> SCSI: read(10)"); textColor(0x0F);
    usbSendSCSIcmd(devAddr, usbDevices[devAddr].numEndpointOutMSD, usbDevices[devAddr].numEndpointInMSD, 0x28, 0, 1, true);
    waitForKeyStroke();
}

    Aber ein zweiter Aufruf von usbSendSCSIcmd() innerhalb von testMSD() geht regelmäßig schief. Irgendwas stimmt mit den blöden Adressen noch nicht.

    VMs schummeln ja immer in dieser Hinsicht. 😡

    0
  • E
    Mod

    stimmt, der einmalige Aufruf einer Funktion ging bisher immer recht gut, nur die Abfolge macht Probleme. Schau dir bitte mal die rev. 435 an.

    Noch besser: die Version 436 mit aktiviertem #define _USB_DIAGNOSIS_ (ging vorher nicht fehlerfrei)

    Ich habe noch ein "test unit ready" vor "inquiry" gesetzt, dann hakt es beim IN-endpoint bei "inquiry" aus, was zuvor an Platz eins bestens lief. Der QH/qTD-Code ist also prinzipiell ok.

    Nimmt man zweimal inquiry hintereinander:
    - erstes läuft gut
    - beim zweiten "inquiry" wird der IN-QueueHead nicht mehr ausgeführt

    dev: 3 interface: 0 endpOUT: 2 endpIN: 1
    USB2: usbTransferBulkOnlyMassStorageReset, dev: 3 interface: 0#
    ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    > SCSI: inquiry
    OUT part#
    IN part transfer>0#
    virtAddrBuf0 C024D000h : 00h 80h 02h 02h 1Fh 00h 00h 00h 6Dh 65h 6Dh 6Fh 72h 79h
    00h 00h 55h 53h 42h 32h 2Eh 30h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 31h 2Eh
    30h 30h
    virtAddrBuf0 C024D000h : memoryUSB2.01.00

    virtAddrBuf0 C024C000h : 55h 53h 42h 53h 12h 42h 42h 42h 00h 00h 00h 00h 00h

    Command Passed ("good status")
    qTD Status: 00h OK (no bit set)<-- data
    qTD Status: 00h OK (no bit set)<-- status

    Command Block Status Values in "good status"

    > Press key <<<
    > SCSI: inquiry
    OUT part#
    IN part transfer>0###################
    timeout - no STS_USBINT set!
    virtAddrBuf0 C0253000h : 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h
    00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h
    00h 00h
    virtAddrBuf0 C0253000h :

    virtAddrBuf0 C0252000h : 55h 53h 42h 53h AAh AAh AAh AAh AAh AAh AAh AAh AAh

    qTD Status: 80h Active - HC transactions enabled<-- data
    qTD Status: 80h Active - HC transactions enabled<-- status

    Beide an den IN-QH angehängten qTD werden nicht ausgeführt, obwohl es beim ersten Durchgang problemlos abgearbeitet wird. 😕

    0
  • E
    Mod

    Irgendwas stimmt mit den blöden Adressen noch nicht.

    @+gjm*: kannst du das genauer spezifizieren? Ich sehe beim speicher kein problem.

    Die neue Rev. 437 ist etwas besser geeignet für Versuche.

    0
  • E
    Mod

    Rev. 439 bietet nun den besten Überblick über den Transfer im qTD-Bereich.

    0
  • E
    Mod

    Mit Rev. 441 haben wir eine erste stabile Plattform bei USB Mass Storage Device erzielt. Wenn sich dies stabilisiert können wir die Floppy bald in "Rente" schicken. 😉

    0
Anmelden zum Antworten