[edk2-devel] EFI_AUDIO_OUTPUT_PROTOCOL: assistance with VirtIO initialization
Ethin Probst
harlydavidsen at gmail.com
Fri Jul 2 18:22:54 UTC 2021
Update: I just realized I'd made a typo -- the unknown request is
actually a get_min request.
On 7/2/21, Ethin Probst <harlydavidsen at gmail.com> wrote:
> Thank you for all that information, both of you. I didn't realize that
> VirtIO sound would be so complicated. The specification seemed simple
> enough -- but, alas, all things seem simple until you actually go and
> try to implement them.
>
> I did manage to retrieve a packet dump, from both myself and from
> somebody else that Leif contacted. The one from myself was from a USB
> mixer that I have -- its how my audio headphones work, and that
> generated far too many packets -- well over 5,000 at least. Utilizing
> display filters wasn't much of a help either -- it doesn't seem like
> my mixer makes available an audio device class descriptor anywhere,
> which is odd because it should. But I also might not have been
> filtering it properly. The other packet dump was sort-of helpful, but
> did contain some confusing elements:
>
> * There were four unknown URB transfer types (0x7F) that Wireshark
> claimed were "malformed". I asked around on the OSDev.org forum and I
> don't think anyone recognizes that either.
> * The primary init sequence was understandable, along with the get
> string requests, but after that there were a bunch of URB control
> transfers from device-to-host and some requests from host-to-device
> containing data that I didn't understand. I wasn't sure what those
> were for. They looked something like this:
>
> Frame 29: 36 bytes on wire (288 bits), 36 bytes captured (288 bits) on
> interface wireshark_extcap1868, id 0
> Interface id: 0 (wireshark_extcap1868)
> Interface name: wireshark_extcap1868
> Encapsulation type: USB packets with USBPcap header (152)
> Arrival Time: Jul 1, 2021 02:21:45.291271000 CDT
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1625124105.291271000 seconds
> [Time delta from previous captured frame: 0.000008000 seconds]
> [Time delta from previous displayed frame: 0.000008000 seconds]
> [Time since reference or first frame: 0.035324000 seconds]
> Frame Number: 29
> Frame Length: 36 bytes (288 bits)
> Capture Length: 36 bytes (288 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: usb]
> USB URB
> [Source: host]
> [Destination: 2.7.0]
> USBPcap pseudoheader length: 28
> IRP ID: 0xffffa90f548b8a20
> IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
> URB Function: URB_FUNCTION_CLASS_INTERFACE (0x001b)
> IRP information: 0x00, Direction: FDO -> PDO
> 0000 000. = Reserved: 0x00
> .... ...0 = Direction: FDO -> PDO (0x0)
> URB bus id: 2
> Device address: 7
> Endpoint: 0x80, Direction: IN
> 1... .... = Direction: IN (1)
> .... 0000 = Endpoint number: 0
> URB transfer type: URB_CONTROL (0x02)
> Packet Data Length: 8
> [Response in: 30]
> Control transfer stage: Setup (0)
> [bInterfaceClass: Audio (0x01)]
> Setup Data
> bmRequestType: 0xa1
> 1... .... = Direction: Device-to-host
> .01. .... = Type: Class (0x1)
> ...0 0001 = Recipient: Interface (0x01)
> bRequest: 130
> wValue: 0x0201
> wIndex: 1536 (0x0600)
> wLength: 2
>
> Frame 30: 30 bytes on wire (240 bits), 30 bytes captured (240 bits) on
> interface wireshark_extcap1868, id 0
> Interface id: 0 (wireshark_extcap1868)
> Interface name: wireshark_extcap1868
> Encapsulation type: USB packets with USBPcap header (152)
> Arrival Time: Jul 1, 2021 02:21:45.291389000 CDT
> [Time shift for this packet: 0.000000000 seconds]
> Epoch Time: 1625124105.291389000 seconds
> [Time delta from previous captured frame: 0.000118000 seconds]
> [Time delta from previous displayed frame: 0.000118000 seconds]
> [Time since reference or first frame: 0.035442000 seconds]
> Frame Number: 30
> Frame Length: 30 bytes (240 bits)
> Capture Length: 30 bytes (240 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: usb]
> USB URB
> [Source: 2.7.0]
> [Destination: host]
> USBPcap pseudoheader length: 28
> IRP ID: 0xffffa90f548b8a20
> IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
> URB Function: URB_FUNCTION_CONTROL_TRANSFER (0x0008)
> IRP information: 0x01, Direction: PDO -> FDO
> 0000 000. = Reserved: 0x00
> .... ...1 = Direction: PDO -> FDO (0x1)
> URB bus id: 2
> Device address: 7
> Endpoint: 0x80, Direction: IN
> 1... .... = Direction: IN (1)
> .... 0000 = Endpoint number: 0
> URB transfer type: URB_CONTROL (0x02)
> Packet Data Length: 2
> [Request in: 29]
> [Time from request: 0.000118000 seconds]
> Control transfer stage: Complete (3)
> [bInterfaceClass: Audio (0x01)]
> CONTROL response data: 00d3
>
> According to the audio 1.0 specification, this is a "get_cur" request
> (appendix 9: Audio Class-Specific Request Codes). However, I wasn't
> really sure what it was trying to get. The spec (SEC. B.3.3.3)
> indicates that this is an input terminal descriptor. I'll continue
> following this chain of requests and responses and see if I can figure
> out exactly what its doing -- I need to map the request IDs onto their
> actual values since Wireshark isn't doing that for me automatically.
>
> On 7/2/21, Michael Brown <mcb30 at ipxe.org> wrote:
>> On 02/07/2021 10:41, Michael Brown wrote:
>>> UsbIo->UsbControlTransfer(UsbIo, &Req, EfiUsbDataIn,
>>> PcdGet32 (PcdUsbTransferTimeoutValue),
>>> &Header, sizeof(Header), &Status);
>>>
>>> (Error handling etc omitted for brevity)
>>>
>>> That would get you the first 8 bytes of the class-specific AC interface
>>> header descriptor. You would then need to extract the TotalLength
>>> field, allocate that length of memory, and repeat the
>>> UsbControlTransfer() call to fetch the full-length descriptor into the
>>> newly allocated block.
>>>
>>> Hope that helps,
>>
>> BTW, in case you aren't already aware of this: wireshark is pretty good
>> at dissecting USB traffic. You can capture it by doing a "modprobe
>> usbmon", after which you'll see a number of usbmonN devices show up in
>> the wireshark interface list. Try them each in turn until you find
>> which one corresponds to the host controller to which your device is
>> attached.
>>
>> My normal method for developing or debugging iPXE USB drivers will
>> typically involve using wireshark to capture the USB traffic that
>> happens when the device is being used by a known-working driver (e.g.
>> the Linux driver for that device) and comparing it to the traffic that
>> happens when I'm using my own driver (via USB pass-through in a VM).
>> This is often a lot faster than trying to pull together all of the
>> information from the multiple USB spec documents.
>>
>> Good luck!
>>
>> Michael
>>
>
>
> --
> Signed,
> Ethin D. Probst
>
--
Signed,
Ethin D. Probst
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77455): https://edk2.groups.io/g/devel/message/77455
Mute This Topic: https://groups.io/mt/83904983/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list