Great feedback thanks. My edid data has a valid checksum. Oddly this seems to only happen on 1 of my TX2’s. I’m not too concerned since I have a workaround.
If you see the same EDID from the same monitor on all of the relevant TX2s, then it might be interesting to see if they are using the same cable…if not, perhaps the cables involved matter. That step with the xorg.conf getting Option “ModeDebug” would be the most interesting as the driver itself would log why it does or doesn’t like various modes. Perhaps there is related software causing this.
To see if the drivers are the same see if this matches on each system:
head -n 1 /etc/nv_tegra_release
…then verify actual content is valid:
sha1sum -c /etc/nv_tegra_release
Should all releases be the same, and all drivers are valid, and if the same monitor is used (and same cables) with the same EDID showing up, then it starts becoming an interesting mystery, e.g., an apt-get update could change something.
Well it’s definitely the same monitor and cable. I have two tx2’s on the bench and was swapping the HDMI cable after cloning. The newly cloned TX2 is the one I’m having problems with. I only cloned the APP partition. (Which I thought was only one necessary). The other oddity with this cloned TX2, is that gnome-terminal does not work (xterm does). I get “Error constructing proxy for …”. Not sure if that is related to the monitor issue. [I tried the locale-gen suggestions on this site, but none resolved the issue, so just use xterm].
Cloning implies only the rootfs partition. Device tree and a number of hardware setup details go on before Linux ever loads and does have an effect on hardware (especially if device tree differs…and the timing of when device tree changes occur can also matter even if the end result is a match).
During any normal flash there are a number of partitions which are more or less custom to the carrier board detected (perhaps including revisions?), the module, and of course software used in the flash. An identical rootfs will only have guaranteed identical behavior if everything in the rest of the eMMC is also identical, and if the hardware revisions are the same. What was the exact flash provided prior to the clone? Is it possible something involved in the flash or setup of the one non-working unit differs? If so, try flashing it the exact same way as the clone source unit, and then apply the clone to the rootfs of this freshly “flashed-to-be-exact” unit.
Thanks, Dustin! It worked for me. Would it be possible to consider adding another command line option to this script to skip flashing rootfs/APP partition altogether? That would be very helpful when one needs to upgrade to vendor-specific BSP or F/W, but would like to retain existing root filesystem.
-albertr
@dusty_nv is there a way to flash an image from a different location than where flash.sh resides? In my case, I’m running the host machine on a very small system (32gb total space, of which 12gb or so is taken up by JetPack and other software) and I store images on an external HDD. So what I’m asking is, is there a way (besides editing the bash script) to SPECIFY the image location ? Like:
$ sudo ./flash.sh -r -k APP jetson-tx2 /my/image/location/system.img mmcblk0p1
?
I also thought of just using disk dump dd to do this as I’ve done on several other embedded systems. Any thoughts there ?
FYI, this is the driver package…you could unpack just that anywhere you want. flash.sh is a script referring to other apps, e.g., in the bootloader subdirectory (which is why it can’t run by itself or if it refers to a relative path which isn’t there).
Hey Linuxdev, thanks for replying so fast,although I am a bit confused by your response. I am trying to clone my entire Jetson TX2 eMMC from one board to another, so I’m referring to the eMMC system.img, like the very first message in this post describes. Sorry if my post was not clear or if maybe I just don’t understand your reply.
The flash.sh script is also used for clone. This is via the driver package, and it sounds like you want to run a clone from some other directory than where flash.sh is located from. Because of relative paths you have to run this from the “Linux_for_Tegra/” subdirectory, but you can otherwise unpack the entire driver package anywhere. Thus if you have a system with limited space, and if that system can mount an SD card (e.g., 64GB) or USB hard drive, e.g., mounted on “/usr/local/tmp” or some such location, then you could unpack the driver package there and use that “Linux_for_Tegra/” subdirectory. You wouldn’t be on the host’s file system space anymore.
Are you wanting to clone from a running Jetson instead of one in recovery mode?
A script I use in R28.1 for TX2:
#!/bin/bash
version='R28.1';
tstamp="$(date '+%Y-%b-%d_%a_%H-%M-%S')";
raw_file="${PWD}/rootfs_${version}_${tstamp}.img.raw";
flash_base_dir="/home/dan/Documents/embedded/L4T/${version}/Linux_for_Tegra";
echo "Raw file at ${raw_file}";
echo "";
echo "EXECUTING: ${flash_base_dir}/flash.sh -r -k APP -G ${raw_file} jetson-tx2 mmcblk0p1"
pushd "${flash_base_dir}/"
./flash.sh -r -k APP -G "${raw_file}" jetson-tx2 mmcblk0p1
popd
(this just does a cd to the flash.sh directory)
Ah that makes sense now. Awesome script, thanks for sharing. On line 13 it looks like you are READING a new image of an existing Jetson TX2. I’ve got an image already (I did both the ./flash.sh script and made another image just in case using the dd command). I did both in recovery mode.
I wish there was a more simple way of specifying an image in any directory to WRITE an image to the board, without unpacking the driver package somewhere else. Are you writing all your images to the driver directory ? And when you are writing the image to a new board, are you using the system.img file or the system.img.raw file ?
All writing of an image from a host to a PC uses the “system.img” of “Linux_for_Tegra/bootloader/” via the flash.sh script of “Linux_for_Tegra/”. All of my commands are from the driver package.
You can restore a clone into a Jetson using either system.img (sparse) or system.img.raw (raw). Whichever is found with name “system.img” (not “.img.raw”) in the “Linux_for_Tegra/bootloader/” subdirectory will be what is restored into the Jetson.
The key to understand is that originally there was no such thing as a sparse image during flash…and system.img was raw…with the addition of sparse file support system.img is still generated, but then renamed to system.img.raw…and a sparse version created from that as system.img. During a flash it won’t matter which one you use so long as the name is sytem.img…flash will detect and deal with sparse versus raw without any effort by you. Beware a sparse image cannot be manipulated or extracted…a raw image is much more useful…but a raw image might take several hours to flash.
In other words, I am using system.img.raw after renaming it to system.img…but the other file would also work if you don’t care about examining or editing the content. Cloning gives you both…I throw away the sparse image and keep the full image which I compress if I’m not using it. You could use the mksparse program at any time to convert the raw image to sparse if you want to.
Thanks @linuxdev. I also tried your script above and I think it’s missing the bang of your she-bang :).
Like:
#!/bin/bash
version='R28.1';
tstamp="$(date '+%Y-%b-%d_%a_%H-%M-%S')";
raw_file="${PWD}/rootfs_${version}_${tstamp}.img.raw";
flash_base_dir="/home/dan/Documents/embedded/L4T/${version}/Linux_for_Tegra";
echo "Raw file at ${raw_file}";
echo "";
echo "EXECUTING: ${flash_base_dir}/flash.sh -r -k APP -G ${raw_file} jetson-tx2 mmcblk0p1"
pushd "${flash_base_dir}/"
./flash.sh -r -k APP -G "${raw_file}" jetson-tx2 mmcblk0p1
popd
Yup :) I did a bit of mouse copy and paste plus hand edits, I missed that (I added it back in though). I think probably the file naming is a big flawed too because whatever file you name as the “.img” it will produce with “.img.raw” as well…you might see something like “.img.raw.img” since I never correct that…but the final “.raw” or “.img” should be valid. The “.raw” will be the byte size of the full file system, e.g., close to 30GB, or for sparse around 2GB to 18GB (depending on how filled the file system is).
Do you think copying the Linux_for_Tegra dir from where I installed JetPack on the host and just pasting it onto my external HDD where the images are stored, and running ./flash.sh from that location is OK or do I literally need to do a re-install of JetPack onto the external HDD?
Copy will work fine. This is just the driver package which JetPack unpacks for you. You can download just the driver package instead of copying if you want. See the R28.1 version at:
[url]https://developer.nvidia.com/embedded/linux-tegra[/url]
[url]https://developer.nvidia.com/embedded/dlc/l4t-jetson-tx2-driver-package-28-1[/url]
The driver package is much smaller than the whole JetPack install. If you were flashing and wanted to generate a new image (instead of cloning or using a clone), then you’d also unpack the sample rootfs…with clone or with restore from clone you don’t need the sample rootfs.
Just as a follow up, I basically just copied the Linux_for_Tegra directory to my external HDD, and put whatever image I wanted to flash in the bootloader directory there and renamed it system.img. I also renamed the original system.img in the bootloader folder as system_stock.img so it was not overwritten. Also note that when the flash is completed that you’ll still have to redo things like IP addresses on the target board (I setup mine static on a LAN, so that was important).
Hi, everyone:
Has anyone experienced any problems with Ethernet connections? I created an image of one of my Jetsons TX2 and was able to load the image into another TX2 without any errors and all the files have stayed the same. The only thing is, my Ethernet is not working. The lights don’t blink when I plug in an Ethernet cable (and I tried various cables that work on other computers as well) and it says that Ethernet is unplugged. The “Ethernet Network” option is also grayed out. I am not sure what is wrong and have tried the suggestion from this forum: https://devtalk.nvidia.com/default/topic/753039/ethernet-not-working-at-all-on-my-jetson/?offset=8
without any success. Any help would be appreciated. Thank you!
Was the installed L4T version the same between both the clone source and the clone recipient? There are differences in partitioning and device trees across versions, and device tree would be a strong suspect if the two versions mismatch.
@linuxdev: Yes I have L4T 27.1.0 on both of them. I should also mention that the wireless works just fine. It even saved all the connections from the TX2 I imaged (not sure if this matters). But when I plug an ethernet cable, it doesn’t even recognize I have it plugged in. The HWaddr is also missing. Help! I am incredibly confused what I did wrong when creating the image.
Hmmm…I suspect you cloned something tied to the original Jetson’s MAC address. udev has a tendency to do this. If parts of the system assume setup for a given MAC address which does not exist, then the setup won’t work.
If you install package “tree”:
sudo apt-get install tree
…what do you see from:
sudo tree /etc/udev
Note that most of those files are just human readable text. If you have one which might be related to networking, then post its content (we’re looking for something which might identify via wired ethernet names or via MAC address).