Slesinger I have this same problem with PCIe Intel Centrino Advanced-N 2230 - i don’t know why yet. Something wrong with Centorino N series and kernel. I’m still looking reason and solution.
Serial console has always been simple, and available even before the kernel starts loading. I’m very curious, how might serial console improve once the kernel loads?
:) linuxdev you are right - sorry, sometimes my engilish is fail - i mean some changes in USB Serial Converter support like adding generic serial driver and somes modules. sorry!
This is the u-boot prompt (my preference), going without error up to this point. If you hit a key stroke on serial console (and obviously you have serial console here), then it is supposed to halt here. You can type “help” to see commands, but continuing to the next stage is command “boot”…see what happens when you run “boot” (I’m assuming the keyboard was touched to halt).
Now if it halted by itself, it is at the kernel selection stage and something caused it to not continue. For u-boot, you do not flash a kernel, no more need (it doesn’t hurt to put a kernel in the default “-k 6” for fastboot, u-boot ignores it). Simply place the zImage in /boot. You can edit /boot/extlinux.conf to have more than one kernel listed…I renamed the original zImage-uname -r, and created several custom zImages with altered uname -r and placed them there with that in the name, editing extlinux.conf to make each one available (e.g., I have one with kernel debug symbols, another with more extreme debugging, another for some bridge code testing).
Here’s a hint on how to get out of this if you flashed in such a way that you don’t have access simply because of lacking the zImage in /boot. The flash.sh script has an option “-r” which skips rebuilding the bootloader/system.img file. This is a huge part of the time in full flash. You can temporarily loopback mount this and copy your zImage to this, then umount it, make sure your loop0 isn’t still used by this edit. Then flash with “-r” and it’ll use your edited filesystem. Or you can do full rebuild of system.img but place zImage and extlinux.conf edits in the sample rootfs first.
@linuxdev, it didn’t halt itself so no worries. I just wanted to point out that U-Boot appears to work fine. :)
Thanks for the concise U-Boot summary. Good point about bypassing flashing since flashing takes a very very long time right now.
A while ago I saw an NVIDIA dev comment that he was beginning to prefer booting from an external USB dongle… I’m now guessing that the dongle let him avoid long flashing (or copying) sessions. :)
Well…I don’t know if it is external USB flash, or external USB NIC for network boot. u-boot helps in all cases, and a tour of config files in /boot is interesting. Take a look at “ls /boot/extlinux”. You’ll find different kinds of boot which can be set up without even touching the Jetson…e.g., if it is a USB memory stick, you can load system.img onto this, snap it into Jetson, and use u-boot to pick this. The flash.sh script never needs to be used for such things once Jetson is set up…that editable menu is a huge time saver, along with re-using system.img.
Excellent! Looking forward to seeing the I/O shield.
It would be cool if someone would also make a DisplayPort output as well. I dug around a few months ago and there is a cable vendor that seems like they’re willing to make custom cables for almost anything. I think Intel references this vendor in some of their PDFs.
Maybe your I/O shield could include a 4K 60Hz DP port!?
Santyago,
do you think it might be possible to load Grinch on the SDHC card as an alternative boot device?
I am a newbie and Grinch looks great for the FTDI support I need, but I am reluctant to blow away
the eMMC image :-)
