本专题服务重点
STM32MP1/MP2载板、OpenSTLinux、驱动、镜像和实时核协同
评估、开发和验收围绕该任务组织；涉及相邻模型、系统、硬件或量产工作时，按对应专题边界组合实施。
SERVICE BOUNDARY
STM32MP是异构Linux系统，不按MCU固件方式简化处理
启动链、TF-A、OP-TEE、U-Boot、Linux、设备树、Yocto层、应用和M核固件之间需要版本与责任边界。
项目实施边界
- DDR和高速接口结论绑定具体载板、器件和PCB
- OpenSTLinux与第三方组件版本按项目冻结
- Android、认证或安全启动量产流程需单独确认范围
ENGINEERING SCOPE
工程服务范围
各项服务可按项目单独实施，也可与相关专题组合；任务书将逐项明确输入、输出、第三方依赖、样机和测试责任。
硬件与启动链
配合电源、DDR、存储、Boot模式、TF-A、OP-TEE和U-Boot。
- 启动日志
- 时序与配置
- 恢复入口
Linux BSP与驱动
处理内核、设备树、显示、触摸、网络、USB、音频、相机和工业接口。
- 驱动配置
- 设备树
- 压力测试
Yocto镜像与应用
维护OpenEmbedded层、软件包、服务、更新、只读或可写分区和部署。
- 镜像复现
- 包许可
- 版本管理
A核与M核协同
划分Linux应用和实时固件，处理资源、通信、启动、故障和升级。
- 资源分配
- 消息接口
- 生命周期
DELIVERY PROCESS
实施路径
先确认项目基线和关键前置条件，再进入详细开发与验证；各阶段结论均对应具体版本与记录。
冻结硬件与BSP
确认MPU、DDR、载板、启动介质和OpenSTLinux版本。
启动与基础外设
打通电源、DDR、存储、控制台、网络和恢复。
驱动与镜像开发
实现设备树、内核配置、Yocto层和服务。
应用与M核协同
接入UI、多媒体、业务和实时固件。
系统与恢复验收
覆盖持续运行、升级、掉电、服务和A/M核异常。
DELIVERABLES
交付内容
最终交付范围由双方在任务书或合同中确认，文件均对应具体硬件、软件、工具链和测试版本。
- 启动链和硬件配置
- U-Boot/内核/设备树修改
- Yocto层与镜像构建
- 驱动、服务和应用代码
- Cortex-M固件与通信接口
- 烧录、恢复、测试和版本说明
ACCEPTANCE
验收条件
环境适应性、可靠性、认证和批量生产如需纳入验收，应在任务书中另行约定范围、样本与标准。
- 目标载板可重复启动并记录启动版本
- DDR、存储、网络和主要外设按用例通过
- 镜像能够在冻结环境重建
- A核与M核资源、通信和异常状态明确
- 升级、掉电和恢复路径经过测试
- 开源与第三方包清单、许可和版本归档
PROJECT INPUT
项目评估需要的输入
资料暂不完整时，可先开展基线检查和可行性评估；正式范围与技术结论在关键输入确认后形成。
- 01STM32MP具体料号
- 02载板、DDR和电源资料
- 03启动介质和分区
- 04OpenSTLinux与工具版本
- 05外设与设备树
- 06Linux应用、M核任务和验收条件
SOURCE BASELINE
原厂资料基线
下列链接用于核对产品组合与工具链事实。项目启动时仍需复核具体料号、数据手册、勘误、软件版本和供货状态。
应根据CPU、实时核、内存、显示、多媒体、接口、安全、功耗、软件和供货条件评估，并落到具体料号。
ST官方资料说明其基于OpenEmbedded构建框架，项目应冻结发行版、层、内核和工具版本。
可以按边界交付，但需要目标载板、可用BSP、硬件资料和可复现测试条件。
通常把Linux界面、网络和复杂应用放在A核，把确定性实时任务放在M核；具体资源与通信需按项目设计。
可以按器件、启动链、密钥、分区和更新策略评估，生产密钥与权限管理需明确责任方。
不能直接推导。DDR、电源、存储、设备树、外设和板级信号差异需要重新适配和测试。
PROJECT INTAKE
先提供基线资料，再形成范围与验收条件
提交目标、现有资料、版本、问题、样机条件和必须达到的指标，可先进行资料审查或可行性评估。
在线咨询
电话咨询
微信咨询
回到顶部