JetPack 4.5 Production Release with L4T 32.5

@WayneWWW should chime in here, but I believe the recently released IMX477 support package was meant to have the DTB flashed to the target in place of the current kernel/BL DTB, not loaded via U-Boot using FDT in extlinux.conf. That support (FDT load from disk) is in flux, as we’ve found that some recompiled/modified kernel DTBs can cause a phandle conflict with the internal DTB that CBoot/U-Boot have modified during HW probe, and possibly cause system instability. We’re looking into using DTB overlays (DTBO) as a possible solution. But for now, unless the changes are small and don’t involve phandle re-ordering by the DTC, I think loading of a kernel DTB via FDT in extlinux.conf should be de-emphasized until I can fix this in U-Boot.

Tom

1 Like

Note that I’d still like to see your entire boot log, @ssvemail1987. The kernel cmd line will show the root= arg, which if you are booting from USB s/b root=/dev/sda1, or the PARTUUID of your USB device.

Hmm, actually I would suggest @ssvemail1987 could file a separate topic for your own issue.

This thread seems has many kinds of topics. Maybe a separate one can help us focus on your issue.

Is there a simple guide on how to permanently switch over the boot from the SD card to an M.2 SSD inserted on the M.2 port of the Jetson Xavier NX?

I’ve been using the rootOnNVME hack from JetsonHacks for this up till now, but that still relies on the MicroSD card for it’s initial boot before it switches over to the M.2 SSD.

And as I experienced yesterday, updating to a new JetPack OTA with a system configured this way leads to a mess.

I had to reflash the SD card with the JetPack 4.5 image and go through the whole setup procedure again (including the rootOnNVME hack) to get back to my working setup.

There has to be a more stable way to do this though.

Any simple instructions out there to achieve this?

Hello, please tell has Python upgrade happen? Python still python 3.6.9?

Please give step-by-step instructions on how to do this on jetson nano 4gb. I’m new to this. Installed everything with a script IMX477 - 12MP HQ Camera - Arducam

Hi, @ssvemail1987

Please file a new topic and we can teach you there.

ок

@pieterjan.kuyten JP 4.5 now natively supports booting the rootfs from USB/NVMe. Once you have booted your system from a JP 4.5 SD card its has updated the onboard firmware to support this. There are official instructions here on how to create a bootable NVMe drive but you could also use the ‘copy rootfs’ script from JetsonHacks to copy you working SD card rootfs to the NVMe drive and change /boot/extlinux/extlinux.conf accordingly to point to your NVMe drive instead of the sd card. After that you should be able to boot directly from your NVMe without the sd card inserted.

1 Like

Hi,

When will python 3.9 be supported on Jetson Nano?

I’ve used nvcr.io/nvidia/l4t-base:r32.5.0 and installed python 3.9 from sources inside docker.
I’m trying to run a simple object detection script in docker on Jetson Nano.

If I run my python script in the docker image without the parameter “–runtime=nvidia” then it says: at “import pycuda.autoinit”

File “/usr/local/lib/python3.9/site-packages/pycuda/autoinit.py”, line 2, in
import pycuda.driver as cuda
File “/usr/local/lib/python3.9/site-packages/pycuda/driver.py”, line 62, in
from pycuda._driver import * # noqa
ImportError: libcuda.so.1: cannot open shared object file: No such file or directory

If I run my python script in the docker image with the parameter “–runtime=nvidia” the it says: at “import tensorrt as trt”
ModuleNotFoundError: No module named ‘tensorrt’

on nano I have tensorrt here:
/usr/lib/python3.6/dist-packages/tensorrt
/usr/lib/python2.7/dist-packages/tensorrt
and the same is visible inside docker when it is run with “–runtime=nvidia”.
(If I run without “–runtime=nvidia” then the tensorrt folder is not visible from docker.)

thanks
Lajos Kelemen

We found an issue on Jetson Nano that it was not able to load kernel, kernel-dtb and initrd from USB or NVME. The fix for this issue is in a python script that we have posted now here: https://developer.nvidia.com/l4t-payload-updater-t210

We are updating the documentation as well but please follow below steps for flashing USB or NVME for Jetson Nano:

Step 1: Prepare rootfs by untaring the BSP, untaring the rootfs and running apply_binaries.sh as mentioned in section “Setting up your root file system” in the developer guide here: https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/rootfs_custom.html#wwpID0E0NB0HA

Step 2: Copy the python script which has the fix from https://developer.nvidia.com/l4t-payload-updater-t210 to rootfs/usr/sbin/l4t_payload_updater_t210

sudo cp <l4t_payload_updater_t210.py> rootfs/usr/sbin/l4t_payload_updater_t210
sudo chmod a+x rootfs/usr/sbin/l4t_payload_updater_t210

Step 3: Follow the instuctions for flashing to USB or NVMe from https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#wwpID0E02L0HA

Please remember to remove the microSD card from Jetson Nano or else Jetson Nano will try to boot from microSD card.

Also, plase remember that to load from USB, one need to have an update QSPi, so just bootup with JetPack 4.5 SD card image once which will update the QSPi and then you are good to go from then on.

1 Like

This tarball is the old version for 4.4. I tried it and doesn’t work with 4.5.

Since loading DTB using FDT is in flux, will this affect how SPI is enabled?

1 Like

@DicksonChow,

If you are modifying the DTB source to enable SPI, the best course is to then flash your new DTB to QSPI or eMMC, depending on the board (Nano or TX1). That ensures that TegraBoot/CBoot see the SPI nodes from the get go, and U-Boot passes them on to the kernel on boot, and DTB merge isn’t needed (no FDT line in extlinux.conf).

If you are making minor mods to the DTB, then DTB merge might still be OK, as it’s only large changes like IMX477 camera support, etc. that cause the phandles to be re-indexed that can cause a problem on merge & possible boot problems.

Best practice is to reflash any DTB modifications you make, for GPIO, pinmux, etc. and avoid using the FDT load option, if at all possible.

Tom

Hi ronzelver,

I tried your suggestion, but it doesn’t work. The NX keeps resetting if I remove the SDcard. Only when I put it back in and do a cold boot does the NX boot to Linux.

Did you change the /boot/extlinux/extlinux.conf on the NVMe to point to the right rootfs location (on the NVMe)?
I had initially an issue because the XHCI driver was not detecting the USB device in time. That was solved by inserting a usb reset in the U-Boot boot script.

@DicksonChow , the link has been corrected https://developer.nvidia.com/rpi-imx477-support-nano-2gb-325
Please use the above link for JP 4.5

1 Like

Approximately how long should it take to flash QSPI? I created an image using jetson-disk-image-creator.sh and it went through the usual proces, but it’s hung at the end of the first boot setup after selecting to flash QSPI. The QSPI has not been updated otherwise.

Edit: it completed eventually. Just had to be patient.
Edit2: now it’s doing the first boot setup again, so it seems there is an issue
Edit3: it works after using the official image to flash QSPI first

Also, loving the new logo. Much better than the old one.

I replace the line below in the /boot/extlinux/extlinux.conf file:

APPEND ${cbootargs quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

with

APPEND ${cbootargs quiet root=/dev/mnvme0n1p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

This leads to a reset cycle when I reboot the NX without the sdcard inserted.
Maybe there is another change that must be made in order for this to work, but its not clear to me what that change would be.

Debug with serial console tool will provide more log for us to know what is going on exactly.

1 Like