Not sure if there is a jetson support email, all I could see was CUDA. I’d successfully flashed a new kernel in R19.2 jetson, and decided to flash R19.3 as a whole (not just a kernel). I ended up with this after a few attempts (since none of the attempts worked):
R19.3/Linux_for_Tegra# ./flash.sh -S 15GiB jetson-tk1 mmcblk0p1
copying dtbfile(/home/dan/Documents/embedded/L4T/R19.3/Linux_for_Tegra/kernel/dtb/tegra124-pm375.dtb) to tegra124-pm375.dtb... done.
Making system.img... /home/dan/Documents/embedded/L4T/R19.3/Linux_for_Tegra/rootfs 16106127360
mapping system.img to loop device failed.
One attempt used the u-boot option, another without any size (no -S). So far, no listings found for mapping system.img failure. Is there an L4T/jetson support email at nVidia, or does the CUDA one handle L4T/jetson?
Check with flash.sh code. I used to receive this error message on Fedora 19 build host until I realised that Fedora doesn’t like losetup command. I’ve created loopback0:0 device manually, as a work around
I rearranged so the -S and -L are prior to jetson-tk1 and mmcblk0p1. Results remain the same. I’ve also tried this with the fastboot.bin, no change. And I’ve rebooted and tried from a fresh boot in case it was something related to using too many loop devices. No change.
I have noticed that “mapping system.img to loop device failed” is part of the flash.sh script, and in particular it is using losetup on /dev/loop0 to access system.img. What it is really saying is that my loopback is failing. I do have losetup on the system, and I have no reason to believe loopback was disabled. However, most people are using ubuntu, I’m using fedora 19.
Perhaps loopback itself needs some kind of setup? If I run losetup manually, it tells me /dev/loop0 does not exist. Indeed, looking in /dev/ a recursive find shows only /dev/loop-control. Right now I’m trying to investigate why my fedora 19 differs from older losetup (it has been a long time since using losetup, it appears that the syntax and setup has changed…I’m suspicious that it is a udev thing).
For those who succeeded in flashing to R19.3, what do you get from “ls /dev/loop*”? What linux distribution are you using?
The --show is for my own test use, it lists it as /dev/loop0…but without --find it never has a loop0. The loop devices seem to now be dynamically generated (again, I’m not positive, but this seems like it is something done for udev). I’ll modify the flash.sh this weekend and post if it works. Manual creation of the loopback works and creates a new /dev/loop# as needed. Script to be adapted.
But, word of warning: Before running flash.sh for anything other than just kernel (I’ve previously kernel flashed with no issues on fedora 19) make sure you have a /dev/loop0. The old style flash.sh losetup script is manually enumerating this, and it may not exist on your system…jetson will no longer be bootable.
Just an update for a temporary workaround which was successful, along with a note on flash.sh.
On my fedora 19 system, which by default never has /dev/loop0 (required during flash.sh installation of R19.3), manually creating /dev/loop0 will work (until reboot):
losetup --find
Once that command has been issued to find the first unused loopback device, /dev/loop0 should exist. Once loop0 exists, installation of R19.3 can be completed.
For those that have been through flash once, you will find in the boot loader section a file which is equal in size to the -S size option: system.img. This file is formatted and accessed under loopback. Once created, you can use this again and save time if you re-use via the -r option to flash.sh. If you want to save disk space on the host, you can delete this file after install. It is plausible that disk space of an entire install might be an issue for some people…the resources of the file plus whatever loopback coverage requires is significant. Should you want to re-use this, you might also consider compressing the file between uses.
Another side note: Using -S 15GiB exceeded eMMC capacity. Using -S 14GiB worked.
Trying to reflash jetson tk1 from Fedora linux WS. Always get a “USB Device not found” (indeed, not present even in lsusb):
[CdAB@localhost Linux_for_Tegra]$ lsusb
Bus 002 Device 003: ID 0a5c:219c Broadcom Corp.
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 2232:1008 Silicon Motion
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Just posting output (just noticed that GPT parameters has a “Target Device Name: none”:
What comes to mind is that the right type of USB cable has to be used, plus Jetson must be in recovery mode. The mini USB cable provided allows Jetson to become a “device” instead of a “host” because of its connector type (going to an A/B socket). Next, the Jetson must be started with the recovery button held down (before flashing software is started). Is this the case? If all of this is correct then you may have a genuine failure of some sort.
Great !
Also this problem that mapping system.img to loop device failed can also happen even if you’ve changed the line 284 of flash.sh and the case is that the loop device (/dev/loop0) is being used by your own host machine and the flash script is unable to unmount what ever is inside the loop device (/dev/loop0) to be able to use it !!
So if this happened you have also two other Solutions : 1 : Reboot your host machine and try flashing again ! 2 : Change flash.sh in a way to be able to find a free loop device to work with : Find this line in flash.sh : local loop_dev="/dev/loop0" Change it like this : local loop_dev=$(losetup --find)
This will make it to be able to set the loop_dev to a free loop device !
Thanks everybody and my Dear friend @linuxdev with the best answers !