[edk2-devel] OpenProtocol() giving me EFI_INVALID_PARAMETER
Andrew Fish via groups.io
afish=apple.com at groups.io
Sat Jul 17 18:34:18 UTC 2021
If I `OvmfPkg/builds.sh qemu -usb -device usb-audio -device qemu-xhci` I see 2 USB handle?
When you open EXCLUSIVE you are kicking other people off the handles. I’m not sure that is a good idea for you to do that to every USB handle in the system. If there was a handle that represented a USB to USB bridge seems like you could kick all the children off….
So when you are probing try using GET_PROTOCOL, and only use EXCLUSIVE after you find the device you want to manage.
Thanks,
Andrew Fish
> On Jul 17, 2021, at 11:10 AM, Ethin Probst <harlydavidsen at gmail.com> wrote:
>
> 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 <afish at apple.com <mailto:afish at apple.com>> wrote:
>>
>>
>>> On Jul 17, 2021, at 10:06 AM, Ethin Probst <harlydavidsen at gmail.com>
>>> 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 <harlydavidsen at gmail.com> 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 = 0;
>>>> UINTN i = 0;
>>>> UINT32 UsbStatus = 0;
>>>> EFI_HANDLE* handles = NULL;
>>>> EFI_USB_IO_PROTOCOL* UsbIo = NULL;
>>>> EFI_STATUS status = 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 = 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 <afish at apple.com> wrote:
>>>>>
>>>>>
>>>>>> On Jul 17, 2021, at 9:41 AM, Ethin Probst <harlydavidsen at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hey all,
>>>>>>
>>>>>> So my UsbAudio.efi app has hit a bit of a roadblock. This code:
>>>>>>
>>>>>> ```C
>>>>>> status = 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 you
>>>>> are
>>>>> at the UEFI Shell and you `dh -v <handleNum> it will show the
>>>>> <handleNum>
>>>>> and the value.
>>>>>
>>>>> Shell> dh -v 98
>>>>> 98: 6d5CF18
>>>>> ….
>>>>>
>>>>> I think you can `dh -p UsbIo’ to get the list of the UsbIo handles.
>>>>>
>>>>> 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’t know why. I don'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 happens
>>>>>> 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 any
>>>>>> idea what's going on?
>>>>>>
>>>>>> --
>>>>>> Signed,
>>>>>> Ethin D. Probst
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>>>
>>>
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> --
> Signed,
> Ethin D. Probst
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77856): https://edk2.groups.io/g/devel/message/77856
Mute This Topic: https://groups.io/mt/84272862/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20210717/94b3fac8/attachment.htm>
More information about the edk2-devel-archive
mailing list