Flashing the official Ubuntu 22.04 Image fails with Unrecognized module SKU

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

I am attempting to flash the image provided by Canonical: https://ubuntu.com/download/nvidia-jetson following the directions here: https://pages.ubuntu.com/rs/066-EOV-335/images/Ubuntu_22.04_for_NVIDIA_Jetson_Orin_Instructions.pdf?version=0

Specifically I am attempting to flash using the l4t_backup_restore.sh script using this command:

sudo ./tools/backup_restore/l4t_backup_restore.sh -r --raw-image ubuntu-22.04-preinstalled-server-arm64+tegra-igx.img.xz -e nvme0n1 jetson-orin-nano-devkit

The failure I see happens after a flood of errors calling cp. It appears the file paths are incorrect. Ex:

warning: cp -f /home/dev/Orin_Ubuntu/Linux_for_Tegra/rootfs/usr/lib//libmount.so.1 /home/dev/Orin_Ubuntu/Linux_for_Tegra/bootloader/ramdisk_tmp//lib//libmount.so.1

$ find ./ -name libmount.so.1
./bootloader/ramdisk_tmp/usr/lib/aarch64-linux-gnu/libmount.so.1

The file exists, it just looks like the script is trying to copy it from the wrong place. I have tracked the failure down to tools/ota_tools/version_upgrade/ota_make_recovery_img_dtb.sh but don’t know the root cause. I’ve attached the full log of stderr and stdout.
flash.log (53.5 KB)

2

Progress, after running

sudo ./flash.sh p3768-0000-p3767-0000-a0-qspi internal

first I re-ran the original call and get this

[ 452.8572 ] Coldbooting the device
[ 452.8578 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 452.8583 ] MB2 version 01.00.0000
[ 452.9576 ] Coldbooting the device
[ 452.9581 ] tegrarcm_v2 --chip 0x23 0 --reboot coldboot
[ 452.9585 ] MB2 version 01.00.0000
*** The target generic has been flashed successfully. ***
Reset the board to boot from internal eMMC.

$ sudo ./tools/backup_restore/l4t_backup_restore.sh -r --raw-image ubuntu-22.04-preinstalled-server-arm64+tegra-igx.img.xz -e nvme0n1 jetson-orin-nano-devkit 
/home/dev/Orin_Ubuntu/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --no-flash --initrd --showlogs jetson-orin-nano-devkit mmcblk0p1
******************************************
*                                        *
*  Step 1: Generate rcm boot commandline *
*                                        *
******************************************
ROOTFS_AB= ROOTFS_ENC= /home/dev/Orin_Ubuntu/Linux_for_Tegra/flash.sh  --no-flash --rcm-boot jetson-orin-nano-devkit mmcblk0p1
###############################################################################
# L4T BSP Information:
# R36 , REVISION: 3.0
# User release: 0.0
###############################################################################
ECID is 
Board ID() version() sku() revision()
Chip SKU(00:00:00:D3) ramcode() fuselevel(fuselevel_production) board_FAB()
emc_opt_disable_fuse:(0)
Error: Unrecognized module SKU 
Cleaning up...
4

Hi,
Would like to check if the module is good. Please connect it to our default Orin Nano carrier board and follow the steps to re-flash it:

Quick Start — NVIDIA Jetson Linux Developer Guide 1 documentation

See if flashing default Jetpack 6.1 works.

5

The module is good. I have been developing on it for almost 2 years now and wanted to try the new Ubuntu image. The nvme is new, though. I need to verify that the nvme is working and will report back here.

6

The nvme was bad. I swapped it out and was able to flash using Jetpack. I first tried flashing using the Ubuntu image as before and it failed in the same way as described above, erroring out with a message about the SKU.

7

What is the method you tried to flash the board? Is the board in recovery mode?

From what I saw here is the flash process didn’t read the EEPROM from your board so it didn’t know what kind of board it is trying to flash.

8

Following the linked instructions above I first ran

sudo ./flash.sh p3768-0000-p3767-0000-a0-qspi internal

That was successful. I then ran

sudo ./tools/backup_restore/l4t_backup_restore.sh -r --raw-image ubuntu-22.04-preinstalled-server-arm64+tegra-igx.img.xz -e nvme0n1 jetson-orin-nano-devkit

which fails on the SKU check.

Yes, the board is in recovery mode.

9

No, the board is probably not in recovery mode.

After you ran “sudo ./flash.sh p3768-0000-p3767-0000-a0-qspi internal”, the recovery mode will finish. You need to put the board back into recovery mode again before you try any further flash attempt.

10

I will try this now.

11

Is there any concern about repeatedly flashing the EEPROM? How many times can I safely write to it before it’s dead?

12

I am not sure why you would “repeatedly flashing the EEPROM”. The flash process won’t do that at all. It is reading EEPROM, not flashing it.

1 Like
13

The one that got flashed is the QSPI-NOR flash on the board and the external storage (NVMe) provided by you.

14

This has failed in the same manner as my original post. I ran sudo ./flash.sh p3768-0000-p3767-0000-a0-qspi internal and it successfully flashed:

[ 448.7294 ] tegradevflash_v2 --write B_MEM_BCT mem_coldboot_sigheader.bct.encrypt
[ 448.7297 ] Bootloader version 01.00.0000
[ 448.8298 ] Writing partition B_MEM_BCT with mem_coldboot_sigheader.bct.encrypt [ 243712 bytes ]
[ 448.8303 ] [................................................] 100%
[ 451.8692 ] Flashing completed

[ 451.8692 ] Coldbooting the device
[ 451.8698 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 451.8702 ] MB2 version 01.00.0000
[ 451.9709 ] Coldbooting the device
[ 451.9715 ] tegrarcm_v2 --chip 0x23 0 --reboot coldboot
[ 451.9719 ] MB2 version 01.00.0000
*** The target generic has been flashed successfully. ***
Reset the board to boot from internal eMMC.

I then reset the board and confirmed that it is

in recovery mode:

$ lsusb | grep NVIDIA
Bus 001 Device 098: ID 0955:7523 NVIDIA Corp. APX

The log is attached; it fails due to broken copy paths.

$ sudo ./tools/backup_restore/l4t_backup_restore.sh -r --raw-image ubuntu-22.04-preinstalled-server-arm64+tegra-igx.img.xz -e nvme0n1 jetson-orin-nano-devkit >> flash.log 2>&1

You will see lines like this in the log

SRC = /home/dev/Orin_Ubuntu/Linux_for_Tegra/rootfs/usr/lib//libparted.so.2, DST = /lib//libparted.so.2, DST_DIR = /lib/, INITRD_DIR = /home/dev/Orin_Ubuntu/Linux_for_Tegra/bootloader/ramdisk_tmp

I added the echo to see variable names

flash.log (77.4 KB)

15

I don’t see any error is “same manner” as original post. The original error is gone.
The sku got read now.

You better checking why there is broken path. It has nothing to do with missing sku.

16

Check my first post. I originally created this thread to address the broken path and then edited the title because I thought I had gotten past that error.

17

Then it is an issue with 2 problems.

  1. Sku issue might lead to some problem in later boot. You didn’t hit it yet and we already resvoled.

  2. broken path issue has nothing I can check on my side. You need to see if those path are really missing on your side.

18

Yes, the SKU issue showed up after I thought I had made progress on the broken paths.

Please check on your side. Those paths are missing and I have not modified the directory structure. Please see my original post. I am able to locate the files it is looking for but the paths that the script creates are wrong.

19

Hi,

Is it possible do what you are doing here with rel-36.4? Will rel-36.4 still reproduce the error you told?

20

And one more question.

Does such file really not exist there? or it is there?

cp: cannot stat ‘/home/dev/Orin_Ubuntu/Linux_for_Tegra/rootfs/bin/mv’: No such file or directory

21

Can you provide me a link to download it? I will try.

There is nothing there.

$ pwd
/home/dev/Orin_Ubuntu
$ ls Linux_for_Tegra/rootfs/
README.txt