-
Notifications
You must be signed in to change notification settings - Fork 230
OE4T Meeting Notes 2021 08 12
Dan Walkes edited this page Sep 25, 2021
·
4 revisions
- Unfortunately this one has audio issues didn't include audio capture for attendees.
11
- Dunfell branch updated in both meta-tegra and the demo distro are updated to JP 4.6. Will use branch naming policy going forward to use the name of the branch corresponding to the core layer. Pulled a dunfell l4t r32.3.1 branch for those who need to stay on the old BSP.
- Master is now up to date with JP 4.6 content. The overrides syntax change in oe core master a couple weeks back caused issues. Master is now building in demo distro. Some layers haven’t been converted, forked those layers and pointed demo distro at the forks. This is a temporary thing, will switch back when determining what the correct long term solution is.
- Short term merges between branches will be more difficult. Bitbake dunfell should support either changes, so we could convert dunfell branch to use the new syntax, will be able to more easily cherry pick changes between the two. Haven’t done that yet because it touches most files in the repository.
- Testing in progress. Open question as to whether the container implementation is functional. Made changes regarding passthrough mounts. Added support for filtering out passthrough mounts. Need to adjust container CSVs we generate, either that or do some additional patches to their library to align with what they are expecting. Everything in their l4t csv file is supposed to be passed through when the container has a flag set to mask out non core stuff. Nvidia doesn’t appear to have a container that actually does that yet on NGC. The containers fired up have worked OK. 4 docker containers currently available: pytorch, machine learning, l4tbase, tensorflow
- Need to do some passthrough because some code in userland is actually driver code, needs to be tied to specific version of the kernel which is running.
- We’ve put together csv files differently than they do to make it more modular, will need to account for that.
- Should be possible to reduce filesystem space on the root OS. Container has an attribute to indicate as to whether it does or does not want to use passthrough. Can start building containers which turn off passthrough flag and bundle content. Then start removing libraries from base OS.
- Don’t have deepstream 6 containers yet as these haven’t been published published. Haven’t tried deepstream 5.1 with 32.6, not sure if this combination will work.
- Ran into issues with t210 nano platforms. H264 test doesn’t work properly, on the nano, fails consistently. Works well on other platforms. Not sure if it’s a pipeline issue or a bug with video decoder plugin specific to Nano. Issue filed at https://github.com/OE4T/meta-tegra/issues/768
- Verified secureboot build is working. There are some tweaks to what needs to be signed in 32.6 for Xaviers. Added signing of USB firmware. Had one issue again on the nano, kernel was hanging on boot. May have been pilot error, needs to be re-tested.
- Some build related scripts had under the hood changes between EA and final which took work to deal with.
- Haven’t seen any patches posted for 32.6 on the NVIDIA forums yet.
- Some support for new hardware in 32.6.1, Xavier Industrial. Not planning on buying or using, looking for contributors to help sponsor a new MACHINE.
- Security bulletin out today, kernel bugs and firmware, bootloader bugs. Some kernel ones are very high priority. Recommendation if you are running older than 32.6.1 upgrade to 32.6.1.
- Welcome anyone with bandwidth who can do testing with new BSP. See discussion thread at https://github.com/OE4T/meta-tegra/discussions/776 and spreadsheet linked there.
- NVIDIA has a test plan for each release. Don’t want to duplicate what they are already doing. Other than making sure we are integrating correctly we don’t need to necessarily test the functionality they are already testing. Focus on these areas:
- GStreamer - we are building everything from source. Want something that matches what they provide in binary form.
- Kernel/cboot/uboot - since we build from source we need coverage of this.
- Anything which might be different between custom build OS we build and what we supply.
- Encrypted root filesystem and A/B upgrade tied to their use cases. Focus on areas where we do things differently.
- Think forward to automation of tests in the future
- CUDA samples, gstreamer pipeline scripts for testing - if there are more scripts we should add to help automate the process more this would be good to add.
- See slack thread at https://oe4t.slack.com/archives/C01BTRXHGQ5/p1624383216192400
- glibc dependencies don’t map correctly between code in the container and outside the container.
- Originally weren’t using the stock tensor rt, though they needed to rebuild the plugin library.
- For FasterRCNN - NVIDIA’s repo has examples about how to run certain networks, and documentation mentions it needs to be rebuilt. However, examination found that symbols are in the library, don’t think it’s necessary to rebuild.
- Explored different options, planned to build on Jetson dev target with correct version of glibc if this was needed, didn’t appear to be needed.
- Working with A/B updates. Roots are smaller, updates go faster, using swupdate.
- Not many commits required to get that work. Will put together a wiki writeup.
- Tried on NX and Nano.
- Haven’t tried with secureboot yet, will look at that next.
- Currently using 32.4.3, queued up to move to 32.5.2
- See related comment at this post shared later.
- Have deployed successfully in production deployment for Jetpack 3.3 to 4.4. Check in with Atharva on slack if you would like to collaborate on further improvements/productization.
The next meeting will be September 9th at 9AM MDT: https://teamup.com/event/show/id/Rn6HvmfkjcirJ5upoLSs9C4cFX54hQ