arm-trusted-firmware

14349 Commits

5 Branches

114 Tags

55 MiB

Tree: fe8cc55a0c

Commit Graph

Author	SHA1	Message	Date
Andre Przywara	69c17f52f9	refactor(cpufeat): move helpers into .c file, rename FEAT_STATE_ The FEATURE_DETECTION functionality had some definitions in a header file, although they were only used internally in the .c file. Move them over there, since there are of no interest to other users. Also use the opportuntiy to rename the less telling FEAT_STATE_[12] names, and let the "0" case join the game. We use DISABLED, ALWAYS, and CHECK now, so that the casual reader has some idea what those numbers are supposed to mean. feature_panic() becomes "static inline", since disabling all features makes it unused, so the compiler complains otherwise. Finally add a new category "cpufeat" to cover CPU feature related changes. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Change-Id: If0c8ba91ad22440260ccff383c33bdd055eefbdc	2 years ago
Jayanth Dodderi Chidanand	6a0da73647	refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro "FEATURE_DETECTION", which is currently being disabled by default. The "FEATURE_DETECTION" macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this "FEATURE_DETECTION" flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43	3 years ago

Author

SHA1

Message

Date

Andre Przywara

69c17f52f9

refactor(cpufeat): move helpers into .c file, rename FEAT_STATE_

The FEATURE_DETECTION functionality had some definitions in a header
file, although they were only used internally in the .c file.
Move them over there, since there are of no interest to other users.

Also use the opportuntiy to rename the less telling FEAT_STATE_[12]
names, and let the "0" case join the game. We use DISABLED, ALWAYS, and
CHECK now, so that the casual reader has some idea what those numbers
are supposed to mean.

feature_panic() becomes "static inline", since disabling all features
makes it unused, so the compiler complains otherwise.

Finally add a new category "cpufeat" to cover CPU feature related
changes.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Change-Id: If0c8ba91ad22440260ccff383c33bdd055eefbdc

2 years ago

Jayanth Dodderi Chidanand

6a0da73647

refactor(el3-runtime): add arch-features detection mechanism

This patch adds architectural features detection procedure to ensure
features enabled are present in the given hardware implementation.

It verifies whether the architecture build flags passed during
compilation match the respective features by reading their ID
registers. It reads through all the enabled feature specific ID
registers at once and panics in case of mismatch(feature enabled
but not implemented in PE).

Feature flags are used at sections (context_management,
save and restore routines of registers) during context switch.
If the enabled feature flag is not supported by the PE, it causes an
exception while saving or restoring the registers guarded by them.

With this mechanism, the build flags are validated at an early
phase prior to their usage, thereby preventing any undefined action
under their control.

This implementation is based on tristate approach for each feature and
currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this
patch. FEAT_STATE=2 is planned for phase-2 implementation and will be
taken care separately.

The patch has been explicitly tested, by adding a new test_config
with build config enabling majority of the features and detected
all of them under FVP launched with parameters enabling v8.7 features.

Note: This is an experimental procedure and the mechanism itself is
      guarded by a macro "FEATURE_DETECTION", which is currently being
      disabled by default.

The "FEATURE_DETECTION" macro is documented and the platforms are
encouraged to make use of this diagnostic tool by enabling this
"FEATURE_DETECTION" flag explicitly and get used to its behaviour
during booting before the procedure gets mandated.

Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43

3 years ago

2 Commits (fe8cc55a0cb5e47a0c0e28b147ee3e8dfdae07b2)