Sourcecode Fortschritt

Erhard Henkes

tatOS: http://code.google.com/p/tatos/

Erhard Henkes

Rev. 434:

bei real PC hängt es im IN-Zweig von usbSendSCSIcmd

Erhard Henkes

rev. 435: Zwischenstand

einige verbesserungen, real PC problem aber noch nicht gelöst

Erhard Henkes

Rev. 436: da +gjm+ auf speicherprobleme tippt, hier eine korrigierte Version mit #define _USB_DIAGNOSIS_ aktiviert.

Hier der aktuelle Ablauf auf PC mit meinem 1GB stick:

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

> SCSI: inquiry
OUT part#
IN part transfer>0#
virtAddrBuf0 C0252000h : 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 C0251000h : 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: test unit ready
OUT part#
IN part transfer==0###################
timeout - no STS_USBINT set!
virtAddrBuf0 C0257000h : 55h 53h 42h 53h AAh AAh AAh AAh AAh AAh AAh AAh AAh

qTD Status: 00h OK (no bit set)<-- data
qTD Status: 80h Active - HC transactions enabled<-- status

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

virtAddrBuf0 C025C000h : 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

> Press key <<<

Wie man sieht, steigt der Ablauf beim ersten "test unit ready" (der zweite SCSI command nach dem ersten "inquiry") Beim IN-Endpoint mit seinem QH/qTD Essemble aus.

So sieht dort der Code aus:

printf("\nIN part");

    pOpRegs->ASYNCLISTADDR = paging_get_phys_addr(kernel_pd, QH_In);

    // IN qTDs 
    void* QTD_In;
    void* next = createQTD_Handshake(OUT); // Handshake
    if (TransferLength > 0)
    {
        printf(" transfer>0");
        next = StatusQTD = createQTD_MSDStatus((uintptr_t)next, 1); // next, toggle // IN 13 byte
        QTD_In = DataQTD = createQTD_IO((uintptr_t)next, IN,  0, TransferLength); // IN/OUT DATA0, ... byte
    }
    else
    {
        printf(" transfer==0");
        QTD_In = StatusQTD = createQTD_MSDStatus((uintptr_t)next, 0); // next, toggle // IN 13 byte
    }

    // IN QH
    createQH(QH_In, paging_get_phys_addr(kernel_pd, QH_In), QTD_In, 1, device, endpointIn, 512); // endpoint IN/OUT for MSD

    performAsyncScheduler();

    if (TransferLength) // byte
    {
        printf("\n");
        showPacket(DataQTDpage0,TransferLength);
        if ((TransferLength==512) && (TransferLength==36)) // data block, inquiry feedback
        {
            showPacketAlphaNumeric(DataQTDpage0,TransferLength);
        }
    }

    printf("\n");
    showPacket(MSDStatusQTDpage0,13);

    if( ( (*(((uint32_t*)MSDStatusQTDpage0)+3)) & 0x000000FF ) == 0x0 )
    {
        printf("\nCommand Passed (\"good status\") ");
    }
    if( ( (*(((uint32_t*)MSDStatusQTDpage0)+3)) & 0x000000FF ) == 0x1 )
    {
        printf("\nCommand failed");
    }
    if( ( (*(((uint32_t*)MSDStatusQTDpage0)+3)) & 0x000000FF ) == 0x2 )
    {
        printf("\nPhase Error");
    }

    // transfer diagnosis
    showStatusbyteQTD(DataQTD);   printf("<-- data");   // In/Out Data
    showStatusbyteQTD(StatusQTD); printf("<-- status"); // In CSW

Mr X

Muss man extra committen, nur um _USB_DIAGNOSIS_ zu aktivieren?

Erhard Henkes

Das lief leider nicht fehlerfrei. Ich wollte +gjm+ nicht zumuten, die entsprechende Version zumindest lauffähig zu bekommen.

Den Ausgabe-Bug habe ich noch übersehen, bitte mit ODER-Verknüpfung anstelle UND:

if ((TransferLength==512) || (TransferLength==36)) // data block, inquiry feedback
{
    showPacketAlphaNumeric(DataQTDpage0,TransferLength);
}

Erhard Henkes

Rev. 437:

ehci/usb:

- void performAsyncScheduler(bool stop) <--- für control transfers mit stop (sonst laufen die nicht), in usbSendSCSIcmd ohne stop (mit stop wird noch der cmd auf OUT ausgeführt, aber nicht der IN zweig)

- QHs und qTD werden analysiert

- zwei QHs (für OUT und IN) im asyncScheduler, die aufeinander zeigen

Ergebnis:
a) in VMWare perfekt
b) real PC:

...
1648000h <-- QH_Out
IN part
asyncList: 01649000h <-- QH_In transfer>0#
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
memoryUSB2.01.00

55h 53h 42h 53h 12h 42h 42h 42h 00h 00h 00h 00h 00h

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

Command Block Status Values in "good status"

> Analyze Async List <<<
asyncList: 01649000h
USB status: 00008000h
Asynchronous Schedule Status

> Press key <<<
> SCSI: test unit ready
OUT part
asyncList: 01649000h <-- QH_Out
IN part
asyncList: 0164F000h <-- QH_In transfer==0###################
timeout - no STS_USBINT set!
55h 53h 42h 53h AAh AAh AAh AAh AAh AAh AAh AAh AAh

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

> Analyze Async List <<<
asyncList: 01649000h
USB status: 00008000h
Asynchronous Schedule Status

> Press key <<<

Erhard Henkes

Rev. 438:
mit Analyse des Fortgangs des Async. Schedulers

Den Fortgang im Async. Scheduler sieht man an aS und nextQH.

Den Fortgang über eine qTD-Kette sieht man hier sehr gut:
next qTD <--- auszuführender qTD
curr qTD <--- zuletzt ausgeführter qTD

hier ist alles ok:

> SCSI: inquiry
OUT part
asyncList: 01663000h <-- QH_Out
IN part transfer>0
before aS:
aS: 01663000h nextQH: 01664000h
curr qTD: 00000000h next qTD: 01665000h

> Press key <<<#
after aS:
aS: 01664000h nextQH: 01663000h
curr qTD: 01667000h next qTD: 00000000h

> Press key <<<
00h 80h 02h 02h 1Fh 00h 00h 00h 41h 36h 30h 43h 30h 37h 30h 34h 46h 6Ch 61h 73h
68h 20h 44h 69h 73h 6Bh 20h 20h 20h 20h 20h 20h 38h 2Eh 30h 37h
A60C0704Flash Disk 8.07

55h 53h 42h 53h 12h 42h 42h 42h 00h 00h 00h 00h 00h

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

Command Block Status Values in "good status"

> Analyze Async List <<<
asyncList (phys): 01664000h DataQTD (phys): 01669000h
USB status: 00000000h

hier bleibt er zwischen QH_Out und QH_In stecken:

> SCSI: read capacity
OUT part
asyncList: 01687000h <-- QH_Out
IN part transfer>0
before aS:
aS: 01687000h nextQH: 01688000h
curr qTD: 00000000h next qTD: 01689000h

> Press key <<<#
after aS:
aS: 01687000h nextQH: 01688000h
curr qTD: 01689000h next qTD: 00000000h

> Press key <<<
00h 00h 00h 00h 00h 00h 00h 00h

55h 53h 42h 53h AAh AAh AAh AAh AAh AAh AAh AAh AAh

qTD Status: 00h OK (no bit set)<-- command
qTD Status: 80h Active - HC transactions enabled<-- data
qTD Status: 80h Active - HC transactions enabled<-- status
Capacity: 0 MB, Last LBA: 0, block size 0

> Analyze Async List <<<
asyncList (phys): 01687000h DataQTD (phys): 0168D000h
USB status: 00002000h
Reclamation

Aktuelle Fragestellung:
Was hemmt auf real PC den Übergang von QH_Out nach QH_In? Konstruktive Ideen zur Klärung dieser Frage werden gerne entgegen genommen.

Hintergrund:
Der EHCI speichert in seinem OpRegister ASYNCLISTADDR (Current Asynchronous List Address Register) die physische Adresse des QH, der als letztes verwendet wurde bzw. als nächstes ausgeführt wird (round robin). Steuergrößen beim Ablauf sind das H-Bit im QH und das Reclamation Bit im USB Status-Register.
Innerhalb des QH zeigt next qTD auf den qTD, der als nächstes ausgeführt wird. Der zuletzt ausgeführte qTD wird in current qTD gespeichert.

ehci spec 1.0, 4.10.5:

4.10.5 Follow Queue Head Horizontal Pointer
The host controller must use the horizontal pointer in the queue head to the next schedule data structure
when any of the following conditions exist:
• If the Active bit is a one on exit from the Execute Transaction state, or
• When the host controller exits the Write Back qTD state, or
• If the Advance Queue state fails to advance the queue because the target qTD is not active, or
• If the Halted bit is a one on exit from the Fetch QH state.
There is no functional requirement that the host controller wait until the current transaction is complete
before using the horizontal pointer to read the next linked data structure. However, it must wait until the
current transaction is complete before executing the next data structure.

Erhard Henkes

Rev. 439:

Wenn der Übergang von QH1 zu QH2 ein Problem ist, dann trennen wir die beiden eben wieder und lassen sie auf sich selbst zeigen. Diese Version konzentriert sich auf den Ablauf bei den qTD-Ketten und zeigt daher die entsprechenden physischen Speicher der qTD an, damit man mit curr qTD und next qTD beobachten kann, wie weit es läuft.

In VMWare sehe ich einen perfekten Ablauf, d.h. der Code ist von der Ablauflogik her ok.

Auf real PC werden die qTD im IN-Zweig entweder vollständig oder teilweise nicht ausgeführt. Trotz der optimalen Beobachtungsmöglichkeit bleibt der Grund noch im Dunkeln. Daher wurde bisher noch kein "Hot Fix" gefunden.

Erhard Henkes

Rev. 440:

sorry, hatte vergessen das H-Bit zu setzen am IN-endpoint (nach dem Trennen der beiden QH), hilft aber auch nichts, aber ohne ist es nicht OK in der async List, was VMWare allerdings egal ist, so wie es aussieht.

Der erste SCSI command läuft sauber durch:

PrettyOS [Version 0.0.0.440] Console 7: EHCI Ports
--------------------------------------------------------------------------------
language: German
JetFlash
Mass Storage Device
N014IM75

USB2: SET_CONFIGURATION 1
USB2: GET_CONFIGURATION 1
dev: 1 interface: 0 endpOUT: 1 endpIN: 2
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

> SCSI: inquiry
OUT part
asyncList: 0166D000h <-- QH_Out
before aS:
aS: 0166D000h nextQH: 0166D000h
curr qTD: 00000000h next qTD: 0166F000h
after aS:
aS: 0166D000h nextQH: 0166D000h
curr qTD: 0166F000h next qTD: 00000000h
IN part
asyncList: 0166E000h <-- QH_In transfer>0
handshakeQTD: 01671000h StatusQTD: 01673000h DataQTD: 01675000h
before aS:
aS: 0166E000h nextQH: 0166E000h
curr qTD: 00000000h next qTD: 01675000h
after aS:
aS: 0166E000h nextQH: 0166E000h
curr qTD: 01671000h next qTD: 00000000h
00h 80h 02h 02h 1Fh 00h 00h 00h 4Ah 65h 74h 46h 6Ch 61h 73h 68h 54h 72h 61h 6Eh
73h 63h 65h 6Eh 64h 20h 31h 36h 47h 42h 20h 20h 38h 2Eh 30h 37h
JetFlashTranscend 16GB 8.07

55h 53h 42h 53h 12h 42h 42h 42h 00h 00h 00h 00h 00h

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

Command Block Status Values in "good status"

USB status: 00000000h

> Press key <<<

Am IN queue head sieht man die Kette:
DataQTD: 01675000h
StatusQTD: 01673000h
handshakeQTD: 01671000h

Vor Start des async Schedulers:
curr qTD: 00000000h
next qTD: 01675000h

Nach Ende des async Schedulers:
curr qTD: 01671000h
next qTD: 00000000h

Der async Scheduler läuft also die qTD-Kette sauber von 01675000h bis 01671000h durch.

Auch ein zweites "inquiry" mit vorgestelltem Reset klappt!
Das führt zu der nächsten Version:

Erhard Henkes

Rev. 441:

Diese Version läuft endlich mit real PC und einem 16 GB usb-Stick ohne Probleme durch. Geschafft!

Auch ein 512 MB Stick läuft.

Ein 1 GB stick "bockt" allerdings, aber das ist jetzt die USB MSD Baustelle. Die EHCI QH/qTD Seite steht. Unsere Analyse zeigt den Grund für das Nicht-Ausführen eines qTD leider noch nicht an.

Es ist erstaunlich, dass wir den usbTransferBulkOnlyMassStorageReset benötigen, denn das CSW war ja ok.

Ansonsten: Die "device (not) attached" Anzeige in showPORTSC() im Modul ehci.c wurde zeitlich vor diese Aktionen gelegt, wo es hingehört.

Erhard Henkes

Rev. 442:

strncpy repariert

Erhard Henkes

Rev. 443:

strncpy ersetzt

Dank an MrX!

Erhard Henkes

Rev. 444:

nun mit NAK/NYET counter (QH overlay DWORD 5, bit 4:1), funktioniert nur, wenn mit RL ungleich null nachgeladen wird. Wir stellen daher RL auf 15 ein.

Erhard Henkes

Rev. 445:

- delay (läuft im thread nicht gut) durch sleepMilliseconds ersetzt.
- Ablauf im asyncScheduler verbessert
- Durchlauf beschleunigt, dafür an den richtigen Stellen gewartet

Erhard Henkes

Rev. 446:

Nun können auch usb-Sticks mit 3 endpoints (2 bulk, 1 interrupt) eingesetzt werden. Die Unterscheidung erfolgt über attributes (0x2 bulk, 0x3 interrupt).

siehe: http://www.beyondlogic.org/usbnutshell/usb5.htm#EndpointDescriptors

Bits 0..1 Transfer Type

00 = Control
01 = Isochronous
10 = Bulk
11 = Interrupt

Erhard Henkes

Rev. 447:

Zwischenstand: GetStatus, ClearFeature(Halt) und MSD_ResetRecovery eingebaut

Erhard Henkes

Rev. 448:

Ergebnisanalyse bei "request sense" ergänzt, damit wir das Ergebnis von test unit ready sehen.

http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command

Erhard Henkes

Rev. 449:

Tipp von +gjm* eingearbeitet.

textColor(0x09); printf("\n>>> SCSI: inquiry"); textColor(0x0F);
usbTransferSetConfiguration(devAddr,config);  // <--- !!!    
usbSendSCSIcmd(devAddr, usbDevices[devAddr].numInterfaceMSD, usbDevices[devAddr].numEndpointOutMSD, usbDevices[devAddr].numEndpointInMSD, 0x12, 0, 36); // dev, endp, cmd, LBA, transfer length
statusByte = BYTE1(*(((uint32_t*)MSDStatusQTDpage0)+3));

Hoffentlich die erwünschte Stabilisierung.

Erhard Henkes

Rev. 450:

Erster Durchbruch bei USB2/SCSI: alle Sticks gehen, auch Tobikings Laptop, und bei +gjm+ geht es hoffentlich auch noch mit dieser Version. Ihm gebührt unser größter Dank für das Finden des fehlenden Puzzleteils.

Bitte breit testen!

Der nun ausgelassene handshake ist übrigens nicht die Komplettlösung. Tauscht man usbTransferSetConfiguration(devAddr,config) gegen den Reset des Interface (ohne geht es dann nicht!) aus, so fallen wieder einzelne qTD aus (status 0x80).

Ein ganz vermintes Gelände!

usbTransferSetConfiguration(devAddr,config) hat also eine wesentliche "Nebenwirkung", die wir bisher nicht gefunden haben. Die gilt es zu verstehen. Also schauen wir in die usb 2.0 spec:

9.1.1.5 Configured
Before a USB device’s function may be used, the device must be configured. From the device’s perspective, configuration involves correctly processing a SetConfiguration() request with a non-zero configuration value. Configuring a device or changing an alternate setting causes all of the status and configuration values associated with endpoints in the affected interfaces to be set to their default values. This includes setting the data toggle of any endpoint using data toggles to the value DATA0.