The Jetson TX2 cannot load using the Jetpack4.4 system initialization interface

We put TX2 8GB module on the baseboard we developed for use. If the L4T version is 32.4.3, after the system is started, there will be no initialization interface pop up. We have tried using the new version of the system, there will be initialization interface pop up, and the core can be used normally on our board. However, we were unable to initialize the system on 32.4.3.
Is there a good solution? We do not currently want to upgrade the L4T system version of TX2 core.

You would need to post the full serial console boot log (without “quiet” in the kernel aruments, e.g., removing “quiet” from “/boot/extlinux/extlinux.conf”) to see what is going on. Most likely though it will come down to the device tree needing to be updated for your carrier board layout. If you have any difference between lane routing on your carrier board versus the dev kit be sure to describe it. You might also attach a copy of your current device tree.

Sorry for not replying to you in time, the attachment is the system startup log printed through the serial port.
TX2_JP44_NO_CONFIG.txt (29.6 KB)

Someone with more detailed knowledge will need to answer, but all looks good up until the Linux kernel loads. Then the log is short, seems to try to deal with sound, and finally fails regarding a regulator. The sound and i2c and much of this looks like it is related to the DDC wire query over HDMI, so you might mention if there is any modification related to video or HDMI, which is my bet on where the device tree went wrong.

tx2_jp44_no_config.dts (318.1 KB)
I uploaded the dts file, can you analyze it for me? See if the system cannot be initialized due to the device tree.

I don’t know enough about lane routing to be able to answer. Someone familiar with that specific hardware would be able to answer since you’ve posted the device tree, but might still need to know more about differences in your hardware lane routing versus the developer carrier board.

However, when I use JP4.5.1, it can work normally, and there is no problem with the hardware path

Device tree depends in part on the driver, in part on the device, and in part on lane routing. I suppose it is possible that some combination of driver and device tree changed between the two releases. For reference, L4T R32.4.3 is from JP4.4, and L4T R32.5.1 is associated with JP4.5.1. It might also be as simple as the older release having a bug which was fixed when going from R32.4.3 to R32.5.1. Is there a reason you must use the older R32.4.3? Unless it is a really good reason I’d probably just move to R32.5.1 and get the bug fixes.

Because we also use NX modules, the software platform used is developed for the 32.4.3 version. If we upgrade the system, our software also needs to be upgraded. At present, we still need to use 32.4.3. Version.

The system version used by our NX platform is also 32.4.3, so we hope to keep the system version consistent for our maintenance.

It might be possible to find the reason for the bug just by comparing source from 32.4.3 and 32.5.1, but if this is just a bug fix, then it isn’t likely you’ll get a bug fix intended for patching 32.4.3 unless you bisect this yourself. Basically, it is a case of narrowing it down to the particular code section.

Regardless of who debugs it, likely you need a full serial console boot log in addition to the device tree you posted, and probably also a copy of the “/proc/config.gz” (which is just the kernel configuration; this might have changed on a third party carrier board). Unfortunately, to some extent, if this is dependent upon the carrier board and device tree there might not be anything which can be done without one of those carrier boards to experiment on. Even if you can’t get a complete answer here it might still be useful if you post the serial console boot log up to the error, and if possible, the config.gz to go with the device tree you posted.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.