Merge "refactor(fvp): move cpus with nomodel" into integration

refactor(fvp): move cpus with nomodel

Move CPUs which are not tested in CI under a new build option.
We have added some CPUs for which there is no FVP models available
yet to test. Move those CPUs u

refactor(fvp): move cpus with nomodel

Move CPUs which are not tested in CI under a new build option.
We have added some CPUs for which there is no FVP models available
yet to test. Move those CPUs under a new FVP build option.

Change-Id: I3da12d2f8d9c246b435b31adfac61c79dc1ab0cb
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

Merge changes I9eba2e34,Iab2a2a2f into integration

* changes:
refactor(cpus): replace adr with adr_l
refactor(build): introduce adr_l macro

refactor(cpus): replace adr with adr_l

Replace "adr" with "adr_l" to handle symbols or labels that exceeds 1MB
access range. This modification resolves the link error.

Change-Id: I9eba2e34c0a303b40

refactor(cpus): replace adr with adr_l

Replace "adr" with "adr_l" to handle symbols or labels that exceeds 1MB
access range. This modification resolves the link error.

Change-Id: I9eba2e34c0a303b40e4c7b3ea7c5b113f4c6d989
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>

show more ...

refactor(build): introduce adr_l macro

Introduce the macro "adr_l," which can handle symbols or labels that
exceed the 1MB access range compared to the "adr" instruction.

Change-Id: Iab2a2a2f8a11a5

refactor(build): introduce adr_l macro

Introduce the macro "adr_l," which can handle symbols or labels that
exceed the 1MB access range compared to the "adr" instruction.

Change-Id: Iab2a2a2f8a11a5e21e386f1001ba27a8de621132
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>

show more ...

Merge "build(fvp): make all builds unconditional" into integration

refactor(cpufeat): restore functions in detect_arch_features

The newly introduced wrapper macro CREATE_FEATURE_PRESENT
replaces the read_feat_xx_id_field function that returns
an integer with the is

refactor(cpufeat): restore functions in detect_arch_features

The newly introduced wrapper macro CREATE_FEATURE_PRESENT
replaces the read_feat_xx_id_field function that returns
an integer with the is_feat_xx_present function that returns
a boolean based on the idfield, mask and feature enablement flag.

This impacts check_feature api which is explicilty used in
detect_arch_features procedure. In order to keep it in original
form, the read functions have been added. Further, the scope has
also been reduced to static without introducing any additonal
overhead on code size, as the feat_detect.c is included for build
only when the FEATURE_DETECTION flag is enabled.

Change-Id: If364f32837a2ad19f49e4f0d355274bf7f26aaac
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>

show more ...

refactor(cpufeat): add macro to simplify is_feat_xx_present

In this patch, we are trying to introduce the wrapper macro
CREATE_FEATURE_PRESENT to get the following capability and
align it for all th

refactor(cpufeat): add macro to simplify is_feat_xx_present

In this patch, we are trying to introduce the wrapper macro
CREATE_FEATURE_PRESENT to get the following capability and
align it for all the features:

-> is_feat_xx_present(): Does Hardware implement the feature.
-> uniformity in naming the function across multiple features.
-> improved readability

The is_feat_xx_present() is implemented to check if the hardware
implements the feature and does not take into account the
ENABLE_FEAT_XXX flag enabled/disabled in software.

- CREATE_FEATURE_PRESENT(name, idreg, shift, mask, idval)
The wrapper macro reduces the function to a single line and
creates the is_feat_xx_present function that checks the
id register based on the shift and mask values and compares
this against a determined idvalue.

Change-Id: I7b91d2c9c6fbe55f94c693aa1b2c50be54fb9ecc
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>

show more ...

chore: simplify the macro names in ENABLE_FEAT mechanism

Currently, the macros used to denote feature implementation
in hardware follow a random pattern with a few macros having
suffix as SUPPORTED

chore: simplify the macro names in ENABLE_FEAT mechanism

Currently, the macros used to denote feature implementation
in hardware follow a random pattern with a few macros having
suffix as SUPPORTED and a few using the suffix IMPLEMENTED.
This patch aligns the macro names uniformly using the suffix
IMPLEMENTED across all the features and removes unused macros
pertaining to the Enable feat mechanism.

FEAT_SUPPORTED --> FEAT_IMPLEMENTED
FEAT_NOT_SUPPORTED --> FEAT_NOT_IMPLEMENTED

Change-Id: I61bb7d154b23f677b80756a4b6a81f74b10cd24f
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>

show more ...

Merge "feat(zynqmp): remove unused pm_get_proc_by_node()" into integration

Merge "fix(xilinx): check proc variable before use" into integration

feat(zynqmp): remove unused pm_get_proc_by_node()

The pm_get_proc_by_node() is not used anywhere. Hence remove the
same.

Change-Id: Ifd68dd524cae0a9f1684d943019563027859ccea
Signed-off-by: Ronak Ja

feat(zynqmp): remove unused pm_get_proc_by_node()

The pm_get_proc_by_node() is not used anywhere. Hence remove the
same.

Change-Id: Ifd68dd524cae0a9f1684d943019563027859ccea
Signed-off-by: Ronak Jain <ronak.jain@amd.com>

show more ...

fix(plat/marvell/a3k): reset GIC before resetting via CM3 secure coprocessor

Add code that acknowledges all SoC interrupts and resets the Generic
Interrupt Controller before resetting the SoC via th

fix(plat/marvell/a3k): reset GIC before resetting via CM3 secure coprocessor

Add code that acknowledges all SoC interrupts and resets the Generic
Interrupt Controller before resetting the SoC via the Cortex-M3 secure
coprocessor.

Recall that Turris MOX has a HW bug wherein a SoC reset initiated by
writing the magic value to the North Bridge Warm Reset register may
randomly freeze the board.

Back in 2021 we introduced the CM3_SYSTEM_RESET build option for the
Armada 3700 platform, which, when enabled, adds code to the PSCI reset
handler so that the SoC reset is done by requesting the firmware in the
Cortex-M3 secure coprocessor to do it, instead of writing the Warm Reset
register.

The secure coprocessor firmware tried various things to put the board
into a state where the SoC reset circuit would work correctly. This
managed to fix the issue for some boards, but not for all of them.

Another considered method to overcome this issue was to reset all the
SoC peripheral controllers one by one by writing to specific registers,
instead of triggering the SoC reset circuit via the Warm Reset register.
This method was not used because until now, there was one peripheral
that I could not find a way how to reset properly: the Generic Interrupt
Controller (GIC).

After 3 years I have finally found a way how to reset the GIC, and it
needs to be done by the main processor, before the secure coprocessor
resets the main processor.

Change-Id: Icc23251ef97738b6b48af514d5118440ec21cdd7
Signed-off-by: Marek Behún <marek.behun@nic.cz>

show more ...

Merge "feat(mt8188): remove apusys kernel handler usage constraints" into integration

build(fvp): make all builds unconditional

commit@138221c2457b9d04101b84084c07d576b0eb5a51 reduced items that
should be build due to SRAM size limitations.

But newer models from 11.19 onwards suppor

build(fvp): make all builds unconditional

commit@138221c2457b9d04101b84084c07d576b0eb5a51 reduced items that
should be build due to SRAM size limitations.

But newer models from 11.19 onwards support to set SRAM size greater
than 256KB. So remove all dependency and conditional builds for FVP.

Change-Id: I38684e100450b74fdda0d685775e2cbce92170b6
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

refactor(tc): move SCMI nodes into the 'firmware' node

As Linux 6.1 and later kernels require the SCMI nodes must be placed in
a firmware node, this patch adds the 'firmware' node and puts SCMI node

refactor(tc): move SCMI nodes into the 'firmware' node

As Linux 6.1 and later kernels require the SCMI nodes must be placed in
a firmware node, this patch adds the 'firmware' node and puts SCMI nodes
under it.

Change-Id: I37855095b8b0e5051c5de6e8db30e43f6220f9de
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

refactor(tc): move MHUv2 property to tc2.dts

As only TC2 uses MHUv2, move the protocol property to tc2.dts.

Change-Id: I39dd57311e1058a6aabd4cbd5028511f704dd234
Signed-off-by: Boyan Karatotev <boya

refactor(tc): move MHUv2 property to tc2.dts

As only TC2 uses MHUv2, move the protocol property to tc2.dts.

Change-Id: I39dd57311e1058a6aabd4cbd5028511f704dd234
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

refactor(tc): drop the 'mhu-protocol' property in DT binding

As the 'mhu-protocol' property is not used in mhu node, drop it.

Change-Id: I2f7320f668451ce44601dfa48bf47103334c39ed
Signed-off-by: Boy

refactor(tc): drop the 'mhu-protocol' property in DT binding

As the 'mhu-protocol' property is not used in mhu node, drop it.

Change-Id: I2f7320f668451ce44601dfa48bf47103334c39ed
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

refactor(tc): append properties in DT bindings

This patch appends properties in DT bindings to differentiate between
FVP and FPGA. The related macros are no longer used, so they are
removed.

This p

refactor(tc): append properties in DT bindings

This patch appends properties in DT bindings to differentiate between
FVP and FPGA. The related macros are no longer used, so they are
removed.

This patch contains minor improvement for adding labels in device nodes.

Change-Id: I8d708bb7a8a9a0ed32b806abcb4e7651daadf5e6
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

refactor(tc): move SCMI clock DT binding into tc-base.dtsi

As SCMI clock DT bindings are common for TC platforms, move them into
'tc-base.dtsi'.

As a result, the file 'tc_vers.dtsi' is empty, so re

refactor(tc): move SCMI clock DT binding into tc-base.dtsi

As SCMI clock DT bindings are common for TC platforms, move them into
'tc-base.dtsi'.

As a result, the file 'tc_vers.dtsi' is empty, so removes it.

Change-Id: Iaa7219bbbde8458dcfe01de7ad6c277a960357c5
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

refactor(tc): introduce a new file tc-fpga.dtsi

A Total Compute platform supports FVP and FPGA target. And it's possible
that these two targets have different hardware components. For this
reason, t

refactor(tc): introduce a new file tc-fpga.dtsi

A Total Compute platform supports FVP and FPGA target. And it's possible
that these two targets have different hardware components. For this
reason, this patch introduces a new file tc-fpga.dtsi for FPGA related
DT binding.

As a result, this patch moves out FVP and FPGA specific macros into
tc-fvp.dtsi and tc-fpga.dtsi respectively.

Change-Id: I48d7d30d0c500cec5500f1a2a680e8b3a276ea99
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

refactor(tc): move out platform specific DT binding from tc-base.dtsi

The main purpose of 'tc-base.dtsi' is for common DT bindings, however,
it contains bindings for platform specific.

This patch m

refactor(tc): move out platform specific DT binding from tc-base.dtsi

The main purpose of 'tc-base.dtsi' is for common DT bindings, however,
it contains bindings for platform specific.

This patch moves out these plaform specific bindings to 'tc2.dts' and
'tc3.dts' respectively.

Change-Id: I9355eeff539a3f2940190aef399b4fb4828cbbac
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

refactor(tc): move out platform specific code from tc_vers.dtsi

Since now every TC board has its own dts file, this patch moves out the
platform specific code from tc_vers.dtsi to the corresponding

refactor(tc): move out platform specific code from tc_vers.dtsi

Since now every TC board has its own dts file, this patch moves out the
platform specific code from tc_vers.dtsi to the corresponding platform
dts file.

Change-Id: I62e0872eddb2ae18e666a3f8dc0118a539651a9c
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

refactor(tc): add platform specific DT files

Currently, the DT binding uses the file 'tc.dts' as a central place for
all TC platforms. And the variables (for different platforms, or FVP vs
FPGA, etc

refactor(tc): add platform specific DT files

Currently, the DT binding uses the file 'tc.dts' as a central place for
all TC platforms. And the variables (for different platforms, or FVP vs
FPGA, etc.) are maintained in 'tc_vers.dtsi'.

This patch renames 'tc.dts' to 'tc-base.dtsi' and creates an individual
.dts file for every platform. The purpose is to use 'tc-base.dtsi' for
maintaining common DT binding and every platform's specific definitions
will be moved into its own .dts file. This is a preparation for
sequential refactoring.

It changes to include the header files in platform DTS files but not in
the 'tc-base.dtsi'. This can allow 'tc-base.dtsi' is general enough and
platform DTS files covers platform specific defintions.

Change-Id: I034fb3f8836bcea36e8ad8ae01de41127693b0c6
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

refactor(tc): rename 'tc_fvp.dtsi' to 'tc-fvp.dtsi'

To follow up the DT naming convention, this patch renames the file
'tc_fvp.dtsi' to 'tc-fvp.dtsi'.

Change-Id: Ib74cc38eb935d3daac87fbab6de4c004b1

refactor(tc): rename 'tc_fvp.dtsi' to 'tc-fvp.dtsi'

To follow up the DT naming convention, this patch renames the file
'tc_fvp.dtsi' to 'tc-fvp.dtsi'.

Change-Id: Ib74cc38eb935d3daac87fbab6de4c004b1ceddcc
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...