| a852fa1d | 21-Feb-2025 |
Harrison Mutai <harrison.mutai@arm.com> |
feat(arm): support boot info handoff and event log
Add support for processing boot arguments via Firmware
Handoff on Arm platforms. Update platform hooks to pass
boot info to BL31 and BL32 stages.
feat(arm): support boot info handoff and event log
Add support for processing boot arguments via Firmware
Handoff on Arm platforms. Update platform hooks to pass
boot info to BL31 and BL32 stages.
Enable parsing and dumping of an event log from the
transfer list when MEASURED_BOOT is enabled. This allows
measured boot testing in the secure world.
Also update BL32 sources to include event log support when
TSPD and measured boot are both enabled.
Change-Id: Ia310696d0e6cfe93d756bfb075e9fda08342c0a1
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
show more ...
|
| 92aa7b42 | 04-Feb-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
chore: fix preprocessor checks
We can also drop the preprocessor check from plat_gic_init - it was
introduced because the tsp needed to call this function on gicv2 but not
gicv3 and this was the cle
chore: fix preprocessor checks
We can also drop the preprocessor check from plat_gic_init - it was
introduced because the tsp needed to call this function on gicv2 but not
gicv3 and this was the cleanest way to filter this out. Now that we have
the generic driver, the caller has all the tools to cater for this.
Callers have been converted so this is redundant.
Also, the FVP observes different behaviour on debug and release builds
in regards to the contents of plat_params_from_bl2. Make this explicit
so that release builds with ENABLE_ASSERTIONS=1 are possible.
Change-Id: I86959e67460d0c25c558f33c08e6233a8b6eeb7f
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| 5d893410 | 07-Jan-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
refactor(gic): promote most of the GIC driver to common code
More often than not, Arm based systems include some revision of a GIC.
There are two ways of adding support for them in platform code - c
refactor(gic): promote most of the GIC driver to common code
More often than not, Arm based systems include some revision of a GIC.
There are two ways of adding support for them in platform code - calling
the top-level helpers from plat/arm/common/arm_gicvX.c or by using the
driver directly. Both of these methods allow for a high degree of
customisation - most functions are defined to be weak and there are no
calls to any of them in generic code.
As it turns out, requirements around those GICs are largely the same.
Platforms that use arm_gicvX.c use the helpers identically among each
other. Platforms that use the driver directly tend to end up with calls
that look a lot like the arm_gicvX.c helpers and the weakness of the
functions are never exercised.
All of this results in a lot of code duplication to do what is
essentially the same thing. Even though it's not a lot of code, when
multiplied among many platforms it becomes significant and makes
refactoring it quite difficult. It's also bug prone since the steps are
a little convoluted and things are likely to work even with subtle
errors (see 50009f61177421118f42d6a000611ba0e613d54b).
So promote as much of the GIC to be called from common code. Do the
setup in bl31_main() and have every PSCI method do the state management
directly instead of delegating it to the platform hooks. We can base
this implementation on arm_gicvX.c since they already offer logical
names and have worked quite well so far with minimal changes.
The main benefit of doing this is reduced code duplication. If we assume
that, outside of some platform setup, GIC management is identical, then
a platform can add support by telling the build system, regardless of
GIC revision. The other benefit is performance - BL31 and PSCI already
know the core_pos and they can pass it as an argument instead of having
to call plat_my_core_pos(). Now, the only platform specific GIC actions
necessary are the saving and restoring of context on entering and
exiting a power domain. The PSCI library does not keep track of this so
it is unable perform it itself. The routines themselves are also
provided.
For compatibility all of this is hidden behind a build flag. Platforms
are encouraged to adopt this driver, but it would not be practical to
convert and validate every GIC based platform.
This patch renames the functions in question to follow the
gic_<function>() convention. This allows the names to be version
agnostic.
Finally, drop the weak definitions - they are unused, likely to remain
so, and can be added back if the need arises.
Change-Id: I5b5267f4b72f633fb1096400ec8e4b208694135f
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| b6e6e2e6 | 20-Mar-2025 |
Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> |
refactor(arm): simplify early platform setup function in BL31
Refactor `arm_bl31_early_platform_setup` to accept generic u_register_t
values, enabling support for firmware handoff boot arguments in
refactor(arm): simplify early platform setup function in BL31
Refactor `arm_bl31_early_platform_setup` to accept generic u_register_t
values, enabling support for firmware handoff boot arguments in
common code. This simplifies the interface for early platform setup.
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: Iff20300d2372e1a9825827ddccbd1b3bc6751e40
show more ...
|
| 8187b95e | 13-Mar-2025 |
Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> |
refactor(arm): simplify early platform setup function in BL2
Refactor `arm_bl2_early_platform_setup` to accept generic u_register_t
values, enabling support for firmware handoff boot arguments in
co
refactor(arm): simplify early platform setup function in BL2
Refactor `arm_bl2_early_platform_setup` to accept generic u_register_t
values, enabling support for firmware handoff boot arguments in
common code. This simplifies the interface for early platform setup.
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: Ie0dbe4d32bbef22bd185fdafe50091a2ea5f550f
show more ...
|