网站设计策划书 模板,网站后台管理系统权限,租用网站的服务器,iis7 网站用户权限这篇文章会简单的介绍8255的启动流程#xff0c;然后着重介绍8255在实际项目中新硬件上的bring up工作#xff0c;可以给大家做些参考。
8255 boot介绍
下面这些信息来自文档#xff1a;《QAM8255P IVI Boot and CoreBSP Architecture Technical Overview》 80-42847-11 R…这篇文章会简单的介绍8255的启动流程然后着重介绍8255在实际项目中新硬件上的bring up工作可以给大家做些参考。
8255 boot介绍
下面这些信息来自文档《QAM8255P IVI Boot and CoreBSP Architecture Technical Overview》 80-42847-11 Rev. AC如果已经对这个文档比较熟悉可以跳过这个部分。如果没有看过建议一定要认真看一遍。 1. After the chipset is reset, the SAIL and Qualcomm® Kryo™ CPU Gold core 0 comes out of reset.
1a. SAIL configures the pre-built-in self-test (pre-BIST) and go into wait for interrupt (WFI) and hardware BIST controller unit (HBCU), which is a
hardware controller performs the BIST on SAIL. SAIL PBL initializes hardware and loads SAIL hypervisor to run.
1b. SAIL hypervisor loads the SW1/SW2/SW3 images.
1c. APPS core0 executes application primary boot loader (APPS PBL) pre-BIST configuration and goes into WFI and wait for SAIL communication
to run BIST on APSS. After Phase-1 BIST, SAIL sends post BIST reset to APSS, APSS reset and the Kryo Gold core 0, APPS PBL initializes
hardware (timer, PRNG, clocks, and so on), enables caches and memory management unit (MMU), and detects the boot device according to
the boot option configuration:
□ Default boot option for APSS: UFS
□ Default boot option for SAIL: NOR
□ Default boot option: Overridden by EDL cookie or force USB GPIO
2a. APPS PBL loads and authenticates XBL loader (region #1) from the boot device to the Boot IMEM.
2b. APPS PBL loads and authenticates XBL SDI (region #2) from the boot device to on-chip internal memory (OCIMEM).
2c. APPS PBL loads XBL SEC (region #0) from the boot device to boot IMEM. XBL SEC is a QTI-signed ELF segment, which locks xPUs. XBL
SEC runs the security configuration in the EL3 mode
3. XBL SEC runs the security configuration in the EL3 mode and after it is done, it will inform SAIL hypervisor that APPS is ready for the phase
BIST-II on DPU, Camera, CamNoc, NSP, Ethernet, PCIe, and so on.
4a. XBL loader will take over control and continue to load multi-image signature and integrity check (MISC).
4b. XBL loader loads and authenticates XBLConfig image.
4c. XBL loader loads SHRM.
4d. XBL loader loads and authenticates MISC image.
4e. XBL loader loads and authenticates the AOP image from the boot device to the AOP CodeRAM.
4f. XBL loader brings the AOP processor out of reset.
4g. XBL loader will then load and authenticate the CPU firmware.
4h. XBL loader loads and authenticates Qualcomm® Trusted Execution Environment (TEE) into pseudo internal memory (pIMEM).
4i. XBL loader loads and authenticates Qualcomm® Hypervisor Execution Environment (HEE).
4j. Loads and authenticates XBL core from XBL image.
4k. XBL jumps to XBL_SEC and XBL SEC transfers execution to the Qualcomm TEE.
5. Qualcomm TEE transfers the execution to Qualcomm HEE, Qualcomm HEE runs at EL2 mode. Qualcomm HEE configures SMMUs and
provides virtualization support.
6. Qualcomm HEE transfers the execution to XBL core(region #3). It runs at nonsecure EL1 mode
7. Linux loader application (part of application boot loader firmware volume (ABL FV)) loads and authenticates the HLOS kernel with verified boot,
jumps to HLOS. HLOS runs at nonsecure EL1 mode
8-13. HLOS Peripheral image loader (PIL) driver loads all subsystems iris firmware (FW), camera FW, audio FW, sensor FW, turing FW, deep
learning FW images to DDR and configures the clocks and power rails, if necessary. HLOS PIL driver executes a secure channel manager
(SCM) call to Qualcomm TEE to request a secure PIL driver, authenticates images, and Qualcomm HEE brings each subsystem out of reset.
QAM8255P Cold Boot Flow – Phase 2 BIST
8255 bring up经验分享
这几天刚刚把新到的8255的硬件完成了bring up中间遇到了挺多问题趁着现在还有些印象抓紧记录一下。
8255 boot硬件框架 1由于功能安全的要求8255的boot流程和8155有很大的差异
2MCU和SAIL安全岛在boot的流程中需要多次握手且SAIL软件正常工作时才会放行MD(main domain)域的软件
3MCU-SAIL之间通信方式为UART同时SAIL会向外输出ERR_PIN1/PIN2来表明当前的异常状态
4SAIL和MD之间是通过mailbox进行通信他们之间也会做一些状态监控
5这里的MD主域指的是APPS即application processes我们常说的A核
6这里的MCU/VIP型号可能是TC397也可能是瑞萨的RH850系列
8255 bring up前期准备
bring up工作更像是阶段性的总结工作对这一阶段的工作成果进行验证和总结打个比喻你可以认为bring up是一次期中考试。前期工作做的好不好准备的充不充分将会在这个时刻得到充分的验证。所以越是前期工作准备的越充分bring up节点到来的时候成功bring up的难度就越小成功率就越高软硬件的问题也就越少。
硬件设计阶段
在前期的硬件设计阶段你需要
1参与硬件原理图设计的评审会
2检查review pin mux/HSIS
文档准备
软件需要提前阅读熟悉下面几个文档
QAM8255P IVI Boot and CoreBSP Architecture Technical Overview
Qualcomm® Snapdragon Ride™ Platform Automotive Reference (SA8775P/SA8650P/SRV1H/SRV1M/SA8255P/ SA8620P/SA7255P) Vehicle Interface Processor (Aurix) User Guide)
SoC-MCU Protocol – Boot and Safety Status Messages
MCU部分
1搭建好MCU的开发环境
2熟悉MCU芯片的各项功能编写控制GPIO驱动SPI/UART通信驱动
3熟悉MCU-SAIL之间的通信方式握手机制阅读相关的文档
SOC部分
编译环境准备
1准备好QNX的编译环境,下载好SDP包
2下载8255 SDK软件包
3编译好所有镜像文件
烧录环境准备
1安装刷机软件熟悉刷机流程
2准备好相关的刷机工具如USB线束等
8255 硬件bring up
MCU供电部分
MCU需要根据手册要求控制连接到PMIC的两个pin脚PWR_EN和RESET。
这里的前提是MCU自己本身的bring-up已经完成
这里我们就遇到了一些问题在bring up MCU的时候烧录完MCU的软件重新上电之后发现MCU的晶振并没有起振。做了一些列的检查之后发现硬件本身是没有问题的问题出在软件上这个MCU比较特殊需要配置一些参数才能触发外部晶振起振MCU内部自带一个时钟源。
电源检测流程图 8255 刷机
下面的每一个步骤都是在上一个步骤完成的前提下进行的
1需要确保MCU自身bring up 完成
2MCU完成对PWR_EN/RESET两个pin的控制之后需要硬件确认所有的供电是否正常才能进行下一步
3通过FORCE_USB pin强制让SOC进入下载模式
4SOC进入下载模式后连接USB CABLE到PC上这个时候应该在PC上识别到com设备如果没有观察到COM设备请回去检查前面的步骤需要注意的是进入下载模式的COM设备是不需要安装特别驱动就能识别到的
5打开烧录软件烧录nor-flashUFS需要注意的是在烧录nor-flash时需要先擦在写这里我们踩过坑UFS需要做一次provision。
6如果烧录成功那么刷机软件会有相应的提示否则会提示错误这里导致烧录失败的原因有很多比如DDR的问题线束的问题供电的问题等等可以说烧录成功是bring up成功的一个里程碑的节点。
MCU-SAIL握手通信
MCU-SAIL之间需要有一些通信和握手细节可以看下面这张图。 总结来说
1在MCU给SOC上电之后MCU需要通过uart来查询SAIL的bootstatus发送的数据帧格式长下面这样 具体来说是crccmd 0xB0 0x10 数据包长度64个字节 0x40 消息序列号从0开始每次递增1 data[0] ... data[58]. 下面是几个具体的发送帧示例 数据包的总长度是64个字节
2这个时候SAIL通常会返回一个256个字节数据帧来告诉MCU当前他的boot状态
一个正常的uart返回帧 一个异常的返回帧 需要注意的是异常的时候返回的数据帧格式可能不是完全按照 第2点的帧格式返回的但是也是可以解析出来哪里出了异常。比如上面返回的异常uart消息我们可以按照协议解析出来哪里出了问题 异常状态帧数据00 A0 10 OC 00 FO B1 40 00 00 00 00 E2 FF FF FF 00
MD第一行日志 SAIL第一行日志
QNX bring up
Android bring up
成功启动Launcher
