Just a general statement…much in the way of cross compiling involves setting up an environment for a specific set of software (e.g., the linux kernel has added adjustments to its kbuild to allow a tool chain). Making a general “works for all situations” cross compile environment is much more difficult.
What I mentioned above about system.img would give you the best basis for both individual software setup or a general setup starting point. If you can use a cross compile tool chain, and thus run x86 host to ARMv7 output, system.img on host should work perfectly.
I do not know much about QEMU, but this is how you would make a general environment capable of running ARMv7 software on x86 host without a cross toolchain. You would be able to indirectly run native nvcc ARMv7 on x86 as if your x86 host were ARMv7, using the same libraries and directories as you have on Jetson.
Provided ARMv7 software does not need to run on x86 host, the general system I gave above should work for almost any software via cross compile tool chain. Should you need QEMU to execute ARMv7, the above setup could serve as the file system QEMU uses…so consider the above system.img method as something of a building block useful on its own for cross compile, or from which to build on from QEMU to completely emulate.
rsync has many methods to copy from one machine to another. You could add the rsync server, but I’ve never done this. Perhaps easiest is just an example…my assumption is that you created a directory on x86 “/L4T”, and that on the host root has mounted system.img (mount -o loop -t ext4 system.img /L4T). I also assume the two machines are networked without any firewall restrictions. Keep in mind these rsync options while looking at the example:
-c is checksum method
-r // is recursive
-a // is archive mode
-z // is compress
-v // if you want verbose
-e ssh // tells rsync to use ssh
--delete-before // this deletes system.img files which shouldn't exist on system.img
From TK1, assume loopback mounted on host named “x86”, and that whatever account has root authority for /L4T writes is used (I use root, I’m using Fedora):
sudo rsync -avczr -e ssh /boot root@x86:/L4T
EDIT: sudo rsync --delete-before -avczr -e ssh /boot root@x86:/L4T
Related to rsync and loopback system.img, a subtle fact is to know the “ubuntu” admin account on Jetson is user ID 1000 (UID), group ID 1000 (GID). When you go to use “ls -l” on linux, and it shows user name and group, it’s simply looking those ID numbers up in /etc files. Preserving UID/GID from rsync to x86 means that when you are on x86 and “ls -l” the user and group won’t list as ubuntu/ubuntu unless UID/GID 1000 on x86 are also user ubuntu. On my x86 host development machine I gave my regular user UID/GID 1000…whenever I copy files to/from Jetson via x86 host developer account I never worry about permissions. Any rsync files on loopback mounted L4T owned by ubuntu show up on x86 as my developer account. I’d advise simplifying life by either making your developer account on remote x86 host UID/GID 1000, or else adding an account to Jetson with a UID/GID matching your x86 developer account. UID/GID translations get messy or are an accident waiting for a place to happen.
Another thing about rsync is that not all files are on an actual file system…some are just pseudo systems in ram. You cannot and should not try to copy those. The /proc system is not real, nor is /sys. Also, several /dev files are generated and not truly static, but those which are not static are ok to back up anyway. If you’ve added an SD card or other storage, you probably don’t want them mounted during rsync, although mount point directory structure is fine. I personally run rsync on “/” directories bin, boot, dev, etc, home, lib, media, mnt, opt, root, sbin, srv, usr, var. If you cd to a directory and run “df -T .” it’ll tell you file system type…ext4 is a go, others should be skipped. If in doubt, copy your system.img (always keep a pristine backup anyway) and practice rsync on the copy.
As for use of environment variables, I’ve found that different software might depend on different variables…plus I develop on other non-Jetson Tegra hardware. I got tired of constantly dealing with paths and environment variables, so I use sym links. This was especially motivated by software linked to software linked to software, so on, and somewhere in all those links was some piece of software hard wired for a particular path and ignoring environment variables.