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