Hi Dan,
I am not sure if this is mentioned anywhere in any documents but I
think EHF handlers should be able to preempt all execution contexts at
lower ELs and lower ELs should never be able to mask such interrupts.
If the behavioral expectation is set the implementation can be fixed.
Thanks
Sandeep
On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A
<tf-a(a)lists.trustedfirmware.org> wrote:
>
> A correction...
>
> > -----Original Message-----
> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan Handley
> > via TF-A
> > Sent: 17 September 2020 15:14
> > > >
> > > > I want to handle something similar in OP-TEED along with EHF
> > > > depending on
> > > what is the expected behavior.
> > > >
> > Hmm, I thought OP-TEED was more like the TSP_NS_INTR_ASYNC_PREEMPT=0 case,
> > where NS interrupts are routed to S-EL1 while processing a yielding SMC in S-
> > EL1? Perhaps that's a better TSPD config for you to follow?
> >
> Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are routed to EL3 first, but the TSPD re-enables NS interrupts before handing over to the TSP to handle yielding calls, via a call to ehf_allow_ns_preemption.
>
Right, that is the case for yielding SMC handling where both NS
interrupts and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context.
But I would expect the same routing model even for 'Fast SMC' unlike
what is happening in TSPD.
> Dan.
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
A correction...
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan Handley
> via TF-A
> Sent: 17 September 2020 15:14
> > >
> > > I want to handle something similar in OP-TEED along with EHF
> > > depending on
> > what is the expected behavior.
> > >
> Hmm, I thought OP-TEED was more like the TSP_NS_INTR_ASYNC_PREEMPT=0 case,
> where NS interrupts are routed to S-EL1 while processing a yielding SMC in S-
> EL1? Perhaps that's a better TSPD config for you to follow?
>
Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are routed to EL3 first, but the TSPD re-enables NS interrupts before handing over to the TSP to handle yielding calls, via a call to ehf_allow_ns_preemption.
Dan.
Hi Sandeep
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep
> Tripathy via TF-A
> >
> > EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1
> ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs.
> >
> > Which means G0 interrupts (all EHF interrupts) expected to preempt any
> > execution context. And secure state cannot mask such interrupts
> >
> > eg: critical error interrupts. Sort of NMI behavior.
> >
> > However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a
> slightly different behavior. G0 interrupt cannot preempt a fast smc handler
> in SPD.
> >
> > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’
> is in effect. Intention is to avoid NS interrupt preempt secure execution
> (Fast SMC).
> > But I think that will also disable G0 interrupt as both NS interrupt and G0
> interrupt are on FIQ.
I haven't double checked but that sounds correct.
> > EHF already ensures this by GIC PMR adjustment. So disabling routing model
> seems unnecessary in this case.
> > This is my understanding from the code please confirm if this is correct.
> >
The TSPD's TSP_NS_INTR_ASYNC_PREEMPT functionality predates the EHF, which probably explains why NS interrupts are disabled in 2 ways in this config (i.e. when both TSP_NS_INTR_ASYNC_PREEMPT and EL3_EXCEPTION_HANDLING equal 1). I guess it's possible that the call to disable the routing model can be safely removed in this config but it would require some thorough code review and testing. I'm not sure if this config is tested much at all.
> >
> >
> > Do we think it is not aligned with G0 interrupt preemption rule. Or do we
> treat Fast SMC at S_EL1/EL2 as non interruptible.
> >
I think G0 interrupts should be handled in this case but I'm not sure if this is easy to fix in the TSPD.
> >
> >
> > I want to handle something similar in OP-TEED along with EHF depending on
> what is the expected behavior.
> >
Hmm, I thought OP-TEED was more like the TSP_NS_INTR_ASYNC_PREEMPT=0 case, where NS interrupts are routed to S-EL1 while processing a yielding SMC in S-EL1? Perhaps that's a better TSPD config for you to follow?
Regards
Dan.
Updated..
On Wed, Sep 16, 2020 at 10:51 AM Sandeep Tripathy via TF-A
<tf-a(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1 ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs.
>
> Which means G0 interrupts (all EHF interrupts) expected to preempt any execution context. And secure state cannot mask such interrupts
>
> eg: critical error interrupts. Sort of NMI behavior.
>
>
>
> However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a slightly different behavior. G0 interrupt cannot preempt a fast smc handler in SPD.
>
> Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC).
> But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ.
> EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case.
> This is my understanding from the code please confirm if this is correct.
>
>
>
> Do we think it is not aligned with G0 interrupt preemption rule. Or do we treat Fast SMC at S_EL1/EL2 as non interruptible.
>
>
>
> I want to handle something similar in OP-TEED along with EHF depending on what is the expected behavior.
>
>
>
> Thanks
>
> Sandeep
>
>
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1
ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs.
Which means G0 interrupts (all EHF interrupts) expected to preempt any
execution context. And secure state cannot mask such interrupts
eg: critical error interrupts. Sort of NMI behavior.
However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a
slightly different behavior. G0 interrupt cannot preempt a fast smc handler
in SPD.
Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’
is in effect. Intention is to avoid NS interrupt preempt secure execution
(Fast SMC).
But I think that will also disable G0 interrupt as both NS interrupt and G0
interrupt are on FIQ.
This is my understanding from the code please confirm if this is correct.
Do we think it is not aligned with G0 interrupt preemption rule. Or do we
treat Fast SMC at S_EL1/EL2 as non interruptible.
I want to handle something similar in OP-TEED along with EHF depending on
what is the expected behavior.
Thanks
Sandeep
Hello,
ATF currently uses non-portable printf format specifiers for fixed width types defined in stdint.h
In addition, ATF redefines types defined in gcc for stdint.h with its own custom types causing additional issues.
This causes compilation issues when porting code to/from ATF.
AND, generates coverity parse errors as int64_t and uint64_t are incorrectly defined in ATF vs. gcc for aarch64.
The printf format specifiers in inttypes.h are to be used for the proper format specifiers.
And, uint64_t/int64_t should be defined the same as in gcc.
I tried fixing up all the instances of int64 printf format specifiers by introducing inttypes.h and redefined the stdint types correctly here:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5437
We have checked the change into our local tree so that everything compiles and runs in our system. Please accept change upstream.
Regards,
Scott
On Thu, 11 Jun 2020 at 23:42, Varun Wadekar via TF-A <
tf-a(a)lists.trustedfirmware.org> wrote:
> Hello Matteo,
>
> Apologies for still using an outdated term. I have trained myself to get
> used to "TF-A" - looks like I am still not there.
>
> >> The idea has also been just raised to the Trusted Firmware project
> Board for initial consideration and we will be all very keen to understand
> how much interest there is from the wider TF-A community of adopters and
> external (non-Arm) maintainers
>
> That is good to hear. For the exact scope, I think we can assume the usual
> expectations from any LTS software stack - stability, performance,
> security, bug fixes along with maintenance support. We are open to
> discussing the cadence and any other operational commitments.
>
> @Francois, from the description of Trusted Substrate looks like you also
> expect the sub-projects to provide LTS versions for the project as a whole
> to succeed (?)
>
> Yes. I assume relevant tf.org projects decide to branch LTSes so that we
can extend the scope to selected OP-TEE TAs for the Trusted Substrate LTS
and may be extend duration of support for the tf.org LTSes. (just to make
sure: this is just early open thinking to understand what it would mean to
build such a service on the Linaro side should there be tf.org LTSes).
-Varun
>
>
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Matteo
> Carlini via TF-A
> Sent: Thursday, June 11, 2020 4:25 AM
> To: tf-a(a)lists.trustedfirmware.org
> Subject: Re: [TF-A] ATF LTS version
>
> External email: Use caution opening links or attachments
>
>
> Hi Francois,
>
> > I'd be happy to know more about what you see as TFA LTS: exact scope,
> number of versions, duration, operational commitments (zero-day...).
> > Do you have other firmware LTS needs?
>
> Agree. That’s precisely what I was hinting to Varun, when mentioning
> concrete requirements for the LTS scheme.
>
> > Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps
> such as firmwareTPM, U-Boot }.
> > Trusted Substrate effort is led by Linaro members and is going to be set
> up as a more open project.
>
> First time I heard about it. Good to know, but I guess we'll need to
> discuss the intersection and collaboration with the Trusted Firmware
> project at some point.
> Having a LTS versioning scheme for the Trusted Firmware hosted projects
> should be theoretically either in the scope of the Project itself or, if
> the Board agrees, appointed to some other project/entity.
>
> > Our end goal is to enable unified, transactional, robust (anti-bricking,
> anti rollback) UEFI OTA on both U-Boot and EDK2.
>
> Fair, but IMHO this has little to do with Arm Secure world software LTS
> releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside,
> this is not in scope of what Varun is raising.
>
> Thanks
> Matteo
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Hi All,
The next TF-A Tech Forum is scheduled for Thu 10th September 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know.
Agenda:
* Proposal for a LTS (Long Term Support) Release Option for TF-A
* Presented by Varun Wadekar
* Long-term support is a lifecycle management policy in which a stable release is maintained for a period of time
* Optional TF-A Mailing List Topic Discussions
If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled.
Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list.
Thanks
Joanna
Hi again,
After further check, it looks gcc 9.2 already supports the appropriate option.
Maybe you missed ARM_ARCH_MINOR on the build command line depending on whether you need PAuth (Armv8.3) and/or BTI (Armv8.5).
BRANCH_PROTECTION=2 or 3 => need ARM_ARCH_MINOR=3 (at least)
BRANCH_PROTECTION=1 or 4 => need ARM_ARCH_MINOR=5
Regards,
Olivier.
________________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 03 September 2020 09:47
To: Kalyani Chidambaram Vaidyanathan; tf-a(a)lists.trustedfirmware.org; Varun Wadekar
Subject: Re: [TF-A] GCC compiler option to support "xpaci" instruction
Hi Kalyani,
According to https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/build-op…
you need a compiler supporting the -mbranch-protection option.
This seems to be the case from gcc 9.3 onwards: https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/AArch64-Options.html#AArch64-O…
Notice a GCC10.2 cross-compiler release is planned by end of this year according to this page:
https://community.arm.com/developer/tools-software/tools/b/tools-software-i…
Regards,
Olivier.
________________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 03 September 2020 04:08
To: Kalyani Chidambaram Vaidyanathan; tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] GCC compiler option to support "xpaci" instruction
<Dummy response to get the email through to the mailing list>
From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>
Sent: Wednesday, September 2, 2020 3:43 PM
To: tf-a(a)lists.trustedfirmware.org
Cc: Varun Wadekar <vwadekar(a)nvidia.com>
Subject: GCC compiler option to support "xpaci" instruction
Hi,
We are using gcc-arm-9.2 toolchain and see that this is not supporting the “xpaci” instruction.
Is there any compiler flag that has to be included to support this?
Reference code that uses “xpaci” when PAUTH is enabled -
https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/aarch…
Thanks,
Kalyani
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Kalyani,
According to https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/build-op…
you need a compiler supporting the -mbranch-protection option.
This seems to be the case from gcc 9.3 onwards: https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/AArch64-Options.html#AArch64-O…
Notice a GCC10.2 cross-compiler release is planned by end of this year according to this page:
https://community.arm.com/developer/tools-software/tools/b/tools-software-i…
Regards,
Olivier.
________________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 03 September 2020 04:08
To: Kalyani Chidambaram Vaidyanathan; tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] GCC compiler option to support "xpaci" instruction
<Dummy response to get the email through to the mailing list>
From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>
Sent: Wednesday, September 2, 2020 3:43 PM
To: tf-a(a)lists.trustedfirmware.org
Cc: Varun Wadekar <vwadekar(a)nvidia.com>
Subject: GCC compiler option to support "xpaci" instruction
Hi,
We are using gcc-arm-9.2 toolchain and see that this is not supporting the “xpaci” instruction.
Is there any compiler flag that has to be included to support this?
Reference code that uses “xpaci” when PAUTH is enabled -
https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/aarch…
Thanks,
Kalyani
<Dummy response to get the email through to the mailing list>
From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>
Sent: Wednesday, September 2, 2020 3:43 PM
To: tf-a(a)lists.trustedfirmware.org
Cc: Varun Wadekar <vwadekar(a)nvidia.com>
Subject: GCC compiler option to support "xpaci" instruction
Hi,
We are using gcc-arm-9.2 toolchain and see that this is not supporting the "xpaci" instruction.
Is there any compiler flag that has to be included to support this?
Reference code that uses "xpaci" when PAUTH is enabled -
https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/aarch…
Thanks,
Kalyani
Hi @Olivier<mailto:Olivier.Deprez@arm.com>,
We have been trying to use Cactus as SPMC on Tegra194 (pre 8.4) platforms and have faced the following issues.
1. Cactus_main.c - During cold boot, Cactus checks if the ffa-id for the instance of Cactus == SPM_VM_ID_FIRST. It issues FFA_ID_GET SMC to TF-A which returns the spmc_id in return. But on pre-8.4 platforms the value does not match SPM_VM_ID_FIRST and so the system assumes that the device is running on a post-8.4 CPU. The problem is that TF-A returns the spmc_id for this SMC, which seems incorrect. I don't understand why Cactus needs to know its own VM_ID on pre-8.4 CPUs. Can we assume that only one SPMC can run on pre-8.4?
2. Cactus_ffa_tests.c - The ` ffa_partition_info_get_test` incorrectly queries the partition info for secondary and tertiary VMs on pre-8.4 CPUs.
3. In general the boot tests that execute within Cactus seem incorrect to me. Some tests expect the presence of a non-secure world payload, which is not available at this point in the boot. This leads to numerous crashes and asserts during boot.
4. Cactus incorrectly uses a hard-coded address 0x7300000 as the RX/TX memory base. It should be using a platform defined value instead. We do not support this memory address on Tegra194.
5. The debug UART in Cactus needs rework too. Right now, it only supports PL011 as the UART driver.
6. TF-A SPMD forwards some SMCs to the non-secure world without checking if a non-secure world payload exists. This causes crashes during cold boot.
Please let me know if you have commits for any or all of these issues. We have some WIP commits that we can push to gerrit for review, if required.
Thoughts?
-Varun
Hello arm expects,
While reading the tf-a spec about the section "3.5.1 Register state".
It described that "The MMU must be disabled for a partition that does
not run in S-EL0".
Does this mean that the S-EL1 SP need to create their own page table
and enable the MMU itself. I wonder in this way, it is not very friendly
to a SP developer.
Since the SP can be a verify simple binary, maybe a single driver which
can benefited from the isolation from other partitions.
So in the pointer of developing a single driver. I think it do not need
to care about the MMU configuration. It will be more friendly to be as
easy as developing a user-land binary. The SPMC(SEL2) can do this
configure for the SEL1's page-tables and enable MMU for SEL1 before jump
into the SP.
So I want to discuss here to understand the meaning behind it.
Cheers,
Feng
Hi Dan,
On Thu, Aug 27, 2020 at 8:31 PM Dan Handley via TF-A
<tf-a(a)lists.trustedfirmware.org> wrote:
>
> Hi Sandeep
>
>
>
> Arm development platforms that have an SBSA secure watchdog like N1SDP do not register an interrupt handler for the WS0 signal. They simply wait for the WS1 signal, which is fed to a higher agent (in this case the System Control Processor), which resets the platform.
> There is no explicit watchdog interrupt handling functionality in TF-A.
>
what happens to non secure sbsa WS1 ?
That is the case for Secure sbsa WS1.
NS WS0 ----> EL1 X (optional) but linux already implements it .
NS WS1 ----> EL3 X TF-A Do not handle it. Hence the patch.
Not handling it altogether is not an option I guess.
S WS0 -------> EL3 X (optional) . Platform might want to log
this condition.
S WS1 ----------------------------------------> handled by a higher agent.
>
>
> If your platform does not have a higher agent that handles WS1 then I guess you could add a handler in TF-A as you suggest in your code snippet, though I'm not sure if the maintainers would want this in generic SBSA code. Also, I don't see why you need both callback(s) and the explicit call to psci_systrem_reset2(), when presumably the callback(s) would do the latter.
>
Platform callback can optionally do more things like some logging.
Ultimately 'system_reset2' seems to be the thing everyone would like
to do as part of action. Then to reduce duplicate code we can have at
one place.
>
>
> > Q1- What happens if core is stuck and interrupts are not taken.
>
> It's rare for EL3 interrupts not to be taken when the core is stuck, unless an EL3 exception handler itself is stuck, in which case I'm not sure there's much you can do. That's why it's good to have a higher agent.
>
The rare lockup of core where it's not able to respond (not the
software ones) requires some other agent to detect and reset/recover
the system. Linux watchdog (ns sbsa WS1) will go unnoticed in such
cases.
ie. even if the watchdog hardware detected the lockup and indicated by
WS0 then WS1 .. both were not acted upon. If it were the secure
watchdog then no issues.
>
>
> > Or it has to be registered as a RAS priority exception.
>
> I don't think that would help, unless the system was flooded with higher priority exceptions that prevented the watchdog handler from running.
>
>
>
> Regards
>
>
> Dan.
>
>
>
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep Tripathy via TF-A
> Sent: 27 August 2020 12:14
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] [query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3
>
>
>
> Hi,
>
> Based on sbsa spec for level-3 firmware specification watchdog signals NS WS1 and S WS0 to be handled at EL3 firmware.
>
> I have some query on how TF-A plans to implement this.
>
>
>
> Ref: Excerpt DEN0029D_SBSA_6.0 https://developer.arm.com/documentation/den0029/d/?lang=en
>
> 3.2.3 Watchdogs The required behavior of watchdog signal 1 of the Non-secure watchdog is modified in level 3– firmware and is required to be routed as an SPI to the GIC. It is expected that this SPI be configured as an EL3 interrupt, directly targeting a single PE. A system compatible with level 3- firmware must implement a second watchdog, and is referred to as the Secure watchdog. It must have both its register frames mapped in the Secure memory address space and must not be aliased to the Non-secure address space. Watchdog Signal 0 of the Secure watchdog must be routed as an SPI to the GIC and it is expected this will be configured as an EL3 interrupt, directly targeting a single PE.
>
>
>
> Q1- What happens if core is stuck and interrupts are not taken. Non-secure watchdog will expire and ultimately results in a WS1 which is also not taken as the core is not responding.
>
> If WS1 were to another subsystem (eg: SCP) then it would take action.
>
> In current scheme is it the secure sbsa wdg expected to detect such hang ?
>
>
>
> Q2- How to handle sbsa watchdog interrupt at EL3. Please suggest if I should make a patch in following approach to start with. Or it has to be registered as a RAS priority exception.
>
>
>
> diff --git a/drivers/arm/sbsa/sbsa.c b/drivers/arm/sbsa/sbsa.c
>
> index 79c6f26..9683ef8 100644
>
> --- a/drivers/arm/sbsa/sbsa.c
>
> +++ b/drivers/arm/sbsa/sbsa.c
>
> @@ -40,3 +40,26 @@
>
> +
>
> +#define weak plat_sbsa_nt_wdog_ws1_handle
>
> +#define weak plat_sbsa_t_wdog_ws0_handle
>
> +void sbsa_wdog_handler(int id)
>
> +{
>
> + if (id == SBSA_NT_WDG_WS1_INT) {
>
> + /* PUBLISH_EVENT */
>
> + plat_sbsa_nt_wdog_ws1_handle();
>
> + } else if (id == SBSA_T_WDG_WS0_INT) {
>
> + /* PUBLISH_EVENT */
>
> + plat_sbsa_t_wdog_ws0_handle();
>
> + }
>
> + /* EOI and reset , log what else */
>
> + psci_systrem_reset2();
>
> +}
>
> +
>
> +void sbsa_wdog_hander_init(void)
>
> +{
>
> +#if EXCEPTION_HANDLING_FRAMEWORK
>
> + ehf_register_priority_handler(SBSA_WDG_PRI, sbsa_wdog_handler);
>
> +#endif
>
> +}
>
>
>
> Thanks
>
> Sandeep
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Thanks
Sandeep
Hi Sandeep
Arm development platforms that have an SBSA secure watchdog like N1SDP do not register an interrupt handler for the WS0 signal. They simply wait for the WS1 signal, which is fed to a higher agent (in this case the System Control Processor), which resets the platform. There is no explicit watchdog interrupt handling functionality in TF-A.
If your platform does not have a higher agent that handles WS1 then I guess you could add a handler in TF-A as you suggest in your code snippet, though I'm not sure if the maintainers would want this in generic SBSA code. Also, I don't see why you need both callback(s) and the explicit call to psci_systrem_reset2(), when presumably the callback(s) would do the latter.
> Q1- What happens if core is stuck and interrupts are not taken.
It's rare for EL3 interrupts not to be taken when the core is stuck, unless an EL3 exception handler itself is stuck, in which case I'm not sure there's much you can do. That's why it's good to have a higher agent.
> Or it has to be registered as a RAS priority exception.
I don't think that would help, unless the system was flooded with higher priority exceptions that prevented the watchdog handler from running.
Regards
Dan.
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep Tripathy via TF-A
Sent: 27 August 2020 12:14
To: tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] [query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3
Hi,
Based on sbsa spec for level-3 firmware specification watchdog signals NS WS1 and S WS0 to be handled at EL3 firmware.
I have some query on how TF-A plans to implement this.
Ref: Excerpt DEN0029D_SBSA_6.0 https://developer.arm.com/documentation/den0029/d/?lang=en
3.2.3 Watchdogs The required behavior of watchdog signal 1 of the Non-secure watchdog is modified in level 3– firmware and is required to be routed as an SPI to the GIC. It is expected that this SPI be configured as an EL3 interrupt, directly targeting a single PE. A system compatible with level 3- firmware must implement a second watchdog, and is referred to as the Secure watchdog. It must have both its register frames mapped in the Secure memory address space and must not be aliased to the Non-secure address space. Watchdog Signal 0 of the Secure watchdog must be routed as an SPI to the GIC and it is expected this will be configured as an EL3 interrupt, directly targeting a single PE.
Q1- What happens if core is stuck and interrupts are not taken. Non-secure watchdog will expire and ultimately results in a WS1 which is also not taken as the core is not responding.
If WS1 were to another subsystem (eg: SCP) then it would take action.
In current scheme is it the secure sbsa wdg expected to detect such hang ?
Q2- How to handle sbsa watchdog interrupt at EL3. Please suggest if I should make a patch in following approach to start with. Or it has to be registered as a RAS priority exception.
diff --git a/drivers/arm/sbsa/sbsa.c b/drivers/arm/sbsa/sbsa.c
index 79c6f26..9683ef8 100644
--- a/drivers/arm/sbsa/sbsa.c
+++ b/drivers/arm/sbsa/sbsa.c
@@ -40,3 +40,26 @@
+
+#define weak plat_sbsa_nt_wdog_ws1_handle
+#define weak plat_sbsa_t_wdog_ws0_handle
+void sbsa_wdog_handler(int id)
+{
+ if (id == SBSA_NT_WDG_WS1_INT) {
+ /* PUBLISH_EVENT */
+ plat_sbsa_nt_wdog_ws1_handle();
+ } else if (id == SBSA_T_WDG_WS0_INT) {
+ /* PUBLISH_EVENT */
+ plat_sbsa_t_wdog_ws0_handle();
+ }
+ /* EOI and reset , log what else */
+ psci_systrem_reset2();
+}
+
+void sbsa_wdog_hander_init(void)
+{
+#if EXCEPTION_HANDLING_FRAMEWORK
+ ehf_register_priority_handler(SBSA_WDG_PRI, sbsa_wdog_handler);
+#endif
+}
Thanks
Sandeep
Hi,
Based on sbsa spec for level-3 firmware specification watchdog signals
NS WS1 and S WS0 to be handled at EL3 firmware.
I have some query on how TF-A plans to implement this.
Ref: Excerpt DEN0029D_SBSA_6.0
https://developer.arm.com/documentation/den0029/d/?lang=en
3.2.3 Watchdogs The required behavior of watchdog signal 1 of the
Non-secure watchdog is modified in level 3– firmware and is required to be
routed as an SPI to the GIC. It is expected that this SPI be configured as
an EL3 interrupt, directly targeting a single PE. A system compatible with
level 3- firmware must implement a second watchdog, and is referred to as
the Secure watchdog. It must have both its register frames mapped in the
Secure memory address space and must not be aliased to the Non-secure
address space. Watchdog Signal 0 of the Secure watchdog must be routed as
an SPI to the GIC and it is expected this will be configured as an EL3
interrupt, directly targeting a single PE.
Q1- What happens if core is stuck and interrupts are not taken. Non-secure
watchdog will expire and ultimately results in a WS1 which is also not
taken as the core is not responding.
If WS1 were to another subsystem (eg: SCP) then it would take action.
In current scheme is it the secure sbsa wdg expected to detect such
hang ?
Q2- How to handle sbsa watchdog interrupt at EL3. Please suggest if I
should make a patch in following approach to start with. Or it has to be
registered as a RAS priority exception.
diff --git a/drivers/arm/sbsa/sbsa.c b/drivers/arm/sbsa/sbsa.c
index 79c6f26..9683ef8 100644
--- a/drivers/arm/sbsa/sbsa.c
+++ b/drivers/arm/sbsa/sbsa.c
@@ -40,3 +40,26 @@
+
+#define weak plat_sbsa_nt_wdog_ws1_handle
+#define weak plat_sbsa_t_wdog_ws0_handle
+void sbsa_wdog_handler(int id)
+{
+ if (id == SBSA_NT_WDG_WS1_INT) {
+ /* PUBLISH_EVENT */
+ plat_sbsa_nt_wdog_ws1_handle();
+ } else if (id == SBSA_T_WDG_WS0_INT) {
+ /* PUBLISH_EVENT */
+ plat_sbsa_t_wdog_ws0_handle();
+ }
+ /* EOI and reset , log what else */
+ psci_systrem_reset2();
+}
+
+void sbsa_wdog_hander_init(void)
+{
+#if EXCEPTION_HANDLING_FRAMEWORK
+ ehf_register_priority_handler(SBSA_WDG_PRI, sbsa_wdog_handler);
+#endif
+}
Thanks
Sandeep
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)
** CID 361485: Integer handling issues (SIGN_EXTENSION)
/plat/qti/common/src/spmi_arb.c: 54 in wait_for_done()
________________________________________________________________________________________________________
*** CID 361485: Integer handling issues (SIGN_EXTENSION)
/plat/qti/common/src/spmi_arb.c: 54 in wait_for_done()
48
49 static int wait_for_done(uint16_t apid)
50 {
51 unsigned int timeout = 100;
52
53 while (timeout-- != 0U) {
>>> CID 361485: Integer handling issues (SIGN_EXTENSION)
>>> Suspicious implicit sign extension: "apid" with type "uint16_t" (16 bits, unsigned) is promoted in "207618056 + 65536 * apid" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "207618056 + 65536 * apid" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
54 uint32_t status = mmio_read_32(REG_ARB_STATUS(apid));
55 if ((status & ARB_STATUS_DONE) != 0U) {
56 if ((status & ARB_STATUS_FAILURE) != 0U ||
57 (status & ARB_STATUS_DENIED) != 0U ||
58 (status & ARB_STATUS_DROPPED) != 0U) {
59 return status & 0xff;
** CID 361484: Integer handling issues (SIGN_EXTENSION)
/plat/qti/common/src/spmi_arb.c: 72 in arb_command()
________________________________________________________________________________________________________
*** CID 361484: Integer handling issues (SIGN_EXTENSION)
/plat/qti/common/src/spmi_arb.c: 72 in arb_command()
66 return ARB_FAKE_STATUS_TIMEOUT;
67 }
68
69 static void arb_command(uint16_t apid, uint8_t opcode, uint32_t addr,
70 uint8_t bytes)
71 {
>>> CID 361484: Integer handling issues (SIGN_EXTENSION)
>>> Suspicious implicit sign extension: "apid" with type "uint16_t" (16 bits, unsigned) is promoted in "207618048 + 65536 * apid" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "207618048 + 65536 * apid" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
72 mmio_write_32(REG_ARB_CMD(apid), (uint32_t)opcode << 27 |
73 (addr & 0xff) << 4 | (bytes - 1));
74 }
75
76 int spmi_arb_read8(uint32_t addr)
77 {
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
Things should be back to normal.
Joanna
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org>
Reply to: Joanna Farley <Joanna.Farley(a)arm.com>
Date: Wednesday, 26 August 2020 at 12:51
To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] TF-A Gerrit access permissions currently broken.
Just to inform project contributors that people may find their gerrit access rights may be broken at this time.
I have raised a support request with the trustedfirmware.org support team.
Joanna
Just to inform project contributors that people may find their gerrit access rights may be broken at this time.
I have raised a support request with the trustedfirmware.org support team.
Joanna
Hi All,
The next TF-A Tech Forum is scheduled for Thu 27th August 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know.
Agenda:
* TF-A Errata Process – Presented by Bipin Ravi
* Bug Review Committee (BRC) & Categorization of Errata
* Software Developers Errata Notice (SDEN) & Product Errata Notice (PEN)
* What TF-A Implements
* How TF-A Implements
* Testing
If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled.
Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list.
Thanks
Joanna
<Cc alias>
-----Original Message-----
From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com>
Sent: Tuesday, August 25, 2020 8:59 AM
To: Varun Wadekar <vwadekar(a)nvidia.com>; Soby Mathew <Soby.Mathew(a)arm.com>
Subject: RE: [TF-A] [RFC] Api to power down all cores
Thanks,
I will use callback as param to get rid of the 'plat*'. 'void psci_stop_other_cores(void (*stop_func)(uregister_t mpidr))'
Platform can call like .. psci_stop_other_cores(ipi_send_stop); I will
update the patch tomorrow.
This api is not invoked by psci generic functions. So I think that should suffice your concern. Anyways I will take care any other suggestions.
IPI implementation is under flag 'IPI_SUPPORT'.
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5323/
Thanks
Sandeep
> -----Original Message-----
> From: Varun Wadekar [mailto:vwadekar@nvidia.com]
> Sent: Tuesday, August 25, 2020 9:11 AM
> To: Soby Mathew; Sandeep Tripathy
> Subject: RE: [TF-A] [RFC] Api to power down all cores
>
> Hi,
>
> In addition to the suggestions already posted, we should provide a
> build flag or dynamic knob to allow platforms to disable this feature.
>
> -Varun
>
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby
> Mathew via TF-A
> Sent: Friday, August 21, 2020 3:57 AM
> To: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com>
> Cc: tf-a(a)lists.trustedfirmware.org
> Subject: Re: [TF-A] [RFC] Api to power down all cores
>
> External email: Use caution opening links or attachments
>
>
> Hi Sandeep,
> Thanks for the clarification. I too think this has general utility and
> since you need access to internal PSCI data to perform the
> functionality , exporting a utility function from PSCI for platforms
> to invoke seems the right thing to do.
> The small concern I have is using the `plat_*` namespace as this is a
> utility function invoked by the platform and another porting layer
> beneath it seems out of place.
>
> I would suggest to add a parameter to stop_other_cores(), this could
> be either the IPI number or a callback function to trigger the IPI.
> This allows to provide the platform specific details without `plat_*`
> API.
>
> Best Regards
> Soby Mathew
>
> > -----Original Message-----
> > From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com>
> > Sent: 21 August 2020 07:17
> > To: Soby Mathew <Soby.Mathew(a)arm.com>
> > Cc: tf-a(a)lists.trustedfirmware.org
> > Subject: RE: [TF-A] [RFC] Api to power down all cores
> >
> > Hi Soby,
> > I realize using term 'PSCI API' in rfc tag is misleading like Achin
> > mentioned in gerrit.
> >
> > Here I wanted to have a generic API to 'stop_other_cores' in
> > secure world.
> > The usage is platform firmware specific.
> > Implementation of 'stop_other_cores' depends on a generic 'IPI'
> > support
> (1).
> > It leverages the existing EHF. So I feel it is not adding and
> > complexity or overhead in normal execution path.
> >
> > 'stop_other_cores' API implementation depends on some psci private
> > functions to traverse the pd nodes and extract MPIDRs for target pe
> > list. That was the reason to put the function within psci lib. So
> > there are
> two things.
> > 1- Does this idea of 'stop_other_core' api qualify to be generic
> > 2- Does a generic IPI layer make sense
> >
> > Thanks
> > Sandeep
> > > -----Original Message-----
> > > From: Soby Mathew [mailto:Soby.Mathew@arm.com]
> > > Sent: Thursday, August 20, 2020 8:54 PM
> > > To: Sandeep Tripathy
> > > Cc: tf-a(a)lists.trustedfirmware.org
> > > Subject: RE: [TF-A] [RFC] psci: api to power down all cores
> > >
> > > Hi Sandeep,
> > > Just to understand better, if there is a secure side
> > > panic/watchdog interrupt, then the secure side is already able to
> > > do such an intervention without the availability of a PSCI API to the NS side.
> > >
> > > In case the NS world has crashed, then PSCI_SYSTEM_RESET and
> > > PSCI_SYSTEM_OFF APIs can be invoked which then does the
> > > appropriate actions. From my reading, the PSCI specification
> > > doesn't prevent firmware implementation of the reset and off API's
> > > from doing the kind of implementation as per your proposal.
> >
> > I intend to do 'stop_other_cores' in platform extension of
> > 'plat_system_resetx()', secure side watchdog expiry/
> > plat_panic_handler().
> >
> > >
> > > Best Regards
> > > Soby Mathew
> > >
> > > > -----Original Message-----
> > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of
> > > Sandeep
> > > > Tripathy via TF-A
> > > > Sent: 19 August 2020 16:42
> > > > To: tf-a(a)lists.trustedfirmware.org
> > > > Subject: [TF-A] [RFC] psci: api to power down all cores
> > > >
> > > > Hi,
> > > > I am proposing to have a generic api in psci lib which can be
> > > > used to
> > > force
> > > > power down all other cores from any initiating core analogous to
> > > > 'smp_cpu_stop' in linux. It is immune to interrupt lock by
> > > > EL1/EL2 software.
> > > >
> > > > Platforms may use this api in case of secure side panic, secure
> > > > watchdog interrupt handling or if required in certain types of
> > > > warm resets. The usage
> > > is
> > > > platform dependent.
> > > >
> > > > This depends on a generic implementation of secure IPI (1) which
> > > > uses EHF
> > > to
> > > > handle IPI at platform defined priority. We probably require
> > > > more types of secure IPIs.
> > > >
> > > > Please review the series
> > > > Ref:
> > > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5
> > > > 32
> > > > 4
> > > >
> > > > diff --git a/lib/psci/psci_system_off.c
> > > > b/lib/psci/psci_system_off.c index
> > > > 141d69e..011aaa6 100644
> > > > --- a/lib/psci/psci_system_off.c
> > > > +++ b/lib/psci/psci_system_off.c
> > > > @@ -10,10 +10,44 @@
> > > > #include <arch_helpers.h>
> > > > #include <common/debug.h>
> > > > #include <drivers/console.h>
> > > > +#include <drivers/delay_timer.h>
> > > > #include <plat/common/platform.h>
> > > >
> > > > #include "psci_private.h"
> > > >
> > > > +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS #define
> > > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif
> > > > +
> > > > +#if IMAGE_BL31
> > > > +void psci_stop_other_cores(void) { #define
> > > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif
> > > > +
> > > > +#if IMAGE_BL31
> > > > +void psci_stop_other_cores(void) {
> > > > + int idx, this_cpu_idx, cnt;
> > > > +
> > > > + this_cpu_idx = plat_my_core_pos();
> > > > +
> > > > + /* Raise G0 IPI cpustop to all cores but self */
> > > > + for (idx = 0; idx < psci_plat_core_count; idx++) {
> > > > + if ((idx != this_cpu_idx) &&
> > > > + (psci_get_aff_info_state_by_idx(idx) ==
> > > > AFF_STATE_ON)) {
> > > > +
> > > > plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr);
> > > > + }
> > > > + }
> > > > +
> > > > + /* Wait for others cores to shutdown */
> > > > + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS;
> > > > + cnt++)
> > > {
> > > > + if (psci_is_last_on_cpu())
> > > > + break;
> > > > + mdelay(1);
> > > > + }
> > > > +
> > > > + if (!psci_is_last_on_cpu()) {
> > > > + WARN("Failed to stop all cores!\n");
> > > > + psci_print_power_domain_map();
> > > > + }
> > > > +}
> > > > +#endif
> > > > +
> > > >
> > > > (1)
> > > > RFC: ipi: add ipi feature
> > > > Ref:
> > > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-
> > > a/+/5323/1
> > > >
> > > > Thanks
> > > > Sandeep
> > > > --
> > > > TF-A mailing list
> > > > TF-A(a)lists.trustedfirmware.org
> > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hello team,
Requesting reviews for the latest patches [1] form our internal repos for Tegra platforms. I have updated the verification steps for each patch in the comments to help answer some questions.
Thanks in advance.
-Varun
[1] https://review.trustedfirmware.org/q/topic:%22tegra-downstream-08252020%22+…