github/arm-trusted-firmware - arm-trusted-firmware - Gitea: Git with home nas server

Author	SHA1	Message	Date
Samuel Holland	2b2b565717	feat(fdt): add the ability to supply idle state information Some platforms require extra firmware to implement CPU_SUSPEND, or only have working CPU_SUSPEND in certain configurations. On these platforms, CPU idle states should only be listed in the devicetree when they are actually available. Add a function BL31 can use to dynamically supply this idle state information. Change-Id: I64fcc288303faba8abec4f59efd13a04220d54dc Signed-off-by: Samuel Holland <samuel@sholland.org>	3 years ago
Andre Przywara	1aa7e302a8	feat(libfdt): add function to set MAC addresses The devicetree specification[1] defines the generic DT properties "mac-address" and "local-mac-address", that allow to set the MAC address for a network device. This is needed because many platform network devices do not define a method for obtaining a unique MAC address, and many devices lack the non-volatile storage to hold such a number. Some platforms (for instance Allwinner) derive the MAC address from another unique SoC property, for instance some serial number. To allow those MAC address to be set by TF-A, add a function that finds the DT node of a network device (by using the "ethernet<x>" alias), then adding the "local-mac-address" property into that node, setting it to a user provided address. Platforms can use this function to generate MAC addresses in a platform specific way, and store them in the DT. DT consumers like U-Boot or the Linux kernel will automatically pick up the address from that property and program the MAC device accordingly. [1] https://devicetree-specification.readthedocs.io/en/latest/chapter4-device-bindings.html#local-mac-address-property Change-Id: I3f5766cc575fa9718f9ca23e8269b11495c43be2 Signed-off-by: Andre Przywara <andre.przywara@arm.com>	3 years ago
Andre Przywara	4d585fe52f	feat(libfdt): also allow changing base address For platforms where we don't know the number of cores at compile time, the size of the GIC redistributor frame is then also undetermined, since it depends on this number of cores. On top of this the GICR base address can also change, when an unknown number of ITS frames (including zero) take up space between the distributor and redistributor. So while those two adjustments are done for independent reasons, the code for doing so is very similar, so we should utilise the existing fdt_adjust_gic_redist() function. Add an (optional) gicr_base parameters to the prototype, so callers can choose to also adjust this base address later, if needed. Change-Id: Id39c0ba83e7401fdff1944e86950bb7121f210e8 Signed-off-by: Andre Przywara <andre.przywara@arm.com>	4 years ago
Andre Przywara	9f7bab42a1	fdt: Add function to adjust GICv3 redistributor size We now have code to detect the CPU topology at runtime, and can also populate the CPU nodes in a devicetree accordingly. This is used by the ARM FPGA port, for instance. But also a GICv3 compatible interrupt controller provides MMIO frames per core, so the size of this region needs to be adjusted in the DT, to match the number of cores as well. Provide a generic function to find the GICv3 interrupt controller in the DT, then adjust the "reg" entry to match the number of detected cores. Since the size of the GICR frame per cores differs between GICv4 and GICv3, this size is supplied as a parameter to the function. The caller should determine the applicable value by either hardcoding it or by observing GICR_TYPER.VLPIS. Change-Id: Ic2a6445c2c5381a36bf24263f52fcbefad378c05 Signed-off-by: Andre Przywara <andre.przywara@arm.com>	4 years ago
Javier Almansa Sobrino	780dd2b310	Add support to export a /cpus node to the device tree. This patch creates and populates the /cpus node in a device tree based on the existing topology. It uses the minimum required nodes and properties to satisfy the binding as specified in https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/cpus.txt Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: I03bf4e9a6427da0a3b8ed013f93d7bc43b5c4df0	4 years ago
Andre Przywara	3ef45dda88	Add fdt_add_reserved_memory() helper function If a firmware component like TF-A reserves special memory regions for its own or secure payload services, it should announce the location and size of those regions to the non-secure world. This will avoid disappointment when some rich OS tries to acccess this memory, which will likely end in a crash. The traditional way of advertising reserved memory using device tree is using the special memreserve feature of the device tree blob (DTB). However by definition those regions mentioned there do not prevent the rich OS to map this memory, which may lead to speculative accesses to this memory and hence spurious bus errors. A safer way of carving out memory is to use the /reserved-memory node as part of the normal DT structure. Besides being easier to setup, this also defines an explicit "no-map" property to signify the secure-only nature of certain memory regions, which avoids the rich OS to accidentally step on it. Add a helper function to allow platform ports to easily add a region. Change-Id: I2b92676cf48fd3bdacda05b5c6b1c7952ebed68c Signed-off-by: Andre Przywara <andre.przywara@arm.com>	5 years ago
Andre Przywara	f240728b76	qemu: Move and generalise FDT PSCI fixup The QEMU platform port scans its device tree to advertise PSCI as the CPU enable method. It does this by scanning every node in the DT and check whether its compatible string starts with "arm,cortex-a". Then it sets the enable-method to PSCI, if it doesn't already have one. Other platforms might want to use this functionality as well, so let's move it out of the QEMU platform directory and make it more robust by fixing some shortcomings: - A compatible string starting with a certain prefix is not a good way to find the CPU nodes. For instance a "arm,cortex-a72-pmu" node will match as well and is in turn favoured with an enable-method. - If the DT already has an enable-method, we won't change this to PSCI. Those two issues will for instance fail on the Raspberry Pi 4 DT. To fix those problems, we adjust the scanning method: The DT spec says that all CPU nodes are subnodes of the mandatory /cpus node, which is a subnode of the root node. Also each CPU node has to have a device_type = "cpu" property. So we find the /cpus node, then scan for a subnode with the proper device_type, forcing the enable-method to "psci". We have to restart this search after a property has been patched, as the node offsets might have changed meanwhile. This allows this routine to be reused for the Raspberry Pi 4 later. Change-Id: I00cae16cc923d9f8bb96a9b2a2933b9a79b06139 Signed-off-by: Andre Przywara <andre.przywara@arm.com>	5 years ago