4.6. Firmware Configuration Framework

This document provides an overview of the FCONF framework.

4.6.1. Introduction

The Firmware CONfiguration Framework (FCONF) is an abstraction layer for platform specific data, allowing a “property” to be queried and a value retrieved without the requesting entity knowing what backing store is being used to hold the data.

It is used to bridge new and old ways of providing platform-specific data. Today, information like the Chain of Trust is held within several, nested platform-defined tables. In the future, it may be provided as part of a device blob, along with the rest of the information about images to load. Introducing this abstraction layer will make migration easier and will preserve functionality for platforms that cannot / don’t want to use device tree.

4.6.2. Accessing properties

Properties defined in the FCONF are grouped around namespaces and sub-namespaces: a.b.property. Examples namespace can be:

  • (TBBR) Chain of Trust data: tbbr.cot.trusted_boot_fw_cert

  • (TBBR) dynamic configuration info: tbbr.dyn_config.disable_auth

  • Arm io policies: arm.io_policies.bl2_image

  • GICv3 properties: hw_config.gicv3_config.gicr_base

Properties can be accessed with the FCONF_GET_PROPERTY(a,b,property) macro.

4.6.3. Defining properties

Properties composing the FCONF have to be stored in C structures. If properties originate from a different backend source such as a device tree, then the platform has to provide a populate() function which essentially captures the property and stores them into a corresponding FCONF based C structure.

Such a populate() function is usually platform specific and is associated with a specific backend source. For example, a populator function which captures the hardware topology of the platform from the HW_CONFIG device tree. Hence each populate() function must be registered with a specific config_type identifier. It broadly represents a logical grouping of configuration properties which is usually a device tree file.

Example:
  • FW_CONFIG: properties related to base address, maximum size and image id of other DTBs etc.

  • TB_FW: properties related to trusted firmware such as IO policies, mbedtls heap info etc.

  • HW_CONFIG: properties related to hardware configuration of the SoC such as topology, GIC controller, PSCI hooks, CPU ID etc.

Hence the populate() callback must be registered to the (FCONF) framework with the FCONF_REGISTER_POPULATOR() macro. This ensures that the function would be called inside the generic fconf_populate() function during initialization.

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);

Then, a wrapper has to be provided to match the FCONF_GET_PROPERTY() macro:

/* 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

This second level wrapper can be used to remap the FCONF_GET_PROPERTY() to anything appropriate: structure, array, function, etc..

To ensure a good interpretation of the properties, this documentation must explain how the properties are described for a specific backend. Refer to the Properties binding information section for more information and example.

4.6.4. Loading the property device tree

The fconf_load_config(image_id) must be called to load fw_config and tb_fw_config devices tree containing the properties’ values. This must be done after the io layer is initialized, as the DTB is stored on an external device (FIP).

@startuml

box "BL1 common code"
	participant bl1_main
	participant bl_common
end box

box "arm platform code" #LightBlue
	participant fvp_bl1_setup
	participant arm_bl1_setup
	participant arm_io_storage
end box

box "platform common code"
	participant plat_bl1_common
	participant fconf_dyn_cfg_getter
	participant fconf
end box

bl1_main -> fvp_bl1_setup : bl1_platform_setup()
fvp_bl1_setup -> arm_bl1_setup : arm_bl1_platform_setup()
arm_bl1_setup -> arm_io_storage : plat_arm_io_setup()
note over arm_io_storage : register and setup fip
arm_bl1_setup -> fconf : set_config_info(fw_config_base, max_size, FW_CONFIG_ID)
note over fconf
	set fw_config information
	(address, size, image_id)
	in global dtb_infos array.
end note
activate fconf
	arm_bl1_setup -> fconf : fconf_load_config(FW_CONFIG_ID)
	fconf -> fconf : FCONF_GET_PROPERTY(dyn_cfg, dtb, FW_CONFIG_ID)
	fconf -> fconf_dyn_cfg_getter: dyn_cfg_dtb_info_getter(FW_CONFIG_ID)
	fconf_dyn_cfg_getter -> fconf: fw_config_info
	fconf -> bl_common : load_auth_image(FW_CONFIG_ID, &image_info)
	activate bl_common
	note over bl_common
		load and auth image from fip
		with info from plat_io_policy
	end note
	bl_common -> arm_io_storage
	arm_io_storage -> fconf: FCONF_GET_PROPERTY(arm, arm_io_policies, FW_CONFIG_ID)
	note over fconf: use statically defined policies in bl1
	fconf <- bl_common : image_info
	deactivate bl_common
	note over fconf : get fw_config_dtb from image_info
	arm_bl1_setup -> fconf: FCONF_GET_PROPERTY(dyn_cfg, dtb, FW_CONFIG_ID)
	fconf -> fconf_dyn_cfg_getter: dyn_cfg_dtb_info_getter(FW_CONFIG_ID)
	fconf_dyn_cfg_getter -> arm_bl1_setup: fw_config_info
	arm_bl1_setup -> fconf_dyn_cfg_getter: populate_dtb_registry(uintptr_t dtb)
	arm_bl1_setup -> fconf: fconf_load_config(TB_FW_CONFIG_ID)
	fconf -> fconf : FCONF_GET_PROPERTY(dyn_cfg, dtb, TB_FW_CONFIG_ID)
	fconf -> fconf_dyn_cfg_getter: dyn_cfg_dtb_info_getter(TB_FW_CONFIG_ID)
	fconf_dyn_cfg_getter -> fconf: tb_fw_config_info
	fconf -> bl_common : load_auth_image(TB_FW_CONFIG_ID, &image_info)
	activate bl_common
	note over bl_common
		load and auth image from fip
		with info from plat_io_policy
	end note
	bl_common -> arm_io_storage
	arm_io_storage -> fconf: FCONF_GET_PROPERTY(arm, arm_io_policies, TB_FW_CONFIG_ID)
	note over fconf: use statically defined policies in bl1
	fconf <- bl_common : image_info
	deactivate bl_common
	note over fconf : get tb_fw_config_dtb from image_info
	fconf -> arm_bl1_setup
	arm_bl1_setup -> plat_bl1_common : bl1_plat_get_image_desc(BL2_IMAGE_ID)
	arm_bl1_setup <- plat_bl1_common : BL2_IMAGE_DESC
	note over arm_bl1_setup
	set ep_info.args.arg0 of BL2_IMAGE_DESC
	to FW_CONFIG base address
	end note
deactivate fconf

== load & auth, prepare and jump to BL2 ==

@enduml

4.6.5. Populating the properties

Once a valid device tree is available, the fconf_populate(config) function can be used to fill the C data structure with the data from the config DTB. This function will call all the populate() callbacks which have been registered with FCONF_REGISTER_POPULATOR() as described above.

@startuml

box "BL2 common code"
	participant bl2_entrypoint
	participant bl2_main
end box

box "platform common code"
	participant fconf
	participant fconf_tbbr_getter
participant fconf_dyn_cfg_getter
end box

box "arm platform code" #LightBlue
	participant arm_bl2_setup
	participant arm_io_storage
	participant arm_fconf_io
end box

== bl2 setup ==
bl2_entrypoint -> bl2_main : bl2_setup()
bl2_main -> arm_bl2_setup : bl2_early_platform_setup2(\n\t arg0, arg1, arg2, arg3)
note over arm_bl2_setup
	arg0 = fw_config
	arg1 = mem_layout
end note
arm_bl2_setup -> arm_bl2_setup : arm_bl2_early_platform_setup(\n\t fw_config, mem_layout)
activate arm_bl2_setup
	arm_bl2_setup -> fconf: fconf_populate("FW_CONFIG", fw_config)
	activate fconf
		fconf -> fconf_dyn_cfg_getter: populate_dtb_registry(uintptr_t dtb)
		note over fconf_dyn_cfg_getter: read dtb_registry properties from dtb
		fconf_dyn_cfg_getter -> arm_bl2_setup
		arm_bl2_setup -> fconf: FCONF_GET_PROPERTY(dyn_cfg, dtb, TB_FW_CONFIG_ID)
		fconf -> fconf_dyn_cfg_getter: dyn_cfg_dtb_info_getter(TB_FW_CONFIG_ID)
		fconf_dyn_cfg_getter -> arm_bl2_setup: tb_fw_config_info
		arm_bl2_setup -> fconf: fconf_populate("TB_FW_CONFIG", tb_fw_config)
		fconf -> fconf_tbbr_getter: fconf_populate_tbbr_dyn_config(uintptr_t dtb)
		note over fconf_tbbr_getter: read tbbr properties from dtb
		fconf -> arm_fconf_io: fconf_populate_arm_io_policies(uintptr_t dtb)
		note over arm_fconf_io: read arm io propeties from dtb
	deactivate fconf
	arm_bl2_setup -> arm_io_storage : plat_arm_io_setup()
	note over arm_io_storage: use populated properties
deactivate arm_bl2_setup

== bl2 main ==

@enduml

4.6.6. Namespace guidance

As mentioned above, properties are logically grouped around namespaces and sub-namespaces. The following concepts should be considered when adding new properties/namespaces. The framework differentiates two types of properties:

  • Properties used inside common code.

  • Properties used inside platform specific code.

The first category applies to properties being part of the firmware and shared across multiple platforms. They should be globally accessible and defined inside the lib/fconf directory. The namespace must be chosen to reflect the feature/data abstracted.

Example:
  • TBBR related properties: tbbr.cot.bl2_id

  • Dynamic configuration information: dyn_cfg.dtb_info.hw_config_id

The second category should represent the majority of the properties defined within the framework: Platform specific properties. They must be accessed only within the platform API and are defined only inside the platform scope. The namespace must contain the platform name under which the properties defined belong.

Example:
  • Arm io framework: arm.io_policies.bl31_id

4.6.7. Properties binding information