| /rk3399_ARM-atf/lib/extensions/ras/ |
| H A D | ras_common.c | 553c24c3ad1fd996b4ae873b09a325c1747990a8 Mon Jul 07 12:21:13 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED
can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the
is_feat_ras_supported() helper instead of the `#if FEATURE` pattern.
There are no corner cases to consider there. The feature is either
present (and appropriate action must be taken) or the feature is not (so
we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors
despite it being in a hot path. Any fixed platform that seeks to be
performant should be setting features to 0 or 1. Then, the
SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect
FEAT_IESB to be present if FEAT_RAS is (despite the architecture not
guaranteeing it). If FEAT_RAS isn't present then we don't particularly
care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work.
This is true out of the box with the is_feat_xyz_supported() helpers, as
they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work.
This is also true out of the box and no logical change is undertaken in
common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the
whole handling machinery will be built-in and registered as appropriate.
However, when RAS is built-in but not present in hardware, these
registrations can still happen, they will only never be invoked at
runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/docs/components/ |
| H A D | ras.rst | 553c24c3ad1fd996b4ae873b09a325c1747990a8 Mon Jul 07 12:21:13 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED
can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the
is_feat_ras_supported() helper instead of the `#if FEATURE` pattern.
There are no corner cases to consider there. The feature is either
present (and appropriate action must be taken) or the feature is not (so
we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors
despite it being in a hot path. Any fixed platform that seeks to be
performant should be setting features to 0 or 1. Then, the
SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect
FEAT_IESB to be present if FEAT_RAS is (despite the architecture not
guaranteeing it). If FEAT_RAS isn't present then we don't particularly
care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work.
This is true out of the box with the is_feat_xyz_supported() helpers, as
they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work.
This is also true out of the box and no logical change is undertaken in
common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the
whole handling machinery will be built-in and registered as appropriate.
However, when RAS is built-in but not present in hardware, these
registrations can still happen, they will only never be invoked at
runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/common/ |
| H A D | runtime_svc.c | 553c24c3ad1fd996b4ae873b09a325c1747990a8 Mon Jul 07 12:21:13 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED
can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the
is_feat_ras_supported() helper instead of the `#if FEATURE` pattern.
There are no corner cases to consider there. The feature is either
present (and appropriate action must be taken) or the feature is not (so
we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors
despite it being in a hot path. Any fixed platform that seeks to be
performant should be setting features to 0 or 1. Then, the
SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect
FEAT_IESB to be present if FEAT_RAS is (despite the architecture not
guaranteeing it). If FEAT_RAS isn't present then we don't particularly
care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work.
This is true out of the box with the is_feat_xyz_supported() helpers, as
they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work.
This is also true out of the box and no logical change is undertaken in
common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the
whole handling machinery will be built-in and registered as appropriate.
However, when RAS is built-in but not present in hardware, these
registrations can still happen, they will only never be invoked at
runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/include/arch/aarch64/ |
| H A D | asm_macros.S | 553c24c3ad1fd996b4ae873b09a325c1747990a8 Mon Jul 07 12:21:13 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED
can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the
is_feat_ras_supported() helper instead of the `#if FEATURE` pattern.
There are no corner cases to consider there. The feature is either
present (and appropriate action must be taken) or the feature is not (so
we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors
despite it being in a hot path. Any fixed platform that seeks to be
performant should be setting features to 0 or 1. Then, the
SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect
FEAT_IESB to be present if FEAT_RAS is (despite the architecture not
guaranteeing it). If FEAT_RAS isn't present then we don't particularly
care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work.
This is true out of the box with the is_feat_xyz_supported() helpers, as
they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work.
This is also true out of the box and no logical change is undertaken in
common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the
whole handling machinery will be built-in and registered as appropriate.
However, when RAS is built-in but not present in hardware, these
registrations can still happen, they will only never be invoked at
runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/plat/common/aarch64/ |
| H A D | plat_common.c | 553c24c3ad1fd996b4ae873b09a325c1747990a8 Mon Jul 07 12:21:13 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED
can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the
is_feat_ras_supported() helper instead of the `#if FEATURE` pattern.
There are no corner cases to consider there. The feature is either
present (and appropriate action must be taken) or the feature is not (so
we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors
despite it being in a hot path. Any fixed platform that seeks to be
performant should be setting features to 0 or 1. Then, the
SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect
FEAT_IESB to be present if FEAT_RAS is (despite the architecture not
guaranteeing it). If FEAT_RAS isn't present then we don't particularly
care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work.
This is true out of the box with the is_feat_xyz_supported() helpers, as
they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work.
This is also true out of the box and no logical change is undertaken in
common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the
whole handling machinery will be built-in and registered as appropriate.
However, when RAS is built-in but not present in hardware, these
registrations can still happen, they will only never be invoked at
runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/plat/arm/common/ |
| H A D | arm_bl31_setup.c | 553c24c3ad1fd996b4ae873b09a325c1747990a8 Mon Jul 07 12:21:13 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED
can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the
is_feat_ras_supported() helper instead of the `#if FEATURE` pattern.
There are no corner cases to consider there. The feature is either
present (and appropriate action must be taken) or the feature is not (so
we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors
despite it being in a hot path. Any fixed platform that seeks to be
performant should be setting features to 0 or 1. Then, the
SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect
FEAT_IESB to be present if FEAT_RAS is (despite the architecture not
guaranteeing it). If FEAT_RAS isn't present then we don't particularly
care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work.
This is true out of the box with the is_feat_xyz_supported() helpers, as
they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work.
This is also true out of the box and no logical change is undertaken in
common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the
whole handling machinery will be built-in and registered as appropriate.
However, when RAS is built-in but not present in hardware, these
registrations can still happen, they will only never be invoked at
runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/bl31/ |
| H A D | bl31.mk | 553c24c3ad1fd996b4ae873b09a325c1747990a8 Mon Jul 07 12:21:13 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED
can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the
is_feat_ras_supported() helper instead of the `#if FEATURE` pattern.
There are no corner cases to consider there. The feature is either
present (and appropriate action must be taken) or the feature is not (so
we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors
despite it being in a hot path. Any fixed platform that seeks to be
performant should be setting features to 0 or 1. Then, the
SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect
FEAT_IESB to be present if FEAT_RAS is (despite the architecture not
guaranteeing it). If FEAT_RAS isn't present then we don't particularly
care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work.
This is true out of the box with the is_feat_xyz_supported() helpers, as
they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work.
This is also true out of the box and no logical change is undertaken in
common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the
whole handling machinery will be built-in and registered as appropriate.
However, when RAS is built-in but not present in hardware, these
registrations can still happen, they will only never be invoked at
runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/docs/getting_started/ |
| H A D | build-options.rst | 553c24c3ad1fd996b4ae873b09a325c1747990a8 Mon Jul 07 12:21:13 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED
can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the
is_feat_ras_supported() helper instead of the `#if FEATURE` pattern.
There are no corner cases to consider there. The feature is either
present (and appropriate action must be taken) or the feature is not (so
we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors
despite it being in a hot path. Any fixed platform that seeks to be
performant should be setting features to 0 or 1. Then, the
SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect
FEAT_IESB to be present if FEAT_RAS is (despite the architecture not
guaranteeing it). If FEAT_RAS isn't present then we don't particularly
care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work.
This is true out of the box with the is_feat_xyz_supported() helpers, as
they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work.
This is also true out of the box and no logical change is undertaken in
common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the
whole handling machinery will be built-in and registered as appropriate.
However, when RAS is built-in but not present in hardware, these
registrations can still happen, they will only never be invoked at
runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/plat/arm/board/fvp/ |
| H A D | platform.mk | 553c24c3ad1fd996b4ae873b09a325c1747990a8 Mon Jul 07 12:21:13 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED
can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the
is_feat_ras_supported() helper instead of the `#if FEATURE` pattern.
There are no corner cases to consider there. The feature is either
present (and appropriate action must be taken) or the feature is not (so
we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors
despite it being in a hot path. Any fixed platform that seeks to be
performant should be setting features to 0 or 1. Then, the
SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect
FEAT_IESB to be present if FEAT_RAS is (despite the architecture not
guaranteeing it). If FEAT_RAS isn't present then we don't particularly
care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work.
This is true out of the box with the is_feat_xyz_supported() helpers, as
they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work.
This is also true out of the box and no logical change is undertaken in
common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the
whole handling machinery will be built-in and registered as appropriate.
However, when RAS is built-in but not present in hardware, these
registrations can still happen, they will only never be invoked at
runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/ |
| H A D | Makefile | 553c24c3ad1fd996b4ae873b09a325c1747990a8 Mon Jul 07 12:21:13 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED
can still be allowed by being a bit clever about it.
First, the remainder of common code can be converted to use the
is_feat_ras_supported() helper instead of the `#if FEATURE` pattern.
There are no corner cases to consider there. The feature is either
present (and appropriate action must be taken) or the feature is not (so
we can skip RAS code).
A conscious choice is taken to check the RAS code in synchronize_errors
despite it being in a hot path. Any fixed platform that seeks to be
performant should be setting features to 0 or 1. Then, the
SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect
FEAT_IESB to be present if FEAT_RAS is (despite the architecture not
guaranteeing it). If FEAT_RAS isn't present then we don't particularly
care about the status of FEAT_IESB.
Second, platforms that don't set ENABLE_FEAT_RAS must continue to work.
This is true out of the box with the is_feat_xyz_supported() helpers, as
they make sure to fully disable code within them.
Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work.
This is also true out of the box and no logical change is undertaken in
common code.
Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the
whole handling machinery will be built-in and registered as appropriate.
However, when RAS is built-in but not present in hardware, these
registrations can still happen, they will only never be invoked at
runtime.
Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|