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.
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
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.
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.
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.
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, ...
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
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.
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.
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.
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.
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
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
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.