1. 项目概述从单核到异构解锁开发板并行处理新维度在嵌入式开发领域我们常常面临一个经典难题如何在一块硬件平台上同时满足实时性要求极高的控制任务和功能复杂的应用层业务传统的单系统方案无论是实时操作系统还是通用操作系统往往难以兼顾。实时系统如FreeRTOS、RT-Thread虽然响应快、确定性高但生态和开发便利性不足通用系统如Linux、Android生态丰富、易于开发但其非实时内核和复杂的调度机制在处理毫秒甚至微秒级响应的任务时就显得力不从心。这正是“AMP”Asymmetric Multi-Processing非对称多处理架构大显身手的地方。它允许我们在一个多核处理器上同时运行两个或多个独立的操作系统每个系统独享一个或多个CPU核心彼此通过共享内存等机制进行通信。这就像在一栋大楼里划分出独立的办公区和精密实验室互不干扰又能通过内部电话协同工作。今天要深入探讨的就是基于迅为iTOP-3568这款高性能ARM开发板实现AMP双系统通常是Linux RTOS的核心第一步烧写AMP镜像。这不仅仅是把文件拷贝到板子那么简单它涉及到对处理器启动流程的深度理解、对分区表的精确规划、对引导程序的巧妙配置以及对不同系统镜像的融合打包。对于初次接触AMP的开发者来说烧写环节往往是第一个“拦路虎”镜像烧错、分区不对、系统无法启动等问题层出不穷。本文将从一个资深嵌入式工程师的视角手把手带你拆解iTOP-3568 AMP镜像烧写的完整流程。我会详细解释每一步背后的原理分享从官方文档和实际踩坑中总结出的关键技巧并提供一份可直接“抄作业”的详细操作指南。无论你是想为机器人项目构建实时控制AI视觉的双系统还是为工业网关打造高可靠的数据采集与边缘计算平台掌握AMP镜像的烧写都是打开这扇大门的钥匙。2. 核心概念与准备工作理解AMP与iTOP-3568的硬件基础在动手烧写之前我们必须先打好理论基础理解我们要做什么以及硬件平台为我们提供了什么支持。盲目操作只会导致反复失败。2.1 AMP架构深度解析为何选择它AMP并非一个具体的软件而是一种系统设计范式。在iTOP-3568这样的多核处理器通常是四核Cortex-A55上AMP意味着核心隔离例如将CPU0、CPU1分配给实时操作系统如FreeRTOS或Zephyr专门用于电机控制、传感器数据采集等实时任务。将CPU2、CPU3分配给Linux系统用于运行图形界面、网络服务、文件系统等复杂应用。内存分区通过硬件或软件方式为两个系统划分独立的物理内存区域避免相互踩踏。同时会预留一小块“共享内存”区域作为两个系统之间交换数据、发送信号的“信箱”。独立启动与运行两个系统拥有各自完全独立的镜像文件、运行上下文和中断体系。它们从硬件上电开始就沿着不同的路径初始化最终并行不悖地运行。与SMP对称多处理的区别这是最容易混淆的概念。SMP下所有CPU核心运行同一个操作系统内核共享所有内存和资源由内核统一调度任务。它强调整体性能和负载均衡但无法保证某个任务始终在指定核心运行实时性无法严格保障。AMP则是“分而治之”为特定任务分配专属资源牺牲了部分灵活性换来了极致的确定性和可靠性。选择AMP的场景你的项目需求中是否同时包含“硬实时”响应延迟必须在XX微秒内和“富生态”需要大量开源库、网络协议栈、图形界面如果是那么AMP几乎是必然选择。例如无人机飞控实时与图传/地面站通信非实时或者数控机床的运动控制实时与HMI人机界面非实时。2.2 iTOP-3568开发板硬件特性与启动流程迅为iTOP-3568核心板采用Rockchip RK3568处理器这是一颗集成了四核ARM Cortex-A55、Mali-G52 GPU和丰富外设的SoC。对于AMP支持我们需要重点关注以下几点启动ROMBootROM芯片上电后首先运行固化在内部ROM中的一小段代码。它的作用是初始化最基本的外设如SRAM、eMMC接口然后从指定的存储设备如eMMC、SD卡、SPI Flash的固定位置加载下一阶段的引导程序。这个位置通常是存储设备的起始扇区。一级引导加载程序SPL/U-Boot SPL由于BootROM空间有限它通常只加载一个非常精简的引导程序即SPL。SPL会初始化更复杂的外设如DDR内存然后从存储设备上加载完整的主引导程序U-Boot。U-Boot功能强大的开源引导程序。在AMP场景下U-Boot的角色至关重要。它需要读取分区表了解eMMC上各个分区如boot, rootfs, rtos的布局。加载多个内核根据配置分别加载Linux内核镜像Image和RTOS镜像到内存的不同地址。传递参数通过设备树Device Tree或ATAGs将内存布局、核心分配等信息告诉即将启动的内核。启动核心最后通过ARM的SMCSecure Monitor Call或PSCIPower State Coordination Interface命令唤醒并跳转到指定核心的入口地址从而启动RTOS。Linux内核则通常由CPU0启动。多核启动机制PSCIRK3568使用标准的ARM PSCI协议来管理多核的电源状态如开机、关机、挂起。U-Boot正是通过PSCI接口在适当的时机让处于“等待”状态的CPU核心例如CPU1开始执行RTOS的代码。准备工作清单硬件iTOP-3568开发板套件含核心板与底板、12V电源适配器、Type-C数据线用于ADB调试和Fastboot、网线、MicroSD卡可选用于备用启动。软件宿主机推荐使用Ubuntu 20.04/22.04 LTS系统因为大多数嵌入式工具链和脚本对其兼容性最好。工具adb和fastboot工具sudo apt install android-tools-adb android-tools-fastboot、RK开发工具rkdeveloptool用于Rockchip特有的Loader模式烧写。镜像文件从迅为官方获取或自己编译的AMP系统镜像包。通常包含MiniLoaderAll.bin(Rockchip的二级Loader)uboot.img(U-Boot镜像)boot.img(Linux内核设备树initramfs)rootfs.img(Linux根文件系统如ext4格式)rtos.bin(RTOS镜像需明确其加载地址如0x08000000)parameter.txt(分区表文件这是AMP烧写的关键)注意务必确认你获取的镜像包与你的硬件版本尤其是DDR型号匹配。错误的Loader或U-Boot可能导致板子无法启动甚至需要短接进入MaskROM模式才能救砖。3. 分区表设计AMP系统的磁盘规划蓝图如果说烧写镜像是在“盖房子”那么分区表就是“建筑图纸”。在AMP系统中我们需要在单一的存储设备通常是eMMC上为两个操作系统以及引导程序划分出各自的地盘。parameter.txt文件就是这份图纸。3.1 解读标准分区表一个典型的单Linux系统parameter.txt可能如下所示FIRMWARE_VER: 1.0 MACHINE_MODEL: RK3568 MACHINE_ID: 007 MANUFACTURER: RK3568 MAGIC: 0x5041524B ATAG: 0x00200800 MACHINE: 3568 CHECK_MASK: 0x80 PWR_HLD: 0,0,A,0,1 TYPE: GPT CMDLINE: mtdpartsrk29xxnand:0x000020000x00004000(uboot),0x000020000x00006000(trust),0x000100000x00008000(boot),-0x00018000(rootfs:grow) uuid:rootfs614e0000-0000-4b53-8000-1d28000054a9关键参数是CMDLINE中的mtdparts对于eMMC也可能是blkdevparts。它定义了分区布局0x000100000x00008000(boot)表示从偏移0x8000单位通常是扇区512字节开始大小为0x10000个扇区的分区命名为boot。-0x00018000(rootfs:grow)表示从偏移0x18000开始到磁盘末尾的动态扩展分区命名为rootfs。3.2 为AMP定制分区表为了容纳RTOS我们需要新增一个分区。假设RTOS镜像大小为4MB0x2000个扇区我们计划将其放在boot分区之后rootfs分区之前。修改后的CMDLINE可能如下CMDLINE: mtdpartsrk29xxnand:0x000020000x00004000(uboot),0x000020000x00006000(trust),0x000100000x00008000(boot),0x000020000x00018000(rtos),-0x0001A000(rootfs:grow)解读uboot和trust分区是Rockchip平台特有的存放引导程序和安全相关代码一般不变。boot分区存放Linux内核boot.img。新增rtos分区从偏移0x18000开始大小0x2000扇区4MB用于存放rtos.bin。rootfs分区起始偏移相应后移到0x1A000存放Linux根文件系统。计算与规划要点对齐分区起始偏移和大小最好按4MB0x2000扇区对齐这符合eMMC擦除块大小能提升读写性能。预留空间RTOS分区大小一定要比你实际编译出的rtos.bin文件大一些预留20%-50%的空间用于后续功能扩展和日志存储。共享内存AMP双系统需要通过共享内存通信。这段内存通常不在eMMC分区中而是在DDR内存中预留。需要在U-Boot和两个系统的设备树或链接脚本中约定一段物理内存地址例如0x30000000开始的大小为1MB的区域不被任何一方使用并映射到各自的地址空间。这部分配置在烧写阶段不涉及但必须在系统编译前规划好。实操心得修改parameter.txt后一个非常有效的验证方法是使用rkdeveloptool或adb shell中的cat /proc/mtd对于MTD设备或lsblk命令在烧写后查看实际分区情况是否与预期一致。我曾因为一个扇区计算错误导致rootfs分区起始位置错误系统根本无法挂载根文件系统。4. 烧写工具与模式选择找到正确的“写入笔”有了镜像和分区表我们需要选择合适的工具将其“写入”eMMC。iTOP-3568提供了多种烧写模式对应不同的工具和场景。4.1 烧写模式详解Loader模式升级模式进入方式板子先不上电按住主板上的“升级键”Recovery或Volume-键不放再插入Type-C数据线连接电脑最后上电。电脑设备管理器会识别到一个“Rockusb Device”。原理此时板子运行在BootROM阶段等待通过USB接收Loader程序。我们通过rkdeveloptool工具先将MiniLoaderAll.bin下载到板载SRAM并运行然后这个Loader会接管USB通信接受后续的镜像烧写命令。优点最底层、最可靠的烧写方式即使eMMC完全空白或U-Boot损坏也能使用。是首次烧写或救砖的首选。工具rkdeveloptool(Rockchip官方命令行工具)。Fastboot模式进入方式系统启动到U-Boot阶段时在串口终端快速按下键盘打断U-Boot自动启动进入U-Boot命令行输入fastboot usb 0命令。原理U-Boot内置了Fastboot协议服务端通过USB与PC端的fastboot工具通信执行分区擦除、烧写等命令。优点灵活可以单独更新某个分区如只更新boot或rtos无需重写整个磁盘。适合增量开发和调试。工具PC端的fastboot命令。ADB推送更新前提Linux系统已经正常启动并且ADB调试功能已开启。方式通过adb push将更新文件推到开发板然后在开发板上通过dd命令或专门的更新脚本写入对应分区。优点无需连接串口通过网络或USB进行方便。缺点需要系统已运行无法更新U-Boot等底层组件风险较高如果dd命令参数写错可能破坏分区表。模式选择策略全新板子或彻底重刷毫不犹豫使用Loader模式。仅更新Linux内核或RTOS镜像使用Fastboot模式快速高效。已进入系统进行小幅度文件替换使用ADB推送。4.2 工具安装与配置以Ubuntu为例安装rkdeveloptool# 1. 安装依赖 sudo apt update sudo apt install -y libudev-dev libusb-1.0-0-dev dh-autoreconf pkg-config # 2. 克隆源码建议使用稳定分支 git clone https://github.com/rockchip-linux/rkdeveloptool.git cd rkdeveloptool # 3. 编译安装 autoreconf -i ./configure make sudo make install # 4. 配置USB规则让普通用户也能访问Rockusb设备 echo SUBSYSTEMusb, ATTR{idVendor}2207, ATTR{idProduct}350a, MODE0666 | sudo tee /etc/udev/rules.d/51-rockusb.rules sudo udevadm control --reload-rules sudo udevadm trigger安装完成后连接板子进入Loader模式执行rkdeveloptool ld应该能看到设备列表。安装adb和fastbootsudo apt install android-tools-adb android-tools-fastboot5. 完整烧写流程实操以Loader模式为例现在我们进入最核心的实操环节。假设我们已经准备好了所有镜像文件并修改好了parameter.txt。5.1 步骤详解第一步进入Loader模式并连接确保开发板断电。用Type-C数据线连接开发板的OTG口和电脑的USB口。按住开发板上的“升级键”不放通常标有“REC”或旁边有音量减符号。给开发板上电。等待2-3秒后松开按键。在电脑终端执行rkdeveloptool ld如果看到类似DevNo1 Vid0x2207,Pid0x350a,LocationID106的输出说明设备已正确识别。第二步擦除并重新分区这是关键一步将按照新的parameter.txt对eMMC进行布局。# 下载并运行Loader rkdeveloptool db /path/to/your/MiniLoaderAll.bin # 擦除整个eMMC的旧数据谨慎 rkdeveloptool ef /path/to/your/parameter.txt # 注意ef命令会擦除所有数据包括原有的U-Boot。确保后续会立即烧写新的U-Boot。 # 另一种更安全的方式是只重新分区如果已有Loader在运行 # rkdeveloptool ppt /path/to/your/parameter.txt重要警告ef命令是“擦除闪存”会清空整个eMMC。如果只执行了db和ef但没有成功烧写后续的U-Boot板子将变“砖”下次上电无法启动任何程序必须再次进入Loader模式才能救回。所以务必确保所有镜像文件准备就绪且命令序列连续执行。第三步烧写各个镜像到对应分区# 1. 烧写U-Boot rkdeveloptool wl 0x0 /path/to/your/uboot.img # 这里的0x0是分区起始偏移单位字节对于uboot分区通常就是0。具体值需参考parameter.txt中uboot分区的起始扇区号乘以512。 # 2. 烧写Trust如果有 # rkdeveloptool wl 0x4000 /path/to/your/trust.img # 3. 烧写Linux内核boot分区 # 首先需要知道boot分区的起始地址。假设parameter.txt中boot分区是 0x000100000x00008000 # 起始字节地址 0x8000 * 512 0x1000000 (16MB) rkdeveloptool wl 0x1000000 /path/to/your/boot.img # 4. 烧写RTOS镜像rtos分区 # 假设rtos分区是 0x000020000x00018000 # 起始字节地址 0x18000 * 512 0x3000000 (48MB) rkdeveloptool wl 0x3000000 /path/to/your/rtos.bin # 5. 烧写Linux根文件系统rootfs分区 # 假设rootfs分区起始于 0x1A000 # 起始字节地址 0x1A000 * 512 0x3400000 (52MB) # 注意rootfs.img通常很大烧写时间较长 rkdeveloptool wl 0x3400000 /path/to/your/rootfs.img地址计算技巧可以写一个简单的Python或Shell脚本来根据parameter.txt自动计算地址避免手动计算错误。例如解析mtdparts字符串提取偏移和大小。第四步重启设备rkdeveloptool rd执行此命令后开发板会重启。此时U-Boot应该会根据其内部的配置去加载boot.img和rtos.bin并启动双系统。5.2 Fastboot模式增量更新示例假设我们只修改了RTOS代码生成了新的rtos.bin可以不用全盘擦写。进入Fastboot模式串口连接开发板上电。在U-Boot启动倒计时时按任意键打断。在U-Boot命令行输入fastboot usb 0。串口会显示Waiting for Fastboot command...。在PC端操作# 查看当前分区表确认rtos分区名 fastboot devices # 确认设备连接 fastboot getvar all # 可以查看分区信息但Rockchip平台可能不标准 # 假设我们知道rtos分区在eMMC上的块设备名是mmcblk0p4但Fastboot通常使用在U-Boot中定义的别名。 # 更常见的做法是U-Boot的Fastboot支持通过分区名来操作。如果U-Boot配置了rtos分区别名则 fastboot flash rtos /path/to/new/rtos.bin # 如果不知道别名最保险的方法是先通过Loader模式查看parameter.txt计算出rtos分区在eMMC上的绝对扇区地址 # 然后使用dd命令在Linux下更新前提是Linux已启动。但这不是Fastboot的标准用法。 # 对于AMP更推荐在U-Boot源码中明确定义好RTOS分区并为其创建Fastboot别名这样最方便。6. 启动配置与验证让双系统跑起来烧写完成只是第一步确保两个系统能按预期启动才是成功的关键。这主要依赖于U-Boot的配置。6.1 U-Boot环境变量配置U-Boot启动时会读取环境变量来决定如何启动。对于AMP我们需要配置的关键变量可能包括# 定义RTOS镜像在eMMC上的位置需与parameter.txt中的rtos分区地址对应 rtos_addr_r0x08000000 # RTOS加载到DDR中的地址 rtos_img_sector0x18000 # RTOS镜像在eMMC中的起始扇区来自parameter.txt # 定义Linux内核启动参数 bootargsconsolettyFIQ0,1500000 earlyconuart8250,mmio32,0xfe660000 root/dev/mmcblk0p5 rootwait ro # 注意root/dev/mmcblk0p5需要对应rootfs分区的实际编号可以通过ls -l /dev/disk/by-partlabel/在Linux系统中查看。 # 定义启动命令序列 bootcmdmmc dev 0; \ ext4load mmc 0:3 ${kernel_addr_r} /boot/Image; \ # 从boot分区加载内核 ext4load mmc 0:3 ${fdt_addr_r} /boot/dtbs/rockchip/rk3568-itop-3568.dtb; \ # 加载设备树 mmc read ${rtos_addr_r} ${rtos_img_sector} 0x2000; \ # 从rtos分区读取RTOS镜像到内存 (0x2000是扇区数需根据镜像大小调整) booti ${kernel_addr_r} - ${fdt_addr_r}; \ # 启动Linux内核 # 注意RTOS的启动通常不在bootcmd中而是由Linux内核启动后或通过U-Boot的特定命令如cpu start在另一个核心启动。更常见的AMP启动流程U-Boot加载Linux内核和设备树到内存并启动Linux在CPU0上。在Linux的设备树中为RTOS预留好内存区域reserved-memory节点并定义好远程处理器remoteproc节点。Linux启动后通过remoteproc框架将rtos.bin固件加载到预留内存并启动指定的CPU核心如CPU1运行RTOS。因此U-Boot的bootcmd可能只需要负责启动Linux。RTOS的加载和启动由Linux端的用户空间程序如rproc控制脚本来完成。这种方式更灵活可以在Linux运行时动态加载/重载RTOS固件。6.2 系统启动验证串口观察连接调试串口通常是UART2查看启动日志。你应该能看到U-Boot的启动信息。Linux内核的解压和启动信息。Linux用户空间初始化的信息直到出现登录提示符。关键在Linux启动日志中搜索remoteproc、rproc、CPU1等关键词看是否有RTOS固件加载和核心启动成功的消息。在Linux中验证# 登录Linux系统后 # 1. 检查CPU状态CPU1应该处于运行状态而非idle cat /proc/cpuinfo # 2. 检查remoteproc状态如果使用该框架 ls /sys/class/remoteproc/ # 应该能看到一个rproc设备例如remoteproc0 cat /sys/class/remoteproc/remoteproc0/state # 查看状态可能是running # 3. 检查共享内存 # 如果共享内存被映射为字符设备或出现在/proc/iomem中可以检查 cat /proc/iomem | grep -i sharedRTOS侧验证RTOS通常也会有调试输出通过另一个串口如果RTOS配置了或者通过共享内存中的日志环缓冲区供Linux端读取查看。你需要根据RTOS的具体实现来确认它是否已成功运行。7. 常见问题与深度排查指南烧写AMP系统过程中你会遇到各种问题。这里汇总了典型问题及其排查思路。7.1 烧写阶段问题问题1rkdeveloptool db命令执行后无反应或报错“Download Boot Fail”。可能原因1MiniLoaderAll.bin文件损坏或与硬件不匹配。解决重新从可靠来源获取对应你板载DDR型号的Loader文件。可能原因2USB连接不稳定或驱动问题。解决换一条高质量的USB数据线尝试电脑不同的USB端口重新插拔并严格按照步骤进入Loader模式。可能原因3板子已处于某种异常状态。解决尝试让板子完全断电包括拔掉Type-C线静置10秒后再重试。有时需要短接eMMC的CLK或DATA引脚与地线进入MaskROM模式具体短接点需查核心板手册这是最底层的恢复模式。问题2烧写成功但板子重启后无任何输出串口无信息。可能原因1U-Boot镜像错误或损坏。解决确认烧写的uboot.img是否正确。用rkdeveloptool rl 0x0 0x200000 uboot_backup.img命令读回刚烧写的U-Boot与原始文件做二进制比较(cmp)。可能原因2parameter.txt分区表错误导致U-Boot无法找到有效的引导信息。解决仔细检查parameter.txt中分区布局特别是起始偏移确保没有重叠且boot分区位置正确。可以尝试使用官方提供的标准单系统parameter.txt先测试U-Boot能否启动。可能原因3DDR初始化失败。这通常与Loader和U-Boot的配置有关属于底层硬件适配问题个人用户较难解决需核对板子与镜像的兼容性。7.2 启动阶段问题问题3Linux内核能启动但挂载根文件系统失败。日志提示VFS: Unable to mount root fs on unknown-block(0,0)或/dev/mmcblk0p5 does not exist。排查检查分区号bootargs中的root/dev/mmcblk0pX的X是否正确。在U-Boot命令行下可以尝试mmc part命令列出eMMC所有分区看rootfs分区对应的编号是多少。检查文件系统确认rootfs.img是否被正确烧写。可以尝试在U-Boot下用ext4ls mmc 0:X /命令X是分区号看看能否列出根目录文件。检查分区表一致性确保Linux内核编译时使用的设备树中的分区信息如果有与parameter.txt一致。问题4Linux正常启动但RTOS无法启动。排查检查RTOS镜像加载首先确认rtos.bin是否被正确烧写到指定分区。在Linux中可以用dd if/dev/mmcblk0p4 of/tmp/rtos_dump.bin bs512 count$((4*1024*1024/512))假设rtos是p4将分区内容dump出来用file命令或与原始rtos.bin比较。检查预留内存这是最常见的问题。确保在Linux设备树中为RTOS预留的内存区域reserved-memory节点的起始地址和大小与RTOS镜像链接脚本中定义的运行地址完全一致且这段内存没有被Linux其他驱动占用。可以通过cat /proc/iomem查看内存分配情况。检查remoteproc驱动与固件确认内核配置已启用CONFIG_REMOTEPROC和对应的平台驱动如CONFIG_REMOTEPROC_RK3568。检查/lib/firmware/目录下是否有正确的RTOS固件文件例如rk3568_rtos.bin并且用户空间程序如rproc控制脚本是否正确加载了它。查看内核日志dmesg | grep -i rproc获取详细错误信息。检查核心启动确认PSCI驱动工作正常。在U-Boot或Linux中查看/sys/devices/system/cpu/下的CPU核心是否在线。7.3 调试技巧与高级工具U-Boot命令行在启动倒计时时打断进入U-Boot命令行这是强大的调试工具。mmc info/mmc part查看存储设备信息和分区。fatls mmc 0:1/ext4ls mmc 0:3列出FAT/EXT4分区文件验证镜像是否存在。load/mmc read手动加载文件到内存并用go命令跳转执行可以用于单独测试RTOS镜像是否能运行。printenv查看和修改环境变量。Linux下的调试dmesg查看内核环缓冲区日志所有内核和驱动相关的信息都在这里。remoteproc文件系统/sys/class/remoteproc/下的文件可以用于控制固件的加载、启动、停止并查看状态和日志。devmem工具直接读写物理内存地址可用于检查和修改共享内存区域的内容是调试双系统通信的利器需谨慎使用。烧写AMP镜像是一个系统工程涉及硬件、引导程序、内核、文件系统多个层面。耐心、细致的排查和对于启动流程的清晰理解是解决问题的关键。当你第一次看到两个系统的日志同时从不同的串口输出或者在一个系统中通过共享内存成功控制另一个系统的任务时那种成就感会让你觉得所有的折腾都是值得的。这不仅仅是烧写一个镜像更是打开了一扇通往异构计算和实时系统设计的大门。