| Message ID | 20230403154306.3422-2-adam.johnston@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | arm-bsp/optee: Update OP-TEE TA devkit to 3.20 for N1SDP | expand |
On Mon, Apr 03, 2023 at 04:43:06PM +0100, Adam Johnston wrote: > From: Adam Johnston <adam.johnston@arm.com> > > As optee-os for the N1SDP has been updated to 3.20 we need to do the > same for optee-os-tavdekit. Otherwise errors will be seen if/when > optee-os-tavdekit is built. So, why only update it for N1SDP and not for everyone globally in meta-arm? > Signed-off-by: Adam Johnston <adam.johnston@arm.com> > --- > .../optee/optee-os-tadevkit_3.18.0.bbappend | 1 - > .../optee/optee-os-tadevkit_3.20.0.bbappend | 6 +++++ > .../optee/optee-os-tadevkit_3.20.0.bb | 24 +++++++++++++++++++ > 3 files changed, 30 insertions(+), 1 deletion(-) > create mode 100644 meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappend > create mode 100644 meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > > diff --git a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappend b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappend > index 9a210832..6a22d47e 100644 > --- a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappend > +++ b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappend > @@ -2,6 +2,5 @@ > > MACHINE_OPTEE_OS_TADEVKIT_REQUIRE ?= "" > MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:tc = "optee-os-generic-tc.inc" > -MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:n1sdp = "optee-os-n1sdp.inc" > > require ${MACHINE_OPTEE_OS_TADEVKIT_REQUIRE} > diff --git a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappend b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappend > new file mode 100644 > index 00000000..e09c4a5e > --- /dev/null > +++ b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappend > @@ -0,0 +1,6 @@ > +# Machine specific configurations > + > +MACHINE_OPTEE_OS_TADEVKIT_REQUIRE ?= "" > +MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:n1sdp = "optee-os-n1sdp.inc" > + > +require ${MACHINE_OPTEE_OS_TADEVKIT_REQUIRE} > diff --git a/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb b/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > new file mode 100644 > index 00000000..202caa54 > --- /dev/null > +++ b/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > @@ -0,0 +1,24 @@ > +require optee-os_3.20.0.bb > + > +SUMMARY = "OP-TEE Trusted OS TA devkit" > +DESCRIPTION = "OP-TEE TA devkit for build TAs" > +HOMEPAGE = "https://www.op-tee.org/" > + > +DEPENDS += "python3-pycryptodome-native" > + > +do_install() { > + #install TA devkit > + install -d ${D}${includedir}/optee/export-user_ta/ > + for f in ${B}/export-ta_${OPTEE_ARCH}/* ; do > + cp -aR $f ${D}${includedir}/optee/export-user_ta/ > + done > +} > + > +do_deploy() { > + echo "Do not inherit do_deploy from optee-os." > +} > + > +FILES:${PN} = "${includedir}/optee/" > + > +# Build paths are currently embedded > +INSANE_SKIP:${PN}-dev += "buildpaths" > -- > 2.38.1
The only other platform which also enables OP-TEE OS is Corstone-1000, but they didn't enable OP-TEE OS TA Devkit (required for OP-TEE xtest) I agree it would make sense to update/enable both at the same time for CI (as long as it doesn't affect the Corstone-100 BSPs) -----Original Message----- From: Denys Dmytriyenko <denis@denix.org> Sent: Tuesday, April 4, 2023 1:06 AM To: Adam Johnston <Adam.Johnston@arm.com> Cc: meta-arm@lists.yoctoproject.org; Ross Burton <Ross.Burton@arm.com>; nd <nd@arm.com> Subject: Re: [meta-arm] [PATCH 1/1] arm-bsp/optee: Update OP-TEE TA devkit to 3.20 for N1SDP On Mon, Apr 03, 2023 at 04:43:06PM +0100, Adam Johnston wrote: > From: Adam Johnston <adam.johnston@arm.com> > > As optee-os for the N1SDP has been updated to 3.20 we need to do the > same for optee-os-tavdekit. Otherwise errors will be seen if/when > optee-os-tavdekit is built. So, why only update it for N1SDP and not for everyone globally in meta-arm? > Signed-off-by: Adam Johnston <adam.johnston@arm.com> > --- > .../optee/optee-os-tadevkit_3.18.0.bbappend | 1 - > .../optee/optee-os-tadevkit_3.20.0.bbappend | 6 +++++ > .../optee/optee-os-tadevkit_3.20.0.bb | 24 +++++++++++++++++++ > 3 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 > meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappend > create mode 100644 > meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > > diff --git > a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappen > d > b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappen > d > index 9a210832..6a22d47e 100644 > --- > a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappen > d > +++ b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bba > +++ ppend > @@ -2,6 +2,5 @@ > > MACHINE_OPTEE_OS_TADEVKIT_REQUIRE ?= "" > MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:tc = "optee-os-generic-tc.inc" > -MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:n1sdp = "optee-os-n1sdp.inc" > > require ${MACHINE_OPTEE_OS_TADEVKIT_REQUIRE} > diff --git > a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappen > d > b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappen > d > new file mode 100644 > index 00000000..e09c4a5e > --- /dev/null > +++ b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bba > +++ ppend > @@ -0,0 +1,6 @@ > +# Machine specific configurations > + > +MACHINE_OPTEE_OS_TADEVKIT_REQUIRE ?= "" > +MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:n1sdp = "optee-os-n1sdp.inc" > + > +require ${MACHINE_OPTEE_OS_TADEVKIT_REQUIRE} > diff --git > a/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > b/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > new file mode 100644 > index 00000000..202caa54 > --- /dev/null > +++ b/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > @@ -0,0 +1,24 @@ > +require optee-os_3.20.0.bb > + > +SUMMARY = "OP-TEE Trusted OS TA devkit" > +DESCRIPTION = "OP-TEE TA devkit for build TAs" > +HOMEPAGE = "https://www.op-tee.org/" > + > +DEPENDS += "python3-pycryptodome-native" > + > +do_install() { > + #install TA devkit > + install -d ${D}${includedir}/optee/export-user_ta/ > + for f in ${B}/export-ta_${OPTEE_ARCH}/* ; do > + cp -aR $f ${D}${includedir}/optee/export-user_ta/ > + done > +} > + > +do_deploy() { > + echo "Do not inherit do_deploy from optee-os." > +} > + > +FILES:${PN} = "${includedir}/optee/" > + > +# Build paths are currently embedded > +INSANE_SKIP:${PN}-dev += "buildpaths" > -- > 2.38.1
On Tue, Apr 04, 2023 at 08:24:14AM +0000, Adam Johnston wrote: > The only other platform which also enables OP-TEE OS is Corstone-1000, but > they didn't enable OP-TEE OS TA Devkit (required for OP-TEE xtest) > I agree it would make sense to update/enable both at the same time for CI > (as long as it doesn't affect the Corstone-100 BSPs) And there are downstream BSPs using meta-arm and consuming OPTEE (OS, client, xtest, etc) It would be appreciated if generic recipes are also updated for everyone to use and not just platform-specific bbappends. Thanks.
Ross/Jon might be able to provide more insight here. AFAIK they drive the versions supported based on what the component team (in this case OP-TEE) have released. The complexity for components like OP-TEE, which require platform adaptation, is that updating the recipe for a specific platform is gated by when the adaptation (or OoT patches) can be updated and validated by the relevant platform team. Regards Adam
On Wed, Apr 05, 2023 at 08:02:52AM +0000, Adam Johnston wrote: > Ross/Jon might be able to provide more insight here. > > AFAIK they drive the versions supported based on what the component team (in > this case OP-TEE) have released. > > The complexity for components like OP-TEE, which require platform > adaptation, is that updating the recipe for a specific platform is gated by > when the adaptation (or OoT patches) can be updated and validated by the > relevant platform team. At the TSC meetings recently we've discussed the possibility of migrating Trusted Firmware and OP-TEE components from meta-arm to oe-core in order to reduce dependencies on these core components by other BSPs. In meta-ti BSP we've been updating OPTEE (and TF-A to a lesser extent) regularly to the very latest release and often ahead of meta-arm, even though meta-arm is upstream to meta-ti for those components - usually latest versions add new features or new platform support. TI policy for OPTEE and TF-A is to work directly with upstream and hence there are no local patches. I was wondering how ARM reference platforms in meta-arm-bsp and platforms in other BSPs handle this and whether there's extra work required updating local patches or adaptations for regular version bumps. If OPTEE and TF-A go to oe-core, would that negatively affect meta-arm? > ________________________________ > From: Denys Dmytriyenko <denis@denix.org> > Sent: Tuesday, April 4, 2023 5:14:14 PM > To: Adam Johnston <Adam.Johnston@arm.com> > Cc: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org>; Ross Burton <Ross.Burton@arm.com>; nd <nd@arm.com> > Subject: Re: [meta-arm] [PATCH 1/1] arm-bsp/optee: Update OP-TEE TA devkit to 3.20 for N1SDP > > On Tue, Apr 04, 2023 at 08:24:14AM +0000, Adam Johnston wrote: > > The only other platform which also enables OP-TEE OS is Corstone-1000, but > > they didn't enable OP-TEE OS TA Devkit (required for OP-TEE xtest) > > I agree it would make sense to update/enable both at the same time for CI > > (as long as it doesn't affect the Corstone-100 BSPs) > > And there are downstream BSPs using meta-arm and consuming OPTEE (OS, client, > xtest, etc) > > It would be appreciated if generic recipes are also updated for everyone to > use and not just platform-specific bbappends. Thanks. > > -- > Denys > > > > -----Original Message----- > > From: Denys Dmytriyenko <denis@denix.org> > > Sent: Tuesday, April 4, 2023 1:06 AM > > To: Adam Johnston <Adam.Johnston@arm.com> > > Cc: meta-arm@lists.yoctoproject.org; Ross Burton <Ross.Burton@arm.com>; nd <nd@arm.com> > > Subject: Re: [meta-arm] [PATCH 1/1] arm-bsp/optee: Update OP-TEE TA devkit to 3.20 for N1SDP > > > > On Mon, Apr 03, 2023 at 04:43:06PM +0100, Adam Johnston wrote: > > > From: Adam Johnston <adam.johnston@arm.com> > > > > > > As optee-os for the N1SDP has been updated to 3.20 we need to do the > > > same for optee-os-tavdekit. Otherwise errors will be seen if/when > > > optee-os-tavdekit is built. > > > > So, why only update it for N1SDP and not for everyone globally in meta-arm? > > > > > > > Signed-off-by: Adam Johnston <adam.johnston@arm.com> > > > --- > > > .../optee/optee-os-tadevkit_3.18.0.bbappend | 1 - > > > .../optee/optee-os-tadevkit_3.20.0.bbappend | 6 +++++ > > > .../optee/optee-os-tadevkit_3.20.0.bb | 24 +++++++++++++++++++ > > > 3 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 > > > meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappend > > > create mode 100644 > > > meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > > > > > > diff --git > > > a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappen > > > d > > > b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappen > > > d > > > index 9a210832..6a22d47e 100644 > > > --- > > > a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappen > > > d > > > +++ b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bba > > > +++ ppend > > > @@ -2,6 +2,5 @@ > > > > > > MACHINE_OPTEE_OS_TADEVKIT_REQUIRE ?= "" > > > MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:tc = "optee-os-generic-tc.inc" > > > -MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:n1sdp = "optee-os-n1sdp.inc" > > > > > > require ${MACHINE_OPTEE_OS_TADEVKIT_REQUIRE} > > > diff --git > > > a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappen > > > d > > > b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappen > > > d > > > new file mode 100644 > > > index 00000000..e09c4a5e > > > --- /dev/null > > > +++ b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bba > > > +++ ppend > > > @@ -0,0 +1,6 @@ > > > +# Machine specific configurations > > > + > > > +MACHINE_OPTEE_OS_TADEVKIT_REQUIRE ?= "" > > > +MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:n1sdp = "optee-os-n1sdp.inc" > > > + > > > +require ${MACHINE_OPTEE_OS_TADEVKIT_REQUIRE} > > > diff --git > > > a/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > > > b/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > > > new file mode 100644 > > > index 00000000..202caa54 > > > --- /dev/null > > > +++ b/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > > > @@ -0,0 +1,24 @@ > > > +require optee-os_3.20.0.bb > > > + > > > +SUMMARY = "OP-TEE Trusted OS TA devkit" > > > +DESCRIPTION = "OP-TEE TA devkit for build TAs" > > > +HOMEPAGE = "https://www.op-tee.org/" > > > + > > > +DEPENDS += "python3-pycryptodome-native" > > > + > > > +do_install() { > > > + #install TA devkit > > > + install -d ${D}${includedir}/optee/export-user_ta/ > > > + for f in ${B}/export-ta_${OPTEE_ARCH}/* ; do > > > + cp -aR $f ${D}${includedir}/optee/export-user_ta/ > > > + done > > > +} > > > + > > > +do_deploy() { > > > + echo "Do not inherit do_deploy from optee-os." > > > +} > > > + > > > +FILES:${PN} = "${includedir}/optee/" > > > + > > > +# Build paths are currently embedded > > > +INSANE_SKIP:${PN}-dev += "buildpaths" > > > -- > > > 2.38.1
On Wed, Apr 05, 2023 at 11:08:47AM -0400, Denys Dmytriyenko wrote: > On Wed, Apr 05, 2023 at 08:02:52AM +0000, Adam Johnston wrote: > > Ross/Jon might be able to provide more insight here. > > > > AFAIK they drive the versions supported based on what the component team (in > > this case OP-TEE) have released. > > > > The complexity for components like OP-TEE, which require platform > > adaptation, is that updating the recipe for a specific platform is gated by > > when the adaptation (or OoT patches) can be updated and validated by the > > relevant platform team. > > At the TSC meetings recently we've discussed the possibility of migrating > Trusted Firmware and OP-TEE components from meta-arm to oe-core in order to > reduce dependencies on these core components by other BSPs. > > In meta-ti BSP we've been updating OPTEE (and TF-A to a lesser extent) > regularly to the very latest release and often ahead of meta-arm, even though > meta-arm is upstream to meta-ti for those components - usually latest versions > add new features or new platform support. TI policy for OPTEE and TF-A is to > work directly with upstream and hence there are no local patches. Please send patches when there is the delta you describe. Or, let me know and I'll do the patches. I try to stay on top of the latest releases as they come out, but sometimes I don't notice for a bit. > I was wondering how ARM reference platforms in meta-arm-bsp and platforms in > other BSPs handle this and whether there's extra work required updating local > patches or adaptations for regular version bumps. If OPTEE and TF-A go to > oe-core, would that negatively affect meta-arm? It is not known by me who needs the latest versions of the packages in a cadence more frequent than what has been occurring. To my knowledge, meta-arm always has the latest version when the releases are cut. If this is not the case, please do hold me accountable. Thanks, Jon > > ________________________________ > > From: Denys Dmytriyenko <denis@denix.org> > > Sent: Tuesday, April 4, 2023 5:14:14 PM > > To: Adam Johnston <Adam.Johnston@arm.com> > > Cc: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org>; Ross Burton <Ross.Burton@arm.com>; nd <nd@arm.com> > > Subject: Re: [meta-arm] [PATCH 1/1] arm-bsp/optee: Update OP-TEE TA devkit to 3.20 for N1SDP > > > > On Tue, Apr 04, 2023 at 08:24:14AM +0000, Adam Johnston wrote: > > > The only other platform which also enables OP-TEE OS is Corstone-1000, but > > > they didn't enable OP-TEE OS TA Devkit (required for OP-TEE xtest) > > > I agree it would make sense to update/enable both at the same time for CI > > > (as long as it doesn't affect the Corstone-100 BSPs) > > > > And there are downstream BSPs using meta-arm and consuming OPTEE (OS, client, > > xtest, etc) > > > > It would be appreciated if generic recipes are also updated for everyone to > > use and not just platform-specific bbappends. Thanks. > > > > -- > > Denys > > > > > > > -----Original Message----- > > > From: Denys Dmytriyenko <denis@denix.org> > > > Sent: Tuesday, April 4, 2023 1:06 AM > > > To: Adam Johnston <Adam.Johnston@arm.com> > > > Cc: meta-arm@lists.yoctoproject.org; Ross Burton <Ross.Burton@arm.com>; nd <nd@arm.com> > > > Subject: Re: [meta-arm] [PATCH 1/1] arm-bsp/optee: Update OP-TEE TA devkit to 3.20 for N1SDP > > > > > > On Mon, Apr 03, 2023 at 04:43:06PM +0100, Adam Johnston wrote: > > > > From: Adam Johnston <adam.johnston@arm.com> > > > > > > > > As optee-os for the N1SDP has been updated to 3.20 we need to do the > > > > same for optee-os-tavdekit. Otherwise errors will be seen if/when > > > > optee-os-tavdekit is built. > > > > > > So, why only update it for N1SDP and not for everyone globally in meta-arm? > > > > > > > > > > Signed-off-by: Adam Johnston <adam.johnston@arm.com> > > > > --- > > > > .../optee/optee-os-tadevkit_3.18.0.bbappend | 1 - > > > > .../optee/optee-os-tadevkit_3.20.0.bbappend | 6 +++++ > > > > .../optee/optee-os-tadevkit_3.20.0.bb | 24 +++++++++++++++++++ > > > > 3 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 > > > > meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappend > > > > create mode 100644 > > > > meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > > > > > > > > diff --git > > > > a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappen > > > > d > > > > b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappen > > > > d > > > > index 9a210832..6a22d47e 100644 > > > > --- > > > > a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappen > > > > d > > > > +++ b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bba > > > > +++ ppend > > > > @@ -2,6 +2,5 @@ > > > > > > > > MACHINE_OPTEE_OS_TADEVKIT_REQUIRE ?= "" > > > > MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:tc = "optee-os-generic-tc.inc" > > > > -MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:n1sdp = "optee-os-n1sdp.inc" > > > > > > > > require ${MACHINE_OPTEE_OS_TADEVKIT_REQUIRE} > > > > diff --git > > > > a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappen > > > > d > > > > b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappen > > > > d > > > > new file mode 100644 > > > > index 00000000..e09c4a5e > > > > --- /dev/null > > > > +++ b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bba > > > > +++ ppend > > > > @@ -0,0 +1,6 @@ > > > > +# Machine specific configurations > > > > + > > > > +MACHINE_OPTEE_OS_TADEVKIT_REQUIRE ?= "" > > > > +MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:n1sdp = "optee-os-n1sdp.inc" > > > > + > > > > +require ${MACHINE_OPTEE_OS_TADEVKIT_REQUIRE} > > > > diff --git > > > > a/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > > > > b/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > > > > new file mode 100644 > > > > index 00000000..202caa54 > > > > --- /dev/null > > > > +++ b/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb > > > > @@ -0,0 +1,24 @@ > > > > +require optee-os_3.20.0.bb > > > > + > > > > +SUMMARY = "OP-TEE Trusted OS TA devkit" > > > > +DESCRIPTION = "OP-TEE TA devkit for build TAs" > > > > +HOMEPAGE = "https://www.op-tee.org/" > > > > + > > > > +DEPENDS += "python3-pycryptodome-native" > > > > + > > > > +do_install() { > > > > + #install TA devkit > > > > + install -d ${D}${includedir}/optee/export-user_ta/ > > > > + for f in ${B}/export-ta_${OPTEE_ARCH}/* ; do > > > > + cp -aR $f ${D}${includedir}/optee/export-user_ta/ > > > > + done > > > > +} > > > > + > > > > +do_deploy() { > > > > + echo "Do not inherit do_deploy from optee-os." > > > > +} > > > > + > > > > +FILES:${PN} = "${includedir}/optee/" > > > > + > > > > +# Build paths are currently embedded > > > > +INSANE_SKIP:${PN}-dev += "buildpaths" > > > > -- > > > > 2.38.1 > > -- > Regards, > Denys Dmytriyenko <denis@denix.org> > PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 > Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 >
On 5 Apr 2023, at 20:13, Jon Mason <jdmason@kudzu.us> wrote: > >> At the TSC meetings recently we've discussed the possibility of migrating >> Trusted Firmware and OP-TEE components from meta-arm to oe-core in order to >> reduce dependencies on these core components by other BSPs. My opinion here is that in the ideal world a generic-arm64 BSP wouldn’t need anything extra in oe-core to work: assume working firmware (SystemReady), mainline kernel, mainline U-Boot, etc and it will work. It may not be as fully functional as you’d get by adding custom optee/tf pieces but that’s where meta-arm steps in, which was designed explicitly to be BSP-agnostic. Ross
On Wed, Apr 05, 2023 at 03:13:33PM -0400, Jon Mason wrote: > On Wed, Apr 05, 2023 at 11:08:47AM -0400, Denys Dmytriyenko wrote: > > On Wed, Apr 05, 2023 at 08:02:52AM +0000, Adam Johnston wrote: > > > Ross/Jon might be able to provide more insight here. > > > > > > AFAIK they drive the versions supported based on what the component team (in > > > this case OP-TEE) have released. > > > > > > The complexity for components like OP-TEE, which require platform > > > adaptation, is that updating the recipe for a specific platform is gated by > > > when the adaptation (or OoT patches) can be updated and validated by the > > > relevant platform team. > > > > At the TSC meetings recently we've discussed the possibility of migrating > > Trusted Firmware and OP-TEE components from meta-arm to oe-core in order to > > reduce dependencies on these core components by other BSPs. > > > > In meta-ti BSP we've been updating OPTEE (and TF-A to a lesser extent) > > regularly to the very latest release and often ahead of meta-arm, even though > > meta-arm is upstream to meta-ti for those components - usually latest versions > > add new features or new platform support. TI policy for OPTEE and TF-A is to > > work directly with upstream and hence there are no local patches. > > Please send patches when there is the delta you describe. Or, let me > know and I'll do the patches. I try to stay on top of the latest > releases as they come out, but sometimes I don't notice for a bit. > > > I was wondering how ARM reference platforms in meta-arm-bsp and platforms in > > other BSPs handle this and whether there's extra work required updating local > > patches or adaptations for regular version bumps. If OPTEE and TF-A go to > > oe-core, would that negatively affect meta-arm? > > It is not known by me who needs the latest versions of the packages in > a cadence more frequent than what has been occurring. To my > knowledge, meta-arm always has the latest version when the releases > are cut. If this is not the case, please do hold me accountable. Jon, Version 3.20.0 of all the OPTEE components was released in January, but only optee-os got updated in meta-arm. Other components like optee-os-tadevkit, optee-client, optee-test and optee-examples were 2 versions behind on 3.18.0. Patches are submitted here: https://patchwork.yoctoproject.org/project/arm/list/?series=11813 Most of these updated components were tested on TI platforms, build-tested on qemuarm64 and qemuarm64-secureboot, so let me know if you see any issues.
On Wed, Apr 05, 2023 at 07:20:20PM +0000, Ross Burton wrote: > On 5 Apr 2023, at 20:13, Jon Mason <jdmason@kudzu.us> wrote: > > > >> At the TSC meetings recently we've discussed the possibility of migrating > >> Trusted Firmware and OP-TEE components from meta-arm to oe-core in order to > >> reduce dependencies on these core components by other BSPs. > > My opinion here is that in the ideal world a generic-arm64 BSP wouldn’t need > anything extra in oe-core to work: assume working firmware (SystemReady), > mainline kernel, mainline U-Boot, etc and it will work. It may not be as > fully functional as you’d get by adding custom optee/tf pieces but that’s > where meta-arm steps in, which was designed explicitly to be BSP-agnostic. Understood and agree. I'm not yet that much familiar with SystemReady firmware specifics - does that include Trusted Firmware? Not so sure about OP-TEE, but what does the spec say about it?
On 6 Apr 2023, at 00:44, Denys Dmytriyenko <denis@denix.org> wrote: > > On Wed, Apr 05, 2023 at 07:20:20PM +0000, Ross Burton wrote: >> On 5 Apr 2023, at 20:13, Jon Mason <jdmason@kudzu.us> wrote: >>> >>>> At the TSC meetings recently we've discussed the possibility of migrating >>>> Trusted Firmware and OP-TEE components from meta-arm to oe-core in order to >>>> reduce dependencies on these core components by other BSPs. >> >> My opinion here is that in the ideal world a generic-arm64 BSP wouldn’t need >> anything extra in oe-core to work: assume working firmware (SystemReady), >> mainline kernel, mainline U-Boot, etc and it will work. It may not be as >> fully functional as you’d get by adding custom optee/tf pieces but that’s >> where meta-arm steps in, which was designed explicitly to be BSP-agnostic. > > Understood and agree. I'm not yet that much familiar with SystemReady firmware > specifics - does that include Trusted Firmware? Not so sure about OP-TEE, but > what does the spec say about it? The very short version is that from userspace you can assume UEFI (the embedded band is more flexible though). How that happens isn’t really relevant, but it means that for generic-arm64 we get to ignore the problem, like we ignore firmware on x86 targets. Ross
On 4/6/23 3:29 AM, Ross Burton wrote: > On 6 Apr 2023, at 00:44, Denys Dmytriyenko <denis@denix.org> wrote: >> On Wed, Apr 05, 2023 at 07:20:20PM +0000, Ross Burton wrote: >>> On 5 Apr 2023, at 20:13, Jon Mason <jdmason@kudzu.us> wrote: >>>>> At the TSC meetings recently we've discussed the possibility of migrating >>>>> Trusted Firmware and OP-TEE components from meta-arm to oe-core in order to >>>>> reduce dependencies on these core components by other BSPs. >>> My opinion here is that in the ideal world a generic-arm64 BSP wouldn’t need >>> anything extra in oe-core to work: assume working firmware (SystemReady), >>> mainline kernel, mainline U-Boot, etc and it will work. It may not be as >>> fully functional as you’d get by adding custom optee/tf pieces but that’s >>> where meta-arm steps in, which was designed explicitly to be BSP-agnostic. >> Understood and agree. I'm not yet that much familiar with SystemReady firmware >> specifics - does that include Trusted Firmware? Not so sure about OP-TEE, but >> what does the spec say about it? > The very short version is that from userspace you can assume UEFI (the embedded band is more flexible though). How that happens isn’t really relevant, but it means that for generic-arm64 we get to ignore the problem, like we ignore firmware on x86 targets. Is there any reason to treat op-tee differently than u-boot? If Op-tee where in core, would that help anything ? V86d is in core and its X86 only. Why are we treating Arm differently? Uncle Armin > > Ross > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#1542): https://lists.yoctoproject.org/g/tsc/message/1542 > Mute This Topic: https://lists.yoctoproject.org/mt/98084362/3616698 > Group Owner: tsc+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/tsc/unsub [akuster808@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On 6 Apr 2023, at 18:39, akuster808 <akuster808@gmail.com> wrote: >> The very short version is that from userspace you can assume UEFI (the embedded band is more flexible though). How that happens isn’t really relevant, but it means that for generic-arm64 we get to ignore the problem, like we ignore firmware on x86 targets. > > Is there any reason to treat op-tee differently than u-boot? If Op-tee where in core, would that help anything ? V86d is in core and its X86 only. Why are we treating Arm differently? v86d is a dependency of the qemux86 machines, so appears to be needed there (this may not actually be the case). U-Boot is a generic bootloader for multiple architectures. There is also a difference between meta-intel and meta-arm. meta-intel contains BSPs for Intel boards, whereas meta-arm contains generic Arm-specific components. Speaking as a meta-arm maintainer I like being able to, for example, carry three versions of optee because different BSPs have different release cadences. We want to have it down to one, but that’s not always realistic. But this is a digression. I don’t believe a recipe for optee would be _needed_ to boot a SystemReady board. The point of SystemReady is that the firmware is a known quantity and verified to be reasonable. Ross
diff --git a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappend b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappend index 9a210832..6a22d47e 100644 --- a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappend +++ b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.18.0.bbappend @@ -2,6 +2,5 @@ MACHINE_OPTEE_OS_TADEVKIT_REQUIRE ?= "" MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:tc = "optee-os-generic-tc.inc" -MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:n1sdp = "optee-os-n1sdp.inc" require ${MACHINE_OPTEE_OS_TADEVKIT_REQUIRE} diff --git a/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappend b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappend new file mode 100644 index 00000000..e09c4a5e --- /dev/null +++ b/meta-arm-bsp/recipes-security/optee/optee-os-tadevkit_3.20.0.bbappend @@ -0,0 +1,6 @@ +# Machine specific configurations + +MACHINE_OPTEE_OS_TADEVKIT_REQUIRE ?= "" +MACHINE_OPTEE_OS_TADEVKIT_REQUIRE:n1sdp = "optee-os-n1sdp.inc" + +require ${MACHINE_OPTEE_OS_TADEVKIT_REQUIRE} diff --git a/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb b/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb new file mode 100644 index 00000000..202caa54 --- /dev/null +++ b/meta-arm/recipes-security/optee/optee-os-tadevkit_3.20.0.bb @@ -0,0 +1,24 @@ +require optee-os_3.20.0.bb + +SUMMARY = "OP-TEE Trusted OS TA devkit" +DESCRIPTION = "OP-TEE TA devkit for build TAs" +HOMEPAGE = "https://www.op-tee.org/" + +DEPENDS += "python3-pycryptodome-native" + +do_install() { + #install TA devkit + install -d ${D}${includedir}/optee/export-user_ta/ + for f in ${B}/export-ta_${OPTEE_ARCH}/* ; do + cp -aR $f ${D}${includedir}/optee/export-user_ta/ + done +} + +do_deploy() { + echo "Do not inherit do_deploy from optee-os." +} + +FILES:${PN} = "${includedir}/optee/" + +# Build paths are currently embedded +INSANE_SKIP:${PN}-dev += "buildpaths"