Preliminary support for NVIDIA Jetson boards #1692

dmitriy-philimonov · 2025-05-03T10:39:26Z

NVIDIA Jetson device is an insdustrial Linux based embedded aarch64 platfrom with powerful builtin GPU, which is used for AI tasks, mostly for CV purposes.

The support is provided via --enable-nvidia-jetson switch in the configure script.

All the source code related to the NVIDIA Jetson is placed in the linux/NvidiaJetson.{h,c} source files and hidden by 'NVIDIA_JETSON' C preprocessor define. So, for x86_64 platforms the source code stays unchanged.

Additional functionality added by this commit:

Fix for the CPU temperature reading. The Jetson device is not supported by libsensors. The CPU has 8 cores with only one CPU temperature sensor for all of them located in the thermal zone file. libsensor might be compiled in or turned off. The additional care was taken to provide successfull build with/without libsensors.
The Jetson GPU Meter was added: current load, frequency and temperature.

== Technical details ==

The code tries to find out the correct sensors during the application startup. As an example, the sensors location for NVIDIA Jetson Orin are the following:

CPU temperature: /sys/devices/virtual/thermal/thermal_zone0/type
GPU temperature: /sys/devices/virtual/thermal/thermal_zone1/type
GPU frequency: /sys/class/devfreq/17000000.gpu/cur_freq
GPU curr load: /sys/class/devfreq/17000000.gpu/device/load

Measure:

The GPU frequency is provided in Hz, shown in MHz.
The CPU/GPU temperatures are provided in Celsius multipled by 1000 (milli Celsius), shown in Cesius

P.S. The GUI shows all temperatures for NVIDIA Jetson with additional precision comparing to the default x86_64 platform.

== NVIDIA Jetson models ==

Tested for NVIDIA Jetson Orin and Xavier boards.

Explorer09 · 2025-05-03T10:55:09Z

I fear the option of --enable-nvidia-jetson will make future board-specific customizations add similar configure options. That would make things unmaintainable.

Explorer09 · 2025-05-03T11:00:17Z

Another problem is the conflict with #1620, which is an attempt to unify the GPU meter structure to one interface.

Explorer09 · 2025-05-03T11:02:03Z

linux/NvidiaJetson.c

+   RichString_appendAscii(out, CRT_colors[METER_VALUE], buffer);
+
+   RichString_appendAscii(out, CRT_colors[METER_TEXT], " temp:");
+   xSnprintf(buffer, sizeof(buffer), "%.1f°C", this->values[JETSON_GPU_TEMP]);


Use CRT_degreeSign rather than hard-code a degree sign here.

Fixed. Additionally supported Fahrenheit.

linux/NvidiaJetson.c

dmitriy-philimonov · 2025-05-03T11:20:54Z

Another problem is the conflict with #1620, which is an attempt to unify the GPU meter structure to one interface.

I looked through 'main' branch implementation of the GpuMeter. If I understand correctly, it collects information about the GPU usage from each running process.

NVIDIA Jetson has a different approach - it provides a separate GPU statistics via sysfs / custom nvgpu driver.

Since all the NVIDIA Jetson specific code is hidden under the C define 'NVIDIA_JETSON', there should be no code collisions. Semantically, the switch 'NVIDIA_JETSON' for GPU might turn off all the future code in #1620 and turning on the Jetson specific GPU code (anyway, all the data is already collected by the nvgpu driver).

You could merge the final version of the #1620 first, then I'll figure out how to reuse it correctly, on the next big holidays :)

dmitriy-philimonov · 2025-05-03T11:23:48Z

I fear the option of --enable-nvidia-jetson will make future board-specific customizations add similar configure options. That would make things unmaintainable.

The main purpose of the commit was to minimize the interference with the major code base for the default x86_64 platform. Honestly, I do not want to compile in the nvidia jetson board specific code anywhere else.

What approach would you recommend here?

Explorer09 · 2025-05-03T18:07:35Z

I fear the option of --enable-nvidia-jetson will make future board-specific customizations add similar configure options. That would make things unmaintainable.

The main purpose of the commit was to minimize the interference with the major code base for the default x86_64 platform. Honestly, I do not want to compile in the nvidia jetson board specific code anywhere else.

What approach would you recommend here?

There are two ideas that came in my mind.

The more ideal one: Make the board identifier part of the machine type, so we can have --host=aarch64-nvidiajetson-linux-gnu. But that requires your toolchain to be configured with the same machine type identifier, which is sometimes not feasible.
The less ideal, but easier approach: name the the configure option as --with-board=nvidia_jetson. This assumes that htop would accept patches for additional board customizations, and I don't know the maintainers' attitude on this.

Update: Oh no. Nvidia didn't use a unique machine type for their GCC cross-toolchain. Reference

dmitriy-philimonov · 2025-05-04T16:55:27Z

I fear the option of --enable-nvidia-jetson will make future board-specific customizations add similar configure options. That would make things unmaintainable.

The main purpose of the commit was to minimize the interference with the major code base for the default x86_64 platform. Honestly, I do not want to compile in the nvidia jetson board specific code anywhere else.
What approach would you recommend here?

There are two ideas that came in my mind.

The more ideal one: Make the board identifier part of the machine type, so we can have --host=aarch64-nvidiajetson-linux-gnu. But that requires your toolchain to be configured with the same machine type identifier, which is sometimes not feasible.

The less ideal, but easier approach: name the the configure option as --with-board=nvidia_jetson. This assumes that htop would accept patches for additional board customizations, and I don't know the maintainers' attitude on this.

Update: Oh no. Nvidia didn't use a unique machine type for their GCC cross-toolchain. Reference

@BenBE , as a maintainer, are you agree? If so, I will fix according to the idea №2.

BenBE · 2025-05-04T21:35:25Z

There's some internal discussion still going on. We're still discussing which direction we'd like to move forward in.

dmitriy-philimonov · 2025-06-13T20:45:25Z

Changes:

Rebased. Honestly, I've left all GPU-related code unchanged. It utilized the different kernel API, might work with nvidia jetson one day, who knows?
Additionally pushed the per process GPU memory allocation functionality right into the LinuxProcess class / GPU_MEM field in main screen. Marked it as experimental, because it works with root privileges only. In short, it reads the special sysfs file inside kernet/debug directory which is published by nvgpu nvidia driver, where the dictionary {pid -> gpu_memory} is published.

Added the Action for this functionality. Pressing 'g' hot key the main screen shows only the processes which uses GPU right now. Having the GPU_MEM field, you see the current GPU load per process. Useful, I guess. Hope, you'll utilize the same approach in your future development.

dmitriy-philimonov · 2025-06-13T20:47:49Z

I've left all the deep details in both: the commit message and the NvidiaJetson.c file. Have a look, please. @BenBE

Finally, with "Jetson GPU" Meter and "g" hot key applied, with GPU_MEM field, the "htop" looks like this:

BenBE · 2025-07-15T07:27:59Z

CPUMeter.c

+   #else
   #ifdef BUILD_WITH_CPU_TEMP


Maybe flatten into one #if block as:

#if defined(BUILD_WITH_CPU_TEMP) && !defined(NVIDIA_JETSON) … #elif defined(NVIDIA_JETSON) … #endif

What's the relationship between the macro NVIDIA_JETSON and BUILD_WITH_CPU_TEMP? At a glance they don't seem to be mutually exclusive.

AFAICS, BUILD_WITH_CPU_TEMP is set, whenever you are building with temperature sensor support (i.e. libsensors or similar source), It's also set, when building with NVIDIA Jetson support.

You also could check for libsensors in the first block AFAICS, but that should be properly evaluated it that hits all cases.

The CPU temperature showing code is rewritten.

The duplication is removed.

Additional settings showCPUTemperatureFractional is added.

All decisions are explained in comments.

Machine.c

MainPanel.c

XUtils.h

BenBE · 2025-07-15T07:39:00Z

linux/LinuxMachine.c

   if (settings->showCPUFrequency
 #ifdef HAVE_SENSORS_SENSORS_H
-       || settings->showCPUTemperature
+       || settings->showCPUTemperature /* TODO: looks like this line in the condition might be removed */


Can you explain your comment on this line?

Removed /* TODO: ... */ comment. Let's keep backward compatibility.

Explanation.

The semantics is broken. If showCPUTemperature is activated, the application starts to read CPU frequencies from the system via LinuxMachine_scanCPUFrequency function. There's no connection with the CPU temperature. CPU frequency is not shown in case if showCPUFrequency is turned off. No commentary why it's done. Looks like some old forgotten hack (maybe there was a connection cpu_frequency with cpu_temperature some time ago, or other platforms have/had these connection).

The code inside the linux directory only affects Linux itself, thus there should be no connection with other platforms here. And if the code guarded by this condition no longer has any references to CPU temperatures, then this condition can be removed.

IIRC libsensors is used for CPU temperature stuff, but this was refactored some time ago. I thus think it's more likely a remnant from that refactoring.

linux/LinuxMachine.c

linux/LinuxProcess.c

linux/NvidiaJetson.c

linux/NvidiaJetson.h

dmitriy-philimonov · 2025-08-03T10:12:07Z

Fixed issues, @BenBE, have a look, please.

BenBE · 2025-08-03T11:03:50Z

Action.c

+#ifdef NVIDIA_JETSON
+#include "NvidiaJetson.h"
+#include "ProcessTable.h"


Includes should be kept near the top of the file.

BenBE · 2025-08-03T11:06:37Z

CRT.h

+#ifdef NVIDIA_JETSON
+   GPU_FILTER,
+#endif


No need to define this conditional. Also, probably group near the GPU_ENGINE_x fields.

BenBE · 2025-08-03T11:07:35Z

CRT.c

+#ifdef NVIDIA_JETSON
+      [GPU_FILTER] = A_BOLD | ColorPair(Red, Cyan),
+#endif


Needs to be inserted for every color scheme. Also see the note regarding conditional defines/ordering.

BenBE · 2025-08-03T11:10:06Z

XUtils.h

   return r;
 }

+


Just one blank line between functions.

linux/NvidiaJetson.c

BenBE · 2025-08-03T11:33:28Z

linux/NvidiaJetson.c

+char CPU_TEMP_SENSOR_PATH[64];
+char GPU_TEMP_SENSOR_PATH[64];
+char GPU_FREQ_SENSOR_PATH[64];
+char GPU_LOAD_SENSOR_PATH[64];


Only pre-processor macros should have uppercase names.

Also not quite happy with fixed-size buffers for filenames here.

Renamed, changed to the xMalloc'ed strings

linux/NvidiaJetson.c

BenBE · 2025-08-12T21:16:41Z

XUtils.c

+char *xSnprintfDup(char *buf, const size_t len, const char *fmt, ...) {
+   assert(buf != NULL);
+   assert(len > 0);
+
+   va_list vl;
+   va_start(vl, fmt);
+   int n = vsnprintf(buf, len, fmt, vl);
+   va_end(vl);
+
+   if (n < 0 || (size_t)n >= len) {
+      fail();
+   }
+
+   /* vsnprintf returns number of bytes without terminating null character */
+   size_t slen = n + 1;
+   void *data = malloc(slen);
+   if (!data) {
+      fail();
+   }
+
+   memcpy(data, buf, slen);
+   return data;
+}
+


Isn't this a case for xAsprintf?

Thanks! Really, haven't seen the asprintf() before :)
Non POSIX, but pretty useful.

You rarely ever see it in code, but when you see it, it's quite helpful.

There's often the question regarding whether or not to force that one additional allocation, but when not inside a tight loop, that's usually fine.

BenBE · 2025-08-12T21:18:11Z

Machine.c

+
+   #ifdef NVIDIA_JETSON
+   NvidiaJetson_LoadGpuProcessTable(this->activeTable->table);
+   #endif


Given the Jetson code is placed in the Linux platform directory, I'd've expected this call somewhere inthe LinuxMachine code …

Moved to the LinuxProcessTable::ProcessTable_goThroughEntries.

linux/NvidiaJetson.c

XUtils.h

NVIDIA Jetson device is an insdustrial Linux based embedded aarch64 platfrom with powerful builtin GPU, which is used for AI tasks, mostly for CV purposes. The support is provided via --enable-nvidia-jetson switch in the configure script. All the source code related to the NVIDIA Jetson is placed in the linux/NvidiaJetson.{h,c} source files and hidden by 'NVIDIA_JETSON' C preprocessor define. So, for x86_64 platforms the source code stays unchanged. Additional functionality added by this commit: 1. Fix for the CPU temperature reading. The Jetson device is not supported by libsensors. The CPU has 8 cores with only one CPU temperature sensor for all of them located in the thermal zone file. libsensor might be compiled in or turned off. The additional care was taken to provide successfull build with/without libsensors. 2. The Jetson GPU Meter was added: current load, frequency and temperature. 3. The exact GPU memory allocated by each process is loaded from the nvgpu kernel driver via sysfs and merged to the LinuxProcess data (field LinuxProcess::gpu_mem). The field "GPU_MEM" visualizes this field. For root user only. 4. Additional filter for processes which use GPU right now via hot key 'g', the help is supplied. For root user only. == Technical details == The code tries to find out the correct sensors during the application startup. As an example, the sensors location for NVIDIA Jetson Orin are the following: - CPU temperature: /sys/devices/virtual/thermal/thermal_zone0/type - GPU temperature: /sys/devices/virtual/thermal/thermal_zone1/type - GPU frequency: /sys/class/devfreq/17000000.gpu/cur_freq - GPU curr load: /sys/class/devfreq/17000000.gpu/device/load Measure: - The GPU frequency is provided in Hz, shown in MHz. - The CPU/GPU temperatures are provided in Celsius multipled by 1000 (milli Celsius), shown in Cesius P.S. The GUI shows all temperatures for NVIDIA Jetson with additional precision comparing to the default x86_64 platform. If htop starts with root privileges (effective user id is 0), the experimental code activates. It reads the fixed sysfs file /sys/kernel/debug/nvmap/iovmm/clients with the following content, e.g.: ``` CLIENT PROCESS PID SIZE user gpu_burn 7979 23525644K user gnome_shell 8119 5800K user Xorg 2651 17876K total 23549320K ``` Unfortunately, the /sys/kernel/debug/* files are allowed to read only for the root user, that's why the restriction applies. The patch also adds a separate field 'GPU_MEM', which reads data from the added LinuxProcess::gpu_mem field. The field stores memory allocated for GPU in kilobytes. It is populated by the function NvidiaJetson_LoadGpuProcessTable (the implementation is located in NvidiaJetson.c), which is called at the end of the function Machine_scanTables. Additionally, the new Action is added: actionToggleGpuFilter, which is activated by 'g' hot key (the help is updated appropriately). The GpuFilter shows only the processes which currently utilize GPU (i.e. highly extended nvmap/iovmm/clients table). It is achieved by the filtering machinery associated with ProcessTable::pidMatchList. The code below constructs GPU_PID_MATCH_LIST hash table, then actionToggleGpuFilter either stores it to the ProcessTable::pidMatchList or restores old value of ProcessTable::pidMatchList. The separate LinuxProcess's PROCESS_FLAG_LINUX_GPU_JETSON (or something ...) flag isn't added for GPU_MEM, because currently the functionality of population LinuxProcess::gpu_mem is shared with the GPU consumers filter construction. So, even if GPU_MEM field is not activated, the filter showing GPU consumers should work. This kind of architecture is chosen intentially since it saves memory for the hash table GPU_PID_MATCH_LIST (which is now actually a set), and therefore increases performance. All other approaches convert GPU_PID_MATCH_LIST to a true key/value storage (key = pid, value = gpu memory allocated) with further merge code. == NVIDIA Jetson models == Tested for NVIDIA Jetson Orin and Xavier boards.

dmitriy-philimonov · 2025-09-13T18:42:57Z

Polite ping, @BenBE

BenBE · 2025-09-13T21:54:32Z

Polite ping, @BenBE

NP. Haven't forgotten you, just busy right now (day job). Will take a look as things calm down again; this will take a few weeks though.

Explorer09 reviewed May 3, 2025

View reviewed changes

linux/NvidiaJetson.c Show resolved Hide resolved

BenBE added the Linux 🐧 Linux related issues label May 3, 2025

dmitriy-philimonov force-pushed the nvidia-jetson branch 2 times, most recently from 53914a0 to 68ddb34 Compare May 3, 2025 15:41

dmitriy-philimonov force-pushed the nvidia-jetson branch 3 times, most recently from 0f0f553 to 109046f Compare June 13, 2025 20:33

BenBE requested changes Jul 15, 2025

View reviewed changes

dmitriy-philimonov force-pushed the nvidia-jetson branch 4 times, most recently from 106efc9 to af4c327 Compare August 3, 2025 09:58

dmitriy-philimonov requested a review from BenBE August 3, 2025 10:01

dmitriy-philimonov force-pushed the nvidia-jetson branch from af4c327 to 212c424 Compare August 3, 2025 10:09

BenBE requested changes Aug 3, 2025

View reviewed changes

dmitriy-philimonov force-pushed the nvidia-jetson branch from 212c424 to 82c18be Compare August 12, 2025 20:52

dmitriy-philimonov requested a review from BenBE August 12, 2025 20:59

BenBE reviewed Aug 12, 2025

View reviewed changes

dmitriy-philimonov force-pushed the nvidia-jetson branch from 82c18be to f096e35 Compare August 13, 2025 06:51

dmitriy-philimonov requested a review from BenBE August 13, 2025 06:54

BenBE reviewed Aug 13, 2025

View reviewed changes

XUtils.h Outdated Show resolved Hide resolved

dmitriy-philimonov force-pushed the nvidia-jetson branch from f096e35 to bd4285e Compare August 13, 2025 19:32

dmitriy-philimonov requested a review from BenBE August 13, 2025 19:33

Uh oh!

Preliminary support for NVIDIA Jetson boards #1692

Are you sure you want to change the base?

Preliminary support for NVIDIA Jetson boards #1692

Uh oh!

Conversation

dmitriy-philimonov commented May 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Explorer09 commented May 3, 2025

Uh oh!

Explorer09 commented May 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmitriy-philimonov May 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dmitriy-philimonov commented May 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmitriy-philimonov commented May 3, 2025

Uh oh!

Explorer09 commented May 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmitriy-philimonov commented May 4, 2025

Uh oh!

BenBE commented May 4, 2025

Uh oh!

dmitriy-philimonov commented Jun 13, 2025

Uh oh!

dmitriy-philimonov commented Jun 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dmitriy-philimonov commented Aug 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

dmitriy-philimonov commented May 3, 2025 •

edited

Loading

dmitriy-philimonov May 3, 2025 •

edited

Loading

dmitriy-philimonov commented May 3, 2025 •

edited

Loading

Explorer09 commented May 3, 2025 •

edited

Loading

dmitriy-philimonov commented Jun 13, 2025 •

edited

Loading