飞凌嵌入式RK3568开发板通过TFTP烧写文件系统操作指南

2025-12-03 来源：elecfans

本测试基于搭载RK3568的OK3568-C开发板，在Linux 4.19.206标准开发环境下进行。该平台网络基础稳定，满足TP协议传输要求。测试中，TFTP服务器部署于Ubuntu系统，并通过桥接模式与开发板连接（利用开发板双网口硬件优势以降低传输延迟），服务器地址设置为172.16.0.177。测试前，需将系统镜像（boot.img、rootfs.img）置于TFTP服务器目录，并确保开发板与服务器网络互通，此为后续烧写操作的必要条件。

1、Uboot配置环境变量，确保网络互通

RK3568开发板的 Uboot 环境配置简洁直观，配合板载的 Debug（集成转串口芯片，无需额外转接器），可快速通过终端工具（如 SecureCRT、Xshell）进入 Uboot 命令行，完成网络参数配置。

操作提示：Type-C Debug接口默认波特率为115200bps，数据位8，停止位1，无校验，连接后重启开发板即可进入Uboot 命令行。

=> senv ethdr aa:bb:cc:dd:ee:ff # 设置开发板MAC地址，确保网络身份唯一 => setenv ipaddr 172.16.0.176 # 配置开发板静态IP，需与服务器在同一网段 => setenv gatewayip 172.16.0.218 # 设置网关地址，保障跨网段（若需） => setenv netmask 255.255.0.0 # 配置子网掩码，匹配局域网网段规划 => saveenv # 保存环境变量至eMMC，避免重启后丢失 Saving Environment to ENV_BLK... Wring to mmc(0)... done # 验证网络连通性：先ng真机，再ping Ubuntu服务器 => ping 172.16.0.77 # 测试开发板与真机网络互通 @fe2a0000 Wting for PHY auto negotiation to complete. done Using ethernet@fe2a0000 device host 172.16.0.77 is alive => ping 172.16.0.177 # 关键步骤：验证与TFTP服务器连通性（若不通，检查VMware桥接模式或开发板网口接线） Using ethernet@fe2a0000 device host 172.16.0.177 is alive => setenv serverip 172.16.0.177 # 指定TFTP服务器IP，后续传输默认指向该地址 => saveenv Saving Environment to ENV_BLK... Writing to mmc(0)... done

注意：若 ping 服务器失败，需优先排查：

① VMware网络是否设为“桥接模式”；

② 开发板网口接线是否正常（推荐使用超五类及以上网线）；

③ 服务器防火墙是否关闭 TFTP （默认69端口）。

2、查询eMMC分区表，明确烧写目标

RK3568开发板提供 8/16/32/6B多规格的eMMC存储选项，本次测试采用标准Linux分区规划，通过mmc part命令可查看完整分区结构，明确boot.img（引导镜像）和rootfs.img（文件系统镜像）的目标分区

=> mmc part # 列出eMMC设备0的分区表（Partition Type: EFI） Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00004000 0x00005fff "uboot" 0x00000000 0a100000-... b7030000-... 2 0x00006000 0x00007fff "misc" 0x00000000 420c0000-... ca5e0000-... 3 0x00008000 0x00017fff "boot" 0x00000000 aa0c0000-... 81190000-... # boot.img目标分区 4 0x00018000 0x00027fff "recovery" 0x00000000 2a050000-... c4620000-... 5 0x00028000 0x00037fff "bkup" 0x00000000 aa600000-... 7b5d0000-... 6 0x00038000 0x00c37fff "rootfs" 0x00000000 12770000-... 614e0000-... # rootfs.img目标分区 7 0x00c38000 0x00c77fff "oem" 0x00000000 4a1c0000-... e52f0000-... 8 0x00c78000 0x01d59fbf "userdata" 0x00000000 3b120000-... 680f0000-...

该分区规划充分适配RK3568开发板的多系统特性：若需切换至或系统，仅需通过飞凌嵌入式提供的partition_tool.sh脚本调整分区表，无需更换硬件。

3、TFTP烧写boot.img至boot分区

利用tftpflash命令可直接将TFTP服务器中的boot.img加载至 eMMC的“boot”分区（3号分区）。RK3568处理器的高速数据处理能力可保障TFTP传输速率稳定，确保引导镜像快速烧写完成。

# tftpflash命令说明：tftpflash [加载地址] [文件名] [目标分区名] => tftpflash 0x09400000 boot.img "boot" Using ethernet@fe2a0000 device TFTP from server 172.16.0.177; our IP address is 172.16.0.176 Filename 'boot.img'. Load address: 0x9400000 Long: ################################################################# ################################################################# ......（省略中间加载过程） ############################################### 3.1 MiB/s done Bytes transferred = 23584256 (167de00 hex) ## TFTP flash boot.img to partititon 'boot' size 0x167de00 ... OK => reboot # 烧写完成后重启，验证引导分区是否正常（可选步骤，也可待rootfs烧写后统一重启）

技术亮点：

boot.img包含内核与设备树，其烧写稳定性直接影响系统启动。RK3568的eMMC支持“坏块管理”功能，配合底板的5V/12V 防护设计，可避免烧写过程中因电压波动导致的镜像损坏，适配工业场景长期运行需求。

4、TFTP烧写rootfs.img至rootfs分区

rootfs.img包含完整的文件系统（如/bin、/etc、/lib等目录），需烧写至“rootfs”分区（6号分区）。RK3568开发板的rootfs分区预留充足空间（本次测试分区大小约1.9GB），不仅可容纳基础文件系统，还能满足后续功能扩展需求——例如开发板内置1TOPS算力的NPU，若需部署轻量级AI 应用，可直接在该文件系统中集成 RKNN-Toolkit工具（支持 Caffe、、PyTorch等主流模型一键转换），无需额外调整存储架构。

=> tftpflash 0x09400000 rootfs.img "rootfs" Using ethernet@fe2a0000 device TFTP from server 172.16.0.177; our IP address is 172.16.0.176 Filename 'rootfs.img'. Load address: 0x9400000 Loading: ################################################################# ################################################################# ......（省略中间加载过程，因文件较大，加载时间稍长） ################################################################# done Bytes transferred = 1404391424 (53b55000 hex) ## TFTP flash rootfs.img to partititon 'rootfs' size 0x53b55000 ... OK => reboot # 烧写完成，重启开发板进入目标系

注意：

RK3568开发板采用“核心板+底板”分体式设计，若后续需扩展存储（如通过3.0接口添加硬盘）或联网方式（通过M.2 Key-B接口扩展4G/模组），无需重新烧写文件系统——仅需在现有系统中安装对应驱动（飞凌嵌入式资料包提供预编译驱动），大幅简化功能迭代流程。