Can't boot 4.4 kernel on L4T 32.3.1

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hello.

I have a TX2 machine with Linux4Tegra 32.3.1 installed (via Jetpack 4.3). I also have a custom Linux 4.4 kernel tree with some additional drivers which I need to use. This kernel worked well on L4T 28.2.1 (Jetpack 3.2), but I’ve been unable to make it boot on the newer system.

When I try to boot, I get no output from the serial console. The network and the HDMI output don’t work either (the latter keeps showing the NVIDIA logo), so I assume it isn’t booting at all. I also tried kernel images bundled with Jetpack 3.x and the result is the same. On the other hand, I tried many 4.9 images and they always boot (in some few occasions they gave me some error at boot, but at least they always produce console output).

This doesn’t seem to be related to the signing of images, because that’s never been a problem with the 4.9 images. Boot parameters on extlinux.conf don’t seem to be the cause either.

Are there some changes related to CBoot or U-Boot that could be causing this? Or some other components?

In such a case, how feasible would it be to adapt either such component or the kernel to solve the issue? Or do you consider it would be easier to migrate to 4.9 instead?

2

The older releases will just get in the way as newer releases come out. I would strongly suggest porting your drivers to the 4.9 kernel. Keep in mind that some time in 2021 even the 4.9 kernel will end up migrating to a 5.x kernel, and knowing how to port the driver will end up as good experience for some future 5.x kernel.

The boot software is itself closely related to the kernel config, and that config can be quite different in places when comparing 4.4 and 4.9, especially where related to boot. I couldn’t tell you about the specific issues, but if you were take the config (such as via “/proc/config.gz” when running that kernel) of both kernels, then I’d expect trying to transplant the 4.4 kernel config into the 4.9 kernel config (or vice versa) would have some failures (such as unknown symbols or different dependency chains using new features). Any way you look at it porting a single driver is easier than porting an entire kernel.