Sourcecode Fortschritt

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.

Mr X

Revision 451:

- console.c/video.c: Videomemory wird auf 0 statt komischer, unverständlicher Werte gesetzt
- Scheduler: Erste Umformungen Richtung neuer Scheduler (Umbenennungen)
- list.c: Fehlerkorrekturen in Ring-Funktionen
- Korrekturen, um _DIAGNOSIS_ wieder funktionsfähig zu machen
- Funktion memmove eingebaut (Dank an den Autor)
- Bootscreen leicht verändert (vertikal zentriert und Code vereinfacht). Ist auch wieder aktiviert
- Diverse Kleinigkeiten, Entfernung überflüssigen Codes und Stilkorrekturen

Erhard Henkes

Rev. 452:

- Der Handshake-qTD zerstörte bei manchen Mass Storage Devices die Konfiguration
- Dennoch lief es nach Entfernen des schädlichen Handshake am IN endpoint nicht richtig
- set_config setzt nämlich das toggle an den endpoints auf 0, so dass die Vorgehensweise mit 0 zu beginnen klappte
- nun wird das toggle endpoint-spezifisch in der Device Struktur gespeichert und ständig pro endpoint geswitcht

Fazit: kein handshake-qTD, abwechselndes togglen pro endpoint OUT und IN

usb spec:

The host always initializes the first transaction of a bus transfer to the DATA0 PID with a configuration event. The second transaction uses a DATA1 PID, and successive data transfers alternate for the remainder of the bulk transfer. The data packet transmitter toggles upon receipt of ACK, and the receiver toggles upon receipt and acceptance of a valid data packet.
Fig. 8-30 zeigt ein ACK, ob das vom EHCI kommt?

Erhard Henkes

Rev. 453:

Die USB-Diagnose-Ausgaben (vor allem OK und QH/qTD) wurden weitgehend aus dem Standard genommen (kann per define in os.h aktiviert werden), damit man die SCSI CBW und CSW Abfolge klarer erkennt.

Hier ein typischer Ablauf auf real PC mit 16 GB USB stick mit drei endpoints (die für MSD notwendigen bulk IN und bulk OUT, zusätzlich einer für interrupt):

> function: startHostController (reset HC)
DeactivateLegacySupport: eecp = 0070h
eecp = 0070h, eecp_id = 0001h

BIOS did not own the EHCI. No action needed.

> function: enablePorts
> function: resetPort 1
> function: resetPort 2
> function: resetPort 3
> function: resetPort 4
> function: resetPort 5
> function: resetPort 6
> Press key to close this console. <<<

PrettyOS [Version 0.0.0.453] Console 1: EHCI Ports
--------------------------------------------------------------------------------

> function: resetPort 2
port 2: 00001005h, line: 00h SE0,power on, enabled, EHCI owned
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
USB specification: 2.0 USB class: 0000h
USB subclass: 0000h USB protocol 0000h
max packet size: 64
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
total length: 39 number of interfaces: 1

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
interface number: 0 number of endpoints: 3
interface class: 8
interface subclass: 6
interface protocol: 80

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
endpoint in/out: out endpoint number: 1
attributes: 02h
attributes: bulk - no sync - data endpoint
max packet size: 512

> Press key to go on with data analysis from config descriptor. <<<

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
endpoint in/out: in endpoint number: 2
attributes: 02h
attributes: bulk - no sync - data endpoint
max packet size: 512

> Press key to go on with data analysis from config descriptor. <<<

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
endpoint in/out: in endpoint number: 3
attributes: 03h max packet size: 64

> Press key to go on with data analysis from config descriptor. <<<

language: German
USBest Technology
USB Mass Storage Device
0000000000040F

dev: 2 interface: 0 endpOUT: 1 endpIN: 2
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

> SCSI: inquiry
00h 80h 02h 02h 1Fh 00h 00h 00h 55h 44h 49h 53h 4Bh 20h 20h 20h 50h 44h 55h 30h
31h 2Dh 31h 36h 47h 20h 38h 38h 48h 32h 2Eh 30h 30h 2Eh 30h 30h
UDISK PDU01-16G 88H2.00.00

55h 53h 42h 53h 12h 42h 42h 42h 00h 00h 00h 00h 00h
Do Ping<-- command
- - - - - - - - - - - press key - - - - - - - - - - -

> SCSI: test unit ready
55h 53h 42h 53h 00h 42h 42h 42h 00h 00h 00h 00h 00h
Do Ping<-- command
- - - - - - - - - - - press key - - - - - - - - - - -

> SCSI: request sense
70h 00h 00h 00h 00h 00h 00h 0Ah 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h

55h 53h 42h 53h 03h 42h 42h 42h 00h 00h 00h 00h 00h
Do Ping<-- command

Results of "request sense":
Valid: Sense data are not SCSI compliant
Response Code: Current errors, fixed format
Sense Key: No Sense
- - - - - - - - - - - press key - - - - - - - - - - -

> SCSI: read capacity
01h E1h FFh FFh 00h 00h 02h 00h

55h 53h 42h 53h 25h 42h 42h 42h 00h 00h 00h 00h 00h
Do Ping<-- command
Capacity: 15872 MB, Last LBA: 31588351, block size 512

- - - - - - - - - - - press key - - - - - - - - - - -

> SCSI: read sector: 0
EBh 58h 90h 4Dh 53h 44h 4Fh 53h 35h 2Eh 30h 00h 02h 10h 26h 00h 02h 00h 00h 00h
00h F8h 00h 00h 3Fh 00h FFh 00h 00h 00h 00h 00h 00h 00h E2h 01h 31h 3Ch 00h 00h
00h 00h 00h 00h 02h 00h 00h 00h 01h 00h 06h 00h 00h 00h 00h 00h 00h 00h 00h 00h
00h 00h 00h 00h 00h 00h 29h FEh F5h 5Eh 84h 4Eh 4Fh 20h 4Eh 41h 4Dh 45h 20h 20h
20h 20h 46h 41h 54h 33h 32h 20h 20h 20h 33h C9h 8Eh D1h BCh F4h 7Bh 8Eh C1h 8Eh
D9h BDh 00h 7Ch 88h 4Eh 02h 8Ah 56h 40h B4h 08h CDh 13h 73h 05h B9h FFh FFh 8Ah
F1h 66h 0Fh B6h C6h 40h 66h 0Fh B6h D1h 80h E2h 3Fh F7h E2h 86h CDh C0h EDh 06h
41h 66h 0Fh B7h C9h 66h F7h E1h 66h 89h 46h F8h 83h 7Eh 16h 00h 75h 38h 83h 7Eh
2Ah 00h 77h 32h 66h 8Bh 46h 1Ch 66h 83h C0h 0Ch BBh 00h 80h B9h 01h 00h E8h 2Bh
00h E9h 48h 03h A0h FAh 7Dh B4h 7Dh 8Bh F0h ACh 84h C0h 74h 17h 3Ch FFh 74h 09h
B4h 0Eh BBh 07h 00h CDh 10h EBh EEh A0h FBh 7Dh EBh E5h A0h F9h 7Dh EBh E0h 98h
CDh 16h CDh 19h 66h 60h 66h 3Bh 46h F8h 0Fh 82h 4Ah 00h 66h 6Ah 00h 66h 50h 06h
53h 66h 68h 10h 00h 01h 00h 80h 7Eh 02h 00h 0Fh 85h 20h 00h B4h 41h BBh AAh 55h
8Ah 56h 40h CDh 13h 0Fh 82h 1Ch 00h 81h FBh 55h AAh 0Fh 85h 14h 00h F6h C1h 01h
0Fh 84h 0Dh 00h FEh 46h 02h B4h 42h 8Ah 56h 40h 8Bh F4h CDh 13h B0h F9h 66h 58h
66h 58h 66h 58h 66h 58h EBh 2Ah 66h 33h D2h 66h 0Fh B7h 4Eh 18h 66h F7h F1h FEh
C2h 8Ah CAh 66h 8Bh D0h 66h C1h EAh 10h F7h 76h 1Ah 86h D6h 8Ah 56h 40h 8Ah E8h
C0h E4h 06h 0Ah CCh B8h 01h 02h CDh 13h 66h 61h 0Fh 82h 54h FFh 81h C3h 00h 02h
66h 40h 49h 0Fh 85h 71h FFh C3h 4Eh 54h 4Ch 44h 52h 20h 20h 20h 20h 20h 20h 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 00h 00h 00h 00h 00h
00h 00h 00h 00h 00h 00h 00h 00h 0Dh 0Ah 52h 65h 6Dh 6Fh 76h 65h 20h 64h 69h 73h
6Bh 73h 20h 6Fh 72h 20h 6Fh 74h 68h 65h 72h 20h 6Dh 65h 64h 69h 61h 2Eh FFh 0Dh
0Ah 44h 69h 73h 6Bh 20h 65h 72h 72h 6Fh 72h FFh 0Dh 0Ah 50h 72h 65h 73h 73h 20h
61h 6Eh 79h 20h 6Bh 65h 79h 20h 74h 6Fh 20h 72h 65h 73h 74h 61h 72h 74h 0Dh 0Ah
00h 00h 00h 00h 00h ACh CBh D8h 00h 00h 55h AAh
XMSDOS5.0&?1<)^NO NAME FAT32 3{|NV@sf@f?AfffF_u8w2fFf+H}}t<t}}f`f;FJfjfPS
fh~ AUV@UFBV@fXfXfXfXf3fNfffvV@faTf@IqNTLDR Remove disks or other media.Di
sk errorPress any key to restartU

55h 53h 42h 53h 28h 42h 42h 42h 00h 00h 00h 00h 00h
Do Ping<-- command
- - - - - - - - - - - press key - - - - - - - - - - -
--------------------------------------------------------------------------------
Port: 2, device attached

Erhard Henkes

Rev. 454:

Non-MSD werden nun nicht mehr dem MSD-Test unterzogen. Dieses lästige Procedere wird nun abgekürzt, sobald die Interface Class nicht gleich 0x08 ist.

PrettyOS [Version 0.0.0.454] Console 1: EHCI Ports
--------------------------------------------------------------------------------

> function: resetPort 1
port 1: 00001005h, line: 00h SE0,power on, enabled, EHCI owned
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
USB specification: 2.0 USB class: 00EFh
USB subclass: 0002h USB protocol 0001h
max packet size: 64
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
total length: 783 number of interfaces: 4

length: 8 type: 11 unknown

> Press key to go on with data analysis from config descriptor. <<<

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
interface number: 0 number of endpoints: 1
interface class: 14
interface subclass: 1
interface protocol: 0

...
...

language: German
Chicony Corp.
QEye 2.0M pixel

dev: 1 interface: 1 endpOUT: 0 endpIN: 0
This is no Mass Storage Device! MSD test cannot be carried out.

void testMSD(uint8_t devAddr, uint8_t config)
{
    if (usbDevices[devAddr].InterfaceClass != 0x08)
    {
        textColor(0x0C);
        printf("\nThis is no Mass Storage Device! MSD test cannot be carried out.");
        textColor(0x0F);
        waitForKeyStroke();
    }
    else
    {
        // maxLUN (0 for USB-sticks)
        usbDevices[devAddr].maxLUN = 0;

        // start with correct endpoint toggles 
        usbDevices[devAddr].ToggleEndpointInMSD  = 0;
        usbDevices[devAddr].ToggleEndpointOutMSD = 0;
//...

Erhard Henkes

Rev. 455:

Sector 0 (bootsector) wird ausgelesen und analysiert.

1GB Stick mit FAT16:

OEM name:           MSDOS5.0    byte per sector:        512                     
sectors per cluster:    32      number of FAT copies:   2                       
max root dir entries:   512     total sectors (<65536): 0                       
media Descriptor:       F8h     sectors per FAT:        251                     
sectors per track:      1       heads/pages:            1                       
hidden sectors:         0       total sectors (>65535): 2050560                 
FAT 12/16:              FAT16

512 MB Stick mit FAT16:

OEM name:           MSDOS5.0    byte per sector:        512                     
sectors per cluster:    16      number of FAT copies:   2                       
max root dir entries:   512     total sectors (<65536): 0                       
media Descriptor:       F8h     sectors per FAT:        246                     
sectors per track:      63      heads/pages:            255                     
hidden sectors:         0       total sectors (>65535): 1007614                 
FAT 12/16:              FAT16

http://de.wikipedia.org/wiki/File_Allocation_Table

Der Mediadeskriptor 0xF8 bedeutet "Festplatte".