OE4T Meeting Notes 2022 01 13 - OE4T/meta-tegra GitHub Wiki

Video

https://youtu.be/DUDfW8AqgoU

Attendees

8

Topics

  • Plan to move meeting time later by ½ hour starting next month.
  • Root of trust mechanism for A/B rootfs on Nano
    • Discovered nano bootloader redundancy is different than NX. Both redundant partitions updated, no fallback strategy as there is with NX.
    • Found in testing - intentionally corrupted in the rootfs, expected failover. Since both bootloader A/B partitions were updated concurrently ended up with mismatch of root hash in rootfs, no longer matched verity hash for fallback.
    • Relevant changes in https://github.com/OE4T/tegra-demo-distro/wiki/Tegra-&-Uboot-Flattened-Image-Tree-(FIT-image)
      • Need to add code to this to add chain of trust.
    • Need to design a/b failover strategy to use uboot.
    • RAUC does a similar thing with uboot script.
    • Current implementation is signing but not encrypting. Storing verity's root hash in the environment. Add uboot scripts to store somewhere else. Two fit images different bootloader A/B and different rootfs A/B.
      • Added two extra partitions to put FIT images in, requires a difference in layout from NVIDIA partitioning scheme.
    • NVIDIA introduced a new version of slot metadata, separated out partitions used to load bootloader and rootfs. Hasn’t made it back to Nano. Tegra boot tools only deal with version 3 metadata, where slot which loads bootloader is the slot that loads rootfs. In newer versions they added the ability to split the two things apart with lots of additional controls.
      • Unfortunately t210s don’t use slot metadata, don’t have A/B redundancy back to boot ROM.
      • First introduced in r32.5, wasn’t publicly supported until r32.6
      • Do have a devicetree in FIT image, bundled initramfs in the kernel. Can also use DTB overlay.
      • Need to mount with specific options, possible to brick devices if not careful.
      • Secure Boot Key can’t be used to generate root filesystem hash, since it's not accessible in protection mode.
  • Changes in recent master regarding toolchain and CUDA, improvements
    • Changes going into OE master made it hard to build things with old versions of GCC. Specifically Rust support. Could not come up with a way to coax rust content from C to build with the old compiler. Using C++ feature for atomic instructions, functions which provide atomic support. Changes in g++10 made them not inlined. Rust support depended on this feature.
    • Figured out a different approach to using CUDA GCC8 support. In master include the GCC8 toolchain in main part of layer. Used only for doing CUDA compiles. Anything which uses CUDA builds using GCC8.
    • Don’t need to set the toolchain anymore, will build with whatever toolchain OE wants to use.
    • Similar approach used for Ubuntu, Debian and other distros handle the toolchain problem.
    • Now in master no longer need to use gstreamer 1.14. Nvvidconv and nvcompositor were not compatible, are now. Could be backported, not done yet. Should only be necessary if you need nvcompositor. Have used older plugins against newer gstreamer. May not be a compelling reason to backport.
    • Changes in OE core - set recipes to include OpenGL as a required distro feature. Lots of compatibility issues without this.
    • Fixed a problem with meson and qemu
    • Rust support in tegra demo distro - if using shared state, Rust support always needs to be rebuilt. Have a workaround in demo distro. Takes a long time to build.
    • Not planning to move GCC backward, will be incorporated in the next release, not planning to backport into existing branches.
  • Additional OTA System Investigations/Mender Alternatives
    • Played with swupdate and RAUC. Liked swupdate, but looking for something with better delta update support.
    • Swupdate has delta update support in development, not using rdiff but using zchunk which looked promising, however not really ready for experimentation. Zchunck not working, swupdate portions not really working yet.
    • Can’t switch to OSTree given the existing project with A/B assumption built in, otherwise might have started with OSTree.
    • RAUC uses casync and has some limitations. See previous discussion at https://github.com/madisongh/tegra-test-distro/wiki/RAUC-integration-notes.
      • Would like a speed increase as a part of an update, not just smaller update payload.
    • Discussed swupd as an additional option: https://docs.01.org/clearlinux/latest/guides/clear/swupd.html
  • Container issues on honister