Commit Graph

6 Commits

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>
2022-04-26 17:52:25 +02:00
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>
2021-11-04 15:58:34 +00:00
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>
2020-09-29 13:28:25 +01:00
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
2020-09-01 18:17:11 +01:00
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>
2019-09-13 16:54:21 +01:00
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>
2019-09-13 16:54:21 +01:00