RV1126开发板烧录与SSH登录实践

RV1126 开发板：固件烧录与 SSH 登录全流程记录

在本篇笔记中，我们结合一次实际踩坑过程，系统地梳理基于 RK1126/RV1126 开发板，使用 瑞芯微官方开发工具 烧录固件、理解三种典型设备状态（MASKROM / LOADER / ADB），以及最终通过光纤/以太网链路实现 SSH 远程登录 的完整步骤。

目标是把这次实战过程沉淀成一份可以「从零照着做」的操作文档，方便以后自己排错。

第一部分：整体流程与核心概念

1. 实验环境概览

本次实践的典型连接和软件环境如下（不同项目数值可能略有差异）：

主机（Windows）
- 网卡 1：无线网卡 WLAN，IP 例：192.168.31.111/24（上网用）
- 网卡 2：光纤/以太网口（在系统中表现为普通以太网适配器，如 以太网），用于直连开发板
- 安装工具：
  - 瑞芯微开发工具 AndroidTool v2.7.1（或相近版本）
  - adb 工具（Android Debug Bridge）
  - SSH 客户端（如 MobaXterm / PuTTY / OpenSSH）
开发板（RV1126）
- SoC：RK1126
- Flash：eMMC / NAND（本次为 256MB Samsung Flash）
- 接口：
  - USB（连接 PC，用于刷机、adb 调试）
  - 光纤（在 PC 侧表现为一个以太网适配器 Meta 或普通网卡）
  - 以太网口 eth0（Linux 系统内的网络接口）

2. 三种典型设备状态

在 Rockchip 平台上，刷机和启动过程中常见三种设备状态：

MASKROM 设备
- SoC 内部 BootROM 模式，属于最底层、最"原始"的救砖状态。
- 典型特征：
  - AndroidTool 底部显示：发现一个 MASKROM 设备
  - 只能接受 PC 发送的低级读写命令，用于 修复 IDB、重建分区、彻底刷机。
  - 此时 Flash 上的 Loader 系统是空的，不会启动 Linux/Android 系统，自然也没有 adb / ssh。
- 处于 MASKROM 状态时，开发工具中大多数"读取 Chip 信息 / 读取 FlashID"等功能都不可用，只能做最基本的下载 Boot、刷写固件等操作。
LOADER 设备
- BootROM 已经从 Flash 中成功加载了 Loader（如 MiniLoader / u-boot），进入了「升级模式」。
- 典型特征：
  - AndroidTool 底部显示：发现一个 LOADER 设备
  - 可以使用「升级固件」「下载镜像」等功能，方便地刷 update.img 或若干分区镜像。
  - 依旧不会启动完整操作系统，主要作用仍是 固件升级。
ADB 设备
- 开发板已经从 Flash 正常启动，Linux/Android 系统运行起来，并启动了 adbd 服务。
- 典型特征：
  - 在 PC 上执行 adb devices 时会看到一行 xxxx device
  - 可以 adb shell 直接进入板子的 shell 终端。
- 此时系统已经正常运行，可以：
  - 配置以太网 IP
  - 检查/启动 ssh 服务
  - 做应用调试与日志采集
- 注意：在 ADB 状态下，AndroidTool 仅把设备视为调试终端，不能再直接读取底层 Flash 信息，如需读取 Chip/Flash 信息，需要先在工具中「切换」回 LOADER 模式。

从整体流程看，状态之间的关系可以简化为：

MASKROM（救砖） → 刷入 Loader 与固件 → LOADER（升级） → 重启 → ADB（系统正常运行）

第二部分：使用瑞芯微开发工具烧录固件

1. 固件与工具准备

在开始刷机前，需要确认以下文件和工具：

AndroidTool / 瑞芯微开发工具
- 版本示例：v2.7.1.0
- 用于识别 MASKROM / LOADER 设备、下载 Boot（Loader）、刷写固件镜像。
固件镜像
- 简单场景使用 update.img 整包固件，只能在 LOADER 或 MASKROM 设备状态下烧录；
- 也可以使用分区镜像（如 boot.img、rootfs.img）配合「下载镜像」模式刷写。

务必确保固件是 板卡厂商提供的匹配版本，否则即使工具显示「下载成功」，设备仍可能无法从 Flash 启动，只能反复进入 MASKROM。

2. AndroidTool 中的设备类型与"切换"规则

在瑞芯微开发工具中，底部状态栏常见的几类提示及含义如下：

发现一个 MASKROM 设备：处于 BootROM 救砖模式；
发现一个 LOADER 设备：处于升级模式，可刷 update.img 或镜像；
发现一个 MSC 设备：以 USB 大容量存储设备方式连接；
发现一个 ADB 设备：以 ADB 调试设备方式连接；
发现一个 MTP 设备：以媒体传输设备方式连接；
发现一个 UVC 设备：以 USB 摄像头设备方式连接。

几个关键规则：

烧录 update.img 或分区镜像，只支持在 LOADER / MASKROM 状态下进行；
当状态栏显示 MSC / ADB / MTP / UVC 等设备类型时，需要先点击工具上的 「切换」 按钮，将设备切换到 LOADER 或 MASKROM 模式，再执行「升级固件」「下载镜像」等操作；
「读取 Chip 信息」「读取 FlashID」「读取分区信息」等大多数底层操作，只支持在 LOADER 状态 下使用；
MASKROM 和 ADB 状态下，这些读取功能通常不可用，这是工具设计上的限制，不代表板子一定损坏/连接异常。

3. 从 MASKROM 状态刷入 Loader 与固件

假设此时 AndroidTool 底部显示：发现一个 MASKROM 设备，刷机操作大致如下：

连接设备
- 用 USB 线连接 PC 与开发板的 USB 调试口。
- 按厂商说明短接/按键，使板子进入 MASKROM 模式（救砖模式）;或者选择在瑞芯微开发工具的高级模式中选择进入 Maskrom模式.
- AndroidTool 状态栏出现 发现一个 MASKROM 设备。
下载固件
- 在工具中选择合适的 .img 文件。
- 载入固件后升级。
- 日志中出现：
  - 下载Boot开始
  - 下载Boot成功
- 工具会自动进行：
  - 准备IDB开始 / 成功
  - 下载IDB开始 / 成功
- 接着刷写整包固件：
  - Start to download uboot
  - Start to download boot
  - Start to download recovery
  - Start to download rootfs
  - 直至 下载固件成功
重启设备
- 工具最后会执行 重启设备开始 / 成功。
- 此时 USB 连接短暂断开，设备尝试从新刷写的系统启动。

4. 异常情况说明

实战中可能遇到的日志错误包括：

刷完后反复上电仍然只看到 MASKROM
- 说明系统仍无法从 Flash 启动，常见原因：
  - Loader 文件与芯片/板卡不匹配
  - update.img 与实际硬件不匹配
  - Flash 本身存在硬件问题
- 处理：
  - 优先确认开发板的固件与固件文件的匹配性
  - 必要时携带完整刷机日志与厂商技术支持沟通

当刷写成功且硬件正常时，设备上电后应进入 ADB 设备 状态，可以在 PC 上用 adb 进行验证。

第三部分：ADB 模式与网络配置

1. adb 是什么？

ADB（Android Debug Bridge） 是 Android / 嵌入式系统中常用的调试桥接工具，本质上是一条「PC ↔ 设备」之间的调试通道。

在本项目中，adb 的主要用途：

adb devices：查看当前连接的设备列表
adb shell：进入开发板的 shell 终端
adb push / adb pull：在 PC 与开发板之间传输文件

与 SSH 相比：

adb 更多是「Android / 嵌入式开发」场景下的通用调试入口。
SSH 是标准的远程登录协议，偏向普通 Linux 服务器使用。
在板子网络未配置之前，adb 通常是我们第一次进入系统的入口。

Rockchip 平台上的系统架构与 adb 的关系

在 Rockchip 平台上，底层几乎都是 Linux 内核，只不过版本和补丁是 Rockchip 自己维护的 BSP 分支（比如 4.4 / 4.19 / 5.x，具体可以在板子上通过 uname -a 查看）。在这个内核上，可以跑两类东西：一类是完整的 Android 系统（Android Framework + HAL + 一堆 APK），另一类是纯 Linux 发行版（比如 BusyBox/Buildroot/Yocto 定制出来的 rootfs，只跑命令行和你自己的服务）。从 RV1126 编译烧写的固件版本信息（如"固件版本 8.1.00"）来看，很可能是基于 Android 8.1 的方案，或者至少是"Android SDK 改出来的 Linux 系统"。

adb 只是一个"调试通道工具"，不等于 Android 本身。设备里跑一个守护进程 adbd，PC 上有 adb 客户端，两者通过 USB/TCP 说一种自定义协议。当执行 adb shell 的时候，本质就是让 adbd 在设备上启动一个 /system/bin/sh 或 /bin/sh，把标准输入输出转到 PC。这套机制对"上层是 Android 还是纯 Linux"没有强依赖，只要 rootfs 里集成了 adbd，就能用 adb 调试。Rockchip、全志这类做多媒体/安防方案的厂商喜欢用 adb 的原因主要有：他们很多 SDK 起源于 Android，现成就有 adb；Windows 上装个 adb.exe 就能连，驱动生态成熟，对客户友好；adb 自带 adb push/pull、端口转发等功能，调试方便。所以你现在看到的情况是：底层是 Linux 内核，上层是"Android SDK 体系 + BusyBox 风格的用户空间"，再加一个 adbd，当成统一的调试入口。

从更宏观的角度理解 Linux 和 Android 的关系：Android 可以看作 Linux 内核加上一整套 Google 定制的用户空间和应用框架。内核基本就是 Linux，加上一些 Android 自己的补丁。用户空间不是 glibc，而是 Google 自己的 C 运行库 bionic，有 Android Framework、Java 虚拟机、系统服务、APK 等，Shell 环境也有 busybox/toybox 等工具，所以命令行和"普通 Linux"很像。因为内核是 Linux，所以所有"Linux 开发"的基础知识（进程、线程、IPC、网络、文件系统）在 Android 上 90% 都通用。也正因为这种"基因同源"，厂商做嵌入式板子时，经常会要么直接跑 Android，顺便开放 adb、串口和 ssh，要么基于 Android SDK 把上层砍掉，只保留 Linux + 少量 Android 组件（比如 adbd），做成"看起来像 Linux，又带一点 Android 味道"的固件------目前的 RV1126 很可能就是这种。

2. 进入 ADB 模式

刷机成功、设备正常启动后：

确保 USB 仍连接在 PC 与开发板之间。
在 Windows 的终端（cmd / PowerShell）中执行：
bash 复制代码
```
adb devices
```

正常情况会看到类似输出：

text 复制代码

List of devices attached 
63bdd414d64665fe        device

之后执行：
bash 复制代码
```
adb shell
```
若成功，会进入开发板的 shell，提示符类似：
text 复制代码
```
[root@RV1126_RV1109:/]#
```

若 adb devices 为空、或 adb shell 报 device not found，一般说明：

板子尚未正常启动系统（仍在 MASKROM / LOADER）
PC 上 USB 驱动未正确安装为「ADB 接口」
PC端 adb 驱动未安装成功或固件内未启动 adbd 服务

3. 在 adb shell 中配置以太网 IP

进入 adb shell 后，可以像在普通 Linux 中一样操作网络接口。示例：

bash 复制代码

# 查看网络接口信息
ifconfig
# 或
ip a

在本次实验中，eth0 为板子上连接光纤收发模块/网口的以太网接口。配置静态 IP 示例：

bash 复制代码

# 可选：先清理多余的自动链路本地地址
ip addr flush dev eth0

# 为 eth0 配置 192.168.100.75/24，并启用接口
ifconfig eth0 192.168.100.75 netmask 255.255.255.0 up

配置完成后再次查看：

bash 复制代码

ip a show eth0

应该能看到：

text 复制代码

2: eth0: ...
    inet 192.168.100.75/24 brd 192.168.100.255 scope global eth0

此时从网络角度看，只要 PC 在同一网段，就可以通过 ping 或 ssh 访问这块板子。

第四部分：SSH 的基本概念

1. SSH 是什么？

SSH（Secure Shell） 是一种用于远程登录和远程命令执行的安全协议，特点包括：

基于加密通道传输数据，防止明文泄露。
默认使用 TCP 端口 22。
支持密码登录、密钥登录等多种认证方式。

在本实验中，SSH 的用途主要是：

从 PC 直接登录到 RV1126 开发板的 Linux 系统。
替代 adb 成为日常调试、运维的主要入口（终端体验更佳、工具生态更丰富）。

2. SSH 登录的基本流程（逻辑层面）

PC 与板子通过某种物理介质（网线/光纤）形成以太网链路。
双方各在一个 IP 网段内配置一个地址（如 192.168.100.74 与 192.168.100.75）。
板子上运行 SSH 服务（sshd / dropbear），监听端口 22。
PC 上运行 SSH 客户端，执行：
bash 复制代码
```
ssh root@192.168.100.75
```
通过密钥/密码完成认证后，即可获得远程 shell。

无论「无线」还是「网线」，对于操作系统本身，都是一个普通的以太网接口，只要 IP 层配置正确，SSH 的使用方式完全相同。

第五部分：通过光纤 / 以太网实现 SSH 登录

本节以一次成功登录的实际过程为例，说明从「只剩 adb」到「可以通过光纤链路 SSH 登录」的完整步骤。

1. 确认物理与链路状态

物理连接
- PC 的以太网口（Realtek 网卡）通过网线或光纤收发模块连接到开发板。

Windows 中网络适配器名称可能为 以太网、Meta 等。

链路状态检查
- 在 Windows 中确认该适配器状态为「已连接」或「正在识别...」。
- 在板子 adb shell 中：
  bash 复制代码
```
ip a show eth0
```
- 确保 eth0 处于 UP 状态。

2. 在板子上配置固定 IP

在 adb shell 中执行：

bash 复制代码

ip addr flush dev eth0
ifconfig eth0 192.168.100.75 netmask 255.255.255.0 up

这里 192.168.100.75 可以在小型本地私有地址 192.168.100.0/24 内任意选择, 只需要保证后续的 PC 端地址与其地址的网段保持一致即可.

再次确认：

bash 复制代码

ip a show eth0

此时板子的 IP 为 192.168.100.75/24。

3. 在 Windows 上为以太网适配器配置同网段 IP

打开：设置 → 网络和 Internet → 以太网。
选择当前连接开发板的那个以太网适配器，点击「IP 分配」旁边的编辑。
将「自动 (DHCP)」改为手动，打开 IPv4，填写：
- IP 地址：192.168.100.74
- 子网掩码：255.255.255.0
- 默认网关：可留空
- DNS：可留空或随意填写（与本地调试无关）
保存后，在 PowerShell 中确认：
powershell 复制代码
```
ipconfig
```
能看到对应的 以太网 适配器为 192.168.100.74。
为避免路由混淆，调试阶段可临时关闭 Wi-Fi（WLAN 适配器），让所有 192.168.100.* 的访问都走这张以太网卡。

4. 测试连通性并通过 SSH 登录

在 Windows 上测试连通性：
powershell 复制代码
```
ping 192.168.100.75
```
若能得到稳定的回复（ TTL = 64, 若TTL = 128不能说明 IP 访问连通），说明 PC 已经通过光纤/网口直接和板子建立了 IP 层连接。
使用 SSH 登录（以 MobaXterm 为例）：
- 新建会话 → 类型选择 SSH
- Remote host 填写：192.168.100.75
- 用户名：root（或厂商提供的默认帐号）
或者在 PowerShell / cmd 中直接执行（前提是安装了 OpenSSH 客户端）：
bash 复制代码
```
ssh root@192.168.100.75
```

登录成功后，提示符类似：

text 复制代码

[root@RV1126_RV1109:~]#

此时即可像操作本地 Linux 一样在开发板上执行命令。

常见问题: 在 Windows 上「任何 192.168.0.0/16 都能 ping 通」

现象：

ping 192.168.100.75、ping 192.168.100.124、ping 192.168.1.123 等都能得到回复。

根本原因：

当本机没有配置 192.168.0.0/16 网段的本地地址时，所有发往该网段的数据会按默认路由从 Wi-Fi 网卡发到路由器或上游网络。

回复实际上来自路由器或其他网络设备，而不是开发板。

解决办法：

按本笔记第五部分的步骤，为连接开发板的以太网口配置 静态地址 192.168.100.74/24。

调试时暂时关闭 Wi-Fi，保证 192.168.100.* 的路由只走 PC ↔ 开发板这条链路。

小结

本次 RV1126 开发板调试过程，从「只能看到 MASKROM」到「成功通过光纤链路 SSH 登录」，完整经历了：

理解并区分 MASKROM / LOADER / ADB 设备状态；
使用瑞芯微开发工具正确刷入 Loader 与固件；
通过 USB adb shell 首次进入系统，确认系统正常运行；
在板子与 PC 上分别配置以太网 IP，使其处于同一个网段；
最终通过 ssh root@192.168.100.75 实现稳定的远程登录。

今后在遇到类似问题时，可以沿着以下思路快速自查：

是否在 ADB 设备状态 → 是否能 adb shell 进系统 → 板子 IP 是否配置正确 → PC 网卡 IP 与路由是否合理 → SSH 服务是否正常监听。