Anyone have a guide on how I can take a working TK1 setup (custom kernel and software) and back it up, and use it to flash other boards?
That info is not about a clone of system, just a clone of the flash which would go onto a tk1 (which in turn you can edit over time to preserve changes). I’m sure there’s a way when in recovery mode to write a script which would read memory, but the research time is high. nVidia knows their own scripts, they’d be the one who writes this.
I have a JTAG debugger, but unfortunately the Jetson and ARM15 do not seem to be easily supported with OpenOCD. If OpenOCD did support this, you would still need a special piece of hardware to do the backup, but you could bypass scripts and directly download the entire eMMC like dd.
So correct me if I’m wrong, but I could follow the instructions for flashing my particular kernel (say the Grinch) but replace the downloaded rootfs with one copied from my working board?
Yes…there are two ways to do this.
Option 1. What you would do is use the command line option to skip building and reuse system.img, “-r”. You would first put your rootfs on this system.img.
Option 2. Let the flash.sh script build a new system.img based on your edited rootfs. Place your system in the sample rootfs instead of the sample…or edit the sample rootfs. This would build a new image based on your rootfs being from a backup. Incidentally, from then on you could use the “-r” reuse option and not keep rebuilding this image. Should you want to make minor changes you could always loopback mount system.img as an ext4 file system and edit, then umount it.
There are basically two things going on. First is to build a file system, which then is copied bit-by-bit exact onto an offset of your eMMC. This is what bootloader/system.img is, an exact clone of what flash puts on the root partition. Second thing it is doing is basically boot loader work, e.g., a boot sector with boot strapping for bare metal to handing off to the kernel. This boot loader work differs depending on which boot loader is used, fastboot or u-boot. In all cases the flash script begins copy of the system.img at the same exact offset, with all boot loader related items at the start of the eMMC. For fastboot, partition “-k 6” puts the kernel where fastboot wants the image, while u-boot puts the image onto system.img’s /boot partition as zImage. Even though u-boot does not use partition “-k 6”, it is possible that some part of the boot process requires this as a spacer if byte offsets are used.
I use u-boot, and my changes are such that I just recursively copy my change tree into a sample rootfs and flash results in my system being already configured before I boot up. I even have multiple zImage kernels in /boot which my u-boot menu then makes available without ever having to install them again. Should I want a new kernel, I just copy a zImage kernel to /boot (with uname -r on the file name), and edit extlinux.conf. Since I mirror this in my edit tree this can be copied onto any future L4T as well, I just recursively place it over the new L4T version rootfs and everything is magically in existence from the moment I boot. Had I used fastboot I would have to update the “-k 6” partition each time and not had a boot menu choice.
Once I have a system.img I like I archive this and can instantly flash this without rebuilding it.