I have a AGX Xavier 32GB module and a STEVIE carrier board. The board vendor has provided pinmux files and kernel/device tree patches, from which I have been able to start with the L4T BSP and sample rootfs, apply their patches, run pinmux-dts2cfg.py, build the kernel, flash the device, and boot it successfully.
I am trying to bring this forward to r32.7.2. Every step of the patch, build, and flash process works without issue, but the device does not boot. I do not even get early console output from the kernel booting.
I’ve consulted the release notes for r32.7.2 to look for any obvious sources of incompatibility, but none noted seem relevant to me.
What is the next step in troubleshooting this issue? For example, can I confirm that the bootloader is working? (I have never seen console output from it on this device.)
No, I’ve never see the bootloader log. I have only seen the kernel log (by removing quiet from the kernel command line and attaching a RS-232 cable to the debug interface on the carrier board).
Is there a guide to seeing the bootloader output? Or would this be specific to my carrier board? There is no mention of it in their documentation.
I noticed that between r32.6.1 and r32.7.2, the MB1 BCT configuration file has changed significantly. Here is a diff.. The pinmux version number changed from 1.0 to 1.4, for example, and there are many changes.
I used Excel to compare the vendor’s pinmux Excel spreadsheet with the original template from the same version. I wrote a VB script to find the modified values from the original template, then applied these changes to the latest version of the template, version 1.4. Then I rebuilt the .cfg file and flashed the device. That succeeded.
I think there are improvements NVIDIA could make to this process:
I don’t think NVIDIA publishes the old of the Pinmux spreadsheet. I just happened to have one lying around. If I didn’t, it would be even more challenging to figure out what customizations were made.
The release notes should call out the change to the Pinmux version numbers used. If there is an incompatibility between the new bootloader release and the older Pinmux .cfg files, this should especially be called out.
Just want to clarify this. I feel there are some misunderstanding here…
First, for your suggestion here:
I don’t think NVIDIA publishes the old of the Pinmux spreadsheet. I just happened to have one lying around. If I didn’t, it would be even more challenging to figure out what customizations were made.
There is actually no need to keep a “old” pinmux spreadsheet… we have each cfg file in each l4t release.
Also, these things do not matter because it would change from one carrier board to another. For example, if you use the board from vendor A, you may need to change pinmux when you upgrading. However, maybe you don’t need to do that when you use board from vendor B.
The release notes should call out the change to the Pinmux version numbers used. If there is an incompatibility between the new bootloader release and the older Pinmux .cfg files, this should especially be called out.
Actually, there is no direct link between pinmux version and L4T release version. For example, “you must use pinmux 1.x with rel-32.x.x” is not a valid statement…
And some clarification for your issue…
You are using a 3rd party carrier board. Actually, the board vendor should take the responsibility to do the work you are doing now. The board vendor here, I mean the Diamondsystem who released the Stevie board.
And the issue you are talking about here seems related to pinmux. Which means the hardware is crucial here. The board vendor has the info of the hardware but I don’t have it.
Honestly, if you cannot provide a log here, everything you are talking about has no evidence but just a guess. It is kind of blind test that you “fix” this issue by replacing the pinmux. But we will never know what is the exact issue. For example, maybe that board vendor has special use on UART, and that causes something go wrong in boot up. Change the pinmux somehow disable the use of that UART and bypass error.