7、固件配置框架 fconf/索引

本文档概述了固件配置框架

7.1 固件配置框架是什么？

1 介绍

固件配置框架（|FCONF|）是平台特定数据的抽象层，允许查询“属性”并检索值，而请求实体不知道使用什么后备存储来保存数据。
它用于连接提供平台特定数据的新方法和旧方法。今天，像信任链这样的信息被保存在几个嵌套的平台定义的表中。将来，它可以作为设备blob的一部分提供，以及关于要加载的图像的其余信息。引入此抽象层将使迁移更容易，并将为无法/不想使用设备树的平台保留功能。

2 访问属性-Accessing properties

|FCONF|中定义的属性围绕命名空间和子命名空间分组：a.b.property。示例命名空间可以是：

• （|TBBR|）信任链数据：TBBR.cot.trusted_boot_fw_cert
• （|TBBR|）动态配置信息：TBBR.dyn_config.disable_auth
• 防护策略：Arm.io_policies.bl2_image
• GICv3属性：hw_config.GICv3_config.gicr_base

可以使用FCONF_GET_PROPERTY（a，b，PROPERTY）宏访问属性。

3 定义属性

组成|FCONF|的属性必须存储在C结构中。如果属性来自不同的后端源（如设备树），则平台必须提供populate（）函数，该函数本质上捕获属性并将其存储到相应的基于|FCONF|的C结构中。

这样的populate（）函数通常是特定于平台的，并且与特定的后端源相关联。例如，一个populator函数，它从HW_CONFIG设备树中捕获平台的硬件拓扑。因此，必须使用特定的config_type标识符注册每个populate（）函数。它广泛表示配置属性的逻辑分组，通常是设备树文件。

例子：

• FW_CONFIG：与其他DTB的基地址、最大大小和镜像id等相关的属性。
• TB_FW：与可信固件相关的属性，如IO策略、mbedtls堆信息等。
• HW_CONFIG：与SoC硬件配置相关的属性，如拓扑、GIC控制器、PSCI挂钩、CPU ID等。

因此，populate（）回调必须使用FCONF_REGISTER_POPULATION（）宏注册到（|FCONF|）框架。这确保了在初始化期间在通用fconf_populate（）函数内调用该函数。

int fconf_populate_topology(uintptr_t config)
{
    /* read hw config dtb and fill soc_topology struct */
}

FCONF_REGISTER_POPULATOR(HW_CONFIG, topology, fconf_populate_topology);

然后，必须提供一个包装以匹配FCONF_GET_PROPERTY（）宏：

/* generic getter */
#define FCONF_GET_PROPERTY(a,b,property)    a##__##b##_getter(property)

/* my specific getter */
#define hw_config__topology_getter(prop) soc_topology.prop

此二级包装器可用于将FCONF_GET_PROPERTY（）重新映射到任何适当的对象：结构、数组、函数等。
为了确保对属性的良好解释，本文档必须解释如何为特定后端描述属性。有关更多信息和示例，请参阅：ref:bindingdocument部分。

4 Loading the property device tree -加载属性设备树

必须调用fconf_load_config（image_id）来加载包含属性值的fw_config和tb_fw_config设备树。这必须在io层初始化后完成，因为|DTB|存储在外部设备（FIP）上。

.. uml:: ../../resources/diagrams/plantuml/fconf_bl1_load_config.puml

5 填充属性

一旦有效的设备树可用，就可以使用fconf_populate（config）函数用config|DTB|中的数据填充C数据结构。此函数将调用所有已使用FCONF_REGISTER_POPULATION（）注册的populate（）回调，如上所述。

.. uml:: ../../resources/diagrams/plantuml/fconf_bl2_populate.puml

6 命名空间指南

如上所述，属性在逻辑上围绕名称空间和子名称空间分组。添加新属性/名称空间时应考虑以下概念。该框架区分了两种类型的属性：

• 公共代码中使用的属性。
• 平台特定代码内使用的属性。

第一类适用于作为固件的一部分并在多个平台上共享的属性。它们应该是全局可访问的，并在lib/fconf目录中定义。必须选择名称空间以反映抽象的特性/数据。

例子：

• |TBBR |相关属性：TBBR.cot.bl2_id
• 动态配置信息：dyn_cfg.dtb_info.hw_config_id

第二类应该代表框架中定义的大多数属性：特定于平台的属性。它们只能在平台API内访问，并且只能在平台范围内定义。命名空间必须包含定义的属性所属的平台名称。

例子：

• Arm-io框架：Arm.io_policies.bl31_id

7 属性绑定信息

.. toctree::
  :maxdepth: 1

  fconf_properties
  amu-bindings
  mpmm-bindings

7.2 FCONF属性的DTB绑定

本文档描述|FCONF|属性的设备树格式。这些属性与特定平台无关，可以从公共代码中查询。

1、动态配置

|FCONF|框架需要具有以下字段的dtb注册表节点：

• 兼容[强制性]
  • 值类型：＜string＞
  • 必须是字符串“fconf，dyn_cfg-dtb_registry”。

然后是表示配置|DTB|的子节点列表，|FCONF|可以使用它。每个子节点应根据其包含的信息进行命名，并且必须由以下字段组成：

• 加载地址[强制]
  • 值类型：
  • 配置的物理加载基地址。
• 最大尺寸[强制要求]
  • 值类型：
  • 配置的最大大小。
• id[必填]
  • 值类型：
  • 配置的镜像ID。
• ns加载地址[可选]
  • 值类型：
  • 非安全内存中配置的物理加载基地址。仅适用于需要加载到安全存储器（加载地址）以及非安全存储器（例如HW_CONFIG）中的配置文件

7.3 活动监视器单元（AMU）绑定

为了通过FCONF支持平台定义的活动监视器单元（|AMU|）辅助计数器，HW_CONFIG设备树接受几个|AMU|-特定的节点和属性。

• 绑定

  • /cpus/cpus/cpu*节点属性
  • /cpus/amus节点属性
  • /cpus/amus/amu*节点属性
  • /cpus/amus/amu*/counter*节点属性

• /cpus/cpus/cpu*节点属性

cpu节点已被增强，以支持关联|AMU|视图的句柄，该视图应描述内核提供的计数器。

• /cpus/amus节点属性
  ams节点描述了由系统中的核心实现的|AMU|。此节点没有任何属性。
• /cpus/amus/amu*节点属性
  amu节点描述一个或多个|amu|的辅助计数器寄存器的布局和含义，并且可以由多个核共享。

• /cpus/amus/amu*/counter*节点属性
  计数器节点描述属于父|AMU|视图的辅助计数器。

栗子

提供由两个集群组成的四个核心的示例系统，其中每个集群的核心共享不同的|AMU|，可以使用以下内容：

cpus {
    #address-cells = <2>;
    #size-cells = <0>;

    amus {
        amu0: amu-0 {
            #address-cells = <1>;
            #size-cells = <0>;

            counterX: counter@0 {
                reg = <0>;

                enable-at-el3;
            };

            counterY: counter@1 {
                reg = <1>;

                enable-at-el3;
            };
        };

        amu1: amu-1 {
            #address-cells = <1>;
            #size-cells = <0>;

            counterZ: counter@0 {
                reg = <0>;

                enable-at-el3;
            };
        };
    };

    cpu0@00000 {
        ...

        amu = <&amu0>;
    };

    cpu1@00100 {
        ...

        amu = <&amu0>;
    };

    cpu2@10000 {
        ...

        amu = <&amu1>;
    };

    cpu3@10100 {
        ...

        amu = <&amu1>;
    };
}

在这种情况下，cpu0和cpu1（第一个集群中的两个核心）共享amu0定义的AMU的视图。同样，cpu2和cpu3（第二个集群中两个核）共享amu1定义的|AMU|的视图。这将导致cpu0与cpu1都启用counterX和counterY，而cpu2与cpu2都启用了counterZ。

7.4 最大功率缓解机制（MPMM）绑定

固件无法在运行时确定MPMM支持。相反，这些DTB绑定允许平台通过HW_CONFIG设备树blob对|MPMM|的每个核心就是否支持进行通信。

绑定

• /cpus/cpus/cpu*节点属性
  cpu节点已被增强，以允许平台在给定内核上表示对|MPMM|的支持。
  
  栗子
  提供两个内核的示例系统，一个支持|MPMM|，另一个不支持，可以描述如下：

cpus {
    #address-cells = <2>;
    #size-cells = <0>;

    cpu0@00000 {
        ...

        supports-mpmm;
    };

    cpu1@00100 {
        ...
    };
}

小节

这一章其实就是教你怎么配置设备树的，这些属性是什么意思，相应支持实现什么功能，你应该去添加什么元素。

8、固件更新-firmware-update

9、引导方式-measured_boot/index

每毫米英里
平台中断控制器API
ras公司
romlib设计
sdei公司
安全分区管理器
安全分区管理器mm
xlat-tables-lib-v2-设计
胶布装订
领域管理扩展
颗粒保护台设计