linux驱动由浅入深系列:PBL-SBL1-(bootloader)LK-Android启动过程详解之一(高通MSM8953启动实例)

翻译 2017年06月14日 14:59:47

对于嵌入式工程师了解芯片启动过程是十分有必要的,在分析、调试各种问题的时候都有可能涉及到这方面的知识。同时这部分知识也是比较复杂的,因为其中涉及到芯片内部架构,启动各个阶段软件代码执行顺序,启动模式等等。下面以比较常用的Qualcomm MSM8953芯片的启动过程为例,进行宏观分析(大部分翻译了高通的手册^-^),下一篇文章进行代码分析。


处理器核心

可以看到MSM8953中的处理器有5个,分别为:

1,  APPS           Cortex A53 core,运行android

2,  RPM(Resource Power Manager)      CortexM3 core,主要用于低功耗应用

3,  Modem(MSS_QDSP6)        高通自有指令集处理器,处理3G、4G通信协议等

4,  Pronto(WCNSS) 处理wifi相关代码

5,  LPASS        音频相关

对映下面芯片硬件结构图中各个处理器的框图来看就很清晰了。

 

启动相关image介绍

1,PBL(Primary Boot Loader)   位于rom中,是芯片上电后执行的真正第一行代码,在正常启动流程中会加载SBL1。如果启动异常会虚拟出9008端口用于紧急下载(短接板子上的force_boot_from_usb引脚(MSM8953 为gpio37)到1.8v可以强制进入紧急下载模式)。

2,SBL1(Second BootLoader stage 1) 位于eMMC中,由PBL加载,初始化buses、DDR、clocks等,会虚拟出9006端口,用于不能开机时dump ram

3,QSEE/TrustZone  安全相关,如fuse

4,DEVCFG OEM配置信息(如OEMLock)

6,  Debug Policy 调试相关

7,  APPSBL      即为BootLoader,目前使用LK(littlekernel)

8,HLOS(High LevelOperating System) 即为Linux/Android

9,Modem PBL  即为Modem处理器的PBL

10,MBA(Modem BootAuthenticator) Modem处理器启动鉴权

 

启动流程

1,  系统上电,使MSM8953从上电复位开始运行。

2,  在Cortex A53中运行的PBL会加载:

        a,  从启动设备(如eMMC)加载SBL1 segment1到L2(即为TCM)

        b,  加载SBL1 segment2到RPM处理器的RAM中。

3,  SBL1 segment1会初始化DDR,然后完成如下加载:

        a,  从启动设备加载QSEE image到DDR

        b,  从启动设备加载DEVCFG image到DDR

        c,  从启动设备加载Debug Policy image到DDR

        d,  从启动设备加载HLOS APPSBL image到DDR

        e,  从启动设备加载RPMfirmware image到RPM的RAM中。

4,  SBL1移交运行控制权给QSEE。QSEE建立安全运行环境,配置xPU,支持fuse。

        a,  SBL1运行在AArch32(译者注:名词相关知识见文末“附件介绍一”)模式,而QSEE运行在AArch64模式。为了切换到AArch64模式,SBL1会启动重映射器,操作RMR寄存器,然后触发warm-reset,QSEE就能够运行在AArch64模式了。

5,  QSEE通知RPM启动RPM 固件的执行。

6,  QSEE移交运行控制权给HLOS APPSBL。

        a,  APPSBL只能在AArch32模式开始运行。

        b,  这时AArch32的运行模式切换是在EL3/Monitor模式(译者注:名词相关知识见文末“附件介绍二”)完成的。通过查看APPSBL的ELF头能够得知其需要运行在32位指令集架构下。EL3/Monitor模式改变到32位模式,然后再启动APPSBL。

7,  APPSBL加载、验证kernel。APPSBL通过SCM调用改变到HLOS kernel需要的AArch64模式。这和之前LK直接跳转到kernel运行是不同的。

8,  HLOS kernel通过PIL加载MBA到DDR

9,  HLOS kernel对Hexagon modem DSP进行解复位。

10,Modem PBL继续它的启动。

11,HLOS kernel 通过PIL加载AMSS modemimage到DDR

12,Modem PBL验证MBA然后跳转到MBA。

13,HLOS通过PIL加载WCNSS(Pronto)image到DDR

14,HLOS对WCNSS(Pronto)进行解复位以便Prontoimage开始执行。

15,HLOS通过PIL加载LPASS image到DDR

16,HLOS对LPSAA进行解复位以便LPASSimage开始执行。

 

下面是流程的简化图,其中区分了AArch32和AArch64位的QSEE/TrustZone

 

关于eMMC和DDR的初始化时间问题

从上面的描述中已经可以看清,为避免迷惑,在分离出来看看:

1,PBL中是含有eMMC驱动的,有访问eMMC的能力,自身运行在MCU内部SRAM中。

2,除了PBL程序的img在MCU片内ROM外,其余img均存储在eMMC中。

3,PBL首先从eMMC加载SBL1到L2(内部缓存并非DDR),SBL1同样运行在片内SRAM。

4,有SBL1初始化DDR各种时序后,DDR自此可用(eMMC一直可用)

5,再由SBL1加载其余各个img到DDR,然后按照linux的正常顺序启动^-^....


附加介绍一:AArch64、AArch32

AArch64ARMv8架构的一种执行状态。

为了更广泛地向企业领域推进,需要引入 64位构架。同时也需要在 ARMv8架构中引入新的 AArch64执行状态。AArch64不是一个单纯的 32 ARM构架扩展,而是 ARMv8内全新的构架,完全使用全新的 A64指令集。这些都源自于多年对现代构架设计的深入研究。更重要的是, AArch64作为一个分离出的执行状态,意味着一些未来的处理器可能不支持旧的 AArch32执行状态。虽然最初的 64 ARM处理器将会完全向后兼容,但我们大胆且前瞻性地将 AArch64作为在 ARMv8处理器中唯一的执行状态。我们在这些系统中将不支持 32位执行状态,这将使许多有益的实现得到权衡,如默认情况下,使用一个较大的 64K大小的页面,并会使得纯净的 64 ARM服务器系统不受遗留代码的影响。立即进行这种划分是很重要的,因为有可能在未来几年内将出现仅支持 64位的服务器系统。没有必要在新的 64位架构中去实现一个完整的 32位流水线,这将会提高未来 ARM服务器系统的能效。这样回想起来, AArch64作为在 Fedora ARM项目中被支持的 ARM构架是一个很自然的过程: armv5telarmv7hlaarch64。新的架构被命名为:aarch64,这同 ARM 自己选择的主线命名方式保持一致,同时也考虑到了 ARM架构名与 ARM商标分开的期望。

ARMv8-A 64位架构支持引入 ARM架构中,其中包括:

  • 64 位通用寄存器、SP(堆栈指针)和 PC(程序计数器)
  • 64 位数据处理和扩展的虚拟寻址

两种主要执行状态:

  • AArch64 - 64 位执行状态,包括该状态的异常模型、内存模型、程序员模型和指令集支持
  • AArch32 — 32 位执行状态,包括该状态的异常模型、内存模型、程序员模型和指令集支持

这些执行状态支持三个主要指令集

  • A32(或 ARM):32 位固定长度指令集,通过不同架构变体增强部分 32 位架构执行环境现在称为 AArch32。
  • T32 (Thumb) 是以 16 位固定长度指令集的形式引入的,随后在引入 Thumb-2 技术时增强为 16 位和 32 位混合长度指令集。部分 32 位架构执行环境现在称为 AArch32。
  • A64:提供与 ARM 和 Thumb 指令集类似功能的 32 位固定长度指令集。随 ARMv8-A 一起引入,它是一种 AArch64 指令集。 
    ARM ISA 不断改进,以满足前沿应用程序开发人员日益增长的要求,同时保留了必要的向后兼容性,以保护软件开发投资。在 ARMv8-A 中,对 A32 和 T32 进行了一些增补,以保持与 A64 指令集一致。

 

附件介绍二:Exception Level

• ARMv8定义EL0-EL3共 4个Exception Level来控制PE的行为.

ELx(x<4),x越大等级越高,执行特权越高

执行在EL0称为非特权执行

EL2 没有Secure state,只有Non-secure state

EL3 只有Secure state,实现EL0/EL1的Secure 和Non-secure之间的切换

EL0 & EL1 必须要实现,EL2/EL3则是可选实现

 Exception Level 与Security

Exception Level

EL0

Application

EL1

Linux kernel- OS

EL2

Hypervisor (可以理解为上面跑多个虚拟OS)

EL3

Secure Monitor(ARM Trusted Firmware)

Security

Non-secure

EL0/EL1/EL2, 只能访问Non-secure memory

Secure

EL0/EL1/EL3, 可以访问Non-secure memory & Secure memory,可起到物理屏障安全隔离作用

 

关于ARMv8架构的知识,推荐如下博客:

http://blog.csdn.net/forever_2015/article/details/50285865






sbl1启动代码分析

1. sbl1.s -- 汇编启动文件 sbl1程序的入口点在0xF800_C000,从memory map可以看出此地址位于L2 cache中,所以sbl1实际上是运行在L2 cache上的; ...

bootloader详解

4.2               Bootloader的总体设计 4.2.1        阶段设计 在前面的章节中,已经介绍过bootloader的启动可以是分阶段的。在设计时,我们将boot...

高通 MSM8K bootloader 之一: SBL1

高通 MSM8K bootloader 之一: SBL1
  • Fybon
  • Fybon
  • 2014年01月12日 17:57
  • 26008

ARM cortex a 的SDRAM (DDR)

下面介绍一下SDRAM的初始化工作。   SDRAM是同步动态随机存储器,需要初始化才能正常使用,但是可惜它的初始化太麻烦,里面涉及的东西也是非常之多,那么下面我们概括地分析一下它到底需要哪些初...

高通 MSM8K bootloader 之二: SBL1

续:高通 MSM8K bootloader 之一: SBL1 在 本章我重点关注SBL1,且主要描述我认为重点的几方面: 1、    CDT : Platform ID和DDR参数  2、 debug...
  • Fybon
  • Fybon
  • 2014年07月08日 15:11
  • 30436

高通 MSM8K bootloader : SBL1 .

一、 MSM8K Boot Flow                               图1: 高通MSM8K平台bootloader启动流程基本类似,但具体各平台,比如MSM8974、MS...

高通 MSM8K bootloader 之二: SBL1

http://www.xuebuyuan.com/2209890.html   高通 MSM8K bootloader 之二: SBL1   续:高通 MSM8K boot...

Android系统典型bootloader分析

1 、bootloader是什么? 简单地说,bootloader 就是在操作系统内核运行之前运行的一段小程序。通过这段小程序,我们可以初始化硬件设备、建立内存空间的映射图,从而将系统的软硬件环境带到...
  • Fybon
  • Fybon
  • 2014年01月12日 19:21
  • 4592

Android Init进程源码分析

Init 进程源码分析 基于Linux内核的android系统,在内核启动完成后将创建一个Init用户进程,实现了内核空间到用户空间的转变。在Android 启动过程介绍一文中介绍了Android...

linux驱动由浅入深系列:高通sensor架构实例分析之三(adsp上报数据详解、校准流程详解)

本系列导航: linux驱动由浅入深系列:高通sensor架构实例分析之一(整体概览+AP侧代码分析) linux驱动由浅入深系列:高通sensor架构实例分析之二(adsp驱动代码结构) li...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:linux驱动由浅入深系列:PBL-SBL1-(bootloader)LK-Android启动过程详解之一(高通MSM8953启动实例)
举报原因:
原因补充:

(最多只允许输入30个字)