Booting problems after using jetson-io.py

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
, ,
1

Hello,

I have been trying to use the jeson-io.py script to enable I2S (pins 12, 35, 38 & 40 of the 40 pin GPIO header). To do it I go to the “manual configuration” menu and select i2s, then I reboot the system. During the startup I get the option to choose between the two kernels, the “default” one and the “custom one”, which is one with the modified device tree. No matter which one I select (custom one is the new default selection) the board does not boot; at most it gets stuck in a blinking underscore. The only way I can get it to boot again is by following"Device Manager → NVIDIA Configuration → L4T Configuration → OS chain A status → (The value is Unbootable if UEFI attemps recovery kernel) choose Normal → Save and exit, reboot, UEFI will try Direct Boot." and flashing a fresh new Jetpack install in my SD card,

The borad is the Jetson Orin Nano devkit 8GB. I have tried Jetpack 6.0, 6.1 and 5.1.3 and I am booting from a 64GB micro-SD card.

Bests,

Jorge

Edits: typos.

2

Would you post a link to the image you are currently using.

The 6.1 has at least one i2c on by default, they connect direct to SoC without mux. Have not checked the other i2c if its live but it should be.

How are you getting the choice of two kernels? I don’t see that on my board.

3

Yes, indeed the 6.1 image comes with I2C routed by default, however note that I am refering to I2S. This is the (6.1) image link >> then “Jetson Orin nano Developer Kit” >> Jetson Orin Nano.

Thanks.

4

Sorry, I did not read it close enough.

For that you will need to create an overlay. So far the instructions in the manuals lead to nowhere. This appears to be an issue that Nvidia is going to have to provide more clarity on regarding building non-trival overlays. The manual has different stories in multiple places. Using the DTC example fails by default because you need to link to tegra-gpio.h and DTC does not link, so I use cpp and did a manual pointing to the .h The content from pinmux spread sheet is not in overlay format…

We are stuck in the mud too trying to get control of gpio header pins.

5

No problem, thanks for your answer. The jetson-io script was pointed from various documentation sources but apparently a lot of people compain about it not working… Lets hope we get some workaround or fix.

Jorge

6

The needed files are actually missing from key functions. I live in a zero trust world and so many things smell, I hope this is just an oversight on their part. Other than this we like the board/SoC but it needs to do more than an i2c port…

7

If that is the case (other than the fact it obviously does not work) I will give up using it to try to configure the device tree. This promised to be a quick and easy way but I will have to try writing the overlay directly, but even for that the documentation is scarce and not very straightforward. Changing the pinmux shoudl not be that difficult…

Jorge

8

I don’t know what is actually going on, stuff references MB1 bootloader. Then a trival overlay example using DTC overlays, then dropping the 3 files into into Linux_for_Tegra directories and that did not work.

The spreadsheet generates a massive pinmux file, that to me seems like more is going on that I don’t understand. 6.1 rev1 is burning on a sd card, trying that. If that does not work then 5.x will go on the sd card. If that does not work this board is out. It did extremely well up until this point.

9

Good luck. As I mentioned in my original post I have already tried both 6.1 and older 5.x versions. Please let me know your outcome.

Jorge

10

Its broken in 6.1 rev 1, it will not launch.

Update:
Just tried jp5.x sd image, splash screen starts then the board is dead…

12

Hi Jorge100,

Let’s focus on the status with the latest JP6.1.

Please refer to the following steps to use Jetson-IO to enable I2S on the devkit.

$ sudo /opt/nvidia/jetson-io/jetson-io.py
Configure Jetson 40pin Header -> Configure header pins manually -> [*] i2s2 (12,35,38,40) -> Back -> Save pin changes -> Save and reboot to reconfigure pins -> ENTER -> devkit reboot

I’ve verified above steps working on Orin Nano devkit with JP6.1.

You don’t need to select here since Jetson-IO should configure the JetsonIO as default.
You can also check /boot/extlinux/extlinux.conf to confirm.

Please share the full serial console log for further check.

13

That is the same line I use to launch.

I wiped out everything and started over to rule out something I might have done to break some of this.

Only thing I can see at this point is your on a different version of hw or 6.1?? No reason why this would not work if both systems are running the same. My board does boot, its the jetson-io.py that breaks and will not launch. It never will launch on my board because several of the modules failed to install on the target. They are in the BSP in the sdkmanager download.

What version of sdkmanager are you running, it seems like that might be the problem. Not so much jp6.1. That might also be why the 3 overlay files are not being picked up and placed on the MB1.
sdkmanager that is on the 22.04 box is version 2.2.0.12021

14

Please share the result of the following command on your devkit for further check.

$ cat /etc/nv_boot_control.conf
$ cat /etc/nv_tegra_release
15

Regarding this, I am booting by flashing the SD card directly with etcher.

I will retry the steps above (which are the same I already performed) and get back with the full logs ASAP.

Jorge

16

Hello,

After attempting the process again, it keeps failing. Below I attatch two serial log captures: a “normal booting”, which I captured after a fresh Jetpack 6.1 install, and a capture just after rebooting the jetson after changing the pinmux as stated in your answer:

NORMAL_BOOT.txt (101.5 KB)
BOOT_AFTER_JETSONIO.txt (210.8 KB)

Note that I was not able to check /boot/extlinux/extlinux.conf since the board is not booting correctly, please let me know if I am missing something or there are further checks I can do.

Thanks,

Jorge

17

Suspect the bootloader is not matching the image. I have been bouncing between 6 and 5 and use the sdk manager. Might try using sdkmanager and see what happens.

18

I don’t know if this is even close, but I just made a mess trying to create flash.sh to move the kernel over to the target. Suspect something got messed up during the botched flash. Well, make a long story short tried to reflash and it would not boot after that. Went into sdkmanger and it was breaking. What I did was pull NVMe and made it blank, then it would boot after a fresh flash. Not sure what happened, I don’t believe the script wipes the drive and assumes it is blank when starting out. So, maybe wipe your media and try the flasher script from the manual.

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
  --showlogs --network usb0 jetson-orin-nano-devkit internal
19

It seems you are using R36.2.0 from Jetpack 6.0 DP, which is a developer preview version.
Please use R36.3.0(JP6.0) or R36.4.0(JP6.1) to verify.

20

Your command of l4t_initrd_flash.sh will format and re-partition the disk, which is expected.
If you are using the devkit, we would strongly suggest you reflashing it with SDK manager in case the error is caused from any customization.

21

Hello,

I have attempted to repeat the procedure making sure the downloaded version has no “DP” in it (Jetpack 6.1), however, It still does not work. Could you please provide me the link to the correct version since the one I downloaded from the download page appears to be wrong .

Still aparently that is not the issue since other people are having the same issue with different versions. However, I would love to try your suggestion, but downloading a version without “DP” in the name apparently is not enough to avoid a developer preview; please could you kindly point me to the download page for the correct version (with a specific link or instructions)?

Below I attach the new logs (which are of the same Jepack version), as well as an additional log after setting the booting mode to “normal” after having used jetso-io.py

Boot_After_JetsonIO_setToNormal.txt (284.1 KB)
Normal_Boot_2.txt (104.6 KB)
Boot_After_JetsonIO2.txt (213.0 KB)

Thank you very much for your time,

Jorge