I am flashing Jetson TK1 with JetPackTK1.1-1.2. After flashing, it was good to boot in ubuntu for the first time. But after restart, all the io crash down ( usb mouse, monitor, even ethernet cable won’t work ), so i cant do anything to the board. I have flashing 4~5 times but same problem coming out.
Anyone can give me suggestion or solution to this issue? T_T…
Thank you.
What was your exact flash command line?
The serial port should work fine even with crash and provide information. The DB9 connector uses a NULL modem cable and serial port program such as minicom or gtkterm or PuTTY, set for 1152008N1.
I used virtual machine ubuntu 14.04, 64bits to flash my Jetson.
and flashing with JetPackTK11.2, so no command is used.
for every try of flashing,it was good to log in Ubuntu for the first reboot(which the system will do it automaticly) , but it crashes after reboot again( no respond, every IO is not working )
for the serial port, I used putty and configure baud rate to 115200 was unable to connect to the device :(
Is there anymore solution to this problem?
There have sometimes been issues with permissions, I’m wondering if JetPack installed correctly. There have also at times been issues with virtual machine hosts (setting it up to work for flash can be more difficult).
So far as the serial device not connecting, it is likely just an incorrect port assignment. For the case of a USB serial UART to make a DB-9 available on host side, this changes identity in many cases, e.g., if that USB device loads in a different order for any reason…unplugging anything USB and plugging it back in would cause this.
I strongly suggest trying the flash from the command line. If Jetson has been correctly started in recovery mode and the micro-B USB cable is connected, your host will have output from this:
lsusb -d 0955:7140
Once your Jetson is known to be in recovery mode, find the directory Linux_for_Tegra from the L4T installation (should be present from the JetPack install). From there:
sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
Watch for any errors. This will take significant time. When it completes your bootloader directory should contain “system.img.raw” (size 15288238080 bytes), and also “system.img” (approximate size 3-6GB).
Does this work?
Hi, linuxdev
No. The same error keep going.
Even today I try to flash it with another version of jetpack nor I flash it without using virtual machine
same issue going on T_T…
and one visualizable error is that when I double clicked the detail button( at the left side of Ubuntu ) it will crash(i.e it can’t show the detail of jetson-tk1 ).
Is this the problem causing I can’t reboot?
Is serial cable necessary connected to flash Jetson?
Going crazy to solve the problem T_T…
with the logs attached…
edited: besides that, when choosing suspend, it will directly crash down, no more chance to control. Anyone have idea how the problem come?
Xorg.0.log (15.8 KB)
alternatives.log (673 Bytes)
auth.log (1.83 KB)
boot.log (4.36 KB)
pm-powersave.log (1.67 KB)
The Xorg.0.log looks normal until near the end. Assuming you use a USB keyboard (or other keyboard), there should be one or more config/udev lines like:
(II) config/udev: Adding input device USB Keyboard (/dev/input/event3)
What kind of keyboard do you use? Is there a USB keyboard?
alternatives.log shows some differences with my system, although I don’t know if it is significant. I’ve done a lot of updates and perhaps have not installed things which you have. However, it’s worth noting this one line from my system which differs from your…it MIGHT matter:
run with --force --install /etc/ld.so.conf.d/arm-linux-gnueabihf_EGL.conf arm-linux-gnueabihf_egl_conf /usr/lib/arm-linux-gnueabihf/mesa-egl/ld.so.conf 500
Mine links with a mesa directory, yours links with a tegra-egl directory. It is possible for these libraries to be linked incorrectly and bring down graphics or perhaps even produce an OOPS. This could be an issue if your rootfs was modified to do this prior to flash, it could also occur by changes to support EGL after install. Since I don’t have ubuntu for my host (I use fedora) I can’t say what JetPack does or does not do correctly. Regardless, you could go to your L4T R21.4 directory and recreate the rootfs directory (along with apply_binaries.sh) as if using just the flash app and ignoring the JetPack GUI. I would be more specific, but I just don’t know how JetPack works on this and especially JetPack from a VM.
My auth.log differs from yours, but there are a lot of reasons why this may happen. In particular, I don’t see errors.
boot.log does not show any obvious errors. pm-powersave.log probably is not useful unless looking for a specific setting.
FYI, the serial cable is not used during flash. You could view it during flash and perhaps get some information if the failure is from a bad flash…but a bad flash usually leaves Jetson unbootable until reflashed (an impossible size for system.img would result in an error during flash). The part from flash which can consistently cause failure without a flash error is if the rootfs is incorrect. For example, only root authority (including sudo) can unpack and place device special files as needed; if a loopback device needs to be created, only root authority can do this as well. A file system unpacked as non-root cannot set permissions to root, and flash copies permissions as-is…modified rootfs implies modified Jetson from flash, and no error during flash.
Serial cable is often necessary to debug problems such as this, and it would make a huge difference in how easy or difficult it is to figure out the problem. Serial cable console does not depend on the video card and continues to function in many cases when the rest of the system is in a terrible and extreme state of failure. This would certainly be the best way to see what is going on. If you don’t have a convenient DB-9 serial port on your host, you could get a serial UART which is a USB cable with a DB-9 on one end. Here’s one that works well:
http://www.newegg.com/Product/Product.aspx?Item=N82E16812156039
…this would use something /dev/ttyUSB1 for the serial port name. 115200 8N1 would be the setting.
The closest thing to a “smoking gun” on the problem is the EGL graphics linking differences, but again this might be because I have updated packages and installed different things. Without serial console, I’d suggest manually downloading and installing non-JetPack L4T R21.4 on your flash host and running the flash in a console, paying particular attention to making sure rootfs unpack and sudo apply_binaries.sh are correct.
Hi Linuxdev,
Do you mean i can show the progress of flashing with serial cable?
In my jetson-tk1 i can’t connect with serial by putty when i am flashing( which i use rs232 to usb port ) :(
And the keyboard problem is because i use Onboard in linux :D :D
With your clue with different system, today I flash it again with Ubuntu 12.04 on virtual device.
Same problem occurs T_T
I give up to keep flashing and ready to send it back to company for repair, maybe it ss hardware problem…
Thank you very much for helping me these days.
I’ll come back to report if the repair works :D
Hi Linuxdev,
Do you mean i can show the progress of flashing with serial cable?
In my jetson-tk1 i can’t connect with serial by putty when i am flashing( which i use rs232 to usb port ) :(
And the keyboard problem is because i use Onboard in linux :D :D
With your clue with different system, today I flash it again with Ubuntu 12.04 on virtual device.
Same problem occurs T_T
I give up to keep flashing and ready to send it back to company for repair, maybe it ss hardware problem…
Thank you very much for helping me these days.
I’ll come back to report if the repair works :D
During flash the serial port will output some of the flash process. Normally I wouldn’t even connect the serial port during flash. PuTTY complicates things because it runs from a non-linux host and may have some differences…I’m always suspicious of windows being involved because there are places where simple differences may get in the way (e.g., translating end-of-line character). I’d strongly advise monitor from a linux machine using something like gtkterm or minicom, or not even connecting the serial port.
I’m not familiar with Onboard. From what I see on the web, it requires X11 to already be started to work. If X11 has a bug during startup where it must have a keyboard, then this would be an issue…but I’m just speculating. Many years ago I wrote a headless/diskless Beowulf cluster install/administration program, and had to rewrite part of the boot loader because although it was able to function without video, a lack of a keyboard caused it to crash and burn (large clusters shouldn’t need a keyboard attached to each node). Very few software authors think to test their software when there is no keyboard attached. Until X11 starts, Online is missing, and thus no keyboard…when you get your Jetson replacement, try connecting a real USB keyboard for testing and see if things change (perhaps even connect it during flash).
Before you re-flashed JetPackTK1.1-1.2, is the board working fine, including reboot?
chijen: Yes, the board is fine with the original OS, the problem comes after flashing. And now I have a new Jetson TK1, the same problem keep going on.
linuxdev:Sad to say that I’ve changed new board and same problem going on. And the new board is more weird. I haven’t start force recovery mode(which i just plug in usb), the virtual linux will auto detect lsusb -d 0955:7140. Is this because I get a defect board again?
By the way, I just directly flashing the second board(new). So I don’t know how is it working before flashed…
This is the “weird” picture after rebooting. The ethernet light is on but not blinking.
And I’ve also tried connected with usb keyboard.Not working.
lsusb showing the device on a host is a result of the device being in recovery mode and having the type-B micro USB connector connected to the host. This shouldn’t happen unless powered up with the recovery button held down. If the board had no software installed on it at all, I’m unsure what the behavior would be…it might possibly start in recovery mode if no o/s were ever flashed to it. This should not happen, you should not receive a board which always powers up to recovery mode even when recovery button is not pressed.
If flashing succeeds, I wouldn’t worry about it. If this board stays in recovery mode after a proper flash, I would consider it defective. Did the most recent flash solve this?
Yes,this is what i seen just powe it on
And the it can boot ubuntu for the 1st time. …
I’ll try to flash it again…
I heard of problems when flashing device on a virtual machine. Can you please try to flash on a Ubuntu host instead of virtual machine?
Can you also provide the flash log located in /_installer/logs directory?
Today the problem have been solved.
I’ve change another new board (third one) and flash it using with “real” linux.
No problem! Works great.
I have no clue whether the virtual machine affect flashing or the boards were defected.
My conclusion is not try to flash Jetson with virtual machine. ( I’ve used vmware and virtual box, same problem occurs )
Very thanks for everyone giving help and suggestion.
Edward: I have flashed the first board with Ubuntu host for once. But don’t work too. It’s weird. Anyway now I have a jetson to continue my project…
"I have flashed the first board with Ubuntu host for once. But don’t work too.
=> if you have a chance to try it again now that you have working board to compare with and still have an issue, can let us know again. Thanks for the update.
