OE4T Meeting Notes 2021 10 14

Video:

9

Had one case on TX2 (r32.4.3) where this issue was suspected, however the problem was ultimately the wifi kernel module. Have not seen this wifi problem in r32.3.1.
MMC tool for querying estimated lifetime available.
Created a post on the forum, no response from NVIDIA yet about whether status is reported accurately.

Honister branch started yesterday in meta-tegra and demo-distro. OE core master is now post honister, close to release.
Demoted gatesgarth to be no longer supported, hardknott is deprecated.
OE core is planning around the next cycle, April of next year, kirkstone should be next LTS. Want to make sure that if there are significant changes to meta-tegra we get in within this cycle so it makes into the next LTS release without need to backport. If you have ideas for new content, set a goal to get in sooner rather than later to make it be a part of next OpenEmbedded LTS.
Honister has the new stuff in OE core, big change to use colons for separator instead of overrides.

Using in secure facility and locked down. CSO will be concerned that the key is on the signing server, needs direct access. Wanted to know if there’s a way to back open SSL with an HSM. PKCS11 standard for this. Posted in the forum to get an answer from NVIDIA, went back and forth, latest comment is encouraging. In 32.6 release the tegra signing binary is broken into a python script. Pointed to tegrasign v3 internal. Has HSM environment variable support. Looking at this to determine how this could be used. Trying to make sure our signing key is protected by an HSM. See forum post at this link.
Tegraflash v3 signing script does get included in 32.6, used to sign the linux kernel image. Introduced in 32.5. Has a lot of functions, 3 python files. Looks like it could do a lot more than what it’s used for today.
Even the new python content uses tegra openssl, some private build. Old tools don’t use openssl.

Finished nano
Waiting for Deepstream 6 to complete some of the tests - should be available by November based on NVIDIA GTC schedule.
Automated script which can run all TensorRT samples
Would like to start referencing tegra-demo-distro commit hash in comments for each test case.

See https://github.com/OE4T/meta-tegra/pull/799
If you just need what NVIDIA packages, using the prebuilt is fine. Will use the default prebuilt binary until we have clear evidence going from source would be a better approach.
- Have noticed in the past that building a component from source gave different results from prebuilt. Some concern that the prebuilt components might be built with different settings, etc.

New feature on Jetpack 4.6. Recent presentation from NVIDIA recommended using Triton because it’s frontend and backend. Using TensorRT behind the scenes.
Ridgerun may be able to provide the implementation. Already starting work for one customer. Will have an update by the next meeting.

Time is kept between boot, drift is happening at runtime.
TX2 and Xavier NX are drifting a lot, one second per minute, as shown with a script which prints the current time (from the hardware). NTP is off for all devices. Using real time patches for the kernel, this might be related.
Others haven’t noticed issues with RTC.
The PMIC version seemed to work better, disabled on the SOM in one case.
May be an issue with hardware RTC, but see the same problem with Xavier. May try to build non RT version of image to see if the image persists
Hard-coded to use /dev/rtc0 SOC RTC with hwclock, pointed to the wrong RTC. Need to specifically say you need --device /dev/rtc1. Can’t actually update rtc0, only rtc1.

Ridgerun Customer plans to use NVMe for boot. Want to add support on meta-tegra
Not a simple process, won’t be simple to generalize across different products.
Managed to use the same sysinstall stuff for OTA flashing an image to the device which would then setup NVMe as a boot device. Deployment instructions/process could use some work. Good news that tegra-boot-tools are working with NVMe boot.

Have added in the past, didn’t send up the pull request because it needed additional work. If interested, could include pull requests for both.
Likely to also be working on signature and secure boot as a part of this project.
Ridgerun will have an update in the next meeting,