From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by mx.groups.io with SMTP id smtpd.web08.6721.1626545427747815266 for ; Sat, 17 Jul 2021 11:10:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=r+ghkVme; spf=pass (domain: gmail.com, ip: 209.85.218.54, mailfrom: harlydavidsen@gmail.com) Received: by mail-ej1-f54.google.com with SMTP id hr1so20509327ejc.1 for ; Sat, 17 Jul 2021 11:10:27 -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 :cc:content-transfer-encoding; bh=c1AhO+kwyib26AvwA6ptiOTckiZAE37r/VV6d74nH1s=; b=r+ghkVmedox6dbh5E889m/TvA+srjEfICkew+PWQTLdyoJkRuYxB/qaO6FMMwu8WIr +xT/hiTyAyCpDGIQrLNk0vbxwVrcjQPnPXFh0Vxm/PjIrYFux3RHpJiV6zgY9nwlrqMo XWX+a/92gRCQWg3mb0GsFssLlgmBBmYJ4KxUL4/7OL+3j5+eOTxOCSnmDkiY6QJI9Yi5 8PNmyXHP2fpyFwMw1l7jpWBhSI+STPzvij/Maxj8xBg7EdH4ZxgfXq9VRPzNM1Xu7zz2 50EAyTSk6Sfezl26z2Pgz3wMGxGSaiT8L/xUgfvNbCMpPmN0lg5r+5iouHAYNzyaYoDN 8xKg== 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:cc:content-transfer-encoding; bh=c1AhO+kwyib26AvwA6ptiOTckiZAE37r/VV6d74nH1s=; b=fIqs4qv2+LOyjaYre0ipSMUBIWwNdEDgKK505hzAsRH8KrajJkujGWI7kmyq+GLcFp IbiayhP678nQURfBX1lpL+XtSwzdh559J0EidPK5rELJiDyYMRKtd1qGaL8g0XI0La3u uOqDa1ic4TV1vrOvRpGodh+zpJaqws95TITVhNeBnXvFhhjaGiCXpcw1ZTycvXZ8xEZd 7EcXYvs0EqJoJbpxbu8VaziabPoufmKcwwAINnFLi9sOtyrc7DT0TF3erJz2TVfXbJZm 9o+rTYz1QKSWq01UkH47L4xBfocoN5BhkDo8bmVnYT++5taX73FxCA0uI0emNLVIzacf /IJA== X-Gm-Message-State: AOAM5321vz7lAptIQadFNES1Bywteg7YFjiOigaJW8mzlrHfhPETdM5Y 4IOO2mAfdeFXQKzwkNw1pJx+CUsHONn5HXNNDLA= X-Google-Smtp-Source: ABdhPJzGU4wmL1lrCo+yme6W00YXx3F7vOV3IqsLpY1tpo3VvKW7ceCaUszsA/A3AZpGwiPtN2LsidU1rdSXu1t5Jnw= X-Received: by 2002:a17:907:264e:: with SMTP id ar14mr18750752ejc.134.1626545426297; Sat, 17 Jul 2021 11:10:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:3f89:0:0:0:0:0 with HTTP; Sat, 17 Jul 2021 11:10:25 -0700 (PDT) In-Reply-To: <08756DA4-26D7-4EB9-9E36-0AD739E3B05C@apple.com> References: <88AE4AB4-12BA-433C-9EA4-EDC01B30DAD1@apple.com> <08756DA4-26D7-4EB9-9E36-0AD739E3B05C@apple.com> From: "Ethin Probst" Date: Sat, 17 Jul 2021 13:10:25 -0500 Message-ID: Subject: Re: [edk2-devel] OpenProtocol() giving me EFI_INVALID_PARAMETER To: Andrew Fish Cc: devel@edk2.groups.io, "Leif Lindholm (Nuvia address)" , Ray Ni Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Andrew. So it appears as though only a single handle exists ("AF: DevicePath(..)/Pci(0x1D,0x0)/USB(0x0,0x0)) USBIO") but my app is getting two handles, one of which doesn't actually exist. I still am unsure why though. Getting verbose info about handle AF yields an interface with class 0x01, subclass 0x01, and protocol 0x04, so this appears to match the USB audio control interface. However, no audio streaming device is available, as I would expect. Attempting to set the interface to `1` also fails on the UAC device (though the USB specification does note that this is not necessarily an error and may just indicate that that interface setting is not supported so my app currently just continues on regardless). I am running with qemu args `-usb -device usb-audio,... -audiodev ...`. I've tried with `-device qemu-xhci ...` but I get the same result. On 7/17/21, Andrew Fish wrote: > > >> On Jul 17, 2021, at 10:06 AM, Ethin Probst >> wrote: >> >> Okay, so I just tried dh -v 7EDE4C18 (that was the handle that I'm >> getting from `HandleBuffer()`) and it says "dh: Handle - '7EDE4C18' >> not found". So I'm definitely confused because that's what >> `HandleBuffer()` is getting me. Should I pre-allocate the buffer? >> > > Ethin, > > The UEFI Shell `dh` command UI uses handle numbers from 0 - N as hex > digits. You have use these abstract values with the `dh` command. For > example: use `dh -v A1` to see the actual handle value for A1 (7EBA9598= ). > You can search handles that contain a specific protocol... > > Shell> dh -p PciIo > Handle dump by protocol 'PCIIO' > A1: PCIIO DevicePath(PciRoot(0x0)/Pci(0x0,0x0)) > A2: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1,0x0)) > A3: PCIIO DevicePath(PciRoot(0x0)/Pci(0x2,0x0)) > A4: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x0,0x0)) > A5: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x1,0x0)) > A6: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x2,0x0)) > A7: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x3,0x0)) > A8: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x4,0x0)) > A9: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x5,0x0)) > AA: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1E,0x0)) > AB: DiskIO BlockIO FA920010-6785-4941-B6EC-498C579F160A PCIIO > DevicePath(..)/Pci(0x1E,0x0)/Pci(0x0,0x0)) > AC: ISAACPI PCIIO DevicePath(PciRoot(0x0)/Pci(0x1F,0x0)) > AD: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1F,0x3)) > Shell> dh -v A1 > A1: 7EBA9598 > PCIIO(7EBA8AA8) > Segment #.....: 00 > Bus #.........: 00 > Device #......: 00 > Function #....: 00 > ROM Size......: 0 > ROM Location..: 00000000 > Vendor ID.....: 8086 > Device ID.....: 29C0 > Class Code....: 00 00 06 > Configuration Header : > 8680C029070000000000000600000000 > 00000000000000000000000000000000 > 000000000000000000000000F41A0011 > 000000000000000000000000FF000000 > DevicePath(7EBA9E18) > PciRoot(0x0)/Pci(0x0,0x0) > > Thanks, > > Andrew Fish > >> On 7/17/21, Ethin Probst wrote: >>> I mean, possible... The code I'm using to initialize the handle buffer >>> is >>> this: >>> >>> ```C >>> EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE imageHandle, IN >>> EFI_SYSTEM_TABLE* >>> st) { >>> Print(L"Attempting to find USB IO protocol\n"); >>> UINTN numHandles =3D 0; >>> UINTN i =3D 0; >>> UINT32 UsbStatus =3D 0; >>> EFI_HANDLE* handles =3D NULL; >>> EFI_USB_IO_PROTOCOL* UsbIo =3D NULL; >>> EFI_STATUS status =3D st->BootServices->LocateHandleBuffer(ByProtocol= , >>> &gEfiUsbIoProtocolGuid, NULL, &numHandles, &handles); >>> if (EFI_ERROR(status)) { >>> Print(L"Cannot find any handles for USB devices, reason: %r\n", >>> status); >>> return EFI_ABORTED; >>> } >>> Print(L"Found %d USB devices; enumerating\n", numHandles); >>> for (; i < numHandles; ++i) { >>> Print(L"Trying to open handle %d (%x)... ", i, handles[i]); >>> status =3D st->BootServices->OpenProtocol(handles[i], >>> &gEfiUsbIoProtocolGuid, (void**)&UsbIo, imageHandle, NULL, >>> EFI_OPEN_PROTOCOL_EXCLUSIVE); >>> if (EFI_ERROR(status)) { >>> Print(L"%r, skipping\n", status); >>> continue; >>> } >>> // ... >>> ``` >>> I've done my best to follow SEI secure C coding standards, like >>> initializing all variables, regardless of type -- e.g. initializing >>> pointers to 0/NULL. But I will definitely try that idea. >>> >>> On 7/17/21, Andrew Fish wrote: >>>> >>>> >>>>> On Jul 17, 2021, at 9:41 AM, Ethin Probst >>>>> wrote: >>>>> >>>>> Hey all, >>>>> >>>>> So my UsbAudio.efi app has hit a bit of a roadblock. This code: >>>>> >>>>> ```C >>>>> status =3D st->BootServices->OpenProtocol(handles[i], >>>>> &gEfiUsbIoProtocolGuid, (void**)&UsbIo, imageHandle, NULL, >>>>> EFI_OPEN_PROTOCOL_EXCLUSIVE); >>>>> if (EFI_ERROR(status)) { >>>>> Print(L"%r, skipping\n", status); >>>>> continue; >>>>> } >>>>> ``` >>>> >>>> How are you constructing handle[]? Could it have gotten stale? You >>>> could >>>> print out the value of handle[I] on the failure. >>>> >>>> The contents of a handle are not defined, but the current >>>> implementation >>>> is >>>> a pointer to an IHANDLE internal data structure in the DXE Core. If y= ou >>>> are >>>> at the UEFI Shell and you `dh -v it will show the >>>> >>>> and the value. >>>> >>>> Shell> dh -v 98 >>>> 98: 6d5CF18 >>>> =E2=80=A6. >>>> >>>> I think you can `dh -p UsbIo=E2=80=99 to get the list of the UsbIo ha= ndles. >>>> >>>> So you can poke around and see what is happening on that handle. >>>> >>>> I guess the handle[] array could be getting corrupted? So you could >>>> check >>>> for that? >>>> >>>> Thanks, >>>> >>>> Andrew Fish >>>> >>>>> Is giving me EFI_INVALID_PARAMETER and I don=E2=80=99t know why. I d= on't think >>>>> I'm violating any of its constraints, according to the specification= , >>>>> and I haven't touched this code since it was written. It also happen= s >>>>> irregularly: sometimes it happens on the USB audio streaming device, >>>>> or if I have a device plugged in it might happen on that device, you >>>>> get the idea. But it doesn't consistently fail. Does anybody have an= y >>>>> idea what's going on? >>>>> >>>>> -- >>>>> Signed, >>>>> Ethin D. Probst >>>> >>>> >>> >>> >>> -- >>> Signed, >>> Ethin D. Probst >>> >> >> >> -- >> Signed, >> Ethin D. Probst >> >> >>=20 >> >> > > --=20 Signed, Ethin D. Probst