How can we flash everything apart bootloader to extern sdcard on tx2 like jetson nano(with no intern...

Our team will have a customized tx2 module with only 4GB eMMC. So we must put almost everything including bootloader, kernel, rootfs and other APP all in external sdcard like nano which has no eMMC does. But when i use “sudo ./flash.sh jetson-tx2 mmcblk1p1”, it just update the extlinux.conf in eMMC(I think) to

LABEL sdcard
      MENU LABEL sdcard SATA SSD
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk1p1 rw rootwait rootfstype=ext4

, and nothing write to external sdcard. The generated bootloader/system.img size is only 31M. The flash time is about one minute. Then tx2 reboot again and again.

-rwxr-xr-x 1 root root 31M 8月  13 17:42 bootloader/system.img*
-rwxr-xr-x 1 root root 28G 8月  13 17:42 bootloader/system.img.raw*

I want to resuse image generated by:

sudo ./flash.sh --no-flash -S 28GiB jetson mmcblk0p1

and then flash it to sdcard by:

sudo ./flash.sh -r jetson mmcblk1p1

But this command still flash system.img to internal eMMC leaving sdcard nothing.
and the extlinux.conf is:

ISBU@jetson-0422818032206:/home$ cat /boot/extlinux/extlinux.conf
TIMEOUT 30
DEFAULT primary

MENU TITLE p2771-0000 eMMC boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

Is there some way I can use flash.sh script to flash image directly to external sdcard? Can the flash.sh script only flash to internal eMMC?

The log is as below:
[sudo] password for garret:
###############################################################################

L4T BSP Information:

R28 (release), REVISION: 3.0, GCID: 14690851, BOARD: t186ref, EABI: aarch64,

DATE: Mon Mar 25 17:43:04 UTC 2019

###############################################################################

Target Board Information:

Name: jetson-tx2, Board Family: t186ref, SoC: Tegra 186,

OpMode: production, Boot Authentication: ,

###############################################################################
./tegraflash.py --chip 0x18 --applet “/home/garret/tx2_28_3/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin” --cmd



*** The target t186ref has been flashed successfully. ***
Make the target filesystem available to the device and reset the board to boot from external mmcblk1p1.

Update…

Hi garretzou,

For new r32.2 release need add UUID partition.
Below is detail steps for flash on sdcard:

1). Create GPT and partition using gdisk on the external device
2). Get the UUID for the partition on the external device. For example, if the device partition is /dev/sda1, then execute ...
$ sudo blkid /dev/sda1
/dev/sda1: UUID="93A6-26BA" TYPE="vfat" PARTLABEL="Linux filesystem" PARTUUID="018eff62-2d07-4ca5-8619-c30c18b0a181"
3). Write the PARTUUID shown from the previous command to the following file ...
echo '018eff62-2d07-4ca5-8619-c30c18b0a181' > bootloader/l4t-rootfs-uuid.txt
4). Copy the rootfs folder to your sdcard (/dev/sda1)
5). Flash the board: (external is for sdcard, usb and sata)
$ sudo ./flash.sh jetson-tx2 external
1 Like

Dear carolyuu.
Many thanks for your reply.

But for we must use “Jetson TX2 as Jetson TX2 4GB Configuration Package”, and r32.2 has no that Package. Is it possible flash only bootloader in internal eMMC and others in external sdcard using r28.3?

Hi, I fellow your given steps and found that “bootloader/l4t-rootfs-uuid.txt” have no use here cause it it’s actually called by nothing. The command

sudo ./flash.sh --no-flash jetson-tx2 external

results

$ ll system.img*
-rwxr-xr-x 1 root root 41M 8月  16 15:08 system.img*
-rw-r--r-- 1 root root 28G 8月  16 15:08 system.img.raw

I didn’t Copy the rootfs folder to my sdcard (/dev/sda1), cause we just want to use a command like

sudo ./flash.sh jetson-tx2 mmcblk1p1

to flash a image. We must find a method to do that simply cause we will give a image to factory workers to flash to our product with a customized tx2 module boarding only 4GiB internal eMMC.

update… …

Dear carolyuu:

I made it on new r32.2 release. But it seem too complicated. Can’t I flash SD card like flashing internal eMMC using a command “sudo ./flash.sh -r jetson mmcblk0p1”.

Hi garretzou,

No, for r32.2, external is being used as identification is solely on UUID based and not type of media.
Please following #3 steps for flash on external devices. Thanks!

I finnally find a way to flash SD card. Steps as follow:
(1) make ext4 file system with an 64GiB sd card,

$ sudo mkfs.ext4 /dev/mmcblk0

(2) copy JetPack_4.2.1_Linux_GA_P3310/Linux_for_Tegra/rootfs to sd card

$ sudo mkdir -p /media/mnt/
$ sudo mount /media/mnt/ /dev/mmcblk0
$ sudo cp JetPack_4.2.1_Linux_GA_P3310/Linux_for_Tegra/rootfs/* /median/mnt/ -arp && sync

(3) change extlinux.conf file in rootfs/boot/extlinux to:

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
          APPEND ${cbootargs} root=/dev/mmcblk2 rw rootwait rootfstype=ext4
#APPEND ${cbootargs} quiet

(4) flash bootloader and kernel with:

$ sudo ./flash.sh -S 28GiB jetson-tx2 mmcblk1p1

After finishing those steps, unplug sd card from host to plug it into jetson-tx2. Tx2 surely boot normally.
but the the sd card space is only 4GiB and some tmpfs I dont understand. Can some one give some hints and tips? Thanks in advance.

The emmc and sd card info:

ISBU@tegra-ubuntu:~$ sudo fdisk -l | grep mmcblk*
[sudo] password for ISBU:
Disk /dev/mmcblk0: 29.1 GiB, 31268536320 bytes, 61071360 sectors
/dev/mmcblk0p1      4104 58724359 58720256    28G Microsoft basic data
/dev/mmcblk0p2  58724360 58732551     8192     4M Microsoft basic data
/dev/mmcblk0p3  58732552 58740743     8192     4M Microsoft basic data
/dev/mmcblk0p4  58740744 58741767     1024   512K Microsoft basic data
/dev/mmcblk0p5  58741768 58742791     1024   512K Microsoft basic data
/dev/mmcblk0p6  58742792 58743815     1024   512K Microsoft basic data
/dev/mmcblk0p7  58743816 58744839     1024   512K Microsoft basic data
/dev/mmcblk0p8  58744840 58750983     6144     3M Microsoft basic data
/dev/mmcblk0p9  58750984 58757127     6144     3M Microsoft basic data
/dev/mmcblk0p10 58757128 58761223     4096     2M Microsoft basic data
/dev/mmcblk0p11 58761224 58769415     8192     4M Microsoft basic data
/dev/mmcblk0p12 58769416 58777607     8192     4M Microsoft basic data
/dev/mmcblk0p13 58777608 58778815     1208   604K Microsoft basic data
/dev/mmcblk0p14 58778816 58780023     1208   604K Microsoft basic data
/dev/mmcblk0p15 58780024 58781023     1000   500K Microsoft basic data
/dev/mmcblk0p16 58781024 58782023     1000   500K Microsoft basic data
/dev/mmcblk0p17 58782024 58786119     4096     2M Microsoft basic data
/dev/mmcblk0p18 58786120 58790215     4096     2M Microsoft basic data
/dev/mmcblk0p19 58790216 58802503    12288     6M Microsoft basic data
/dev/mmcblk0p20 58802504 58814791    12288     6M Microsoft basic data
/dev/mmcblk0p21 58814792 58818887     4096     2M Microsoft basic data
/dev/mmcblk0p22 58818888 59081031   262144   128M Microsoft basic data
/dev/mmcblk0p23 59081032 59343175   262144   128M Microsoft basic data
/dev/mmcblk0p24 59343176 59408711    65536    32M Microsoft basic data
/dev/mmcblk0p25 59408712 59474247    65536    32M Microsoft basic data
/dev/mmcblk0p26 59474248 59605319   131072    64M Microsoft basic data
/dev/mmcblk0p27 59605320 59736391   131072    64M Microsoft basic data
/dev/mmcblk0p28 59736392 59737415     1024   512K Microsoft basic data
/dev/mmcblk0p29 59737416 59738439     1024   512K Microsoft basic data
/dev/mmcblk0p30 59738440 60262727   524288   256M Microsoft basic data
/dev/mmcblk0p31 60262728 61071326   808599 394.8M Microsoft basic data
Disk /dev/mmcblk0boot1: 4 MiB, 4194304 bytes, 8192 sectors
Disk /dev/mmcblk0boot0: 4 MiB, 4194304 bytes, 8192 sectors
Disk /dev/mmcblk2: 59.5 GiB, 63864569856 bytes, 124735488 sectors
ISBU@tegra-ubuntu:~$ sudo df -lh
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk2    4.9G  4.0G  642M  87% /
none            3.8G     0  3.8G   0% /dev
tmpfs           3.9G  4.0K  3.9G   1% /dev/shm
tmpfs           3.9G   29M  3.9G   1% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs           786M  112K  786M   1% /run/user/1000
/dev/mmcblk0p1   28G   83M   26G   1% /media/ISBU/2a6f1f37-80f5-46f5-be56-6e42fb67bd96

question 1,
/dev/mmcblk0p1 here I resize it to 28GiB, it can’t be resize large than 30GiB, why?
question 2,
the total size of /dev/mmcblk2 is 59.5GiB, but “df -hl” shows only 4.9 GiB, why, how to resize it?
question 3,
in the first column of “df -lh”, the none and tmpfs mean what? and where is their size 3.xGiB stay? how can I figure it out?

Please do me a favor. Thanks agian.

FYI, eMMC, mmcblk0, does not have enough space on it to use 30GiB. There are other partitions which are mandatory for boot (embedded systems don’t have a BIOS/UEFI, thus more is done in boot software).

Don’t know about the resize.

“df” can provide filesystem type, not just amounts. When you format for a root filesystem, it’s probably ext4 on Linux, and probably NTFS on Windows. In some cases filesystems are in RAM, and not on an actual disk, or sometimes the filesystem is designed to not be persistent between boots. “tmpfs” is one such filesystem type.

Device special files are not really on the filesystem. These are really file-based access to a driver. If the driver doesn’t load, then the file doesn’t exist. Reading or writing to device special files never touches the disk…the i/o is with a driver in RAM. You can’t do a backup and restore to a tmpfs (and doing so wouldn’t make sense…imagine making a backup of the random number generator, “/dev/urandom”…your backup would grow to infinity).

I tend to find UUID with “lsblk -f”.

Thanks for your kindly reply.

I found a way to resize the root size by the following steps.
(1) make ext4 file system with an 64GiB sd card

$ sudo parted /dev/mmcblk0
        mklable gpt
        mkparted
        (start) 0
        (end)   -1

(2) change extlinux.conf file in rootfs/boot/extlinux to:

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
          APPEND ${cbootargs} root=/dev/mmcblk2p1 rw rootwait rootfstype=ext4
#APPEND ${cbootargs} quiet

(3) copy JetPack_4.2.1_Linux_GA_P3310/Linux_for_Tegra/rootfs to sd card

$ sudo mkdir -p /media/mnt/
$ sudo mount /media/mnt/ /dev/mmcblk0
$ sudo cp JetPack_4.2.1_Linux_GA_P3310/Linux_for_Tegra/rootfs/* /median/mnt/ -arp && sync

(4) flash bootloader and kernel

$ sudo ./flash.sh jetson-tx2 mmcblk1p1

The root directory shows the total size of the sd card.

sudo df -lh

Actually, the sd card in tx2 is recognized as /dev/mmcblk2, mot mmcblk1, but here we can use

sudo ./flash.sh jetson-tx2 mmcblk1p1

to flash tx2. In reality, the command did nothing to sd card but only flash kernel and bootloader to internal eMMC.

Here we can find UUID:

ISBU@tegra-ubuntu:~$ sudo lsblk -f
[sudo] password for ISBU:
NAME         FSTYPE LABEL      UUID                                 MOUNTPOINT
loop0        vfat   L4T-README AF07-808D
mmcblk0
├─mmcblk0p1  ext4              6b694d42-c07e-42b0-93c3-3c8a34ee789f /media/ISBU/6b694d42-c07e-42b0-93c3-3c8a34ee789f
├─mmcblk0p2
├─mmcblk0p3
├─mmcblk0p4
├─mmcblk0p5
├─mmcblk0p6
├─mmcblk0p7
├─mmcblk0p8
├─mmcblk0p9
├─mmcblk0p10
├─mmcblk0p11
├─mmcblk0p12
├─mmcblk0p13
├─mmcblk0p14
├─mmcblk0p15
├─mmcblk0p16
├─mmcblk0p17
├─mmcblk0p18
├─mmcblk0p19
├─mmcblk0p20
├─mmcblk0p21
├─mmcblk0p22
├─mmcblk0p23
├─mmcblk0p24
├─mmcblk0p25
├─mmcblk0p26
├─mmcblk0p27
├─mmcblk0p28
├─mmcblk0p29
├─mmcblk0p30
└─mmcblk0p31
mmcblk0boot0
mmcblk0boot1
mmcblk0rpmb
mmcblk2
└─mmcblk2p1  ext4              8e2406a3-4410-49b3-b451-478b10a67e59 /
zram0                                                               [SWAP]
zram1                                                               [SWAP]
zram2                                                               [SWAP]
zram3                                                               [SWAP]
zram4                                                               [SWAP]
zram5                                                               [SWAP]

When you flash, then certain boot required software (such as setting up power rails and clocks) absolutely must be on the Jetson. This cannot go on alternate media.

When you flash to eMMC, you are additionally putting the root filesystem onto eMMC.

Regardless of whether you put the rootfs on eMMC or not, there will be a kind of “pointer” in the eMMC content telling boot where to look for further configuration.

When you flash to non-eMMC it is expected that you have set up the rootfs on that alternate media yourself, and the pointer to rootfs is modified to that alternate media. The alternate media itself is not modified, but the eMMC boot metadata is modified.

It used to be that various boot stages would eventually load U-Boot, and U-Boot would read the ext4linux.conf file to determine where to find the rootfs. On a TX2 some of this content in extlinux.conf is still used, but other changes over time started requiring information earlier in boot. An example is that extlinux.conf has a device tree entry, and this is when the device tree was loaded, but this is no longer possible. Those earlier boot stages cannot read ext4, and much of the content was moved to partitions. This content is then passed on to the bootloader as it starts to run rather than reading the content from ext4. I’m thinking part of the reason for this is to support secure boot options with signed content.

I have not tried to use a UUID instead of a specific device/partition number, but in the instructions above given by @carolyuu, the implication is that during boot there a search for partitions by UUID would occur, and finding a matching UUID specified in the boot “pointer” (I say it in quotes because I’m just paraphrasing from C/C++ pointers) qualifies for naming the rootfs. That alternate pointer has to be added in a custom way prior to flashing. I am unable to tell you anything more about that.

Regardless, you will not be able to “put everything other than the bootloader” on the external drive. This would be akin to asking to put a PC motherboard’s BIOS on the disk and removing the BIOS from the motherboard. The Nano is a special case…maybe one day the TX2 can do this as well, but not for the moment.

I tried runnig tx2 from pci/ssd (nvme0n1p1)

Everything went well, but i found a problem while booting:
Failed to start create Volatile Files and Directories.

Any idea?

Hi zbigniew.waz,

We’re not see this error before.
Can you boot up success when you get this error?
Please attachment the full dmesg logs on here. Thanks!

I can’t boot up.

It looks I flashed tx2 correctly: without disk inserted to pci slot i’ve got message mount:can’t find PARTUUID = …
I suppose it might be a problem either with permission or acl…

No dmseg log appears.
The only log I see in /var/log is apport.log:

ERROR: apport (pid 6112) Tue Dec 17 20:48:45 2019: called for pid 6109, signal 6, core limit 0, dump mode 2
ERROR: apport (pid 6112) Tue Dec 17 20:48:45 2019: not creating core for pid with dump mode of 2
ERROR: apport (pid 6112) Tue Dec 17 20:48:45 2019: executable: /usr/lib/accountsservice/accounts-daemon (command line "/usr/lib/accountsservice/accounts-daemon")
ERROR: apport (pid 6112) Tue Dec 17 20:48:45 2019: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 6112) Tue Dec 17 20:48:45 2019: Unhandled exception:
Traceback (most recent call last):
  File "/usr/share/apport/apport", line 603, in <module>
  File "/usr/lib/python3/dist-packages/apport/report.py", line 375, in add_user_info
KeyError: 'getpwuid(): uid not found: 123'
ERROR: apport (pid 6112) Tue Dec 17 20:48:45 2019: pid: 6112, uid: 123, gid: 65534, euid: 123, egid: 65534
ERROR: apport (pid 6112) Tue Dec 17 20:48:45 2019: environment: environ({})
ERROR: apport (pid 9059) Tue Dec 17 20:51:45 2019: called for pid 7883, signal 6, core limit 0, dump mode 2
ERROR: apport (pid 9059) Tue Dec 17 20:51:45 2019: not creating core for pid with dump mode of 2
ERROR: apport (pid 9059) Tue Dec 17 20:51:45 2019: executable: /usr/sbin/rsyslogd (command line "/usr/sbin/rsyslogd -n")
ERROR: apport (pid 9059) Tue Dec 17 20:51:45 2019: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 9059) Tue Dec 17 20:51:45 2019: Unhandled exception:
Traceback (most recent call last):
  File "/usr/share/apport/apport", line 603, in <module>
  File "/usr/lib/python3/dist-packages/apport/report.py", line 375, in add_user_info
KeyError: 'getpwuid(): uid not found: 109'
ERROR: apport (pid 9059) Tue Dec 17 20:51:45 2019: pid: 9059, uid: 109, gid: 114, euid: 109, egid: 114
ERROR: apport (pid 9059) Tue Dec 17 20:51:45 2019: environment: environ({})
ERROR: apport (pid 9647) Tue Dec 17 20:52:25 2019: called for pid 9072, signal 6, core limit 0, dump mode 2
ERROR: apport (pid 9647) Tue Dec 17 20:52:25 2019: not creating core for pid with dump mode of 2
ERROR: apport (pid 9647) Tue Dec 17 20:52:25 2019: executable: /usr/sbin/rsyslogd (command line "/usr/sbin/rsyslogd -n")
ERROR: apport (pid 9647) Tue Dec 17 20:52:25 2019: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 9647) Tue Dec 17 20:52:25 2019: Unhandled exception:
Traceback (most recent call last):
  File "/usr/share/apport/apport", line 603, in <module>
  File "/usr/lib/python3/dist-packages/apport/report.py", line 375, in add_user_info
KeyError: 'getpwuid(): uid not found: 109'
ERROR: apport (pid 9647) Tue Dec 17 20:52:25 2019: pid: 9647, uid: 109, gid: 114, euid: 109, egid: 114
ERROR: apport (pid 9647) Tue Dec 17 20:52:25 2019: environment: environ({})

Messages i see rigth after nvidia logo disappears:

/mnt/ is a mountpoint
cp: not writing through dangling symlink 'etc/resolv.conf'
[4.973476] cgroup: cgroup2: unknown option "nsdelegate"
[FAILED] Failed to start Create Volatile Files and Directories.
See 'systemctl status systemd-tmpfiles-setup.service' for details
...

Sorry for jumping into this. Could you describe where you got the first error log?

Could you share your steps in detail?

hi , did you get your problem resolve ?

Thanks

This process doesnt work in jetpack 4.5. I’ve tried several times. It breaks it and you won’t be able to boot neither from eMMC neither from SSD (in my case)

Getting a message

mount: /mnt/: can't find PARTUUID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.

Really wished sdk manager would have an option to select the target for flashing the dev kit

Don’t be confused by filesystem UUID (-f) and partition UUID.
Get the PARTUUID with:

lsblk -o NAME,PARTUUID
1 Like

I found the problem. In step 3 you should write the UUID to bootloader/l4t-rootfs-uuid.txt_ext (at least in jetpack 4.5)

that worked for me in jetson tx2. But then the boot works fine on SSD and starts to fail on eMMC. But after I flashed the eMMC again i finally worked on both SSD and eMMC according to priority set in /boot/extlinux/extlinux.conf