Hi, I am using the Xavier AGX 32GB developer kit. I noticed the Linux desktop doesn’t come up when I select a custom kernel (L4T 32.4.3 [ JetPack 4.4 ]) during boot. I must be missing something in the build.
I would suggest you to first check that the compiled kernel and the kernel modules match. I have seen cases where the mismatch between the two, causes the board to show nothing more than a black screen after the kernel messages are shown during boot.
This is very easy to check,
Get the kernel name by running the uname -a command.
Check the modules with: ls /lib/modules
Make sure the prefixes of both the kernel and the modules match. If you are unsure, please share with me the results.
If the test proves that there is no mismatch between the kernel and the modules. I would suggest looking at the changes you performed on both. You can use the ./flash.sh -r to perform a quick flash and restore the kernel and the device tree to its original. And then test one by one, yo pinpoint the source of the problems.
Please let me know how the testing goes. If you still have issues, we can look for a different approach.
best regards,
Andres Campos
Embedded Software Engineer
See the kernel and modules test you detailed below:
nluong@nluong-desktop:~$ uname -a
Linux nluong-desktop 4.9.140-tegra #1 SMP PREEMPT Thu Jun 25 21:22:12 PDT 2020 aarch64 aarch64 aarch64 GNU/Linux
nluong@nluong-desktop:~$ ls /lib/modules
4.9.140-tegra
Looks like they match.
Unfortunately I have not built a version of the kernel/device tree where the desktop comes up. The only kernel/device tree where the desktop comes up is the original primary kernel/device tree that is loaded onto the AGX during bring up with with SDK Manager.
That being said, I’ve only built custom kernels/device trees. I’ll look into removing all modifications and see if the desktop will come up.
Yes, it seems like the kernel and modules do match. That is a great idea of yours to back track the error.
May I ask what kind of modifications have you done to the kernel and dtb ? Are they driver related, or what is the result you want to achieve with said changes?
best regards,
Andres Campos
Embedded Software Engineer
note, the suffix, -tegra is what CONFIG_LOCALVERSION needs to be set to in order to keep a matching, $ uname -r.
quick question, are you able to boot into ubuntu desktop without any code modification,
in the other words, could you please simply re-compile the public sources and replace kernel and device tree, is it bootable?
thanks
I don’t recall details, but I did see a case once of extlinux.conf customization not honored if there were too many entries (not a bug, but also not documented), as well as a case which was an actual bug where the customized entry had to be the first entry before it could be selected. Just as a test, do not mark your test case entry as the default, but do make it the first entry, and the rest of the entries (e.g., the default) after that entry. If that helps, then you’ve run into that bug.
Note: The above assumes the kernel is not loading the right kernel, but this could be completely wrong for what is going on with your case. What @JerryChang mentions is related to something which prevents part of the kernel from loading…the kernel modules won’t load if CONFIG_LOCALVERSION did not get correctly set during kernel build.
Hi All,
I realized something wasn’t adding up after noting that I rename CONFIG_LOCALVERSION in tegra_defconfig.
The uname -a command should not have returned a matching name in the test I ran earlier. That’s when I realized I had run the test for the wrong entry in extlinux.conf! Sorry, my mistake and a pretty dumb one too.
After deleting the CONFIG_LOCALVERSION entry from tegra_defconfig (in the custom kernel), the desktop comes up! Thanks everyone for your help, I really appreciate it.
Follow up question: Should CONFIG_LOCALVERSION always be left alone (not renamed), otherwise it risks kernel modules not loading?
“CONFIG_LOCALVERSION” shows up as a suffix to the command “uname -r”. The start of “uname -r” is just the kernel version. If you change the base kernel “Image” file, then if you are to reuse the modules, “uname -r” must be the same on both the old and new kernels.
If the new kernel only adds features (rather than deleting features), then you have a candidate for reusing the existing modules. If the base kernel removes something, then likely you need a new CONFIG_LOCALVERSION and all modules.
Normally you must set “CONFIG_LOCALVERSION” as this to use existing modules: CONFIG_LOCALVERSION="-tegra"
Most kernel configs leave this out and expect you to manually add the CONFIG_LOCALVERSION. Any time your kernel modules are not at “/lib/modules/$(uname -r)/kernel/” modules will 100% fail. It would be more accurate to say that you want to have a matching “uname -r” when installing a new kernel Image file…which tends to mean setting up CONFIG_LOCALVERSION and not leaving it blank for the case of Jetsons.