* OpenProtocol() giving me EFI_INVALID_PARAMETER
@ 2021-07-17 16:41 Ethin Probst
2021-07-17 16:55 ` Andrew Fish
0 siblings, 1 reply; 8+ messages in thread
From: Ethin Probst @ 2021-07-17 16:41 UTC (permalink / raw)
To: devel; +Cc: Leif Lindholm (Nuvia address), Andrew Fish, Ray Ni
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;
}
```
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: OpenProtocol() giving me EFI_INVALID_PARAMETER 2021-07-17 16:41 OpenProtocol() giving me EFI_INVALID_PARAMETER Ethin Probst @ 2021-07-17 16:55 ` Andrew Fish 2021-07-17 17:01 ` Ethin Probst 0 siblings, 1 reply; 8+ messages in thread From: Andrew Fish @ 2021-07-17 16:55 UTC (permalink / raw) To: Ethin Probst; +Cc: devel, Leif Lindholm (Nuvia address), Ray Ni > On Jul 17, 2021, at 9:41 AM, Ethin Probst <harlydavidsen@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: OpenProtocol() giving me EFI_INVALID_PARAMETER 2021-07-17 16:55 ` Andrew Fish @ 2021-07-17 17:01 ` Ethin Probst 2021-07-17 17:06 ` Ethin Probst 0 siblings, 1 reply; 8+ messages in thread From: Ethin Probst @ 2021-07-17 17:01 UTC (permalink / raw) To: Andrew Fish; +Cc: devel, Leif Lindholm (Nuvia address), Ray Ni 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@apple.com> wrote: > > >> On Jul 17, 2021, at 9:41 AM, Ethin Probst <harlydavidsen@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: OpenProtocol() giving me EFI_INVALID_PARAMETER 2021-07-17 17:01 ` Ethin Probst @ 2021-07-17 17:06 ` Ethin Probst 2021-07-17 18:00 ` [edk2-devel] " Andrew Fish 0 siblings, 1 reply; 8+ messages in thread From: Ethin Probst @ 2021-07-17 17:06 UTC (permalink / raw) To: Andrew Fish; +Cc: devel, Leif Lindholm (Nuvia address), Ray Ni 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? On 7/17/21, Ethin Probst <harlydavidsen@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@apple.com> wrote: >> >> >>> On Jul 17, 2021, at 9:41 AM, Ethin Probst <harlydavidsen@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [edk2-devel] OpenProtocol() giving me EFI_INVALID_PARAMETER 2021-07-17 17:06 ` Ethin Probst @ 2021-07-17 18:00 ` Andrew Fish 2021-07-17 18:10 ` Ethin Probst 0 siblings, 1 reply; 8+ messages in thread From: Andrew Fish @ 2021-07-17 18:00 UTC (permalink / raw) To: devel, harlydavidsen; +Cc: Leif Lindholm (Nuvia address), Ray Ni [-- Attachment #1: Type: text/plain, Size: 5357 bytes --] > On Jul 17, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@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@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@apple.com> wrote: >>> >>> >>>> On Jul 17, 2021, at 9:41 AM, Ethin Probst <harlydavidsen@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 > > > > > [-- Attachment #2: Type: text/html, Size: 23368 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [edk2-devel] OpenProtocol() giving me EFI_INVALID_PARAMETER 2021-07-17 18:00 ` [edk2-devel] " Andrew Fish @ 2021-07-17 18:10 ` Ethin Probst 2021-07-17 18:34 ` Andrew Fish 0 siblings, 1 reply; 8+ messages in thread From: Ethin Probst @ 2021-07-17 18:10 UTC (permalink / raw) To: Andrew Fish; +Cc: devel, Leif Lindholm (Nuvia address), Ray Ni 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@apple.com> wrote: > > >> On Jul 17, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@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@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@apple.com> wrote: >>>> >>>> >>>>> On Jul 17, 2021, at 9:41 AM, Ethin Probst <harlydavidsen@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [edk2-devel] OpenProtocol() giving me EFI_INVALID_PARAMETER 2021-07-17 18:10 ` Ethin Probst @ 2021-07-17 18:34 ` Andrew Fish 2021-07-17 21:00 ` Ethin Probst 0 siblings, 1 reply; 8+ messages in thread From: Andrew Fish @ 2021-07-17 18:34 UTC (permalink / raw) To: edk2-devel-groups-io, harlydavidsen; +Cc: Leif Lindholm (Nuvia address), Ray Ni [-- Attachment #1: Type: text/plain, Size: 7383 bytes --] 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@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@apple.com <mailto:afish@apple.com>> wrote: >> >> >>> On Jul 17, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@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@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@apple.com> wrote: >>>>> >>>>> >>>>>> On Jul 17, 2021, at 9:41 AM, Ethin Probst <harlydavidsen@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 > > > [-- Attachment #2: Type: text/html, Size: 25452 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [edk2-devel] OpenProtocol() giving me EFI_INVALID_PARAMETER 2021-07-17 18:34 ` Andrew Fish @ 2021-07-17 21:00 ` Ethin Probst 0 siblings, 0 replies; 8+ messages in thread From: Ethin Probst @ 2021-07-17 21:00 UTC (permalink / raw) To: Andrew Fish; +Cc: edk2-devel-groups-io, Leif Lindholm (Nuvia address), Ray Ni Tried this and I still get that invalid handle. Definitely confused where that's coming from. On 7/17/21, Andrew Fish <afish@apple.com> wrote: > 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@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@apple.com <mailto:afish@apple.com>> wrote: >>> >>> >>>> On Jul 17, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@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@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@apple.com> wrote: >>>>>> >>>>>> >>>>>>> On Jul 17, 2021, at 9:41 AM, Ethin Probst <harlydavidsen@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 >> >> >> > > -- Signed, Ethin D. Probst ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-07-17 21:00 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-07-17 16:41 OpenProtocol() giving me EFI_INVALID_PARAMETER Ethin Probst 2021-07-17 16:55 ` Andrew Fish 2021-07-17 17:01 ` Ethin Probst 2021-07-17 17:06 ` Ethin Probst 2021-07-17 18:00 ` [edk2-devel] " Andrew Fish 2021-07-17 18:10 ` Ethin Probst 2021-07-17 18:34 ` Andrew Fish 2021-07-17 21:00 ` Ethin Probst
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox