| #
c0dbc3af |
| 01-Oct-2025 |
Manish V Badarkhe <manish.badarkhe@arm.com> |
Merge "fix(fvp): do not unregister the console on system suspend" into integration
|
| #
f185a542 |
| 29-Sep-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
fix(fvp): do not unregister the console on system suspend
On PSCI SYSTEM_SUSPEND, Arm platforms will call arm_system_pwr_domain_save() which will call arm_console_runtime_end(). Usually (eg CSS), th
fix(fvp): do not unregister the console on system suspend
On PSCI SYSTEM_SUSPEND, Arm platforms will call arm_system_pwr_domain_save() which will call arm_console_runtime_end(). Usually (eg CSS), that's just a flush, but on FVP that also unregisters the console. On HW_ASSISTED_COHERENCY=0 builds, this has the potential to break and prevent any EL3 output after a SYSTEM_SUSPEND.
This happens because the calls to console_unregister()/console_register() will overwrite the value of the console_list variable in drivers/console/multi_console.c. They are only called on a system level suspend. The bug happens when the core wakes up. The console will be registered again as part of the pwr_domain_suspend_finish() call. However, this call happens before the data caches have been enabled in psci_do_pwrup_cache_maintenance(). As a result, the write to console_list will not be reflected in the L2 cache and other cores will not be able to read the new value.
The fix is to not unregister the console like other Arm platforms - we don't need to reinitialise the console so there's nothing to do.
A nice side effect is that arm_console_runtime_end() no longer needs to be weak.
Change-Id: Ibbdd4b22bad0d8f1dbd63c60ee0294d889a349a4 Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
a4c69581 |
| 15-Mar-2023 |
Manish Pandey <manish.pandey2@arm.com> |
Merge "refactor(build): distinguish BL2 as TF-A entry point and BL2 running at EL3" into integration
|
| #
42d4d3ba |
| 22-Nov-2022 |
Arvind Ram Prakash <arvind.ramprakash@arm.com> |
refactor(build): distinguish BL2 as TF-A entry point and BL2 running at EL3
BL2_AT_EL3 is an overloaded macro which has two uses: 1. When BL2 is entry point into TF-A(no BL1) 2. When BL2 is runnin
refactor(build): distinguish BL2 as TF-A entry point and BL2 running at EL3
BL2_AT_EL3 is an overloaded macro which has two uses: 1. When BL2 is entry point into TF-A(no BL1) 2. When BL2 is running at EL3 exception level These two scenarios are not exactly same even though first implicitly means second to be true. To distinguish between these two use cases we introduce new macros. BL2_AT_EL3 is renamed to RESET_TO_BL2 to better convey both 1. and 2. Additional macro BL2_RUNS_AT_EL3 is added to cover all scenarious where BL2 runs at EL3 (including four world systems).
BREAKING CHANGE: BL2_AT_EL3 renamed to RESET_TO_BL2 across the repository.
Change-Id: I477e1d0f843b44b799c216670e028fcb3509fb72 Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com> Signed-off-by: Maksims Svecovs <maksims.svecovs@arm.com>
show more ...
|
| #
dfe577a8 |
| 14-Oct-2020 |
Mark Dykes <mardyk01@review.trustedfirmware.org> |
Merge "Don't return error information from console_flush" into integration
|
| #
831b0e98 |
| 05-Aug-2020 |
Jimmy Brisson <jimmy.brisson@arm.com> |
Don't return error information from console_flush
And from crash_console_flush.
We ignore the error information return by console_flush in _every_ place where we call it, and casting the return typ
Don't return error information from console_flush
And from crash_console_flush.
We ignore the error information return by console_flush in _every_ place where we call it, and casting the return type to void does not work around the MISRA violation that this causes. Instead, we collect the error information from the driver (to avoid changing that API), and don't return it to the caller.
Change-Id: I1e35afe01764d5c8f0efd04f8949d333ffb688c1 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
show more ...
|
| #
beff4910 |
| 22-May-2020 |
Mark Dykes <mardyk01@review.trustedfirmware.org> |
Merge "plat/arm/fvp: populate runtime console parameters dynamically" into integration
|
| #
12d13430 |
| 16-Apr-2020 |
Madhukar Pappireddy <madhukar.pappireddy@arm.com> |
plat/arm/fvp: populate runtime console parameters dynamically
We query the UART base address and clk frequency in runtime using fconf getter APIs.
Change-Id: I5f4e84953be5f384472bf90720b706d45cb862
plat/arm/fvp: populate runtime console parameters dynamically
We query the UART base address and clk frequency in runtime using fconf getter APIs.
Change-Id: I5f4e84953be5f384472bf90720b706d45cb86260 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
show more ...
|