Re: [edk2-devel] EFI_AUDIO_OUTPUT_PROTOCOL: assistance with VirtIO initialization

["Ethin Probst" <harlydavidsen@gmail.com>]

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@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@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