| Message ID | 20221221143942.15196-6-emekcan.aras@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add optee-os 3.19 recipe | expand |
On Wed, 21 Dec 2022 at 20:10, <emekcan.aras@arm.com> wrote: > > From: Emekcan Aras <emekcan.aras@arm.com> > > There is a new optee version 3.19. Currently, qemuarm-secureboot cannot boot > optee 3.19 out-of-the-box. This sounds strange since Qemu is regularly tested in OP-TEE build CI as well as 3.19 release [1]. Is it really an OP-TEE related issue? Can you share details of the boot error you are observing? [1] https://github.com/OP-TEE/optee_os/commit/afacf356f9593a7f83cae9f96026824ec242ff52 -Sumit > This pins optee-os version to 3.18 for > qemuarm-secureboot. > > Signed-off-by: Emekcan Aras <emekcan.aras@arm.com> > --- > meta-arm/conf/machine/qemuarm-secureboot.conf | 3 +++ > meta-arm/conf/machine/qemuarm64-secureboot.conf | 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/meta-arm/conf/machine/qemuarm-secureboot.conf b/meta-arm/conf/machine/qemuarm-secureboot.conf > index f08b84fe..db02dc68 100644 > --- a/meta-arm/conf/machine/qemuarm-secureboot.conf > +++ b/meta-arm/conf/machine/qemuarm-secureboot.conf > @@ -21,3 +21,6 @@ WKS_FILE_DEPENDS = "trusted-firmware-a" > IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE}" > > MACHINE_FEATURES += "optee-ftpm" > + > +PREFERRED_VERSION_optee-os ?= "3.18.%" > + > diff --git a/meta-arm/conf/machine/qemuarm64-secureboot.conf b/meta-arm/conf/machine/qemuarm64-secureboot.conf > index 55c4cab4..7277817d 100644 > --- a/meta-arm/conf/machine/qemuarm64-secureboot.conf > +++ b/meta-arm/conf/machine/qemuarm64-secureboot.conf > @@ -23,3 +23,6 @@ WKS_FILE_DEPENDS = "trusted-firmware-a" > IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE}" > > MACHINE_FEATURES += "optee-ftpm" > + > +PREFERRED_VERSION_optee-os ?= "3.18.%" > + > -- > 2.17.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#4220): https://lists.yoctoproject.org/g/meta-arm/message/4220 > Mute This Topic: https://lists.yoctoproject.org/mt/95807186/1777089 > Group Owner: meta-arm+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub [sumit.garg@linaro.org] > -=-=-=-=-=-=-=-=-=-=-=- >
On Wed, 21 Dec 2022 at 21:29, Emekcan Aras <Emekcan.Aras@arm.com> wrote: > > > > ________________________________ > From: Sumit Garg <sumit.garg@linaro.org> > Sent: Wednesday, December 21, 2022 3:37 PM > To: Emekcan Aras <Emekcan.Aras@arm.com> > Cc: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org>; Ross Burton <Ross.Burton@arm.com>; Jon Mason <Jon.Mason@arm.com>; nd <nd@arm.com> > Subject: Re: [meta-arm] [PATCH 5/5] arm/qemuarm-secureboot: pin optee-os version > > On Wed, 21 Dec 2022 at 20:10, <emekcan.aras@arm.com> wrote: > > > > From: Emekcan Aras <emekcan.aras@arm.com> > > > > There is a new optee version 3.19. Currently, qemuarm-secureboot cannot boot > > optee 3.19 out-of-the-box. > > This sounds strange since Qemu is regularly tested in OP-TEE build CI > as well as 3.19 release [1]. Is it really an OP-TEE related issue? Can > you share details of the boot error you are observing? > > [1] https://github.com/OP-TEE/optee_os/commit/afacf356f9593a7f83cae9f96026824ec242ff52 > > -Sumit > > 2022-12-21 11:33:27 - INFO - E/TC:0 0 Panic 'Failed mapping FIP SPs' at core/arch/arm/kernel/secure_partition.c:1223 <sp_init_all> This file won't even compile if CFG_SECURE_PARTITION=n which is the default configuration. So how does it get enabled for Qemu using OP-TEE 3.19? > 2022-12-21 11:33:27 - INFO - E/TC:0 0 TEE load address @ 0xcf412000 > 2022-12-21 11:33:27 - INFO - E/TC:0 0 Call stack: > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf41eb3c > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf42bafc > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf41bd4c > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf42d548 > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf41e268 > 2022-12-21 11:33:27 - INFO - runqemu - INFO - SIGTERM received > 2022-12-21 11:33:27 - INFO - runqemu - INFO - Cleaning up > 2022-12-21 11:33:27 - INFO - runqemu - INFO - Host uptime: 1436.86 > 2022-12-21 11:33:27 - INFO - > 2022-12-21 11:33:27 - INFO - tput: No value for $TERM and no -T specified > 2022-12-21 11:33:27 - INFO - tput: No value for $TERM and no -T specified > > This is the error message. We also have the same issue for n1sdp since the new optee is looking for an SP manifest in FIP.. AFAIK, secure partitions are not enabled by default in OP-TEE. So how does that get enabled for Qemu? Also, I can see from your patch-set that you enable secure partitions explicitly for n1sdp. > Need to create a bbappend or an inc file for qemuarm-secureboot as well where the necessary flags are set. Just left it for now since there are other platforms that use optee 3.18 version. I think this can be fixed relatively easily when all the platforms upgrades to 3.19. I would suggest that we update Qemu as part of OP-TEE uprev as that is something which others could test as well as something that can be tested in CI as well. -Sumit > > -Emek > > > This pins optee-os version to 3.18 for > > qemuarm-secureboot. > > > > Signed-off-by: Emekcan Aras <emekcan.aras@arm.com> > > --- > > meta-arm/conf/machine/qemuarm-secureboot.conf | 3 +++ > > meta-arm/conf/machine/qemuarm64-secureboot.conf | 3 +++ > > 2 files changed, 6 insertions(+) > > > > diff --git a/meta-arm/conf/machine/qemuarm-secureboot.conf b/meta-arm/conf/machine/qemuarm-secureboot.conf > > index f08b84fe..db02dc68 100644 > > --- a/meta-arm/conf/machine/qemuarm-secureboot.conf > > +++ b/meta-arm/conf/machine/qemuarm-secureboot.conf > > @@ -21,3 +21,6 @@ WKS_FILE_DEPENDS = "trusted-firmware-a" > > IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE}" > > > > MACHINE_FEATURES += "optee-ftpm" > > + > > +PREFERRED_VERSION_optee-os ?= "3.18.%" > > + > > diff --git a/meta-arm/conf/machine/qemuarm64-secureboot.conf b/meta-arm/conf/machine/qemuarm64-secureboot.conf > > index 55c4cab4..7277817d 100644 > > --- a/meta-arm/conf/machine/qemuarm64-secureboot.conf > > +++ b/meta-arm/conf/machine/qemuarm64-secureboot.conf > > @@ -23,3 +23,6 @@ WKS_FILE_DEPENDS = "trusted-firmware-a" > > IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE}" > > > > MACHINE_FEATURES += "optee-ftpm" > > + > > +PREFERRED_VERSION_optee-os ?= "3.18.%" > > + > > -- > > 2.17.1 > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#4220): https://lists.yoctoproject.org/g/meta-arm/message/4220 > > Mute This Topic: https://lists.yoctoproject.org/mt/95807186/1777089 > > Group Owner: meta-arm+owner@lists.yoctoproject.org > > Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub [sumit.garg@linaro.org] > > -=-=-=-=-=-=-=-=-=-=-=- > >
From: Sumit Garg <sumit.garg@linaro.org> Sent: Thursday, December 22, 2022 6:48 AM To: Emekcan Aras <Emekcan.Aras@arm.com> Cc: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org>; Ross Burton <Ross.Burton@arm.com>; Jon Mason <Jon.Mason@arm.com>; nd <nd@arm.com> Subject: Re: [meta-arm] [PATCH 5/5] arm/qemuarm-secureboot: pin optee-os version On Wed, 21 Dec 2022 at 21:29, Emekcan Aras <Emekcan.Aras@arm.com> wrote: > > > > ________________________________ > From: Sumit Garg <sumit.garg@linaro.org> > Sent: Wednesday, December 21, 2022 3:37 PM > To: Emekcan Aras <Emekcan.Aras@arm.com> > Cc: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org>; Ross Burton <Ross.Burton@arm.com>; Jon Mason <Jon.Mason@arm.com>; nd <nd@arm.com> > Subject: Re: [meta-arm] [PATCH 5/5] arm/qemuarm-secureboot: pin optee-os version > > On Wed, 21 Dec 2022 at 20:10, <emekcan.aras@arm.com> wrote: > > > > From: Emekcan Aras <emekcan.aras@arm.com> > > > > There is a new optee version 3.19. Currently, qemuarm-secureboot cannot boot > > optee 3.19 out-of-the-box. > > This sounds strange since Qemu is regularly tested in OP-TEE build CI > as well as 3.19 release [1]. Is it really an OP-TEE related issue? Can > you share details of the boot error you are observing? > > [1] https://github.com/OP-TEE/optee_os/commit/afacf356f9593a7f83cae9f96026824ec242ff52 > > -Sumit > > 2022-12-21 11:33:27 - INFO - E/TC:0 0 Panic 'Failed mapping FIP SPs' at core/arch/arm/kernel/secure_partition.c:1223 <sp_init_all> This file won't even compile if CFG_SECURE_PARTITION=n which is the default configuration. So how does it get enabled for Qemu using OP-TEE 3.19? I don't know. I saw that you've developed the qemu recipes. So hoping that you might answered this :) Maybe optee 3.19 set this explicitly. This patchset was already reviewed by maintainers actually and ran on different platforms. It could be related to the recipe as well, but as you can see I'm not doing anything complicated there. > 2022-12-21 11:33:27 - INFO - E/TC:0 0 TEE load address @ 0xcf412000 > 2022-12-21 11:33:27 - INFO - E/TC:0 0 Call stack: > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf41eb3c > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf42bafc > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf41bd4c > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf42d548 > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf41e268 > 2022-12-21 11:33:27 - INFO - runqemu - INFO - SIGTERM received > 2022-12-21 11:33:27 - INFO - runqemu - INFO - Cleaning up > 2022-12-21 11:33:27 - INFO - runqemu - INFO - Host uptime: 1436.86 > 2022-12-21 11:33:27 - INFO - > 2022-12-21 11:33:27 - INFO - tput: No value for $TERM and no -T specified > 2022-12-21 11:33:27 - INFO - tput: No value for $TERM and no -T specified > > This is the error message. We also have the same issue for n1sdp since the new optee is looking for an SP manifest in FIP.. AFAIK, secure partitions are not enabled by default in OP-TEE. So how does that get enabled for Qemu? Also, I can see from your patch-set that you enable secure partitions explicitly for n1sdp. > Need to create a bbappend or an inc file for qemuarm-secureboot as well where the necessary flags are set. Just left it for now since there are other platforms that use optee 3.18 version. I think this can be fixed relatively easily when all the platforms upgrades to 3.19. I would suggest that we update Qemu as part of OP-TEE uprev as that is something which others could test as well as something that can be tested in CI as well. I kindly disagree with this :) Normally, there is always an uprev work for components every now and then. Someone pushes a new recipe for the new version and if any platform fails, Maintainers ask platform-maintainers to fix it. At least that's our experience on corstone1000 and it makes sense, to be honest. I think optee uprev work and upgrading other platforms should go separately if it doesn't work out-of-the-box. I.E. Next month, I'll update corstone1000 to optee 3.19, because it doesn't work quite right with the new version. However, this is not related to the new recipe, it's rather related to configurations. -Sumit > > -Emek > > > This pins optee-os version to 3.18 for > > qemuarm-secureboot. > > > > Signed-off-by: Emekcan Aras <emekcan.aras@arm.com> > > --- > > meta-arm/conf/machine/qemuarm-secureboot.conf | 3 +++ > > meta-arm/conf/machine/qemuarm64-secureboot.conf | 3 +++ > > 2 files changed, 6 insertions(+) > > > > diff --git a/meta-arm/conf/machine/qemuarm-secureboot.conf b/meta-arm/conf/machine/qemuarm-secureboot.conf > > index f08b84fe..db02dc68 100644 > > --- a/meta-arm/conf/machine/qemuarm-secureboot.conf > > +++ b/meta-arm/conf/machine/qemuarm-secureboot.conf > > @@ -21,3 +21,6 @@ WKS_FILE_DEPENDS = "trusted-firmware-a" > > IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE}" > > > > MACHINE_FEATURES += "optee-ftpm" > > + > > +PREFERRED_VERSION_optee-os ?= "3.18.%" > > + > > diff --git a/meta-arm/conf/machine/qemuarm64-secureboot.conf b/meta-arm/conf/machine/qemuarm64-secureboot.conf > > index 55c4cab4..7277817d 100644 > > --- a/meta-arm/conf/machine/qemuarm64-secureboot.conf > > +++ b/meta-arm/conf/machine/qemuarm64-secureboot.conf > > @@ -23,3 +23,6 @@ WKS_FILE_DEPENDS = "trusted-firmware-a" > > IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE}" > > > > MACHINE_FEATURES += "optee-ftpm" > > + > > +PREFERRED_VERSION_optee-os ?= "3.18.%" > > + > > -- > > 2.17.1 > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#4220): https://lists.yoctoproject.org/g/meta-arm/message/4220 > > Mute This Topic: https://lists.yoctoproject.org/mt/95807186/1777089 > > Group Owner: meta-arm+owner@lists.yoctoproject.org > > Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub [sumit.garg@linaro.org] > > -=-=-=-=-=-=-=-=-=-=-=- > >
On Thu, 22 Dec 2022 at 14:12, Emekcan Aras <emekcan.aras@arm.com> wrote: > > From: Sumit Garg <sumit.garg@linaro.org> > Sent: Thursday, December 22, 2022 6:48 AM > To: Emekcan Aras <Emekcan.Aras@arm.com> > Cc: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org>; Ross Burton <Ross.Burton@arm.com>; Jon Mason <Jon.Mason@arm.com>; nd <nd@arm.com> > Subject: Re: [meta-arm] [PATCH 5/5] arm/qemuarm-secureboot: pin optee-os version > > On Wed, 21 Dec 2022 at 21:29, Emekcan Aras <Emekcan.Aras@arm.com> wrote: > > > > > > > > ________________________________ > > From: Sumit Garg <sumit.garg@linaro.org> > > Sent: Wednesday, December 21, 2022 3:37 PM > > To: Emekcan Aras <Emekcan.Aras@arm.com> > > Cc: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org>; Ross Burton <Ross.Burton@arm.com>; Jon Mason <Jon.Mason@arm.com>; nd <nd@arm.com> > > Subject: Re: [meta-arm] [PATCH 5/5] arm/qemuarm-secureboot: pin optee-os version > > > > On Wed, 21 Dec 2022 at 20:10, <emekcan.aras@arm.com> wrote: > > > > > > From: Emekcan Aras <emekcan.aras@arm.com> > > > > > > There is a new optee version 3.19. Currently, qemuarm-secureboot cannot boot > > > optee 3.19 out-of-the-box. > > > > This sounds strange since Qemu is regularly tested in OP-TEE build CI > > as well as 3.19 release [1]. Is it really an OP-TEE related issue? Can > > you share details of the boot error you are observing? > > > > [1] https://github.com/OP-TEE/optee_os/commit/afacf356f9593a7f83cae9f96026824ec242ff52 > > > > -Sumit > > > > 2022-12-21 11:33:27 - INFO - E/TC:0 0 Panic 'Failed mapping FIP SPs' at core/arch/arm/kernel/secure_partition.c:1223 <sp_init_all> > > This file won't even compile if CFG_SECURE_PARTITION=n which is the > default configuration. So how does it get enabled for Qemu using > OP-TEE 3.19? > > I don't know. I saw that you've developed the qemu recipes. So hoping that you might answered this :) > Maybe optee 3.19 set this explicitly. This patchset was already reviewed by maintainers actually and ran on different platforms. > It could be related to the recipe as well, but as you can see I'm not doing anything complicated there. > > > 2022-12-21 11:33:27 - INFO - E/TC:0 0 TEE load address @ 0xcf412000 > > 2022-12-21 11:33:27 - INFO - E/TC:0 0 Call stack: > > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf41eb3c > > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf42bafc > > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf41bd4c > > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf42d548 > > 2022-12-21 11:33:27 - INFO - E/TC:0 0 0xcf41e268 > > 2022-12-21 11:33:27 - INFO - runqemu - INFO - SIGTERM received > > 2022-12-21 11:33:27 - INFO - runqemu - INFO - Cleaning up > > 2022-12-21 11:33:27 - INFO - runqemu - INFO - Host uptime: 1436.86 > > 2022-12-21 11:33:27 - INFO - > > 2022-12-21 11:33:27 - INFO - tput: No value for $TERM and no -T specified > > 2022-12-21 11:33:27 - INFO - tput: No value for $TERM and no -T specified > > > > This is the error message. We also have the same issue for n1sdp since the new optee is looking for an SP manifest in FIP.. > > AFAIK, secure partitions are not enabled by default in OP-TEE. So how > does that get enabled for Qemu? Also, I can see from your patch-set > that you enable secure partitions explicitly for n1sdp. > > > Need to create a bbappend or an inc file for qemuarm-secureboot as well where the necessary flags are set. Just left it for now since there are other platforms that use optee 3.18 version. I think this can be fixed relatively easily when all the platforms upgrades to 3.19. > > I would suggest that we update Qemu as part of OP-TEE uprev as that is > something which others could test as well as something that can be > tested in CI as well. > > I kindly disagree with this :) Normally, there is always an uprev work for components every now and then. The general practice is to bump up the component's version rather than supporting multiple versions. If any bsp layer like meta-arm-bsp has a different need for a component version then it can stick to an older version and migrate later. > Someone pushes a new recipe for the new version and if any platform fails, Maintainers ask platform-maintainers to fix it. Qemu support is part of the meta-arm layer which has the OP-TEE recipes too, see: $ ls meta-arm/conf/machine/ generic-arm64.conf qemuarm64-secureboot.conf qemuarm-secureboot.conf qemu-generic-arm64.conf So I would leave it upto meta-arm maintainers to decide here. -Sumit > At least that's our experience on corstone1000 and it makes sense, to be honest. I think optee uprev work and upgrading other platforms should go separately if it doesn't work out-of-the-box. I.E. Next month, I'll update corstone1000 to optee 3.19, because it doesn't work quite right with the new version. However, this is not related to the new recipe, it's rather related to configurations. > > -Sumit > > > > > -Emek > > > > > This pins optee-os version to 3.18 for > > > qemuarm-secureboot. > > > > > > Signed-off-by: Emekcan Aras <emekcan.aras@arm.com> > > > --- > > > meta-arm/conf/machine/qemuarm-secureboot.conf | 3 +++ > > > meta-arm/conf/machine/qemuarm64-secureboot.conf | 3 +++ > > > 2 files changed, 6 insertions(+) > > > > > > diff --git a/meta-arm/conf/machine/qemuarm-secureboot.conf b/meta-arm/conf/machine/qemuarm-secureboot.conf > > > index f08b84fe..db02dc68 100644 > > > --- a/meta-arm/conf/machine/qemuarm-secureboot.conf > > > +++ b/meta-arm/conf/machine/qemuarm-secureboot.conf > > > @@ -21,3 +21,6 @@ WKS_FILE_DEPENDS = "trusted-firmware-a" > > > IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE}" > > > > > > MACHINE_FEATURES += "optee-ftpm" > > > + > > > +PREFERRED_VERSION_optee-os ?= "3.18.%" > > > + > > > diff --git a/meta-arm/conf/machine/qemuarm64-secureboot.conf b/meta-arm/conf/machine/qemuarm64-secureboot.conf > > > index 55c4cab4..7277817d 100644 > > > --- a/meta-arm/conf/machine/qemuarm64-secureboot.conf > > > +++ b/meta-arm/conf/machine/qemuarm64-secureboot.conf > > > @@ -23,3 +23,6 @@ WKS_FILE_DEPENDS = "trusted-firmware-a" > > > IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE}" > > > > > > MACHINE_FEATURES += "optee-ftpm" > > > + > > > +PREFERRED_VERSION_optee-os ?= "3.18.%" > > > + > > > -- > > > 2.17.1 > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#4224): https://lists.yoctoproject.org/g/meta-arm/message/4224 > Mute This Topic: https://lists.yoctoproject.org/mt/95807186/1777089 > Group Owner: meta-arm+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub [sumit.garg@linaro.org] > -=-=-=-=-=-=-=-=-=-=-=- >
On 23 Dec 2022, at 05:47, Sumit Garg <sumit.garg@linaro.org> wrote: > > Qemu support is part of the meta-arm layer which has the OP-TEE > recipes too, see: > > $ ls meta-arm/conf/machine/ > generic-arm64.conf qemuarm64-secureboot.conf qemuarm-secureboot.conf > qemu-generic-arm64.conf > > So I would leave it upto meta-arm maintainers to decide here. I’m definitely no optee expert, but I’d much prefer it if qemuarm64-secureboot was fixed instead of left on the old release. As there’s no hardware requirement and runqemu works it should be easy to test for someone who knows what the problem actually is. Ross
diff --git a/meta-arm/conf/machine/qemuarm-secureboot.conf b/meta-arm/conf/machine/qemuarm-secureboot.conf index f08b84fe..db02dc68 100644 --- a/meta-arm/conf/machine/qemuarm-secureboot.conf +++ b/meta-arm/conf/machine/qemuarm-secureboot.conf @@ -21,3 +21,6 @@ WKS_FILE_DEPENDS = "trusted-firmware-a" IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE}" MACHINE_FEATURES += "optee-ftpm" + +PREFERRED_VERSION_optee-os ?= "3.18.%" + diff --git a/meta-arm/conf/machine/qemuarm64-secureboot.conf b/meta-arm/conf/machine/qemuarm64-secureboot.conf index 55c4cab4..7277817d 100644 --- a/meta-arm/conf/machine/qemuarm64-secureboot.conf +++ b/meta-arm/conf/machine/qemuarm64-secureboot.conf @@ -23,3 +23,6 @@ WKS_FILE_DEPENDS = "trusted-firmware-a" IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE}" MACHINE_FEATURES += "optee-ftpm" + +PREFERRED_VERSION_optee-os ?= "3.18.%" +