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

["Sumit Garg" <sumit.garg@kernel.org>]

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
> > 
> >
> >

> 
> 
>