Normally, we use OTG+ flash.sh Script, writing root file, etc., but it is too time-consuming. 32GB EMMC writing takes about 1.5 hours. I want to know if there is a faster way, such as uboot + network, or uboot + USB3.0, is there a feasible way?
Not pretty sure what case you are talking about. Do you mean you use otg port to flash tx2 and it takes 1.5 hour?
Yes，it take too long times to write rootfs to emmc with otg link
I need to re-confirm your steps to do this work.
This speed is abnormal.
link to otg port with usb cable ,into recovery mode,then type next cmd
sudo ./flash.sh -r jetson-tx2 mmcblk0p1
write the rootfs, this cmd tooks about 1.5hours
Are you using nvidia TX2 development kit (devkit) or custom carrier board?
Generally, it should be done in 10 mins with devkit.
I’m using custom carrier board.
the rootfs is using about 50% percent of the emmc capacity(32GB)
How many TX2 modules do you have? Does every of them have such flash speed?
Do you have TX2 devkit to test?
- I have a img file ,it’s generated by other guys in the team ,it’s include the running envr that we need.
- the img file is generagted by flash.sh shell ,used like flash.sh -r -k APP -G clone.img jetson-tx2 mmcblk0p1 .
3.it’s used about 10 tx2 modules up to now.the write time is similar equals
4.I’m also used devkit to write the img file ,the consume time have no improve
5.We use the VMware software
I guess VMware on host is the problem…
What time does it take if you use that host to flash jetpack?
I got it ,i will take a try,thks
If you are using your own image, and if that image is “raw” instead of “sparse”, then it can result in far more data needing transport across USB.
The partition itself is “raw”. A sparse image basically sends only the parts of the filesystem with content. If the filesystem is far from full, then a sparse image is much smaller and faster. As the filesystem fills the size of the sparse image approaches the size of the raw image, and thus sparse image advantage disappears as the filesystem becomes full.
The flash does not care if you send a raw image or a sparse image, it will simply work and “do the right thing”. If you have a large raw image you can produce a sparse image from it (just beware that a sparse image cannot be mounted or edited or examined). You will find the application at:
The basic command:
sudo mksparse -v --fillpattern=0 your_raw_image.raw system.img
(where “your_raw_image.raw” produces a “system.img” which is sparse)
If you send 3GB (typical of a new and nearly empty filesystem) you can expect it to be 10 times faster than for the case of a full 30GB filesystem.
Also, what was mentioned…a VM may be slower.