- 21 Jul, 2020 1 commit
-
-
Alexei Fedorov authored
This patch adds support for Measured Boot driver functionality to FCONF library code. Change-Id: I81cdb06f1950f7e6e58f938a1b9c2f74f7cfdf88 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 25 Jun, 2020 1 commit
-
-
Manish V Badarkhe authored
Modified the code to do below changes: 1. Load tb_fw_config along with fw_config by BL1. 2. Populate fw_config device tree information in the BL1 to load tb_fw_config. 3. In BL2, populate fw_config information to retrieve the address of tb_fw_config and then tb_fw_config gets populated using retrieved address. 4. Avoid processing of configuration file in case of error value returned from "fw_config_load" function. 5. Updated entrypoint information for BL2 image so that it's arg0 should point to fw_config address. Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com> Change-Id: Ife6f7b673a074e7f544ee3d1bda7645fd5b2886c
-
- 24 Jun, 2020 2 commits
-
-
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
-
Manish V Badarkhe authored
Moved BL2 configuration nodes from fw_config to newly created tb_fw_config device tree. fw_config device tree's main usage is to hold properties shared across all BLx images. An example is the "dtb-registry" node, which contains the information about the other device tree configurations (load-address, size). Also, Updated load-address of tb_fw_config which is now located after fw_config in SRAM. Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: Ic398c86a4d822dacd55b5e25fd41d4fe3888d79a
-
- 30 Apr, 2020 1 commit
-
-
Louis Mayencourt authored
Dynamic configuration properties are fconf properties. Modify the compatible string from "arm,.." to "fconf,.." to reflect this. Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com> Change-Id: I85eb75cf877c5f4d3feea3936d4c348ca843bc6c
-
- 29 Apr, 2020 1 commit
-
-
Andre Przywara authored
Our fdtw_read_cells() implementation goes to great lengths to sanity-check every parameter and result, but leaves a big hole open: The size of the storage the value pointer points at needs to match the number of cells given. This can't be easily checked at compile time, since we lose the size information by using a void pointer. Regardless the current usage of this function is somewhat wrong anyways, since we use it on single-element, fixed-length properties only, for which the DT binding specifies the size. Typically we use those functions dealing with a number of cells in DT context to deal with *dynamically* sized properties, which depend on other properties (#size-cells, #clock-cells, ...), to specify the number of cells needed. Another problem with the current implementation is the use of ambiguously sized types (uintptr_t, size_t) together with a certain expectation about their size. In general there is no relation between the length of a DT property and the bitness of the code that parses the DTB: AArch64 code could encounter 32-bit addresses (where the physical address space is limited to 4GB [1]), while AArch32 code could read 64-bit sized properties (/memory nodes on LPAE systems, [2]). To make this more clear, fix the potential issues and also align more with other DT users (Linux and U-Boot), introduce functions to explicitly read uint32 and uint64 properties. As the other DT consumers, we do this based on the generic "read array" function. Convert all users to use either of those two new functions, and make sure we never use a pointer to anything other than uint32_t or uint64_t variables directly. This reveals (and fixes) a bug in plat_spmd_manifest.c, where we write 4 bytes into a uint16_t variable (passed via a void pointer). Also we change the implementation of the function to better align with other libfdt users, by using the right types (fdt32_t) and common variable names (*prop, prop_names). [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#n874 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/ecx-2000.dts Change-Id: I718de960515117ac7a3331a1b177d2ec224a3890 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 11 Mar, 2020 1 commit
-
-
Madhukar Pappireddy authored
A populate() function essentially captures the value of a property, defined by a platform, into a fconf related c structure. Such a callback is usually platform specific and is associated to a specific configuration source. For example, a populate() function which captures the hardware topology of the platform can only parse HW_CONFIG DTB. Hence each populator 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 source file. Example: > TB_FW: properties related to trusted firmware such as IO policies, base address of other DTBs, mbedtls heap info etc. > HW_CONFIG: properties related to hardware configuration of the SoC such as topology, GIC controller, PSCI hooks, CPU ID etc. This patch modifies FCONF_REGISTER_POPULATOR macro and fconf_populate() to register and invoke the appropriate callbacks selectively based on configuration type. Change-Id: I6f63b1fd7a8729c6c9137d5b63270af1857bb44a Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
-
- 07 Feb, 2020 1 commit
-
-
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>
-