Batch Production Deployment: Cloning Image of Apalis TK1 + Ixora

Installing the NVIDIA Jetson TK1 JetPack 2.2.1 requires a significant amount of time, even after the Ubuntu rootfs has been updated correctly using the Toradex procedure. How would you go about cloning the final NAND image (that including the VisionWorks and CUDA samples) and what approach would you then use to deploy such image on a stock Apalis TK1 + Ixora pair? So far, I am guessing one could:

  1. boot from SD card (how to do that…),
  2. clone the NAND with a dd command to a USB stick,
  3. boot the blank Apalis with SD card also,
  4. dd the USB drive image to the blank NAND.

I read on the forum this is not recommended though… why?

Bests,

The boot from SD card thematic is briefly covered in the following article on our developer website. However rather than taking the detour via SD card booting one could also simply revert to U-Boot’s UMS feature as explained here.

I read on the forum this is not recommended though… why?

I guess you more or less answered that one on and by itself. A regular distro like Ubuntu is just not really very well suited for any embedded use (e.g. huge footprint, hard to customise etc.) which is why our regular Embedded Linux BSPs are based on Angstrom/OpenEmbedded/Yocto. The big advantage being that one can easily customise images in a reproducible manner (see recreate and customize BSP with OpenEmbedded). Such customisation can even include the top-level application layer as e.g. elaborated here. For more information on our recommended production programming procedure please have a look here.

When it comes to take advantage of Apalis TK1 in Convolutional Neural Networks applications, Ubuntu is the best choice, and the most supported one for Caffe and Tensorflow. We understand it’s not the best choice for an embedded use. Given Ubuntu as a must, what’s the recommended approach to deploy?

I read on the forum this is not recommended though… why?

I guess with that you meant why dd’ing is not recommended: The main reason is that Linux installations typically generate machine specific identifications on initial boot (namely systemd’s machine id, but not applicable for that version of Ubuntu, and OpenSSH’s host keys, but there might be other packages which do machine specific initialization). If you are aware of this, you can probably undo those initialization/manually redo them. But if that is taken care of, I guess cloning is a viable solution to deploy Ubuntu.