浅谈芯片的bringup

来源：缪航


一，浅谈芯片研发
谈到芯片，中美贸易战的中兴事件引发了社会对芯片行业的大量关注，本文不做累述芯片行业现状、痛点，只给大家展现芯片行业纯技术的某一面。
先以芯片研发流程开篇，下图为个人理解的芯片研发流程图。
图1  芯片研发流程图

任何产品都有面向群体，芯片也不例外，面向手机、相机等消费类电子产品，面向机器人、行业自动化等工控类设备，目前主流芯片偏向消费类电子。芯片的面向最终都是转换成规格和需求，需求方或领导层先提要求，架构工程师、项目经理、项目管理、各技术组组长坐在一起讨论拍板出我们芯片所需要的规格list和需求list，这是第一步。

接着，项目管理、经理负责资源组和人员的调配。技术方面，架构师是重点，对需求和规格list进行细化到具体，搭建架构，架构的分析与建模，仿真出可行性，比如整个集成芯片划分为几个模块、CPU选型、主频、总线划分等。如果涉及到高层次算法，需要完成芯片中数字部分的高层次算法，为硬件提供一个正确的软件功能模型，通过大量的高层次仿真和调试，为RTL实现提供总体性的设计指导。

芯片从功能上来看，是由各个IP综合集成出来的。国内多数集成芯片都是采购IP，自研IP多数为小IP，一般ARM、DSP、普罗米修斯等CPU类IP多为采购，当然也不乏大公司自研DSP、超级CPU等，DDR PHY、SD PHY等高速接口IP也多为采购，国内算法能力很强，目前ISP、GPU、CNN、CODEC等都有大公司在自研。

集成和实现都是RTL阶段，CRG（Clock Reset Gate）就是在这个阶段设计的，另外系统、总线、安全等相关控制也是RTL集成和实现的重点。集成将所有IP集合，安排和分配好脉搏、功能信号。实现靠近实际，RTL实现之后就是软件人员所看到的寄存器手册。集成阶段非常重要的是时序，尤其是异步时序，所以需要验证。

验证由根据平台划分为EDA验证、FPGA验证、ZEBU验证等。嵌入式接触比较多的是FPGA和ZEBU验证。EDA验证是模拟的环境上验证的，但其最接近最后的AISC，但仿真毕竟是仿真，离实际差异还是很大；FPGA只能做前端验证，它最真实，也是验证速度最快的，但其频率的限制、模拟器件无法模拟，导致很多功能并不能验证的很完整，CRG 、power control、pinmux根本无法验证，，各类高速接口的PHY无法真实测试，FPGA的CRG一般尽量按比例集成；ZEBU平台也是基于FPGA上集成的，但其可完全模拟出时序关系，不过也存在FPGA的其它通病，而且其验证速度比EDA更慢，跑一个复杂点的验证用例可能需要一天。各大仿真或验证平台各有优缺点，但实际的芯片并没有验证环境那么理想，有corner、生产工艺、功耗散热、DDR稳定性等各种因素，导致最后的芯片问题百出。需要注意，验证并不是固定顺序的，任何一个阶段都需要。

前面陈述的都属于前端，国内后端不甚重视，总体上按顺序有数据整理提供、布图、布局、preCTS（setup优化）、CTS（clock tree setup）、postCTS（进一步优化）、布线、post布线、ECO（进入此过程再无法修改数据）、finish、signoff（检查和验证）、tapeout（设计数据传递给制造方）。

最后就是流片生产，多数在台积电、台联电，嵌入式在此过程需要准备回片bring up的代码，重点在CRG、power、高速IP等仿真无法覆盖完整的代码。

然后等芯片回来，芯片一旦回来，就是嵌入式的大头戏，回片bring up阶段，所有人都在关注着这最后一炮的成功与否，芯片就是一锤子买卖，题外话的说，芯片的回片现场非常类似robocon比赛现场。

以下以常用的ARM cortex-A为主的SOC系列芯片bring up为例。本文纯手敲，如有出入，自行参考。

二，整体bring up流程

回片bring up工作非常关键，但芯片是否如意并不是嵌入式能决定的，虽然前期有负责FPGA、ZEBU验证起到验证作用，但芯片行业的核心不在嵌入式，我们只是检验大家成果的一面镜子。但换个方向思考，嵌入式是处于最底层的软件，对芯片负责，如果过了嵌入式把问题释放出去，那就会收到无数的投诉、黑评等。回片工作流程如图2。
图2  芯片回片bring up流程

回片工作基本上所有IP的冒烟都需要两个前提，coresight(debug/trace)和DDR。图2中还少了SOC的基本功能冒烟实现这个前提，比如CRG、power manager、安全等，由于其牵涉到每一模块，故不加入图中。DDR冒烟非常关键，通常三大巨头公司海力士、镁光和三星都需要测试，开始时有bypass training方案，高频方案等，与产品实际性能需求有关，后面为了稳定性还得进行不同corner芯片、高低温下的压力测试。

DDR之后就可以并行工作了，此时需要根据芯片应用场景进行对应IP功能冒烟，图2提供了多种场景的bring up实现，最基础的kernel的启动、sensor-显示通路、图像识别和处理、编解码等。本文重心在系统的bring up介绍，不展开场景介绍。

三，系统的bring up

系统的启动流程是bootrom->bootloader->kernel->filesystem，具体可参考图3。
图3  某芯片启动流程详解图

1，bootrom
bootrom是系统之始，也就是第一份代码，例如BIOS就是windows的bootrom。大部分嵌入式开发者或者谷歌BSP（Board Support Package）一般最多深究到bootloader，忽略bootrom也是因为它是随着生产固化的，与芯片本身息息相关，硬件工程师关注比较多，软件不可更改，也没必要修改。但如果想对芯片真正了解，必须对bootrom的代码甚为了解。

bootrom里面做了以下几个事：
(1)主CPU boot，一般bootrom只启动单核，并配置处于次低频态；
(2)切入slow或normal模式；
(3)efuse相关位检测；
(4)如果涉及到，调整芯片的安全相关属性；
(5)如果涉及到，将必须的电压打开；
(6)配置debug串口，提供开发者调试；
(7)检测是否非默认引导方式，并引导，有flash/emmc、USB fastboot、ETH等引导；
(8)根据所选方式引导，跳转到RAM起始地址。

值得注意的是既然有多种引导方式，那就可以用以太网、USB甚至串口传输boot程序给芯片，让其运行自己想要的非主线分支程序，比如fastboot功能的实现、安全属性强行修改等。当然，芯片安全问题不用担心，efuse里会有加密信息，bootrom会去校验你的FW，俗称签名。

2，bootloader
bootloader非常关键，是底层软件大展身手的地方。bootloader最终目的是启动内核，至于内核是linux、rtos或者其它OS都可以。bootloader也并不止uboot，还有little kernel、redboot、armboot等，甚至可以自己手写，个人接触比较多的是uboot和little kernel。uboot适应性高，对成熟芯片可以做到是快速上板，对新开发芯片能做到参考作用，但其内容繁琐，全新芯片开发难度比little kernel更大。此处以更为通用的uboot展开，讲述bootloader具体干了什么事情。

Uboot，即universal-bootloader，分为两个阶段，SPL阶段和uboot第二阶段，划分两个阶段是因为片内RAM的价格高昂，且大小一般都只有几十上百K。uboot为了适应各种平台适应各种OS，越到后面版本越来越庞大，为此设计者将uboot一分为二，将初始化flash/emmc并把存储的程序搬运到片外RAM的小uboot称为SPL，将启动内核的大uboot放入片外RAM（一般是DDR，即SDRAM），采取图4流程启动OS。

Uboot也支持单阶段启动或者直接flash启动，但都非常少用，个人曾强行简化uboot到100K，但把uboot很多模块给去除了，比如交互界面、哈希表，导致代码完全像重写，后面弃用不了了之。
图4  uboot启动流程

图4是常见的一种uboot流程，由于是两片内存空间，两个阶段都需要做系统的初始化工作，异常向量表、堆栈、BSS、data、heap、代码段，值得重视的是SPL在底层初始化阶段是无BSS、data、heap段的。

SPL阶段的流程很简单：
(1)ARM的boot，SP、exception设置，关闭MMU、Icache、Dcache；
(2)初始化CRG，电压、频点和工作模式初始化；
(3)初始化debug串口，初始化FLASH，初始化片外RAM；
(4)如果有需要，release其它核或其他CPU，如DSP、cortex-M系列ARM等；
(5)如果有安全需要，boot TrustZone OS；
(6)Relocate堆栈、GB等到第二阶段uboot；
(7)直接跳转到片外RAM执行第二阶段。

第二阶段就是uboot真正起作用的阶段了，其主要流程见图5。uboot的核心在于boot起各类kernel，但它本身不止于此，它还有改写flash内容，对内存映射区域改写，修改启动环境参数等功能，实现都在图5的最后console界面里，俨然是一个小型的裸机交互系统。
图5  第二阶段uboot流程

这里只浅谈下核心部分，也就是起kernel功能。uboot启动的内核为uImage或者zImage，也可以是压缩包，内核格式一般是由两部分组成：真正的内核和内核头部组成，头部中包括内核中的一些信息，比如内核的种类，加载地址，入口地址。以linux为例：uboot在接收到启动命令后，要做的主要是，读取内核头部信息，移动内核到合适的加载地址，启动内核，执行do_bootm_linux。

do_bootm_linux主要做的为，设置启动参数，在特定的地址，保存启动参数arg，传递设备树dtb，以及根文件系统rootfs信息，解压kernel并放置到指定片外RAM位置，跳到入口地址，启动内核。

3，Kernel
大部分嵌入式都是在kernel之上做着辛勤的工作，调用各种标准的写驱动接口，基于各种驱动做开发，标准的代码接口，比如linux的io control、debugfs、sysfs、用户态程序，再如rtos的任务创建挂起、信号量、邮箱等等。本节非常浅面的谈谈kernel的bring up过程。以linux为例，主要流程如图6。
图6  linux启动流程

首先，从bootloader接管控制权后，首先读入根目录下的内核文件，该过程对设备树进行了扫描注册。内核文件加载以后，就开始运行第一个程序linuxrc或init，它的作用是初始化系统环境，这个进程的PID为1，后面称之为init进程。这时候，许多程序需要开机启动，这些在Windows叫做“服务”（service），在Linux就叫做"守护进程"（daemon），init进程的一大任务，就是去运行这些开机启动的程序。但是，不同的场合需要启动不同的程序，linux允许为不同的场合，分配不同的开机启动程序，这就叫做“运行级别”（runlevel）。接着，每个运行级别的运行程序在/etc目录下面，都有一个对应的子目录rc*.d，选择后通过init.d链接启动。这时，开机启动程序加载完毕，然后要让用户登录，有三种登陆方式：命令行登录、ssh登录和图形界面登录，为了方便一般用ssh登录或者直接默认登录某user用户来方便开发者调试。至此，Linux的启动过程就算结束了。

4，filesystem
文件系统的格式极其多，每种格式都有独立的生成标准，最常用的格式，ext4、fat32，一个是linux常用，一个是windows常用，占了大片江山。所有格式文件系统说白了都是对操作系统用于在存储介质上组织文件的方法。存储设备不管是易失的RAM，还是不丢失的ROM，只要可以提供标准的initialization、read、write，都可以对某个区域或者整个区域进行格式化。

比较常见的文件系统格式化设备有SD卡、硬盘、EMMC等ROM设备，一般不用于RAM中。rtos一般是等系统起来后通过进程去管理文件系统，不会用到RAM文件系统。但linux不同，在boot loader 配置了某些参数的情况下（这也是常规做法），它的启动不会一来就加载ROM的文件系统，这就涉及到一个中间系统，称为initrd、ramdisk或者initramfs，后面简称initrd。而最后我们敲shell命令的界面所在文件系统称作rootfs，也即根文件系统。以下浅要介绍linux启动所用的到文件系统。

在linux内核启动前，boot loader 会将存储介质中的initrd文件加载到片外RAM，内核启动时会在访问真正的根文件系统前先访问该内存中的initrd 文件系统。内核启动被分成了两个阶段，第一阶段先执行initrd 文件系统中的某个初始化文件，完成加载驱动模块等任务，第二阶段才会执行真正的根文件系统（rootfs）中的init 进程。

linux是基于unix的系统，unix的设计之初有一哲学核心思想，即“一切皆文件”，在linux上的体现就是rootfs。简单的说，rootfs是一个带有linux整套内核体系结构和硬件设备注册的文件系统，可以看到设备节点，用户进程，debug信息等。相信linux驱动工程师了如指掌。不管是rootfs还是initrd，其实都是一样的文件形式，可以做成同源。rootfs的生成比较有名的工具叫做busybox，busybox自带有许多设备操作和shell的库。在这介绍两个开源代码，一个叫做buildroot，一个叫做yocto，都是基于busybox工具上的rootfs生成项目，都具备可视化可裁剪定制界面，库自选，busybox还带有许多boot kernel相关开源代码，同样initrd也可通过它们获得。

至此，芯片的系统bring up结束。接下来就是各模块的驱动开发，和各种业务场景的实现了。

版权声明：本文来源网络，免费传达知识，版权归原作者所有。如涉及作品版权问题，请联系我进行删除。
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧  END  ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧
关注我的微信公众号，回复“星球”加入知识星球，有问必答。

点击“阅读原文”查看知识星球详情，欢迎点分享、收藏、点赞、在看。