public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ethin Probst" <harlydavidsen@gmail.com>
To: Andrew Fish <afish@apple.com>
Cc: devel@edk2.groups.io,
	"Leif Lindholm (Nuvia address)" <leif@nuviainc.com>,
	Ray Ni <ray.ni@intel.com>
Subject: Re: [edk2-devel] OpenProtocol() giving me EFI_INVALID_PARAMETER
Date: Sat, 17 Jul 2021 13:10:25 -0500	[thread overview]
Message-ID: <CAJQtwF2NyOBahZwiBOW+WJb6vpumYA8c-KrwuJ1JSqHRB2nYoQ@mail.gmail.com> (raw)
In-Reply-To: <08756DA4-26D7-4EB9-9E36-0AD739E3B05C@apple.com>

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

  reply	other threads:[~2021-07-17 18:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2021-07-17 18:34           ` Andrew Fish
2021-07-17 21:00             ` Ethin Probst

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJQtwF2NyOBahZwiBOW+WJb6vpumYA8c-KrwuJ1JSqHRB2nYoQ@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox