Skip to content

OE4T Meeting Notes 2024 01 11

Dan Walkes edited this page Jan 14, 2024 · 3 revisions

Video

https://youtu.be/MH4c6qB7UO0

Attendees

11

Topics

  • OLDEST_KERNEL changes on master this PR
    • Recent change in master and nanbield for oldest kernel
    • Bumped up to 5.15 in nanbield.
    • Led to glibc trying to use syscalls we don’t have.
    • Changed TUNE_PKGARCH to be tegra-specific.
    • If you have a custom distro and other aarch64 targets you’ll notice glibc gets built specifically for tegras. Won’t get any benefit of package sharing between tegra and the other aarch64 targets.
    • 5.15 syscall changes in kernel made it easier to implement 64 bit timestamps consistently, handles year 2038 problem.
    • Will remove this once moving to Rel36.
  • NVIDIA container support - upgraded to correspond to version in L4T in r35.
    • Container toolkit being rewritten in go
    • Still some C code, mainline libnvidia container does not have jetson specific file remapping for CSVs but does dlopen another copy of the libnvidia container which does, still built off old jetson branch.
    • Have to configure the container in config.toml file, configure “legacy support” - to do file path remapping from debian style library paths to normal.
    • Looking at Jetpack 6 version of that, have upgraded to new version of the toolkit which does away with legacy support. To do our patches to remap library paths we need to modify some go code. Started looking at that, not the easiest to read. Have an idea about where to go as to making the changes. Assume the files in csv are identical between host and container.
    • Jose has noticed some issues with runtime on kirkstone mixin. Might only be an issue on their distro.
      • Need to make sure the go binaries are built statically, don’t use shared go runtime. Recipe should set that for container toolkit, make sure it’s set that way in the mixin.
  • Progress on Jetpack 6
    • Lots of recipes have gone in. Pretty much everything builds.
    • Container stuff from r35 is still in, might still work, haven’t tried yet.
    • Other stuff is up to date, deepstream is working.
    • Was a patch on the developer forums which Matt has applied to the kernel, supposedly resolves issues with stock JP6 where initrd flashing didn’t work, USB interface didn’t come up in gadget mode. Did apply that patch. Looks like driver/firmware issue in Jetpack 6.
    • Working on IGX Orin support, working only for iGPU
    • Will try to test secure boot. Have AGX working with the previous jetpack, not in Jetpack 36.2. Secureboot is not expected to work based on release notes, however it does work with stock Jetpack.
  • Swupdate example for Jetpack 5
  • UEFI A/B question
    • Have custom UEFI that others have stripped features out to get to boot faster, might have stripped out too much.
    • Does nvbootctrl verify need to run on every boot? Think there is a service that runs every boot which handles this, but not sure.
    • Have a patch to UEFI to disable verification - see https://github.com/OE4T/meta-tegra/blob/master/external/sota/recipes-bsp/uefi/edk2-firmware-tegra/0003-l4tlauncher-disable-a-b-rootfs-validation.patch
    • Ended up getting rid of shared variable storage that UEFI was doing since it kept getting corrupted. Only corruption between rootfs and UEFI is in the area of the EMMC in the beginning where the variables get set, the stuff MB1 and MB2 reads.
    • Don’t recall if the boot count stuff is there but suspect this is in variable storage for UEFI itself.
  • Headaches around fuse programming
    • Trying to upgrade to production key. Have builds signed with production key. Have what appears to be successful burned fuses. When attempting to do force recovery and initrd flash get nothing out of serial, initrd is hung waiting for boot up.
    • Have tried using odmfuse read command to read out what the fuses were set to. Tells me the module is locked when I don’t provide the key. When using production key to read back it fails when trying to send MB1 to processor.
    • Tried to read fuses with development key. Works, then reports the fuse hashed value is the development key. Have seen this on two modules at least, possibly the 3rd. Act of reading the fuses somehow changes the values to something else.
    • Can then load software with development key signed user images.
    • On Ubuntu 22.04 with newer SSL. Keys were in a format it didn’t expect. Last forum response said the developer guide is still based off Ubuntu 20.04.
    • generate_fskp_blob() in odmfuse.func is used to program FSKP keys.
    • See follow up in element here - this was a result of missing absolute path to odmfuse_pkc.xml and old copy from previous run with development build.
  • CFP for EOSS/ELC in April 2024 (Seattle) ends January 14
    • Should we talk about Jetpack 6 changes given GA may have occurred before?
    • Have been burned by writing CFP before things are done.
    • Will be in Europe in 2025.
    • Probably will skip this one.
Clone this wiki locally