From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id B4A35D8067E for ; Thu, 9 Jan 2025 04:33:43 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=uwM1ftgP8pZ9vvH5h/gRzkoyPdZJuyk0mFbn9UeUf/Y=; c=relaxed/simple; d=groups.io; h=From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Thread-Index:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Language; s=20240830; t=1736397223; v=1; x=1736656422; b=TswToamtJuKgiBPoh/mmQ2arG9xSTy343qjLonR3vwkg7fXB+fcmu/CFZBj7f1FtCgiX7WKZ 3z5QFQYdgQv9wDHIZH/SnU1zLDX8PWEX5wXazUsHLctWvUEdIHztJul5EZlwc+SJt0+yxUUlyEp Zfu3V1LG7U0Bg8m5Ab1lKuneGuDeS9DXzDmcac3gU9TuWYmEOPyFn8hzHCwD+/74z+zMWOGz45+ 6NltHFeo5+pVSGhJJhc10VhahqfyZjVy95SwQp8QbPDjQSQopuVsi/JjRNWsaKQbYo3rRKJN0gb OhjfQzYgKlKhIpgjuAc9JrzuMb5uMb6gxbCDiXpJB0kng== X-Received: by 127.0.0.2 with SMTP id y2UOYY7687511xFRJ7Wq36pI; Wed, 08 Jan 2025 20:33:42 -0800 X-Received: from zrleap.intel-email.com (zrleap.intel-email.com [114.80.218.36]) by mx.groups.io with SMTP id smtpd.web11.40932.1736397220523472369 for ; Wed, 08 Jan 2025 20:33:41 -0800 X-Received: from zrleap.intel-email.com (localhost [127.0.0.1]) by zrleap.intel-email.com (Postfix) with ESMTP id 2F6CAA32DFFE for ; Thu, 9 Jan 2025 12:33:37 +0800 (CST) X-Received: from localhost (localhost [127.0.0.1]) by zrleap.intel-email.com (Postfix) with ESMTP id 1DD0AA32DFDD for ; Thu, 9 Jan 2025 12:33:37 +0800 (CST) X-Received: from mail.byosoft.com.cn (mail.byosoft.com.cn [58.240.74.242]) by zrleap.intel-email.com (Postfix) with SMTP id D9A59A32DFC1 for ; Thu, 9 Jan 2025 12:33:32 +0800 (CST) X-Received: from DESKTOPS6D0PVI ([113.84.1.147]) (envelope-sender ) by 192.168.6.13 with ESMTP(SSL) for ; Thu, 09 Jan 2025 12:33:30 +0800 X-WM-Sender: gaoliming@byosoft.com.cn X-Originating-IP: 113.84.1.147 X-WM-AuthFlag: YES X-WM-AuthUser: gaoliming@byosoft.com.cn From: "gaoliming via groups.io" To: , References: <002001db5fd5$f1d73fd0$d585bf70$@byosoft.com.cn> In-Reply-To: Subject: =?UTF-8?B?5Zue5aSNOiBbZWRrMi1kZXZlbF0gQ29tcGF0aWJpbGl0eSBvZiBQQ0llIFVFRkkgb3B0aW9uIFJPTQ==?= Date: Thu, 9 Jan 2025 12:33:31 +0800 Message-ID: <02d001db624f$a3d90990$eb8b1cb0$@byosoft.com.cn> MIME-Version: 1.0 Thread-Index: AQFfKlrNLr6J6LbOF0ZrdLljrKVrtQD4PqlDAngL9++z6sd+0A== Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Wed, 08 Jan 2025 20:33:41 -0800 Resent-From: gaoliming@byosoft.com.cn Reply-To: devel@edk2.groups.io,gaoliming@byosoft.com.cn List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: kM6Tijr187am1d9CHOV9Lk7jx7686176AA= Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D1_01DB6292.B1FEBA90" Content-Language: zh-cn X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b=TswToamt; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=pass (policy=none) header.from=groups.io ------=_NextPart_000_02D1_01DB6292.B1FEBA90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable UEFI Option ROM Driver only depends on MdePkg. If you meet with such device= driver that has the additional dependency, you can raise this problem to t= he device vendor.=20 =20 Thanks Liming =E5=8F=91=E4=BB=B6=E4=BA=BA: devel@edk2.groups.io = =E4=BB=A3=E8=A1=A8 =E4=B8=B0=E7=AB=8B=E6=B3=A2 via groups.io =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2025=E5=B9=B41=E6=9C=886=E6=97=A5 17:= 26 =E6=94=B6=E4=BB=B6=E4=BA=BA: gaoliming =E6=8A=84=E9=80=81: devel =E4=B8=BB=E9=A2=98: =E5=9B=9E=E5=A4=8D: [edk2-devel] Compatibility of PCIe = UEFI option ROM =20 PCIe option ROMs are UEFI drivers, basiclly. UEFI drivers and UEFI applicat= ions all could encounter the compatibility issue.=20 Consider this situation: build an UEFI driver comsuming some gEdkii****Prot= ocol on EDKII development Kits, then under AMI shell, using "load" command = to load the UEFI driver efi file, the UEFI couldn't work due to the absence= of the gEdkii****Protocol. The same issue could occur on UEFI Application = as well. =20 There is an example: SecurityPkg/HddPassword/HddPassworldDxe.inf is a gener= al UEFI driver, but it consumes gEdkiiVariablePolicyProtocolGuid. Under the= AMI UEFI shell, load the driver with the load command, it may not work.=20 Vice versa, An AMI-built UEFI driver comsuming some AMI-specific protcotol = couldn't run under the EDKII shell, that is the problem we are having. =20 PCIe option ROM are built on the AMI development kits, tranditionally. PCIe= Option ROM is contained in PCIe card, deploy widely. The issue is more sev= ere than UEFI driver and Application.=20 =20 Thanks =20 Feng Libo=20 =20 =20 Original: * From=EF=BC=9Agaoliming > * Date=EF=BC=9A2025-01-06 08:57:22(=E4=B8=AD=E5=9B=BD (GMT+08:00)) * To=EF=BC=9Adevel > , l= bfeng > * Cc=EF=BC=9A * Subject=EF=BC=9A=E5=9B=9E=E5=A4=8D: [edk2-devel] Compatibility of PCIe UE= FI option ROM UEFI Option Rom only consumes the protocols defined in UEFI spec, it doesn= =E2=80=99t depend on other protocols.=20 =20 Thanks Liming =E5=8F=91=E4=BB=B6=E4=BA=BA: devel@edk2.groups.io > =E4=BB=A3=E8=A1= =A8 =E4=B8=B0=E7=AB=8B=E6=B3=A2 via groups.io =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2025=E5=B9=B41=E6=9C=883=E6=97=A5 17:= 45 =E6=94=B6=E4=BB=B6=E4=BA=BA: devel > =E4=B8=BB=E9=A2=98: [edk2-devel] Compatibility of PCIe UEFI option ROM =20 Hello, =20 PCIe option ROM is an UEFI driver, basiclly. You can build an PCIe option= ROM with any UEFI development kits, EDKII or AMI Aptio, burn a flash chip = mounted on PCIe plugin card. At the moment of DXE driver dispatching, PCIe = option ROM loads and runs in the UEFI enviroment of motherboard. The mother= board UEFI could be built with other UEFI development kits, the compatibilt= y issue could occur.=20 This actully happened in a project of ours: A PCIe network Option ROM is = built with AMI UEFI development kits, having the driver health functionalit= y. This PCIe network card plugin an EDKII UEFI motherboard, enter Setup uti= lity, check the driver health, something is not working: a PopupBox was sup= posed to pop, but didn't. and many ASSERT are send out, reporting VFR STRIN= G can't be found. I think the PCIe network Option ROM is using AMI-specific= protocols and string resouces that are totally absent in the EDKII executi= on enviroment. Meanwhile, I look up the EDKII-implemented protocols, many EDKII_** prefi= xed protocols exist, these are not UEFI specified. Think about this situati= on: I build a PCIe option ROM with EDKII, using EDKII_FORM_DISPLAY_ENGINE_P= ROTOCOL, then plugin the PCIe card in an AMI UEFI motherboard, the PCIe opt= ion ROM can't locate the EDKII_FORM_DISPLAY_ENGINE_PROTOCOL, probably. Some= thing is not working, either.=20 Making things worse, it is impossible for PCIe card vendors to deliver va= riants, it is impossible for the end-user to choose a proper variant as wel= l. Now, how can we address this issue? Best Regards Feng Libo =20 =20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120974): https://edk2.groups.io/g/devel/message/120974 Mute This Topic: https://groups.io/mt/110449204/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- ------=_NextPart_000_02D1_01DB6292.B1FEBA90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

UEFI Option ROM Driver only depends on MdePkg. If you meet= with such device driver that has the additional dependency, you can raise = this problem to the device vendor.

 

Thanks

Liming

<= p class=3DMsoNormal>=E5=8F=91=E4=BB=B6=E4=BA=BA:= devel@edk2.groups.io <devel@edk2.groups.io> =E4=BB=A3=E8=A1= =A8 =E4=B8=B0=E7=AB=8B=E6=B3=A2 via groups.io
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2025=E5=B9=B41=E6=9C=886=E6=97=A5 17:26
=E6= =94=B6=E4=BB=B6=E4=BA=BA: = gaoliming <gaoliming@byosoft.com.cn>
=E6=8A=84=E9=80=81<= span lang=3DEN-US>: devel <devel@edk2.grou= ps.io>
=E4=B8=BB=E9=A2=98: =E5=9B=9E=E5=A4=8D: [edk2-devel]= Compatibility of PCIe UEFI option ROM

 

PCIe option ROMs are UEFI drivers, basic= lly. UEFI drivers and UEFI applications all could encounter the compatibili= ty issue.

Con= sider this situation: build an UEFI driver comsuming some gEdkii****Protoco= l on EDKII development Kits, then under AMI shell, using "load" c= ommand to load the UEFI driver efi file, the UEFI couldn't work due to the = absence of the gEdkii****Protocol. The same issue could occur on UEFI Appli= cation as well.

 

There i= s an example: SecurityPkg/HddPassword/HddPassworldDxe.inf is a general UEFI= driver, but it consumes gEdkiiVariablePolicyProtocolGuid. Under the AMI UE= FI shell, load the driver with the load command, it may not work.

Vice versa, An AMI-buil= t UEFI driver comsuming some AMI-specific protcotol couldn't run under the = EDKII shell, that is the problem we are having.

=

 

PCIe option ROM are built on the AMI development k= its, tranditionally. PCIe Option ROM is contained in PCIe card, deploy wide= ly. The issue is more severe than UEFI driver and Application. 

 

Thanks

<= /div>

 

Feng Libo 

 

 

Original:

UEFI Option Rom only consumes the protocols de= fined in UEFI spec, it doesn=E2=80=99t depend on other proto= cols.

 

Thanks

Liming

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>= =E5=8F=91=E4=BB=B6=E4=BA=BA: devel@edk2.groups.io <devel@edk2.groups.io> =E4=BB=A3=E8=A1=A8 <= /span>= =E4=B8=B0=E7=AB=8B=E6=B3=A2 via groups.io
= =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2025=E5=B9=B41=E6=9C=883=E6=97=A5 17:45
=E6=94= =B6=E4=BB=B6=E4=BA=BA: dev= el <devel@edk2.groups.io>=
=E4=B8=BB=E9=A2=98: [edk2-devel] Compatibility of PCIe UEFI option ROM<= span lang=3DEN-US style=3D'font-size:10.5pt'>

 <= /span>

Hello,

 

  PCIe option ROM is an UEFI driver, basiclly. You can= build an PCIe option ROM with any UEFI development kits, EDKII or AMI Apti= o, burn a flash chip mounted on PCIe plugin card. At the moment of DXE driv= er dispatching, PCIe option ROM loads and runs in the UEFI enviroment of mo= therboard. The motherboard UEFI could be built with other UEFI development = kits, the compatibilty issue could occur.

 = This actully happened in a project of ours: A PCIe network Option ROM is b= uilt with AMI UEFI development kits, having the driver health functionality= . This PCIe network card plugin an EDKII UEFI motherboard, enter Setup util= ity, check the driver health, something is not working: a PopupBox was supp= osed to pop, but didn't. and many ASSERT are send out, reporting VFR STRING= can't be found. I think the PCIe network Option ROM is using AMI-specific = protocols and string resouces that are totally absent in the EDKII executio= n enviroment.

  Meanwhile, I look up the EDKII= -implemented protocols, many EDKII_** prefixed protocols exist, these are n= ot UEFI specified. Think about this situation: I build a PCIe option ROM wi= th EDKII, using EDKII_FORM_DISPLAY_ENGINE_PROTOCOL, then plugin the PCIe ca= rd in an AMI UEFI motherboard, the PCIe option ROM can't locate the EDKII_F= ORM_DISPLAY_ENGINE_PROTOCOL, probably. Something is not working, either.

  Making things worse, it is impossible for PCI= e card vendors to deliver variants, it is impossible for the end-user to ch= oose a proper variant as well.




<= span lang=3DEN-US style=3D'font-size:10.5pt'>

Now, how can we address this issue?

Best Regards




Feng Libo

 

&= nbsp;

_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#120974) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
------=_NextPart_000_02D1_01DB6292.B1FEBA90--