[edk2-devel] EFI_AUDIO_OUTPUT_PROTOCOL: assistance with VirtIO initialization
Ethin Probst
harlydavidsen at gmail.com
Fri Jul 2 18:18:50 UTC 2021
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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77454): https://edk2.groups.io/g/devel/message/77454
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