[Question] What kernel version should be available for the latest release?

[brianlinuxing]

Describe the issue Please describe the issue

Context: Just managed to flash my Xavier NX to the USB sda1 (and the scripts are very helpful).

The boot procedure as suggested in the documentation was a little odd (seemingly stuck around the initial setup, after running the wizard, etc)

I suspect it the Ubuntu setup issues, but that’s another story.

I have managed to shoehorn in ssh, to verify the issues and I noticed that the kernel was an old one:

uname -a Linux iontach 4.9.253-tegra #1 SMP PREEMPT Mon Jul 26 12:19:28 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux

4.9.253-tegra

Which version of Ubuntu on the Host machine Ubuntu version:

[16.04 ESM - ok my fault, I can re-do with 18.04 etc but I would expect the end result will be very similar.]

What version of L4T/JetPack L4T/JetPack version:

This is the question.

Which Jetson Jetson: Xavier NX

To Reproduce Steps to reproduce the behavior: For example, what command line did you run?

1. Download the scripts (https://github.com/jetsonhacks/bootFromExternalStorage/archive/refs/tags/jetpack-4.6.tar.gz) to an Ubuntu desktop PC setup with plenty of space (~90 Gb)
2. Follow the documentation, dependencies, etc
3. Connect the device to the desktop PC (via micro USB cable, etc) with a jumper installed, power on, remove jumper
4. Verify that the device can be seen
5. Run time ./flash_jetson_external_storage.sh -s sda1
6. A log is attached.
7. Works, boots on XavierNX
8. On the NX runs through the setup wizard, defaults taken in most cases.
9. At the end screen is basically a blank red desktop without any icons.
10. Via ALT-CTRL-F1 a message about “End-user configuration after initial OEM installation” running can be seen, it never stops.

Expected behavior A clear and concise description of what you expected to happen.

The latest Jetpack 5.1 to be installed, it looks like the previous iteration.

Additional context Add any other context about the problem here.

I followed the documentation as best I could and it worked.

But am wondering:

1) if it pulls down the older one? 2) is there an option to make it get the latest Jetpack?

[PS: am very happy to beta test any fixes, etc if that helps.]

[jetsonhacks]

JetPack 4.6 is Jetson Linux 32.7X which is Ubuntu 18/Linux kernel 4.9. You should git clone master if you want JetPack 5.1 / Jetson Linux 35.2.1 / kernel 5.10

[brianlinuxing]

My mistake, Jim, thank you very much :)

[My fault, I was being lazy as I didn't setup git on the test partition and thought the tar.gz was latest as dated Feb 19.

Gotcha, will do!]

[jetsonhacks]

The releases aren't very well maintained. There should be a JetPack 5.X release, but I know there's another JetPack release soon and only wanted a one and done.

[brianlinuxing]

No worries Jim, it has been very educational and I would have saved a lot of time had I used your scripts from the start (debugging them was informative). :)

I did the newer version last night. I think something small is missing. Any thoughts?

A snippet from session log, the beginning and the key part is at the end, where it says:

no-flash flag enabled. Exiting now...

"brian@nua:~/Downloads/bootFromExternalStorage-main$ ./flash_jetson_external_stora age.sh -s sda1 /home/brian/Downloads/bootFromExternalStorage-main/R35.2.1/Linux_for_Tegra Checking Jetson ... jetson-xavier-nx-devkit Make sure the SD card and the force recovery jumper are removed. Continue (Y/n)? Y Flashing to sda1 sda1 user entered sda1 Checking ONLINE mode ... OK. Checking target board connection ... 1 connections found. Reading ECID ... FUSELEVEL=fuselevel_production hwchipid=0x19 bootauth=NS Reading EEPROM ... --- Copying tegra194-mb1-soft-fuses-l4t.cfg succeeded. "/home/brian/Downloads/bootFromExternalStorage-main/R35.2.1/Linux_for_Tegra/bootloader/tegraflash.py" --chip 0x19 --applet "/home/brian/Downloads/bootFromExternalStorage-main/R35.2.1/Linux_for_Tegra/bootloader/mb1_t194_prod.bin" --soft_fuses tegra194-mb1-soft-fuses-l4t.cfg --bins "mb2_applet nvtboot_applet_t194.bin" --skipuid --cmd "dump eeprom boardinfo cvm.bin; reboot recovery" Welcome to Tegra Flash version 1.0.0 Type ? or help for help and q or quit to exit Use ! to execute system commands

[ 0.0176 ] Generating RCM messages [ 0.0189 ] tegrahost_v2 --chip 0x19 0 --magicid MB1B --appendsigheader /home/brian/Downloads/bootFromExternalStorage-main/R35.2.1/Linux_for_Tegra/bootloader/mb1_t194_prod.bin zerosbk [ 0.0198 ] Header already present for /home/brian/Downloads/bootFromExternalStorage-main/R35.2.1/Linux_for_Tegra/bootloader/mb1_t194_prod.bin

..... [ 6.0648 ] Signed BCT for boot chain B is copied to /home/brian/Downloads/bootFromExternalStorage-main/R35.2.1/Linux_for_Tegra/bootloader/signed/br_bct_b_BR.bct

[ 6.0648 ] Copying BCT backup image bct_backup.img to /home/brian/Downloads/bootFromExternalStorage-main/R35.2.1/Linux_for_Tegra/bootloader/signed/bct_backup.img [ 6.2541 ] tegraparser_v2 --pt flash.xml.bin --generateflashindex /home/brian/Downloads/bootFromExternalStorage-main/R35.2.1/Linux_for_Tegra/bootloader/signed/flash.xml.tmp flash.idx ./tegraflash.py --bl nvtboot_recovery_cpu_t194_sigheader.bin.encrypt --bct br_bct_BR.bct --securedev --bldtb tegra194-p3668-0000-p3509-0000.dtb --applet rcm_2_encrypt.rcm --applet_softfuse rcm_1_encrypt.rcm --cmd "rcmboot" --cfg secureflash.xml --chip 0x19 --mb1_bct mb1_bct_MB1_sigheader.bct.encrypt --mem_bct mem_rcm_sigheader.bct.encrypt --mb1_cold_boot_bct mb1_cold_boot_bct_MB1_sigheader.bct.encrypt --mem_bct_cold_boot mem_coldboot_sigheader.bct.encrypt --bins "mb2_bootloader nvtboot_recovery_t194_sigheader.bin.encrypt; mts_preboot preboot_c10_prod_cr_sigheader.bin.encrypt; mts_mce mce_c10_prod_cr_sigheader.bin.encrypt; mts_proper mts_c10_prod_cr_sigheader.bin.encrypt; bpmp_fw bpmp-2_t194_sigheader.bin.encrypt; bpmp_fw_dtb tegra194-a02-bpmp-p3668-a00_lz4_sigheader.dtb.encrypt; spe_fw spe_t194_sigheader.bin.encrypt; tos tos-optee_t194_sigheader.img.encrypt; eks eks_t194_sigheader.img.encrypt; kernel boot.img; kernel_dtb kernel_tegra194-p3668-0000-p3509-0000.dtb; bootloader_dtb tegra194-p3668-0000-p3509-0000_sigheader.dtb.encrypt" --secondary_gpt_backup --bct_backup --boot_chain A saving flash command in flashcmd.txt

no-flash flag enabled. Exiting now...

User can run above saved command in factory environment without providing pkc and sbk keys to flash a device "

[jetsonhacks]

Interesting, I haven't seen this before. I haven't tried to use USB, the NVIDIA USB driver seems a little bit unreliable at times.

One thing to check is to make sure you only have one USB drive on the machine. USB goes through enumeration, and you aren't assured of always having the same ID each time you enumerate.

What type of USB device are you trying to flash?

[brianlinuxing]

Sorry Jim, I didn’t make it 100% clear.

It is a message from (seemingly) one of the nvidia utilities suggesting that it has not, yet, been passed the proper switch to do the final flashing.

I doubt the USB stick or anything related is the issue, as they are good quality (am using SanDisk Ultra Fit 32Gb, Kioxia U366 64 Gb, Kioxia U366 128 Gb and a SanDisk 64 GB Cruzer Force) and were used before without any issues. Also I pre-format them, just before burning to double-check things.

It seems more an issue with the code, probably a recent change at the Nvidia end.

Maybe related a "no-flash flag enabled"?

I can email you the logs, if required.

[jetsonhacks]

Is your Jetson currently set up to run a 32.7 or 35.X? They use a different QSPI, I thought that the nvsdkmanager script flashed that. I don't know if Ubuntu 16.04 is supported on the host side, I thought they moved to 18. Personally, I would try this using the SDK Manager to see if this actually works. I haven't tried this method with a thumb drive, only a USB drive and USB SSD. Perhaps if I get some time later in the week I can take a look at this.

[brianlinuxing]

Thank Jim. :)

[jetsonhacks]

This appears to be a known issue @ NVIDIA: JetPack 5.X Latest bulletin JetPack 5.1.1 3925680 USB can not be used as a flash and boot device for Jetson AGX Xavier series and Jetson Xavier NX because of issues with UEFI Xhci controller driver.

[brianlinuxing]

Indeed Jim!

Recently, I have had no end of fun building Linux installations and running up the SDK Manager many times, etc. Found that the latest (5.1.1) didn't like my Xavier and said basically 'works on Orin'.

Much greater success with your excellent scripts.

Your Jetpack 4.6 works on an Xavier NX consistently (have burnt 6+ USB sticks) but there is an issue with anything less than 64GB.

Had GPT "corruption" on known good USB sticks (Sandisk Ultras) as they are 32 GB, above that it burns perfectly time after time.

Granted there is a performance issue of sorts (the key is having a quality well-speced USB stick in the first place), I shall look at the IOs later.

I have switched off most things on my Xavier NX (Docker, snap etc) and even disable the GUI from starting yet not 100% happy with the responsiveness.

I have read the nvpmodel doc etc.

But what is your feeling on the best setting for general Linux reactivity (handling a lot of processes, and not zipping through benchmarks with one or 2 CPUs set to max)

Do you favour nvpmodel set to 0 or something else?

I am unconcerned about power usage, am happy for the fan to be on most of the time, if needed!

[jetsonhacks]

The Jetsons use dvfs, which changes the frequency of the the CPU, GPU and memory depending on usage. It does this to save energy. Unless you change the dynamic frequency scaling to static frequency setting, things are a little bumpy. That's what the utility jetson_clocks controls. jetson_clocks sets the frequency to the maximum for the CPU, GPU and memory and then turns the fan on.

As far as Linux reactivity, it depends as to which utilities you are using and how well they handle multiprocessing on different cores. You can always experiment by enabling more CPU cores, I would think the GPU isn't used much by most Linux utilities.

[brianlinuxing]

You are right Jim, I have been experimenting with various ones, stuck with -m6 and the jetson_clocks for the moment. Oddly, it doesn't feel as fast as a Pi 400 but manageable until I try out faster USB sticks and maybe an SSD in the future. (I ssh in and therefore interactive “feel” is noticeable at times on these SBCs).

And I need to thank you again, your 4.6 scripts have been marvellous, open, readable and I can work through them slowly (my mind comes and goes with the insomnia!), tried the SDK Manager route twice+ and a lot of unnecessary sweat, too much of a "black box" for me.

So now I have a reproducible build method, with a minimal Linux (no active GUI needed) thanks to you :)

PS: I got the overall system down to about 230 processes and 520 Mb, which isn’t too shabby but I do wish there was a plain Debian build (they seem to have tried with earlier devices, TK1, etc: https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TK1).

[brianlinuxing]

Been experimenting and the 4.6 scripts work perfectly on an ancient external Buffalo 500 Mb drive, and performance is very acceptable. The HD-CEU2 is from about 2016-17!

Trick: after the "burning" the first reboot might not full work, solution: plug into another PC and fix the APP partition with gparted, then it all works well. :)

[jetsonhacks]

@brianlinuxing Xavier NX vs RPi 400 is about the performance I would expect. Both use ARM processors that are around the same, A72 vs Carmel. For the Carmel, ARM didn't design the execution units and decode logic; NVIDIA did. In two core mode, you can run the Xavier NX CPU at up to 1.9GHz, the RPi 400 is 1.8GHz. But there's all sorts of tradeoffs in design, so it's not surprising it's a give or take kind of thing. If you're not using GPU, the extra CPU cores, or special execution accelerators, there's no advantage over a RPi 4 except a lighter wallet.

You can check out the Yocto project if you want to get hard core into building a fast, custom system without the overhead of Debian and Ubuntu.