- 24 Jun, 2020 1 commit
-
-
Manish V Badarkhe authored
Modified the `fconf_load_config` function so that it can additionally support loading of tb_fw_config along with fw_config. Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com> Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: Ie060121d367ba12e3fcac5b8ff169d415a5c2bcd
-
- 31 Mar, 2020 1 commit
-
-
Masahiro Yamada authored
fconf_dyn_cfg_getter.c calls FCONF_REGISTER_POPULATOR(), which populates the fconf_populator structure. However, bl1/bl1.ld.S does not have: __FCONF_POPULATOR_START__ = .; KEEP(*(.fconf_populator)) __FCONF_POPULATOR_END__ = .; So, this is not linked to bl1.elf We could change either bl1/bl1.lds.S or lib/fconf/fconf.mk to make them consistent. I chose to fix up fconf.mk to keep the current behavior. This is a groundwork to factor out the common code from linker scripts. Change-Id: I07b7ad4db4ec77b57acf1588fffd0b06306d7293 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 07 Feb, 2020 2 commits
-
-
Louis Mayencourt authored
This patch introduces a better separation between the trusted-boot related properties, and the dynamic configuration DTBs loading information. The dynamic configuration DTBs properties are moved to a new node: `dtb-registry`. All the sub-nodes present will be provided to the dynamic config framework to be loaded. The node currently only contains the already defined configuration DTBs, but can be extended for future features if necessary. The dynamic config framework is modified to use the abstraction provided by the fconf framework, instead of directly accessing the DTBs. The trusted-boot properties are kept under the "arm,tb_fw" compatible string, but in a separate `tb_fw-config` node. The `tb_fw-config` property of the `dtb-registry` node simply points to the load address of `fw_config`, as the `tb_fw-config` is currently part of the same DTB. Change-Id: Iceb6c4c2cb92b692b6e28dbdc9fb060f1c46de82 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
Introduce the Firmware CONfiguration Framework (fconf). The 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. The default backing store used is C structure. If another backing store has to be used, the platform integrator needs to provide a "populate()" function to fill the corresponding C structure. The "populate()" function must be registered to the fconf framework with the "FCONF_REGISTER_POPULATOR()". This ensures that the function would be called inside the "fconf_populate()" function. A two level macro is used as getter: - the first macro takes 3 parameters and converts it to a function call: FCONF_GET_PROPERTY(a,b,c) -> a__b_getter(c). - the second level defines a__b_getter(c) to the matching C structure, variable, array, function, etc.. Ex: Get a Chain of trust property: 1) FCONF_GET_PROPERY(tbbr, cot, BL2_id) -> tbbr__cot_getter(BL2_id) 2) tbbr__cot_getter(BL2_id) -> cot_desc_ptr[BL2_id] Change-Id: Id394001353ed295bc680c3f543af0cf8da549469 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-