Three questions/issues related to flashing TX1 modules efficiently and reliably:
-
Does nvidia recommend using the flash.sh and tegra_flash.py scripts that included from the
driver package
in a production environment? If so is there any documentation on these scripts beyond what is provided in the driver package tar file from https://developer.nvidia.com/embedded/linux-tegra. -
Our process currently uses
flash.sh
which callstegra_flash.py
from the “driver package” tarfile. We’ve only dug into this script a little bit to see all of what it’s doing to flash, but one of the things appears to be creating asystem.img
file from therootfs
root filesystem. This appears to be a rather lengthy process. We’d like to understand better what this process is. We expect to have some per-vehicle configuration that we want (e.g. hostname) so we will likely want to automate this. If I can better understand the rootfs → system.img process we might be able to speed it up, rather than repeating some of the steps for every flash. -
Is there a recommended way to update the root filesystem with additional ubuntu packages. The driver package documentation recommends using “rootstock” but it appears that rootstock is deprecated and is no longer distributed by canonical with ubuntu. I have tried the following two things, but neither works as I expected:
a. chroot into the the root filesystem under arm emulation with qemu-arm-static
(binding things like /proc/
, /dev/
, etc into the chroot), run apt-get install
to get the packages we want, exit the chroot, run flash.sh
.
b. Flash a devkit module with r23.2 unmodified. Login, then use apt-get
to install additional packages. Create a backup of the root filesystem with:
tar xf Tegra210_Linux_R23.2.0_armhf.tbz2 --directory /mnt/data0/jetson_tx1/bsp_r23.2/
copy that file to my hostmachine and extract it into the rootfs
dir:
sudo tar xpf backup.tar.gz --directory Linux_for_Tegra/rootfs/
then run flash.sh
Neither (a) nor (b) appears to work well. In (a) the X server does not start, there is a popup on boot indicating that the system is in low-graphics-mode and clicking through the popup to get a graphical session just gets me a black screen. In (b) the system boots but freezes at the lightdm login screen and the colors are funky (bluish/purplish) as if the display driver froze.
I can imagine that (b) might be unreliable due to package config scripts querying the system to make decisions, but (a) I would have thought would be completely consistent. If the only thing that is messed up is the X configuration then that is fine, we don’t really want to run X on our machines anyway, but I’m figuring that if X is messed up some other packages are likely to be messed up as well.
One alternative that I haven’t been able to try is to pull off a direct copy of the system.img
. I don’t know if that is possible, using perhaps tegrarcm
. If that is possible please let me know, though if we proceed with that route we will still want a way to alter the rootfs with per-vehicle configuration files.