OE4T Meeting Notes 2025‐11‐14 - OE4T/meta-tegra GitHub Wiki

Attendees

8

Video

https://youtu.be/U-AzaZ_4PqM

Discussion

Thor/r38.2

  • Thor support r38.2.x branch now a dedicated branch, no longer work in progress.
  • Only supports thor hardware, orin hardware is still in the branch but not supported.
  • Big change is the flashing process
  • No plans to rebase on scarthgap, not production ready
  • meta-tegra-community branch available as well

Documentation Discussion

  • Use of github wiki for documentation - have a lot of pages, hard to find
    • Doesn’t seem to be making improvement for making page organization.
    • Should we move into the layer, especially flashing.
    • Should we have a separate repo just for docs
    • Wrap md files with mdbook, build docs site based on markdown in repo. Would like to stick with markdown.
  • Example setup: https://docs.simpleiot.org https://github.com/simpleiot/simpleiot/tree/master/docs

linux-yocto and work on Xavier

  • Able to boot Xavier on scarthgap (r36) with linux-yocto with existing devicetrees
  • Everything works, in good shape in terms of hardware support.
  • Want it in the project somewhere, not sure where to put it.
  • Want to carry into the future in an unofficial capacity
  • May need slight changes to accommodate flashing in meta-tegra but machine definitions could either be meta-tegra-community or something else.
  • Third party machines which aren’t nvidia, (seed, cti). meta-tegra-community makes sense for those.
  • Would third party make more sense for BSP support.
  • meta-openembedded has sublayer format we could try to match, might be too late for this.
  • Would like to keep absolute minimum dependency on meta-tegra bsp layer, only require oe-core.
  • Want to keep meta-tegra-community a software only not a BSP layer.
  • Could possibly make meta-tegra-comunity a sublayer in a new layer. Layer check rules are different, want to avoid putting more constraints.
  • meta-tegra-thirdparty as a new layer may make sense. May want to be meta-tegra-bsp
  • Other complication is in flashing. Had just split xavier out of initrd flash when this was started. Initially reverted patch to get it back. Unified flashing might be another deviation. Should we keep initrd-flash around as a straightforward/flexible way to flash?
  • Initially will be agx-xavier-devkit based, also will attempt to get xaver-nx-devkit
  • Will also be a community devicetrees repo

digsigserver pull request

  • Don’t have older builds than 32.7.3
  • Will update to Ubuntu 22.04, Chad working on this in December.

Handling l4tlauncher mismatch