Hello,
I am using Jetson Xavier NX devkit with emmc(linux version: r3273).
I have no problems with my rootfs, I just want to know what these files do:
/opt/nvidia/l4t-usb-device-mode/filesystem.img
/usr/share/glvnd/egl_vendor.d/50_mesa.json
I want to know which service will use these two files? Under what circumstances are they generated or modified? Thanks very much.
If your Xavier NX has eMMC, then it is not a dev kit. It is a commercial module, and unless you specifically transferred it to a dev kit carrier board, then you have a third party carrier board (implying that firmware/device tree likely needs to change).
The filesystem.img is part of a demo of the kernel Gadget API on one port which is in device mode. This contains a small image of a filesystem with only a README type file on it. When the Jetson is fully booted, then it provides a virtual network router type device, and a filesystem with that README file. The file is loopback mounted and the USB Gadget pretends the Jetson is a bulk storage device (this is separate from the virtual network device, but uses the same USB port).
I don’t know of any specific use of “50_mesa.json”, but the naming convention suggests it is a configuration file for systemd. When the Linux kernel first loads it is its own program, and it can start only one other program; that program is “init”, and for current Ubuntu (and most other modern Linux distributions) init is a symbolic link to systemd. This first process is process ID 1. PID 1 is what runs all else, e.g., it might fork off networking, disk use, user management, basically everything. If you were to kill init then the system would reboot or shut down. The kernel itself is PID 0. Every PID over 1 is a child of init (systemd).
Long ago init was just a bunch of bash scripts. systemd is a modular (and loosely somewhat object-oriented) replacement. Different modules with prerequisites before running and actual running of various programming are loaded as needed. Boot progresses to single user without networking, with similar systemd modules specifying this, then it eventually gets to multi-user (text mode) based on more modules, then to graphical mode for graphics on top of multi-user text mode.
The standard files are all somewhere in “/usr/share”, and there is customization possible in “/etc/systemd/”. The /etc/systemd/ has subdirectories, and within this, including .conf files, are a number of systemd files such as the 50_mesa.json. If a module is used in a standard way, then typically it will have a symbolic link from that location to the “/usr/share” version of that file. A file might instead be copied into “/etc/systemd/”, and then edited in order change a systemd module without removing it from the system (you can revert by changing back to a symbolic link to the original). Not all of those files are used at the same time, and some are mutually exclusive of each other.
The name tends to be related to order of running. Back when init was just bash scripts the 50_ files would run after 40_, and before 60_. This isn’t entirely true now under systemd, although it is possible to do something like copy the 50_something to 51_something, edit the 51_something, and make it so the original 50_something runs prior to running 51_something.
Mesa is itself the open source graphics software. Often it is used in some other environments for its X server, but Mesa has a lot of other utilities and is not specifically an X server. NVIDIA does not use the Mesa X server, but there are a lot of other utilities surrounding graphics which are present on Jetsons. Mesa is its own open source provider.
The 50_mesa.json is something you’d likely find in most Ubuntu systems, maybe other non-Ubuntu as well. The filesystem.img is entirely custom.
When you flash normally, on the host PC side, the “Linux_for_Tegra/rootfs/” content is almost an exact copy of the final partition. Regardless of whether you manually add the NVIDIA content to the rootfs/, or automatically do this by flashing with JetPack/SDK Manager, this addition of NVIDIA content occurs only once, and this is when the filesystem.img is probably added. The 50_mesa.json is likely there already, though I won’t guarantee it (I haven’t traced down the origins of that file).
The 50_mesa.json would be a human-readable file. You could open it with less or some editor and examine it if interested in some of what the module sets up when systemd sees it (but it might not be used at all).
The filesystem.img is something which could be modified if you want to experiment with exporting filesystem content from the device mode micro-B USB port (you have a third party carrier board, and I am assuming it has a micro-B port, but it depends on the third party vendor’s design).
FYI, if a custom carrier board has the exact same electrical layout as the dev kit, then it uses the same device tree. Chances are though that something differs on this from the dev kit, and thus there might be some small subset of hardware on that carrier board which only functions when the device tree is correctly edited.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.