Right now I am using the JetPack 3.3 and I would like to know How can I get the tx2 processor to have the same specifications listed below?

Processor: ARMv8 Processor rev 3(v8l) x 4 ARMv8 Processor rev 0(v8l)x2
Graphis: NVIDIA Tegra X2 (nvgpu)/integrated
OS type: 64-bit

The CPU is already ARMv8-a/arm64/aarch64, although I don’t know if the revision is 3 (at least some cores are rev. 3). See “cat /proc/cpuinfo”. The two cores which are “rev 0” would be the Denver cores. Are you running into issues?

I was having issues with the onboard camera. I was not able to find it by the path /dev/video0. I thought having the same processor as the specifications above will help me to solve the issue. But, I found out that the SoC light does not turn on. Is there any way to fix this?

Does the system seem to otherwise boot normally and run?

The file “/dev/video0” is the responsibility of a driver. Many files with special purpose use (those in “/dev”, “/proc”, or “/sys”) are not real files at all, but are instead a direct communications with a driver (produced by the driver itself and not existing on hard drive). The driver itself will produce different “/dev/video#” files depending on what cameras it sees attached whereby the driver is the right one for that camera.

So there are usually two related ways this can go wrong. One is that different drivers for different camera formats may actually produce a different file in “/dev”, and so if the driver is the wrong format, and yet running normally, you would access the camera using a different device special file (there would be a file, but the name wouldn’t be what you expect). The other issue is that a driver which is intended to create a “/dev/video0” file may not create that file at all unless it actually sees the camera and is able to initialize.

What kind of camera is it? How does the camera connect, e.g., USB versus a CSI MIPI camera?

Check the kernel message if any error to probe the sensor driver. (dmesg | grep -i ov5693)

I have this processor.

The CPU is generally referred to as the processor, while a question about the GPU might be better phrased as “compute architecture for the GPU”. I have been assuming you were asking about the CPU, and not the GPU. Can I verify that it is the GPU architecture you are referring to? If so, here are some summary details related to GPU architecture:

  • Maxwell TX1, Nano: 5.3 (sm_53)
  • Pascal TX2: 6.2 (sm_62)
  • Volta Xavier: 7.2 (sm_72)
  • Nano is GM20B GPU.

nvcc example:

-gencode arch=compute_72,code=sm_72

Here is a URL related to the topic:

In that URL the Titan V is listed as compute_70, sm_70.

Is this what you were looking for?

I run into a message that it says OS(28,No space left on the device).
After running “cat /proc/cpuinfo” it shows that the revision is 3.

The “/proc/cpuinfo” is for the CPU architecture. Compute architecture is for the GPU. A user space program depends on being compiled for that CPU architecture, while the CUDA part depends on being compiled for that GPU architecture. If CPU is incorrect, then the program itself will fail with exec format error. CUDA has its own error messages, but the error will differ from “exec format” error.

No space left on device is a serious problem. Are you talking about the Jetson, or are you talking about the host PC doing a flash? Either way this means disk storage is so full files cannot be saved.

I am talking about the Jetson TX2. I do not have issues with CUDA.

The system CPU architecture is already correct. Errors related to exec format error should not occur. Issues related to insufficient space would be an entirely different issue, possibly fatal to many cases. The “no space left on device” would be in need of solving before anything else. If you are able to log in, e.g., via serial console or ssh or any other means, what do you see from “df -H -T” (I assume the message is on the Jetson, but if not, then the same question would apply to the host PC)?

I am using the SSH to log in to my Jetson TX2

This is the error that I get in the Jetson TX2 where it shows that it does not have space left on device.


Your root partition is full. There is essentially no possibility of most operations succeeding. It is actually lucky that ssh is able to log in (which implies there is still a tiny amount of space left for temporary files…you are very close to ssh failing). Any files you can delete of any size is critical right now to avoid losing the entire installation (you could still clone and work on the clone and then flash the clone, but direct access to delete is much easier). How much can you delete?