说明

• 嵌入式开发中，重启操作是最常用的操作之一，由于其操作简单，不容易受到关注，但是不同的重启方式实现和现象其实是不一样的。

断电重启

• 操作：关机后再开机，例如：拔掉电源再接上电源或者电池没电后再充电开机。
• 该方式是完整的重启操作，硬件会重新上电，内存等都会被重置，软件会重新执行，重新初始化等。

软重启

• 操作：在Linux平台上手动执行reboot命令重启设备，其它平台类似。
• 不同于断电重启，软重启是软件机制，其通过信号或者其它方式通知各个模块设备需要重启，模块需要自己实现模块的重启，从而实现设备的重启。

异常现象

1. 外挂设备需要自主实现软重启

• 事例：智能家居项目，在开发板上外挂一个rf模块（单片机），调试时发现在开发板上执行reboot，单片机不会有任何重启操作，重启后由于设备端与单片机端数据和状态不一致出现一些异常。
• 确认原因：系统重启时，重启命令并没有传递到外挂模块，外挂模块根本不知道开发板已重启，需要自主实现通知流程。

2. 重启卡顿问题

• 嵌入式开发中，有时会出现执行reboot后，设备并没有立即重启，而是等了几分钟，甚至很久设备才重启。

2.1 应用层卡顿

• 事例：MT8516平台，出现重启卡顿，使用“reboot -f”才能立即重启。
• 确认原因：MT8516平台使用的是systemd机制，reboot命令执行会向initd进程发送信号，initd再向其子进程（所有进程）发送信号，等待它们运行结束，开发板主程序处理有问题，在收到信号后，做清理操作时做了串口设备的flush操作，该flush操作会一直等待执行完成，但是其它进程和线程一直在写该串口设备，导致死锁，进程无法退出，所以设备无法重启。

2.2 内核卡顿

• 事例：ssc323平台，出现重启卡顿，使用“reboot -f”也无法解决。
• 确认原因：执行内核重启时，平台提供的wifi驱动处理有问题，概率性出现忙等，所以设备无法重启。

大致原理

• 手动执行命令“reboot”，实际上是执行的reboot程序，在嵌入式平台中，其实现在busybox中。
• 查看busybox中的源码可知，有两种情况

1. reboot -f

• 直接调用内核重启接口，并不通知上层应用，可能导致上层应用缓存丢失等。

2. reboot 其它选项

• 给第一个进程init发送TERM信号，init收到该信号后，会向其子进程（即所有进程）发送该信号，待其它进程处理TERM信号完后，init进程才会调用内核重启接口，进行内核重启。