2026嵌入式及边缘AI技术生态大会圆满收官

4月17日，飞凌嵌入式「2026嵌入式及边缘AI技术生态大会」在深圳圆满收官！这场大会以“AI向实 生态共融”为核心，汇聚了300余位来自芯片、操作系统、存储、工控等全产业链的专家、生态伙伴与技术从业者，共话技术趋势、拆解落地实践、共筑开放生态，为嵌入式AI技术赋能千行百业，写下了浓墨重彩的一笔。

盛会启幕 锚定产业务实新航向

飞凌嵌入式研发总监宋明洋致开幕辞，分享企业20年来的技术深耕与生态布局，明确大会“AI向实”的核心：让技术走出概念、落地产业，为千行百业智能化升级注入真实动力。

主题演讲 11场分享覆盖全赛道

现场11位行业大咖聚焦工业升级、边缘AI、开源鸿蒙、工控生态等核心赛道，全程输出实战干货（以下按嘉宾演讲顺序排序）：

展区沉浸体验 共览全栈生态成果

大会设置了全产品矩阵展示区、新品推荐展示区、软件生态展示区、教育市场产品展示区、生态厂商展示区等五大主题展区，集中呈现飞凌嵌入式全栈产品矩阵与生态伙伴前沿成果。

生态伙伴联合展区

生态厂商展区邀请到了安谋科技、瑞芯微电子、全志科技、江波龙、鸿湖万联、菲尼克斯电气、统信软件、中移物联、麒麟软件共9家合作伙伴，联合带来多领域前沿成果。从底层芯片架构、高性能硬件平台，到国产化系统适配、工业级通讯方案与端边协同应用，全方位展现产业链协同创新实力。

瑞芯微电子

人工智能物联网处理器芯片企业，深耕智能应用处理器SoC与AI协处理器研发，打造工业级芯片方案与端侧大模型生态

安谋科技

国内领先的芯片IP设计与服务提供商，累计芯片出货量突破450亿片，赋能端侧AI与智能计算生态

全志科技

聚焦工业控制与车载领域，提供国产芯片平台与智能化升级解决方案，深耕工控领域创新实践

江波龙

深耕集成存储领域，探索存储与端侧AI的融合创新应用，为嵌入式场景提供高可靠存储方案

鸿湖万联

软通动力旗下专注开源鸿蒙操作系统研发与产业化服务的高科技企业，打造天鸿操作系统全栈解决方案

菲尼克斯电气

全球领先的电气与自动化解决方案供应商，深耕工业数字化转型，打造软硬件协同的工控新生态

统信软件

中国操作系统骨干企业，打造安全稳定的国产操作系统产品与服务，引领软硬件生态建设

中移物联

中国移动旗下专业化物联网企业，提供全栈物联网核心能力与解决方案，赋能产业数智化转型

麒麟软件

以安全可信操作系统技术为核心，打造世界级操作系统中国品牌，全面适配国产主流CPU

飞凌精灵教育品牌专区

飞凌精灵(EIfBoard)是飞凌嵌入式旗下教育品牌，专注为高校、科研机构及个人学习者提供覆盖嵌入式系统、人工智能、边缘计算与物联网技术的全栈式解决方案。品牌秉持"技术赋能教育，智能驱动未来"的核心理念，依托开发板、开发套件、实验平台及产教融合服务，助力高校强化教学实践体系。

AI场景化方案实景展示

多款AI演示方案实景落地，覆盖智能安防、工业视觉、人脸识别、储能运维、多模态分析等热门场景，嘉宾可零距离体验、与技术专家面对面交流，一站式掌握产业最新落地成果。

工业安防边缘AI智能网关系统

端边云协同AI安防方案，赋能工业智能制造安全管控

LVGL充电桩人机交互方案

基于TI AM62L32核心板，打造流畅的充电桩交互体验

T536光伏箱变测控装置方案

基于全志T526核心板，实现光伏场景高精度测控

RV1126B四路AHD摄像头环视方案

基于国产RV1126B处理器，实现全景拼接与全局态势感知

端侧多路视频VLM监控系统

多通道视频智能分析，实现实时预警与事件记录

8路CAN-FD技术方案

基于全志T536核心板，满足工业场景高可靠通讯需求

能耗管理系统方案

实现全场景能耗监测与智能化管理

DMS驾驶员疲劳监测方案

基于NXP i.MX9352核心板，实现驾驶员状态实时监测预警

← 左右滑动查看更多方案 →

福利高光 惊喜不停 满载而归

除了干货满满的技术分享，本次大会也为到场嘉宾准备了多重惊喜福利，四轮抽奖共送出飞凌嵌入式开发板、华为 GT6手表、夸克AI眼镜、Mac mini等价值近2万元的重磅好礼，将现场氛围一次次推向高潮。

圆满收官 以技术为基 赋能千行百业

华北区负责人

华东区负责人

华南区负责人

中西区负责人

近期，飞凌嵌入式推出的FET3506J-C核心板顺利完成OpenHarmony 5.1 Release版本兼容性测评，成功斩获【OpenHarmony生态产品兼容性证书】，这标志着公司在OpenHarmony生态领域再添重要成果，进一步夯实了全国产化嵌入式硬件方案的技术底座，为工业物联网、边缘计算、智能终端等多领域应用提供更高效、更稳定的底层支撑。

OpenHarmony生态产品兼容性证书

证书编号：NO.OAOH20260300013 | 测评版本：OpenHarmony 5.1.0 Release

FET3506J-C核心板核心硬件特性

飞凌嵌入式FET3506J-C核心板基于瑞芯微RK3506J工业级SoC开发，采用100%国产化物料打造，凭借卓越的硬件设计与性能表现，可适配严苛的工业场景需求，为各类智能硬件产品提供稳定、高效的底层支撑。

多核异构架构 3核Cortex-A7@1.5GHz + Cortex-M0，兼顾运算性能与低功耗控制

极致低功耗 主频最高1.5GHz，满载运行功耗实测仅0.7W，无需额外散热处理

工业宽温适应 -40℃~+85℃超宽工作温度，满足工业现场复杂环境使用需求

100%国产化 全物料国产化选型，保障供应链安全与产品自主可控性

高稳定性 工业级SoC核心，经过严苛测试验证，为产品可靠运行保驾护航

丰富接口拓展 集成多路串口、以太网、GPIO等工业接口，满足各类设备快速接入

华北区负责人

华东区负责人

华南区负责人

中西区负责人

全场景落地能力

1. 超大人员体量的人脸集约化管理

RV1126B开发板搭载强劲的算力与存储硬件模块，可承载超大容量人脸底库，最高支持10万张人脸照片本地存储，硬件层面可轻松覆盖矿场上千至上万名员工的规模化管理需求。依托这一核心硬件优势，矿场可提前将员工人脸信息录入板端，现场仅需一次刷脸，即可通过板端硬件完成实时人脸比对、身份极速核验，核验完成后自动同步各环节登记记录，彻底摒弃低效繁琐的人工登记流程，从硬件层面全方位保障矿场大规模人员管理的效率与便捷性，大幅降低人力运营成本。

轻松覆盖万级人员管理，彻底替代人工登记，大幅降低运营成本

2. 矿场复杂工况下的精准人脸识别

该开发板内置3TOPS端侧NPU AI算力硬件，为高精准、高灵活的人脸识别提供核心算力赋能，可高效完成人脸置信度得分逻辑的硬件级运算，同时支持硬件层面的阈值灵活调节。基于这一硬核算力支撑，矿场可根据不同作业场景灵活切换识别模式：高阈值模式下，硬件全力拉满识别精度，精准适配高权限管控、重要设备操作等核心关键环节，杜绝身份误判；低阈值模式下，硬件优化提升识别容错性，即便在远距离、光线昏暗、轻微遮挡（如佩戴安全帽、口罩）等复杂工况中，也能凭借强劲算力快速完成精准识别，完美适配户外作业、流动巡检等场景。

支持多人同框硬件级处理，自动匹配最高置信度人脸，识别不卡顿

3. 功能多元化拓展

RV1126B开发板具备充足的算力冗余硬件特性（矿场人脸识别解决方案仅占用其0.7-0.8TOPS算力），且支持硬件层面的模型灵活替换、快速部署，为矿场功能拓展提供了坚实的硬件基础。在满足工具借还、考勤登记等核心需求的前提下，可依托剩余算力硬件实现人脸云台跟随功能，通过硬件驱动云台自动跟随核验通过的目标人脸，实现动态追踪识别；同时，开发板硬件支持快速搭载车牌识别、物品检测等专用模型，单台硬件设备可实现多场景复用，最大化释放硬件价值。

单台设备多场景复用，算力冗余充足，可无限拓展智能化场景

4. 人脸数据安全闭环管理

RV1126B开发板具备全本地运行的硬件能力，所有AI运算、人脸数据存储均在板端本地完成，无任何数据上传的硬件链路，从硬件根源上杜绝数据泄露风险，筑牢矿场人员信息隐私防线。同时，硬件层面可设计手动+自动双模式人脸照片删除功能，支持底库清空状态实时查验，可通过简单的硬件操作彻底删除已录入的人脸照片，全方位为矿场人脸数据隐私安全提供硬件级防护，契合矿场数据安全管理的核心诉求。

全本地运算存储，从硬件根源杜绝数据泄露，满足工业级安全要求

5. 安全功能迭代升级

RV1126B开发板为矿场后续安全管理升级预留了充足的硬件拓展空间，可通过硬件对接搭载双目深度/结构光摄像头，在原有硬件基础上快速实现活体检测功能，精准区分真人脸与照片、视频等伪造手段，进一步提升人脸识别的安全性与可靠性。从硬件层面满足矿场更高标准的安全管理需求，灵活适配后续个性化、差异化的硬件升级诉求，为矿场安全管理长效升级提供硬件保障。

可拓展双目活体检测，适配更高安全标准，支持长效升级迭代

飞凌嵌入式边缘AI产品矩阵

高性能AI计算平台 · 全场景工业级解决方案 · 端边云协同赋能

华北区负责人

华东区负责人

华南区负责人

中西区负责人

OK1126B-S开发板LT8912B MIPI转HDMI适配测试场景

在按照常规适配流程完成基础配置后，出现了屏幕无显示且HDMI输出端提示"不能显示此视频模式，请将电脑重新设置为1920X1080"的问题，遂开展针对性的问题排查与适配优化。

基于此，先核查已完成的适配配置步骤，确认驱动部署与设备树硬件挂载的流程无问题，再聚焦到显示模式的匹配性上，最终定位到核心问题：LT8912B的驱动文件lt8912_cp.c中，默认仅启用了1280×800这一种显示模式，而设备树中初始配置的是1920×1080分辨率，导致驱动无法识别并初始化对应的显示模式，进而出现屏幕不亮的兼容问题。

完整适配解决方案

针对上述原因，结合OK1126B-S开发板 6.1.141 Buildroot系统的特性，整理了完整的适配解决思路，分步骤完成驱动部署、编译配置、设备树硬件挂载与显示参数匹配，具体步骤如下：

# 加入LT8912B MIPI转HDMI驱动编译
obj-y += lt8912_cp.o

3

设备树添加LT8912B硬件节点

驱动编译的问题解决了，接下来就是设备树的配置。参照OK1126B-S平台的OK1126B-S-common.dtsi设备树文件，在 i2c3节点下添加LT8912B的设备节点，完成芯片与i2c3总线的硬件绑定与挂载。由于LT8912B拥有三个i2c地址，设备树中暂配置0x01，核心i2c地址由内核驱动函数动态添加，节点配置如下：

&i2c3{
    status = "okay";
    pinctrl-names = "default";
    pinctrl-0 = <&i2c3m1_pins>;
    // 龙迅LT8912B MIPI转HDMI设备节点
    lt8912: lt8912@1 {
        compatible = "lontium,lt8912";
        reg = <0x01>;
        i2c-bus = <&i2c3>;
        reset-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
        status = "okay";
    };
};

设备树i2c3节点配置示意图

4

修改显示设备树匹配驱动显示模式

之前的黑屏问题，主要原因就是分辨率不匹配，编辑OK1126B-S-display.dtsi设备树文件，将显示时序配置修改为 1280×800，与lt8912_cp.c驱动默认支持的显示模式匹配，具体的显示时序参数配置如下：

disp_timings0: display-timings {
    native-mode = <&panel_1280x800>;
    panel_1280x800: timing0 {
        hback-porch = <10>;
        hfront-porch = <100>;
        hactive = <1280>;
        hsync-len = <10>;
        vback-porch = <1>;
        vfront-porch = <2>;
        vactive = <800>;
        vsync-len = <20>;
        clock-frequency = <71000000>;
        /* Approximate 71 MHz for ~60Hz with these timings */
        vsync-active = <0>;
        hsync-active = <0>;
        de-active = <0>;
        pixelclk-active = <0>;
    };
};

显示时序参数配置示意图

验证测试结果

开机测试，打开RV1126B开发板，LT8912B MIPI转HDMI功能已经实现正常适配，屏幕顺利点亮，之前烦人的视频模式报错再也没有出现。通过开发板终端执行指令验证适配结果，均得到符合预期的反馈：

1. 执行 i2cdetect -y 3，可在i2c3总线中检测到LT8912B设备，确认硬件挂载成功；
2. 执行 dmesg | grep 8912，可看到驱动正常的初始化日志，核心日志如下：

[4.964730] LT8912 ID:12,b2
[4.964736] LT8912:Start Initialization...
[5.222233] LT8912:Setting Mode 1280x800
[5.705876] LT8912:Releasing Reset (0xFF)...
[5.806216] LT8912: Enabling HDMI...
[5.806543] LT8912:Init Done.

驱动初始化日志验证截图

华北区负责人

华东区负责人

华南区负责人

中西区负责人

全国大学生嵌入式芯片与系统设计竞赛报名链接：

https://www.socchina.net/home?trackType=2

瑞芯微&飞凌嵌入式选题指南下载地址：

https://www.socchina.net/details?id=6ad88fd486ee4626a2fd7d172b53a68f

在《基于 OpenClaw 与 瑞芯微RV1126B 私有化部署飞书智能助手全流程》一文中，我们讲解了将OpenClaw部署在飞凌嵌入式OK1126B-S开发板（基于瑞芯微RV1126B设计），并通过飞书调用部署在服务器上的本地模型，从而实现专属本地AI助手的方法。本篇文章，我们将进一步深入挖掘OpenClaw的核心能力之一 —— Skills。

一、OpenClaw Skills 生态

截至发稿前，ClawHub社区中发布的Skills数量已达到了2.6w+，但这些Skills中超过99%都是面向Windows/x86 Linux/Mac且聚焦于办公、网页自动化等方面，面向嵌入式Linux的Skills数量极少且成熟度较低，缺乏对嵌入式外设（GPIO、UART、SPI、I2C、传感器、电机、摄像头）的标准化封装与驱动适配，并且没有针对边缘计算、低功耗、实时性场景（如工业控制、机器人、智能家居、车载等）的专用技能集。

ClawHub社区Linux相关Skills列表展示

本文，我们将以一个“控制OK1126B-S开发板上的Led灯闪烁节奏”的简单案例做演示，从基础开始逐步拆解Skills的设计与使用方法。

二、什么是Skills？

从本质上来说，Skills就是一本“操作手册”。它并不是直接帮AI完成任务，而是告诉AI在什么情况下应该做什么，以及如何去做。

我们用一个简单的类比来理解：

在射击游戏中，玩家的目标是击败敌人。枪作为工具，它的职责非常单一：

• 输入：扣动扳机
• 输出：发射子弹

至于子弹打到哪里，枪本身并不关心。而这个Skill的作用，则类似于“战术手册”。它会告诉AI：

• 什么时候可以开枪（检测到敌人）
• 什么时候不该开枪（有友军在前）
• 什么时候停止（敌人血量归零）

通过这些规则约束，AI就不再是一个机械执行指令的工具，而是开始具备初步的判断能力与决策逻辑，开始“像人一样思考”。

2.1 Skill的基本构成

在OpenClaw中，一个Skill实际上是一个结构化的目录，通常存放在：

~/.openclaw/workspace/skills/${SKILL_NAME}

一个完整的Skill由四个核心部分组成：

Skill标准目录结构示意图

命名规范：Skill的目录名称必须符合规范，否则无法被识别：

• 只能使用：小写字母+数字+连字符（-）
• 示例：gpio-led-control

2.2 SKILL.md 详细解释

SKILL.md是整个Skill的核心，可以理解为“说明书+行为指南”。它由两部分组成：

① 前置元数据（Metadata）

使用 --- 包裹，主要用于定义 Skill 的基本信息，这些信息的作用是：帮助 OpenClaw 识别 Skill、提供语义匹配（Skill 触发关键词）。

示例：

---
name: gpio-led-control                      # 必填项
description: 开发板 GPIO LED 灯控制技能。   # 必填项 
# 以下为可选项
user-invocable: true                        # 是否可被用户直接调用
---

② 正文（操作手册）

正文部分就是具体的操作指导手册，可根据需求灵活组织。以我们提前编写好的"gpio-led-control"下的SKILL.md简化版为例：

# GPIO LED Control - 开发板 LED 灯控制
控制 OK1126B 等开发板上的系统 LED 灯（work/net 等）。
## 快速开始
### 查看可用 LED
### 控制 LED 亮灭
## 使用场景示例
## 权限说明
## 注意事项

在实际编写时，可根据需要扩展，例如：增加判断逻辑（何时执行）、增加错误处理、增加参数说明、增加示例输入输出等。

除了核心的 SKILL.md之外，其余三个目录属于辅助结构，各自承担不同角色：

• scripts目录：主要用来存放可直接运行的脚本文件，适合那些执行逻辑固定、无需频繁改动的任务场景，例如控制LED灯的亮灭转换等。这类脚本可以被直接调用运行，从而减少重复生成代码的过程，提高整体执行效率与稳定性。
• references目录：用于整理各类参考资料，例如：API文档、数据库结构说明或操作手册等。这些内容并不会在一开始全部加载，而是根据实际需要按需引入上下文，既避免了无关信息占用资源，也能在关键时刻为AI提供更深入、专业的知识支持。
• assets目录：用于存放各类资源文件，例如模板、图片等。与 references 不同，这里的内容不会参与模型上下文推理，而是服务于最终结果的生成，例如报告模板、输出所需图片等，用于提升Skill输出的表现力和完整度。

2.3 自定义Skill编写流程

理解结构之后，我们就可以开始编写自己的Skill了。编写Skill的整个流程可以总结为： 需求分析→资源规划→初始化→编写→打包→测试

第一步：需求分析

在动手之前，必须明确：

• Skill 要解决什么问题？
• 使用场景是什么？
• 用户会怎么触发它？
• 输入输出是什么？

第二步：资源规划

根据需求判断是否需要：

• scripts（是否需要执行代码）
• references（是否需要文档支持）
• assets（是否需要输出资源）

提前规划可以避免后期结构混乱以及反复修改导致的冗余。

第三步：编写与调试

我们可以借助OpenClaw，在指定目录中自动生成一份符合规范的Skill初始模板，并在此基础上进行二次完善。不过需要注意的是，这类自动生成的Skill只是一个“起点”，通常无法直接满足实际需求。要想真正落地使用，仍然需要结合具体场景，对其内容进行逐步调整与反复测试，最终打磨出符合预期的功能效果。

三、Skill实战展示

为了更直观地理解，我们编写了一个简单的Skill并放在了对应的目录下，该Skill用于控制OK1126B-S开发板上两颗 LED灯的闪烁。

在前序文章中，我们已经将安装在开发板上的OpenClaw接入了飞书，因此，我们此时可以直接用飞书对OpenClaw下达命令，效果演示如下：

接入不同的Skill后，OpenClaw会： 识别用户意图→匹配对应Skill→根据SKILL.md的规则执行→调用scripts中的脚本→返回执行结果。

整个过程无需人工干预，实现真正的“自然语言控制硬件”。

四、总结

我们通过拆解Skills的核心概念、结构，并结合LED控制简易实操案例，清晰展现了Skills的落地应用逻辑。即便只是基础的硬件控制场景，这个案例也直指Skills的核心价值：把复杂业务流程封装成可复用的标准化能力单元。

Skills的设计初衷，就是实现指令化调用、规范化执行：完成Skills搭建后，仅需一句指令即可驱动AI按预设规则完成任务，既彻底规避重复开发、重复调试的冗余劳动，又能保障全场景任务执行的稳定性与一致性，在嵌入式开发、自动化运维、智能设备管控等领域具备极强的实用价值。

嵌入式领域是OpenClaw生态落地的核心突破口，既是实现硬件实时交互、落地边缘智能的关键入口，也是整个生态中增长潜力最大、优质能力供给最紧缺的赛道。只有持续打造丰富、易用、高可靠的嵌入式Skills能力池，OpenClaw才能突破桌面工具的定位局限，真正成长为覆盖“云-边-端”全链路的完整智能执行框架。

华北区负责人

华东区负责人

华南区负责人

中西区负责人

OpenClaw凭借出众的能力爆火出圈，如果将它集成到飞书中做成专属智能助手，能大幅提升日常办公效率，让文档总结、消息处理、任务协同更智能高效。想要稳定落地这一场景，一块靠谱的边缘硬件平台必不可少。

飞凌嵌入式OK1126B-S开发板

本方案基于瑞芯微RK1126B处理器打造的边缘AI视觉开发板，集成4个ARM Cortex-A53高性能核心，具备3TOPS@INT8的AI计算能力，可轻松完成端侧轻量化AI模型实时推理。性能高、功耗低、私密性强的特性，让它非常适合作为本地AI Agent的运行平台。

OK1126B-S开发板硬件接口示意图

系统推荐：使用Debian/Ubuntu等完整Linux发行版，方便通过apt安装依赖库与AI相关组件；不建议使用精简Linux（如Buildroot），否则在开发和部署过程中会增加环境搭建成本。

本文将为大家介绍本地私有化模型部署以及访问云端模型API的方法，完成基于RV1126B开发板飞书智能助手的全流程搭建。

一、OpenClaw安装与模型配置

1.1 安装OpenClaw

执行以下命令一键安装OpenClaw：

curl -fsSL https://openclaw.ai/install.sh | bash

安装完成后进入引导界面，若未自动弹出，可在终端输入以下命令手动启动：

openclaw onboard --install-daemon

进入引导界面后，依次选择：yes → QuickStart → Use existing values

OpenClaw初始化引导配置界面

1.2 接入云端付费模型

进入模型选择界面，此处我们选择Qwen免费模型进行体验，若您拥有付费模型的API，可在此处选择对应的模型。

OpenClaw模型提供商选择列表

以接入Qwen模型为例，点击界面中的链接，登录后即可免费体验Qwen模型：

Qwen模型OAuth授权引导界面

1.3 接入本地模型

若选择云端模型API，可跳过此章节。本地模型部署基于Ollama实现，全流程如下：

1.3.1 服务器端安装Ollama

最低配置要求：

• 内存：4GB（适配1B-3B小模型）
• 存储：10GB空闲空间
• 系统：Linux/macOS 12+ /Windows 10+

推荐配置要求：

• 内存：16GB+（适配7B-14B模型）
• 显卡：NVIDIA 8GB+显存（支持GPU加速）
• 存储：50GB+SSD

执行以下命令安装Ollama：

curl -fsSL https://ollama.com/install.sh | sh

上述脚本会自动下载最新版本的Ollama，创建系统服务并启动后台进程。安装完成后，执行以下命令验证安装，输出版本号即为成功：

ollama --version

Ollama安装成功版本验证示例

1.3.2 修改Ollama service服务配置

Ollama服务默认运行在127.0.0.1上，无法满足远程调用需求，需修改对应service服务配置：

vi /etc/systemd/system/ollama.service

在[Service]区域添加以下配置：

Environment="OLLAMA_HOST=0.0.0.0"

Ollama service服务配置修改示例

修改完成后，执行以下命令重启服务：

sudo systemctl daemon-reload
sudo systemctl restart ollama

1.3.3 下载并运行指定模型

执行以下命令，会自动下载指定模型并运行，此处我们选择qwen3.5-9b模型，您可根据实际服务器情况选择对应模型。

ollama run qwen3.5:9b

Ollama模型成功运行界面示例

此时，可在OK1126B-S开发板（基于RV1126B设计）上执行以下命令测试对话，正常情况下将得到模型返回的输出内容：

curl http://${服务器IP地址}:11434/api/chat -d '{"model": "qwen3.5:9b",
"messages": [ 
{"role": "user", "content": "你是谁"} 
]
}'

1.3.4 OpenClaw配置文件修改

使用本地模型时，需手动修改OpenClaw的配置文件，步骤如下：

Step1：编辑OpenClaw配置文件

vi ~/.openclaw/openclaw.json

Step2：粘贴以下配置内容，并按Step3说明修改适配

{
  "meta": {
    "lastTouchedVersion": "2026.3.8",
    "lastTouchedAt": "2026-03-12T01:44:37.610Z"
  },
  "wizard": {
    "lastRunAt": "2026-03-12T01:44:37.566Z",
    "lastRunVersion": "2026.3.8",
    "lastRunCommand": "onboard",
    "lastRunMode": "local"
  },
  "auth": {
    "profiles": {}
  },
  "models": {
    "providers": {
      "ollama-remote": {
        "baseUrl": "http://192.168.1.111:11434/v1",
        "apiKey": "sk-no-key-required",
        "api": "openai-completions",
        "models": [
          {
            "id": "qwen3.5:9b",
            "name": "Qwen 3.5 9B (Remote Ollama)",
            "reasoning": false,
            "input": [
              "text"
            ],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "contextWindow": 32768,
            "maxTokens": 8192
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "ollama-remote/qwen3.5:9b"
      },
      "models": {
        "ollama-remote/qwen3.5:9b": {
          "alias": "qwen"
        }
      },
      "workspace": "/root/.openclaw/workspace",
      "compaction": {
        "mode": "safeguard"
      },
      "maxConcurrent": 4,
      "subagents": {
        "maxConcurrent": 8
      }
    }
  },
  "tools": {
    "profile": "coding"
  },
  "messages": {
    "ackReactionScope": "group-mentions"
  },
  "commands": {
    "native": "auto",
    "nativeSkills": "auto",
    "restart": true,
    "ownerDisplay": "raw"
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "gateway": {
    "port": 18789,
    "mode": "local",
    "bind": "loopback",
    "auth": {
      "mode": "token",
      "token": "4893303352c56f5e9acbb076cc47c5398bb8df525fed4699"
    },
    "tailscale": {
      "mode": "off",
      "resetOnExit": false
    },
    "nodes": {
      "denyCommands": [
        "camera.snap",
        "camera.clip",
        "screen.record",
        "contacts.add",
        "calendar.add",
        "reminders.add",
        "sms.send"
      ]
    }
  },
  "plugins": {
    "entries": {}
  }
}

Step3：配置字段修改适配说明

1. models.providers 下面的 key 可自定义填写，示例中为 "ollama-remote"；
2. baseUrl 字段需填写服务器的地址，即1.3.3中使用curl测试时的地址，示例为 "http://192.168.1.111:11434/v1"；
3. apiKey 字段可任意填写，但不可为空；
4. api 字段需根据模型的输出接口形式确定，ollama输出标准openai格式，故此处为 openai-completions；
5. models 字段下的 id 需严格匹配 ollama 中的模型名，name 字段可自定义填写；
6. agents 字段需修改 primary 字段以及 models 字段的 key 值，修改为 "models.providers 下的key / models.id"，示例为 "ollama-remote/qwen3.5:9b"。

配置完成后，重新在命令行输入以下命令进入引导界面：

openclaw onboard

1.3.5 选择本地模型

进入模型选择阶段，直接选择Skip for now跳过即可。

OpenClaw模型选择跳过界面

后续筛选模型时，选择All providers，然后在默认模型选项中，选择Keep current，括号内会显示之前配置的本地模型。

OpenClaw本地模型默认选择界面

1.4 基础配置

以下基础配置仅适用于初次验证，无额外集成功能，按界面提示依次选择即可。

OpenClaw启动方式选择界面

OpenClaw通道选择界面

若为首次安装，会自动安装Gateway service；若非首次安装，选择Restart即可。

OpenClaw启动方式选择界面

首次安装完成后，会出现启动方式选择：TUI为终端命令行输入模式，Web UI为开发板连接显示器后通过Web界面操作。

OpenClaw启动方式选择界面

若未自动弹出启动方式选择界面，可手动输入以下命令进入终端对话模式：

openclaw tui

执行后即可正常与模型对话：

OpenClaw TUI终端对话界面示例

二、飞书智能助手部署全流程

2.1 创建飞书应用

进入飞书开发者后台：https://open.feishu.cn/app，点击"创建企业自建应用"。

飞书开发者后台创建企业自建应用入口

填写"应用名称"和"应用描述"后，点击"创建"按钮完成应用创建。

飞书企业自建应用创建信息填写界面

在"凭证与基础信息"栏目中，复制App ID以及App Secret，后续配置需要使用。

飞书应用凭证信息查看界面

2.2 OpenClaw飞书插件配置

在OK1126B-S开发板上输入以下命令，安装并启用飞书插件，查看插件状态：

openclaw plugins enable feishu
openclaw plugins list

Feishu一栏显示Loaded即代表插件启动成功。

OpenClaw插件列表状态查看界面

执行以下命令进入通道配置界面，选择Yes：

openclaw channels add

OpenClaw飞书插件配置

在通道选择列表中，选择"Feishu/Lark（飞书）"。

OpenClaw飞书插件配置

选择"Enter App Secret"，依次输入2.1步骤中复制的App Secret以及App ID。

OpenClaw飞书插件配置

设置连接模式为"WebSocket"，并选择国内域名"Feishu (feishu.cn) -China"。

OpenClaw飞书插件配置

群聊策略选择"Open"（响应所有群聊，需@机器人），Allowlist策略仅响应白名单中的群聊，可按需选择。

OpenClaw飞书插件配置

点击"Finished"，其余选项保持默认配置即可。

OpenClaw飞书插件配置

OpenClaw飞书插件配置

2.3 飞书机器人权限与事件配置

回到飞书开发者后台的应用界面，完成以下配置：

2.3.1 开启机器人能力

依次点击：添加应用能力→机器人，点击"添加"按钮，开启机器人能力。

飞书应用添加机器人能力界面

2.3.2 配置应用权限

依次点击：权限管理→批量导入/导出权限。

飞书应用权限管理界面

在批量导入/导出权限界面，粘贴以下JSON内容，启用对应权限：

{
  "scopes": {
    "tenant": [
      "aily:file:read",
      "aily:file:write",
      "application:application.app_message_stats.overview:readonly",
      "application:application:self_manage",
      "application:bot.menu:write",
      "cardkit:card:read",
      "cardkit:card:write",
      "contact:user.employee_id:readonly",
      "corehr:file:download",
      "event:ip_list",
      "im:chat.access_event.bot_p2p_chat:read",
      "im:chat.members:bot_access",
      "im:message",
      "im:message.group_at_msg:readonly",
      "im:message.p2p_msg:readonly",
      "im:message:readonly",
      "im:message:send_as_bot",
      "im:resource"
    ],
    "user": ["aily:file:read", "aily:file:write", "im:chat.access_event.bot_p2p_chat:read"]
  }
}

依次点击：下一步，确认新增权限 → 申请开通，完成权限配置。

飞书应用权限导入确认界面

2.3.3 配置事件订阅

依次点击：事件与回调 → 事件配置 → 订阅方式 → 使用长连接接收事件 → 保存。

飞书事件订阅方式配置界面

点击"添加事件"，添加以下事件：

飞书添加事项配置界面

• im.message.receive_v1 - 接收消息
• im.message.message_read_v1 - 消息已读回执
• im.chat.member.bot.added_v1 - 机器人进群
• im.chat.member.bot.deleted_v1 - 机器人被移出群

2.3.4 发布应用版本

依次点击：版本管理与发布 → 创建版本，填写版本号和版本说明后，提交发布申请。

飞书应用版本创建与发布界面

2.4 功能测试

进入飞书APP端，点击右上角+号，创建群组。

飞书创建群组

依次点击右上角...进入群设置界面，选择添加机器人。

飞书群添加机器人界面

输入刚才创建的机器人名字后，添加机器人即可。

飞书群添加机器人界面

添加完成后，即可在飞书中@机器人进行对话，完成飞书智能助手的全流程部署。

飞书机器人对话测试效果示例

华北区负责人

华东区负责人

华南区负责人

中西区负责人

工业网关选型总踩坑？既要强劲硬件性能、稳定可靠运行，又要操作便捷易上手，还得兼容多种工业协议、适配严苛工业环境？今天我们开箱飞凌嵌入式2026年全新上市的FCU1501工业级嵌入式控制单元，这款专为电力能源、工业自动化、轨道交通、储能EMS、智慧市政等场景打造的国产工业网关，完美解决选型痛点，话不多说，直接开拆！

产品分为基础版与扩展版两大版本，整机尺寸完全一致，接口灵活差异化配置，无需改动安装结构即可随心切换，本次开箱的是接口更丰富的扩展版，全方位解锁它的硬核实力。

工业级精工设计，恶劣环境稳如磐石

拆开包装，FCU1501整机工业质感拉满，金属机身做工扎实，无多余冗余设计，适配各类工业控制柜紧凑安装需求。基础尺寸仅177×130.5×45mm（含卡扣、端子及天线座为187×152×45mm），基础版重0.8kg、扩展版重0.9kg，小巧轻便却承载强悍性能。

双版本灵活适配，全场景接入无压力

FCU1501创新采用双生接口设计，基础版与扩展版尺寸完全相同，仅接口数量差异化配置，用户可根据现场设备数量灵活选择，不用重新设计安装开孔，极大降低项目改造成本。扩展版接口布局清晰，分正面与顶部规整排布，接口资源拉满，单台可替代多台传统网关，大幅提升系统集成度。

正面核心接口（扩展版）

• 8路LED指示灯：1路PWR电源灯、1路RUN运行灯、1路ERR故障灯、3路4G信号指示灯、2路自定义指示灯，设备状态一目了然；
• 1路USB2.0（Type-A）：支持U盘固件烧写，现场升级系统无需拆机，便捷高效；
• 1路Type-C DEBUG调试口：直接连接电脑即可调试，降低开发门槛；
• 2路百兆自适应以太网口：满足工业现场局域网通信、数据上传需求；
• 2路CANFD接口：兼容CAN2.0B，每路独立数字地，抗干扰更强，适配汽车电子、工业控制、轨道交通等CAN总线设备；
• 8路RS485接口：支持多路串口设备同时接入，每路独立数字地，杜绝信号串扰，适配传感器、仪表、PLC等工业串口设备；
• 2路RS232接口：与RS485复用，兼顾老旧串口设备接入需求；
• 8路DI干接点输入、8路DO继电器输出：DO触点容量达5A 250VAC/5A 30VDC（常开），完美对接工业开关、阀门、报警器等执行设备；
• 双频Wi-Fi+蓝牙5.0：标配双天线，无线通信稳定，支持设备无线调试、数据传输；
• 1路4G Cat1（选配）：满足无网线场景的远程数据传输，适配户外场站、偏远厂区等场景。

顶部辅助接口

• ANT天线座：适配4G、Wi-Fi、蓝牙天线，信号传输更稳定；
• DC9~36V宽压输入：支持反接保护、过流保护，适配工业现场复杂供电环境；
• 自弹式Nano SIM卡槽：插拔便捷，适配4G通信模组；
• RESET KEY复位键：支持一键恢复网络参数，误配置后快速复位，无需重新刷机，运维效率翻倍；
• 机身内置：蜂鸣器（故障报警）、电池供电RTC实时时钟、硬件看门狗，断电不丢时间，异常自动重启，保障7×24小时不间断运行。

国产硬核算力，稳定运行不卡顿

FCU1501作为全国产化工业网关，整机关键元器件均采用国产物料，自主可控，有效保障供应链安全，满足各行业国产化替代高标准需求，核心配置更是同级领先。

协议全覆盖+Web可视化，运维零门槛

工业网关的核心价值在于协议转换与便捷运维，FCU1501在这方面做到了极致，完美打通OT与IT数据壁垒，让设备互联更简单。

• 协议支持：内置Modbus 、MQTT、TCP/IP、SSH、OpenVPN、Nginx等主流工业协议与中间件，覆盖工业现场绝大多数通信需求；
• Web可视化管理：新增专属Web管理界面，无需安装专用调试软件、不用依赖专业工具，通过浏览器访问设备IP，即可直观完成网络设置、通信参数配置、系统状态监控等操作，新手也能快速上手，运维效率提升50%以上；
• 开箱即用：集成一键恢复参数、4G状态指示、对外供电输出、U盘烧写等实用功能，无需额外配件，通电即可快速部署，大幅缩短现场实施周期。

全行业覆盖，赋能工业数字化升级

凭借强悍性能、丰富接口、稳定可靠的特性，FCU1501可广泛应用于各类工业场景，成为数字化升级的核心枢纽。

华北区负责人

华东区负责人

华南区负责人

中西区负责人

适配背景与平台特性分析

适配背景

我正在基于飞凌嵌入式RK3588开发板，做Android14系统（内核版本6.1.99）下的工业级显示方案开发，需要完成LT9211 MIPI转LVDS模块的适配，配套1280×800分辨率的LVDS屏幕与GT911触摸屏，核心目标是稳定点亮屏幕并实现正常触控功能。

适配前的平台特性分析

瑞芯微RK3588平台的Android14 BSP，显示框架采用标准DRM架构，MIPI DSI桥接芯片的适配，核心离不开三个闭环环节：驱动正确编译进内核、设备树硬件资源无冲突配置、显示时序与屏幕参数完全匹配。

在动手修改前，我先通过编译环境命令确认了内核配置的分层规则：OK3588-Android14的内核配置由rockchip_defconfig（芯片级）、android-14.config（系统级）、OK3588-C-Android.config（板级）三个文件组成。所有板级自定义配置必须放在第三个文件中，避免后续SDK升级时配置被覆盖，这是工业级开发必须遵守的版本兼容规则。

具体适配实施步骤

一、驱动层部署

1. LT9211驱动文件与Makefile配置

LT9211是龙讯的MIPI转LVDS桥接芯片，属于DRM bridge类驱动，必须放在对应驱动目录下才能被框架正确识别。

将lt9211.c驱动文件拷贝到kernel-6.1/drivers/gpu/drm/bridge目录下，修改同目录的Makefile文件，在文件末尾添加编译配置，确保驱动被编译进内核镜像。

完整上下文参考：

Makefile
27 obj-$(CONFIG_DRM_SIMPLE_BRIDGE)      += simple-bridge.o
28 obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
29 obj-$(CONFIG_DRM_TOSHIBA_TC358762)   += tc358762.o
30 obj-$(CONFIG_DRM_TOSHIBA_TC358764)   += tc358764.o
31 obj-$(CONFIG_DRM_TOSHIBA_TC358767)   += tc358767.o
32 obj-$(CONFIG_DRM_TOSHIBA_TC358768)   += tc358768.o
33 obj-$(CONFIG_DRM_TOSHIBA_TC358775)   += tc358775.o
34 obj-$(CONFIG_DRM_I2C_ADV7511)        += adv7511/
35 obj-$(CONFIG_DRM_TI_DLPC3433)        += ti-dlpc3433.o
36 obj-$(CONFIG_DRM_TI_SN65DSI83)       += ti-sn65dsi83.o
37 obj-$(CONFIG_DRM_TI_SN65DSI86)       += ti-sn65dsi86.o
38 obj-$(CONFIG_DRM_TI_TFP410)          += ti-tfp410.o
39 obj-$(CONFIG_DRM_TI_TPD12S015)       += ti-tpd12s015.o
40 obj-$(CONFIG_DRM_NWL_MIPI_DSI)       += nwl-dsi.o
41 obj-$(CONFIG_DRM_ITE_IT66121)        += ite-it66121.o
42 obj-y                                 += lt8912b.o
43
44 obj-y                                 += analogix/
45 obj-y                                 += cadence/
46 obj-y                                 += imx/
47 obj-y                                 += lt9211.o

2. 内核配置修改

本次适配配套的是GT911触摸屏，需要在内核中启用Goodix系列触控驱动。按照之前确认的配置分层规则，修改板级配置文件kernel-6.1/kernel/configs/OK3588-C-Android.config，添加如下配置：

完整上下文参考：

Plain Text
CONFIG_TOUCHSCREEN_EDT_FT5X06=y
CONFIG_GPIO_PCA953X=y
CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_SND_SOC_NAU8822=y
CONFIG_NET_VENDOR_INTEL=y
CONFIG_R8169=y
CONFIG_E1000E=y
CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_RX8010=y
CONFIG_NXPWIFI=m
CONFIG_VIDEO_OV5645=y
CONFIG_USB_SERIAL_EXAR=y
CONFIG_TOUCHSCREEN_GOODIX=y

二、设备树硬件资源配置

设备树修改路径为kernel-6.1/arch/arm64/boot/dts/rockchip/OK3588-C-Common.dtsi，本次适配以MIPI0通道为例。所有原有冲突配置均采用注释方式保留，不直接删除，方便后续回滚与排查。

1. 新增触控引脚节点定义

原设备树中ft5x06触控节点占用了本次GT911所需的GPIO引脚，先注释原有节点，新增GT911的中断、复位引脚复用配置，避免引脚资源冲突。

Plain Text
    usb-typec {
        usbc0_int: usbc0-int {
            rockchip,pins = <1 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
        };
        typec5v_pwren0: typec5v-pwren0 {
            rockchip,pins = <0 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
        };
        usbc1_int: usbc1-int {
            rockchip,pins = <1 RK_PB3 RK_FUNC_GPIO &pcfg_pull_up>;
        };
        typec5v_pwren1: typec5v-pwren1 {
            rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };
    tp_int {
        gt911_dsi1_gpio: gt911-dsi0-gpio {
            rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>,
                            <3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };
    /* 原ft5x06节点注释，避免引脚冲突 */
    /*
    ft5x06_dsi0_gpio: ft5x06-dsi0-gpio {
        rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>,
                        <3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
    };
    */
    ft5x06_dsi1_gpio: ft5x06-dsi1-gpio {
        rockchip,pins = <3 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>,
                        <3 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
    };
    headphone {
        hp_det: hp-det {
            rockchip,pins = <1 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };
};

2. I2C2节点新增设备配置

LT9211与GT911均挂在I2C2总线上，在&i2c2节点下新增两个设备的节点配置，同时注释原有冲突的ft5x06设备节点。

Plain Text
    extio: tca6424@23 {
        compatible = "ti,tca6424";
        reg =;
        interrupt-parent = <&gpio1>;
        interrupts =;
        gpio-controller;
        #gpio-cells =;
        interrupt-controller;
        #interrupt-cells =;
        pinctrl-0 = <&extio_int_gpio>;
        pinctrl-names = "default";
        status = "okay";
    };
    /* 原ft5x06节点注释，保留作为参考 */
    /*
    ft5x06_dsi0: ft5x06@38 {
        compatible = "edt,edt-ft5406", "edt,edt-ft5x06";
        reg =;
        pinctrl-names = "ft5x06_default";
        pinctrl-0 = <&ft5x06_dsi0_gpio>;
        interrupt-parent = <&gpio3>;
        interrupts =;
        // irq-gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
        // reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
        touchscreen-size-x =;
        touchscreen-size-y =;
        input-phy = "ft5x06 2 38/input0";
        status = "okay";
    }
    */
    usbc0: fusb302@22 {
        compatible = "fcs,fusb302";
        reg =;
        interrupt-parent = <&gpio1>;
        interrupts =;
        pinctrl-names = "default";
        pinctrl-0 = <&usbc0_int>;
        vbus-supply = <&vbus5v_typec>;
        status = "okay";
    };
    /* LT9211 MIPI转LVDS桥接芯片设备节点 */
    lt9211: lt9211@2d {
        compatible = "lontium,lt9211";
        reg =;
        // reset-gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>; 
        status = "okay";
    };
    /* GT911触摸屏设备节点 */
    gt911_14: gt911_14_ts@14 {
        compatible = "goodix,gt911";
        reg =;
        pinctrl-names = "default";
        pinctrl-0 = <>911_dsi1_gpio>;
        interrupt-parent = <&gpio3>;
        interrupts =;
        irq-gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
        // reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
        touchscreen-size-x =;
        touchscreen-size-y =;
        // touchscreen-inverted-x; 
        // touchscreen-inverted-y; 
        touchscreen-swapped-x-y;
        status = "okay";
    };
};

3. DSI节点屏参修改

替换&dsi0节点原有的1024×600时序配置，适配本次1280×800分辨率LVDS屏幕的时序参数，所有参数需要严格对应屏幕规格书，避免出现黑屏、花屏问题。

Plain Text
/* 原有1024×600时序配置注释，保留参考 */
/*
disp_timings0: display-timings {
    native-mode = <&dsi0_timing0>;
    dsi0_timing0: timing0 {
        hback-porch     =;
        hfront-porch    =;
        hactive         =;
        hsync-len       =;
        vback-porch     =;
        vfront-porch    =;
        vactive         =;
        vsync-len       =;
        clock-frequency =;
        vsync-active    =;
        hsync-active    =;
        de-active       =;
        pixelclk-active =;
    };
};
*/
/* 新增1280×800 LVDS屏对应时序配置 */
disp_timings0: display-timings {
    native-mode = <&dsi0_timing0>;
    dsi0_timing0: timing0 {
        hback-porch     =;
        hfront-porch    =;
        hactive         =;
        hsync-len       =;
        vback-porch     =;
        vfront-porch    =;
        vactive         =;
        vsync-len       =;
        clock-frequency =;
        vsync-active    =;
        hsync-active    =;
        de-active       =;
        pixelclk-active =;
    };
};

三、内核编译与烧录

为提高验证效率，无需全量编译Android系统，使用命令单独编译内核，编译完成后生成的boot.img镜像位于rockdev/Image-ok3588_c/目录下，单独烧录该镜像即可完成适配。

Bash
# 进入SDK根目录
cd /home/forlinx/work/OK3588-android14-source/
# 加载编译环境，选择对应产品分支
source build/envsetup.sh;lunch ok3588_c-userdebug
# 单独编译内核并生成boot镜像
./build.sh -Ku

验证与经验总结

华北区负责人

华东区负责人

华南区负责人

中西区负责人

2026.3.10 · 德国纽伦堡会展中心 展位号 NO.3-561

2026年3月10日，全球嵌入式技术领域的年度盛会——embedded world 2026国际嵌入式展览会，在德国纽伦堡会展中心盛大启幕。飞凌嵌入式携多款重磅新品及全场景解决方案再一次隆重参展（展位号NO.3-561），旨在向全球行业伙伴彰显中国嵌入式企业的创新实力与强劲竞争力，持续深化全球化布局。

01 全方位、更多元

本次展会，飞凌嵌入式打造了多元化展示矩阵，全方位展出基于恩智浦（NXP）、瑞芯微（Rockchip）、全志（Allwinner）、德州仪器（TI）等主流芯片平台研发的嵌入式核心板、开发板、工控机、边缘计算网关等核心产品；并通过动态演示方案，直观呈现产品在边缘AI、工业自动化、智能显示、充电桩等热门应用场景下的高性能表现与高稳定性，充分彰显与全球头部芯片企业的深度合作成果，以及自身过硬的硬件研发与方案整合能力。

核心板/开发板矩阵 · 基于NXP, Rockchip, TI方案

边缘计算网关 & 动态演示 · 高性能与高稳定性

02 全场景、更生动

多款首发动态演示方案在飞凌嵌入式展位集中亮相，包括：i.MX 9596+Ara240感知与理解方案、i.MX 94x智能显示方案、FCU3501边缘计算网关（基于RK3588J打造）16路AI摄像头方案、RV1126B四路摄像头环视拼接方案、T536 8路CAN技术方案、TI AM62L充电桩交互方案等等，全新的平台、生动的形式，吸引了现场观众的驻足交流。

i.MX 9596+Ara240

感知与理解方案

i.MX 94x智能显示

智能交互显示方案

FCU3501 · 16路AI

基于RK3588J打造

RV1126B 环视拼接

四路摄像头无缝拼接

T536 8路CAN

工业总线连接方案

TI AM62L充电桩

智能充电桩交互

边缘AI推理

实时端侧智能分析

工业自动化控制

高稳定工控场景

03 生态聚合，联展新体验

本次展会，飞凌嵌入式继续深化与芯片原厂的合作。恩智浦、瑞芯微、德州仪器等芯片原厂更是为飞凌嵌入式提供了宝贵的联展机会。在他们的展位上，飞凌嵌入式基于各家优势产品打造的核心板、开发板以及动态演示方案吸引了众多海外观众关注。

联合演示动态方案

联合演示动态方案

04 深耕不辍，向新而行

一直以来，飞凌嵌入式坚持以技术创新为核心深耕嵌入式领域，成立20年来，凭借强大的研发实力、卓越的产品品质、完善的技术支持服务，赢得了全球客户的广泛认可。此次亮相德国纽伦堡国际嵌入式展，不仅是飞凌嵌入式技术实力与品牌形象的一次集中展示，更是企业深化国际合作、拓展全球市场的关键一步。

未来，飞凌嵌入式将继续秉持创新精神，聚焦客户需求，持续打磨产品，不断加强与全球合作伙伴的协同发展，以更优质的嵌入式解决方案赋能全球各行各业，助力嵌入式产业实现高质量、可持续发展。

embedded world 2026进行中，3月11日~12日将有更多精彩内容呈现，欢迎全球行业伙伴莅临飞凌嵌入式展台（展位号：NO.3-561），共话技术创新，共谋合作共赢！

华北区负责人

华东区负责人

华南区负责人

中西区负责人

飞凌嵌入式 · 展位 NO.3-561 期待您的莅临

核心亮点

不用逐字啃参数，先记住这4个核心亮点，快速判断是否适配你的项目：

核心参数详解

核心算力

RV1126BJ内置独立NPU，3TOPS@INT8算力，支持混合精度运算与Transformer模型优化，可本地运行2B参数级大语言模型和多模态模型，无需依赖云端，完美适配多种端侧AI场景。

处理器性能

瑞芯微RV1126BJ四核ARM Cortex-A53，主频最高1.6GHz，多任务并行处理流畅。

图像处理

VPU支持4K@30fps H.264/H.265硬解码，AI-ISP支持8M@30fps输入，可实现降噪、HDR等功能，不占用NPU资源。

存储与尺寸

LPDDR4内存（1/2/4GB可选）、eMMC存储（8/16/32/64GB可选），商业级芯片即可覆盖宽温；40mm×40mm小尺寸，邮票孔+LGA复合连接，引出237个引脚，扩展性拉满，节省终端设备空间。

适配场景

飞凌嵌入式FET1126BJ-S核心板不搞"全能冗余"，而是精准适配主流场景，每一个优势都能落地到实际应用中，覆盖当下热门的智能领域：

本产品搭载 3TOPS 峰值 AI 算力，主打端侧全离线智能推理能力，无需依赖云端即可实现低延迟、高可靠的 AI 算法运行，完美兼容百度人脸离线识别 SDK，可深度适配多行业终端设备，为全场景智能化升级提供高适配、高稳定的边缘算力支撑。

在智能安防领域，产品可无缝适配网络摄像头、人脸门禁等前端设备，依托强劲算力实现毫秒级实时人脸比对、智能异常检测；端侧离线运行的模式充分保障数据隐私与断网可用的通行稳定性，已广泛落地于轨道交通刷脸通行、智慧社区门禁等核心场景，为公共空间与居住场景打造安全高效的智能管控体系。

在智慧工业领域，产品可深度嵌入各类工业检测设备，凭借丰富的工业总线接口与专用 AI 算力，精准实现工业零件缺陷检测、生产设备故障智能预警，助力制造企业实现生产全流程的智能化管控，有效降低品控成本、规避非计划停机风险，筑牢工业生产的安全与效率防线。

面向智慧工地与智慧园区场景，产品可灵活搭配各类边缘终端，精准覆盖安全帽佩戴规范检测、危险区域入侵识别等多维度安全管控需求；本地端侧推理实现极速预警响应，大幅缩短安全事件处置时效，全方位守护施工生产与园区运营的全流程安全。

在车载后装市场，产品凭借工业级宽温运行、超低功耗的核心特性，可完美适配行车记录仪、驾驶行为分析终端等各类车载设备，在复杂多变的车载环境下依旧保持长期稳定运行，为行车安全与车载智能化升级提供可靠的边缘算力支撑。

为什么选择飞凌嵌入式

坦率来讲，市面上的RV1126BJ核心板不少，而飞凌嵌入式的核心竞争力，在于"省心+可靠+高性价比"：

从开发全链路的资源支持，到产品全生命周期的品质保障，再到企业级的技术沉淀与服务能力，飞凌嵌入式的核心底气，源于全链条自研自产的硬核实力。 公司总人数400+，研发人员占比46%，以高配比技术团队筑牢产品创新与技术服务根基；自建31000㎡智慧园区，配套年产超百万片的数智化产线，实现从研发设计、生产制造到品控交付的全流程自主可控。 也正是这份从技术到产能、从品质到服务的全维度硬实力，让飞凌嵌入式成为万千企业客户智能化升级路上，更省心、更可靠、更具性价比的优选合作伙伴。

咨询立即获得专属报价

联系销售 | 报价咨询 | 索取样品

华北区负责人

华东区负责人

华南区负责人

中西区负责人

开发背景与环境冲突解决方案选型

具体实施步骤

为高效解决该环境冲突问题，我采用Docker搭建Ubuntu 22.04独立编译环境，全程操作基于虚拟机Ubuntu 18.04，具体实施步骤如下：

1. 配置网络环境

2. 下载Ubuntu22.04 Docker镜像

docker pull homebrew/ubuntu22.04

3. 启动容器并挂载源码路径

sudo docker run --privileged=True --rm \
--mount type=bind,source=/T_2T/forlinx/ok3588/Linux-code/OK3588_Linux_fs,target=/mnt \
-i -t 80fdda227e1a

4. 补充编译所需工具

sudo apt-get install build-essential libncurses* lzop net-tools

5. 留存配置好的编译环境

sudo docker run --privileged=True --rm --mount type=bind,source=/T_2T/forlinx/ok3588/Linux-code/OK3588_Linux_fs,target=/mnt -i -t 80fdda227e1a

sudo docker commit -m="linux_3576" -a="forlinx123" dbd2586e6e36 forlinx123/linux_3576:v1

sudo docker login -u forlinx123 -p 这里换成自己的密码

sudo docker push forlinx123/linux_3576:v1

sudo docker save -o linux_3576_v1.tar forlinx123/linux_3576:v1

sudo docker load -i linux_3576_v1.tar

实践验证与开发总结

Docker常用命令

华北区负责人

华东区负责人

华南区负责人

中西区负责人

2026马年春晚直接成了机器人的秀场！宇树科技、魔法原子等4家企业的机器人花式登场，练武术、演小品、跳歌舞、盘核桃样样拿手，"机器人全面入侵春晚"的词条直接冲上热搜。春晚开播两小时，京东机器人订单暴涨150%，同款上线就售罄，银河通用70万的机型24小时狂揽数百单。这场科技盛宴不仅秀出国产人形机器人的硬核实力，更标志着具身智能赛道正式迈入规模化商业化的关键元年。

春晚科技秀：人形机器人的技术突破与场景落地信号

行业新变局：人形机器人进入规范发展新阶段

技术底座：高性能AI芯片支撑人形机器人核心需求

人形机器人的规模化发展，离不开底层硬件的支撑。无论是春晚机器人的高动态运动、多机协同，还是工业场景的精密作业、民用场景的智能交互，都对底层计算平台提出了严苛要求：高算力支撑AI算法与多传感器融合，高实时性保障运动控制与动作响应，高稳定性适配复杂多变的应用环境，小体积低功耗满足机器人的本体设计需求。

可以说，高性能的AI芯片，是人形机器人实现"大脑"与"肢体"协同的关键技术底座。

飞凌嵌入式深耕嵌入式领域多年，聚焦高端AI芯片研发，推出的FET3588-C核心板、FET1126B-S核心板等高性能嵌入式产品，精准匹配人形机器人的核心技术需求，为具身智能的落地提供坚实的硬件支撑。

FET1126B-S / FET1126BJ-S核心板

基于瑞芯微RV1126B系列 | 内置3TOPS NPU

兼具高算力与低功耗特性，可高效支撑机器视觉、语音识别等轻量级AI任务，同时具备丰富的外设接口，能实现与传感器、电机、执行器的无缝对接，为机器人的环境感知、动作反馈提供实时计算能力。

FET3588-C / FET3588J-C核心板

高性能AI计算平台 | 强大算力支持

从春晚舞台的科技惊艳，到产业端的规模化落地，为具身智能的实现提供坚实的硬件基础，连接"智能大脑"与"执行肢体"的关键纽带。

从春晚舞台的科技惊艳，到产业端的规模化落地，人形机器人的发展浪潮已至。具身智能的实现，需要算法、软件、硬件的协同创新，而高性能的嵌入式核心板，正是连接"智能大脑"与"执行肢体"的关键纽带。飞凌嵌入式将持续以技术创新为核心，打造更贴合人形机器人产业需求的AI计算平台，为国内人形机器人产业的规模化发展注入底层动力，助力具身智能从"未来已来"走向"无处不在"。

华北区负责人

华东区负责人

华南区负责人

中西区负责人

IEC 62443：工业网络安全的黄金标准

随着工业4.0与智能制造深度推进，工业控制系统面临的网络威胁日趋严峻，一旦遭受勒索软件、高级持续性威胁等攻击，轻则导致生产线停摆，重则引发基础设施瘫痪，甚至危及公共安全。

由ISA和IEC联合制定的IEC 62443系列标准，是国际公认的工业自动化和控制系统网络安全标准，被誉为工业网络安全的 “宪法”。其覆盖产品开发、系统集成、运维管理全生命周期，对嵌入式设备、网络设备等提出严苛技术要求。

拿下该认证，意味着飞凌嵌入式FCU2601嵌入式控制单元在安全开发生命周期、访问控制、数据完整性、漏洞管理等核心维度均达到国际一流水准，为工业场景安全应用筑牢根基。

CRA合规迫在眉睫！不合规将面临重罚与市场禁令

2024年12月，欧盟《网络弹性法案》（CRA）正式生效，并将于2027年12月11日全面实施，要求所有带数字元素的软硬件产品，全生命周期满足强制性网络安全要求，方可通过CE认证进入欧盟市场。

CRA将产品分为：通用类、关键I类、关键II类。其中，工业控制、储能网关、智能电表等均属关键产品，必须通过第三方权威机构认证。对于布局出海的企业而言，CRA 合规已不是 “选择题”，而是进入国际市场的 “必修课”。

CRA合规推进时间表

也就是说，距离2026年9月11日企业漏洞报告义务启动，仅剩不到6个月！

IEC 62443的完整认证周期通常需要6-9个月，若此刻尚未启动认证流程，极有可能错过关键合规节点，无法向欧盟监管机构证明履行漏洞报告义务，意味着面临巨大的法律与商业风险。

飞凌嵌入式全链条赋能 助您快速跨越CRA合规门槛

作为专业的嵌入式智能设备核心平台提供商，飞凌嵌入式深谙企业出海的合规痛点与需求。拿下IEC 62443双认证，不仅证明飞凌嵌入式自身的产品开发体系已具备国际一流的安全能力，更意味着公司可以将这套成熟的经验和方法赋能给广大客户，帮助客户快速、低成本地满足CRA及其他国际网络安全法规要求。

飞凌嵌入式可以为客户提供从安全设计到认证落地的全流程技术支持，核心服务包括：

此次斩获的IEC 62443双认证，并非单一产品的认可，而是飞凌嵌入式安全开发流程与技术能力的全面国际背书。

基于这套通过验证的成熟体系，飞凌嵌入式可将能力复制到客户各类定制化项目中，助力客户的PLC、网关、HMI、RTU、工业计算机等不同平台产品，快速通过CRA合规，抢占国际市场先机。

安全是底线 更是全球市场的入场券

华北区负责人

华东区负责人

华南区负责人

中西区负责人

项目背景与需求

本次项目是基于RK3576开发板（型号：OK3576-C）开发自助终端设备，客户核心需求是 系统启动后插入U盘可自动挂载到固定目录，且目录名无乱码。Ubuntu 24.04桌面版自带的文件管理器（如nautilus）虽支持U盘自动挂载，但挂载点路径会包含UUID或中文卷标，在终端操作时极易出现乱码，直接干扰后续自动化脚本的执行。

由于终端环境对路径的 固定性和可预测性要求极高，因此决定抛弃文件管理器的默认挂载机制，改用udev接管U盘的插拔事件，自定义挂载/卸载脚本，实现标准化的U盘挂载管理。

实现思路与核心逻辑

首先明确核心实现思路：udev是Linux内核设备管理器的用户空间守护进程，核心负责管理/dev目录下的设备节点，并能在设备插入/移除时触发自定义动作。我们的核心目标是—— U盘插入时自动执行挂载脚本，U盘拔出时自动执行卸载脚本。

需要注意的是，Ubuntu 24.04这类高版本系统中，直接在udev规则里调用shell脚本大概率会失效：一方面udev事件触发的运行环境极度受限，另一方面脚本执行为异步模式，易出现竞争条件导致执行失败。Linux官方推荐的最优方案是 通过systemd服务包装脚本，在udev规则中通过TAG+="systemd"和ENV{SYSTEMD_WANTS}触发服务，让脚本在systemd管理的干净环境中运行，从根本上规避权限、路径等问题。

• /etc/udev/udev.conf：确认udev基础配置，指向正确的规则目录；
• /etc/udev/rules.d/95-usb-mount.rules：编写udev核心规则，捕获U盘分区插拔事件，触发对应systemd服务；
• /etc/systemd/system/mount.service/umount.service：创建两个systemd服务单元，分别承载U盘挂载、卸载逻辑；
• /etc/systemd/system/mount.sh/umount.sh：编写实际的挂载、卸载脚本，由上述systemd服务调用。

分步实操实现方案

以下为分步实现步骤，所有配置命令、脚本代码均经过实际环境验证，直接复制即可使用，仅在格式上做缩进和注释优化，未改动任何核心参数。

# /etc/udev/udev.conf
# 参考udev.conf(5)获取详细配置说明
# udevd会在initrd中启动，修改此文件后建议重建initrd使配置生效
#udev_log=info
#children_max=
#exec_delay=
#event_timeout=180
#timeout_signal=SIGKILL
#resolve_names=early
# 设备根目录
udev_root="/dev/"
# udev规则文件存放目录
udev_rules="/etc/udev/rules.d/"
# 日志级别设为错误，减少冗余日志
udev_log="err"

# /etc/udev/rules.d/95-usb-mount.rules
# 为U盘主设备（sd[a-z]）创建符号链接usb%m，%m为内核次要设备号，保证设备标识唯一
KERNEL=="sd[a-z]", NAME="%k", SYMLINK+="usb%m", OPTIONS="last_rule"
# U盘分区（sd[a-z][0-9]）插入事件：创建符号链接
ACTION=="add", KERNEL=="sd[a-z][0-9]", SYMLINK+="usb%m", NAME="%k"
# U盘分区插入事件：自动创建挂载点目录，路径为/mnt/分区名（如/mnt/sda1）
ACTION=="add", KERNEL=="sd[a-z][0-9]", RUN+="/bin/mkdir -p /mnt/%k"
# U盘分区插入事件：核心触发挂载服务，仅匹配USB块设备，避免识别SATA等本地设备
ACTION=="add",KERNEL=="sd[a-z][0-9]",SUBSYSTEM=="block",ENV{ID_BUS}=="usb",TAG+="systemd", PROGRAM="/bin/systemd-escape -p %k", ENV{SYSTEMD_WANTS}+="mount.service"
# U盘分区移除事件：创建符号链接（保持与插入规则一致性，可省略）
ACTION=="remove", KERNEL=="sd[a-z][0-9]", SYMLINK+="usb%m", NAME="%k"
# U盘分区移除事件：触发卸载服务，仅匹配USB块设备
ACTION=="remove", KERNEL=="sd[a-z][0-9]", SUBSYSTEM=="block", ENV{ID_BUS}=="usb", PROGRAM="/usr/bin/systemctl start umount.service", TAG+="systemd"

# /etc/systemd/system/mount.service
[Unit]
# 服务描述
Description=mountservice
# 服务启动时机：在网络服务后启动（挂载无需网络，仅为通用习惯，可省略）
After=network.target
[Service]
# 服务类型：forking表示脚本会以后台进程模式运行
Type=forking
# 执行用户/用户组：必须为root，挂载/卸载操作需要最高权限
User=root
Group=root
# 工作目录：挂载点根目录
WorkingDirectory=/mnt
# 服务执行命令：调用挂载脚本，--log-target=journal让日志写入systemd日志，可通过journalctl查看
ExecStart=/etc/systemd/system/mount.sh start --log-target=journal
[Install]
# 服务安装目标：多用户模式下启用
WantedBy=multi-user.target

# /etc/systemd/system/umount.service
[Unit]
# 服务描述
Description=umountservice
# 服务启动时机：在网络服务后启动
After=network.target
[Service]
# 服务类型：forking表示脚本会以后台进程模式运行
Type=forking
# 执行用户/用户组：root最高权限
User=root
Group=root
# 工作目录：挂载点根目录
WorkingDirectory=/mnt
# 服务执行命令：调用卸载脚本
ExecStart=/etc/systemd/system/umount.sh start --log-target=journal
[Install]
# 服务安装目标：多用户模式下启用
WantedBy=multi-user.target

chmod 777 /etc/systemd/system/mount.service
chmod 777 /etc/systemd/system/umount.service

#!/bin/bash
# /etc/systemd/system/mount.sh
# U盘自动挂载脚本，挂载路径/mnt/设备名（如/dev/sda1 → /mnt/sda1）
# 初始变量，后续会被遍历结果覆盖
var2="/mnt/sda"
# 遍历所有/dev目录下的USB分区设备
for V in $(ls /dev/sd[a-z][0-9])
do
  # 打印当前设备名（调试用）
  echo $V
  # 赋值当前设备路径给变量
  var2=$V
  # 截取设备名（如从/dev/sda1中截取sda1）
  echo ${var2:5:4}
  # 执行挂载：将设备挂载到/mnt/设备名目录
  /bin/mount $V /mnt/${var2:5:4}
done

#!/bin/sh
# /etc/systemd/system/umount.sh
# U盘自动卸载脚本，检测设备不存在则卸载并删除挂载点
# 定义需监控的USB设备节点
usb_device_1="/dev/sda1"
usb_device_2="/dev/sdb1"
usb_device_3="/dev/sdc1"
usb_device_4="/dev/sdd1"
# 定义设备对应的挂载点目录
mount_dir_1="/mnt/sda1"
mount_dir_2="/mnt/sdb1"
mount_dir_3="/mnt/sdc1"
mount_dir_4="/mnt/sdd1"
# 延时1秒，等待设备彻底移除，避免竞争条件导致卸载失败
sleep 1
# 检测设备1是否存在，不存在则卸载并删除挂载点
if [ ! -e "$usb_device_1" ];then
        umount $usb_device_1 > /dev/null 2>&1
        rm -rf $mount_dir_1 > /dev/null 2>&1
fi
# 检测设备2是否存在，不存在则卸载并删除挂载点
if [ ! -e "$usb_device_2" ];then
        umount $usb_device_2 > /dev/null 2>&1
        rm -rf $mount_dir_2 > /dev/null 2>&1
fi
# 检测设备3是否存在，不存在则卸载并删除挂载点
if [ ! -e "$usb_device_3" ];then
        umount $usb_device_3 > /dev/null 2>&1
        rm -rf $mount_dir_3 > /dev/null 2>&1
fi
# 检测设备4是否存在，不存在则卸载并删除挂载点
if [ ! -e "$usb_device_4" ];then
        umount $usb_device_4 > /dev/null 2>&1
        rm -rf $mount_dir_4 > /dev/null 2>&1
fi

chmod 777 /etc/systemd/system/mount.sh
chmod 777 /etc/systemd/system/umount.sh

# 重载udev规则，让新编写的U盘插拔规则生效
udevadm control --reload-rules
# 重载systemd配置，让新创建的挂载/卸载服务生效
systemctl daemon-reload

验证总结

在飞凌RK3576开发板的Ubuntu 24.04桌面版环境中，经过多次实际插拔测试，该方案可实现 U盘插入自动挂载到/mnt/设备名固定目录，拔出自动卸载并删除挂载点，挂载点路径无任何UUID或中文卷标，彻底解决了默认挂载的乱码问题，完全满足自助终端设备的自动化脚本操作需求。

执行以下调试命令，可验证挂载/卸载服务是否已正常启用：

# 查看挂载服务启用状态
systemctl is-enabled mount.service
# 查看卸载服务启用状态
systemctl is-enabled umount.service

正常情况下，两个命令的输出均为enabled，表示服务已成功启用并随系统开机自启。

经验反思

本次基于udev+systemd实现U盘自动挂载，踩过了高版本Ubuntu的环境坑，也积累了嵌入式Linux外设管理的实用经验，核心总结三点：

对于飞凌嵌入式RK3576开发板，Ubuntu 24.04桌面版的整体运行表现稳定，结合udev的设备事件监听和systemd的服务管理，可灵活定制USB、串口、网卡等各类外设的自动处理逻辑。本次U盘自动挂载的改造方案，也为后续嵌入式项目中的外设管理提供了可直接复用的模板。

华北区负责人

华东区负责人

华南区负责人

中西区负责人

产品简介

RK3576工业级开发板采用核心板与底板分离的架构设计。其核心部分搭载了瑞芯微RK3576系列处理器，该处理器采用先进的8nm制程工艺，集成了4个ARM Cortex-A72和4个ARM Cortex-A53核心，并内置了算力高达6TOPS的神经网络处理单元（NPU）。底板则引出了处理器的几乎所有功能接口，方便开发者进行各项功能验证和外围设备扩展。

该开发板的一大特点是提供了工业级（-40℃~+85℃）和商业级（0℃~+80℃）两种温度版本选择，以满足不同应用场景的需求。核心板通过高可靠性板对板连接器与底板相连，这种可插拔设计不仅便于安装维护，也为产品的未来升级提供了便利。飞凌嵌入式为该系列产品承诺10至15年的生命周期，为工业产品的长期稳定供应提供了保障。

OK3576-C开发板正面视图

FET3576-C核心板

核心特性

技术规格

RK3576工业级开发板由FET3576-C系列核心板和OK3576-C底板组成，主要规格参数如下：

FET3576-C核心板基础参数

FET3576-C核心板功能参数

Video Port说明

OK3576-C开发板功能参数

应用领域

华北区负责人

华东区负责人

华南区负责人

中西区负责人

飞凌嵌入式边缘AI核心板：全谱系算力无断档 筑牢“人工智能+”硬件根基

民建中央在提案调研中发现，人工智能与实体经济融合发展仍面临产业生态待优化、行业要素市场体系不健全等问题，其中不同行业、不同场景对AI算力的差异化需求，是企业落地AI应用的首要门槛。针对这一核心痛点，飞凌嵌入式精准布局，打造了从0.5TOPS轻量级端侧算力到32TOPS可扩展旗舰级算力的全梯度嵌入式AI核心板产品矩阵，实现算力覆盖无断档、场景适配无盲区，精准匹配企业对“工业级AI核心板”“不同算力AI核心板”的核心需求，让不同规模、不同领域的客户都能找到性能与成本的最优契合点。

旗舰级重载算力场景解决方案

在智慧交通、城市级安防、工业AI质检等需要处理海量数据、运行复杂模型的重载算力场景，飞凌嵌入式旗舰级AI硬件解决方案表现突出。

工业智能化主流场景核心板

在市场需求较旺盛、应用较广泛的工业智能化主流场景，飞凌嵌入式多款嵌入式AI核心板经海量项目验证，覆盖0.5TOPS-2.3TOPS算力区间。

端侧AI计算赛道专用核心板

在端侧AI计算赛道，飞凌FET1126BJ-S核心板基于瑞芯微RV1126处理器打造，助力端侧智能场景创新。

飞凌嵌入式：深耕工业基因 破解AI产业落地核心痛点

“人工智能+”行动的核心是让AI技术扎根产业现场，而工业场景的严苛环境、复杂协议、长周期运行要求，是AI落地的核心挑战。飞凌嵌入式以工业基因为产品研发核心底色，从硬件设计到软件支持，全方位破解企业AI应用落地痛点，助力优化人工智能产业生态，让更多企业敢用AI、用好AI。

工业级硬件品质与长周期保障

在硬件品质上，飞凌嵌入式全系嵌入式AI核心板均通过严苛工业环境测试，绝大多数产品支持-40℃~+85℃宽温运行，可稳定适配高温、高湿、强电磁干扰的极端工业环境；同时承诺10-15年产品生命周期供应保障，有效解决客户量产后面临的器件停产、项目停滞难题，精准匹配工业设备长周期运行特性。

接口设计上，每款核心板接口资源丰富，PCIe、SATA、USB3.0等高速接口与CAN-FD、多路UART等工业现场总线全面覆盖，支持TSN时间敏感网络、IEEE 1588精密时钟协议，最大程度减少客户底板设计限制，实现与各类工业设备的无缝对接。

全栈式技术支持与产业生态赋能

在产业生态赋能上，飞凌嵌入式不止于提供高品质嵌入式AI硬件产品，更打造全栈式技术支持体系，大幅降低企业AI应用落地门槛。

全系产品均提供稳定的Linux、Android等系统级软件支持，配套完整的BSP开发包、内核源码与驱动程序，兼容TensorFlow、PyTorch等主流深度学习框架，同时提供完善的开发文档、参考设计与测试用AI算法例程；专业技术支持团队全程跟进，提供从方案咨询、开发指导到问题排查的全流程服务，将客户从复杂的底层驱动和系统移植工作中解放出来，让企业能够专注于上层应用与行业算法创新，大幅缩短研发周期、降低落地成本。

飞凌嵌入式AI核心板 千行百业落地实践 赋能实体经济高质量发展

从民建中央提案建言到国家政策落地实施，“人工智能+”行动的最终价值，体现在千行百业的智能化转型成果中。飞凌嵌入式嵌入式AI核心板产品，已深度渗透工业制造、智慧交通、智能安防、电力能源、医疗健康、金融科技等数十个行业，成为万千智能设备的核心“大脑”，用实打实的落地成果践行“人工智能赋能千行百业”的时代使命。

人工智能+制造 智能制造核心中枢

在“人工智能+制造”主战场上，飞凌嵌入式AI核心板成为智能制造的重要中枢。飞凌FETMX8MP-C核心板嵌入工业检测设备，实现生产线上零件缺陷的实时检测与亚像素级精密尺寸测量，助力提升产品良品率；飞凌FET536-C核心板作为AGV/AMR机器人的主控核心，同步处理导航传感器数据与多路电机控制，助力提升工厂物流自动化效率；飞凌FET3588-C核心板部署在大型产线末端，实现多台高清工业相机的图像并行分析，完成高速缺陷检测与分类，为工业质检提供智能支撑。

智慧城市与智能安防 核心赋能

在智慧城市与智能安防领域，飞凌嵌入式产品发挥核心赋能作用。飞凌FCU3501边缘计算盒子部署在城市路口，成为智慧交通边缘智能中枢，实时完成车牌识别、交通流量分析与信号联动，提升城市交通管理效率；飞凌FET1126BJ-S核心板嵌入各类监控终端，实现安全帽佩戴检测、烟火告警、违规行为识别等功能，筑牢安全生产防线；飞凌FET3588-C核心板打造的高端智能NVR，可同时对多路4K/8K视频流进行人、车、物实时识别与行为分析，为城市级安防体系提供核心算力支撑。

关键行业智能化升级 持续赋能

在电力、医疗、金融等关键行业，飞凌嵌入式AI产品持续赋能行业智能化升级。飞凌FET536-C核心板打造的智能电力网关，在配电网自动化中实现设备数据采集与本地故障识别，助力新型电力系统建设；飞凌FET3576-C核心板凭借硬件隔离特性与强劲AI算力，赋能高端医疗影像终端，辅助医生完成医学影像分析与诊断，提升诊疗效率；飞凌FET3562-C全国产化核心板，广泛应用于金融自助终端与安全设备，实现安全的人证比对与票据识别，为金融行业自主可控与智能化升级保驾护航。

华北区负责人

华东区负责人

华南区负责人

中西区负责人

从核心硬件研发到行业方案定制，从本土技术深耕到全球市场布局，飞凌嵌入式始终以技术创新为核心，以客户需求为导向，不断打造高品质的嵌入式产品与解决方案。让我们相聚embedded world 2026，飞凌嵌入式期待与全球合作伙伴携手共进，探索嵌入式技术的无限可能。

华北区负责人

华东区负责人

华南区负责人

中西区负责人

JTAG调试技术核心优势

JTAG（Joint Test Action Group）调试技术是一种广泛应用于嵌入式系统开发和硬件测试的国际标准技术，它具备深度交互与实时控制能力，可在线设置断点、执行单步调试，同时支持实时查看并修改寄存器与变量值；更关键的是，其非侵入式调试模式无需在代码中插入打印语句，能最大程度保留程序原有逻辑与运行性能，且可随时暂停CPU，精准捕捉任一时刻的系统完整状态，快速定位各类复杂调试难题。

方案架构：一体化JTAG调试生态

这里我们用飞凌嵌入式基于RK3568处理器设计开发的OK3568-C开发板进行演示。

飞凌嵌入式实现的方案基于完整的工具链整合，在Windows环境下提供无缝调试体验。系统架构分为三个关键层次：开发主机层、硬件接口层和目标设备层。

这一架构的核心优势在于高度集成与透明化，开发者无需关注底层通信细节，可专注于代码逻辑和问题定位。

调试实战：可视化的问题定位流程

以上这套AMP多核协同场景下的JTAG调试方案显著地降低了实时核调试技术的使用门槛。将调试工作可视化，可同时监控AMP实时核状态，让程序跳转、任务切换等动作变得更加清晰，希望这套方案能够对您有所帮助。

华北区负责人

华东区负责人

华南区负责人

中西区负责人

在人工智能技术飞速迭代、物联网设备全面普及的今天，边缘AI已从技术概念深度走进产业实践，成为连接AI算法与终端场景的核心纽带。很多人会疑惑：边缘AI是什么？它和传统云端AI有什么核心区别？为何能快速成为工业、医疗、交通等领域的刚需技术？更关键的是，边缘AI落地该如何选型适配的硬件？本文将从边缘AI的核心定义、工作原理、核心优势、主流应用场景及发展趋势全面拆解，同时结合飞凌嵌入式全场景边缘AI硬件产品矩阵，详解边缘AI落地选型思路与实践路径，让你一文读懂边缘AI的核心价值，轻松选对适配的边缘AI硬件。

一、边缘AI核心认知：定义与工作原理

1. 边缘AI是什么？核心定义与基础逻辑

边缘AI，全称边缘人工智能（Edge Artificial Intelligence），是将人工智能算法、模型训练与推理能力，部署在靠近数据产生源头的“边缘设备”上，而非依赖远端的云端数据中心，实现数据本地采集、实时处理、快速决策的一种新型AI技术形态。简单来说，边缘AI就是让AI“走出云端数据中心”，下沉到手机、智能摄像头、工业传感器、自动驾驶车载设备等终端硬件上，让终端设备具备自主的智能分析和决策能力，无需频繁与云端进行数据交互。

边缘AI核心关键点拆解：

• 核心载体：边缘设备（终端硬件），包括工业网关、智能摄像头、可穿戴设备、车载终端、物联网传感器等，是边缘AI运行的基础；
• 核心能力：数据本地处理、实时推理决策，无需依赖云端，即使在网络中断、带宽不足的场景下，也能正常运行；
• 核心逻辑：“数据在哪里，AI就在哪里”，减少数据传输环节，解决云端AI延迟高、带宽消耗大、隐私泄露风险高的痛点；
• 与云端AI的关系：并非对立，而是互补共生——云端AI侧重大规模模型训练、海量数据存储与模型迭代优化，边缘AI侧重本地实时推理、数据隐私保护，二者协同形成“云边协同”的完整AI架构，兼顾效率与安全。

在边缘AI的产业落地中，核心板与边缘计算设备是承载AI能力的关键硬件载体。飞凌嵌入式凭借20年工业级产品设计经验，构建了从0.5TOPS轻量算力到32TOPS旗舰级可扩展算力的完整边缘AI硬件产品矩阵，覆盖从低端传感器终端到高端边缘智能服务器的全场景需求，让不同行业、不同规模的企业都能找到适配自身场景的边缘AI硬件解决方案，真正推动边缘AI从概念走向规模化落地。

2. 边缘AI的工作原理：从模型适配到本地闭环

边缘AI的工作流程并不复杂，核心分为3个核心步骤，而飞凌嵌入式全系列产品均针对这一核心流程完成了深度优化，大幅降低边缘AI的开发与部署门槛。

（1）边缘AI模型轻量化适配：端侧部署的核心前提

云端训练好的大型AI模型（如深度学习模型），需要通过量化、剪枝、蒸馏等技术优化进行“轻量化压缩”，在保留核心推理能力的前提下删减冗余参数，才能适配边缘设备有限的算力、存储硬件资源。例如Llama-3-7B通过动态稀疏激活技术，在参数量减少70%的情况下保持核心推理质量，可轻松部署在普通边缘设备上。

边缘AI的落地，核心前提是模型能在端侧硬件上流畅稳定运行，飞凌嵌入式全系AI核心板均针对边缘AI主流深度学习框架完成了深度适配与优化。其中FET1126BJ-S核心板基于瑞芯微RV1126BJ处理器打造，不仅完美兼容TensorFlow、PyTorch、Caffe等主流AI框架，还直接提供成熟的边缘侧AI算法例程，配合完整的BSP支持包，可帮助开发者快速完成边缘AI轻量化模型的移植与部署。该核心板内置3TOPS@INT8算力的独立NPU，可在保留边缘AI模型核心推理能力的前提下，完美适配各类压缩后的轻量化AI模型，让端侧设备轻松承载边缘AI智能推理任务。

（2）边缘AI本地数据采集与处理：数据不出端的核心逻辑

边缘设备（如智能摄像头、工业传感器）实时采集现场数据（图像、声音、设备运行参数、生命体征等），采集完成后，直接在设备本地运行轻量化AI模型，对数据进行实时分析、识别与推理，无需将原始数据上传至云端。比如上海某CBD的边缘AI摄像头，可本地采集视频数据并运行YOLOv8模型，实时识别异常行为，无需依赖云端算力。

这一能力的实现，高度依赖边缘硬件的算力与图像处理能力。飞凌嵌入式FET1126BJ-S核心板搭载高性能ISP与VPU，支持4K@30fps超清视频解码、12M@30fps编码输出，可同时接入多路高清摄像头采集视频流，并本地流畅运行YOLOv8等目标检测模型，实时完成异常行为识别、人脸检测、烟火告警等边缘AI推理任务，无需将原始视频数据上传至云端，真正实现“数据在哪里，AI就在哪里”的边缘AI核心逻辑。

（3）边缘AI本地决策与反馈：毫秒级闭环的核心价值

AI模型在边缘设备上完成数据推理后，直接输出决策结果，并控制边缘设备执行相应操作，同时仅将关键决策数据（而非原始数据）上传至云端，用于后续模型优化。整个过程耗时可缩短至毫秒级，实现“采集-处理-决策-反馈”的完整闭环，这也是边缘AI最核心的优势所在。例如急诊科边缘AI系统，可本地处理CT影像并快速判断脑出血情况，30秒内即可输出结果，为救治争取黄金时间。

要实现毫秒级的端到端闭环，需要边缘硬件具备算力、实时性与稳定性的三重保障。飞凌嵌入式FET3588-C核心板作为旗舰级边缘AI硬件，搭载6TOPS算力的三核独立NPU，支持INT4/INT8/INT16/FP16混合精度运算，可在本地快速完成医疗影像、工业缺陷图像等复杂数据的推理分析，最短可在数十毫秒内输出决策结果，完美适配紧急医疗、工业实时控制等对响应速度有极致要求的边缘AI场景。同时，其仅将关键决策数据上传云端用于模型迭代，既实现了实时闭环控制，也兼顾了边缘AI模型的持续优化。

二、边缘AI核心价值：5大优势与全场景应用

1. 边缘AI的核心优势：对比云端AI的5大核心价值

边缘AI之所以能快速普及，核心是解决了云端AI在实际应用中的诸多痛点，其优势精准贴合工业、医疗、交通等行业的核心需求，而飞凌嵌入式的产品矩阵，更是将这些优势转化为了可落地、可复制的边缘AI行业解决方案。

2. 边缘AI的主流应用场景：全行业落地实践详解

边缘AI的优势决定了其应用场景极具广泛性，已深度渗透到工业、医疗、交通、零售、农业等多个领域，而飞凌嵌入式针对不同行业的场景特性，打造了专属的边缘AI硬件解决方案，全面赋能千行百业的智能化转型。

三、边缘AI发展趋势与落地选型指南

1. 边缘AI的发展趋势：未来4大核心方向

随着物联网、人工智能、芯片技术的持续迭代，边缘AI正朝着“更高效、更智能、更普惠”的方向发展，未来几年将迎来爆发式增长，而飞凌嵌入式也始终紧跟行业趋势，持续推动边缘AI技术的落地与创新。

2. 边缘AI硬件选型指南：飞凌嵌入式全场景产品矩阵

结合边缘AI的技术特性与场景需求，整理飞凌嵌入式边缘AI硬件选型对照表，覆盖全场景需求，帮助用户快速选对适配的边缘AI硬件：

四、总结：边缘AI的核心价值与未来意义

综上，边缘AI并非简单的“AI+边缘设备”，而是一种以“本地实时处理、隐私安全保障、低成本落地”为核心的新型AI技术形态，核心解决了云端AI延迟高、带宽消耗大、隐私泄露风险高的痛点，实现了AI技术从“云端”到“终端”的下沉，让AI真正走进产业实践、融入日常生活。

而飞凌嵌入式作为嵌入式行业的领军企业，凭借完整的边缘AI硬件产品矩阵、深厚的工业级设计经验与全栈式技术支持，为边缘AI技术的规模化落地提供了坚实的硬件基石。从0.5TOPS到32TOPS的无断档算力覆盖，从消费级智能家居到工业级智能制造的全场景适配，飞凌嵌入式始终致力于将前沿的芯片算力，转化为客户可快速部署、稳定运行的边缘智能解决方案，助力千行百业实现数字化、智能化转型。

作为连接AI算法与终端场景的核心纽带，边缘AI的发展不仅推动了人工智能、物联网技术的深度融合，更助力各行业实现数字化、智能化转型，提升生产效率、降低运营成本、保障数据安全。未来，随着技术的持续迭代，边缘AI将渗透到更多细分场景，成为数字经济时代的核心基础设施，也将成为AI技术发展的重要趋势，值得我们持续关注与探索。

华北区负责人

华东区负责人

华南区负责人

中西区负责人

瑞芯微系列开发板支持上电显示LOGO并持续展示至应用启动，默认搭载飞凌嵌入式官方LOGO，用户可根据客制化需求完成LOGO与开机动画的替换，以下为瑞芯微系列（RK3588/RK3576/RK3568/RK3562）全平台、全系统的详细配置与修改方法。

一、系统LOGO显示基础配置修改

瑞芯微系列开发板的LOGO均通过各平台SDK中kernel目录下的logo.bmp和logo_kernel.bmp两个位图文件配置，直接替换该文件夹下的同名文件即可完成LOGO修改， 文件命名必须严格为logo.bmp和logo_kernel.bmp，不可更改。

二、系统LOGO显示效果调整

（一）LOGO旋转

暂不支持通过系统配置实现LOGO旋转，需提前修改原始BMP文件的显示方向，以此达到LOGO旋转的展示效果。

（二）LOGO显示模式选择

瑞芯微开发板在uboot和kernel两个启动阶段，会分别调用上述两张BMP图，默认采用center居中显示模式，可修改为fullscreen全屏显示模式，需通过各平台对应的dtsi文件配置，以RK3568开发板为例：

修改arch/arm64/boot/dts/rockchip/rk3568.dtsi文件中，panel节点下的LOGO显示模式相关配置即可，核心配置片段如下：

route_dsio: route-dsio{
status = "disabled";
Logo,uboot ="Logo.bmp";
Logo,kernel ="Logo kernel.bmp";
Logo,mode ="center";
charge_Logo,mode="center";
connect=<&vp0_out_dst0>;
};
route_dsi1:route-dsi1{
status = "disabled";
Logo,uboot="Logo.bmp";
Logo,kernel ="Logo_kernel.bmp";
logo,mode ="center";
charge_Logo,mode = "center";
connect=<&vpo_out_dsi1>;
};
route_edp:route-edp{
status = "disabled";
Logo,uboot="Logo.bmp";
Logo,kernel="Logo_kernel.bmp";
logo,mode ="center";
charge_Logo,mode ="center";
connect=<&vpo_out_edp>;
};

（三）显示模式选型建议

BMP格式为无压缩图片，不同显示模式和图片分辨率会影响展示效果与系统镜像大小，具体注意事项如下：

1. center居中模式：小分辨率图片的非LOGO区域会以黑色填充，建议更换的LOGO图统一使用黑色背景；
2. fullscreen全屏模式：图片会出现明显的缩放模糊效果；
3. 大分辨率图片会导致kernel镜像体积过大，造成冗余。

飞凌嵌入式公司推荐采用 小分辨率、黑色背景、居中显示的组合方案。

三、系统LOGO图片格式规范

替换的LOGO图片需严格遵循以下格式要求，否则会导致展示异常甚至系统崩溃：

1. 若使用PS工具转换BMP图，需选择 Windows格式、 24位深，并勾选 反转行序；
2. 图片分辨率建议不超过1080P，若分辨率过高会导致boot镜像过大，需同步修改EMMC分区大小，否则烧写过程会报错（编译环节可正常执行）；
3. 因VOP虚宽以word为单位，RK全平台要求LOGO图片按4byte对齐，其中356x平台需满足 分辨率位宽为4pixel对齐，否则启动过程中可能出现概率性系统崩溃，崩溃打印关键信息为rk_iommu Page fault；
4. 图片位深仅支持8bit、16bit、24bit、32bit四种，若需减小图片体积，可在该范围内调整位深。

四、瑞芯微各型号开发板用户层LOGO替换方案

部分型号开发板支持在用户空间直接更换开机LOGO，无需修改源码并重新编译烧写，核心为新增LOGO分区并配置相关脚本/文件，各型号具体实现方法详见飞凌嵌入式在线文档中的 《瑞芯微平台开发手册》，关键信息如下：

1. OK3568（4.19.206 Buildroot）：以patch格式在源码中修改，新增boot分区并创建开机自启脚本，脚本可检测U盘内的LOGO图片，自动读取并生成logo.img镜像，通过dd命令烧写至LOGO分区； 点击查阅
2. OK3576（6.1.75 Android14）：基于OK3576-C_Android14_用户资料_R1修改，因uboot源码不开源，提供编译好的uboot.img直接使用；若更新用户资料版本，需先验证后再部署；点击查阅
3. OK3562（5.10.198 Buildroot）：添加独立LOGO分区，后续可直接在开发板端完成LOGO图片更换，操作无需依赖源码编译。 点击查阅

五、开机动画修改方法

Buildroot和Forlinx Desktop系统默认无开机动画，可通过内核进程绘制实现动画效果， 注意：该方法会增加系统启动时间；Android系统则支持通过专用动画文件配置开机动画，各系统具体实现如下：

（一）Buildroot系统添加LOGO动画效果（以OK3568 4.19.206 Buildroot为例）

需先将启动动画的连续图片转换为指定的ppm格式，转换步骤如下：

1. 若为PNG格式：pngtopnm logo.png > logo.pnm
2. 若为BMP格式：bmptopnm logo.bmp > logo.pnm
3. 颜色量化：pnmquant 224 logo.pnm > logo224.pnm
4. 转换为目标格式：pnmtoplainpnm logo224.pnm > logo_linux_clut224.ppm

具体后续配置详见 《瑞芯微平台开发手册》。点击查阅

（二）Android系统开机动画修改（以OK3568 4.19.193 Android11为例）

1. 动画核心文件：开机动画由bootanimation.zip压缩包实现，包含part0文件夹和desc.txt文件两部分；
2. part0文件夹：存放与屏幕分辨率一致的动画图片，图片命名需按数字递增排序；
3. 关键注意事项：图片位深需严格控制，经测试高位深（32位深）会导致动画无画面，默认推荐使用8位深；

具体配置与文件制作方法详见 《瑞芯微平台开发手册》。点击查阅

华北区负责人

华东区负责人

华南区负责人

中西区负责人

1. 方案概述

本文所提供的源码修改内容，均以 patch格式标准化呈现（便于团队复用、版本管控及协同开发），其核心实现逻辑清晰明确：

2. 源码修改方法

2.1 解决措施

针对上述问题，需手动创建对应空文件夹，且文件夹路径需与后续配置参数严格保持一致，确保编译流程顺畅：

# 赋予读写执行权限（所有者、组用户、其他用户均有执行权限）
mkdir -p logo/logo_normal

2.2 虚拟机源码修改

（1）配置logo分区挂载

buildroot/board/rockchip/ok3568/fs-overlay-recovery/etc/fstab

作用：新增logo分区挂载规则，将logo分区精准挂载至/mnt/logo目录，为系统访问logo分区搭建便捷通道。

diff --git a/buildroot/board/rockchip/ok3568/fs-overlay-recovery/etc/fstab b/buildroot/board/rockchip/ok3568/fs-overlay-recovery/etc/fstab
index bb97eaf92..b5e92e026 100644
--- a/buildroot/board/rockchip/ok3568/fs-overlay-recovery/etc/fstab
+++ b/buildroot/board/rockchip/ok3568/fs-overlay-recovery/etc/fstab
@@ -9,5 +9,6 @@ sysfs /sys sysfs defaults 0 0
 /dev/block/by-name/misc /misc emmc defaults 0 0
 /dev/block/by-name/userdata /userdata ext2 defaults 0 0
 /dev/block/by-name/oem /oem ext2 defaults 0 0
+# 新增logo分区挂载：设备节点为/dev/block/by-name/logo，挂载点/mnt/logo，文件系统ext2
+/dev/block/by-name/logo /mnt/logo ext2 defaults 0 2
 /dev/sda1 /mnt/usb_storage vfat defaults 0 0
 /dev/mmcblk1p1 /mnt/sdcard vfat defaults 0 0

（2）修改固件生成脚本

device/rockchip/common/mkfirmware.sh

作用：新增logo镜像生成逻辑，实现logo.img镜像的自动化构建，同时将其纳入固件包。

diff --git a/device/rockchip/common/mkfirmware.sh b/device/rockchip/common/mkfirmware.sh
index cc07d7a1b..5a1328a12 100755
--- a/device/rockchip/common/mkfirmware.sh
+++ b/device/rockchip/common/mkfirmware.sh
@@ -4,8 +4,11 @@ set -e
 
 SCRIPT_DIR=$(dirname $(realpath $BASH_SOURCE))
 TOP_DIR=$(realpath $SCRIPT_DIR/../../..)
+# 定义logo目录路径：拼接源码根目录与配置文件中指定的RK_LOGO_DIR（logo_normal）
+LOGO_DIR=$TOP_DIR/device/rockchip/logo/$RK_LOGO_DIR
 cd $TOP_DIR
 
 # （原有函数逻辑保持不变）
@@ -268,6 +271,27 @@ then
     fi
 fi
 
+# 新增logo镜像生成逻辑
+# 定义logo镜像生成脚本路径
+LOGO_FAKEROOT_SCRIPT=$ROCKDEV/logo.fs
+if [ $RK_LOGO_DIR ] # 判断是否配置了logo目录（从BoardConfig中读取）
+then
+    if [ -d "$LOGO_DIR" ] # 检查logo目录是否存在
+    then
+        # 创建logo镜像生成脚本
+        echo "#!/bin/sh" > $LOGO_FAKEROOT_SCRIPT
+        echo "set -e" >> $LOGO_FAKEROOT_SCRIPT # 脚本执行出错时立即退出
+        if [ "$RK_LOGO_FS_TYPE" = "ubi" ]; then # 判断logo分区文件系统类型
+            # UBI文件系统：调用mkimage工具生成带指定参数的logo镜像
+            echo "$MKIMAGE $LOGO_DIR $ROCKDEV/logo.img $RK_LOGO_FS_TYPE $RK_LOGO_PARTITION_SIZE logo $RK_UBI_PAGE_SIZE $RK_UBI_BLOCK_SIZE" >> $LOGO_FAKEROOT_SCRIPT
+        else
+            # 非UBI文件系统（本文为ext2）：生成基础logo镜像
+            echo "$MKIMAGE $LOGO_DIR $ROCKDEV/logo.img $RK_LOGO_FS_TYPE " >> $LOGO_FAKEROOT_SCRIPT
+        fi
+        chmod a+x $LOGO_FAKEROOT_SCRIPT # 赋予脚本可执行权限
+        $FAKEROOT_TOOL -- $LOGO_FAKEROOT_SCRIPT # 执行脚本生成镜像
+        rm -f $LOGO_FAKEROOT_SCRIPT # 清理临时脚本
+    else
+        echo "warning: $LOGO_DIR not found!" # 目录不存在时输出警告
+    fi
+fi
+
 if [ -f $UBOOT_IMG ]
 then
     echo -n "create uboot.img..."

（3）添加logo分区配置

device/rockchip/ok3568/BoardConfig-ok3568.mk

作用：精准配置logo分区的文件系统类型、目录名称、分区大小等核心参数。

diff --git a/device/rockchip/ok3568/BoardConfig-ok3568.mk b/device/rockchip/ok3568/BoardConfig-ok3568.mk
index 74c2fff2d..202efa5ff 100644
--- a/device/rockchip/ok3568/BoardConfig-ok3568.mk
+++ b/device/rockchip/ok3568/BoardConfig-ok3568.mk
@@ -46,12 +46,17 @@ export RK_RAMBOOT_TYPE=
 export RK_OEM_FS_TYPE=ext2
 # Set userdata partition type, including ext2, fat
 export RK_USERDATA_FS_TYPE=ext2
+# 配置logo分区文件系统类型（与挂载配置一致为ext2）
+export RK_LOGO_FS_TYPE=ext2
 #OEM config
 export RK_OEM_DIR=oem_normal
 # OEM build on buildroot
 #export RK_OEM_BUILDIN_BUILDROOT=YES
 #userdata config
 export RK_USERDATA_DIR=userdata_normal
+# logo分区核心配置
+export RK_LOGO_DIR=logo_normal # logo文件存放目录（需与实际创建的文件夹名称一致）
+export RK_LOGO_PARTITION_SIZE=0x0000a000 # logo分区大小（以512字节存储块为单位：0x0000a000×512=20MB）
 #misc image
 export RK_MISC=wipe_all-misc.img
 #choose enable distro module

（4）修改eMMC分区表

device/rockchip/ok3568/parameter-buildroot-fit.txt

作用：在eMMC分区表中新增20M大小的logo分区，同步微调userdata分区的起始地址，有效规避分区重叠问题。

diff --git a/device/rockchip/ok3568/parameter-buildroot-fit.txt b/device/rockchip/ok3568/parameter-buildroot-fit.txt
index 17d6da32b..3c5f175d9 100644
--- a/device/rockchip/ok3568/parameter-buildroot-fit.txt
+++ b/device/rockchip/ok3568/parameter-buildroot-fit.txt
@@ -8,5 +8,5 @@ MACHINE: 0xffffffff
 CHECK_MASK: 0x80
 PWR_HLD: 0,0,A,0,1
 TYPE: GPT
-CMDLINE: mtdparts=rk29xxnand:0x00002000@0x00004000(uboot),0x00002000@0x00006000(misc),0x00010000@0x00008000(boot),0x00010000@0x00018000(recovery),0x00010000@0x00028000(backup),0x00c00000@0x00038000(rootfs),0x00040000@0x00c38000(oem),-@0x00c78000(userdata:grow)
+# 新增logo分区：大小0x0000a000（20MB），起始地址0x00c78000（接续oem分区）；userdata分区起始地址调整为0x00c82000（0x00c78000+0x0000a000）
+CMDLINE: mtdparts=rk29xxnand:0x00002000@0x00004000(uboot),0x00002000@0x00006000(misc),0x00010000@0x00008000(boot),0x00010000@0x00018000(recovery),0x00010000@0x00028000(backup),0x00c00000@0x00038000(rootfs),0x00040000@0x00c38000(oem),0x0000a000@0x00c78000(logo),-@0x00c82000(userdata:grow)
 uuid:rootfs=614e0000-0000-4b53-8000-1d28000054a9

（5）添加logo镜像到固件包

tools/linux/Linux_Pack_Firmware/rockdev/rk356x-package-file

作用：将自动化生成的logo.img镜像纳入固件打包列表，确保固件烧录过程中，logo镜像可同步写入eMMC的logo分区。

diff --git a/tools/linux/Linux_Pack_Firmware/rockdev/rk356x-package-file b/tools/linux/Linux_Pack_Firmware/rockdev/rk356x-package-file
index 4cad31ed5..dfaa54157 100644
--- a/tools/linux/Linux_Pack_Firmware/rockdev/rk356x-package-file
+++ b/tools/linux/Linux_Pack_Firmware/rockdev/rk356x-package-file
@@ -13,6 +13,7 @@ boot Image/boot.img
 recovery Image/recovery.img
 rootfs Image/rootfs.img
 oem Image/oem.img
+logo Image/logo.img # 新增logo镜像打包配置
 userdata Image/userdata.img

2.3 创建开机自启脚本

（1）新建脚本文件

buildroot/board/rockchip/ok3568/fs-overlay/etc/init.d/S99logo

脚本功能：系统开机后，自动检测U盘内指定路径的logo图片，若成功检测到目标图片，将自动完成logo镜像的生成与logo分区的烧录操作，同时创建标志文件，有效避免重复烧录。

#!/bin/sh
# 检测U盘logo文件并烧录的核心函数
check_sdcard() {
    while true; do # 循环检测（确保U盘挂载完成）
        sleep 1 # 每秒检测一次，降低系统资源占用
        # 判断U盘是否挂载且存在指定logo文件夹（路径需与U盘实际存放logo文件的文件夹路径保持一致）
        if [[ -d "/run/media/sda1/Forlinx_logo" ]]; then
            cd "/run/media/sda1/Forlinx_logo"
            # 检测标志文件：存在则说明已烧录，直接退出循环
            if [[ -f "Forlinx_logo_flag" ]]; then
                echo "Forlinx_logo_flag file exists, skip reflashing."
                break
            else
                # 检测是否同时存在uboot和kernel阶段的logo文件（二者缺一不可）
                if [[ -f "logo.bmp" && -f "logo_kernel.bmp" ]]; then
                    # 合并logo文件生成镜像（uboot logo在前，kernel logo在后）
                    cat "logo.bmp" > "logo.img"
                    # 镜像文件按512字节对齐（适配分区存储块大小）
                    truncate -s %512 "logo.img"
                    cat "logo_kernel.bmp" >> "logo.img"
                    # 烧录镜像至logo分区（of参数为logo分区设备节点）
                    dd if="logo.img" of="/dev/block/by-name/logo"
                    echo "Logo files flashed to /dev/block/by-name/logo successfully."
                    touch "Forlinx_logo_flag" # 创建标志文件，避免重复烧录
                    break; # 烧录完成，退出循环
                else
                    echo "Error: Missing logo.bmp or logo_kernel.bmp in the U盘."
                fi
            fi
        fi
    done
}
# 脚本入口：仅在start参数下执行烧录逻辑（符合init.d脚本规范）
case "$1" in
    start)
        check_sdcard & # 后台运行检测函数，不阻塞系统启动
        ;;
    *)
        exit 1 # 非start参数直接退出
        ;;
esac

（2）赋予脚本可执行权限

在终端执行以下命令，为脚本配置可执行权限：

# 赋予读写执行权限（所有者、组用户、其他用户均有执行权限）
chmod 775 S99logo

（3）编译烧录

所有修改配置操作全部完成后，执行全编译命令生成新固件，将新固件重新烧录至开发板，即可完成整套logo替换功能的配置工作，具体编译命令如下：

# 全编译（根据实际编译脚本调整，此处为常规命令示例）
make clean && make

3. 验证方法

3.1 准备logo文件

3.2 U盘配置

3.3 烧录验证步骤

3.4 重新替换logo

若RK3568开发板需更换新的开机logo，只需手动删除U盘中Forlinx_logo文件夹内的Forlinx_logo_flag文件，替换文件夹内的logo.bmp和logo_kernel.bmp两张图片后，重复上述重启验证步骤，即可完成新logo的替换，操作便捷高效。

咨询立即获得专属报价

联系销售 | 报价咨询 | 索取样品

华北区负责人

华东区负责人

华南区负责人

中西区负责人

本文为 OK3568-C开发板（基于瑞芯微RK3568处理器设计） 4.19.206 Buildroot 环境下添加内核 Logo 动画的实操指南，聚焦RK3568开发板启动 Logo 动画的完整实现流程。从动画帧图片的格式转换与重命名，到文件部署至内核指定目录，再到 Makefile、logo.c 等核心文件的配置修改，最后完成编译验证，步骤清晰且实操性强，按指引操作可实现 25 帧居中循环、每帧延时 50ms 的 Logo 动画效果。

一、准备工作：图片格式转换

需提前准备动画所需的 连续序列图片（建议 25 张，对应动画帧 00-24），并按以下命令转换为内核支持的 ppm 格式：

1.1 PNG格式转换

若图片为 PNG 格式，使用以下命令转换：

pngtopnm logo.png > logo.pnm

1.2 BMP格式转换

若图片为 BMP 格式，使用以下命令转换：

bmptopnm logo.bmp > logo.pnm

1.3 统一转为224色ppm格式

将转换后的图片统一处理为内核支持的224色ppm格式：

pnmquant 224 logo.pnm > logo224.pnm
pnmtoplainpnm logo224.pnm > logo_linuxXX_clut224.ppm

二、文件部署：拷贝至内核指定目录

将转换后的 25 张logo_linuxXX_clut224.ppm图片，拷贝到内核源码的 logo 驱动目录：

图1：内核logo目录文件部署结构

OK3568-linux-source/kernel/drivers/video/logo/

三、配置修改：核心文件编辑

（一）修改 Makefile（编译规则添加）

编辑 Makefile，添加新增图片的编译规则，确保 25 帧图片被内核编译：

OK3568-linux-source/kernel/drivers/video/logo/Makefile

图2：Makefile中添加25帧图片编译规则

（二）修改 logo.c（帧切换逻辑）

编辑 logo.c，修正语法错误并添加帧序列匹配逻辑：

OK3568-linux-source/kernel/drivers/video/logo/logo.c

diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index 36aa050f9..71ce3bade 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -43,6 +43,8 @@ late_initcall_sync(fb_logo_late_init);
 const struct linux_logo *fb_find_logo(int depth)
 {
 	const struct linux_logo *logo = NULL;
+	int num = depth >> 16;
+	depth &= 0xFFFF;
 	if (nologo || logos_freed)
 		return NULL;
@@ -72,7 +74,34 @@ const struct linux_logo *_ref fb_find_logo(int depth)
 	if (depth >= 8) {
 #ifdef CONFIG_LOGO_LINUX_CLUT224
 		/* Generic Linux Logo */
-		logo = &logo_linux_clut224;
+		// logo = &logo_linux_clut224;
+		switch (num) {
+		case 0: logo = &logo_linux00_clut224; break;
+		case 1: logo = &logo_linux01_clut224; break;
+		case 2: logo = &logo_linux02_clut224; break;
+		case 3: logo = &logo_linux03_clut224; break;
+		case 4: logo = &logo_linux04_clut224; break;
+		case 5: logo = &logo_linux05_clut224; break;
+		case 6: logo = &logo_linux06_clut224; break;
+		case 7: logo = &logo_linux07_clut224; break;
+		case 8: logo = &logo_linux08_clut224; break;
+		case 9: logo = &logo_linux09_clut224; break;
+		case 10: logo = &logo_linux10_clut224; break;
+		case 11: logo = &logo_linux11_clut224; break;
+		case 12: logo = &logo_linux12_clut224; break;
+		case 13: logo = &logo_linux13_clut224; break;
+		case 14: logo = &logo_linux14_clut224; break;
+		case 15: logo = &logo_linux15_clut224; break;
+		case 16: logo = &logo_linux16_clut224; break;
+		case 17: logo = &logo_linux17_clut224; break;
+		case 18: logo = &logo_linux18_clut224; break;
+		case 19: logo = &logo_linux19_clut224; break;
+		case 20: logo = &logo_linux20_clut224; break;
+		case 21: logo = &logo_linux21_clut224; break;
+		case 22: logo = &logo_linux22_clut224; break;
+		case 23: logo = &logo_linux23_clut224; break;
+		case 24: logo = &logo_linux24_clut224; break;
+		}
 #endif
 #ifdef CONFIG_LOGO_DEC_CLUT224
 		/* DEC Linux logo (on MIPS/MIPS64 or ALPHA) */

（三）修改 linux_logo.h（结构体声明）

编辑 linux_logo.h，修正语法错误并声明 25 帧图片结构体：

OK3568-linux-source/kernel/include/linux/linux_logo.h

diff --git a/include/linux/linux_logo.h b/include/linux/linux_logo.h
index d4d5b93ef..b0ffc168b 100644
--- a/include/linux/linux_logo.h
+++ b/include/linux/linux_logo.h
@@ -35,7 +35,32 @@ struct linux_logo {
 extern const struct linux_logo logo_linux_mono;
 extern const struct linux_logo logo_linux_vga16;
-extern const struct linux_logo logo_linux_clut224;
+// extern const struct linux_logo logo_linux_clut224;
+extern const struct linux_logo logo_linux00_clut224;
+extern const struct linux_logo logo_linux01_clut224;
+extern const struct linux_logo logo_linux02_clut224;
+extern const struct linux_logo logo_linux03_clut224;
+extern const struct linux_logo logo_linux04_clut224;
+extern const struct linux_logo logo_linux05_clut224;
+extern const struct linux_logo logo_linux06_clut224;
+extern const struct linux_logo logo_linux07_clut224;
+extern const struct linux_logo logo_linux08_clut224;
+extern const struct linux_logo logo_linux09_clut224;
+extern const struct linux_logo logo_linux10_clut224;
+extern const struct linux_logo logo_linux11_clut224;
+extern const struct linux_logo logo_linux12_clut224;
+extern const struct linux_logo logo_linux13_clut224;
+extern const struct linux_logo logo_linux14_clut224;
+extern const struct linux_logo logo_linux15_clut224;
+extern const struct linux_logo logo_linux16_clut224;
+extern const struct linux_logo logo_linux17_clut224;
+extern const struct linux_logo logo_linux18_clut224;
+extern const struct linux_logo logo_linux19_clut224;
+extern const struct linux_logo logo_linux20_clut224;
+extern const struct linux_logo logo_linux21_clut224;
+extern const struct linux_logo logo_linux22_clut224;
+extern const struct linux_logo logo_linux23_clut224;
+extern const struct linux_logo logo_linux24_clut224;
 extern const struct linux_logo logo_dec_clut224;
 extern const struct linux_logo logo_mac_clut224;
 extern const struct linux_logo logo_parisc_clut224;

（四）修改 defconfig（内核配置启用）

编辑 defconfig，启用 Logo 功能（删除冗余声音配置）：

OK3568-linux-source/arch/arm64/configs/OK3568-C-linux_defconfig

diff --git a/arch/arm64/configs/OK3568-C-linux_defconfig b/arch/arm64/configs/OK3568-C-linux_defconfig
index 97d46ceff..d5af9f21d 100644
--- a/arch/arm64/configs/OK3568-C-linux_defconfig
+++ b/arch/arm64/configs/OK3568-C-linux_defconfig
@@ -590,3 +590,18 @@ CONFIG_RCU_CPU_STALL_TIMEOUT=60
 CONFIG_FUNCTION_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
 CONFIG_LKDTM=y
+
+#
+# Console display driver support
+#
+CONFIG_FONT_8x8=n
+CONFIG_VGA_CONSOLE=y
+CONFIG_DUMMY_CONSOLE=y
+CONFIG_DUMMY_CONSOLE_COLUMNS=80
+CONFIG_DUMMY_CONSOLE_ROWS=25
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
+# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
+# CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER is not set
+CONFIG_LOGO=y
+CONFIG_LOGO_LINUX_MONO=n
+CONFIG_LOGO_LINUX_VGA16=n
+CONFIG_LOGO_LINUX_CLUT224=y

（五）修改 fbcon.c（动画播放逻辑）

编辑 fbcon.c，添加帧循环播放和延时逻辑：

OK3568-linux-source/kernel/drivers/video/fbdev/core/fbcon.c

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index bf7959fdf..2607ac9cb 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -569,6 +569,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct fb_info *info,
 	if (fb_get_color_depth(&info->var, &info->fix) == 1)
 		erase &= ~0x400;
 	logo_height = fb_prepare_logo(info, ops->rotate);
+	logo_height += (info->var.yres / 2) - (logo_height / 2); // 垂直居中
 	logo_lines = DIV_ROUND_UP(logo_height, vc->vc_font.height);
 	q = (unsigned short *) (vc->vc_origin +
 				vc->vc_size_row * rows);
@@ -2037,6 +2038,8 @@ static int fbcon_resize(struct vc_data *vc, unsigned int width,
 	return 0;
 }
 
+extern int fb_get_logo(struct fb_info *info, int num);
+
 static int fbcon_switch(struct vc_data *vc)
 {
 	struct fb_info *info, *old_info = NULL;
@@ -2158,7 +2161,14 @@ static int fbcon_switch(struct vc_data *vc)
 		logo_shown = fg_console;
 		/* This is protected above by initmem_freed */
-		fb_show_logo(info, ops->rotate);
+		// fb_show_logo(info, ops->rotate);
+#if 1
+		int i;
+		for (i = 0; i < 25; i++) { // 循环播放 25 帧 + fb_get_logo(info, i); + fb_show_logo(info, ops->rotate);
+			msleep(50); // 每帧延时 50ms，可调整动画速度
+		}
+#endif
 		update_region(vc,
 			      vc->vc_origin + vc->vc_size_row * vc->vc_top,
 			      vc->vc_size_row * (vc->vc_bottom - vc->vc_top));

（六）修改 fbmem.c（Logo 位置与函数导出）

编辑 fbmem.c，修正 Logo 显示位置并导出 fb_get_logo 函数：

OK3568-linux-source/kernel/drivers/video/fbdev/core/fbmem.c

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 7a70e7b80..63cfad4c0 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -509,10 +509,10 @@ static int fb_show_logo_line(struct fb_info *info, int rotate,
 		fb_set_logo(info, logo, logo_new, fb_logo.depth);
 	}
 
-	image.dx = 0;
-	image.dy = y;
 	image.width = logo->width;
 	image.height = logo->height;
+	image.dx = (info->var.xres / 2) - (logo->width / 2); // 水平居中
+	image.dy = (info->var.yres / 2) - (logo->height / 2); // 垂直居中
 
 	if (rotate) {
 		logo_rotate = kmalloc_array(logo->width, logo->height,
@@ -681,12 +681,25 @@ int fb_show_logo(struct fb_info *info, int rotate)
 	return y;
 }
 
+int fb_get_logo(struct fb_info *info, int num)
+{
+	int depth = fb_get_color_depth(&info->var, &info->fix);
+	depth |= num << 16; + fb_logo.logo = fb_find_logo(depth); + if (!fb_logo.logo) { + return -1; + } + return 0; +} #else int fb_prepare_logo(struct fb_info *info, int rotate) { return 0; } int fb_show_logo(struct fb_info *info, int rotate) { return 0; } +int fb_get_logo(struct fb_info *info, int num) { return 0; } #endif /* CONFIG_LOGO */ EXPORT_SYMBOL(fb_prepare_logo); EXPORT_SYMBOL(fb_show_logo); +EXPORT_SYMBOL(fb_get_logo);

（七）修改 bitblit.c（隐藏光标）

编辑 bitblit.c，禁用光标显示避免影响动画效果：

OK3568-linux-source/kernel/drivers/video/fbdev/core/bitblit.c

diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c
index 436365efa..e8e874653 100644
--- a/drivers/video/fbdev/core/bitblit.c
+++ b/drivers/video/fbdev/core/bitblit.c
@@ -373,7 +373,8 @@ static void bit_cursor(struct vc_data *vc, struct fb_info *info, int mode,
 	if (info->fbops->fb_cursor)
 		err = info->fbops->fb_cursor(info, &cursor);
 
-	if (err)
+	// if (err) // 禁用软光标
+	if (0)
 		soft_cursor(info, &cursor);
 
 	ops->cursor_reset = 0;

四、编译验证

完成所有修改后，执行内核编译命令，生成新的镜像文件并烧录到 RK3568 开发板，启动开发板即可看到居中播放的 Logo 动画（25 帧循环，每帧延时 50ms）。

咨询立即获得专属报价

联系销售 | 报价咨询 | 索取样品

华北区负责人

华东区负责人

华南区负责人

中西区负责人

本指南详细介绍了OK3568-C开发板（基于瑞芯微RK3568处理器设计），Android 11系统开机动画的配置方法，涵盖动画文件结构、压缩生成、系统集成及测试验证等完整流程。

一、动画文件介绍

安卓开机动画的核心文件为bootanimation.zip，该压缩包包含两部分： partX文件夹（X取值范围0-100）和 desc.txt配置文件。

1.1 partX文件

partX文件夹用于存放动画帧图片，需遵循以下技术要求：

• 图片分辨率必须与设备屏幕分辨率保持一致
• 图片命名需按数字连续递增（如01.png、02.png、03.png...）
• 图片位深需默认为 8位深，高位深（如32位深）有几率导致动画无法显示

图1：图片位深设置与验证示例

1.2 desc.txt文件

desc.txt文件用于配置动画的播放规则，格式错误会导致安卓系统无法解析。建议直接复制基础模板后按需修改。

1.2.1 desc.txt基础模板

720 1280 7
p 0 0 part0
（第三行必须保留空行，否则安卓系统不解析）

1.2.2 基础模板参数说明

1.2.3 SDK中desc.txt完整格式说明

首行参数配置：动画文件的起始行定义全局播放参数，格式为WIDTH HEIGHT FPS

• WIDTH：动画宽度，单位像素
• HEIGHT：动画高度，单位像素
• FPS：每秒帧数，例如60

动画段落配置：后续每行定义一个动画段落，格式如下：

TYPE COUNT PAUSE PATH [#RGBHEX] [CLOCK]

系统动画调用：支持特殊类型标识符$SYSTEM，用于调用系统默认动画文件/system/media/bootanimation.zip

二、生成bootanimation.zip压缩文件

提供Windows和Ubuntu两种系统的压缩方法，二选一即可。

图2：正确的压缩包内部结构（无多余层级）

三、预置动画包到系统源码

将生成的开机动画包集成到OK3568 Android11系统源码中：

操作步骤：将自制的bootanimation.zip文件，直接替换上述路径中的原有文件即可。重新编译系统或单独编译该模块后烧录验证。

四、手动测试方法

通过ADB命令替换设备中的动画包并重启测试，适用于开发调试阶段快速验证动画效果。

4.1 一键测试命令

adb root && adb remount && adb push bootanimation.zip /system/media/bootanimation.zip && adb shell sync && adb reboot

4.2 操作说明

• 确保PC与设备已通过USB连接，且设备已开启USB调试模式
• 在PC端打开命令提示符（Windows）或终端（Ubuntu）
• 复制上述命令并执行，等待设备重启后即可查看新的开机动画
• 如遇到权限问题，请检查设备是否已正确root

技术规格速查

咨询立即获得专属报价

联系销售 | 报价咨询 | 索取样品

华北区负责人

华东区负责人

华南区负责人

中西区负责人

1. 方案介绍

本文所提供的源码修改细节、操作流程及配置方案，均以标准化patch格式规范呈现，可满足团队复用、版本管控与协同开发的实际需求。其核心实现逻辑清晰明确：在OK3576 6.1.75 Android14系统镜像中新增独立logo分区，同步优化分区表配置、编译脚本及镜像打包脚本；通过标准化的分区验证、logo镜像打包、板端烧写全流程设计，实现无需重新编译全量系统源码即可完成开机logo替换及集成的核心需求。

该设计不仅大幅简化开发操作流程、降低调试成本，同时可保障系统配置的规范性与运行稳定性，精准适配开发过程中开机logo样式快速迭代的场景需求。

2. 前置资源准备

本文档配套资源中，已包含适配OK3576 6.1.75 Android14版本的预编译uboot.img文件，该文件可直接应用于本指南后续全部操作流程，无需额外进行编译适配，为开发调试工作提供便捷支撑。

3. 分区表定制配置

3.1 文件替换

将附件中的uboot.img文件，覆盖替换至RK3576开发板源码u-boot目录下的同名文件，确保底层引导程序与系统版本精准适配，为后续分区配置工作奠定基础。

3.2 脚本修改

参照下述patch内容，精准调整指定mk文件配置，执行build.sh脚本完成重新编译后，系统分区表将自动新增logo分区，实现分区结构的规范扩展：

--- a/device/rockchip/common/build/rockchip/RebuildParameter.mk
+++ b/device/rockchip/common/build/rockchip/RebuildParameter.mk
@@ -5,7 +5,7 @@ $(info build parameter.txt with $(PRODUCT_PARAMETER_TEMPLATE)....)
ifeq ($(strip $(BOARD_USES_AB_IMAGE)), true)
partition_list := security:4M,uboot_a:4M,trust_a:4M,misc:4M
else
-partition_list := security:4M,uboot:4M,trust:4M,misc:4M
+partition_list := security:4M,uboot:4M,logo:4M,trust:4M,misc:4M
endif # BOARD_USES_AB_IMAGE

3.3 结果核查

Android分区表将在编译过程中自动生成，编译完成后需及时验证logo分区是否成功添加，确保配置生效。分区表生成路径如下：

其中CMDLINE分区配置信息如下，可见logo分区已成功纳入系统分区序列，配置符合预期要求：

CMDLINE:mtdparts=rk29xxnand:0x00002000@0x00002000(security),0x00002000@0x00004000(uboot),0x00002000@0x00006000(logo),0x00002000@0x00008000(trust),...

4. Logo分区有效性验证

烧写经分区表修改后的完整编译镜像（update.img镜像），待设备正常启动后，可通过下述命令精准验证logo分区节点是否正常创建，确认分区配置无误：

ok3576_c:/ $ ls -l /dev/block/by-name/logo

lrwxrwxrwx 1 root root 20 1970-01-01 08:00 /dev/block/by-name/logo -> /dev/block/mmcblk0p3

5. Logo镜像标准化打包

logo.img镜像打包需选用24位色深的BMP格式图片作为源文件，可直接选用源码自带的BMP测试图，亦可自定义符合规格的图片，确保镜像兼容性与显示效果。打包操作支持两种实用场景：

cat logo.bmp > logo.img && truncate -s %512 logo.img && cat logo_kernel.bmp >> logo.img

6. 板端即时替换测试

logo.img镜像可通过U盘、TF卡或adb工具传输至RK3576开发板，满足不同调试场景的使用需求。下述为adb传输方式的标准化操作流程：

6.1 设备连接与权限配置

• 硬件连接：选用USB-TypeC线缆，规范连接主机与开发板的TypeC0接口，确保连接稳定、信号通畅
• 权限获取：依次执行下述命令，核查设备识别状态，并获取root权限

adb devices    # 验证adb工具是否成功识别开发板
adb root       # 提升操作权限至root级别

6.2 镜像文件传输

执行下述命令，将本地已打包完成的logo.img镜像，精准传输至开发板的data目录：

adb push logo.img /data

6.3 分区写入与效果验证

• 串口权限获取：通过开发板调试串口登录系统，执行su命令获取root权限
• 分区写入操作：切换至data目录，执行下述命令，将logo.img镜像精准写入logo分区

dd if=logo.img of=/dev/block/by-name/logo    # 将logo.img镜像写入logo分区

验证流程：重启开发板，观察开机logo显示效果，确认是否成功更新为目标样式，完成替换验证工作。

7. 编译阶段集成logo.img

系统默认编译流程不会自动生成logo.img镜像，需通过手动配置实现编译阶段的无缝集成，确保最终生成的update.img镜像包含logo相关配置。

7.1 文件放置

将已打包完成的logo.img镜像，规范存放至源码目录的kernel-6.1路径下，确保编译脚本可正常读取该文件。

7.2 脚本修改

编辑打包脚本mkimage.sh，添加logo.img镜像的分区拷贝指令：

--- a/device/rockchip/common/mkimage.sh
+++ b/device/rockchip/common/mkimage.sh
@@ -109,6 +109,7 @@ copy_images_from_out vendor_boot-debug.img
copy_images_from_out recovery.img
copy_images_from_out super.img
copy_images $OUT/userdata.img $IMAGE_PATH/data.img
+copy_images kernel-6.1/logo.img $IMAGE_PATH/logo.img
if [ ! "$PRODUCT_USE_DYNAMIC_PARTITIONS" = "true" ]; then
    copy_images_from_out system.img

7.3 编译与验证

确认脚本修改无误，且logo.img镜像已按要求放置在指定路径后，执行编译打包命令，生成包含logo分区及镜像的update.img镜像；将该镜像烧写至开发板，开机后即可验证logo集成效果。

8. 技术规格速查

咨询立即获得专属报价

联系销售 | 报价咨询 | 索取样品

华北区负责人

华东区负责人

华南区负责人

中西区负责人

本文档由飞凌嵌入式技术支持团队提供 · 适用于OK3576 6.1.75 Android14系统版本

中国AI产业动态：算力硬科技成核心竞争力

在2026年1月由胡润研究院发布的《2025胡润中国人工智能企业50强》榜单上，呈现了一个令人瞩目的现象：寒武纪以6300亿元价值登顶，紧随其后的是摩尔线程和沐曦股份，包揽了国内AI芯片企业前三甲。

图源：胡润研究院

前10名席位中，有7家聚焦算力硬件，整个榜单上主营AI算力硬件的企业从去年的5家猛增至14家，几乎翻了3倍。这些数据背后隐藏着中国AI产业的深刻转向。胡润榜单的分析指出，AI领域已成为财富创造的新引擎，占胡润百富榜企业家比例达9%，在40岁及以下的创业先锋（U40）中，AI领域创业者占比10%。

一个清晰的信号正在释放： 谁掌握了提供算力的核心硬件，谁就扼住了AI产业发展的命脉。这种从"软"到"硬"的价值回归，标志着中国AI产业进入更加成熟和深化的发展阶段。

端侧AI崛起：重构"云-边-端"协同生态

榜单揭示的产业转型背后，是中国AI从"量的积累"到"质的飞跃"的关键蜕变，3大趋势尤为显著：

• 底层技术攻坚成为竞争核心

  经过多年应用层探索，市场与资本形成共识：掌握算力硬件、核心算法等底层技术，才能占据AI产业制高点。从通用GPU到专用AI芯片，从开源生态到统一软件标准，中国企业正全方位突破技术壁垒。

• 端侧AI成为增长新引擎

  将AI计算任务从云端迁移至终端设备，既能提升响应速度、降低使用成本，又能保障数据隐私，完美契合行业智能化需求。这种"云-边-端"协同的架构，让AI应用从数据中心延伸至各类终端产品，催生了智能汽车、工业机器人、消费电子等领域的创新热潮。

• 产业生态走向多元均衡

  尽管算力硬件企业风光无限，但榜单同时覆盖了自动驾驶、视觉识别、数据分析决策等多元赛道，科大讯飞、地平线、小马智行等垂直领域龙头持续崛起，形成"硬件支撑、算法赋能、场景落地"的完整产业链生态。

端侧AI重构"云-边-端"协同生态架构

端侧AI企业盈利：商业化价值全面凸显

底层技术突破与场景需求爆发的双重利好，直接体现在端侧AI企业的业绩答卷上：

数据来源：各企业2025年年度业绩预告 | 制表：产业研究部

整体来看，上述企业盈利增长源于端侧AI技术的成熟与AIoT市场扩张的推动，覆盖智慧工业、消费电子、自动驾驶等多场景，带动企业实现规模化盈利。

以硬件为基础：赋能端侧AI场景落地

在AI产业从技术突破走向价值兑现的浪潮中， 飞凌嵌入式作为智能设备核心平台的提供商，始终紧跟产业趋势，将AI芯片技术与行业应用场景深度融合，为客户提供高可靠、易落地的嵌入式AI产品。

飞凌嵌入式不仅提供硬件平台，更注重构建完整的开发生态。围绕主流AI框架，公司提供了丰富的开发工具和示例代码，降低了AI应用开发的门槛。—— 飞凌嵌入式产品战略

针对不同行业的特殊需求，飞凌嵌入式提供从硬件接口设计到底层驱动开发，从系统优化到算法移植的支持服务，帮助客户缩短产品开发周期。

随着"人工智能+"行动的深入实施，端侧AI必将迎来更广阔的发展空间。飞凌嵌入式会持续聚焦核心技术创新，深化与产业链上下游的协同合作，以更优质的嵌入式AI解决方案，赋能千行百业的智能化转型，与行业伙伴共同见证中国AI产业的高质量发展。

一、方案介绍

本方案的核心设计思想是将开机LOGO资源独立存储于专用分区，与系统根文件系统分离。这种架构设计带来了以下显著优势：

• 隔离性：LOGO更新操作不会影响系统核心文件，降低更新风险
• 便捷性：无需重新编译整个系统，缩短产品迭代周期
• 灵活性：支持生产环境动态更换品牌标识，满足OEM需求
• 兼容性：适配Linux 5.10.198内核与QT5.15.10图形框架

二、修改步骤

（一）添加LOGO分区

在Ubuntu开发环境中，执行命令编辑分区配置文件，定义存储分区布局：

forlinx@ubuntu:~/work/3562/OK3562-linux-source$ vi device/forlinx/.chips/ok3562/parameter-buildroot-fit.txt

在配置文件中添加LOGO分区并调整userdata分区，完整配置内容如下：

// 添加logo分区：0x00100000@0x00cba000(logo)
// 修改userdata分区：-@0x00dba000(userdata:grow)
CMDLINE: mtdparts=:0x00002000@0x00004000(uboot),0x00002000@0x00006000(misc),0x00020000@0x00008000(boot),0x00040000@0x00028000(recovery),0x00010000@0x00068000(backup),0x00c00000@0x00078000(rootfs),0x00040000@0x00c78000(oem),0x00002000@0x00cb8000(amp),0x00100000@0x00cba000(logo),-@0x00dba000(userdata:grow)

（二）修改U-Boot并验证分区

由于RK3562的U-Boot源码未开源，直接使用适配本方案的修改版uboot.img（基于Linux5.10.198+QT5.15.10_用户资料_R1制作，新版本需重新验证兼容性）。

1. 将uboot.img文件放入OK3562-linux-source/u-boot目录，替换原有文件
2. 执行全编译操作，将编译后的镜像烧写至开发板
3. 开发板启动后，执行验证命令查看分区信息

分区验证：

开发板启动后，执行fdisk -l命令查看分区信息，完整输出如下：

root@ok3562:/# fdisk -l
Found valid GPT with protective MBR; using GPT
Disk /dev/mmcb1k0: 30576640 sectors, 2642M
Logical sector size: 512
Disk identifier(GUID): 27330000-0000-4656-8000-71000000163b
Number  Start(sector)  End (sector)  Size   Name
   1      16384         24575       4096K  uboot
   2      24576         32767       4096K  misc
   3      32768        163839       64.0M  boot
   4     163840        425983       128M   recovery
   5     425984        491519       32.0M  backup
   6     491520       13074431      6144M  rootfs
   8    13336576      13344767      4096K  amp
   9    13344768      14393343      512M   logo
  10    14393344      30576606      7901M  userdata

三、LOGO更新方法

（一）U盘自动更新

准备工作：

在U盘根目录创建Forlinx_logo文件夹，将logo.bmp和logo_kernel.bmp两张LOGO图片放入该文件夹。

自动更新脚本：

编写LOGO自动更新脚本logo.sh，脚本按功能分段实现检测、打包、写入逻辑，完整代码如下：

#!/bin/bash
# 功能1：定义U盘检测与LOGO更新核心函数
check_sdcard(){
    # 循环检测U盘挂载状态
    while true; do
        # 检测U盘根目录是否存在Forlinx_logo文件夹
        if [[ -d "/run/media/sda1/Forlinx_logo" ]]; then
            cd "/run/media/sda1/Forlinx_logo"
            # 检测是否存在更新标志文件，避免重复更新
            if [[ -f "Forlinx_logo_flag" ]]; then
                echo "Forlinx_logo_flag file. Exiting."
                break
            else
                # 功能2：校验LOGO图片是否齐全，齐全则执行打包与写入操作
                if [[ -f "/run/media/sda1/Forlinx_logo/logo.bmp" && -f "/run/media/sda1/Forlinx_logo/logo_kernel.bmp" ]]; then
                    # 合并LOGO图片为镜像文件
                    cat "logo.bmp" > "logo.img"
                    # 按512字节对齐镜像文件，适配分区写入要求
                    truncate -s %512 "logo.img"
                    # 追加内核LOGO图片至镜像文件
                    cat "logo_kernel.bmp" >> "logo.img"
                    # 将镜像文件写入LOGO分区
                    dd if="logo.img" of="/dev/block/by-name/logo"
                    # 功能3：更新完成后输出提示，并创建标志文件
                    echo "Logo files copied and written to /dev/block/by-name/logo."
                    touch "Forlinx_logo_flag"
                    break;
                else
                    echo "Missing logo.bmp or logo_kernel.bmp files."
                fi
            fi
        fi
        # 每5秒检测一次，避免占用过多系统资源
        sleep 5
    done
}
# 功能4：后台启动检测函数，不阻塞系统其他进程
check_sdcard &

配置脚本开机自启：

临时生效：编辑开发板/etc/autorun.sh文件，原文件内容如下：

root@ok3562:/# cat /etc/autorun.sh
#!/bin/sh
#env
#user command
exit 0

添加脚本执行命令，修改后完整内容：

#!/bin/sh
# env
# 启动LOGO自动更新脚本
./logo.sh
sync
exit 0

保存后重启开发板，脚本即可临时生效。

永久生效：编辑buildroot/board/forlinx/ok3562/fs-overlay/etc/autorun.sh文件，添加上述脚本执行命令，重新编译烧写镜像后，脚本永久生效。

（二）手动更新

将logo.bmp和logo_kernel.bmp两张LOGO图片传入开发板。

执行以下命令，完成LOGO镜像打包与分区写入：

root@ok3562:/# cat logo.bmp > logo.img && truncate -s %512 logo.img && cat logo_kernel.bmp >> logo.img
root@ok3562:/# dd if=logo.img of=/dev/block/by-name/logo
7201+1 records in
7201+1 records out
3686966 bytes (3.7 MB, 3.5 MiB) copied, 0.234017 s, 15.8 MB/s
root@ok3562:/# sync

重启开发板，开机LOGO即可完成更换。

四、关键说明

华北区负责人

华东区负责人

华南区负责人

中西区负责人

T527系列处理器特性

T527系列采用高性能八核Cortex-A55 AI平台SoC，适用于电子商业、工业和汽车领域。该芯片系列集成了八核Cortex-A55 CPU，一个HiFi4 DSP，2 TOPS NPU，G57 MC1 GPU，芯片支持4K@30fps H.265解码器，4K@30fps H.264编码器，1080p@60fps H.264编码器，DI和SmartColor系统，为用户提供流畅的体验和专业的AI视觉效果。

应用目标场景

FET527-C核心板介绍

FET527N-C核心板基于全志T527系列高性能处理器开发设计，集成了8个ARM Cortex-A55高性能核，同时内置1个RISC-V核和1个DSP核。具有2TOPS算力的NPU，为您的AI应用赋能。

核心板采用板对板连接方式，可插拔式设计便于产品的安装与维护。产品通过飞凌嵌入式实验室严苛的工业环境测试，为您的产品稳定性保驾护航。同时，FET527N-C核心板具有10-15年生命周期，为您的产品提供持续供应保障。

结构尺寸 70mm×46mm（公差±0.15mm）

制版工艺 厚度1.15mm，8层沉金PCB

连接器 双排0.5mm间距，80pin板对板连接器

固定建议：核心板与底板固定建议选择M2，外径5.56mm，柱高2mm的贴片螺母，配套螺钉规格M2*4mm。

FET527-C核心板正面视图

FET527-C核心板反面视图

性能参数

供电参数

工作环境

核心板接口速度

ESD特性

核心板接口资源

飞凌OK527N-C嵌入式开发平台

OK527N-C开发板采用核心板+底板分体式设计，共320个引脚，采用4个80Pin板对板连接器的方式将处理器的功能引脚以最便利的方式引出，并针对不同的功能做了深度优化，方便用户二次开发的同时简化用户设计，为您的项目提供良好的评估及设计依据。

飞凌嵌入式T527N开发板接口布局图（PCB尺寸：130mm×190mm）

底板资源列表

整机功耗表

注：1、测试条件：核心板配置是4GB内存+32GB eMMC，4G模块移远EC20，屏幕是飞凌选配产品。核心板是5V供电，底板是12V供电。
2、功耗仅供参考。

FET527-C硬件设计指南

最小系统设计

FET527-C核心板已经将电源、复位监控电路、存储电路集成于一个小巧的模块上，所需的外部电路非常简洁，构成一个最小系统只需要5V电源、复位按键、启动配置即可运行。

最小系统构成示意图

不过一般情况下，除最小系统外建议连接上一些外部设备，例如调试串口，用来查看打印信息；预留OTG接口，用来烧写系统。做好这些后，再在此基础上根据飞凌提供的核心板默认接口定义来添加用户需要的功能。

核心板电源与时序

BOOT启动配置

核心板在上电时判断FEL的电平状态，若为低则进入OTG烧写模式，若为高则进入顺序启动模式。（若使用OTG烧写方式，为了方便烧写，建议不要省略RESET按键。）

T527核心板顺序启动优先级为：

1. TF卡启动
2. EMMC启动
3. RAW NAND Flash启动
4. SPI NOR Flash启动
5. SPI NAND Flash启动

关键信号引脚

接口设计规范

TF卡烧写接口设计

FET527-C核心板TF卡烧写时使用SD0组信号线，该组信号线电压域会在TF卡与核心板协商后可在3.3V电压和1.8V之间切换。

OTG烧写接口设计

仅核心板原生的USB0支持USB烧写系统。

高速接口设计要点

PCB设计规范

通用设计规范

关键信号布线要求

I2C/TWI设计

音频设计

常见接口问题排查思路

通用排查思路

1. 如果参考飞凌设计的底板功能，首先要保证所用芯片和原理的一致性，如果功能芯片不一致可能需要移植芯片驱动
2. 原理芯片一致，功能验证失败，需要依次排查功能芯片的电源、复位、时钟是否正常
3. 交叉测试，判断问题点在核心板上还是在底板上
4. 引脚电平是否匹配，数据信号是否有输出
5. 排查焊接问题，阻容器件是否存在虚焊、连焊、漏焊、错焊等问题
6. 测量信号的空闲状态是否正常
7. 确认引脚复用是否正确

不启动问题

1. 除电源和复位外，需要检查power on信号是否正常
2. 确认底板设计时是否对FEL、RESET引脚做了上下拉处理
3. 使用示波器测量，核心板的供电波形，是否有跌坑导致启动异常
4. 底板是否有外设漏电到核心板

I2C问题排查

1. I2C为OD输出，首先需要确认是否有上拉电阻
2. 确认同组I2C总线下挂载的设备地址是否有冲突
3. 测量信号波形，空闲状态是否为高电平，数据传输时波形是否正常
4. 如果波形上升缓慢可以减小上拉电阻阻值，如果低电平过高可以增大上拉电阻阻值
5. 可通过I2C tool工具查看总线上是否挂载设备：
   • i2cdetect -l//检测系统上有几组I2C
   • i2cdetect -r -y 2//检测I2C第二组总线上的挂载的设备

其他接口排查要点

PCIE与音频

咨询立即获得专属报价

专业工程师团队为您提供T527核心板的技术支持与定制化开发服务

联系销售 | 报价咨询 | 索取样品

华北区负责人

华东区负责人

华南区负责人

中西区负责人

功能简介

程序使用说明

基础命令格式

配置文件要求

manuid.conf 文件需放置于板卡 /etc 目录下。 该文件包含eMMC厂商的制造商ID信息，是程序正常运行的必要条件。

• 若文件缺失，程序将报错退出
• 若文件中未包含对应eMMC厂商的manuid，程序将报错退出
• 请确保配置文件与实际硬件型号匹配

启动方式建议

参数选项说明

生成文件说明

程序运行后，将在以下路径生成健康状态报告文件：

文件内容结构

告警信息说明

当系统检测到异常状态时，将在调试串口以红色字体打印告警信息：

使用举例

实例说明

以 8G江波龙eMMC为例，运行eMMC健康监测工具后，查看生成的health.info文件：

图1：health.info文件内容示例

关键检查点

确认eMMC是否寿命用尽或是否损坏，主要关注以下两个核心指标：

1. 平均擦写次数（Average erase count）
   格式：[ 59 / 3000 ]
   要求：不得超过3000次
2. 坏块数量（Bad block count）
   当前值：0
   要求：必须保持为零

健康状态判定标准：

• 平均擦写次数 < 3000 且 坏块数 = 0：健康
• 平均擦写次数 ≥ 3000：需立即更换
• 坏块数 > 0：需检查文件系统

获取技术支持与专属方案

专业工程师团队为您提供eMMC健康监测工具的部署指导与定制化开发服务

联系销售 | 报价咨询 | 索取样品

华北区负责人

华东区负责人

华南区负责人

中西区负责人

RK3568处理器架构与核心特性

RK3568处理器功能框图与接口布局

RK3568核心板产品系列

飞凌嵌入式基于RK3568处理器推出FET3568-C/FET3568J-C与FET3568-C2/FET3568J-C2核心板，采用统一引脚定义设计，确保硬件平台的兼容性与可升级性。

物理规格与结构设计

FET3568-C 核心板正面视图

FET3568-C 核心板反面视图

FET3568-C2 核心板正面视图

FET3568-C2 核心板反面视图

核心板接口资源

RK3568开发平台硬件配置

OK3568-C/C21开发平台采用核心板+底板分离设计，FET3568-C与FET3568-C2核心板引脚定义相同，可共用OK3568-C底板，实现硬件资源的最大化利用与灵活配置。

底板接口资源布局

OK3568-C底板接口布局（正面）- 含DC 12V、PCIe 3.0x2、USB 3.0 HOST、HDMI、双路Ethernet等接口

RK3568电气特性与工作环境

供电参数

温度规格

RK3568 系列硬件设计规范

RK3568功耗与稳定性数据

OK3568-C平台功耗表（Linux系统）

OK3568-C21平台功耗表（Linux系统）

RK3568常见问题排查策略

咨询立即获得专属报价

联系销售 | 报价咨询 | 索取样品

华北区负责人

华东区负责人

华南区负责人

中西区负责人

飞凌嵌入式RV1126B集成 4 个 ARM Cortex-A53 高性能核心，具备 3TOPS@INT8 的 AI 计算能力，并配备多路适用于边缘侧应用的工业接口。已通过飞凌嵌入式实验室严苛的工业环境测试，确保品质稳定可靠，且提供 10~15 年生命周期支持，保障供应长期稳定。

产品概述

飞凌嵌入式RV1126B系列包括FET1126BJ-S核心板，OK1126BJ-S开发板，采用瑞芯微RV1126B/ RV1126BJ 处理器，该处理器为四核 ARM Cortex-A53 架构，配备 NEON 与 FPU，并拥有512KB L2缓存；NPU 算力达 3.0TOPs，支持 INT8/INT16 混合运算；支持最高1200万像素 ISP 及800万像素 AI-ISP，可接入四路摄像头；支持 H.265/H.264 4Kp30 解码，以及多流编码，支持高分辨率本地存储与低分辨率云端同步；提供 MIPI CSI、LVDS、DVP 及 I2C、SPI、PWM 等外设接口，便于系统集成与功能拓展。

产品特点：

采用 40mm×40mm 小尺寸设计，引出处理器全部功能引脚 

具备 3TOPS 算力，并提供 RKNN 等 NPU 使用例程 

具备两种显示接口：MIPI DSI、RGB 

具备丰富的工业总线接口：RGMII、UART、CANFD、SPI 等 

提供测试用边缘侧 AI 算法例程 

运行温度范围-20℃~+85℃/-40℃~+85℃

软件支持：

飞凌嵌入式为 RV1126B 系列搭载 Linux 6.1 操作系统，同时配套提供用户使用手册、用户编译手册、烧写镜像、内核源码、测试程序源码、文件系统，以及驱动工具、下载工具、烧录工具等各类工具，还包含开发环境与 AI 算法例程。

开发支持：

飞凌嵌入式推出 RV1126B 专用完整开发套件 OK1126B-S 开发板，同时提供全套硬件开发资料，具体涵盖硬件手册、引脚复用对照表、引脚功能对照表，核心板 STEP 文件、核心板 DXF 文件，底板 DXF 文件、底板 PDF 原理图、底板原理图源文件、底板 PCB 源文件及底板设计数据手册等。

▊ RV1126B核心板 功能配置

处理器	CPU：	Rockchip RV1126B	Rockchip RV1126BJ
	架构：	4×Cortex-A53，up to 1.6GHz	4×Cortex-A53，up to 1.3GHz
	NPU：	3 TOPS@INT8
	GPU：	无3D GPU，仅支持2D RGA
	ISP：	VICAP输入:RX raw8/raw10/raw12/raw14/raw16 最大输入:12M@30fps 最小输入:264x264
	AI ISP：	最大输入:8M@30fps 最大分辨率:4096 x4096
	VPU：	视频解码器： · 支持H.264、H.265硬解码 · H.265 HEVC/MVC Main Profile yuv420@L5.0 up to 3840x2160@30fps · H.264 AVC/MVC Main Profile yuv400/yuv420/yuv422@L5.1 up to 3840x2160@30fps 视频编码器： · 支持HEVC、H.264、JPEG硬编码 · 支持并行编码(HEVC+JPEG 或 H.264+JPEG) · 最高支持12M@30fps JPEG解码器： · 支持的图像分辨率48x48 ~ 65520x65520 · 支持YUV400/YUV420/YUV422/YUV440/YUV411/YUV444
RAM		1GB/2GB/4GB LPDDR4	1GB/2GB/4GB LPDDR4
ROM		64GB eMMC	8GB/16GB/32GB eMMC
工作温度		-20℃~+85℃	-40℃~+85℃
工作电压		DC 5V
连接方式		邮票孔+LGA（共引出237个引脚，其中邮票孔形式引脚140个，引脚中心间距1mm；LGA形式引脚97个，中心间距1.27mm）
核心板尺寸		40*40mm
操作系统		Linux 6.1.141
系统烧写方式		USB OTG、TF

功能	数量	参数
Display	1	支持1路显示输出，最大分辨率支持1920*1080@60fps 支持多种显示接口可选择： · RGB：24bit · MIPI-DSI：4lane，1.5Gbps/lane · BT.656/BT.1120
MIPI CSI	≤2	支持2路4lane,2.5Gbps/lane · 支持两个MIPI CSI/LVDS/SubLVDS DPHY · 每个MIPI DPHY V1.2，4lane，2.5Gbps/lane · 每个接口可配置为2x2 数据通道端口 · 支持虚拟通道
DVP	1	支持8/10/12/14/16-bit, I/O频率最高可达150MHz 支持BT.601/BT.656 and BT.1120输入
Ethernet	1	1路MAC，可用于一路RGMII接口或一路百兆接口（CPU内置1路百兆PHY)
USB	2	1路USB2.0 Host 1路USB 2.0/3.0 DRD
UART	≤8	支持的最大波特率为4Mbps，UART1-UART7支持自动流控
CAN	≤2	支持CAN2.0 A/B
SDIO 3.0	≤2	1路TF卡接口，支持高速卡；1路SDIO接口，3.3V电平
DSMC	≤1	1路主机接口，可用于连接FPGA 支持4路片选信号，支持8-wire 或 16-wire 串行传输模式
FSPI	≤1	支持启动，支持1/2/4位模式
SPI	≤2	可配置主从模式
I2C	≤5	支持7bits和10bits地址模式，最高速率可达1 Mbit/s
PWM	≤27	最多支持27通道PWM
ADC	≤24	24路单端输入，13bit，2MSPS
SAI	≤3	可配置主从模式
Audio ADC	≤2	2路差分MIC输入，2路 Audio DSM 差分输出
GPIO	≤118	除核心板内部使用外的总数量

注：表中参数为硬件设计或CPU理论值。

▊ RV1126B开发板 功能配置

功能	数量	参数
LCD	1	插针引出，支持电容触摸屏，支持背光亮度调整
MIPI DSI	1	4-lane MIPI DSI，支持电容触摸屏，支持背光亮度调整
MIPI CSI	2	FPC座引出，4lane+4lane
UART Debug	1	集成在一个Type-C端口，可连接电脑进行调试
USB2.0	2	一路USB_HOST使用USB座子引出 一路USB_OTG由Type-C引出用作OTG烧写或与USB3.0组合由USB3.0座子引出
USB3.0	1	一路USB3.0 HOST由USB3.0座子引出
Ethernet	1	标准RJ45插座引出，开发板具备一个百兆接口及一个千兆接口，由于CPU仅具备1个MAC，故二者只能选择其中一个，不能同时使用
UART	1	UART5由40PIN插针引出
CAN	2	CAN0、CAN1由40PIN插针引出
IIC	2	I2C3、I2C4由40PIN插针引出
SPI	1	SPI1由40PIN插针引出
WiFi Bluetooth	1	单天线2.4G&5GHz Wi-Fi Dual-band 1X1 802.11ac +Bluetooth 4.2
ADC	7	7路ADC由插针引出
RTC	1	外接CR2032纽扣电池，断电保持时间
SPEAKER	1	经过功放芯片引出，可外接4Ω-3.3W喇叭
MIC	2	一路接板载驻极体，一路未引出
FSPI	1	可外接FLASH芯片,可支持启动
TF Card Slot	1	支持最大SDR104速率的TF卡
KEY	3	CPU复位、开关机与启动项按键

IgH EtherCAT Master是什么？

EtherCAT工作原理示意图

IgH EtherCAT则是运行于Linux系统的开源EtherCAT主站程序，IgH EtherCAT主站通过构建Linux字符设备，应用程序通过对字符设备的访问实现与EtherCAT主站模块的通信。

它主要包括以下三部分：

2. Device Modules

角色：经过实时性优化的"网卡驱动"（如瑞芯微RK平台的 stmmac）。

功能：作为主站与物理网口的桥梁。它能智能分流：被主站选中的设备用于收发 EtherCAT 帧；未被选中的设备则作为普通以太网设备走常规协议栈，实现 EtherCAT 与普通网络的并行工作。

3. Application

角色：业务逻辑的执行者（用户编写或生成）。

功能：通过应用接口向主站申请总线控制权。一旦获准，即可配置总线并进行周期性的过程数据交换。应用程序既可以是内核模块，也可以是通过库（EtherCAT/RTDM）调用的用户空间程序。

应用层架构示意图

实时内核Preempt-RT

1. 独具优势：

IgH EtherCAT Master要保证高实时性，需要在实时操作系统上运行。Preempt-RT是一种针对实时性能进行了优化的Linux内核，与普通的Linux内核相比，Preempt-RT的优势很明显：

• 硬实时保障：具备硬实时能力，能确保关键任务在严格规定的时限内完成，不受其他任务干扰，满足工业自动化、航空航天等对时间精度极高的场景需求。
• 高效调度与低延迟：采用基于优先级的抢占式调度算法，高优先级任务可立即抢占低优先级任务；同时深度优化中断处理机制，大幅缩短响应时间，消除系统抖动。
• 高精度定时：提供微秒级的内核定时器精度，配合实时扩展机制，支持用户对内核进行定制，精准满足EtherCAT通信的周期性数据交换需求。

2. 实时性测试

本次测试参考Rockchip RealTime Linux Performance Test Report，分为空载测试和压力测试。测试的环境如下：

• 工具：cyclictest
• 硬件平台：OK3576-C开发板
• 内核版本：6.1.118-rt36
• Path：SDK/docs/rk35xx/Patches/Real-Time-Performance/PREEMPT_RT/kernel-6.1/kernel-6.1.118

空载测试结果示意图

压力测试结果示意图

演示案例

本节的演示选取周期同步速度模式（通讯周期时间为1ms）与周期同步转矩模式（通讯周期时间为125μs）驱动伺服电机转动。

1. 环境介绍

开发环境：

• Kernel：6.1.118-rt36
• IgH EtherCAT Master：IgH EtherCAT master 1.6.0-rc1
• EtherCAT主站：OK3576-C
• EtherCAT从站：
  • （1）EtherCAT耦合器EK1100
  • （2）数字量输出模块EL2008
  • （3）伺服驱动器IS620NS1R6I + 伺服电机MS1H1-10B30CB A330Z

拓扑结构图：

系统拓扑结构图

主站通过网线连接EtherCAT耦合器EK1100，EK1100通过E-Bus连接数字量输出模块EL2008、通过网线连接伺服驱动器IS620N，交流伺服电机MS1H1-10B30CB通过动力线和编码线与伺服驱动器IS620N相连。

使用EtherCat调试工具输出识别到的从站：

从站识别

使用EtherCat调试工具输出总线拓扑：

总线拓扑

2. 伺服模式

IS620N 支持 7 种伺服模式，分别为轮廓位置模式（PP）、轮廓速度模式（PV）、轮廓转矩模式（PT）、回零模式（HM）、周期同步位置模式（CSP）、周期同步速度模式（CSV）、周期同步转矩模式（CST）。

不同模式支持的通讯周期不同，如下所示：

伺服模式通讯周期表

3. 主站性能测试方法

抖动和延迟定义

代码示意图

演示一：周期同步速度模式(1ms)

周期同步速度模式下，上位控制器将计算好的目标速度 60FF 周期性同步发送给伺服驱动器，速度、转矩调节由伺服内部执行。

基本配置：

周期同步速度模式基本配置

使用EtherCat调试工具输出的pdo信息：

周期同步速度模式PDO信息

操作步骤：

控制指令设置步骤

性能指标：

压力测试结果

隔离测试结果

演示二：周期同步转矩模式(125μs)

此模式下，上位控制器将计算好的目标转矩 6071h 周期性同步的发送给伺服驱动器，转矩调节由伺服内部执行。当速度达到限幅值后将进入调速阶段。

基本配置：

周期同步转矩模式基本配置

使用EtherCat调试工具输出的pdo信息：

周期同步转矩模式PDO信息

操作步骤：

转矩模式控制指令设置

性能指标：

转矩模式压力测试结果

转矩模式隔离测试结果

方案展示：

完整方案展示

RK3576核心板

行业背景与芯片演进

核心参数对比分析

RV1109 / RV1126 / RV1126B 规格对比

RV1126B核心参数升级亮点

飞凌OK1126B-S开发平台详解

开发板外观

OK1126B-S开发板正面视图

核心板规格

核心板型号是FET1126B-S，10层沉金PCB，采用邮票孔+LGA的封装形式共引出237个引脚，电源、复位电路、存储电路已经集成在核心板上面。

4GB RAM

64GB存储

10层沉金PCB

硬件接口深度解析

网络通信接口

OK1126B-S开发平台主要接口布局

扩展与存储接口

软件系统配置

操作系统与工具链

OK1126B-S开发板运行Linux 6.1.118操作系统，并且基于buildroot进行文件系统定制，提供了常用的Qt和命令行测试工具，用来验证开发板基本的外设。

RV1126在线文档

AI性能核心亮点

AI-ISP技术革新

RV1126B AI-ISP 画质提升效果

实测性能数据

3TOPS算力应用场景实测

NPU算力提升至3TOPS，可以在设备端进行数据多模态分析，通过架构优化可以把功耗控制得非常好，以下是各种数据实测：

大模型和多模态模型

目标检测

图像分割

人体&人脸关键点识别

评估总结

华北区负责人

华东区负责人

华南区负责人

中西区负责人

当然，如果对AI辅助编程有很强的依赖性，还不如直接使用Cursor或者Copilot。但是话说回来，工程师自己实现这个部署过程真的没用吗？我并不这么认为。实际上通过这样的尝试，可以让工程师具备本地部署AI的能力，而这个能力在什么地方会用到呢？那就是 边缘AI这个应用领域。

边缘AI典型应用场景

边缘AI项目往往要求工程师在资源受限、成本要求较高的边缘终端设备中部署AI来实现对应的功能。举几个例子：

飞凌OK1126B-S开发板推荐

飞凌OK1126B-S开发板 - 高性能边缘AI解决方案

核心性能参数

这个板子大概是个什么性能参数呢，这里简单说一下：

模型运行测试数据

大语言模型和多模态模型测试

目标检测模型测试

图像分割模型测试

专用AI-ISP技术亮点

AI-ISP技术：将AI算法融入ISP处理链路，实现画质增强与智能分析并行

工业级与宽温级支持

根据项目需求选择适合的核心板等级

开发支持与快速落地 · 咨询立即获得专属报价

技术支持包含

• 完整的硬件设计参考
• 详细的软件开发手册
• AI模型部署优化指南
• 专业的在线技术支持团队

立即咨询

联系销售 报价咨询 索取样品

华北区

华东区

华南区

中西区

飞凌嵌入式LPDDR5内存升级战略方案

主动应对，化解供应风险

图1：飞凌嵌入式供应链战略布局

双重价值：技术领先与供应保障并举

✓ 技术层面，实现跃迁式提升

✓ 供应层面，构建体系化保障优势

成为客户更值得信赖的伙伴

华北区负责人

华东区负责人

华南区负责人

中西区负责人

在这样的背景下，全志T153平台直接搬出ARM+RISC-V的"双核CP"：主打高性能计算的Cortex-A7核心运行Linux，聚焦高实时性任务的RISC-V E907核心运行RTOS，组成 "互补型搭档"。

本文会通过飞凌嵌入式OK153-S开发板，为大家实测这对双核CP的协作实力——依托异构核间通讯机制（IPC）与Suspend/Resume电源管理机制，全面验证A核与R核的协同工作能力，并验证异构多核环境下的数据交互效率与智能化唤醒逻辑。

1 休眠唤醒功能验证

# 设置pm_test模式
echo devices > /sys/power/pm_test
# 设备进入休眠
echo mem > /sys/power/state
# 执行以上命令后，设备5s后会被唤醒。

2 R核唤醒休眠的A核

A核进入WFI模式，R核运行在DRAM上，R核唤醒A核

echo 0 >/sys/class/pm_msgbox/set_dram_refresh

echo mem > /sys/power/state

cpux_resume

3 双核通讯验证

T153处理器采用ARM Cortex-A7+RISC-V的多核异构架构，让系统兼具"大脑"与"小脑"，而异构核间通讯机制（IPC）正是连接两个"脑"的高速通道，通过共享内存机制，双核之间可实现数据传输。以下是操作方法：

# 测试之前首先使能R核：
echo amp_rv0.bin > /sys/class/remoteproc/remoteproc0/firmware
echo start > /sys/class/remoteproc/remoteproc0/state

RISC-V端例程

static void print_help_msg(void)
{
    printf("\n");
    printf("USAGE:\n");
    printf("  rpbuf_test [OPTIONS]\n");
    printf("OPTIONS:\n");
    printf("  -h : print help message\n");
    printf("  -c : create buffer\n");
    printf("  -C : Send Cnt(default: 1)\n");
    printf("  -d : destory buffer\n");
    printf("  -s : send test messagese\n");
    printf("  -l : list created buffers\n");
    printf("  -a : sync transmit\n");
    printf("  -I ID : specify controller ID (default: 0)\n");
    printf("  -N NAME : specify buffer name (default: \"%s\")\n", RPBUF_BUFFER_NAME_DEFAULT);
    printf("  -L LENGTH : specify buffer length (default: %d bytes)\n", RPBUF_BUFFER_LENGTH_DEFAULT);
    printf("  -p : print performance data\n");
    printf("\n");
    printf("e.g.\n");
    printf("  First, create a buffer (its name and length should match that of remote rpbuf buffer):\n");
    printf("    rpbuf_buffer -N \"xxx\" -L LENGTH -c\n");
    printf("  Then if remote sends data to it, the buffer callback will be called.\n");
    printf("\n");
    printf("  We can send test data to remote:\n");
    printf("    rpbuf_test -d 100 -s -L 32\n");
    printf("\n");
    printf("  If this buffer is no longer in use, destroy it:\n");
    printf("    rpbuf_test -N \"xxx\" -d\n");
    printf("\n");
}

A核例程

static void print_help_msg(void)
{
    printf("\n");
    printf("USAGE:\n");
    printf("  rpbuf_test [OPTIONS]\n");
    printf("\n");
    printf("OPTIONS:\n");
    printf("  -d time : set data sending interval (default: 100 ms)\n");
    printf("  -s : send test messages\n");
    printf("  -c : send count (default: 10)\n");
    printf("  -r : receive messages\n");
    printf("  -t time : specifies the time of receive messagess, unit:ms\n");
    printf("  -a : sync transmit\n");
    printf("  -I ID : specify rpbuf ctrl ID (default: 0)\n");
    printf("  -N NAME : specify buffer name (default: \"%s\")\n", RPBUF_BUFFER_NAME_DEFAULT);
    printf("  -L LENGTH : specify buffer length (default: %d bytes)\n", RPBUF_BUFFER_LENGTH_DEFAULT);
    printf("  -p : print performance data\n");
    printf("\n");
    printf("e.g.\n");
    printf("  rpbuf_test -L 0x1000 -c 10 -s : send 10 test data, size=0x1000\n");
    printf("  rpbuf_test -L 0x1000 -r : receive test data forever, size=0x1000\n");
    printf("  rpbuf_test -L 0x1000 -r -t 1000 : receive test data 1 second, size=0x1000\n");
    printf("\n");
}

实验现象

cpu0>rpbuf_test -c -I 0 -N rpbuf_test -L 524160 -a
cpu0>[RPBUF_INFO][rpbuf_addr_remap_default:206]reamp pa:0x42144000 -> va:0x42144000
[RPBUF_INFO][rpbuf_service_command_buffer_created_handler:827]buffer "rpbuf_test" (id:0): local_dummy_buffers -> buffers
buffer "rpbuf_test" is available
cpu0>rpbuf_test -N rpbuf_test -C 100 -s
[0]data:21a94801873e262b487f31000da27543...
[md5:fd0f42ddde63121837ebcdec775250b9]

root@OKT153:/# rpbuf_test -L 524160 -N rpbuf_test -r
ping: 8099.576172ms  bandwidth: 0.517149Mbps
data:21a94801873e262b487f31000da27543...  check:fd0f42ddde63121837ebcdec775250b9 success
ping: 14.155000ms   bandwidth: 186.086807Mbps
data:21a94801873e262b487f31000da27543...  check:fd0f42ddde63121837ebcdec775250b9 success
ping: 14.721000ms   bandwidth: 181.881592Mbps
data:21a94801873e262b487f31000da27543...  check:fd0f42ddde63121837ebcdec775250b9 success
ping: 14.694000ms   bandwidth: 181.992096Mbps
data:21a94801873e262b487f31000da27543...  check:fd0f42ddde63121837ebcdec775250b9 success
ping: 14.680000ms   bandwidth: 182.055313Mbps
data:21a94801873e262b487f31000da27543...  check:fd0f42ddde63121837ebcdec775250b9 success
ping: 14.712000ms   bandwidth: 181.779083Mbps
data:21a94801873e262b487f31000da27543...  check:fd0f42ddde63121837ebcdec775250b9 success
ping: 14.690000ms   bandwidth: 182.276901Mbps
data:21a94801873e262b487f31000da27543...  check:fd0f42ddde63121837ebcdec775250b9 success

4 结论

华北区负责人

华东区负责人

华南区负责人

中西区负责人