Skip to content

OE4T Meeting Notes 2021 12 09

Dan Walkes edited this page Dec 11, 2021 · 1 revision

Video:

https://youtu.be/xXQRujQg9cM

Attendees:

9

Topics

Mender Support

  • Newer L4T releases now supported on https://github.com/OE4T/meta-mender-community/pull/15 thanks to work from Matt
    • Most of the content is identical to what was currently in dynamic layers on meta-tegra-community, some minor additions to support multiple l4t versions on one branch.
    • Dan will work to get this upstreamed and merged back into tegra-demo-distro with corresponding changes to meta-tegra-community to remove no longer needed dynamic layers.

HSM Support for firmware signing

  • Discussed response from NVIDIA in email.
  • Not sure what to put in https://forums.developer.nvidia.com/t/signing-firmware-with-an-hsm-protected-private-key/191616 in terms of additional requirements, will need to research this a bit more.
    • Someone reached out privately to Chad about their approach, discussed a concept of dynamic engines in OpenSSL, delegating out operations. A vendor can provide dynamic engine and route through OpenSSL, this was the approach they were taking to resolve. Chad to ask if it's possible to share details in the thread above.
    • Saw a forum post regarding signing in Java, have figured out how to signatures for everything other than 1 file. Might trigger some information sharing which could be useful. See https://forums.developer.nvidia.com/t/format-of-mb1-t194-prod-bin-oem-signature-header/196157/7
    • Discussed using binary scripts which either natively support creating a hash off the key, or the binary provides a call out to something which can do that hash step on the HSMs behalf. It seems the hashing step needs to be broken out.

Boot logo

  • Work in slack post at https://oe4t.slack.com/archives/C01BTRXHGQ5/p1637267929085100
  • Issue is due to the fact that a linear RGB buffer is expected. What goes to display gets gamma corrected. If you have a buffer which is already gamma corrected it gets gamma corrected twice. Normally linux will do de-gamma.
    • Two ways to get boot logo to cboot:
      • One is to pre generate images that go to boot logo. An existing source script and LFS repo on github with three different resolutions provides the stock OE4T logo using this method, in a “precooked”. This approach worked because source image was in linear RGB space to begin with
      • Second way to give one source image, have the recipe apply imagemagick stuff when it builds. The imagemagick command doesn’t do anything with the color space, uses what it gets. This assumes you don’t want linear RGB, assumes it will be SRGB. Can read color space from file, sends it out, but that’s the wrong format for cboot.
  • Proposed changing imagemagic to look at the source, put into the right color space. Ran into problems trying to apply to the version Matt has produced with gimp. Wasn’t reading the right color space out of the file.
  • Typical case supported going forward is to use sRGB for input images, which the scripts will then force to go to linear RGB. If you use something other than sRGB imagemagick will ignore it. This implementation won’t impact the existing “precooked” version. If we change the logo later, we’ll need to use the right commands to cook it.
  • Kurt has patches lined up to do that, see PR at https://github.com/OE4T/meta-tegra/pull/865
    • May need to change bitmaps after merging this PR.
  • Matt did find issues with initial cooked images. If you need an image that works for both nano and xavier, take that into account. BMP version has multiple copies of different heights.
  • NVIDIA’s scripts to put bitmaps in payload do a compression. Trick is to make sure the background is solid color, so the compressor can efficiently deal with it. If you have a gradient it doesn’t work well.

Fixes to nvcompositor and build against gstreamer 1.18

  • One user had trouble building, had patches that build but aren’t functional, see slack thread at https://oe4t.slack.com/archives/C01BTRXHGQ5/p1638891279150700
  • Doesn’t work at runtime.
  • Kurt posted a draft pull request at https://github.com/OE4T/meta-tegra/pull/864
    • Not reading properties right out of gstreamer element
    • Also not working yet
    • Looking for help from anyone else who is using nvcompositor
  • Matt spent some time on this, fixed the property problem. Comparing to compositor plugin in 1.16 and later, basically re-architected. Handles a lot more things. Managed to get it to the point that it could run with properties. Ran into issues where the video plugin reads nvbuffer properties and size, that size looks completely wrong (only around 1800 bytes). This is related to using the nvbuffer as a handle instead of actual buffer contents.
  • Looked into V4L2 source and buffer copy changes at nvcamerasrc plugin - not much usable.
  • Decided to use a custom transform element that passed through but offered a buffer pool for v4l2 source. Then the v4l2 source could get DMA buffers. Exposed nvidia buffers as DMA buffers. Because buffer memory isn’t the buffer it talk to any other gstreamer plugins.
  • A forum post already existed for someone who ran into this problem, advice from NVIDIA was to modify sources to support gstreamer 1.18. Would like to suggest NVIDIA support for newer versions of gstreamer, using something other than ubuntu sources.
  • All containers are based on ubuntu 18.04 and all are using gstreamer 1.14 currently.

TX2 Supply chain problems

  • Existing TX2 are difficult to find. Don’t believe they will have supply until May. Relates to ethernet PHY component. Created a new SKU for TX2 without Ethernet.
    • Suppliers are asking for minimum required and minimum stocks. In one case a will have only half of existing orders, rest will be available in June.

Container support issues on later OpenEmbedded branches

  • Opened a new issue at https://github.com/OE4T/meta-tegra/issues/857 regarding glibc version mismatches on honister and later.
  • Most containers won’t run on honister or later due to upgrade of glibc to 2.34.
    • Several libraries are merged into one main glibc, so anything running on old glibc won’t work.
  • Dan has updated https://github.com/OE4T/meta-tegra/wiki/L4T-Integration-Issues
    • We need to discuss with NVIDIA to determine how we can continue to support products which are retiring, get access to sources needed to maintain going forward.
Clone this wiki locally