Hi to all here! First let me thank all of you for a lot of nice info in this forum! Very useful!
I have just started to use a Jetson TK1 and I started with a full re-flash using the Grinch kernel. I spent a lot of time to install and move all our code (plus dependencies) over for compilation on the Jetson itself. All well so far.
I did however find out that I needed to disable the console from the serial port as I want to use it for our application…but this requires change of the kernel command line…gahh…and I flashed the system using fastboot and hence it is tricky…or?
Are there any alternatives for me other than a full re-flash? I could do a backup (clone) first in order for me to save re-install time etc. Then a full re-flash using the saved image. But, I had an idea that I could simply install uboot without changing the rootfs image.
My thought was to (before flashing uboot):
- Copy the kernel into /boot
- Make sure that the extlinux.conf also is in /boot (taken from my host desktop)
Then, reflash only the boot partition (is there such a thing?). Is this possible using flash.sh?
Or, is it possible to just change the command line in the fastboot and reflash that? That would be good enough (I do like uboot better as I am used to that).
@nvidia: How about using uboot as default bootloader for future releases? This is a dev-kit and should be used like that (i.e. not released to customers), hence uboot would be better for this board as it is easier to test variations in kernels/command lines etc.
Anyhow, all ideas&input on this topic are welcome.
I’m not sure if the default system.img includes files for u-boot if created with parameters for fastboot. Which in turn means that there might be changes to rootfs to support u-boot, e.g., it’s already known that /boot/extlinux.conf is needed, but there may be other files similar to this. zImage is one of the obvious files, but who knows what else is required. If-and-only-if those files are already correct would a flash of u-boot only succeed. Then the next question is whether the nVidia boot scripts can flash just u-boot without changing other partitions. That’s a lot to guess about, so I’d think backing up to a spare/separate system.img would be important anyway.
A while back I needed to experiment with this so I made a cut down version of flash.sh which takes all of the same arguments, and generates system2.img, but does not actually flash nor does it require Jetson to be plugged in. You could test if file content is what you expect by first generating a new system.img to compare with and editing sample rootfs until satisfied (e.g., put YOUR version of zImage in). generateSystemImage.sh is available here:
I’d really love it if nVidia were to officially separate out the generation of system.img in this way as a separate program. I have also suggested to L4T maintainers use of u-boot by default.
In your position what I think I would do is to rsync the non-pseudo directories (e.g., /usr is non-pseudo, /proc and /sys are pseudo), something like this run from Jetson (using /boot as one directory example):
rsync -avczr -e ssh --delete-before /boot root@my_host:/mnt/embedded/L4T_loopback/
This gives you an exact copy of system.img which can be used for fastboot (and if all fails you can just flash this again). Then I would create (via generateSystemImage.sh) a u-boot version of system.img, and rsync for non-boot directories, then manually update /boot on the u-boot system.img. Following this I’d do a complete flash using the new u-boot system.img (telling the flash to re-use this new system.img).
Thank you for all ideas and hints. I will definitely make a backup and spend some time to see if there might be an easier way…if found, I will post it here.
Small update on the topic…
Here is what I did to get u-boot operating, but without a full re-install of all I had on my image:
First made a full backup to a system.img on my host (http://elinux.org/Jetson/Cloning) instead of messing around with rsync. Always a little afraid that I mess up when using rsync… :)
I then used linuxdev’s script (THANX!) to generate a separate image (see post above). While doing this, I could see that the script created the zImage (needed and was already correct, even for fastboot flashing) as well as the extlinux.conf. Both files are located in /boot. If you have these locally in your rootfs, you do not need to “generate” a new image using the linuxdev-script.
I then mounted my backup-image using “sudo mount -t ext4 -o loop system.img /mnt”.
I then copied over the “extlinux.conf” into /boot of my backup-image (actually /mnt/boot when mounted in your host).
When done, umount the backup-image from your host.
Finally, I ran a “full flash”, but without rebuilding the image. I also added the flags for it to use the u-boot instead of fastboot. Note that you must use the a matching size-argument for your system.img (the same as first time flashing). This is the actual command line for that: “sudo ./flash.sh -r -S 14580MiB -L bootloader/ardbeg/u-boot.bin jetson-tk1 mmcblk0p1”
After this I just rebooted and it worked! So, in order for u-boot to work you need the kernel file as well as a correct config file installed in your /boot-directory.
I have now successfully edited the command-line (i.e. edit of extlinux.conf) to remove the serial port to be used as console. After the reboot I could see that the /proc/cmdline actually was the one I edited in extlinux.conf and hence u-boot uses this file.
Make sure to have some time available as creating the backup and re-flashing takes some time.
- After changing the cmdline for u-boot (to remove the console=ttySO…) and removal of the “/etc/init/ttyS0.conf” file I now have full access to the serial port and using it in our application!