Forum: Mikrocontroller und Digitale Elektronik Usb BOS descriptor


von Thomas Z. (usbman)


Lesenswert?

Bei der Suche nach automatisierter Treiberinstallation für USB Geräte
auf Interface Ebene bin ich auf die BOS Deskriptoren gestoßen. Damit
sollte es nach meinen Recherchen möglich sein vollautomatisch Winusb auf
einem zusätzlichen Interface zu installieren.

Wie ich das  rausgelesen habe funktioniert das ab Win8, wenn man bcdUSB
auf 2.10 stellt. Diese BOS Deskriptoren sind wohl eine USB2 Erweiterung
und wurden in die usb3 Spec aufgenommen.

Dazu gibt es auch ein Dokument von MS:
https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-os-2-0-descriptors-specification

Wie üblich bei MS ist das alles sehr kryptisch beschrieben.

- Hat da jemand Erfahrung mit?
- Kennt jemand Beispiel Deskriptoren?

Mir ist klar dass das wieder eine MS Sonderlocke ist. Wenn man damit
aber unter win eine automatische Installation ohne jegliche inf
hinbekommt, wäre mir das egal.

Den normalen Weg via 0xEE Deskriptoren kenne ich.

von Roland E. (roland0815)


Lesenswert?

Entweder ist ein (kompatibler) Treiber für den hinterlegten Descriptor 
da, oder nicht.

Nur weil zusätzlich zu den USB-eigenen noch ein M$-spezifischer 
Descriptor gezeigt wird, taucht doch nicht plötzlich ein Treiber auf?

Oder verstehe ich da was falsch?

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Roland E. schrieb:
> Nur weil zusätzlich zu den USB-eigenen noch ein M$-spezifischer
> Descriptor gezeigt wird, taucht doch nicht plötzlich ein Treiber auf?

naja genauso soll es aber funktionieren. Bedingung ist halt dass der der 
Treiber schon im System vorhanden ist was für WinUsb gegeben ist. Ich 
habe mir bisher z.B für Updates immer ein zusätzliches Hid Interface 
eingebaut oder ich habe libusb auf einem zusätzlichen Interface 
installiert.
Die Lösung HID + Funktion weist automatisch die Treiber beim ersten 
Anstecken zu. Mein Wunsch wäre sowas mit WinUsb + Funktion zu 
realisieren.

von Jim M. (turboj)


Lesenswert?

Roland E. schrieb:
> Nur weil zusätzlich zu den USB-eigenen noch ein M$-spezifischer
> Descriptor gezeigt wird, taucht doch nicht plötzlich ein Treiber auf?

Doch.

Windows fragt den Hersteller spezifischen Deskriptor ab und lädt den 
darin spezifizierten Treiber.

von Thomas Z. (usbman)


Lesenswert?

Jim M. schrieb:
> Doch.
hast du das schon mal gemacht?

Ich bau mir gerade ein Demo. Wenn man bcdUSB auf 0x210 stellt kommt ein 
GetDescriptor mit wValueHi == 0x0F für den BOS Descriptor. Im BOS 
Deskriptor wird wohl das bRequest Feld für den VendorRequest definiert

Die MS Descriptoren werden dann mit einem Vendor Request ausgelesen.
Genau da hänge ich momentan.

von 123 (Gast)


Lesenswert?

Jo das tut so, wenn die passenden treiber von MS vorhanden sind.

für RNDIS (MS USB Netzerk treiber) tut das z.B genau so,
zusätzliche descriptoren, dort wird der zu verwendende "treiber" mit 
angeben, noch ein paar spezifische marker, und Windows lädt dann den 
zugehörigen treiber von selber.

Ohne bräuchte man einen für das Gerät angepasste INF der dann auch noch 
signiert werden müsste. Wenn es sich nicht um einen Klassentreibern wie 
z.B. HID, MassStorage handelt.

Such mal nach RNDIS und Raspbery pi, da gibt es einige beispiele die das 
beschreiben.
Wie die descriptoren jetzt genau aussehen müssen, ... war mir bis jetzt 
egal, das hat linux für mich gemacht. aber wenn man was am laufen hat 
kann man sich entweder durch die kernel sourcen wühlen, oder schauen, 
was windows alles an descriptoren anzeigt / abfrägt.

ps. mir ist klar, das man die Treibersignatur auch umgehen kann, ...

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Thomas Z. schrieb:
> Den normalen Weg via 0xEE Deskriptoren kenne ich.

Damit kann man aber eben auch WinUSB laden, die neue Version 2.0 ist 
dazu nicht nötig. Die hat wohl im Wesentlichen nur Vorteile für 
Composite-Devices.

Die alte Variante mit 0xEE-Deskriptoren hab ich hier beschrieben und 
implementiert, wie man damit WinUSB lädt:

https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32#Konfiguration_der_PC-Seite

Hier eine gute Erklärung:
https://github.com/pbatard/libwdi/wiki/WCID-Devices

Meiner Erfahrung nach funktioniert das super. Gerät anstecken, wird 
sofort erkannt und Treiber geladen, und dann kann man per libusb direkt 
zugreifen. Echtes Plug&Play! Man braucht auch keine Admin-Rechte auf dem 
PC (wichtig für Anwendung in Unternehmen).

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Niklas G. schrieb:
> Thomas Z. schrieb:
>> Den normalen Weg via 0xEE Deskriptoren kenne ich.
>
> Damit kann man aber eben auch WinUSB laden, die neue Version 2.0 ist
> dazu nicht nötig. Die hat wohl im Wesentlichen nur Vorteile für
> Composite-Devices.

Eben weil ich das mit Composite Devices machen will ist die V2.0 wohl 
für mich der richtige Ansatz. Deinen Artikel kannte ich schon.
Wie gesagt ich will weg von dem inf Gewürge. Das funktioniert ja 
zunehmend schlechter seit die infs auch signiert werden müssen.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Thomas Z. schrieb:
> Eben weil ich das mit Composite Devices machen will

Achso! Dann bin ich gespannt ob es klappt 😁

Thomas Z. schrieb:
> Wie gesagt ich will weg von dem inf Gewürge.

Der Vollständigkeit halber: Das ist bei 1.0 auch nicht nötig aber das 
geht eben nicht gut mit Composite Devices.

von Thomas Z. (usbman)


Lesenswert?

ich hatte vor vielen Jahren mal ein relativ komplexes USB-Audio Device 
gebaut.
Damals wurde das FW update über einen Custom Treiber gemacht.
Die Fa von damals existiert nicht mehr, weshalb es auch nur den Treiber 
bis XP gibt. Die Audio Geschichte geht immer noch. Zuerst hatte ich mir 
überlegt das FW update via Sysex und Midi zu machen, dazu müsste ich 
aber ziemlich frickeln.

Da ich noch sämtliche Unterlagen von damals habe will ich das einfach 
mal probieren. Wenn das funktioniert werde ich das in meine allgemeinen 
USB libs einbauen.

von 123 (Gast)


Lesenswert?

Mit composide tut das auch,
ich hab mir aus HID, MSC und RNDIS auf nem raspi ein device 
zusammengezimmert,
es ist glaube ich aber wichtig, an welcher stelle dein endpoint drin 
hängt, bzw wo die MS Spezifischen discriptoren drin sind, ... sonst tut 
das anscheinend nicht.

von Thomas Z. (usbman)


Lesenswert?

So ich hab mal einen BOS Deskriptor aus einem Gerät ausgelesen und etwas 
aufbereitet. Bei diesem Descriptor ist allerdings das UUID Feld 
fehlerhaft.
Da das Gerät auch noch andere Deskriptor Fehler hat und trotzdem korrekt 
unter W10 funktioniert, gehe ich davon aus das MS das ganze Geraffel 
nicht so genau prüft.
Es wird in diesem Fall auf Interface 0 automatisch WINUSB benutzt.
1
BOS_Desc:
2
    db   5                ;len 
3
    db   0x0F             ;BOS see 3.0 Spec page 357
4
    db   low(40),high(40) ;wTotalLengtn 
5
    db   2                ;2 sets (Extension Desc + MS OS Desc)
6
7
;USB2 Extension Descriptor (desc 1)   
8
    db   7                ;len
9
    db   0x10             ;DEVICE_CAPABILITY see 3.0 Spec page 357
10
    db   2                ;USB 2.0 Extension Descriptor 
11
    db   0,0,0,0          ;cap bitmap nothing used
12
13
; Microsoft OS 2.0 platform capability descriptor header (desc 2)   
14
    db   28               ;bLength
15
    db   0x10             ;DEVICE CAPABILITY Descriptor 
16
    db   5                ;MS_PLATFORM
17
    db   0                ;reserved    
18
;MS OS 2.0 descriptor platform capability ID
19
;D8DD60DF-4589-4CC7-9CD2-659D9E648A9F
20
    db   0xDF,0x60,0xDD,0xD8
21
    db   0x89,0x45
22
    db   0xC7,0x4C
23
    db   0x9C,0xD2                     ;bugbug wrong byteorder
24
    db   0x65,0x9D,0x9E,0x64,0x8A,0x9F ;bugbug wrong byteorder
25
    ;db   0xD2,0x9C 
26
    ;db   0x9F,0x8A,0x64,0x9E,0x9D,0x65 
27
    db   0,0,3,6            ;0x06030000 NTDDI_WINBLUE (W8.1)
28
    db   low(170),high(170) ;vendor request  wTotalength
29
    db   0x20               ;vendor bRequest code
30
    db   0                  ;reserved

die beiden wichtigen Felder sind vendor bRequest und vendor 
wTotalLength.
Diese definieren den Request für die MS Custom Settings

Wie schon geschrieben fragt MS automatisch nach dem Bos Descriptor 
sobald bcdUSB auf 2.10 gestellt wird

von Thomas Z. (usbman)


Lesenswert?

ok ich habe das nun mal in mein audio device eingebaut. Für winusb habe 
ich einfach ein weiteres Interface (ohne Eps) angehängt, damit kann ich 
dann Vendor Control Requests absetzen. Ich benutze das im Moment zum FW 
Update.

Der Aufbau ist wie folgt:
Interface0 -> Audio Control
Interface1 -> Audio Stream
Interface2 -> Midi Control
Interface3 -> Midi Stream
Interface4 -> WinUsb FW update.

Die ersten 4 Interfaces werden von usbaudio bedient. Das funktioniert 
soweit.

Eine Verständnis Frage habe ich allerdings noch. Das Beispiel stammt aus 
der MS Doc
1
UCHAR Example1_MSOS20PlatformCapabilityDescriptor[0x1B] =
2
{
3
//
4
// Microsoft OS 2.0 Platform Capability Descriptor Header
5
//
6
0x1C, // bLength - 28 bytes
7
0x10, // bDescriptorType - 16
8
0x05, // bDevCapability – 5 for Platform Capability
9
0x00, // bReserved - 0
10
0xDF, 0x60, 0xDD, 0xD8, // MS_OS_20_Platform_Capability_ID -
11
0x89, 0x45, 0xC7, 0x4C, // {D8DD60DF-4589-4CC7-9CD2-659D9E648A9F}
12
0x9C, 0xD2, 0x65, 0x9D, //
13
0x9E, 0x64, 0x8A, 0x9F, //
14
...
15
}
in dem MS Beispiel sind die ersten beiden GUUID Felder LSB first die 
restlichen aber MSB first. Das ergibt in meinen Augen keinerlei Sinn, es 
funktioniert aber nur wenn man das genauso baut.
Hat jemand eine Erklärung oder einen Link warum das so aussehen muss?

: Bearbeitet durch User
von Jim M. (turboj)


Lesenswert?

Thomas Z. schrieb:
> Hat jemand eine Erklärung oder einen Link warum das so aussehen muss?

Das Zeuchs stammt aus einer Zeit wo man sich fragte was die bei M$ so 
rauchen - und es noch keine 64-Bitter als PCs gab.

Dadruch ist das Format extra krank: 1x32 Bit LE, 2*16 Bit LE gefolgt von 
8 Bytes (in der originalen Reihenfolge). Das wurde damals(tm) so 
implementiert und später nie mehr angefasst.

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Ich hab das jetzt mal auf dem CH552 und meiner Demo Stick Platine 
implementiert.
3 Interfaces : Interface0 Winusb, Interface1/2 std CDC

Ziemlich früh bei der Enumeration fragt Windows via GetDescriptor(0x0F) 
den BOS Deskriptor ab. (zuerst mit wLength 0x005, danach mit wlength 
0x028).
Der Bos Deskriptor liefert am Ende Vendor Length und bRequest code 
zurück.
Windows setzt dann einen Vendor Request Device mit bRequest = bRequest 
code und wIndex = 0x0007 ab.
-> 0xC0 0x40 0x00 0x00 0x07 0x00 0x0AA 0x00
Dieser Request liefert dann den kompletten Vendor Deskriptor wie im 
Beispiel.

Der gesamte Vorgang der Enum dauert etwa 200ms danach ist der Bus frei 
und kommen nur noch die SOFs.

In diesem Beispiel wird automatisch winusb geladen. Vorrausetzung ist 
dass das BCD_USB Feld im Device Deskriptor auf 0x210 gesetzt ist.

Ich habs noch nicht getestet aber das Ganze funktioniert wohl erst ab 
W8.1. Für W7 muss man weiterhin eine inf bauen oder mit zadig für 
Interface0 winusb zuordnen.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.