12月31日，在这个慵懒的下午，原以为2020年最后一天的工作可以愉快地收尾，
没想到下午3点半收到客户的求救信息：
客人的Jetson Xavier NX开发套件 ——
也就是用户使用一张有效的TF系统卡，并不能够启动系统，直接掉进RAM Disk里的bash中. 而并不能进一步的mount root和后续启动过程.
我们工程师很敏锐地判断可能性：存储卡的设备名称发生了改变: 从/dev/mmcblk0变成了/dev/mmcblk1, 从而让原本应该从/dev/mmcblk0上挂载的根文件系统操作失败。
为了确认这一点，工程师让用户立刻使用如下指令查看是否跟我们预期符合:
代码语言：javascript复制ls -l /dev/mmc*客户很配合，立刻发来图片：
果然跟我们预期的一样，工程师判断客户应该做了以下三点之一，导致发生这个情况：
(1)改变了EEPROM,
(2)改变了启动电阻
(3)准备加焊EMMC芯片, 从而脱离存储卡启动,
于是我们问客户——
于是我们询问客户：
(1)是否使用外置编程器进行的修改?
(2)修改前有无备份原始内容?
客户表示——
我们让客户尝试：
(1)将一个好的卡的kernel参数配置文件, 改成mmcblk1p1, 保存. 卸载该卡.
(2)用适配过的该卡, 插入你的坏NX, 启动.
并给予了详细的步骤。
时间已经到了12月31日下午4点49分，
于是这个问题变成了跨年问题....
假期总是短暂的，一下子就到了1月4日上班日，也就是今天，一早客户传来了好消息：
客户描述了流程：
1.我先用另一个正常sd卡设置从mmcblk1p1进入系统； 2.然后再自己写了个能修改emmc的程序，参照另一个正常的NX开发板，更改了0地址的8个字节； 3.拔出sd卡，插入之前原本的sd卡，启动、重启、关进入。机启动都正常
总结这个问题解决的关键就是：
1. 从一个好的nx上读取该eeprom的前8B。
2. 在没有外置联机烧录器的情况下，同时也不想买一个，先临时启动坏nx，从而能在系统里刷新，是我们为何要修改系统，适配该坏nx的原因。
3.NVIDIA的官方文档里提供了原始extlinux.conf内容, 从而让客户能改成mmcblk1启动
案例总结：
1.这个客户十分地坦诚，让我们很快定位了问题！
出现问题，有的客户不能诚实地告诉我们到底发了什么，总是一句：我什么也没干就这样了——这无益于解决问题。而面对这样的客户，我们也确实什么也干不了，只能走NVIDIA的返修流程。要知道，NVIDIA一个正常的返修流程是要３个月时间，有些明明可以自我解决的问题就这样白白浪费时间。
2.这个客户十分配合，让我们可以在解决问题的道路上共同成长！
我们提供的方案，客户能够配合去尝试。相信在这个过程中无论是客户，还是我们，都获得了一个宝贵的解决问题的经验。
3.有的问题确实不属于硬件故障，但会让硬件启动不起来。
