I’m having trying to flash emmc over vmware 11. Anyone had problems or any tips ?
100% of all permissions and file types must be preserved. Even from unpacking on through flash this requires root or root privileges (e.g., sudo). If your underlying file system is not native linux (e.g., NTFS) it is unlikely to succeed. In general virtual machines tend to be a problem for flashing. Is your underlying file system native, e.g., ext3 or ext4?
I use VMWare Workstation 10 with a Ubuntu 14 session to do all my Jetson flashing, and have had no problems whatsoever. You need to remember to connect the session to the “Nvidia APX” USB device, which should show up when you put the Jetson in ‘recover’ mode.
OOps – I forgot to add that I am using a 64-bit Ubuntu session with ext4 virtual drive on a native 64-bit Windows 7 OS with NTFS disk.
All works just fine.
I’m wondering about what steps have to be taken to avoid an underlying NTFS file system type (under vmware)? Is there a default which would not use the ext4 virtual drive without explicit instructions?
I’m really not sure what you are asking, but I’ll give it a shot anyway.
I suppose if you want to avoid NTFS altogether you can use a physical drive partition formatted with ext4, and tell your Virtual Linux session to use that. I’ve never tried this, however.
Thank you guys for the support I didnt think it would be that fast and productiv:D .
My actual problem is that the flashing start and somehow hangs on the system partition image at the same number : 264241152 . Don’t have a clue there:(
Try connecting a serial cable and see if there are any errors printed out?
Which version are you flashing? FYI, you can log everything via “tee” while still seeing output. Example:
echo "foo bar" 2>&1 | tee my_log.txt
You could then copy and paste relevant log content. It “sounds” like it could be failing either at creating its system.img from the raw image or maybe from the actual copy of bytes to Jetson.
Also, is your install to the internal memory and not an SD card or SATA drive? What is the command line you used? Flashing takes a lot of disk space, what do you see for available under something like “df -h”?
Thanks, I would say that I’m quite familiar with the flashing process and tools. What I’m searching for is more of a gotcha or a bug someone has overcome.
The problem is that I can’t have physical access to the machine flashing the device. I run Fedora as my daily OS so I’m not familiar with Windows ‘incongruities’.
I’ve developed a Cyanogenmod version during the summer with the tools up to date at this time. Now I want to flash the system.img everything is going fine until the 264241152th byte of my system.img file.
One of my saved logs from R21.2 flash shows everything being similar up through u-boot.bin. This is where they diverge (which might just be a case of me looking at the wrong L4T flash log). What is your exact flash command, and which specific L4T release is it?
I use the last release with the following command : ./flash.sh -L bootloader/u-boot.bin -r jetson-tk1 mmcblk0p1
By last release do you mean R21.3? Probably, but I have to ask.
Note 1: u-boot.bin is normally created in bootloader/u-boot.bin via bootloader/ardbeg/u-boot.bin. u-boot is also the default in R21.x series. Assuming the bootloader/system.img was created from the same flash which placed u-boot.bin in place this should work fine. The -r option re-uses system.img, so this should not be an issue unless there was some sequence of flashing prior to this which would cause system.img to be out of sync with u-boot.bin…even then it might not matter but I couldn’t guarantee it.
Note 2: Since you are reusing system.img it would be necessary to know if the original flash which created the system.img worked. Has a previous flash worked with this system.img?
Note 3: You didn’t specify partition size. If partition size differed at some point and the default partition size is incorrect there might be an issue. Using the system.img is a “sparse” image which is basically compressed and might work when applied to a changed partition size…I have not tested. In prior versions size mismatch would have been a cause of failure…this compressed “sparse” version might not care. So a question does come to mind: Was there a size specification during the flash which originally created the system.img, or was it a default like the above command line?
For testing, I would suggest saving your system.img,system.img.raw, and u-boot.bin to some alternate backup location, and then try flashing via:
flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
If this works, then put the old saved versions back in place and try again with -r. If your original flash used a different partition size the -S could be left out. FYI, in R21.x series the above command will result in u-boot default boot loader.
Thank you for the answer I tried another images and it worked O.o
Note 1: I don’t know ¯_(ツ)_/¯
Note 2: I would say yes, I’m creating one cyanogenmod image and then flashing it with the tool and it worked before. The image that was failing looked normal, I have to investigate then.
Note 3 : I’m not specifiying the partition because I wrote a gnu_linux_fastboot_emmc_full.cfg file