Hi James & TF-A guys,
When hest acpi table configure Hardware Error Notification type as
Software Delegated Exception(0x0B) for RAS event, kernel RAS interacts with
TF-A by SDEI mechanism. On the firmware first system, kernel was notified by
TF-A sdei call.
The calling flow like as below when fatal RAS error happens:
TF-A notify kernel flow:
sdei_dispatch_event()
ehf_activate_priority()
call sdei callback // callback registered by kerenl
ehf_deactivate_priority()
Kernel sdei callback:
sdei_asm_handler()
__sdei_handler()
_sdei_handler()
sdei_event_handler()
ghes_sdei_critical_callback()
ghes_in_nmi_queue_one_entry()
/* if RAS error is fatal */
__ghes_panic()
panic()
If fatal RAS error occured, panic was called in sdei_asm_handle()
without ehf_deactivate_priority executed, which lead interrupt masked.
If interrupt masked, system would be halted in kdump flow like this:
arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for cmdq
arm-smmu-v3 arm-smmu-v3.3.auto: allocated 32768 entries for evtq
arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for priq
arm-smmu-v3 arm-smmu-v3.3.auto: SMMU currently enabled! Resetting...
So interrupt should be restored before panic otherwise kdump will hang.
In the process of sdei, a SDEI_EVENT_COMPLETE(or SDEI_EVENT_COMPLETE_AND_RESUME)
call should be called before panic for a completed run of ehf_deactivate_priority().
The ehf_deactivate_priority() function restore pmr_el1 to original value(>0x80).
The SDEI dispatch flow was broken if SDEI_EVENT_COMPLETE was not be called.
This will bring about two issue:
1 Kdump will hang for firmware reporting fatal RAS event by SDEI;
(as explain above)
2 For NMI scene,TF-A enable a secure timer, the PPI 29 will trigger periodically.
Kernel register a callback for hard lockup. The below code will not be
called when panic in kernel callback:
TF-A, services/std_svc/sdei/sdei_intr_mgmt.c sdei_intr_handler():
/*
* We reach here when client completes the event.
*
* If the cause of dispatch originally interrupted the Secure world,
* resume Secure.
*
* No need to save the Non-secure context ahead of a world switch: the
* Non-secure context was fully saved before dispatch, and has been
* returned to its pre-dispatch state.
*/
if (sec_state == SECURE)
restore_and_resume_secure_context();
/*
* The event was dispatched after receiving SDEI interrupt. With
* the event handling completed, EOI the corresponding
* interrupt.
*/
if ((map->ev_num != SDEI_EVENT_0) && !is_map_bound(map)) {
ERROR("Invalid SDEI mapping: ev=%u\n", map->ev_num);
panic();
}
plat_ic_end_of_interrupt(intr_raw);
How to fix above issues?
I think the root cause is that kernel broken the SDEI dispatch flow, so kernel
should modify to fix these issues.
Thanks,
Ming
According to the Generic Names Recommendation in the Devicetree
Specification Release v0.3, and the DT Bindings for the Renesas Reduced
Pin Count Interface, the node name for a Renesas RPC-IF device should be
"spi". The node name matters, as the node is enabled by passing a DT
fragment from TF-A to subsequent software.
Fix this by renaming the device nodes from "rpc" to "spi".
Fixes: 12c75c8886a0ee69 ("feat(plat/rcar3): emit RPC status to DT fragment if RPC unlocked")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
---
Background:
On Renesas R-Car Gen3 platforms, the SPI Multi I/O Bus Controllers
(RPC-IF) provide access to HyperFlash or QSPI storage. On production
systems, they are typically locked by the TF-A firmware, unless TF-A is
built with RCAR_RPC_HYPERFLASH_LOCKED=0. When unlocked, TF-A
communicates this to subsequent software by passing a DT fragment that
sets the "status" property of the RPC-IF device node to "okay".
Unfortunately there are several issues preventing this from working all
the way to Linux:
1. TF-A (and U-Boot on the receiving side) uses a device node name
that does not conform to the DT specification nor the DT bindings
for RPC-IF,
2. While U-Boot receives the RPC-IF enablement from TF-A, it does not
propagate it to Linux yet,
3. The DTS files that are part of Linux do not have RPC HyperFlash
support yet.
This patch takes care of the first issue in TF-A.
The related patches for U-Boot are [1].
Patches to enable RPC-IF support in Linux are available at [2].
Thanks for your comments!
[1] "[PATCH u-boot 0/3] renesas: Fix RPC-IF enablement"
https://lore.kernel.org/r/cover.1648544792.git.geert+renesas@glider.be
[2] "[PATCH 0/5] arm64: dts: renesas: rcar-gen3: Enable HyperFlash support"
https://lore.kernel.org/r/cover.1648548339.git.geert+renesas@glider.be
---
plat/renesas/rcar/bl2_plat_setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plat/renesas/rcar/bl2_plat_setup.c b/plat/renesas/rcar/bl2_plat_setup.c
index bbfa16927d6c2384..f85db8d650c6b1a5 100644
--- a/plat/renesas/rcar/bl2_plat_setup.c
+++ b/plat/renesas/rcar/bl2_plat_setup.c
@@ -574,7 +574,7 @@ static void bl2_add_rpc_node(void)
goto err;
}
- node = ret = fdt_add_subnode(fdt, node, "rpc@ee200000");
+ node = ret = fdt_add_subnode(fdt, node, "spi@ee200000");
if (ret < 0) {
goto err;
}
--
2.25.1
All,
This is to inform you all that the TF-A Techforum for Thursday, 19th May 2022 is cancelled as we didn't receive any topic for this week.
The next meeting will now be Thursday, 2nd June 2022 at 16:00 - 17:00 BST.
Thanks,
Bipin Ravi
Hi,
There have been discussions about having long term support releases
for TF-A, e.g. the email thread [1] and a tech forum [2]. For partners
releasing TF-A in their production devices, LTS is very much needed.
From the previous discussions, it seems like there is an agreement
that LTS is a good idea but we need to build consensus on how to
support it. Any thoughts on this?
Thanks,
Okash
[1] https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…
[2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf
Hi,
I'm currently working on porting TFA to our upcoming SOC.
We plan to support Measured boot using external I2C TPM module.
I'm wondering about the implementation of that in BL1.
Do you think that I need to write the measurements directly to the I2C
module in BL1 ?
I'm asking because I would like to have the least source of problems
in BL1 which I can't upgrade.
I thought of storing the measurements in secure RAM and perhaps copy later.
Would love to hear your thoughts.
PS.
Actually I would love to have the option to choose to implement TPM
also in SW (fTPM using optee - as was done in the POC).
I think that if I store the measurement of BL2 in secure RAM I can
later change the specific TPM while upgrading only BL2/BL31...
Thanks,
Ramon
We are using an arm ARCH-64 (A55) and we need to do some floating point math in BL2. It seems this is not enabled. Is there a reason why I cannot do FP math (security issue?) and if I can, how do I enable it?
I am seeing this error when I use floats "-mgeneral-regs-only"
thanks
hi,
I has quality engineer from china.
I would to start study the Arm profile-A trustedfirmware and try to test it.
I has read trustedfirmware documetion ,
From the Processes & policies Chap about CI part. "https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… "
Find ATF has Coverity Scan and test image build.
but I would to know, trustedfirmware-a whether has unit test part in the code level quality check.
Brs
Tony