Nvidia Jetson Nano support? Any chances or Progress?

1st Official Post

    I've been scanning various links on Jetson Nano and I could find few interesting things here and there but I'm very much hoping for LibreELEC to be ported on this device


    These are my finds:

    Some DEV talks

    Nvidia Jetson Nano, superfast Kodi device?


    Run Jetson from USB

    Jetson Nano - Run on USB Drive - JetsonHacks


    Xbuntu-core XFCE4 18.04.2 Custom image

    https://devtalk.nvidia.com/def…age-for-the-jetson-nano-/


    Armbian for Jetson Nano

    https://devtalk.nvidia.com/def…/armbian-for-jetson-nano/


    .NET Core3 related

    Jetson Nano - A quick start with .NET Core 3


    Android on Jetson

    [ROM][UNOFFICIAL][8.1] switchroot LineageOS … | Nintendo Switch


    https://devtalk.nvidia.com/def…son-nano/android-on-nano/


    WiFi and Bluetooth related

    Jetson Nano + Intel Wifi and Bluetooth - JetsonHacks


    Metal case and parts related

    jetson nano – Geekworm

    Edited 3 times, last by Lama: New LineageOS image with shield android drivers (TegraX1) was released on 27/7/2019 ().

    +1

    Kodi Matrix works well using Docker on Jetson Nano: Docker Hub

    Having a LibreELEC image released would give a perfect low power HTPC solution for low cost :)

    Have any LibreELEC developers started to look at the newer Nvidia Jetson Nano developer kits / Nvidia Jetson Nano development boards?


    The first inexpensive Nvidia Jetson Nano Developer Kit was released just last year and the latest Nvidia Jetson Nano 2GB Developer Kit now only cost about $54 (US), while the original 4GB version of Nvidia Jetson Nano Developer Kit today looks to cost about the double at $99 (US).


    Jetson Nano 2GB Developer Kit | NVIDIA Developer


    Getting Started with Jetson Nano 2GB Developer Kit | NVIDIA Developer


    Community member hashtag on Kodi forum (aliubimov on GitHub) has been working on a Kodi branch with video player patches for NVDEC hardware acceleration via V4L2 on newer Nvidia Tegra like the Jetson Nano series.


    Nvidia Jetson Nano, superfast Kodi device?


    Commits · aliubimov/xbmc · GitHub


    Docker Hub


    Do you think that there be interest in LibreELEC support for Nvidia Jetson Nano Dev Kit board (Nvidia Tegra SBC) if those patches are mainlined?


    As I understand, Nvidia Jetson Nano (and Nvidia Jetson TX1) boards are basically single-board computers for Linux based on a similar SoC with same type of processor and GPU to NVIDIA Tegra X1 used in Nvidia SHIELD TV / Nvidia SHIELD TV Pro and Nintendo Switch / Nintendo Switch Lite.


    Tegra - Wikipedia


    Nvidia Jetson Nano 2GB Developer Kit specification does list 4K @ 60 H.264/H.265 video decode support and HDMI 2.0 output.

    Edited 5 times, last by Hedda ().

    Quote from chewitt

    Last time we looked the Tegra GPU drivers needed X11 to run, which does not align with the V4L2 oriented technical direction LE is persuing for all devices, so there is little interest in trying to support the boards.

    aliubimov on GitHub ("hashtag" on Kodi forums) has been working on NVDEC and V4L2 support for Jetson Nano, but yes he currently use X11


    Commits · aliubimov/xbmc · GitHub


    Not sure but it sounds as if could use NVIDIA V4L2 Video Decoder so not sure that X11 is a still requirement from Nvidia any longer?


    Jetson Linux API Reference: V4L2 NV Extensions API


    Jetson Linux API Reference: V4L2 Video Decoder


    Jetson Nano and Jetson TX1 Package Manifest list "libnvgbm.so" as "Library for Generic Buffer Management (GBM) implementation":


    Tegra Linux Driver


    It does dounds as if you could enable Weston (Wayland) Windowing System with libnvgbm.so gbm (Generic Buffer Manager)?


    Tegra Linux Driver


    Nvidia docs do mention that libnvgbm.so is still considered experimental and that there are limits with multi-planar dma-buf formats.

    Edited 8 times, last by Hedda ().

    • Official Post

    There was some traffic on the mesa mailing list in the last couple of months about alternative GBM back-ends, which is basically about nVidia partially conceeding they aren't going to win the GBM vs. EGL Streams discussion and tweaking things on their side to reduce the differences, combined with compromise on the mesa side to allow alternatives to current libgbm; which isn't so objectionable now the EGL Streams "GBM" shim makes the differences relatively minor.


    This basically allows Tegra DRM drivers to plug into mesa's userspace rendering infra which is well proven and widely supported; the shift from X11 is gathering momentum and Wayland needs mesa. Tegra V4L2 accelerated decoding is then the (non-trivial) missing link. If V4L2 compliant DRM/ffmpeg drivers are written (compliant to kernel V4L2, not some proprietary nVidia-ised interpretation) Kodi should require no changes to support Tegra boards. That's the theory anyway :)

    Hi, I like your way of thinking. And I think it is right way of moving forward. I have a board and most of the code for it, only change that I have to do, is to integrate it with GBM. I'll find some time to give it a shot.

    Quote from chewitt

    This basically allows Tegra DRM drivers to plug into mesa's userspace rendering infra which is well proven and widely supported; the shift from X11 is gathering momentum and Wayland needs mesa. Tegra V4L2 accelerated decoding is then the (non-trivial) missing link. If V4L2 compliant DRM/ffmpeg drivers are written (compliant to kernel V4L2, not some proprietary nVidia-ised interpretation) Kodi should require no changes to support Tegra boards. That's the theory anyway :)


    All right. I did some research of best way to approach this. As CvH mentioned, NVidia Decoder seems to be encoded in firmware for SoC and data passed via NVidia specific system calls via nvhost bus.


    I am not Kernel developer, correct me if I wrong. The way I see it might work, is to create wrapper driver that is V4L2 compliant.

    Last option would be to make a change to FFMPEG to support NVidia Decoder and redistribute it as patch to image. FFMPEG community isn't very excited about having NVidia-ish V4L2 and basically consider it madness to implement :)

    Edited 4 times, last by hashtag: spelling ().

    • Official Post

    Wrappers aren't the right approach because the level of optimisation required for functional 4K pipelines on ARM hardware is high and you'll always end up needing to write efficient native drivers. You can bodge 1080p, but RAM speed and bandwidth become big factors with 4K. The tertiary challenge with V4L2 is that it's all super new and still in a lot of flux; we're still some way from making a serious effort to upstream our current working code to ffmpeg because lots of things are still being experimented on.