问题标签 [edk2]

如果我们有一个在 EDK2/UEFI 中安装协议的驱动程序，然后卸载该驱动程序，该协议是否继续存在并可供其他驱动程序和服务使用？UEFI 应用程序的相同问题。我主要想知道 UEFI 框架是否以某种方式将协议与安装它们的驱动程序联系起来，如果驱动程序被卸载，协议是否在卸载图像后仍可供其他驱动程序使用，或者协议是否在驱动程序被卸载时也退出内存。

我认为当然可以编写代码来使这种情况成为当驱动程序退出时它会卸载它所创建的协议，但是这是否会在 UEFI/EDK2 中默认发生？或者只有当驱动程序明确声明在卸载协议时卸载协议时才会发生这种情况？

此外，这里的行业最佳实践是什么？协议通常应该继续存在于安装它们的驱动程序之后，还是应该将两者联系起来？

对不起，如果这个问题是高水平的。我正在尝试对这个主题获得一些高级别的直觉。

我想将驱动程序包含edk2/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf在我的 AArch64 平台的固件中。如图RngDxe.inf所示，它依赖于 class 的库实例，RngLib似乎 edk2 存储库中有两个通用实例可用：

• RngLib|MdePkg/Library/DxeRngLib/DxeRngLib.inf：这个使用 CPU 来生成 RNG。
• RngLib|MdePkg/Library/BaseRngLib/BaseRngLib.inf：这个依赖于RNDRARM 内核的指令支持（FEAT_RNG）。由于我的平台不支持此指令，看来我唯一的选择是第一个。

但是，DxeRngLib.inflib 依赖于gEfiRngProtocolGuid，它将由要构建的驱动程序安装。似乎这是一个循环依赖。

以下是模块构建报告的摘录RngDxe：

以下是在我的平台（FPGA）上执行时的日志（带注释）：

我对模块/库的使用有什么问题吗？有没有办法解决这个问题？

谢谢！

嗨，所以我一直在为此奋斗一段时间，我试图学习构建 uefis 等，但视觉 UEFI 对我不起作用，因为 nasm 库不会构建任何人有任何想法吗？我尝试了多种方法，例如仅使用 nasm 构建但它不会工作我可能做错了我不确定谢谢你的 错误

您好我刚刚更新了 edk2 包并尝试构建一个 BaseTools 模块。

但是它报告了如下错误

我正在使用 gcc 11 和 manjaro 系统。我想问一下这是否是一个错误以及如何修复它。非常感谢！！

我尝试在 UEFI 中使用EFI_TCG2_PROTOCOL来访问 TPM 功能。我以这种方式使用 TSS API 在用户空间中创建持久密钥：

它工作得很好，即使在重新启动后我也可以访问这个密钥，所以密钥被保存到非易失性内存中，以后可以重复使用。但是，当我尝试从 UEFI 访问此密钥时，例如使用EFI_TCG2_PROTOCOL为该密钥调用函数TPM_CC_ReadPublic它不会返回错误代码，但响应似乎不正确。例子：

我在这里做错了吗？

我对 UEFI 开发相对较新，我正在探索各种选项以使 UEFI 开发类似于普通的 C/C++ 编程，或者至少更接近它。

我发现了一些很棒的人所做的出色工作。
Visual UEFI：https ://github.com/ionescu007/VisualUefi （使基于 UEFI EDK2 的开发变得有趣）
gnu-efi：https
://sourceforge.net/projects/gnu-efi/ Toro-C：https://github。 com/KilianKegel/toro-C-Library （标准 C 库移植）
EDK2-LibC：https ://github.com/tianocore/edk2-libc （EDK2 中的标准 C 库支持）

我能够使用 EDK2-LibC 使用 main() 和 printf() 构建简单的程序，
包括 efi shell 应用程序中的 edk2-libc

ToroC 也提供了类似的功能，尽管它可能没有 EDK2-LibC 那样广泛的支持。但是，当我直接引导到这些标准库支持的程序时（例如通过更改引导选项和引导顺序引导到 Hello.efi），这些标准库支持的程序不起作用，因此我知道它需要 EFI Shell 支持。如果我错了，请纠正我。

有什么方法可以引导到使用 EDK2-LibC 或 Toro-C 编译的 EFI 应用程序？