Yocto Kirkstone support

[iknerfS]

Dear meta-updater team,

I am just asking when do you plan to add kirkstone support?

Thanks for the answer, Frenk

[pattivacek]

Kirkstone is supported in the uptane namespace. FYI I'm not sure if anyone is maintaining the repo in this namespace anymore. See also #825.

FYI I currently still only use dunfell, so if you want substantive support for other branches, you'll need to appeal to others for help. There are a number of people using kirkstone, just not me.

[iknerfS]

Thanks you very much for the answer. We are using kirkstone so I need to make it work somehow.

How do you mean by others? You mean other team members that are working on meta-updater?

I am still reading and trying to understand this meta-updater. I also see that my cpu iMX8M nano is not supported and need to add the support. Any advices are recommended.

[pattivacek]

How do you mean by others? You mean other team members that are working on meta-updater?

The original team that created this repo no longer exists. I happen to still use this layer in my current employment, but I use the Uptane version. There are other people at other companies, and perhaps some hobbyists, who use kirkstone and possibly other branches. It's a pretty loose network because the layer generally doesn't need a lot of maintenance. You can try to ask for help there, but I personally can't offer much.

I also see that my cpu iMX8M nano is not supported and need to add the support. Any advices are recommended.

You might not need to do much to support it, but there's usually some work to be done to get your bootloader compatible. I recommend checking out some of the BSP work for other boards (some of that is in this repo, some is in other, related repos) to get an idea of what might necessary if it doesn't work out of the box.

[iknerfS]

Again thank you very much for so quick answer and very helpful information.

Are you sure kirkstone is supported? As from the comments I read there is not yet supported or did I miss something?

[pattivacek]

Are you sure kirkstone is supported?

Yes, to the extent that there's a branch for it. Others are using it, including for production purposes, to my understanding. See for example the Foundries documentation here and here, although the link in their docs still points to this namespace. (@ricardosalveti I think you've moved to the Uptane namspace; if so, can you update that link?)

If you're going off of the Here documentation, it's a bit stale at this point. They haven't kept up with the changes in the Uptane namespace, presumably because their customers aren't interested the features and branches we've added since the split. I'm not interested in updating documentation for a proprietary service offered by a company I don't work for anymore, but I can tell you that the open-source software that their product and documentation is based on has continued to evolve in the meantime.

[ricardosalveti]

Yes, to the extent that there's a branch for it. Others are using it, including for production purposes, to my understanding. See for example the Foundries documentation here and here, although the link in their docs still points to this namespace. (@ricardosalveti I think you've moved to the Uptane namspace; if so, can you update that link?)

It is indeed wrong there, thanks for the pointer, will update the doc.

[ricardosalveti]

Thanks you very much for the answer. We are using kirkstone so I need to make it work somehow.

How do you mean by others? You mean other team members that are working on meta-updater?

We (Foundries) are using kirkstone with the meta-updater from the Uptane repos, and it is well supported there.

I am still reading and trying to understand this meta-updater. I also see that my cpu iMX8M nano is not supported and need to add the support. Any advices are recommended.

This would depend on your distro and BSP used, but we also added support for nano as part of our latest distro release (foundriesio/meta-lmp#777). Have a look at our docs as well (https://docs.foundries.io/latest/), our service is well integrated with meta-updater, but we use aktualizr-lite instead.

[iknerfS]

As again thanks you both for such quick response and all the useful information.

[iknerfS]

Thanks you very much for the answer. We are using kirkstone so I need to make it work somehow.
How do you mean by others? You mean other team members that are working on meta-updater?

We (Foundries) are using kirkstone with the meta-updater from the Uptane repos, and it is well supported there.

I am still reading and trying to understand this meta-updater. I also see that my cpu iMX8M nano is not supported and need to add the support. Any advices are recommended.

This would depend on your distro and BSP used, but we also added support for nano as part of our latest distro release (foundriesio/meta-lmp#777). Have a look at our docs as well (https://docs.foundries.io/latest/), our service is well integrated with meta-updater, but we use aktualizr-lite instead.

I am now reading the provided documentation to get familiar with everything.

We have some customized BSP where we are trying first to make FIT image working (we can load it, but after that we get error invalid image). In your case I see you have everything under the meta-lmp. Will also check this aktualizr-lite.

[iknerfS]

Are you sure kirkstone is supported?

Yes, to the extent that there's a branch for it. Others are using it, including for production purposes, to my understanding. See for example the Foundries documentation here and here, although the link in their docs still points to this namespace. (@ricardosalveti I think you've moved to the Uptane namspace; if so, can you update that link?)

If you're going off of the Here documentation, it's a bit stale at this point. They haven't kept up with the changes in the Uptane namespace, presumably because their customers aren't interested the features and branches we've added since the split. I'm not interested in updating documentation for a proprietary service offered by a company I don't work for anymore, but I can tell you that the open-source software that their product and documentation is based on has continued to evolve in the meantime.

Hello Patti,

Thank you for all the excellent explanation. I was busy with some other tasks and now started with the ostree. I hope I dont bother you too much, but as I am new to all this I still dont fully understand how to integrate the ostree. I also dont know if there is some other mean of the communication than using this issues tab, so I also apologize for this.

I am looking into the old ota here documentation and for a test just added uptane/meta-updater and tried to compile it. The build is failing with as it seems I am missing some checksum for the ostree.git. I will try to solve the problem, but as the raspberry pi is from the older branch, I dont see kirkstone support there. Also ota here docs is as you mention outdated, so I dont know if all the steps there are valid. I checked updane README, but links pointed to the ota here docs. I am now reading ostree docs to somehow find the missing puzzles how to put everything together. I really appreciate for any steps what is minimum required to add ostree.

Thank you very much, Frenk

[pattivacek]

The build is failing with as it seems I am missing some checksum for the ostree.git.

That's strange. These days the main OSTree recipe lives in meta-openembedded, so meta-updater just builds on top of that.

as the raspberry pi is from the older branch, I dont see kirkstone support there.

Yes, if you mean meta-updater-raspberrypi, you are correct. You can probably get away with using master there, but that's pretty unmaintained these days. I was hoping it'd just work, but I can't guarantee anything, and I don't have capacity to actively support it.

Also ota here docs is as you mention outdated, so I dont know if all the steps there are valid.

I would expect them to work just fine with dunfell, since last I knew that was the last branch they officially supported, but it's true, it might be trickier with kirkstone. I don't know; I haven't used kirkstone myself yet!

I checked updane README, but links pointed to the ota here docs.

Yeah, not ideal, I know. They still have some of the best docs around for meta-updater, and I mean the source of the docs is all open-source, too (they also live in the aktualizr repo). Foundries and Toradex both have related docs as well which might be fresher. But anyway, even if someone did update the docs in the uptane namespace, the meaning of "support" has changed. Here Technologies used the word to mean that if you were a paying customer, we'd fix bugs for you. The Uptane organization cannot offer that level of support, so as far as I'm concerned that word now just means "someone is using it and if you're lucky they might respond to requests for help".

I really appreciate for any steps what is minimum required to add ostree.

I can't really offer anything better than https://docs.ota.here.com/ota-client/latest/add-ota-functonality-existing-yocto-project.html. You don't need much to get it to work on your device. That said, you will need a backend, and rolling your own can be difficult. There is a project underway to improve the OTA Community Edition to do exactly that. Your other option is to use one of the commercial providers. Foundries or Toradex are the choices I'm aware of. I doubt Here would be interested anymore.

[iknerfS]

The build is failing with as it seems I am missing some checksum for the ostree.git.

That's strange. These days the main OSTree recipe lives in meta-openembedded, so meta-updater just builds on top of that.

I summarize what I did.

    My environment:
    Ubunt 18.04 and using yocto Kirkstone and am building for the imx8m nano.
    
    What I did is following:
    Added to bblayers.conf: BBLAYERS += "${BSPDIR}/sources/meta-updater"
    Added to local.conf: 
    INHERIT += " sota"
    DISTRO_FEATURES_append = " sota systemd usrmerge"
    
    Added into the ostree_2021.1.bb following to fix the CRC problem:
    SRC_URI[sha256sum] = "cd6f17458ec805cf7c1eda3da68fd11ad9925554d3548eb90ae89259bf786005"

But the build is still failing with optee-os Fatal QA error.

Maybe a stupid question, but do I need to also customize it for the imx8mn even if I am not yet using any part of the meta-updater? I would first like to see if this is at least building before customizing it for imx8mn board.

Thanks for any hints, Frenk

[ricardosalveti]

But the build is still failing with optee-os Fatal QA error.

What is the error here? It might be due usrmerge, or just another generic issue.

Maybe a stupid question, but do I need to also customize it for the imx8mn even if I am not yet using any part of the meta-updater? I would first like to see if this is at least building before customizing it for imx8mn board.

It should build fine without extra customizations, but won't necessarily boot correctly (as the ostree setup implies a different boot command logic, for example).

[iknerfS]

But the build is still failing with optee-os Fatal QA error.

What is the error here? It might be due usrmerge, or just another generic issue.

I get following error:

ERROR: optee-os-3.17.0.imx-r0 do_package: QA Issue: optee-os: Files/directories were installed but not shipped in any package:
  /usr/lib/optee_armtz
  /usr/lib/optee_armtz/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.ta
  /usr/lib/optee_armtz/fd02c9da-306c-48c7-a49c-bbd827ae86ee.ta
  /usr/lib/optee_armtz/023f8f1a-292a-432b-8fc4-de8471358067.ta
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
optee-os: 4 installed and not shipped files. [installed-vs-shipped]
ERROR: optee-os-3.17.0.imx-r0 do_package: Fatal QA errors were found, failing task.

To me it seems like I need to add optee and optee is trusted execution environment in arm, but do I really need this for ostree? Does ostree enforce to use secure boot, kernel, etc.?

Thanks Frenk

[ricardosalveti]

ERROR: optee-os-3.17.0.imx-r0 do_package: QA Issue: optee-os: Files/directories were installed but not shipped in any package:
  /usr/lib/optee_armtz
  /usr/lib/optee_armtz/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.ta
  /usr/lib/optee_armtz/fd02c9da-306c-48c7-a49c-bbd827ae86ee.ta
  /usr/lib/optee_armtz/023f8f1a-292a-432b-8fc4-de8471358067.ta
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
optee-os: 4 installed and not shipped files. [installed-vs-shipped]
ERROR: optee-os-3.17.0.imx-r0 do_package: Fatal QA errors were found, failing task.

Yes, this is probably because of usrmerge (which changes the default install path for libs from /lib to /usr/lib). I think you just found a bug in the optee-os recipe from meta-freescale (check for FILES and see how it is including the files from the optee_armtz folder).

To me it seems like I need to add optee and optee is trusted execution environment in arm, but do I really need this for ostree? Does ostree enforce to use secure boot, kernel, etc.?

OP-TEE is built by default for your target, with and without ostree, the difference here is that ostree requires usrmerge, and I think that is what caused your issue.

[iknerfS]

Yes, this is probably because of usrmerge (which changes the default install path for libs from /lib to /usr/lib). I think you just found a bug in the optee-os recipe from meta-freescale (check for FILES and see how it is including the files from the optee_armtz folder).

Uh, I really hope not. I was looking a little on the sources and found out the yocto is actually using optee from 2 different locations that include different version:

• /meta-freescale/recipes-security/optee version 3.13 and optee-imx/ version 3.15
• /meta-imx/meta-bsp/recipes-security/optee-imx version 3.17

And probably there is a confusion between both versions of the optee-imx as I think we are using only this one.

I am not a yocto expert, but will try somehow to update or us just one version.

Thanks again for all the support

[ricardosalveti]

Uh, I really hope not. I was looking a little on the sources and found out the yocto is actually using optee from 2 different locations that include different version:

• /meta-freescale/recipes-security/optee version 3.13 and optee-imx/ version 3.15
• /meta-imx/meta-bsp/recipes-security/optee-imx version 3.17

And probably there is a confusion between both versions of the optee-imx as I think we are using only this one.

You are using the one from meta-imx, which is newer.

rsalveti@evaxps:~/projects/fio/lmp/meta-imx$ git diff
diff --git a/meta-bsp/recipes-security/optee-imx/optee-os.imx.inc b/meta-bsp/recipes-security/optee-imx/optee-os.imx.inc
index 793c8a3ac..86ee1dace 100644
--- a/meta-bsp/recipes-security/optee-imx/optee-os.imx.inc
+++ b/meta-bsp/recipes-security/optee-imx/optee-os.imx.inc
@@ -92,7 +92,7 @@ do_install () {

 addtask deploy after do_compile before do_install

-FILES:${PN} = "${nonarch_base_libdir}/firmware/ /lib*/optee_armtz/"
+FILES:${PN} = "${nonarch_base_libdir}/firmware/ ${nonarch_base_libdir}/optee_armtz/"
 FILES:${PN}-staticdev = "/usr/include/optee/"
 RDEPENDS:${PN}-dev += "${PN}-staticdev"

This change should fix your build issue, and would confirm that it is usrmerge related.

[iknerfS]

Uh, I really hope not. I was looking a little on the sources and found out the yocto is actually using optee from 2 different locations that include different version:

• /meta-freescale/recipes-security/optee version 3.13 and optee-imx/ version 3.15
• /meta-imx/meta-bsp/recipes-security/optee-imx version 3.17

And probably there is a confusion between both versions of the optee-imx as I think we are using only this one.

You are using the one from meta-imx, which is newer.

rsalveti@evaxps:~/projects/fio/lmp/meta-imx$ git diff
diff --git a/meta-bsp/recipes-security/optee-imx/optee-os.imx.inc b/meta-bsp/recipes-security/optee-imx/optee-os.imx.inc
index 793c8a3ac..86ee1dace 100644
--- a/meta-bsp/recipes-security/optee-imx/optee-os.imx.inc
+++ b/meta-bsp/recipes-security/optee-imx/optee-os.imx.inc
@@ -92,7 +92,7 @@ do_install () {

 addtask deploy after do_compile before do_install

-FILES:${PN} = "${nonarch_base_libdir}/firmware/ /lib*/optee_armtz/"
+FILES:${PN} = "${nonarch_base_libdir}/firmware/ ${nonarch_base_libdir}/optee_armtz/"
 FILES:${PN}-staticdev = "/usr/include/optee/"
 RDEPENDS:${PN}-dev += "${PN}-staticdev"

This change should fix your build issue, and would confirm that it is usrmerge related.

Thank you very much for all the support. I have tried it and it still not compiling. I am now getting similar error for the package jailhouse-0.2-r0. Will check further and let you know if I manage to fix the problem. Apparently I need to set FILES here as well.

[ricardosalveti]

Thank you very much for all the support. I have tried it and it still not compiling. I am now getting similar error for the package jailhouse-0.2-r0. Will check further and let you know if I manage to fix the problem. Apparently I need to set FILES here as well.

It is quite common to see issues related to usrmerge as that feature is not enabled by default on most Yocto distros.

Basically any recipe hardcoding installing and consuming files from /lib will have this issue. ${nonarch_base_libdir} tracks that difference, and is set to /lib when usrmerge is not used and to /usr/lib when used.

[iknerfS]

I see, thanks for the explanation.

As before with the ostree here I also have two versions, one in the meta-freescale and the the other in the meta-imx (0.2 newer one and this one is being used).

But here the build complains with different folders (not usr/lib, but with the lib):

ERROR: jailhouse-0.2-r0 do_package: QA Issue: jailhouse: Files/directories were installed but not shipped in any package:
  /lib/firmware
  /lib/modules/5.15.32-lts-next+gceda485a78e6/extra/driver/jailhouse.ko
  /lib/firmware/jailhouse.bin
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.

And in the jailhouse bb I see all the paths are set correctly using the "${nonarch_base_libdir}" as in the ostree bb file:
FILES:${PN} += "${nonarch_base_libdir}/firmware ${libexecdir} ${sbindir} ${JH_DATADIR}"

[ricardosalveti]

But here the build complains with different folders (not usr/lib, but with the lib):

ERROR: jailhouse-0.2-r0 do_package: QA Issue: jailhouse: Files/directories were installed but not shipped in any package:
  /lib/firmware
  /lib/modules/5.15.32-lts-next+gceda485a78e6/extra/driver/jailhouse.ko
  /lib/firmware/jailhouse.bin
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.

And in the jailhouse bb I see all the paths are set correctly using the "${nonarch_base_libdir}" as in the ostree bb file: FILES:${PN} += "${nonarch_base_libdir}/firmware ${libexecdir} ${sbindir} ${JH_DATADIR}"

The issue here is that the install step is installing files under lib instead of using ${nonarch_base_libdir}, so you have to make sure both install and FILES are tracking the correct path.