使用NVIDIA SDK Manager刷机NVIDIA Jetson TX2开发套件记录

前言

在最近半个月的时间里开始接触NVIDIA Jetson TX2开发套件。出于任务需求，要把SSD目标检测模型通过TensorRT部署到TX2板子上。刚拿到TX2的时候，板子上安装的是JetPack3.3，系统是Ubuntu16.04。我测试了一下能跑，但是系统桌面有问题。一开始是不显示任务栏，也没有应用程序的边框，搞得打开一个应用就没法关闭，只能强制kill进程。。当时咱也没见过正常的TX2长什么样子啊，第一次用，差点以为这就是正常的样子，心里想着嵌入式设备嘛，资源受限，正常正常！但后面一想不对啊，这么大个系统都跑起来了还会在乎这点？肯定是系统有问题嘛！

更换清华镜像源

然后我开始尝试更换系统桌面，首先我做的事情是更换TX2的国内源，这样下载东西速度会快一点。我使用的国内源是清华镜像源，对于Ubuntu16.04系统，源列表如下：

deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ xenial-updates main restricted universe multiverse
# deb-src http://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ xenial-updates main restricted universe multiverse
deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ xenial-security main restricted universe multiverse
# deb-src http://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ xenial-security main restricted universe multiverse
deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ xenial-backports main restricted universe multiverse
# deb-src http://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ xenial-backports main restricted universe multiverse
deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ xenial main universe restricted
# deb-src http://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ xenial main universe restricted

对于Ubuntu18.04系统，源列表如下：

deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ bionic main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ bionic main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ bionic-updates main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ bionic-updates main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ bionic-backports main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ bionic-backports main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ bionic-security main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ bionic-security main restricted universe multiverse

更换的方式也很简单：打开终端，切换到/etc/apt/目录下，先执行命令sudo cp sources.list sources.list.bk备份原来的源列表，然后sudo gedit sources.list，清空文件内容再根据系统版本添加新的源列表，最后执行sudo apt-get install update更新源即可。

搞笑问题GET

拿到系统有问题的TX2板子本身已经搞笑了（之前有人用过的。。），但是后面的事情更让人无语。前面儿不是说系统桌面有问题吗，那换一个就不得咯。在sudo apt-get upgrade更新软件后没用，然后我突然灵光一闪（要悲剧了。。）：换个Gnome桌面吧！美观大气！网上随便一搜，教程一大堆，装好重启后发现，玩完儿！直接黑屏也无法进入桌面，Gnome桌面的兼容性有问题。按理说遇到这样的问题，直接Ctrl+Alt+F1进入控制台卸载刚安装的软件就完事大吉了，但要命的是TX2板子这时候一闪一闪亮晶晶，每隔2、3秒就闪屏一次，键盘也是反应巨迟钝，基本上是输入N次响应一次的情况，导致进入控制台后根本无法登录用户。能想象在这样恶劣的条件下还是在无提示的情况下输入nvidia几个字符密码的感受吗？我是深切体会到了，简直是绝望的赶jio！在失败了N次后我想就放弃了吧，但是任务在那里又不能不继续，这是真的难受。在又尝试了很多次后，我偶然地发现（哥伦布发现新大陆了简直。。）在闪屏后极短的一段时间内，暴击键盘是可以输入一个字符的！哇，简直了。。然后在接下来的几分钟里，我跟着闪屏的节奏蹦跶蹦跶地硬是登录成功了，真是嗨心！在登陆用户、卸载Gnome桌面后，TX2终于恢复了平静，也是松了一口气。
可能有人会问，为什么不直接重新刷机呢？费那劲儿！这就要扯出更扯淡的话题了，因为我拿到的板子刷机的USB口没了。。不要问是哪个XX干的，反正就是没了。。唉，折腾得我！后面重新安装了Unity桌面，工具栏和边框倒是出现了，但桌面背景始终是漆黑一片，不过好歹能正常用啊。我给老师反映不能刷机的问题，咱老师想了一下说道：我们不是有两块板子吗？你交换一下核心板，用另外一块板子刷机不就得了，做人要聪明一点嘛！（哦~~厉害，果然那啥还是老的辣！）总之接下来进入正题，刷机记录奉上。

准备Host OS

同我们开发嵌入式软件一样，要对TX2开发套件刷机需要先准备好一个X64架构的宿主机系统。NVIDIA官方对宿主机系统给出的要求如下：

即至少8GB内存的Ubuntu16.04或者Ubuntu18.04系统。上面虽然没说，但宿主机的磁盘空间也不能太小，否则将不能下载、安装所需的软件。一般来说100GB的磁盘空间是合适的。这里推荐宿主机使用虚拟机，因为要安装JetPack到TX2板子上需要在宿主机上安装CUDA、cuDNN等软件。安装在虚拟机上可以避免同时安装多个版本的软件所可能引起的冲突，同时虚拟机也是支持安装的。

下载NVIDIA SDK Manager

NVIDIA SDK Manager的官网下载地址为NVIDIA SDK Manager，目前最新的版本是1.2.0，对应的Ubuntu镜像版本是18.04，JetPack可选择4.2 - 4.4之间的版本。下载后在宿主机上执行命令sudo apt install ./sdkmanager-[version].deb进行安装，对于1.2.0版本，对应的安装命令为sudo apt install ./sdkmanager_1.2.0-6738_amd64.deb。SDK Manager在运行时对主机内存和显示屏分辨率有一定的要求，即最少8GB内存和分辨率1440x900以上。如果内存达不到要求将无法下载、安装软件，分辨率达不到要求则会导致部分显示。
NVIDIA SDK Manager的优点大致在于：可获取最新的系统镜像，可根据需求安装指定版本的JetPack，同时它支持在线下载、离线安装的模式。这种模型可使得软件一次下载，多次使用。也就是说有多台主机的情况下，我们只需下载一次安装包，就可以在多个宿主机上多次使用，而不用费时费力地在每台机器上都下载一次。

下载离线安装包

下载安装好NVIDIA SDK Manager，并且检查网络无误后，即可打开软件下载所需的安装包。我在使用时发现如果使用在线安装（边下载边安装）的方式，虚拟机的存储空间总是报不足的警告，而换成离线安装的方式则能正常运行，因此推荐使用下载离线安装包的方式。SDK Manager启动后的界面如下：

如果没有NVIDIA账号需要去官网注册一个，登陆栏可以选择登陆NVIDIA账号，或者选择无需登陆的OFFLINE离线安装模式。如果没有下载离线安装包，那么需要先登陆账号进行安装包的下载。下载完成后则可以选择OFFLINE模式进行安装。登陆NVIDIA账号后的STEP1界面如下：

在STEP1界面中，需要选择开发套件的类型以及对应的JetPack版本，我这里选择的是Jetson TX2，JetPack选的是4.4DP版本，可按照需求进行选择。
在STEP1点击CONTINUE后，出现的STEP2界面会加载前一步选择的安装包，包括Ubuntu系统镜像和JetPack软件包，用户可根据需要选择性下载。需要注意的是，由于网络原因可能导致STEP2加载失败，没办法只能耐心重试。打开的STEP2界面如下：

在点击同意用户协议后，即可点击CONTINUE下载软件。SDK Manager默认采用边下载边安装的方式，如果宿主机的内存或存储空间不足，则会弹出提示不能下载。这时可以勾选下面的Download now, Install later（离线安装）选项进行下载。如果网络不好的话，下载的过程是非常漫长的，并且中间可能会失败，要不断重试，直到安装包下载完毕。下载完成的界面如下所示：

离线安装

离线安装包下载完毕后，点击FINISH AND EXIT选项退出软件，然后再次打开软件，选择OFFLINE模式，并指定刚才软件下载的存放目录作为安装目录（默认的目录是/home/user/Downloads/nvidia/sdkm_downloads）开始进行离线安装。打开的OFFLINE界面如下：

点击START按钮，会出现上面STEP1、STEP2的内容。在STEP1中选择下载时的选项，STEP2中同意用户协议，即可进入STEP3中开始离线安装。SDK Manager会先在宿主机上安装必要的软件。安装完成后，如果STEP2中勾选了Jetson OS的选项，则接着会弹出下面的刷机界面：

SDK Manager提供了两种刷机模式：手动模式和自动模式。在手动模式下需要TX2板子连接电源但保持关机，并且使用USB线连接到主机。接着按下恢复按键，再按下、松开电源按键开机，期间保持恢复按键按下，停顿一会儿后松开恢复按键，即进入恢复模式。此时在宿主机上可以看到TX2的USB设备接入（恢复模式下TX2的USB设备名与正常开机模式下不同），然后点击上面的Flash按钮，进入漫长的自动刷机过程。
在自动模式中更加简单，如果TX2板子已经有烧写过系统，那么使其正常开机，然后连接USB到主机，使TX2与主机在同一局域网下，在主机上输入TX2的IP地址、用户名和密码后，软件会自动配置TX2进入恢复模式对TX2进行刷机。
注意在刷机过程中不能中断，当然可以按暂停按钮，不过那也得等当前步骤安装完成后才会暂停。在TX2刷机完成后，并不能直接安装JetPack，需要先把刷机后的TX2板子开机进行初始化，并手动打开ssh服务后才能继续通过ssh远程对TX2板子进行JetPack的安装。在安装JetPack的时候不需要连接USB到主机。安装JetPack的界面如下所示：

要注意的是，在安装JetPack的过程中，重新打开SDK Manager时一定不要选中Jetson OS的选项，也不需要连接TX2的USB到主机，不然就可能会重新把TX2板子给刷机一次，白白浪费时间。
在安装完成后会弹出STEP4安装完成的界面，到此TX2刷机便已经全部完成。如果在之后有新的JetPack需要安装，或者要刷新的系统，都可以再下载然后单独刷机或者进行安装。总地来说流程还是比较简单滴。

注意事项

在安装过程中，如果出现安装失败的提示，不要直接退出软件，要点击RETRY FAILED ITEMS对失败的部分重新安装，不然重新启动软件后它会重装所有选择的条目。由于网络的原因可能会多次失败，要一直重试直到所有软件安装完毕。还有就是，要确保在安装JetPack的途中TX2可联网，因为在宿主机安装的过程中需要TX2联网下载一些软件依赖。最后，宿主机上需要安装Python，因为在安装过程中会用到主机上的python命令。

结语

使用NVIDIA SDK Manager刷机还是很快捷方便的，在整个过程中实际上最花时间的是安装包和依赖的下载，特别是在网络环境差的时候更是磨人。因此也奉劝小伙伴儿刷机的时候一定要在网络好的地方搞，不然真的很伤人。。我目前使用TX2实现的功能还是很简单的，就是把SSD目标检测模型部署上去，通过视屏检测的方式搭一个DEMO。实际上TensorRT安装包中已经附带了相关的示例，使用TensorFlow的例子在刷机后TX2系统的/usr/src/tensorrt/samples/sampleUffSSD/目录下可以找到，而例子使用的SSD模型是谷歌官方提供的ssd_inception_v2_coco，通过UFF转换模型后可直接在TX2板子上运行，并且在MAXQ模式下也能达到20 FPS左右，还是挺不错的。但我发现这个例子想用谷歌的其他SSD模型就不行，例如ssd_mobilenet_v2_coco。这两个模型实际上输入输出都是一样的，区别在于构建计算图的过程中节点的操作类型、以及顺序不同，导致无法直接应用到TensorRT官方的例子中。对此，在GitHub上已经有一些开源项目实现了如ssd_mobilenet_v2_coco等模型的部署，有兴趣的小伙伴儿可以看看。不过我更无聊一点，相比起他们通过修改UFF的config.py文件顺利进行模型的转换，我使用的方法则是直接重构计算图以满足需要，简单直接粗暴。最后也成功把ssd_mobilenet_v2_coco部署到了TX2板子上，整个过程也是比较简单的，有空可能会写篇博客记录一下。