From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.apple.com [17.179.253.44]) by mx.groups.io with SMTP id smtpd.web10.6567.1626544849893089546 for ; Sat, 17 Jul 2021 11:00:49 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=NbRaMxCc; spf=pass (domain: apple.com, ip: 17.179.253.44, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 16HHvnjQ027203; Sat, 17 Jul 2021 11:00:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=TV41O6urARrFEGaBsPartaIpYG4bYf8m+yizWnJp6gQ=; b=NbRaMxCcNyU4kDvB37d8BQHMKTs+7rbXrO64320aeaHfAW67f2GAN2ObY7xils/WbE5D l20JsOq2J0XG9yQz8qdCgb3X4VYwayRfr9YbttWYNOCKOy8zGw2/FRqy3nYJ0kkuB/WW xrre7B87YRxXwn9tZKFrVm55hRCXts4BdWVNVuk3mkZlH6qdagkzpr8J2XT8oVhckhZW bfVaCSxmAtwCEG+NPGSkW1F6Mkvh5xHxg6UWO1QEc+PMeNFIEMKXXGNbuxne92EoscK+ 7yc5KJkP9gH3L04rgRePXA4iwlemBJJD1oBR5TVQD6YKM+k569ig7IkCTsDDj+rDbgNd Vw== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 39utr5pc33-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 17 Jul 2021 11:00:49 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QWE00AN8I1DNQB0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Sat, 17 Jul 2021 11:00:49 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QWE00D00HZO5300@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sat, 17 Jul 2021 11:00:49 -0700 (PDT) X-Va-A: X-Va-T-CD: 7465fa55048cd8249c6ea5d21a328e37 X-Va-E-CD: 086b2cc192df006f59d7facad959a6fe X-Va-R-CD: a7a5a53aae481dccc3f624a5487f0eef X-Va-CD: 0 X-Va-ID: ac69f333-fe14-43e0-9741-6f4f87d7836a X-V-A: X-V-T-CD: 7465fa55048cd8249c6ea5d21a328e37 X-V-E-CD: 086b2cc192df006f59d7facad959a6fe X-V-R-CD: a7a5a53aae481dccc3f624a5487f0eef X-V-CD: 0 X-V-ID: 95ffe7d9-6c79-4952-a773-cf0127d979d8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-07-17_07:2021-07-16,2021-07-17 signatures=0 Received: from [17.235.34.166] (unknown [17.235.34.166]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QWE00B2LI1BG800@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sat, 17 Jul 2021 11:00:48 -0700 (PDT) From: "Andrew Fish" Message-id: <08756DA4-26D7-4EB9-9E36-0AD739E3B05C@apple.com> MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] OpenProtocol() giving me EFI_INVALID_PARAMETER Date: Sat, 17 Jul 2021 11:00:47 -0700 In-reply-to: Cc: "Leif Lindholm (Nuvia address)" , Ray Ni To: devel@edk2.groups.io, harlydavidsen@gmail.com References: <88AE4AB4-12BA-433C-9EA4-EDC01B30DAD1@apple.com> X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-07-17_07:2021-07-16,2021-07-17 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_7033F645-DAA8-40D0-808E-52B176F72A77" --Apple-Mail=_7033F645-DAA8-40D0-808E-52B176F72A77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 17, 2021, at 10:06 AM, Ethin Probst wro= te: >=20 > 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? >=20 Ethin, The UEFI Shell `dh` command UI uses handle numbers from 0 - N as hex digi= ts. 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 s= earch handles that contain a specific protocol... Shell> dh -p PciIo Handle dump by protocol 'PCIIO' A1: PCIIO DevicePath(PciRoot(0x0)/Pci(0x0,0x0))=20 A2: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1,0x0))=20 A3: PCIIO DevicePath(PciRoot(0x0)/Pci(0x2,0x0))=20 A4: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x0,0x0))=20 A5: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x1,0x0))=20 A6: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x2,0x0))=20 A7: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x3,0x0))=20 A8: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x4,0x0))=20 A9: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x5,0x0))=20 AA: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1E,0x0))=20 AB: DiskIO BlockIO FA920010-6785-4941-B6EC-498C579F160A PCIIO DevicePath(.= .)/Pci(0x1E,0x0)/Pci(0x0,0x0))=20 AC: ISAACPI PCIIO DevicePath(PciRoot(0x0)/Pci(0x1F,0x0))=20 AD: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1F,0x3))=20 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: >>=20 >> ```C >> EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE imageHandle, IN EFI_SYSTEM_TAB= LE* >> 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. >>=20 >> On 7/17/21, Andrew Fish wrote: >>>=20 >>>=20 >>>> On Jul 17, 2021, at 9:41 AM, Ethin Probst >>>> wrote: >>>>=20 >>>> Hey all, >>>>=20 >>>> So my UsbAudio.efi app has hit a bit of a roadblock. This code: >>>>=20 >>>> ```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; >>>> } >>>> ``` >>>=20 >>> How are you constructing handle[]? Could it have gotten stale? You cou= ld >>> print out the value of handle[I] on the failure. >>>=20 >>> The contents of a handle are not defined, but the current implementati= on >>> is >>> a pointer to an IHANDLE internal data structure in the DXE Core. If yo= u >>> are >>> at the UEFI Shell and you `dh -v it will show the >>> and the value. >>>=20 >>> Shell> dh -v 98 >>> 98: 6d5CF18 >>> =E2=80=A6. >>>=20 >>> I think you can `dh -p UsbIo=E2=80=99 to get the list of the UsbIo han= dles. >>>=20 >>> So you can poke around and see what is happening on that handle. >>>=20 >>> I guess the handle[] array could be getting corrupted? So you could ch= eck >>> for that? >>>=20 >>> Thanks, >>>=20 >>> Andrew Fish >>>=20 >>>> Is giving me EFI_INVALID_PARAMETER and I don=E2=80=99t know why. I do= n'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? >>>>=20 >>>> -- >>>> Signed, >>>> Ethin D. Probst >>>=20 >>>=20 >>=20 >>=20 >> -- >> Signed, >> Ethin D. Probst >>=20 >=20 >=20 > --=20 > Signed, > Ethin D. Probst >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_7033F645-DAA8-40D0-808E-52B176F72A77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 17, 2= 021, at 10:06 AM, Ethin Probst <harlydavidsen@gmail.com> wrote:

Okay, so I just trie= d dh -v 7EDE4C18 (that was the handle that I'm
getting from `= HandleBuffer()`) and it says "dh: Handle - '7EDE4C18'
not fou= nd". So I'm definitely confused because that's what
`HandleBu= ffer()` is getting me. Should I pre-allocate the buffer?


Ethin,

The UEFI Shell `dh` command  UI use= s handle numbers from 0 - N as hex digits. You have use these abstract valu= es with the `dh` command. For example:  use `dh -v A1` to see the actu= al handle value for A1 (7EBA9598). You can search handles that contain a sp= ecific protocol...

Shell> dh -p PciIo
Handle dump by protocol 'PCIIO'
A1: PCIIO De= vicePath(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)) 
<= div style=3D"margin: 0px; font-stretch: normal; font-size: 11px; line-heigh= t: normal; font-family: Menlo; color: rgb(178, 178, 178); background-color:= rgb(0, 0, 0);" class=3D"">A5: PCIIO <= /span>DevicePath(..0)/Pci(0x2,0x0)/Pci(0x1,0x0)) 
A6: PC= IIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x2,0x0))&nb= sp;
A7: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x3,= 0x0)) 
A8: PCIIO DevicePath(..0)/Pci(0x2,0x0)/= Pci(0x4,0x0)) 
A9<= /span>: PCIIO DevicePath(..0)/Pci(0= x2,0x0)/Pci(0x5,0x0)) 
AA: PCIIO DevicePath(= PciRoot(0x0)/Pci(0x1E,0x0)) 
<= span style=3D"font-variant-ligatures: no-common-ligatures" class=3D"">AB: DiskIO BlockIO FA920010-6785-4941-B6EC-498C579F160A PCIIO DevicePath(..)/Pci(0x1E,0x0)/Pci(0x0,= 0x0)) 
AC: ISAACPI PCIIO De= vicePath(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
<= span style=3D"font-variant-ligatures: no-common-ligatures" class=3D""> = ; Device #......: 00
  Function #.= ...: 00
  ROM Size......: 0=
  ROM Location..: 00000000
<= div style=3D"margin: 0px; font-stretch: normal; font-size: 11px; line-heigh= t: normal; font-family: Menlo; color: rgb(178, 178, 178); background-color:= rgb(0, 0, 0);" class=3D"">  Vendor ID.....: 8086
  Device ID.....: 29C0
  Class Code....: 00 00 06
  Configuration Header :
 =       8680C029070000000000000600000000
       00000000000000000000000000000000<= /span>
       000000000000= 000000000000F41A0011
    = ;   000000000000000000000000FF000000
DevicePath(7EBA9E18)
  PciRoot(0x0)/Pci(0x0,0x0)

Thanks,

=
Andrew Fish

On 7/17/21, Ethin Probst <harlydavidsen@gmail.com> wrote:
I mean, po= ssible... 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_HAN= DLE* handles =3D NULL;
 EFI_USB_IO_PROTOCOL* UsbIo =3D = NULL;
 EFI_STATUS status =3D st->BootServices->Lo= cateHandleBuffer(ByProtocol,
&gEfiUsbIoProtocolGuid, NULL= , &numHandles, &handles);
 if (EFI_ERROR(status= )) {
   Print(L"Cannot find any handles for U= SB devices, reason: %r\n",
status);
 &nbs= p; return EFI_ABORTED;
 }
 Pri= nt(L"Found %d USB devices; enumerating\n", numHandles);
&nbs= p;for (; i < numHandles; ++i) {
   Print(L= "Trying to open handle %d (%x)... ", i, handles[i]);
 &= nbsp; status =3D st->BootServices->OpenProtocol(handles[i],
&gEfiUsbIoProtocolGuid, (void**)&UsbIo, imageHandle, NULL= ,
EFI_OPEN_PROTOCOL_EXCLUSIVE);
  &n= bsp;if (EFI_ERROR(status)) {
     P= rint(L"%r, skipping\n", status);
    &nb= sp;continue;
   }
  =  // ...
```
I've done my best to follow SE= I 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/2= 1, Andrew Fish <afish@appl= e.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 =3D st->BootServices->OpenP= rotocol(handles[i],
&gEfiUsbIoProtocolGuid, (void**)&= UsbIo, imageHandle, NULL,
EFI_OPEN_PROTOCOL_EXCLUSIVE);
  if (EFI_ERROR(status)) {
  &= nbsp; Print(L"%r, skipping\n", status);
  &nb= sp; continue;
  }
```

How are you constructing handle[]? Could= it have gotten stale? You could
print out the value of handl= e[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 <ha= ndleNum> it will show the <handleNum>
and the value.=

Shell> dh -v 98
98: 6d5CF18<= br class=3D"">=E2=80=A6.

I think you can `dh -= p UsbIo=E2=80=99 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 cor= rupted? So you could check
for that?

Thanks,

Andrew Fish

Is giving me EFI_INVALID_PAR= AMETER and I don=E2=80=99t know why. I don't think
I'm violat= ing any of its constraints, according to the specification,
a= nd 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 de= vice, you
get the idea. But it doesn't consistently fail. Doe= s anybody have any
idea what's going on?

--
Signed,
Ethin D. Probst



<= br class=3D"">--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst






--Apple-Mail=_7033F645-DAA8-40D0-808E-52B176F72A77--