github/arm-trusted-firmware - arm-trusted-firmware - Gitea: Git with home nas server

Author	SHA1	Message	Date
Jayanth Dodderi Chidanand	47c681b7d7	feat(trbe): add trbe under feature detection mechanism This change adds "FEAT_TRBE" to be part of feature detection mechanism. Previously feature enablement flags were of boolean type, containing either 0 or 1. With the introduction of feature detection procedure we now support three states for feature enablement build flags(0 to 2). Accordingly, "ENABLE_TRBE_FOR_NS" flag is now modified from boolean to numeric type to align with the feature detection. Change-Id: I53d3bc8dc2f6eac63feef22dfd627f3a48480afc Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>	3 years ago
Jayanth Dodderi Chidanand	1298f2f13d	feat(brbe): add brbe under feature detection mechanism This change adds "FEAT_BRBE" to be part of feature detection mechanism. Previously feature enablement flags were of boolean type, possessing either 0 or 1. With the introduction of feature detection procedure we now support three states for feature enablement build flags(0 to 2). Accordingly, "ENABLE_BRBE_FOR_NS" flag is now modified from boolean to numeric type to align with the feature detection. Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> Change-Id: I1eb52863b4afb10b808e2f0b6584a8a210d0f38c	3 years ago
Jayanth Dodderi Chidanand	781d07a421	refactor(twed): improve TWED enablement in EL-3 The current implementation uses plat_arm API under generic code. "plat_arm" API is a convention used with Arm common platform layer and is reserved for that purpose. In addition, the function has a weak definition which is not encouraged in TF-A. Henceforth, removing the weak API with a configurable macro "TWED_DELAY" of numeric data type in generic code and simplifying the implementation. By default "TWED_DELAY" is defined to zero, and the delay value need to be explicitly set by the platforms during buildtime. Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> Change-Id: I25cd6f628e863dc40415ced3a82d0662fdf2d75a	3 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