- OP-TEE - lists.trustedfirmware.org

[PATCH] tee: optee: add invoke_fn tracepoints

by Jisheng Zhang

Add tracepoints to retrieve information about the invoke_fn. This would help to measure how many invoke_fn are triggered and how long it takes to complete one invoke_fn call. Signed-off-by: Jisheng Zhang <Jisheng.Zhang(a)synaptics.com> --- Since v1: - add BUILD_BUG_ON() macro usage to make sure that the size of what is being copied, is not smaller than the amount being copied. Thank Steve. - move optee_trace.h to keep include headers sorted drivers/tee/optee/call.c | 4 ++ drivers/tee/optee/optee_trace.h | 67 +++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 drivers/tee/optee/optee_trace.h diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 780d7c4fd756..0da6fe50f1af 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -14,6 +14,8 @@ #include <linux/uaccess.h> #include "optee_private.h" #include "optee_smc.h" +#define CREATE_TRACE_POINTS +#include "optee_trace.h" struct optee_call_waiter { struct list_head list_node; @@ -138,9 +140,11 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) while (true) { struct arm_smccc_res res; + trace_optee_invoke_fn_begin(&param); optee->invoke_fn(param.a0, param.a1, param.a2, param.a3, param.a4, param.a5, param.a6, param.a7, &res); + trace_optee_invoke_fn_end(&param, &res); if (res.a0 == OPTEE_SMC_RETURN_ETHREAD_LIMIT) { /* diff --git a/drivers/tee/optee/optee_trace.h b/drivers/tee/optee/optee_trace.h new file mode 100644 index 000000000000..7c954eefa4bf --- /dev/null +++ b/drivers/tee/optee/optee_trace.h @@ -0,0 +1,67 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * optee trace points + * + * Copyright (C) 2021 Synaptics Incorporated + * Author: Jisheng Zhang <jszhang(a)kernel.org> + */ + +#undef TRACE_SYSTEM +#define TRACE_SYSTEM optee + +#if !defined(_TRACE_OPTEE_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_OPTEE_H + +#include <linux/arm-smccc.h> +#include <linux/tracepoint.h> +#include "optee_private.h" + +TRACE_EVENT(optee_invoke_fn_begin, + TP_PROTO(struct optee_rpc_param *param), + TP_ARGS(param), + + TP_STRUCT__entry( + __field(void *, param) + __array(u32, args, 8) + ), + + TP_fast_assign( + __entry->param = param; + BUILD_BUG_ON(sizeof(*param) < sizeof(__entry->args)); + memcpy(__entry->args, param, sizeof(__entry->args)); + ), + + TP_printk("param=%p (%x, %x, %x, %x, %x, %x, %x, %x)", __entry->param, + __entry->args[0], __entry->args[1], __entry->args[2], + __entry->args[3], __entry->args[4], __entry->args[5], + __entry->args[6], __entry->args[7]) +); + +TRACE_EVENT(optee_invoke_fn_end, + TP_PROTO(struct optee_rpc_param *param, struct arm_smccc_res *res), + TP_ARGS(param, res), + + TP_STRUCT__entry( + __field(void *, param) + __array(unsigned long, rets, 4) + ), + + TP_fast_assign( + __entry->param = param; + BUILD_BUG_ON(sizeof(*res) < sizeof(__entry->rets)); + memcpy(__entry->rets, res, sizeof(__entry->rets)); + ), + + TP_printk("param=%p ret (%lx, %lx, %lx, %lx)", __entry->param, + __entry->rets[0], __entry->rets[1], __entry->rets[2], + __entry->rets[3]) +); +#endif /* _TRACE_OPTEE_H */ + +#undef TRACE_INCLUDE_PATH +#define TRACE_INCLUDE_PATH . +#undef TRACE_INCLUDE_FILE +#define TRACE_INCLUDE_FILE optee_trace + +/* This part must be outside protection */ +#include <trace/define_trace.h> -- 2.30.0

4 years, 2 months

4
11
0 0

Re: [PATCH] tee: optee: fix build error caused by recent optee tracepoints feature

by Guenter Roeck

On Thu, Mar 25, 2021 at 12:06:01PM +0800, Jisheng Zhang wrote: > If build kernel without "O=dir", below error will be seen: > > In file included from drivers/tee/optee/optee_trace.h:67, > from drivers/tee/optee/call.c:18: > ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such file or directory > 95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) > | ^ > compilation terminated. > > Fix it by adding below line to Makefile: > CFLAGS_call.o := -I$(src) > > Tested with and without "O=dir", both can build successfully. > > Reported-by: Guenter Roeck <linux(a)roeck-us.net> > Suggested-by: Steven Rostedt <rostedt(a)goodmis.org> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang(a)synaptics.com> Tested-by: Guenter Roeck <linux(a)roeck-us.net> > --- > drivers/tee/optee/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile > index 56263ae3b1d7..3aa33ea9e6a6 100644 > --- a/drivers/tee/optee/Makefile > +++ b/drivers/tee/optee/Makefile > @@ -6,3 +6,6 @@ optee-objs += rpc.o > optee-objs += supp.o > optee-objs += shm_pool.o > optee-objs += device.o > + > +# for tracing framework to find optee_trace.h > +CFLAGS_call.o := -I$(src) > -- > 2.31.0 >

4 years, 2 months

1
0
0 0

[GIT PULL] OP-TEE tracepoints for v5.13

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch adding tracepoints around calls to OP-TEE in secure world. Thanks, Jens The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-tracepoints-for-v5.13 for you to fetch changes up to 0101947dbcc3204f08fb5b69a21dbd4b1535cad6: tee: optee: add invoke_fn tracepoints (2021-03-15 12:04:01 +0100) ---------------------------------------------------------------- Add tracepoints around calls to secure world ---------------------------------------------------------------- Jisheng Zhang (1): tee: optee: add invoke_fn tracepoints drivers/tee/optee/call.c | 4 +++ drivers/tee/optee/optee_trace.h | 67 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 drivers/tee/optee/optee_trace.h

4 years, 2 months

2
1
0 0

Linaro OP-TEE Contributions meeting March 2021

by Joakim Bech

Hi, LOC monthly meeting is planned to take place Thursday March 25th(a)16.00 (UTC+1). Current topics on the agenda are: - RNG in OP-TEE: This was proposed by Jorge for Foundries.io who created a couple of patches in a pull request. However he's unable to continue working with that, but no matter it's a good discussion, so I've left it on the agenda. - OCALL: Then there has been a patch set / PR: OCALL pull request, Jerome wanted to discuss what the next steps are. There is most likely room for additional topics, so feel free to suggest. Meeting details: --------------- Date/time: Thursday March 25th(a)16.00 (UTC+1) https://everytimezone.com/s/3596d6d3 Connection details: https://www.trustedfirmware.org/meetings/ Meeting notes: http://bit.ly/loc-notes Project page: https://www.linaro.org/projects/#LOC Regards, Joakim on behalf of the Linaro OP-TEE team

4 years, 2 months

1
1
0 0

Re: [TF-A] EHF + OPTEE on ARM64

by Sandeep Tripathy

Hi Peng, 1-Asynchronous preemption of SP: The long route is to make changes in the dispatcher and the corresponding SPD implementation to have synchronous preemption. ie: OP-TEE dispatcher will implement a G1NS (fiq) handler and invoke an entry of OP-TEE synchronously. OP-TEE will save the thread context and return. I did some POC but the complexity and effort to generalise was not justified by our requirement at that point especially envisioning the movement to SPMD in future. 2-Synchronous preemption of SP: ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6345 I used this approach instead to unblock OP-TEE work alongside EHF. This serves the purpose without changing the routing model with a limitation that non yielding/fast SMC can not be preempted. And ofcourse OP-TEE can mask G0 interrupt in anycase. But I think this is sufficient for your purpose. Please feedback if the above patch works for you. Thanks Sandeep On Mon, Mar 22, 2021 at 2:43 PM Peng Fan via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Achin, > > > > We are using SDEI for Jailhouse hypervisor to minimize interrupt latency, however we also wanna use OP-TEE when SDEI enabled. > > > > So I wanna how to make both work together. > > > > Thanks, > > Peng. > > > > From: Achin Gupta [mailto:Achin.Gupta@arm.com] > Sent: 2021年3月17日 17:59 > To: Peng Fan <peng.fan(a)nxp.com>; Jens Wiklander <jens.wiklander(a)linaro.org> > Cc: op-tee(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org > Subject: Re: EHF + OPTEE on ARM64 > > > > Hi Peng, > > > > +TF-A folk. > > > > My 0.02$. > > > > What is the problem you are trying to solve? Why do you need to run OP-TEE and EHF together? EHF was originally written to support a S-EL0 SP that is managed directly by TF-A in EL3 (TF-A folk can chime in). > > > > The SP could perform RAS error handling for which it needs the EHF. The EHF triages asynchronous exceptions and hands RAS errors to the SP for further handling. > > > > This is just one use case but there is no Trusted OS in these configurations. > > > > So, it would help to understand the requirement. > > > > cheers, > > Achin > > > > ________________________________ > > From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> > Sent: 17 March 2021 09:23 > To: Peng Fan <peng.fan(a)nxp.com> > Cc: op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> > Subject: Re: EHF + OPTEE on ARM64 > > > > On Wed, Mar 17, 2021 at 9:43 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > On Wed, Mar 17, 2021 at 9:02 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > On Wed, Mar 17, 2021 at 8:41 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > > > > > On Tue, Mar 16, 2021 at 11:08 AM Peng Fan <peng.fan(a)nxp.com> > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > In bl31/ehf.c, there are following two lines, per my > > > > > > > > understanding, when cpu is in secure world, the non-secure > > > > > > > > interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 > > > > > > > > /* Route EL3 interrupts when in Secure and Non-secure. > > > */ > > > > > > > > set_interrupt_rm_flag(flags, NON_SECURE); > > > > > > > > set_interrupt_rm_flag(flags, SECURE); > > > > > > > > > > > > > > > > So this will conflict with OP-TEE, because OP-TEE needs catch > > > > > > > > NS-interrupt as FIQ in S-EL1 world. > > > > > > > > > > > > > > In the case of GICv3, OP-TEE is configured to receive the > > > > > > > non-secure interrupts as FIQ and secure interrupts as IRQ. See > > > CFG_ARM_GICV3. > > > > > > > > > > > > But EHF needs NS-interrupt FIQ be catched by EL3 if I understand > > > > > > correct, per " set_interrupt_rm_flag(flags, SECURE);" > > > > > > > > > > > > So currently EHF could not work together with OP-TEE, right? > > > > > > > > > > To be honest, I'm not completely sure what EHF does. From OP-TEE > > > > > point of view we expect to receive the non-secure interrupts as a > > > > > way of doing a controlled exit. This allows OP-TEE to resume > > > > > execution with a different core on re-entry. If EL3 takes the > > > > > non-secure interrupts directly it will have to make sure to only re-enter > > > OP-TEE on this core as a return from exception. > > > > > > > > Is this easy to be achieved? > > > > > > I don't know, it depends on what you intend to do with this non-secure > > > interrupt. If it's handled at EL3 and then there's a return from exception back > > > to S-EL1 there's likely no harm done. But if there's a world switch involved > > > there might be trouble, OP-TEE might not be in a suitable state for a world > > > switch. > > > > > > > > > > > Or by using opteed_sel1_interrupt_handler, could we have similar > > > > behavior to allow the other core resume execution? > > > > > > Only OP-TEE itself can make a controlled exit as there's an internal state to > > > maintain. Currently that's signalled with a non-secure interrupt. > > > > > > Per EHF, https://trustedfirmware-a.readthedocs.io/en/latest/components/exception-han… > > On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of > > sufficient priority are signalled as FIQs, and therefore will be routed to EL3. > > As a result, S-EL1 software cannot expect to handle Non-secure interrupts at S-EL1. > > Essentially, this deprecates the routing mode described as CSS=0, TEL3=0. > > > > In order for S-EL1 software to handle Non-secure interrupts while having EHF enabled, > > the dispatcher must adopt a model where Non-secure interrupts are received at EL3, > > but are then synchronously handled over to S-EL1. > > > > The issue to me here how to synchronously handled over to S-EL1 and not break optee. > > I understand. OP-TEE is masking interrupts in some critical sections, > while in such a state OP-TEE cannot handle any asynchronous interrupt. > Temporarily masking interrupts is normally a quick operation so we do > it in quite a few places. > So the crux of the problem is to make sure that OP-TEE is in a state > where it can make a controlled exit. I don't have any good ideas for > this right now. > > Cheers, > Jens > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 2 months

2
1
0 0

[PATCH 1/1] tee: optee: do not check memref size on return from Secure World

by Jerome Forissier

When Secure World returns, it may have changed the size attribute of the memory references passed as [in/out] parameters. The GlobalPlatform TEE Internal Core API specification does not restrict the values that this size can take. In particular, Secure World may increase the value to be larger than the size of the input buffer to indicate that it needs more. Therefore, the size check in optee_from_msg_param() is incorrect and needs to be removed. This fixes a number of failed test cases in the GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09 when OP-TEE is compiled without dynamic shared memory support (CFG_CORE_DYN_SHM=n). Suggested-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Jerome Forissier <jerome(a)forissier.org> --- drivers/tee/optee/core.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 319a1e701163..ddb8f9ecf307 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -79,16 +79,6 @@ int optee_from_msg_param(struct tee_param *params, size_t num_params, return rc; p->u.memref.shm_offs = mp->u.tmem.buf_ptr - pa; p->u.memref.shm = shm; - - /* Check that the memref is covered by the shm object */ - if (p->u.memref.size) { - size_t o = p->u.memref.shm_offs + - p->u.memref.size - 1; - - rc = tee_shm_get_pa(shm, o, NULL); - if (rc) - return rc; - } break; case OPTEE_MSG_ATTR_TYPE_RMEM_INPUT: case OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT: -- 2.25.1

4 years, 2 months

1
0
0 0

Re: EHF + OPTEE on ARM64

by Achin Gupta

Hi Peng, +TF-A folk. My 0.02$. What is the problem you are trying to solve? Why do you need to run OP-TEE and EHF together? EHF was originally written to support a S-EL0 SP that is managed directly by TF-A in EL3 (TF-A folk can chime in). The SP could perform RAS error handling for which it needs the EHF. The EHF triages asynchronous exceptions and hands RAS errors to the SP for further handling. This is just one use case but there is no Trusted OS in these configurations. So, it would help to understand the requirement. cheers, Achin ________________________________ From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> Sent: 17 March 2021 09:23 To: Peng Fan <peng.fan(a)nxp.com> Cc: op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> Subject: Re: EHF + OPTEE on ARM64 On Wed, Mar 17, 2021 at 9:43 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > Subject: Re: EHF + OPTEE on ARM64 > > > > On Wed, Mar 17, 2021 at 9:02 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > On Wed, Mar 17, 2021 at 8:41 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > > > On Tue, Mar 16, 2021 at 11:08 AM Peng Fan <peng.fan(a)nxp.com> > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > In bl31/ehf.c, there are following two lines, per my > > > > > > > understanding, when cpu is in secure world, the non-secure > > > > > > > interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 > > > > > > > /* Route EL3 interrupts when in Secure and Non-secure. > > */ > > > > > > > set_interrupt_rm_flag(flags, NON_SECURE); > > > > > > > set_interrupt_rm_flag(flags, SECURE); > > > > > > > > > > > > > > So this will conflict with OP-TEE, because OP-TEE needs catch > > > > > > > NS-interrupt as FIQ in S-EL1 world. > > > > > > > > > > > > In the case of GICv3, OP-TEE is configured to receive the > > > > > > non-secure interrupts as FIQ and secure interrupts as IRQ. See > > CFG_ARM_GICV3. > > > > > > > > > > But EHF needs NS-interrupt FIQ be catched by EL3 if I understand > > > > > correct, per " set_interrupt_rm_flag(flags, SECURE);" > > > > > > > > > > So currently EHF could not work together with OP-TEE, right? > > > > > > > > To be honest, I'm not completely sure what EHF does. From OP-TEE > > > > point of view we expect to receive the non-secure interrupts as a > > > > way of doing a controlled exit. This allows OP-TEE to resume > > > > execution with a different core on re-entry. If EL3 takes the > > > > non-secure interrupts directly it will have to make sure to only re-enter > > OP-TEE on this core as a return from exception. > > > > > > Is this easy to be achieved? > > > > I don't know, it depends on what you intend to do with this non-secure > > interrupt. If it's handled at EL3 and then there's a return from exception back > > to S-EL1 there's likely no harm done. But if there's a world switch involved > > there might be trouble, OP-TEE might not be in a suitable state for a world > > switch. > > > > > > > > Or by using opteed_sel1_interrupt_handler, could we have similar > > > behavior to allow the other core resume execution? > > > > Only OP-TEE itself can make a controlled exit as there's an internal state to > > maintain. Currently that's signalled with a non-secure interrupt. > > > Per EHF, https://trustedfirmware-a.readthedocs.io/en/latest/components/exception-han… > On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of > sufficient priority are signalled as FIQs, and therefore will be routed to EL3. > As a result, S-EL1 software cannot expect to handle Non-secure interrupts at S-EL1. > Essentially, this deprecates the routing mode described as CSS=0, TEL3=0. > > In order for S-EL1 software to handle Non-secure interrupts while having EHF enabled, > the dispatcher must adopt a model where Non-secure interrupts are received at EL3, > but are then synchronously handled over to S-EL1. > > The issue to me here how to synchronously handled over to S-EL1 and not break optee. I understand. OP-TEE is masking interrupts in some critical sections, while in such a state OP-TEE cannot handle any asynchronous interrupt. Temporarily masking interrupts is normally a quick operation so we do it in quite a few places. So the crux of the problem is to make sure that OP-TEE is in a state where it can make a controlled exit. I don't have any good ideas for this right now. Cheers, Jens

4 years, 2 months

2
1
0 0

[PATCH] optee: enable apci support

by Ran Wang

This patch add ACPI support for optee driver. Signed-off-by: Ran Wang <ran.wang_1(a)nxp.com> --- drivers/tee/optee/core.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index cf4718c6d35d..8fb261f4b9db 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -5,6 +5,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include <linux/acpi.h> #include <linux/arm-smccc.h> #include <linux/errno.h> #include <linux/io.h> @@ -735,12 +736,21 @@ static const struct of_device_id optee_dt_match[] = { }; MODULE_DEVICE_TABLE(of, optee_dt_match); +#ifdef CONFIG_ACPI +static const struct acpi_device_id optee_acpi_match[] = { + { "OPTEE01",}, + { }, +}; +MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match); +#endif + static struct platform_driver optee_driver = { .probe = optee_probe, .remove = optee_remove, .driver = { .name = "optee", .of_match_table = optee_dt_match, + .acpi_match_table = ACPI_PTR(optee_acpi_match), }, }; module_platform_driver(optee_driver); -- 2.25.1

4 years, 2 months

3
5
0 0

EHF + OPTEE on ARM64

by Peng Fan

Hi, In bl31/ehf.c, there are following two lines, per my understanding, when cpu is in secure world, the non-secure interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 /* Route EL3 interrupts when in Secure and Non-secure. */ set_interrupt_rm_flag(flags, NON_SECURE); set_interrupt_rm_flag(flags, SECURE); So this will conflict with OP-TEE, because OP-TEE needs catch NS-interrupt as FIQ in S-EL1 world. Am I understand correct? Any ideas how we could address this to make EHF + OPTEE run together? Thanks Peng.

4 years, 2 months

2
7
0 0

Re: EHF + OPTEE on ARM64

by Jelle Sels

Hi, If I am not mistaking, the fiq handler should be opteed_sel1_interrupt_handler which will forward the interrupt to S-EL1. R, Jelle ________________________________________ From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Peng Fan via OP-TEE <op-tee(a)lists.trustedfirmware.org> Sent: Tuesday, March 16, 2021 11:08 To: op-tee(a)lists.trustedfirmware.org; Jens Wiklander; Joakim Bech Subject: EHF + OPTEE on ARM64 Hi, In bl31/ehf.c, there are following two lines, per my understanding, when cpu is in secure world, the non-secure interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 /* Route EL3 interrupts when in Secure and Non-secure. */ set_interrupt_rm_flag(flags, NON_SECURE); set_interrupt_rm_flag(flags, SECURE); So this will conflict with OP-TEE, because OP-TEE needs catch NS-interrupt as FIQ in S-EL1 world. Am I understand correct? Any ideas how we could address this to make EHF + OPTEE run together? Thanks Peng.

4 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

OP-TEE