From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by mx.groups.io with SMTP id smtpd.web11.13422.1625249933169181037 for ; Fri, 02 Jul 2021 11:18:53 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UEBB2lQL; spf=pass (domain: gmail.com, ip: 209.85.208.51, mailfrom: harlydavidsen@gmail.com) Received: by mail-ed1-f51.google.com with SMTP id l24so14390392edr.11 for ; Fri, 02 Jul 2021 11:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=6Uhp/QVIgMGnPu+KddsmjYuhACAh0Ads6sELjqXDlCg=; b=UEBB2lQLB1IIySBkSBiSLU/f4jeqExhkhM6+NFWTTvahWIiIaVVRBS9Xiv5cc8hJDa tqu2JjK/vv9Le31+Z3t5nfJj4SVuH2zu/Eg8mKIKiWIJ6qZmc04btxcDt0p9Fk9dRGov osSFDDHU6HQ4YByD4pxLAWIkOr4eLiV47NNbLe5JmldN69MvLesqX8HviO3jO5a4Vb1X 921drNFiNDPb70Vv2M7zk7wt/0qhWMrhROKIs0RRPxWL+syam5RYU8lnb3nfFfFBeudh a+Wx73BSwuVIBRJw7CZYK/Md9otb3FL+PpFOORuEAs+z/kEWZffJBR28GPpHn90RRe57 Qqug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=6Uhp/QVIgMGnPu+KddsmjYuhACAh0Ads6sELjqXDlCg=; b=D2NhG6SLZhyt4rR9akL81hgoeNU8p8HmJxuGjSpLgbyn8aYQNgqoHAcn+ikrrEHZ1f 8/OhK+dasApIsYK5mI/Tbg7wLfjAxOV6SyoKDUEYfrVnCplOp8/pisHV0e5asIprcl90 ZoTwtgX1RDQ1ypHPFl2JfOuHF2F+25DHrqLy26UkgE+CDcRuanTJ4b1ujS9EVSSWQOmS xwnShUXc07O7nHc2J+YL3qqcHCprv2sO0DWsxDwaDrJuv4L/gdkm1up/clUab4AN3edx ywn0zF114+XOkgLUXgvB49KWaEEG5UQdDk5HGL/S0t/cgdy0Ev2DAqXV7UEuynoGhFjh 3rqg== X-Gm-Message-State: AOAM530EghS9p1fplx7F2+lZcsi/nq/gDGabKm8aLN4AvRl4ycYfuFTd 6MX6iVeFPI4FtQdXFqQaYXg1zRqUNWYZG8vNM1k00tHa X-Google-Smtp-Source: ABdhPJzGdmKV2znMGEO0e+sUY3vS7Q8BeH/L3ZVgWMyhjJ9DBjOkcW3manzDokFzUqAtKJlFBkkcaLwEf3ATQaPpWbw= X-Received: by 2002:a05:6402:89a:: with SMTP id e26mr1024089edy.91.1625249931418; Fri, 02 Jul 2021 11:18:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6400:5b92:0:0:0:0 with HTTP; Fri, 2 Jul 2021 11:18:50 -0700 (PDT) In-Reply-To: References: <168DEFFB0E406B59.30759@groups.io> From: "Ethin Probst" Date: Fri, 2 Jul 2021 13:18:50 -0500 Message-ID: Subject: Re: [edk2-devel] EFI_AUDIO_OUTPUT_PROTOCOL: assistance with VirtIO initialization To: devel@edk2.groups.io, mcb30@ipxe.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. =3D Reserved: 0x00 .... ...0 =3D Direction: FDO -> PDO (0x0) URB bus id: 2 Device address: 7 Endpoint: 0x80, Direction: IN 1... .... =3D Direction: IN (1) .... 0000 =3D 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... .... =3D Direction: Device-to-host .01. .... =3D Type: Class (0x1) ...0 0001 =3D 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. =3D Reserved: 0x00 .... ...1 =3D Direction: PDO -> FDO (0x1) URB bus id: 2 Device address: 7 Endpoint: 0x80, Direction: IN 1... .... =3D Direction: IN (1) .... 0000 =3D 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 wrote: > On 02/07/2021 10:41, Michael Brown wrote: >> UsbIo->UsbControlTransfer(UsbIo, &Req, EfiUsbDataIn, >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 PcdGet32 (PcdUsbTransferTimeoutValue), >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 &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.=C2=A0 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 > --=20 Signed, Ethin D. Probst