This corrects the MISRA violation C2012-15.6:
The body of an iteration-statement or a selection-statement shall
be a compound-statement.
Enclosed statement body within the curly braces.
Change-Id: I66f957467bdee13052847f3e8c5ad6ae258c4222
Signed-off-by: Nithin G <nithing@amd.com>
Signed-off-by: Maheedhar Bollapalli <maheedharsai.bollapalli@amd.com>
* changes:
fix(rdn2): add LCA multichip data for RD-N2-Cfg2
fix(rdv3): add LCA multichip data for RD-V3-Cfg2
feat(gic): add support for local chip addressing
This patch adds support for Local Chip Addressing (LCA). In a multi-chip
system, enablig LCA allows each GIC Distributor to maintain its own
version of routing table. This feature is activated when the
GICD_CFGID.LCA bit is set to 1.
The existing `gic600_multichip_data` data structure did not account for
the LCA feature. To support LCA:
- `rt_owner_base` is replaced by `base_addrs[]`. This is required
because each GICD in the system needs to be configured independently,
and their base addresses must be passed to the driver.
- `chip_addrs` is changed from 1D to 2D array to store the routing table
for each chip's GICD. The entries in `chip_addrs` are configuration
dependent, as the GIC specification does not enforce this.
On a multi-chip platform with chip count N where LCA is enabled by
default, the `gic600_multichip_data` structure should contain all copies
of the routing table (N*N entries). On platforms where LCA is not
supported, only the first sub-array with N entries is required. The
function signature of `gic600_multichip_init` remains unchanged, but if
the LCA feature is enabled, the driver will expect the routing table
configuration in the described format.
Change-Id: I8830c2cf90db6a0cae78e99914cd32c637284a2b
Signed-off-by: Jerry Wang <Jerry.Wang4@arm.com>
When initialising a GICv3 compatible interrupt controller, we currently
assume that the GIC is still in its reset state, which means
the GICR_WAKER.ProcessorSleep bit is set. There is an "assert" in the
GIC setup function to check this.
However when using RESET_TO_BL31, there might be prior firmware running,
and it might have used the GIC already. This is for instance the case on
the Allwinner A523 SoC, where the BootROM initialises the GIC to use it
when handling the built-in USB debug protocol.
Drop the assert, which is not the right thing to do here anyway: it's
not checking an internal state. Instead return early when the
redistributor is already marked as active.
Also keep waiting if ChildrenAsleep is unexpectedly set, but warn about
this.
This fixes booting TF-A on an Allwinner A523 SoC when using the USB
debug mode.
Change-Id: I5be9e1b0489d33b8371fff484e526483d5f3d937
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Per GIC architecture version 3 and version 4, Where the GICR_CTRL.EnableLPIs
remains programmable:
- Software must observe GICR_CTLR.RWP==0 after clearing GICR_CTLR.EnableLPIs
from 1 to 0 before writing GICR_PENDBASER or GICR_PROPBASER, otherwise
behavior is UNPREDICTABLE.
- Software must observe GICR_CTLR.RWP==0 after clearing GICR_CTLR.EnableLPIs
from 1 to 0 before setting GICR_CTLR.EnableLPIs to 1, otherwise behavior is
UNPREDICTABLE.
After changing EnableLPIs from 1 to 0, wait RWP got cleared, otherwise
setting EnableLPIs from 0 to 1 may fail.
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Tested-by: Clark Wang <xiaoning.wang@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Change-Id: I6aaf96dc9984376de9399d0dac8a8504ba095149
The GICR_WAKER.Sleep and GICR_WAKE.Quiescent functionality is solely
about flushing out the LPI cache and ensuring that the contents are
consistent with external memory.
Hence, as shown in GIC-700 TRM version r3p0, software must poll for
Quiescent bit only if LPIs are supported.
Change-Id: I7d69b208428e24d8a3ff30e81bd1a8ee3d0bda6e
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
GIC600 erratum 2384374 is a Category B erratum. Part 1 is fixed
in this patch, and the Part 1 failure mode is described as
'If the packet to be sent is a SET packet, then a higher priority SET
may not be sent when it should be until an unblocking event occurs.'
This is handled by calling gicv3_apply_errata_wa_2384374() in the
ehf_deactivate_priority() path, so that when EHF restores the priority
to the original priority, the interrupt packet buffered
in the GIC can be sent.
gicv3_apply_errata_wa_2384374() is the workaround for
the Part 2 of erratum 2384374 which flush packets from the GIC buffer
and is being used in this patch.
SDEN can be found here:
https://developer.arm.com/documentation/sden892601/latest/
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Change-Id: I4bb6dcf86c94125cbc574e0dc5119abe43e84731
In gicv3_main.c the function is_sgi_ppi() returns true when its
sgi/ppi or false when the interrupt number matches an spi interrupt.
Introducing a new API is_valid_interrupt() which validates if
an interrupt number matches SGI/PPI or SPI as a valid interrupt,
any other interrupt number is considered invalid and panics.
Change-Id: Idce8f5432a94c8d300b9408cf5b2502c60e13318
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
The generic interrupt controller identifies an interrupt based on its
type whereas the GIC uses the notion of groups to identify an
interrupt.
Currently, they are used interchangeably in GICv3 driver. It did not
cause any functional issues since the matching type and group had the
same value for corresponding macros. This patch makes the necessary
fixes.
The generic interrupt controller APIs, such as
plat_ic_set_interrupt_type map interrupt type to interrupt group
supported by the GICv3 IP. Similarly, other generic interrupt
controller APIs map interrupt group to interrupt type as needed.
This patch also changes the name of the helper functions to use group
rather than type for handling interrupts.
Change-Id: Ie2d88a3260c71e4ab9c8baacde24cc21e551de3d
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
The generic interrupt controller identifies an interrupt based on its
type whereas the GIC uses the notion of groups to identify an
interrupt.
This patch changes the name of the helper functions to use group
rather than type for handling interrupts. No functional change in this
patch.
Change-Id: If13ec65cc6c87c2da73a3d54b033f02635ff924a
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
gicv3_get_multichip_base in case of GICV3_IMPL_GIC600_MULTICHIP flag
being set, only works if the id belongs to SPI range.
Moving invocation of the function after confirming that the
intr_num belongs to SPI range.
Signed-off-by: sahil <sahil@arm.com>
Change-Id: I429eb473a7aeccb30309b1ffa5994663393ba0a2
According to GIC-600 TRM, it supports up to 960 SPIs. With the
starting SPI_ID of 32, the maximum SPI_ID should be 991. This patch
fixes the value of GIC600_SPI_ID_MAX which is currently configured
to be 960.
Signed-off-by: sahil <sahil@arm.com>
Change-Id: I441f9a607d160db8533f2a03e02afd1a9bab991e
EL3's context is poorly defined as it is and polluting it further is not
a good idea. Put it back as it was before the function call.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I9d13c9517962b501246989fd2126d08410191784
The purpose of this patch is to address the T241 erratum T241-FABRIC-4,
which causes unexpected behavior in the GIC when multiple transactions
are received simultaneously from different sources. This hardware issue
impacts NVIDIA server platforms that use more than two T241 chips
interconnected. Each chip has support for 320 {E}SPIs.
This issue occurs when multiple packets from different GICs are
incorrectly interleaved at the target chip. The erratum text below
specifies exactly what can cause multiple transfer packets susceptible
to interleaving and GIC state corruption. GIC state corruption can
lead to a range of problems, including kernel panics, and unexpected
behavior.
Erratum documentation:
https://developer.nvidia.com/docs/t241-fabric-4/nvidia-t241-fabric-4-errata.pdf
The workaround is to ensure that MMIO accesses target the GIC on the
socket that holds the data, for example SPI ranges owned by the socket’s
GIC. This ensures that the GIC will not utilize the inter-socket AXI
Stream interface for servicing these GIC MMIO accesses.
This patch updates the functions that use the GICD_In{E} registers to
ensure that the accesses are directed to the chip that owns the SPI,
instead of using the global alias.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I04e33ba64eb306bd5fdabb56e63cbe273d8cd632
Default priority was not being set for all interrupts (gicr_write_ipriorityr takes INTID, not register number). The fix makes the loop to pass INTID in range 0, 4, 8, 12, ...
Signed-off-by: Sylwester Garncarek <sylwester.garncarek@sciopta.com>
Change-Id: Iaa975f6af49f5826c2811161f55242844c28ea81
with reference to feature 04c730 (feat(cpus): make cache ops conditional),
booting with caches in debug recovery means SCTLR_C_BIT will be 0.
Wrap the assert for the d-cache enabled check in CONDITIONAL_CMO and
plat_can_cmo calls to allow booting with d-cache disabled.
Signed-off-by: Channagoud kadabi <kadabi@google.com>
Change-Id: I80153df493d1ec9e5e354c7c2e6a14322d22c446
When spi_id_max is 5119, the expression `(spi_id_max - 4096U + 1U >> 5)`
evaluates to 32 leading to undefined behavior when using it to left
shift 1. Fix this undefined behavior.
Reported-by coverity scan:
https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/RMB4U7COL6IONZWEGF2FWXOQ6FPDIT4U/
```
large_shift: In expression 1 << (spi_id_max - 4096U + 1U >> 5), left
shifting by more than 31 bits has undefined behavior. The shift
amount, spi_id_max - 4096U + 1U >> 5, is as much as 32.
```
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
Change-Id: I5e77a78b81a6d0367875e7ea432a82b6ba0e587c
- Removing platform dependencies from libc modules.
- Replacing panicking with actual error handling.
- Debug macros are included indirectly from assert.h. Removing
"platform_def.h" from assert.h and adding "common/debug.h"
where the macros are used.
- Removing hack for fixing PLAT_LOG_LEVEL_ASSERT to 40.
Instead removing assert with expression, as this
does not provide additional information.
Signed-off-by: Claus Pedersen <claustbp@google.com>
Change-Id: Icc201ea7b63c1277e423c1cfd13fd6816c2bc568
This patch adds two helper functions:
- plat_ic_raise_ns_sgi to raise a NS SGI
- plat_ic_raise_s_el1_sgi to raise a S-EL1 SGI
Signed-off-by: Florian Lugou <florian.lugou@provenrun.com>
Change-Id: I6f262dd1da1d77fec3f850eb74189e726b8e24da
This patch introduces support to validate the GIC-700 multichip data
structure passed by the platform.
GIC-700 provides support for SPI ID 4096 to 5119. Platforms using the
GIC-700 in a multichip configuration can enable these SPI IDs. The
driver needs to validate the data before using it and this patch
implements the support.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I6f85ec21ef7a59f397fcf6271f8c13c24fe47697
If the interrupt being targeted is released from the CPU before the
CLEAR command is sent to the CPU then a subsequent SET command may not
be delivered in a finite time. To workaround this, issue an unblocking
event by toggling GICR_CTLR.DPG* bits after clearing the cpu group
enable (EnableGrp* bits of GIC CPU interface register)
This fix is implemented as per the errata 2384374-part 2 workaround
mentioned here:
https://developer.arm.com/documentation/sden892601/latest/
Change-Id: I13926ceeb7740fa4c05cc5b43170e7ce49598f70
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
The following SMIDs are disabled by default.
* GICD: MBIST REQ error and GICD FMU ClkGate override
* PPI: MBIST REQ error and PPI FMU ClkGate override
* ITS: MBIST REQ error and ITS FMU ClkGate override
This patch explicitly enables them during the FMU init sequence.
Change-Id: I573e64786e3318d4cbcd07d0a1caf25f8e6e9200
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch updates the gic600_fmu_init function to disable all safety
mechanisms for a block ID that is not present on the platform. All
safety mechanisms for GIC-600AE are enabled by default and should be
disabled for blocks that are not present on the platform to avoid
false positive RAS errors.
Change-Id: I52dc3bee9a8b49fd2e51d7ed851fdc803a48e6e3
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
The GIC-600AE uses a range of RAS features for all RAMs, which include
SECDED, ECC, and Scrub, software and bus error reporting. The GIC makes
all necessary information available to software through Armv8.2 RAS
architecture compliant register space.
This patch introduces support to probe the FMU_ERRGSR register to find
the right error record. Once the correct record is identified, the
"handler" function queries the FMU_ERR<m>STATUS register to further
identify the block ID, safety mechanism and the architecturally defined
primary error code. The description of the error is displayed on the
console to simplify debug.
Change-Id: I7e543664b74457afee2da250549f4c3d9beb1a03
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
As mpidr is unsigned long long, U should be ULL. We use macro to
fix this issue.
Signed-off-by: Ming Huang <huangming@linux.alibaba.com>
Change-Id: I7dfd51a63f27f471794bcbf72ffff0c1a0598b46
The previous codes were using the cntpct_el0 to check the time
elapsed. But this physical timer does not seem to count for
the expected time resulting in gic fmu communication failures
on Tegra platforms.
This patch uses the delay_timer instead to use a platform
defined timer for calculating timeouts.
Change-Id: Ic8646ad1662c9928ac64c4152deb27e8c86fe344
Signed-off-by: Anthony Zhou <anzhou@nvidia.com>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
The GIC specification describes ID registers in each GIC register frame
(PIDRx), which can be used to identify a GIC component. The Arm Ltd. GIC
implementations use certain ID values to identify the distributor, the
redistributors and other parts like ITSes.
Introduce a function that reads those part number IDs, which are spread
over two registers. The actual numbers are only meaningful in connection
with a certain GIC model, which would need to be checked beforehand, by
the caller.
Change-Id: Ia6ff326a1e8b12664e4637bc8e2683d2b5c7721c
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
there are features which are marked as experimental even though they
are stable and used for quite some time.
Following features are no longer marked as experimental
- SPMD
- MEASURED_BOOT
- FCONF and associated build flags
- DECRYPTION_SUPPORT and associated build flags
- ENABLE_PAUTH
- ENABLE_BTI
- USE_SPINLOCK_CAS
- GICv3 Multichip support
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: I4bb653d9c413c66095ec31f0b8aefeb13ea04ee9
The FMU is part of the GIC Distributor (GICD) component. It implements
the following functionality in GIC-600AE:
* Provides software the means to enable or disable a Safety Mechanism
within a GIC block.
* Receives error signaling from all Safety Mechanisms within other GIC
blocks.
* Maintains error records for each GIC block, for software inspection
and provides information on the source of the error.
* Retains error records across functional reset.
* Enables software error recovery testing by providing error injection
capabilities in a Safety Mechanism.
This patch introduces support to enable error detection for all safety
mechanisms provided by the FMU. Platforms are expected to invoke the
initialization function during cold boot.
The support for the FMU is guarded by the GICV3_SUPPORT_GIC600AE_FMU
makefile variable. The default value of this variable is '0'.
Change-Id: I421c3d059624ddefd174cb1140a2d2a2296be0c6
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
At the moment we have a GIC_ENABLE_V4_EXTN build time variable to
determine whether the GIC interrupt controller is compliant to version
4.0 of the spec or not. This just changes the number of 64K MMIO pages
we expect per redistributor.
To support firmware builds which run on variable systems (emulators,
fast model or FPGAs), let's make this decision at runtime.
The GIC specification provides several architected flags to learn the
size of the MMIO frame per redistributor, we use GICR_TYPER[VLPI] here.
Provide a (static inline) function to return the size of each
redistributor.
We keep the GIC_ENABLE_V4_EXTN build time variable around, but change
its meaning to enable this autodetection code. Systems not defining this
rely on a "pure" GICv3 (as before), but platforms setting it to "1" can
now deal with both configurations.
Change-Id: I9ede4acf058846157a0a9e2ef6103bf07c7655d9
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
At the moment we have a GIC_ENABLE_V4_EXTN build time variable to
determine whether the GIC interrupt controller is compliant to version
4.0 of the GIC spec or not.
In case of the GIC-600 multichip support we were somewhat abusing that
flag to differentiate between a GIC-700 and GIC-600 implementation
being used in the system.
To avoid a build time dependency on this flag, look at the GICD_IIDR
register and check if the hardware is a GIC-600 or not, to make this
decision at runtime. We then use the values for either GIC-700 or the
GIC-600, respectively.
Change-Id: I8c09ec1cd6fd60d28da879ed55ffef5506f9869d
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
For the GIC power management we need to identify certain GIC
implementations, so we have the IIDR values for some Arm Ltd. GIC models
defined.
We will need those number elsewhere very soon, so export them to a
shared header file, to avoid defining them again.
Change-Id: I1b8e2d93d6cea0d066866143c89eef736231134f
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The GIC IP formerly known as "GIC Clayton" has been released under the
name of "GIC-700".
Rename occurences of Clayton in comments and macro names to reflect the
official name.
Change-Id: Ie8c55f7da7753127d58c8382b0033c1b486f7909
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
A RAS error may be triggered while offline core in OS. Error:
Uncorrected software error in the Distributor, with IERR=9,SERR=f.
Core put to sleep before its Group enables were cleared.
gicv3_cpuif_disable() will be called in offline core flow.
According to GIC architecture version 3 and version 4:
Architectural execution of a DSB instruction guarantees that
the last value written to ICC_IGRPEN0_EL1, ICC_IGRPEN1_EL1,
ICC_IGRPEN1_EL3 or GICC_CTLR.{EnableGrp0, EnableGrp1}is observed
by the associated Redistributor.
An ISB or other context synchronization operation must precede
the DSB to ensure visibility of System register writes.
Signed-off-by: Ming Huang <huangming@linux.alibaba.com>
Change-Id: Iff1475657f401374c761b5e8f2f5b3a4b2040e9d
Use helper functions to get SPI and ESPI INTID limit, to remove
several pieces of similar code in gicv3 driver.
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: Iaf441fe5e333c4260e7f6d98df6fdd931591976d
Add helper function gicv3_get_espi_limit() to get the value of
(maximum extended SPI INTID + 1), so that some duplicated code can be
removed later.
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: I0355ca2647f872e8189add259f6c47d415494cce
Add helper function gicv3_get_spi_limit() to get the value of (maximum
SPI INTID + 1), so that some duplicated code can be removed later.
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: I160c8a88fbb71d22790b8999a84afbfba766f5e7
ESPI register offset should also be shifted right by REG##R_SHIFT to
keep consistent.
It is not a functional issue, for GICD_OFFSET_64() is only used for
GICD_IROUTER<E>, and IROUTER_SHIFT is 0.
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: I76eee5c50e4300890e78e80bddde135ce88daa2d
Add debug log for the maximum supported INTID of SPI and eSPI on the
current GIC implementation.
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: Ie45ab1d85b39658c4ca4bc54ee433ac44e41d03f
The GICv3 architecture allows GICD_TYPER.ITLinesNumber to be 31, so
the maximum possible value for num_ints is 1024. The value must be
limited to (MAX_SPI_ID + 1), or GICD_OFFSET() will consider it as ESPI
INTID and return wrong register address.
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: Iddcb83d3e5d241b39f4176c19c2bceaa2c3dd653
In function gicv3_spis_config_defaults(), the variable num_ints is set
to (maximum SPI INTID + 1), while num_eints is set to (maximum ESPI
INTID). It introduces not only inconsistency to the code, but also
logical bug in the "for" loops, for the INTID of num_eints is also
valid and the check should be inclusive.
Fix this by setting num_eints to (maximum ESPI INTID + 1) as well.
Fix similar issues in gicv3_distif_save() and
gicv3_distif_init_restore().
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: I4425777d17e84e85f38853603340bd348640154f
RESTORE/SAVE_GICD_EREGS uses (int_id - (MIN_ESPI_ID - MIN_SPI_ID)) to
get the context array index for ESPI, which will override the space of
standard SPI starting from (MIN_SPI_ID + MIN_SPI_ID).
However, using TOTAL_SPI_INTR_NUM to replace the above MIN_SPI_ID
cannot totally fix the issue, for TOTAL_SPI_INTR_NUM is not well
aligned and the array index will be rounded down by the shifting
operation if being shifted more than 2 bits. It will cause buffer
override again when the existing maximum SPI reaches 1019.
So round up TOTAL_SPI_INTR_NUM with (1 << REG##R_SHIFT) for GICD
context arrays.
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: I5be2837c42f381a62f8d46a4ecd778009b1fe059
In function gicv3_rdistif_probe(), line #1322 implies
gicv3_driver_data->mpidr_to_core_pos() may be null, but the original
code uses this interface to get current CPU index unconditionally.
It is better to use MPIDR to probe GICR which does not depend on
gicv3_driver_data->mpidr_to_core_pos().
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: I64add055385040fe0a56b977e2299608e2309a6e
In the function gicv2_set_spi_routing, the signed value proc_num is cast
to unsigned int before being compared to other unsigned values in two
assert calls. The value proc_num can be a negative value, and once the
negative value is cast to unsigned it becomes a very large number which
will trigger the assert. This patch changes the assert cast so that the
unsigned values are cast to signed instead, keeping the same functionality
but allowing proc_num to be negative.
This bug can be seen when running the SDEI RM_ANY routing mode test in
TFTF on the Juno platform.
This patch also makes the usage of the proc_num variable in other gicv2
functions more clear.
Signed-off-by: John Powell <john.powell@arm.com>
Change-Id: If1b98eebb00bd9b73862e5e995e5e68c168170a6
A GICv3 interrupt controller will be instantiated for a certain number
of cores. This will result in the respective number of GICR frames. The
last frame will have the "Last" bit set in its GICR_TYPER register.
For platforms with a topology unknown at build time (the Arm FPGAs, for
instance), we need to learn the number of used cores at runtime, to size
the GICR region in the devicetree accordingly.
Add a generic function that iterates over all GICR frames until it
encounters one with the "Last" bit set. It returns the number of cores
the GICv3 has been configured for.
Change-Id: I79f033c50dfc1c275aba7122725868811abcc4f8
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
