Skip to content

OE4T Meeting Notes 2022 12 8

Jump to bottom Edit New page
Dan Walkes edited this page Dec 9, 2022 · 2 revisions

Video

https://youtu.be/ZMog0lbiQ60

Attendees

9

Topics

  • Initrd flashing
    • Upcoming Orin NX doesn’t have a mechanism to flash with current meta-tegra support.
    • Matt spent time experimenting with ways we can implement the basic functionality without going the nvidia route with lots of manual intervention required.
    • Have a work in progress branch at https://github.com/OE4T/meta-tegra/tree/wip-initrd-flashing
    • Have an initrd which starts usb gadget for mass storage, exposes that. Need to make sdcards with gpus for programming with rootfs disk image.
    • Reapplied that to usb served storage. Worked OK
    • Haven’t figured out how to get the bootloader programmed. Hoping to use bup payload and nvupdate_engine -force
    • Scripts NVIDIA uses re-implemented the bootloader flashing in shell script form, looks fragile.
    • Has dependencies on tools we don’t want to carry around
    • If you have a need to do NFS we should discuss.
    • swupdate, can embed a web server in the initrd, then swupdate the image for programming.
    • For NVIDIA “OTA” updates - cross L4T with boot into recover image, not worried about that at the moment, but hopefully some of the tools which come out could be used as well.
    • Tim’s Yocto summit talk about Bmap installer - see https://www.youtube.com/watch?v=LnIvDJLPU20&list=PLD4M5FoHz-TwT20z2FPKy4y38Tur6ArIL&index=8 for lightning talk
    • See https://manpages.debian.org/bullseye/bmap-tools/bmaptool.1.en.html Suspects it might not be useful in the Tegra space but probably worth some investigation.
    • Ability to partition as part of the boot tools needs to be essential. May be a reason to look into bmap installer
    • Using BUP payloads after initrd: My not prior to boot the kernel and running the initrd, use existing flash tools to write before reboot and write from the host side through USB. Can run do_flash with whatever payload you like while it’s in USB DFU mode. If we wrote those partitions first with that tool that might be a way to do it.
    • Boot change for initrd installer might be different than your production image
    • Flash boot chain into the spi flash, then boot the initrd. Not sure it’s easier harder than using the bup payloads. One advantage is that the payloads don’t need to be part of an initrd image or transferred separately.
    • Want to also support secure boot and setting up encryption. Requires initrd to write out to encrypted partitions. Work in progress branch doesn’t address these cases yet.
    • Don’t want to duplicate what NVIDIA does with Jetpack. Since we build from scratch we can build what we need to build, make it flexible enough that other use cases will work.
    • If we could sense that the place we are installing to doesn’t have partitions yet, could hypothetically use bmap to install partitions to it.
    • If you already have an existing partition can use bmap to write just that one partition.
    • tegra-bootloader-update is one other option.
  • Mender
    • Discussed strategy to use mender update modules and https://docs.mender.io/artifact-creation/create-a-custom-update-module and reflash via state scripts which leverage nv_update_engine for boot loader partition updates and some additional mechanism to stream rootfs content.
    • Mender is relying on the bootloader to know if the A/B update is successful. Bootloader will be updated going from 4 to 5. Now you need a custom update script.
    • Some platforms may need flash re-layed out, either spi flash or main storage.
    • Treat the mender artifact as a way to deliver a recover image, then boot into recovery image. Recovery image needs to be able to download the full system image which needs to be installed as a part of the transitional update. Would happen outside the mender context. Recovery rootfs is only around 300MB, meaning we'd need some other mechanism to deliver rootfs payload. This would essentially be back to back mender deployments, one for a recovery image and one for the payload which the recovery image consumes and writes to the rootfs partition(s).
    • Josef is not aware of a direct path that involves two artifact downloads in mender today. If we use the recovery partition approach the main problem is that we don’t have space to buffer the rootfs image.
    • Schedule a mender deployment to deploy the recovery image.
    • Client runs in recovery image.
    • Do a separate deploy to to then deploy the update from the recovery image.
  • Jetpack 4.6.3
  • WIP EA release
    • Just dropped, talk to Suhas about getting an NDA, then can get access to private branches.
  • FOSDEM
  • Jetpack 5
Add a custom footer
Add a custom sidebar
Clone this wiki locally