The nVidia driver requires the X11 ABI from the L4T release. The newer kernel is likely working with a different X11 ABI. In that case you would either have to downgrade the X11 ABI to use the nVidia driver, or else go to the nouveau software-rendering driver. This latter case implies loss of hardware acceleration for both video and CUDA (the GPU direct access will be gone).
That’s a rather big topic. There are a lot of files tied in to X, and the Linux kernel itself may provide its support based on your newer ABI. Even if the kernel does not need ABI changes, as soon as you downgrade the Xorg server you will suddenly find a chain of other things also needing downgrade…the task is far from trivial.
If I were to do this I would start with the current Xorg source and try to build it to match what you have directly on the Jetson. Then I would see if I could use that same environment to build the older Xorg source…very likely you will see a list of missing functions due to libraries being the wrong version. This would then mean getting that older library software and building that…putting in the prerequisite library version one at a time. Each library may also have its own prerequisites and imply the need to downgrade something else. If you get to the point where glibc itself needs downgrade, then you need to build a “glue” wrapper to act as a proxy between newer glibc and the library interface required by the older software.
If you get all of that done, then anything calling a kernel system call will need the same thing…if the kernel only supports a newer interface, then you may have to make changes in either the kernel or the Xorg server.
There is a saying…“if it were easy, someone would have done it by now”. Someone who is an expert in the Xorg software could likely do the job, but for most people this wouldn’t be practical.
The above link ends with this sentence:
" If you intend to use or repurpose your device for use with upstream U-Boot and Linux kernel, you may ignore nvflash, create a flashable image using cbootimage, write that image to the eMMC’s boot sector(s), and then place a standard partition table at the beginning of the eMMC’s general region. "
That’s me, but I have no idea on how to use cbootimage to create a “flashable image” which comprises all eMMC partitions I need to boot the board
Now, I can use tegra-uboot-flasher to update u-boot, but I cannot upload anything with nvflash, so I’m wondering how to use those two tools together without one compromising the other, or if I can use only tegra-uboot-flasher to update other partitions, including the one where kernel and dtbs are…
I first used standard L4T flash.sh (it wraps nvflash); Compiled the mainline kernel with cross compile. Replaced zImage and .dtb files on /boot. Modified /boot/extlinux/extlinux.conf - with right .dtb file name.
Updated the u-boot to mainline and flash it with those tegra scripts.
The main point is that kernel update is just replacement of files at /boot
This sequence works for me.
Hope it helps
That should work yes, problem is that once you use tegra-uboot-flasher scritp, you cannot use nvflash anymore (at least, I can’t).
I’m keeping zImage and dtbs in a separate partition, but that does not change the main point here: tegra-uboot-flasher makes nvflash unable to read partition table, so a complete re-flash of the eMMC (the --create option, I guess) is required, and this is quite bad if you need to replace kernel image often.
At least, this is my understanding of the issue…