dcs-deploy
packages serves as a tool for flashing Nvidia Jetson family devices supporting airvolute hardware. It is developed for Python 3 only.
! DISLAIMER - INSTALL THOSE INSIDE HOST PC !
sudo apt install qemu-user-static sshpass abootimg lbzip2
pip install wget
Put Jetson into force recovery mode
lsusb
command. There should be Nvidia entry in the query.cd into dcs-deploy repo
cd /path/to/dcs-deploy
Run dcs_deploy.py For example:
python3 dcs_deploy.py flash xavier_nx 51 1.2 nvme full
You can list supported configs with:
python3 dcs_deploy.py list
After a successful flash, the Jetson will boot and can be logged in using SSH with default credentials:
dcs_user
dronecore
If you shut the Jetson down after flash and then boot it again, make sure you remove cable/jumper that enables Force recovery mode.
If you run the script with flash
flag, it will re-initialize the Linux for Tegra folder each time. If you just want to re-use the folder and flash the same config to multiple devices, use nvidia flashing script:
Change directory to to kernel_flash
dir
cd ~/.dcs_deploy/flash/<config_name>/Linux_for_tegra/tools/kernel_flash
Launch l4t_initrd_flash.sh
script with appropriate parameters
# nvme
sudo ./l4t_initrd_flash.sh --flash-only --external-only --external-device nvme0n1p1 -c flash_l4t_external_custom.xml --showlogs airvolute-dcs1.2+p3668-0001-qspi-emmc nvme0n1p1
# emmc
sudo ./l4t_initrd_flash.sh --flash-only airvolute-dcs1.2+p3668-0001-qspi-emmc mmcblk0p1
You can use your own root filesystem (rootfs) by providing path to it using --rootfs
flag. The script will use it as is, without any modifications. Using custom rootfs is useful if you want to create backup of your system or you just don't want to install all the software you typically use on the device each time after flashing.
Please run following commands on the Jetson device:
$ mkdir ~/rootfs_merged
$ cd rootfs_merged
$ sudo tar jxpf ../linux-sample-root-filesystem-r3521aarch64tbz2_original
$ cd ~
$ sudo rsync -axHAWX --numeric-ids --info=progress2 --exclude={"/dev/","/proc/","/sys/","/tmp/","/run/","/mnt/","/media/*","/lost+found","/home/dcs_user/rootfs_merged","/home/dcs_user/.ssh"} / rootfs_merged
$ sudo tar -cf rootfs_merged.tar -C rootfs_merged .
$ pbzip2 -k rootfs_merged.tar # output rootfs_merged.tar.bz2
linux-sample-root-filesystem-r3521aarch64tbz2_original
is the root filesystem provided by Nvidia. You can find this on Nvidia website or it is downloaded with dcs-deploy tool. Find it in download
dir (see Filesystem section). So, you need to download this file and place it in the home directory of the Jetson.rootfs_merged
is the directory, where the root filesystem will be merged.pbzip2
is the compression tool, which is used to compress the tarball. You might need to install it using:
sudo apt install pbzip2
Then you can copy rootfs_merged.tar.bz2
to your host pc and use point to it with --rootfs
flag.
--app_size
parameter when using custom rootfs. If you do not set it adequately, APP
partition may be too small for your custom rootfs. app_size
should be bigger than your custom rootfs.If you want to use multiple nvme drives, this is not an issue. Just make sure you plug out secondary NVME during flashing process. After the flashing is successful, you can plug in the secondary NVME. The device will then always boot from the primary NVME (the one that was plugged in during the flashing process).
Keep in mind, that we tried to make this tool as much effective as possible. So, following rules apply:
If you accidentally (or intentionally) left public keys in the rootfs, those are automatically purged. Otherwise each device you flash would be accessible from your host PC which we find harmful. If you feel you want to do this, please find it inside dcs-deploy.py
file and comment it out.
There were some issues specific to our platform and to the Jetsons in general, so we decided to fix them after the flashing or to be more specific - after the first boot. The resources/dcs_first_boot.service
file is a service that is run at only at the first boot. It runs never again. The service runs resources/dcs_first_boot.sh
script on the Jetson device and does following:
The dcs-deploy.py
script can be used instead of Nvidia SDK manager regarding Airvolute hardware. The main advantages are that this package is lightweight and can be used across different Linux distros or Ubuntu versions (SDK manager is strictly tied between Ubuntu and JetPack version). The script does 3 steps in general:
dcs-deploy
package leverages many of Nvidia provided scripts.Preparing the filesystem is crucial for successful device flashing, despite the carrier board manufacturer. The script prepares/extracts:
Linux For Tegra
folder provided by Nvidia.Airvolute overlay
, which satisfies carrier board support (HW) for Jetson devices, that are supported at the moment.Airvolute root filesystem
, which is in fact used as a subfolder inside Linux For Tegra
folder. At this time, this is just a barebones minimal clean filesystem generated by Nvidia tools. We expect to populate this filesystem with custom Airvolute software in the near future.As a root of this filesystem, .dcs_deploy
folder is created inside host pc HOME directory. The structure of the folder:
.dcs_deploy/
├─ download/
│ ├─ <source webpage hostname>/<path to resource without "download/downloads">
│ ├─ .../
├─ flash/
│ ├─ config_1/
│ ├─ config_2/
│ ├─ .../
├─ downloaded_versions.json
config
is the name of the downloaded/extracted configuration consisting of device type, flashing memory type, airvolute carrier board version and jetpack version. Example xavier_nx_emmc_1.2_51
.downloaded_versions.json
consists of configs, that are already downloaded, so if the script is re-ran, those file are not downloaded again and again.download
contains downloaded archives needed for flashingflash
contains extracted folders that are needed for flashing. Those are folders from download
dir + some nvidia and airvolute scripts applied, so the flashing environment is fully ready.ethernet_switch_control
, usb_hub_control
, and usb3_control
are additional services that activate or reinitialize some hardware modules to ensure stable functionality during power cycles. By default, users do not need to modify these services in any way.fan_control
is another extra service that boosts clocks and activates the fan to 100%. If this behavior is undesired, it can be disabled with the command sudo systemctl disable fan_control
.ethernet_switch_control
will reset the USB hub. This is not an issue, but if undesired, it can be disabled similarly to fan_control.mavlink-router
- https://github.com/mavlink-router/mavlink-router.
mavlink-router
, you can specify a connection to the Cube and then define endpoints to which the router should route Mavlink messages (your GCS IP and port).main.conf
file (default location at /etc/mavlink-router/main.conf
).main.conf
file to enable GCS forwarding:[General]
DebugLogLevel = info
TcpServerPort = 0
# Leave to TCP if using SITL
# Main connection to AutoPilot
[UartEndpoint cube]
Device = /dev/ttyTHS0
Baud = 921600
# Note that this is for communication through dev micro USB.
# if you want to use any other interface, change address accordingly.
[UdpEndpoint GCS]
Mode = Normal
Address = 192.168.55.100
Port = 14550
downloaded_versions.json
file is, so if the download folder has been altered script will throw an error.To verify, that the full deployment is sucesfull and that the first boot configuration is done you can run these commands on target:
During 1st boot (right after the flashing is completed):
$ journalctl -u dcs_first_boot
Expected outcome (at the end, you can also check each command's output):
dcs systemd[1]: dcs_first_boot.service: Succeeded.
After 1st boot.
sudo uhubctl
Expected outcome:
List of usb hub port with port 6 disabled.
If the output is not as expected, please reboot the device and run after 1st boot command. If the issue with usbhub is persistent please reflash the device.
On new host kernels, USB flashing problems can happen eg.: ERROR: might be timeout in USB write.
see listing 1). New kernels have enabled USB autosuspend functionality which causes flashing errors. Use following commands to stop usb autosuspend:
$ sudo su
# echo -1 > /sys/module/usbcore/parameters/autosuspend
Listing 1)
1)
Entering RCM boot
[ 0.0378 ] mb1_t234_prod_aligned_sigheader.bin.encrypt filename is from --mb1_bin [ 0.0378 ] psc_bl1_t234_prod_aligned_sigheader.bin.encrypt filename is from --psc_bl1_bin [ 0.0378 ] rcm boot with presigned binaries [ 0.0384 ] tegrarcm_v2 --instance 6-2.4 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt [ 0.0389 ] BR_CID: 0x80012344705DD190400000000F0201C0 [ 0.1299 ] Sending bct_br [ 0.1454 ] ERROR: might be timeout in USB write.