JetPack 4.5 Production Release with L4T 32.5

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

@pieterjan.kuyten,

Note that @ronzelver is talking about Nano, not NX. Nano has native USB and NVMe boot support in U-Boot. Xavier NX uses CBoot, with no U-Boot, and does not (in R32.5) have NVMe boot support, just USB. You can still redirect your SD-boot on NX to have the kernel look for the rootfs on NVMe, to get more space for the OS, etc. That’s done via modifying the extlinux.conf on your SD-card to point the root= arg to your nvme0n1p1 device (you’ve got a typo in your message above - it should be /dev/nvme0n1p1, but you’ve got an extra ā€˜m’ in there, which may explain why the kernel can’t find your rootfs).

We do hope to have NVMe boot support in CBoot for AGX/XNX in the next release.

Tom

Thanks Tom for the reply. The type is most likely because I had to copy my change by hand by typing it in on the forum. The change on the actual file was indeed without the typo.

I’ll await the change for the NX coming (hopefully) in the next release.

@TWarren Thank you for the info! Is there a way to write to the DTB partition on the 2gb / 4gb Nano devkits to sdcard without having to create a new image? This will greatly help in easing prototyping. I tried searching the forums but the info is confusion to me. Thank you in advance for your help!

@DicksonChow,

No, every boot component (bootloaders, DTBs, firmware, etc.) is now on QSPI in R32.5 Nano. There’s no way to have the bootloader look for a DTB on SD-card, it only reads from QSPI. You can write a new DTB to the correct QSPI partition on Nano2GB/4GB easily with the ā€˜flash -k DTB’ command (check the User Guide), and the, as I said above, it’ll be picked up early in the boot process and passed to the kernel via U-Boot.

Tom

2 Likes

Hi @TWarren,

Can you please point me in the right direction where to see a valid procedure (R32.5 JP 4.5) for making an image with a changed pinmux? I managed to make an image but I’m missing something. Pins are not initialized in the desired manner (inputs and outputs).

Thanks!

@dragoslav,

I’ll ask @WayneWWW or one of the other support engineers to jump in here, I don’t usually worry about pinmux changes as all my work is done on our Jetson boards as shipped, i.e. the pinmuxing is already baked in to the DTB. But IIRC, you can generate a new pinmux for a new board/to add support for SPI, etc. by changing the pinmux spreadsheet, and then running the ā€˜generate DTSI’ script in the spreadsheet to give you new pinmux DTSI files that you’ll then have to add back in to your BSP and regenerate a DTB. That DTB is then copied back into your <Linux_for_Tegra/kernel/dtb> directory and reflashed to the board. This procedure should be documented in our User Guide for Nano somewhere, but again, Wayne and the support engineers are the best source for that.

Tom

Hi @dragoslav,

I don’t think your issue is directly related to jp4.5. It should be same on all releases which support jetson nano.
Please file separate topic and we will help you there.

Also, @TWarren 's comment already replied your question, so you can try it first before filing new topic.

@WayneWWW and @TWarren, thanks to both of you!

I will pass my procedure once again and if fail I will fill a separate topic.

Is it me or anyone who experiences this too?

  • I flash my jetson nano kit with SDK to jetpack 4.5. This works just fine but I encounter some problems, So I burn a new sd-card with jetpack 4.2. What I find out now my Jetson nano could not boot from this sd-car with jetpack 4.2 at all it stuck in a loop. It only works with sd-card with jetpack 4.5 …

how to fix this?

I have a Jetson Nano running Jetpack 4.5.

From

  1. the Deep Learning Institute course Getting Started with AI on Jetson Nano
  2. the webinar NVIDIA JETPACK 4.5 OVERVIEW AND FEATURE DEMO
  3. This thread on this forum
  4. NVIDIA Jetson Linux Developer Guide

I have followed many steps towards running my Jetson Nano from USB. However I am not there yet.

I had hoped that running Jetpack 4.5 would put the Nano into a state where running from USB is possible and all I need to do is flash a USB stick with the same Jetpack 4.5 image. After trying this, it doesn’t appear to be possible, though I don’t understand why. My understanding now is that I need to follow a long winded procedure: that I have to download a driver package and a root file system, create a partition on a USB to receive this file system, and copy the root file system across. I have done all these steps except the last one:-
COPY THE ROOTFS FROM A DIRECTORY TO THE USB.

Question (but not my problem)
I don’t understand what makes that too different from just flashing a USB memory device with a working image! What’s the difference?

In addition to the above, there are a few extra steps that I don’t understand their purpose, though I probably don’t need to, as I am happy to just obey.

  1. apt-get install qemu-user-static
  2. apply_binaries.sh
  3. https://developer.nvidia.com/l4t-payload-updater-t210

Some of these seem to be just correcting for elements missing or incorrect in the rootfs image.

My headache now is
Question. How do I create the USB root file system from my ā€˜rootfs’ directory?

The documentation describes a step with two computers. I am using one.
In the documentation a Host computer talkes to a Target Jetson Nano which is in forced recovery mode over a serial cable to the Nano’s small USB connector – the one which can also be used for power. At least, that is how I understand things.

I have prepared my ā€˜rootfs’ directory on my SD card inside my Jetson Nano. (It’s the computer I am using for writing this forum post.)

I feel there should be a very simple procedure for copying the files from SD to USB. However I don’t want to mess things up, as it has taken me a long time to get this far. (My attempts to simply flash the SD card and the USB with Jetpack 4.5 failed miserably with the SD card and USB in a horrible state with 14 partitions requiring manual removal, reformatting, and the SD reflashing with Jetpack4.5, reconfiguring with local keyboard, new swap space adding, etc. I am eager not to have to repeat this.)

So, what is the procedure to move my rootfs directory from the SD in my Nano to the USB memory stick in the back of the same Nano (/dev/sda1) in such a way that I can then remove the SD card, boot from the USB memory and not have to unscrew my Nano’s little aluminium box ever again?

Oh. My worries are that there are a few other little requirements going on somewhere, (i) making sure that something called QSPI has the write contents: ability to boot from USB; maybe a kernel is written to it. (ii) That the steps taken to get the QSPI changed are not run twice - once from SD and then again from USB.

Many thank to anyone taking the trouble to have read this far, whether you know the answer or not!

1 Like

Well, I didn’t see any advice so I just went ahead on my own and followed these steps from 7&8 in Flashing to a USB Drive from NVIDIA Jetson Linux Developer Guide.

$ sudo BOOTDEV=sda1 ./flash.sh --no-flash <board> sda1
$ sudo mkdir tmp_system
$ sudo mount bootloader/system.img.raw ./tmp_system
$ sudo rsync -axHAWX --numeric-ids --info=progress2 --exclude=/proc ./tmp_system/ /mnt

Where sda1 is the device name that the Jetson device assigned to APP.

Unmount the flash drive.

$ sudo umount /mnt
$ sudo umount ./tmp_system

Then I left the USB drive in the Jetson Nano, as I am only using one computer - the Jetson Nano itself for building the USB image, and I rebooted.

It successfully booted just once, but into the SD image, not the USB image and it wouldn’t reboot further without pressing the force reset button.

Now I believe I have a corrupt QSPI because even with no USB memory in the system, and with a fresh Jetpack 4.5 flashed into my SD card, the system isn’t running properly.

Is there a procedure to reset the Nano QSPI to the state it was in when it arrived from the factory, so I can at least start again?

@Ivan.Urwin , sorry for the late response. To reset, you can flash the Jetson Nano using SDK Manager. It will flash the QSPI too.

Also to flash USB drive and work off it on Jetson Nano, i see you have followed the documentation here https://docs.nvidia.com/jetson/l4t/#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#wwpID0E0HM0HA

Did you ensure you ran the instructions at Step 6 as well? I used the same instrucitons when i showcases flashing to a USB drive and booting from it on Jetson Nano in my webinar last week (https://info.nvidia.com/Jetpack-Jan2020-reg-page.html?ondemandrgt=yes#)

Did you ensure you ran the instructions at Step 6 as well?

Yes I did. However it’s possible I made a mistake there. At first I thought I had to copy the file I downloaded. Later I realised that the instructions were to rename it too (by deleting the .py file extension from the download). There was already a smaller file with the same name in the destination directory (from the downloaded rootfs?) with the same name, and so I decided the instructions must mean to overwrite it. There is plenty of scope there for me to have made a mistake.

i see you have followed the documentation here …

I tried to follow the instructions as closely as possible, but ultimately had to combine instructions from various sources. For example an instruction like …

To set up the rootfs
1.Download the following file to your home directory:
Tegra-Linux-Sample-Root-Filesystem_<release_type>.tbz2

… leaves a beginner like me wondering where to download it from and what is the value of <release_type>. So I would follow the written instructions from the documentation but also use google to find the location of the file from the blog of someone who has tried the same thing.

To reset, you can flash the Jetson Nano using SDK Manager

I really don’t seem to be very good at this. I took my instructions from NVIDIA SDK Manager, which told me to download a file called sdkmanager_1.4.0-7363_amd64.deb which I was supposed to install by typing

sudo apt install ./sdkmanager_[version]-[build#]_amd64.deb

This refused to install and I suspect the problem is that this is due to it being for an AMD processor and the computer I am using is my Jetson Nano (ARM processor). I doubt I have an AMD and if I do it will be running Windows! I had similar bad luck with the Docker solution to how to run SDKmanager. From a little background reading the problem might be processor compatibility too. (I have no experience with Docker, but a little reading leads me to believe that docker official images are platform dependent. As late as 2017, Docker official images went multi-platform by having an image per platform to do the same thing.)

Now it’s looking like even using a second Jetson Nano, so that I have a Host and a Target computer might not be enough. I’m still hoping that there is simple way to set up a bootable USB. Copying the Jetpack 4.5 SD was simple in comparison:

1. download image file
2. write to card

@Ivan.Urwin

You may need to prepare a x86 host for sdkmanager. Just as you need a separate host to prepare the sdcard image.

I think maybe you can file a separate topic and we can reply your questions there. This 32.5 post is more like a post to gather the 32.5 issues and many other questions are here too. It will be easier to track your problem with your own topic.

Hi @TWarren ,
I tried JetPack 4.5 on my Jetson Nano , and it’s works well. But when I want to make a copy of the system image and distribute it to other new Jetson nano. It did not start normally. I know, this is because in Jetpack4.5, the bootloader is flashed into QSPI instead of in sd card. This step was done when I first started the original image of jetpack 4.5. But after I clone the sd card image with the dd command, the bootloader is not included.
So, My question is How to make a backup image of jetpack4.5-based system and burn it to the new jetson nano(don’t have QSPI bootloader) correctly?

Besides, i have already try to use L4T(Jetpack 4.5) to clone a Jetson device, command:
sudo ./flash.sh -r -k APP -G backup.img jetson-nano-qspi-sd mmcblk0p1
when went to the following steps, he got stuck, and I waited for about 8 hours, and still couldn’t continue:
[…]
1.3266 ] Applet version 00.01.0000
[ 1.5512 ] Sending bct
[ 1.5513 ] […] 100%
[ 1.7749 ]
[ 1.7751 ] Retrieving storage infomation
[ 1.7782 ] tegrarcm --oem platformdetails storage storage_info.bin
[ 1.7808 ] Applet version 00.01.0000
[ 2.0042 ] 00000003: Could not initialize storage device
[ 2.4692 ]
[ 2.4724 ] tegradevflash --oem platformdetails storage storage_info.bin
Looking forward to your reply, thank you!

Hi EricSun,

You need to directly flash the other jetson nano with jetson-nano-qspi config and it will flash the QSPI only.

As for the cloning, does that problem happen to all of your jetson nano devices? And is this issue only happened to jetpack4.5 or even jetpack4.4 will fail to clone on your side?

For the cloning issue, I only tested it on JetPack 4.5 devices, because for Jetpack4.4 devices, I use dd to backup and distribute images.
The key problem I faced is that in the previous Jetpack version(e.g Jetpack 4.4), after I made my own system image, I only need to clone the entire sd card with dd command , and then it can be distributed to other new jetson nano.
But in Jetpack 4.5, There is no bootloader in the sd card, and the QSPI is not refreshed in other new jetson nano, so is there a way to repackage the bootloader into the sd card image I made, so that I can distribute the image very conveniently as before to other jetson nano(without QSPI bootloader)?
Very Thanks for your reply!!!

Hi @EricSun ,

We can reproduce the clone error on our side too. Will check if any fix for this.
Thanks.