- 博客(22)
- 收藏
- 关注
RSS订阅原创 PCIE Spec ---Software Initialization and Configuration（二）
在支持 ECAM（Enhanced Configuration Access Mechanism）机制的系统中，PCIe Host Bridge 负责将主处理器发出的内存映射的 PCIe 配置空间访问请求转换为 PCIe 配置事务。内存映射访问配置空间的大小和基地址由 host bridge 和固件设计决定，若是支持 N bit 的 BUS，则说明该平台的 Bus 最多可以由 2 n -1 个，而内存映射地址对齐则是需要是 2（n+20）字节的内存地址边界。
2025-03-19 15:32:17
766
原创 UEFI Spec 学习笔记---6 - Block Translation Table (BTT) Layout
BTT的layout 取决于namespace的大小以及在初始化Layout时确认的三个管理选择：•••NFree为了减小BTT元数据的大小并增加并发更新的可能性，将名称空间中的BTT布局划分为多个arena。竞技场容量不能大于512gb或小于16 mib。一个命名空间被划分为尽可能多的512GiB arena，从偏移量零开始，不加填充地打包在一起，如果剩余空间至少为16MiB，则后面是一个小于512GiB的arena。如果需要，较小的区域大小将四舍五入为EFI_BTT_ALIGNMENT的倍数。
2025-02-20 11:05:39
718
原创 UEFI Spec 学习笔记---9 - Protocols — EFI Loaded Image
本节定义EFI_LOADED_IMAGE_PROTOCOL和 EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL。这些描述包括 load image 的源、映像在内存中的当前位置、为image分配的内存类型、 以及在调用image时传递给image的参数。Loaded Image Device Path Protocol 必须安装到EFI引导服务loadimage（）加载的PE/COFF映像的映像句柄上。被 image handle 使用，用于获取加载的 Image 的信息。
2025-02-20 11:01:05
274
原创 UEFI Spec 学习笔记---11 - Protocols — UEFI Driver Model(1)
本节提供EFI_DRIVER_BINDING_PROTOCOL的详细描述。该协议是由遵循UEFI驱动程序模型的每个驱动程序产生的，它是允许 驱动程序和控制器被管理的中心组件。它提供了一个服务来测试一个特定的控制器是否被驱动程序支持，一个服务来开始管理一个控制器，一个服务来停止管理一个控制器。这些服务同样适用于总线控制器和设备控制器的驱动程序。
2025-02-18 10:23:05
755
原创 UEFI Spec 学习笔记---7 - Services — Boot Services(1)
Boot Services是由可能在 UEFI 环境中运行的接口函数的代码定义的。这些代码包括设备管理和扩展性的 protocol， 以及在预启动环境中运行的应用和 OS loader。UEFI application 必须通过 boot service 来访问设备以及内存管理，使用 boot service 时通过一个全局指针（gBS etc）。
2025-01-16 15:01:17
870
原创 UEFI Spec 学习笔记---34 - HII Protocols(1)
本节提供了与uefi相关的协议、函数和类型定义的代码定义，它们 是符合uefi的系统管理用户输入所需的体系结构机制。主要提供用于检索字体信息函数。StringToImage-----根据传入的字符串将字符串转换成 image 或者屏幕上显示。StringIdToImage----根据传入的字符串 Id 查找字符串然后将字符串转换成 image 用于屏幕上显示。GetGlyph----将字符串和字符信息转化成位图显示。
2025-01-10 16:20:52
850
原创 UEFI Spec 学习笔记---4 - EFI System Table(1)
服务表包含固件中的入口点，用于访问核心EFI系统功能。它包括每个表类型的唯一签名，table 的修订版，可以在向EFI表类型添加扩展时更新，以及一个32位的CRC，以便EFI表类型的使用者可以验证EFI表的内容，确认 table 是否被修改。ImageHandle 可以看作是一个 driver 的标识符，每个 driver 的 handle 是唯一的，我们可以通过 EFI_INSTALL_PROTOCOL_INTERFACE 在 handle 上安装多个该 driver 需要调用的 protocol .
2024-12-27 16:31:31
986
原创 UEFI Spec 学习笔记---3 - Boot Manager(3)
映像直接从支持EFI_LOAD_FILE_PROTOCOL的设备加载。当通过EFI_SIMPLE_FILE_SYSTEM_PROTOCOL 加载引导时，FilePath将以指向实现EFI_SIMPLE_FILE_SYSTEM_PROTOCOL或EFI_BLOCK_IO_PROTOCOL的设备路径开始。虽然固件必须产生一个理解UEFI文件系统的EFI_SIMPLE_FILE_SYSTEM_PROTOCOL，但任何文件系统都可以用EFI_SIMPLE_FILE_SYSTEM_PROTOCOL接口抽象出来。
2024-12-03 18:11:24
778
原创 UEFI Spec 学习笔记---3 - Boot Manager(2)
boot manager 通过 BootOptionSupport 这个variable来控制支持从什么类型的 bootoption 来进行 boot，在 BDS 阶段或者其他需要设置启动项的时候，可以先获取到这个 variable 然后和对应的 bit 位来确认是否支持所需要类型的 boot option。EFI_BOOT_OPTION_SUPPORT_KEY 对应的就是 可以通过按键来创建 key option 然后进行 boot；
2024-11-20 10:48:30
670
原创 UEFI Spec 学习笔记---3 - Boot Manager(1)
（可以理解为系统 bootx64.efi 在执行的时候，会去创建一个 Bootoption，名字就是系统的名字）。UEFI Boot Manager 是一个固件政策引擎，它会去通过读取 NVRAM 中的全局变量（也就是 Boot Option 对应的 BootXXXX）来获取可以 boot 的启动项，然后根据中间的信息来加载 UEFI driver 或者 UEFI Image.同时在这个加载过程中若是遇到异常情况，也可也实现其他异常处理机制（比如启动完所有的启动项，都失败则进入 setup 界面）。
2024-10-29 18:21:19
931
原创 UEFI Spec 学习笔记---17 - Protocols — USB Support
USB Host Controller Protocol 也就是代码中的EFI_USB_HC_PROTOCOL 或者 EFI_USB2_HC_PROTOCOL，EFI_USB2_HC_PROTOCOL 可以看作是更新的协议用于支持 USB1.1 和 USB 2.0.可以和 EHCI、UHCI、OHCI 标准一起配合使用，通过使用这个 protocol USB bus driver 不需要知道底层的 USB 控制器是否满足 EHCI、UHCI、OHCI 中的哪一种。同时提供信息用于创建。
2024-09-27 16:02:45
751
1
原创 PCIE Spec --Software Initialization and Configuration（一）
也就是都是由Root Complex 管理。PCIE switch 的概念可以看作是由多个将 PCI 链路连接到内部总线的 PCI-to-PCI bridge 组成。这个 Switch 的上游端口是一个PCI-to-PCI bridge，而对应的 bridge 的二级总线可以看作是 Switch 的内部逻辑路由；PCIE 链路对应的其实就是从 PCI to PCI bridge 引出的二级总线，而 Root port 对应概念的 PCI-to-PCI bridge 用于管理 PCIE 链路。
2024-07-10 16:31:26
323
原创 PCIE Spec ---PCI Express Layering Introduction
扩展的信息在传输过程中被不同的层级进行处理，但是在两个数据链路层(连接到同一个数据链路层)之间支持一种更简单的包通信形式链接)，用于链接管理。如之前所说的，数据链路层也是分为两部分处理，传输方的数据链路层通过解析事务层的 TLPs 计算 Package 的数据校验码和队列号，并且通过链路传输给物理层。同时接受方的数据链路层负责对收到的数据进行完整性的检差，同时通过链路传输给事务层进行进一步的处理。传输方的数据链路层主要是作为事务层和物理层的中间层，主要是负责通信链路的管理、数据完整性检查、错误检测与修正。
2024-04-20 16:42:43
2063
原创 AHCI---System Memory Structures
每个 HBA port 有自己对应的 Command List 以及 FISes 结构，HBA 最多可以支持 32 个 Port.对应 Port 位于 内存寄存器的位置我们也叫对应 port 的 entry.软件和 SATA device 的大部分交互都是通过系统内存进行的，通过系统内存可以进行 FIS 的接收和发送，同时也可以进行数据传输。当HBA期望从设备接收数据FIS时，或者当HBA根据正在使用的命令协议将数据FIS传输到设备时，HBA不需要接收未知的FIS.
2024-04-11 10:39:45
998
1
原创 AHCI ---HBA Memory Registers
通过读取这个寄存器，可以获取当前 Port 连接到的设备的具体状态，是否连接建立，以及接口速度等等。前者用于控制整个 HBA 的功能支持信息，后者是对于 HBA 的 port 的状态与功能信息。用于获取需要传输的 FIS 数据块的物理地址，这个地址是位于系统内存中的。HBA 最重要的寄存器部分，直接控制 Port 与 ATA device 的交互。每个 Port 的长度是固定的 80 h.具体的寄存器的值的含义需要查看对应的章节。主要用于控制Port Multiplier 的交换状态，以及获取状态信息。
2024-04-09 11:07:23
2143
原创 AHCI ---HBA Configuration Registers---PCI Power Management Capabilities
主要介绍控制 HBA device 的电源状态，以及对SATA的支持的寄存器
2024-04-09 10:08:22
602
原创 AHCI ---HBA Configuration Registers---PCI Header
下面表格是截取自 AHCI Spec，主要是介绍 PCI header 的每个字段的具体含义，根据获取这个 header 的数据可以来解析这个 HBA 的具体的配置。用来指示 HBA 在系统内存的内存类型，以及基地址，后面会介绍的HBA memory registers 就是在这个基地址的基础上加上 offset 来获取寄存器的值的。这是一个可选的功能，用于指示 HBA 是否支持 BIST 的功能以及 BIST 的状态。若是 HBA 有自己的扩展 ROM 的话，需要这个字段来获取扩展 ROM 的基地址。
2024-04-08 18:27:04
512
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人