Video

https://youtu.be/eB3BOiAdy8E

Attendees:

8

Topics

• Matt discussed updates on master, simplifications in the layer in this PR
  • Instead of per SOC helper script there’s only one.
  • Master going forward will use unified approach, doesn’t work the same way it does in kirkstone. Impacts how we use flash variables
  • Now uses variables within bitbake and MACHINE configs rather than flashvars files
  • If you are doing customization for flash layouts this should be easier now. Easier way to add bbappend to one recipe rather than creating a new recipe.
  • Now only one place to change things when we have a new L4T release.
  • Don’t intend to backport back to kirkstone, will be used for the new LTS branch when available.
• Jetpack 6 L4T r36 release
  • No progress to report yet.
  • Matt has researched how the kernel is put together, not sure yet how we will map this to our kernel builds.
  • Holoscan EA access in progress. Have Rel 36 booting up to display, GPU is working. Caveat is that it’s not public yet, for EA customers in healthcare space. As soon as Rel 36 can go public will share what is available.
  • Only will have Orin support as Xaviers are no longer supported with Jetpack 6.
  • There was talk about moving forward with kirkstone but likely will want to move to new LTS release. Needed to update to GCC 12 to use the layer with Holoscan.
  • Not sure when r36 will be publicly available yet.
  • Kernel change from 5.10 to 5.15 is the main change. Biggest difference is the structure of the kernel build.
• Initscript support and L4T 32.7.4 kernel
  • Changes for L4T 32.7.4 - kernel update
• R32 series support, likely one more update.
  • Forum post indicated there would be one more 32.7.x release, that would be the final release. Not sure what will be updated or if there could be future updates for security issues.
  • Likely won’t ever move 32.x releases past kirkstone unless there are people who are willing to put in effort for this.
• Digsigserver
  • Signing is more complicated in Jetpack 5.
  • Besides hooks in the layer which allow signing to occur on different machine than build server, typically layers which do signing assume the build machine has access to the keys. This isn’t a best practice.
    • You typically want your developers to be able to do builds, don’t want to pass keys around
  • Have a python based digital signature server to support tegra signing. Have since extended for other platforms
  • Doesn’t currently support Orin.
  • Want to add hooks for UEFI signing
  • Going back and forth on PRs for the layer
  • Would like to add a signing server option for the demo layer.
  • Today the digsigserver is in Matt’s personal repo rather than OE4T. Matt would prefer to keep that way since it’s used on other platforms.
  • If we want to do a fork specific to OE4T that’s a possibility.
  • Don’t want to build into BSP layer, would like to keep in separate layer.
  • Could move to the demo distro.
  • Putting in a separate repo may be a good idea so it’s easy to integrate when not using the demo distro.
  • There is generic signing support at https://git.openembedded.org/meta-openembedded/tree/meta-oe/classes/signing.bbclass which hasn’t been thoroughly evaluated yet.
  • Current status:
    • Xavier NX signed with the signing server and able to do secure boot.
    • Transitioned over to Orin NX, ran into an issue with a python module for flattening device tree.
  • UEFI capsule signing is an area of work Chad hasn’t touched yet. Ilies plans to help with this.
  • Matt has some early work on T234 at https://github.com/madisongh/digsigserver/tree/wip-r35-orin-support.