Embedded Linux

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Hi,

According to the documentation, NVidia provide support for Ubuntu derived root filesystem that is supplied with L4T. Does NVidia supports also Embedded Linux such as Yocto or Buildroot or indent to add support in the near future?

Thanks and Best Regards,
Alex

2

Only the given Ubuntu is officially supported. You can call it “Linux for Tegra” when the direct hardware access drivers are added, but it is still Ubuntu. I know some people have worked on other distributions and might have some URLs, but I’m unable to give any. The major limitation if you wish to port is that the X11 server should be the same ABI as the L4T release you port from. The reason is that the GPU hardware access drivers are tied to that ABI and are available only in binary format. Most of the rest is kind of “plain vanilla” (once you get past the bootloader, but you could use the L4T Ubuntu setup until loading the o/s).

3

I made a root filesystem using buildroot as a test but, as pointed out by linuxdev, this doesn’t have any of the nvidia code for which source code is not published which makes the usefulness of it very limited.

4

Thank you very much for your replies! Can you please give me a link to some information about what does “GPU hardware access drivers actually provide”? We never worked with NVidia before, and we are not sure if we must use it. Our system have no GUI interface at all, so I am not sure we need X11 server at all.

5

While you may not need nor want a GUI the GPU can be used for many computational tasks.

If you have camera inputs you’ll want to utilize hardware that is only available via some software that Nvidia does not publish source code for.

6

If you look at a Jetson you will find it has file “/etc/nv_tegra_release”. That file is a list of NVIDIA-provided files. One specific file of interest is libGLX.so, but browsing each file and looking for what each file provides (although time consuming) will tell you what files are related to hardware access.

JetPack is a front end to the driver package. If you were to flash on command line via the driver package, then the “apply_binaries.sh” step would unpack those libraries into the “rootfs/” subdirectory before building the final rootfs image. That script is human readable and so you can see what is unpacked where.

The X server is often mistaken for being a desktop application. It isn’t. X is a unified interface (via X protocol events) to a buffer which happens to be useful to a video display. In the early days nobody did GPU computation for anything other than video display, and so naming tends to look like this is only for video display. The desktop environment with windows and applications is really the window manager and not X. Window managers are simply applications which use the X protocols to update a buffer. X itself does not provide any kind of user session.

X optionally loads a direct GPU access library…libGLX.so (this is dynamically loaded, and thus it has a dependency on a matching ABI). X runs a single program. That program manipulates a buffer. If you are without a display, then you still want a virtual server because you want the GPU to be accessible. There are some limited low-level cases of using the GPU without X, and I wish I could name them, but someone else will have to answer for your particular use-case (I wouldn’t mind seeing some examples of the low level cases just for my own curiousity). A strong clue though is that if any part of your program is linked against something using X protocols, then you must have the X server (a buffer context identified through the DISPLAY environment variable…the name of which is misleading since it doesn’t point at video display hardware, it points at a buffer usually used by video display hardware). Although you can exclude window managers and login managers you will likely need a virtual desktop in order to obtain a buffer context (it may be called a virtual desktop, but all it does is manage or point to a buffer).

A typical login goes like this:

  1. X is called (running as root or some system user) with a login manager as its only target.
  2. The user authenticates name and pass.
  3. X respawns suid of that user, but names a window manager as its only target.
  4. Window manager brings up windowing features. No window manager implies no features.
  5. Window manager allows running more programs. It isn't X running those programs (though events will eventually pass through to X).
7

.

Hey D3, thanks for posting! Would you mind sharing your buildroot commands/instructions?

I’m working on getting this up and running via sd card. Appreciate it either way!

8

I still have the build sitting on my dev machine so I’m happy to help.

It looks like I built from master (commit hash: 572c7af8dbcc9539ea54724e88b0850ae47d98ee). That’s more than 3000 commits behind now!

I’ve attached the config I used.
dot-config.txt (81.4 KB)

9

@d3_gr

Thank you! for both the quick response and the config file! 3000 commits, * edit, the config file is loud and clear. Thank you!