I tried to add a fake display because TeamViewer does not show the correct resolution of the screen. I modified /etc/X11/xorg.conf file and now the device won’t show any display. I am trying to modify that file and revert the change but there is no way on seeing the terminal. Recovery mode does not work. Boot options don’t work either.
Does serial console or ssh still work?
I never got ssh working. I am reading about serial console. Can I use the terminal there? Any good guide to follow?
Serial console is by far the best rescue you can get in most cases. Much of the system can fail and this will still allow a login. If serial console works, then you can easily edit the xorg.conf file. If there is no access otherwise, then you’ll end up having to flash. You could clone first, and then edit the clone, followed by reflashing the clone, but there have been some clone issues for Orin which I don’t know if they are solved yet (a clone could still be used for restore, but the process would be slow and require a lot of disk space). Serial console is just simple and fast for such a thing compared to anything else.
I am trying to set up the serial console following the headless configuration steps in Getting Started with Jetson AGX Orin Developer Kit | NVIDIA Developer
When I connect the device to my pc the ports are not recognized. I have tried Windows and MacOs.
Trying Ubuntu 20.04 and tried running these commands:
dmesg --follow:
I am using the UsbC to usbA cable that comes with the jetson orin.
I seem to have lost my USB-C cable, so I cannot plug it in to look at devices. However, are you using the USB-C next to the 40-pin header? The dmesg log shows USB is working, and detecting the right manufacturer and product ID. What it does not show is detecting that the device is a serial UART (if it had, then the device special file would have been both logged and created).
The part which does show up is correct for the starting USB log message for either (A) the serial UART being detected, or (B) the Jetson in recovery mode being detected. Was the device booting normally, and not in recovery mode?
Btw, the tty listing is useful, but it cuts off some of what is there. An actual text log, e.g., via ssh or scp is better if possible (I realize you might not have that access). A shortened list which would be useful is “ls /dev/ttyS* /dev/ttyTHS*”.
Note that if “/proc/config.gz” does not exsist, then a kernel feature is missing. This file is not a real file, but is instead a kernel feature in RAM which is pretending to be a file. This indicates perhaps a custom kernel with a serious configuration error. Is this a default kernel?
I am using the USB-C next to the 40-pin header. What do you mean with ‘Was the device booting normally, and not in recovery mode?’ . If if plug it in booting normally the device is not detected, if I plug it in recovery mode (pressing the recovery button and then power it on) I get those messages.
I read that ‘/proc/config.gz’ does not show because I need to build the kernel with IKCONFIG_PROC enable. Do I need this? Do you have any reference to enable this? All the tutorials I am reading give me errors. I installed Ubuntu 20.04 I don’t know how that will come with serious configuration errors…
If the kernel was installed without correct configuration, then a lot is explained by this. The device special files in “/dev” are not real files, they are the result of drivers in RAM pretending to be files. If the driver fails to load (including kernel modules which cannot load due to misconfiguration), then the files will be missing. The missing IKCONFIG_PROC shows the kernel was not initially configured to match the default Jetson configuration. Can I verify this is a custom kernel? Would it also be possible to show the output of “uname -r” and what process you used to configure?
I ended up reflashing my jetson. Where can I find all Nvidia documentation to accomplish this? How to configure the Kernel to match the jetson configuration?
In the documents (assuming AGX Orin from the R35.1 URL you mentioned) there will be a “kernel customization” section. I’ll explain some about configuration here, but a related URL (perhaps covering slightly different content) is here:
https://forums.developer.nvidia.com/t/problem-smb-jetson-nano/193640/11
What it comes down to is that the kernel source is not just one program. A kernel is really a framework for executing a lot of drivers and computer management software. Unless every computer has exactly the same hardware arranged in exactly the same way there cannot really be just one “kernel”. A kernel is really an arrangement of many “standardized” modular subcomponents brought together something like a conductor in an orchestra would do for music. At the time you build a kernel that arrangement is in the file “.config”, located wherever your “intermediate” output is.
By intermediate output location I usually mean where someone has specified the “O=/some/where”, separate from the untouched pristine source code. One can build directly in the source code, in which case that would be where .config is found. Any use of “make mrproper” makes source code pristine, and thus this would remove any .config.
One way to get NVIDIA’s factory shipped configuration to that “.config” file is with the “make O=/some/where tegra_defconfig” target. This is not truly “matching” the running kernel, but unless you’ve modified your kernel, then by coincidence this will almost match. I’ll say more about “almost” below. Most of the time using tegra_defconfig gives you a match.
After some base configuration, e.g., tegra_defconfig, then it is safe to use an editor (such as menuconfig or nconfig) to add new features (at least in the form of modules).
On a running Jetson you will see file “/proc/config.gz”. This is not a real file, it exists only in RAM, and is the kernel pretending to be a file. This file is truly “almost” an exact match to the running system. Even if you’ve modified the kernel, then this will still be as close to a match as you can get with one minor exception. If you were to copy “/proc/config.gz” to your empty and pristine intermediate output location, the “O=/some/where” location, then “gunzip config.gz” to decompress it, and finally to rename it to “.config”, then you’d have a near-perfect match:
# The following is not quite correct since this is all on the Jetson, and you
# are probably cross compiling from the PC; just imagine using scp instead
# of cp to make copies to the $TEGRA_KERNEL_OUT of the host PC. You
# might need to first copy config.gz to a non-"/proc" location on the Jetson
# to the PC to start.
cd $TEGRA_KERNEL_OUT
cp /proc/config.gz .
gunzip config.gz
mv config .config
This is because the kernel itself is telling you its actual compiled configuration.
Very subtle and very important: The “almost” part. The actual features the kernel runs with is truly an exact match; either the tegra_defconfig being a feature-wise exact match to a factory setup, or the config.gz being a feature-wise exact match to the running kernel. However, a kernel is a combination of features along with where it looks to find kernel modules. That location depends on the output of the command “uname -r”. This in turn depends on the specific version of the kernel software (e.g., 4.9.140 is one example) along with the suffix from the kernel compile time string assigned to “CONFIG_LOCALVERSION”. Jetsons ship with this string being set to “-tegra”, and thus a 4.9.140 source would produce “uname -r” of “4.9.140-tegra” for that example CONFIG_LOCALVERSION. Should the kernel version and CONFIG_LOCALVERSION match, then the module search location will match.
Kernels with matching configurations can reuse existing modules. If you merely add modules (in addition to what was already specified), then the same kernel can use both old and new modules (all you would need to do is copy the new module file to the original module search location). In some cases one can add a new kernel feature which is integrated (versus module format) and the new kernel can reuse old modules without rebuilding modules (but not in all cases, in which case you’d want to change the “CONFIG_LOCALVERSION” and install all new modules in the new module search location). When you subtract integrated kernel features it is probably best to recompile all modules and change CONFIG_LOCALVERSION (even if you can get away with it you might run into unexpected issues at a later date, so in such a case I just rebuild the kernel Image along with modules).
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.