What's the current state of being able to log to the REE using components
that already exist in OP-TEE today? I've seen various issues relating to
it in GitHub: https://github.com/OP-TEE/optee_os/issues/4230 and
https://github.com/OP-TEE/optee_os/pull/810, but both ended up being closed
before I can see anything relating to logging to integrated. Did something
like this end up getting implemented yet?
Cheers,
--
Jeffrey Kardatzke
jkardatzke(a)google.com
Google, Inc.
Hi,
It's soon time for another LOC monthly meeting. For time and connection
details see the calendar at https://www.trustedfirmware.org/meetings/
I have one topic to discuss:
OP-TEE 3.20.0 is just released and a PR [1] to upgrade from TEE Internal
Core API version 1.1 to 1.3.1 is soon to be merged. This may bump the
major OP-TEE version in the next release. There's in particular the
define TEE_ALG_SM2_PKE which is tricky to keep compatible when
upgrading. We have some time until the next release to determine if this
is reason enough to bump the major version.
Any other topics?
[1] https://github.com/OP-TEE/optee_os/pull/5688
Thanks,
Jens
Dear all,
This small series aggregates 2 change proposals related to OP-TEE async notif.
I've made a single series since the 2 patches hit the same portions of optee
driver source file and I think this will help the review. If you prefer having
independent post and deal with the conflicts afterward, please tell me.
Patch "optee: add per cpu asynchronous notification" aims at allowing optee
to use a per-cpu interrupt (PPI on Arm CPUs) for async notif instead of a
shared peripheral interrupt.
The 2 next patches implement a new feature in OP-TEE, based on optee async
notif. The allow optee driver to behave as an interrupt controller, for
when a secure OP-TEE event is to be delivered to the Linux kernel as a
interrupt event.
Regards,
Etienne
Etienne Carriere (3):
optee: add per cpu asynchronous notification
dt-bindings: arm: optee: add interrupt controller properties
optee core: add irq chip using optee async notification
.../arm/firmware/linaro,optee-tz.yaml | 19 +-
drivers/tee/optee/optee_private.h | 24 ++
drivers/tee/optee/optee_smc.h | 78 +++++-
drivers/tee/optee/smc_abi.c | 249 +++++++++++++++++-
4 files changed, 358 insertions(+), 12 deletions(-)
--
2.25.1
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.20.0 is scheduled to be released on 2023-01-20. So, now is a
good time to start testing the master branch on the various platforms
and report/fix any bugs.
The GitHub pull request for collecting Tested-by tags or any other
comments is https://github.com/OP-TEE/optee_os/pull/5751
As usual, we will create a release candidate tag one week before the
release date for final testing.
In addition to that you can find some additional information related to
releases here:
https://optee.readthedocs.io/en/latest/general/releases.html
Thanks,
Jens
Hello expert,
I have a few questions about the optee device tree and tee driver.
In our environment, optee uses version 3.19 vexpress-fvp and runs on top of hafnium as SPMC. Here's my question.
1. Does the current optee version support adding ACPI table iterm for optee to enable REE to identify the installed optee driver so that TA and CA can establish communication?
(I raise this question because I cannot find the corresponding optee node in "/sys/devices/platform" in the current linux environment.
While in the QEMU runtime environment, the corresponding optee node is in "/proc/device-tree/firmware", i.e. "linaro,optee-tz".)
2. If I want to transfer dtb file which includes a device tree node written by optee to linux, How to configure CFG_DT, CFG_DT_ADDR, and CFG_EXTERNAL_DTB_OVERLAY?
(I understand that this method should be independent from the method in question 1. If it is not, look forward your explain.)
Looking forward to your reply. Thanks.
regards,
yuye