企业官网建设流程全解析

1. 先摸清SDK的底细：RV1126B移植前要理清的几个层次

拿到一块RV1126B的板子，第一件事不是急着编译，而是先搞清楚SDK里哪些东西是需要你动的，哪些是芯片原厂已经帮你兜底的。RV1126B是瑞芯微面向IPC、智能摄像头这类视觉场景的芯片，集成了2T算力的NPU，自带ISP和视频编解码单元，整体定位就是一颗专门干视觉的SoC。它跑的是Linux，SDK是基于Buildroot那一套来组织的，从Loader到内核再到根文件系统，全部打在一个工程里。

我第一次接触这颗芯片的时候，最大的感受是：SDK里东西很全，但正因为全，反而不知道该从哪里下手。后来我把整个启动链路拆开看，才慢慢理清楚移植的本质工作就三件事：让DDR跑稳、让外设认到、让sensor出图。USB调试虽然排在标题最后，但往往是你前期排查问题的主要通道，所以我会把它和系统启动、烧录放在一起讲。

先说说SDK的目录结构概念。Rockchip的SDK一般包含这几个核心部分：

• u-boot/：负责早期初始化、DDR初始化、加载内核
• kernel/：Linux内核，包含所有外设驱动
• buildroot/：根文件系统构建系统，生成rootfs
• device/rockchip/：各板级的配置文件、DTS设备树、BoardConfig
• rockdev/：编译产物输出目录
• rkbin/：瑞芯微的闭源bin集合，包含ddr初始化代码、miniloader、ATF等

这里我需要重点提醒一点：DDR初始化的代码并不在u-boot/源码里，而是在rkbin/里的闭源bin文件。Rockchip把DDR这一块做成了参数化的形式，你拿到的DDR初始化镜像（通常叫ddrbin）是根据你的DDR颗粒参数生成的，源码不可见，你只需要通过官方工具配置参数。

所以"移植"这件事，其实可以分为几个层次：

1. Loader层：idbloader（包含DDR init和miniloader），这一层决定你的DDR能不能工作
2. U-Boot层：决定存储、网络、USB这些能不能在启动早期用起来
3. Kernel层：决定最终系统里外设能不能工作，sensor、USB、网口都在这层
4. Buildroot/根文件系统层：决定你调试手段全不全，adb、串口工具、v4l2工具都靠它

我刚拿到板子时犯过一个典型的错误：拿到SDK就全量编译，然后烧进去发现起不来，串口log卡在DDR初始化，根本不知道是DDR参数问题还是硬件焊接问题。后来养成的习惯是：移植前先把硬件原理图从头到尾过一遍，特别是DDR wiring、电源时序、USB的DP/DM走线、sensor的MCLK和复位引脚下到了哪个GPIO。这些信息会在你后面的配置中反复用到。

配套的开发工具也要先准备齐全。Windows下用RKDevTool烧录，Linux下用upgrade_tool；DDR参数配置用瑞芯微的DDR Parameter工具（有的版本叫DDR工具，在SDK的tools目录里能找到，或者找FAE要）；串口调试用minicom或PuTTY，波特率一般是1500000。这些都是老熟人，但每一样都可能在某个环节给你使绊子，后面我会逐个提到。

2. DDR配置三板斧：1GB DDR3选型、初始化参数、内存跑稳

2.1 RV1126B到底需要什么样的DDR3颗粒

热搜里有个问题问得很实在："rv1126b可用的ddr3内存1gb的有哪些"。这个问题背后其实是很多硬件工程师刚接触RV1126B时的共同困惑——这颗芯片的DDR控制器对颗粒有什么要求，怎么搭出1GB容量。

RV1126B的DDR控制器支持DDR3、DDR3L、DDR4、LPDDR3、LPDDR4这些类型。做消费级IPC产品，成本敏感，DDR3L是当下的主流选择，因为颗粒成熟、供货稳定、价格也友好。单颗DDR3的位宽一般是16bit，容量有256Mb、512Mb、1Gb甚至2Gb的颗粒，但要注意这里说的"容量"是以bit为单位的内部存储密度，对应到我们拿到的一颗内存颗粒，常见的规格是512MB x16bit这种写法，意思是一颗512MB、数据总线16bit。

RV1126B的DDR总线和大多数瑞芯微SoC一样，需要32bit数据总线才能发挥完整带宽。所以1GB的标准方案就是2颗512MB x16的DDR3L颗粒，拼出32bit总线、总容量1GB。当然也有4颗256MB x16的搭配，但占板面积大、成本也没优势，除非你手头有存量料，否则不推荐。

我整理了几个在RV1126B板子上比较常见的1GB DDR3方案，都是经过实际项目验证过的：

选型的时候有几个坑要提前避开。第一，DDR3和DDR3L电压不同，DDR3是1.5V，DDR3L是1.35V，如果原理图上DDR供电按照1.35V设计，你千万别焊一颗DDR3上去，工作不稳定是小事，长期下来还会影响颗粒寿命。第二，注意封装版本，DDR3常用的78-ball BGA，不同厂家引脚定义基本兼容，但要确认你板子上的焊盘和物料封装对得上。第三，尽量选瑞芯微DDR工具下拉列表里已有的型号，如果没有，你需要手动输入全套时序参数，那才是真正的痛苦起点。

2.2 DDR初始化参数在哪里配置、怎么填

瑞芯微平台的DDR初始化流程是这样的：芯片上电后，固化在芯片内部的ROM先跑起来，然后加载idbloader开头的DDR初始化bin，这段代码负责把DDR控制器的寄存器按照你选的颗粒参数配置好，然后才把U-Boot主程序加载到DDR里运行。所以DDR跑不跑得起来，跟你u-boot源码改了多少没关系，关键在DDR参数工具生成的那个bin文件。

具体操作流程大致如下：

1. 打开瑞芯微DDR Parameter工具，选择芯片型号为RV1126B
2. 在DDR类型里选择DDR3L
3. 设定目标频率，比如DDR3-1600（频率就是800MHz，因为是双倍速率）
4. 填入颗粒厂商、密度（512M x16）、位宽、bank数、row/col地址位数等参数
5. 有些版本的工具有"自动检测"功能，连接板子后可以直接读出非法DDR信息，但不建议第一次就依赖它，先把参数手工填对
6. 工具会生成一个ddrbin_param.bin之类的文件，把它替换到SDK对应位置（一般在rkbin或u-boot的配置目录下）

然后重新编译loader，烧录进去，看串口log。跑通之后你会在log里看到类似这样的信息：

DDR Version 1.16 20230315 In channel 0 DDR3-160M 10-10-10-28 Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB

这行log信息量很大：它告诉你内存跑在DDR3-1600，总线32bit，列地址10位、行地址15位、单CS，最终识别容量1024MB。如果这里显示的Size不对，或者直接卡死在DDR版本号之后不动，基本可以判定是DDR参数和实际颗粒不匹配。

还有一点，瑞芯微的DDR工具通常会让你填"频率表"，也就是把从低到高的几个频率档都填进去。这是因为系统启动初期可能用低频跑，再逐步提频。建议至少配置三档：400MHz、800MHz、最高频率（比如1866）。如果你只填了最高档，有些不成熟的板子在DDR训练阶段反而容易失败，配一个低频兜底档能让启动更稳。

2.3 U-Boot与内核DTS里的内存衔接

DDR初始化bin跑通之后，还有一个容易漏掉的环节：U-Boot和内核的设备树里，内存信息也得对上。虽然DDR控制器自己会检测容量，但U-Boot和内核在某些场景下还会读取设备树里的memory节点来做内存布局，比如给内核传参、预留CMA内存等。

U-Boot的dts里一般有类似这样的节点：

memory@1000000 { device_type = "memory"; reg = <0x0 0x01000000 0x0 0x40000000>; };

这里的reg第二段0x40000000就是1GB大小，如果DDR实际是512MB，这里要改成0x20000000。内核的dts里同样要检查，Rockchip平台通常在/device/rockchip/rv1126b/这个目录下找到你对应板型的dts文件，里面可能有memory-region这样的节点，用来划分cma、iommu保留内存等。这些区域如果超过实际内存大小，内核启动时会报错，表现就是蓝牙、摄像头、GPU这类需要申请连续内存的模块起不来。

我见过一个案例，DDR实际只有512MB，但内核dts里cma预留了0x20000000（512MB），导致系统启动后内存所剩无几，rknpu驱动加载直接失败。排查了一整天才发现是dts里的内存预留参数没跟着实际DDR容量改。

所以我的建议是，DDR参数配置完成后，顺手把U-Boot dts和内核dts里的内存相关节点全部过一遍，确认和实际容量一致。这一条写进你的移植检查清单，可以省掉后面很多莫名其妙的"随机死机"和"驱动加载失败"问题。

3. 从DDR到系统启动：U-Boot与内核移植的衔接细节

DDR跑通只是第一步，紧接着就是U-Boot能不能找到它想找的东西：存储、网络、显示，还有最关键的——能不能把内核镜像加载起来。RV1126B的启动介质一般用eMMC或SPI NOR Flash。U-Boot移植的重点是确认存储控制器时序、分区表和env参数，这些配置分散在U-Boot的dts和defconfig里。

编译U-Boot之前，先确认板级配置。在SDK的U-Boot目录下，执行make rv1126b_defconfig之前，你需要确认这个defconfig对应的是你板子上的DDR、存储、外设配置。Rockchip的U-Boot中，CONFIG_DEFAULT_FDT_FILE和CONFIG_DEFAULT_DEVICE_TREE这两个配置项决定了最终打包进U-Boot的DTS是哪一份。如果你的板子是基于公板改的，最省事的做法是拷贝一份公板dts，改名后放到arch/arm/dts/下，再在defconfig里指定它。

U-Boot阶段如果DDR参数没问题，串口log会往下走到这里：

Net: eth0: ethernet@ffc90000 Hit any key to stop autoboot: 0

看到Hit any key to stop autoboot，说明U-Boot主体已经正常工作。如果卡在这一步之前，比如MMC: no card present或者No ethernet found，那是U-Boot dts里的外设节点没配对，优先检查eMMC的时钟、复位、电源引脚配置，以及SDIO/MMC控制器的reg地址是不是和硬件对得上。

内核部分的移植，我习惯按这个顺序走：

1. 先编译一个最小配置，只保证串口、内存、SD/MMC、USB host能用
2. 确认内核启动到根文件系统挂载成功
3. 再逐步添加sensor、WiFi、音频等外设驱动
4. 每加一个外设，单独测试，别一次全开

内核dts里最容易出问题的几个点：pinctrl（引脚功能复用）、regulator（供电节点）、clock（时钟树）。RV1126B的pinctrl配置规则和大部分Rockchip芯片一样，在dts里通过pinctrl-0引用来描述。比如你要用一个GPIO控制sensor的reset脚，需要确认这个GPIO有没有被其他外设复用，否则sensor永远拉不起来。

启动到内核后，建议先用dmesg | grep -i err扫一遍，把报错先处理掉。很多报错不影响启动，但积累到一定程度会导致某些功能静默失效。比如rockchip-i2c报timeout waiting for bus，可能意味着某条I2C总线上挂了一个地址冲突的设备，或者总线被其他驱动占用了。这些都要在这个阶段解决，别拖到后面做sensor调试时再回头查。

另外，U-Boot的env参数里，bootargs的mem=参数千万不要乱加。有些工程师为了给内核传内存大小，在bootargs里写死mem=512M，后面如果换了大容量DDR，系统只会用到512M，这个坑很隐蔽，排查起来极其浪费感情。正常Rockchip平台的内核是从DTS的memory节点自动获取内存大小的，不需要也不建议在bootargs里手动限制。

4. USB调试链路搭建：烧录模式、ADB、驱动配置与排查

USB调试这条链路，是我在RV1126B移植过程中花时间最多、也最值得拿出来单独讲的一个环节。为什么？因为前期板子没起来的时候，唯一能和你交互的就是串口；但串口速率低、不能传文件，调试效率很低。而一旦USB通了，你可以用ADB传文件、跑命令、抓log、看dmesg，效率完全不是一个量级。

4.1 烧录模式：Loader和Maskrom的区别

先讲烧录模式，因为你第一次拿到板子，最可能的操作就是烧录SDK默认镜像。RV1126B有几种USB相关的运行模式：

• Normal模式：正常启动，连接USB后是一个ADB设备
• Loader模式（预下载模式）：按住板上的RECOVERY/LOADER按键后上电，芯片只加载DDR和miniloader，不启动内核，等待烧录工具下发镜像
• Maskrom模式：连Loader都没能起来（比如DDR参数错误），芯片进入ROM引导状态，此时可以用工具强制烧录

板子上Loader模式的进入方法一般是：先按住RECOVERY键不放，再上电，持续3秒左右松开。在Windows设备管理器里会看到一个USB设备"Rockchip USB"，这就是进入Loader模式了。如果DDR初始化代码本身有问题，连Loader模式都进不了，芯片会掉到Maskrom模式，这时候设备管理器里会显示"Rockchip Maskrom"。别慌，这不是板子坏了，只是DDR初始化bin还没调好，Maskrom模式依然可以用工具烧录——只是烧录动作会先擦除原来错误的loader，所以这种方式也被叫做"救砖"。

Linux环境下用upgrade_tool操作，先列设备：

upgrade_tool L

然后整体烧录：

upgrade_tool uf update.img

如果是单独的loader镜像，用upgrade_tool ld xxx.bin。Windows下RKDevTool的操作逻辑一样，界面上分"Loader模式"和"Maskrom模式"两个烧录分区。

这里有一个我踩过的坑：板子第一次连接电脑无法识别为Rockchip USB设备，用的是一根只能充电不能传数据的USB线。这个低级错误导致我一度以为是板子USB PHY供电有问题，浪费了大半天。换了一根正经的数据线之后秒识别。USB调试出问题，先换线再排查驱动，这是第一原则。

4.2 系统起来之后，如果让ADB工作起来

系统正常启动之后，USB OTG口默认应该枚举成一个ADB设备。RV1126B的USB OTG控制器是DWC2（具体看SDK版本），内核里对应的驱动节点在dts里长这样：

&usbdrd_dwc3 { status = "okay"; dr_mode = "otg"; extcon = <&u2phy0>; }; &usb_host0_ehci { status = "okay"; };

如果你的板子USB口没反应，按这个顺序排查：

1. 看内核log：dmesg | grep -i dwc3，确认控制器有没有probe成功
2. 看PHY：dmesg | grep -i phy，U2PHY有没有正常工作，供电和时钟是否配好
3. 看gadget：ls /sys/kernel/config/usb_gadget/，如果目录存在，说明configfs支持已开启
4. 看adbd进程：ps aux | grep adbd，确认adbd有没有跑起来

Rockchip的Linux SDK默认会通过init脚本把usb_gadget配置好，核心逻辑是挂载configfs，创建gadget目录，然后设置VID/PID、创建ADB function并绑定到配置里。如果系统默认没有启动adbd，你可以手动配置：

mount -t configfs none /sys/kernel/config mkdir /sys/kernel/config/usb_gadget/rk cd /sys/kernel/config/usb_gadget/rk echo 0x2207 > idVendor echo 0x0010 > idProduct mkdir functions/ffs.adb mkdir configs/c.1 ln -s functions/ffs.adb configs/c.1/

然后启动adbd：

/usr/bin/adbd &

连接电脑后执行adb devices，如果有xxxxxxx device输出，说明ADB链路已通。如果显示unauthorized，那是电脑端adb的公钥指纹没确认，在adb对话框里允许即可。如果是Linux开发机，还要确保udev规则里有瑞芯微的VID（0x2207），否则adb会提示no permissions，需要加一条规则：

echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="2207", MODE="0666"' > /etc/udev/rules.d/51-rockchip.rules udevadm control --reload

4.3 USB枚举失败与不稳定问题的排查思路

最常见的USB问题有两类。第一类是插上电脑完全没反应，设备管理器里连未知设备都没有。这种基本是硬件层的问题：VBUS没供上、DP/DM差分线接反或断开、PHY的模拟供电没打开。软件上能查的有限，优先确认dts里USB PHY节点有没有status = "okay"，以及电源LDO有没有给PHY供上电。如果PHY配置正常但依然没反应，用示波器量USB D+/D-上的波形，没有波形基本上就是硬件问题。

第二类是能识别但一传数据就断，或者烧录工具写了一半报错。这种多半是信号完整性问题，USB DP/DM走线过长、地平面不连续、或者VBUS电容没焊。当然也不要排除dts里PHY的tuning参数问题，有时候减小驱动强度可以缓解不稳定，但这是治标不治本，真正原因大概率还是layout。

还有一类运行时的诡异问题：系统跑了好几个小时，ADB突然断开，然后重连此后再也不稳定。这种我倾向怀疑是USB PHY进入了低功耗模式，而驱动的电源管理策略有bug。排查方法是在内核dts里把usb控制器节点加上pm_qos限制，或者直接关闭runtime PM：

&usbdrd_dwc3 { status = "okay"; pm_qos = <5>; };

Rockchip的某些内核版本里，DWC3的runtime PM和extcon的交互确实有坑，把pm_qos设为0可以强制不休眠。这个参数视SDK版本而定，建议查一下你的SDK内核里是否有相关字段，如果没有直接改驱动代码里对应runtime_suspend的调用也可以。

5. sensor接入：让ISP真正出图

热搜里另一个高频词是"rv1126b sensor"。RV1126B干的就是视觉的活，所以sensor接入是几乎所有项目都会遇到的需求。sensor这部分涉及硬件接口、内核驱动、ISP调优三块，任何一个环节有问题，最终结果都是不出图。

5.1 选型参考：哪些sensor配RV1126B比较顺

RV1126B的ISP对各种sensor的适配性不错，常见的IPC类sensor基本都有现成的驱动。我列几个在RV1126B项目里比较常见的型号，给选型做个参考：

选sensor时要先确认你的ISP和MIPI controller支不支持这个分辨率、lane数、虚拟通道数。RV1126B的MIPI CSI一般支持2-lane或4-lane，sensor的MIPI lane数、速率要和SoC侧匹配，速率太高可能过不了信号完整性校验。

驱动方面，Rockchip SDK的kernel里已经带了不少主流sensor驱动，位置在kernel/drivers/media/i2c/下。如果你选型的sensor刚好有驱动，那就省事很多。没有的话，SDK里通常有类似型号可以改，比如GC2053改GC2063，大部分寄存器映射是兼容的，但要仔细对照datasheet。

5.2 DTS配置：从电源到MCLK，一个都不能漏

sensor在设备树里要配置的东西比想象中多。以一个典型的MIPI sensor节点为例：

&i2c2 { status = "okay"; clock-frequency = <400000>; gc2053: gc2053@37 { compatible = "galaxycore,gc2053"; reg = <0x37>; pinctrl-names = "default"; pinctrl-0 = <&gc2053_pwdn &gc2053_rst>; reset-gpios = <&gpio2 RK_PB6 GPIO_ACTIVE_LOW>; pwdn-gpios = <&gpio2 RK_PB5 GPIO_ACTIVE_HIGH>; rockchip,camera-module-index = <0>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "CMK-OT1972-6B30"; rockchip,camera-module-lens-name = "default-lens"; port { gc2053_out: endpoint { remote-endpoint = <&mipi_in_ucam0>; >media-ctl -p

你会看到类似这样的节点列表，sensor的entity、csi2的entity、isp的entity都在里面。确认sensor entity存在的下一步是设置格式，把sensor输出格式配成它支持的格式（比如UYVY 8bit、1920x1080）：

media-ctl -v -V '"gc2053 2-0037":0[fmt:UYVY8_2X8/1920x1080]' media-ctl -v -V '"mipi-csi2":0[fmt:UYVY8_2X8/1920x1080]'

然后是抓帧：

v4l2-ctl --device /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=NV12 --stream-mmap --stream-count=1 --stream-to=frame.raw

抓下来之后把frame.raw拉回电脑，用YUV查看工具看一眼。如果能看到画面，但颜色不对或者画面有彩条，那是ISP参数没调好，需要做3A校准；如果是全黑或者全绿，多半是sensor寄存器初始化序列不对或者MIPI时序没配好，优先查dmesg | grep -i mipi和dmesg | grep -i isp。

sensor的不出图问题，80%出在供电或MCLK上，10%出在I2C地址或复位时序，剩下10%才是MIPI和ISP的配置。所以排查的时候别一开始就冲着寄存器去，先用万用表和示波器量硬件，硬件没问题再查软件。这个排查顺序基本能让你少走一半弯路。

6. 移植路上值得记下来的坑位清单与排查顺序

写到这里，把我这些年在RV1126B以及类似Rockchip平台上踩过、或亲眼见过的坑集中整理一下。它们单独出现时都很好解决，但一旦叠加在一起，很容易让人怀疑人生。

关于DDR的坑：

• 选了DDR3L颗粒，但DDR参数工具里选成了DDR3，启动能起来但长时间运行偶发死机。这种问题最难查，因为不是必现的，跑压力测试跑几个小时才崩一次。排查时建议用memtester或stressapptest跑至少12小时，能过再放量。
• 频率档里只填了最高档，DDR训练偶发失败。启动log有时能过有时卡死，看起来就像硬件接触不良。实际上把低频档配回来就稳定了。
• 容量识别出来只有512MB，实际焊了1GB。原因多半是DDR参数里Bank或Row/Col地址位数填少了，控制器寻址范围不够。

关于USB的坑：

• ADB能识别但烧录不了镜像。检查USB线是否支持OTG，有些线只支持host侧供电，device模式插上会被识别成未知设备。
• Linux开发机上adb devices显示no permissions。udev规则没配好，加一条0x2207的规则即可。
• 烧录到一半报USB通信失败。优先怀疑USB走线过长导致信号劣化，试试把烧录波特率降到低速（工具的"低格"选项就是干这个的）。
• dmesg里报dwc2_hsotg_ep0: timeout但设备又能在设备管理器里看到。这种一般是gadget曲线配置有问题，重新走一遍configfs配置流程。

关于sensor的坑：

• I2C不通，但电压、MCLK都正常。检查reset/pwdn两个GPIO的active电平，很多sensor的pwdn是高电平时工作，低电平是掉电，dts里的GPIO_ACTIVE_HIGH/LOW对应关系一定要对着sensor datasheet逐字核对。
• MIPI信号已配置为2-lane，但sensor寄存器初始化里设置的是4-lane输出，导致ISP收不到有效数据。sensor自身的寄存器初始化和dts lane配置必须一致。
• 出图了但画面有横向条纹。大概率是MCLK频率和sensor输出像素时钟关系不对，检查sensor的PLL配置和MCLK实际频率，用示波器量一下MCLK，24MHz标称值实际跑成24.5MHz也会导致花屏。

关于启动链路的坑：

• 内核起来了但rootfs挂载失败，提示VFS: Unable to mount root fs。检查rootfs镜像格式和bootargs里的root=参数，Rockchip SDK的rootfs一般是ext4或squashfs，bootargs要对应。
• U-Boot的env里bootcmd指向的boot分区偏移和实际烧录位置不一致，导致每次启动都进不了内核。烧录之前用upgrade_tool df看一下分区表，和U-Boot env里的partitions变量对一遍。
• 系统跑了几天，发现日期不对、时间总是回到1970，这是RTC没配好，可以用i2c外接一个RTC芯片，也可以直接用SoC内部的RTC，但要把对应的PMU电源在dts里打开。

调试工具方面，我的建议是串口log和dmesg永远开着，别关。很多偶发问题需要翻历史log，如果没有完整log，问题重现一次的时间成本会非常高昂。加一个dmesg -n 7让所有级别的log都输出到串口，量大的时候用CRT或minicom的scrollback buffer兜底。另外在rootfs里提前放好这些命令：i2cdetect、media-ctl、v4l2-ctl、memtester、stressapptest、adb。这些工具在你调试的时候每一样都会救你的命。

回到开头那句话：RV1126B的SDK移植，本质上就是在跟启动链路的每一层打交道。DDR配置是地基，地基不稳后面全白搭；USB是手脚，手脚不灵效率就上不去；sensor是眼睛，眼睛不亮这个芯片存在的意义就没了。按这个顺序逐层打通，每一步都做好验证再往下走，整个移植过程其实没有真正意义上"难到卡死"的坎。