[RFC] Moving OP-TEE support from meta-arm to oe-core

[RFC] Moving OP-TEE support from meta-arm to oe-core

[Thomas Perrot]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

Hi,

Currently, OP-TEE support is maintained in the meta-arm layer. However,
OP-TEE is now being adopted by non-ARM platforms as well, notably RISC-
V.

Given this broader adoption, would it make sense to move the OP-TEE
recipes from meta-arm to oe-core?

I'd like to hear the community's thoughts on this.

Kind regards,
Thomas Perrot
-- 
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [yocto] [RFC] Moving OP-TEE support from meta-arm to oe-core

[Ross Burton]

On 22 Jan 2026, at 09:33, Thomas Perrot via lists.yoctoproject.org <thomas.perrot=bootlin.com@lists.yoctoproject.org> wrote:
> 
> Hi,
> 
> Currently, OP-TEE support is maintained in the meta-arm layer. However,
> OP-TEE is now being adopted by non-ARM platforms as well, notably RISC-
> V.
> 
> Given this broader adoption, would it make sense to move the OP-TEE
> recipes from meta-arm to oe-core?
> 
> I'd like to hear the community's thoughts on this.

Copying in the meta-arm list.

My immediate thought on this is “would the riscv machines actually use the same recipes” or is there enough forking and vendor branches happening that whilst in theory everyone is using OP-TEE, they’re not all using the _same_ optee.

I’m not against moving genuinely shared recipes somewhere common, but I do think verifying this will actually happen is important.

meta-arm tends to have several versions of optee at once for good reason… (currently one, but about to be two)

Ross

Re: [yocto] [RFC] Moving OP-TEE support from meta-arm to oe-core

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]

On Thu, Jan 22, 2026 at 9:05 AM Ross Burton via lists.yoctoproject.org
<ross.burton=arm.com@lists.yoctoproject.org> wrote:

> On 22 Jan 2026, at 09:33, Thomas Perrot via lists.yoctoproject.org
> <thomas.perrot=bootlin.com@lists.yoctoproject.org> wrote:
> >
> > Hi,
> >
> > Currently, OP-TEE support is maintained in the meta-arm layer. However,
> > OP-TEE is now being adopted by non-ARM platforms as well, notably RISC-
> > V.
> >
> > Given this broader adoption, would it make sense to move the OP-TEE
> > recipes from meta-arm to oe-core?
> >
> > I'd like to hear the community's thoughts on this.
>
> Copying in the meta-arm list.
>
> My immediate thought on this is “would the riscv machines actually use the
> same recipes” or is there enough forking and vendor branches happening that
> whilst in theory everyone is using OP-TEE, they’re not all using the _same_
> optee.
>
> I’m not against moving genuinely shared recipes somewhere common, but I do
> think verifying this will actually happen is important.
>
> meta-arm tends to have several versions of optee at once for good reason…
> (currently one, but about to be two)
>
>
I think its a good idea, but Ross's point is good too. If optee is forked
for every architecture that can not be a good thing. However, if we can get
qemuarm64 and qemuriscv64 based machines use an upstream version reliably,
we might be able to even help upstream to keep things sane
atleast for emulated machine architecture, similar to u-boot.


> Ross
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> You automatically follow any topics you start or reply to.
> View/Reply Online (#66179):
> https://lists.yoctoproject.org/g/yocto/message/66179
> Mute This Topic: https://lists.yoctoproject.org/mt/117397331/1997914
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [
> raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 3244 bytes --]

Re: [yocto] [RFC] Moving OP-TEE support from meta-arm to oe-core

[Rahul Singh]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

Hi,
I would like to add to this point that since the branches aren't gonna be shared (vendor specific or vendor agnostic), I feel we should first choose the suitable architecture implementation first where the base ISA is shared across many platforms (probably RV64* or RV32*)and then list out probable steps how OPTEE should be ported to risc-v.

[-- Attachment #2: Type: text/html, Size: 371 bytes --]

Re: [meta-arm] [yocto] [RFC] Moving OP-TEE support from meta-arm to oe-core

[Sumit Garg]

On Thu, Jan 22, 2026 at 09:22:27AM -0800, Khem Raj via lists.yoctoproject.org wrote:
> On Thu, Jan 22, 2026 at 9:05 AM Ross Burton via lists.yoctoproject.org
> <ross.burton=arm.com@lists.yoctoproject.org> wrote:
> 
> > On 22 Jan 2026, at 09:33, Thomas Perrot via lists.yoctoproject.org
> > <thomas.perrot=bootlin.com@lists.yoctoproject.org> wrote:
> > >
> > > Hi,
> > >
> > > Currently, OP-TEE support is maintained in the meta-arm layer. However,
> > > OP-TEE is now being adopted by non-ARM platforms as well, notably RISC-
> > > V.
> > >
> > > Given this broader adoption, would it make sense to move the OP-TEE
> > > recipes from meta-arm to oe-core?
> > >
> > > I'd like to hear the community's thoughts on this.
> >

I would be supportive of idea to move upstream aligned OP-TEE recipes to
OE core which can be built in an architecture neutral way.

> > Copying in the meta-arm list.
> >
> > My immediate thought on this is “would the riscv machines actually use the
> > same recipes” or is there enough forking and vendor branches happening that
> > whilst in theory everyone is using OP-TEE, they’re not all using the _same_
> > optee.
> >

Agree, I rarely see OP-TEE and TF-A recipes being reused by various
vendor BSP layers. There is enough forking there for sure but the other
reason is that vendor BSP layer maintainers don't typically want to
depend on meta-arm but only OE core. This typically causes the vendor
BSPs to just copy TF-A and OP-TEE recipes rather than using overrides.

Not sure what's the standard practice that OE/Yocto community would
recommend here to avoid duplication.

BTW, compilation for RISC-V can be referred here [1].

[1] https://github.com/OP-TEE/optee_os/blob/master/.github/workflows/ci.yml#L331

> > I’m not against moving genuinely shared recipes somewhere common, but I do
> > think verifying this will actually happen is important.
> >
> > meta-arm tends to have several versions of optee at once for good reason…
> > (currently one, but about to be two)
> >
> >
> I think its a good idea, but Ross's point is good too. If optee is forked
> for every architecture that can not be a good thing. However, if we can get
> qemuarm64 and qemuriscv64 based machines use an upstream version reliably,
> we might be able to even help upstream to keep things sane
> atleast for emulated machine architecture, similar to u-boot.
> 

That's right, getting the OP-TEE recipes in OE core would provide better
chances of cross-architecture reuse following the U-Boot example.

Although I would have hoped full boot stack including TF-A recipes to be
in OE-core for emulated machines but not sure if that's really meta-arm
maintainers are looking forward too.

-Sumit

> 
> > Ross
> > 
> >
> >

> 
> 
> 

Re: [yocto] [RFC] Moving OP-TEE support from meta-arm to oe-core

[John Dowd]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

I had thought that OP-TEE can only work on ARM processors since it relies
on the TrustZone h/w. For intel/AMD you have TPM and for something like
powerpc you have CAAM.

Cheers!!

On Thu, Jan 22, 2026 at 4:33 AM Thomas Perrot via lists.yoctoproject.org
<thomas.perrot=bootlin.com@lists.yoctoproject.org> wrote:

> Hi,
>
> Currently, OP-TEE support is maintained in the meta-arm layer. However,
> OP-TEE is now being adopted by non-ARM platforms as well, notably RISC-
> V.
>
> Given this broader adoption, would it make sense to move the OP-TEE
> recipes from meta-arm to oe-core?
>
> I'd like to hear the community's thoughts on this.
>
> Kind regards,
> Thomas Perrot
> --
> Thomas Perrot, Bootlin
> Embedded Linux and kernel engineering
> https://bootlin.com
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#66178):
> https://lists.yoctoproject.org/g/yocto/message/66178
> Mute This Topic: https://lists.yoctoproject.org/mt/117397331/9366835
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [
> jdowd@slashdevslashnull.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
"To err is human, to forgive is not company policy."

John Dowd
Contract - Software Developer
Cell: (613)316-7884

[-- Attachment #2: Type: text/html, Size: 2468 bytes --]

Re: [yocto] [RFC] Moving OP-TEE support from meta-arm to oe-core

[Thomas Perrot]

[-- Attachment #1.1: Type: text/plain, Size: 3065 bytes --]

Hello,

On Thu, 2026-01-22 at 09:22 -0800, Khem Raj via lists.yoctoproject.org
wrote:
> 
> 
> On Thu, Jan 22, 2026 at 9:05 AM Ross Burton via
> lists.yoctoproject.org <ross.burton=arm.com@lists.yoctoproject.org>
> wrote:
> > On 22 Jan 2026, at 09:33, Thomas Perrot via lists.yoctoproject.org
> > <thomas.perrot=bootlin.com@lists.yoctoproject.org> wrote:
> > > 
> > > Hi,
> > > 
> > > Currently, OP-TEE support is maintained in the meta-arm layer.
> > However,
> > > OP-TEE is now being adopted by non-ARM platforms as well, notably
> > RISC-
> > > V.
> > > 
> > > Given this broader adoption, would it make sense to move the OP-
> > TEE
> > > recipes from meta-arm to oe-core?
> > > 
> > > I'd like to hear the community's thoughts on this.
> > 
> > Copying in the meta-arm list.
> > 
> > My immediate thought on this is “would the riscv machines actually
> > use the same recipes” or is there enough forking and vendor
> > branches happening that whilst in theory everyone is using OP-TEE,
> > they’re not all using the _same_ optee.
> > 
> > I’m not against moving genuinely shared recipes somewhere common,
> > but I do think verifying this will actually happen is important.
> > 
> > meta-arm tends to have several versions of optee at once for good
> > reason… (currently one, but about to be two)
> > 
> > 
> 
> 
> I think its a good idea, but Ross's point is good too. If optee is
> forked for every architecture that can not be a good thing. However,
> if we can get
> qemuarm64 and qemuriscv64 based machines use an upstream version
> reliably, we might be able to even help upstream to keep things sane
> atleast for emulated machine architecture, similar to u-boot.
>  

I agree with this approach. It's worth noting that OP-TEE upstream
already runs their test suite (xtest) on QEMU. This gives us confidence
that the upstream version works reliably on emulated machines. 

                                                                                                                                                                                                                                                                                                                              
Starting with qemuarm64 and qemuriscv64 support in oe-core using
upstream OP-TEE would be a reasonable first step, leaving vendor-
specific versions and hardware-specific configurations in their
respective layers.

Kind regards,
Thomas Perrot

> > Ross
> > 
> > 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#66180):
> https://lists.yoctoproject.org/g/yocto/message/66180
> Mute This Topic: https://lists.yoctoproject.org/mt/117397331/5443093
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe:
> https://lists.yoctoproject.org/g/yocto/unsub [thomas.perrot@bootlin.com
> ]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

-- 
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #1.2: Type: text/html, Size: 5040 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [yocto] [RFC] Moving OP-TEE support from meta-arm to oe-core

[Jose Quaresma]

[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]

Hi Thomas,

Could this proposal be sent to the OE-core mailing list? It's probably a
bit late for the next LTS, but it doesn't hurt to try.

Jose

Thomas Perrot via lists.yoctoproject.org <thomas.perrot=
bootlin.com@lists.yoctoproject.org> escreveu (terça, 3/02/2026 à(s) 16:29):

> Hello,
>
> On Thu, 2026-01-22 at 09:22 -0800, Khem Raj via lists.yoctoproject.org
> wrote:
>
>
>
> On Thu, Jan 22, 2026 at 9:05 AM Ross Burton via lists.yoctoproject.org
> <ross.burton=arm.com@lists.yoctoproject.org> wrote:
>
> On 22 Jan 2026, at 09:33, Thomas Perrot via lists.yoctoproject.org
> <thomas.perrot=bootlin.com@lists.yoctoproject.org> wrote:
> >
> > Hi,
> >
> > Currently, OP-TEE support is maintained in the meta-arm layer. However,
> > OP-TEE is now being adopted by non-ARM platforms as well, notably RISC-
> > V.
> >
> > Given this broader adoption, would it make sense to move the OP-TEE
> > recipes from meta-arm to oe-core?
> >
> > I'd like to hear the community's thoughts on this.
>
> Copying in the meta-arm list.
>
> My immediate thought on this is “would the riscv machines actually use the
> same recipes” or is there enough forking and vendor branches happening that
> whilst in theory everyone is using OP-TEE, they’re not all using the _same_
> optee.
>
> I’m not against moving genuinely shared recipes somewhere common, but I do
> think verifying this will actually happen is important.
>
> meta-arm tends to have several versions of optee at once for good reason…
> (currently one, but about to be two)
>
>
>
> I think its a good idea, but Ross's point is good too. If optee is forked
> for every architecture that can not be a good thing. However, if we can get
> qemuarm64 and qemuriscv64 based machines use an upstream version reliably,
> we might be able to even help upstream to keep things sane
> atleast for emulated machine architecture, similar to u-boot.
>
>
>
> I agree with this approach. It's worth noting that OP-TEE upstream already
> runs their test suite (xtest) on QEMU. This gives us confidence that the
> upstream version works reliably on emulated machines.
>
> Starting with qemuarm64 and qemuriscv64 support in oe-core using upstream
> OP-TEE would be a reasonable first step, leaving vendor-specific versions
> and hardware-specific configurations in their respective layers.
>
> Kind regards,
> Thomas Perrot
>
> Ross
>
>
>
>
>
>
> --
>
> Thomas Perrot, Bootlin
> Embedded Linux and kernel engineeringhttps://bootlin.com
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#66212):
> https://lists.yoctoproject.org/g/yocto/message/66212
> Mute This Topic: https://lists.yoctoproject.org/mt/117397331/5052612
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [
> quaresma.jose@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
Best regards,

José Quaresma

[-- Attachment #2: Type: text/html, Size: 5867 bytes --]