[edk2-devel] Compatibility of PCIe UEFI option ROM

[edk2-devel] Compatibility of PCIe UEFI option ROM

[丰立波 via groups.io]

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

Hello,


  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 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 built with AMI UEFI development kits, having the driver health functionality. This PCIe network card plugin an EDKII UEFI motherboard, enter Setup utility, check the driver health, something is not working: a PopupBox was supposed 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 execution enviroment.
  Meanwhile, I look up the EDKII-implemented protocols, many EDKII_** prefixed protocols exist, these are not UEFI specified. Think about this situation: I build a PCIe option ROM with EDKII, using EDKII_FORM_DISPLAY_ENGINE_PROTOCOL, then plugin the PCIe card in an AMI UEFI motherboard, the PCIe option ROM can't locate the EDKII_FORM_DISPLAY_ENGINE_PROTOCOL, probably. Something is not working, either.
  Making things worse, it is impossible for PCIe card vendors to deliver variants, it is impossible for the end-user to choose a proper variant as well.


Now, how can we address this issue?


Best Regards


Feng Libo







-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120954): https://edk2.groups.io/g/devel/message/120954
Mute This Topic: https://groups.io/mt/110420496/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 5387 bytes --]

回复: [edk2-devel] Compatibility of PCIe UEFI option ROM

[gaoliming via groups.io]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

UEFI Option Rom only consumes the protocols defined in UEFI spec, it doesn’t depend on other protocols. 

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 丰立波 via groups.io
发送时间: 2025年1月3日 17:45
收件人: devel <devel@edk2.groups.io>
主题: [edk2-devel] Compatibility of PCIe UEFI option ROM

 

Hello,

 

  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 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 built with AMI UEFI development kits, having the driver health functionality. This PCIe network card plugin an EDKII UEFI motherboard, enter Setup utility, check the driver health, something is not working: a PopupBox was supposed 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 execution enviroment.

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

  Making things worse, it is impossible for PCIe card vendors to deliver variants, it is impossible for the end-user to choose a proper variant as well.





Now, how can we address this issue?





Best Regards





Feng Libo

 





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120955): https://edk2.groups.io/g/devel/message/120955
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]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 8445 bytes --]

回复: [edk2-devel] Compatibility of PCIe UEFI option ROM

[丰立波 via groups.io]

[-- Attachment #1: Type: text/plain, Size: 3560 bytes --]

PCIe option ROMs are UEFI drivers, basiclly. UEFI drivers and UEFI applications all could encounter the compatibility issue.
Consider this situation: build an UEFI driver comsuming some gEdkii****Protocol 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.


There is an example: SecurityPkg/HddPassword/HddPassworldDxe.inf is a general UEFI driver, but it consumes gEdkiiVariablePolicyProtocolGuid. Under the AMI UEFI shell, load the driver with the load command, it may not work.
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.


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 severe than UEFI driver and Application. 


Thanks


Feng Libo 




Original:
From：gaoliming <gaoliming@byosoft.com.cn>Date：2025-01-06 08:57:22(中国 (GMT+08:00))To：devel<devel@edk2.groups.io> , lbfeng<lbfeng@kunluntech.com.cn>Cc：Subject：回复: [edk2-devel] Compatibility of PCIe UEFI option ROMUEFI Option Rom only consumes the protocols defined in UEFI spec, it doesn’t depend on other protocols.
 
Thanks
Liming
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 丰立波 via groups.io
发送时间: 2025年1月3日 17:45
收件人: devel <devel@edk2.groups.io>
主题: [edk2-devel] Compatibility of PCIe UEFI option ROM


 
Hello,

 

  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 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 built with AMI UEFI development kits, having the driver health functionality. This PCIe network card plugin an EDKII UEFI motherboard, enter Setup utility, check the driver health, something is not working: a PopupBox was supposed 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 execution enviroment.

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

  Making things worse, it is impossible for PCIe card vendors to deliver variants, it is impossible for the end-user to choose a proper variant as well.





Now, how can we address this issue?





Best Regards





Feng Libo

 










-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120960): https://edk2.groups.io/g/devel/message/120960
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]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 10934 bytes --]