No os hardware boot

来自百问网嵌入式Linux wiki

第01节_XIP的概念

who runs programe? 我们常说运行程序,程序通过cpu运行,保存在存储设备上。

存储设备有多种,如下分类

 
|----hard dsik
|----sd card
|----Flash
	|----Nor Flash
	|----Nand FLash

无论是哪一种存储设备,内部的抽象结构是一样的,如下图所示 No os hardware boot chapter1 001.jpg


比如,第0个存储空间存放的0x31这个数据,第一个存储空间存放的0x30这个数据 如何访问存储空间,通过访问每行左上角的编号去访问里面的数据,称这些编号为地址,而编号对应的数值,称为数据

如何访问存储设备(就是为了读写某一个存储空间)?

  1. 发出地址
  2. 读数据(从设备里面范围给CPU)/写数据(从CPU发给存储设备)

地址和数据如何传输?
如果地址和数据直接来自CPU,或者说数据直接发给CPU,那么这个存储设备,我们就称为XIP device(cpu可以直接访问存储设备)

No os hardware boot chapter1 002.jpg

按照正常的执行流程,cpu和存储设备之间还会有内存控制器

U盘的内部存储结构

如何访问U盘的内部存储结构 U盘对外只有5条线,cpu不可能直接发数据给u盘的,中间需要引入一个USB控制器 cpu可以直接访问到usb控制器,通过usb控制器发送符合U盘传输协议的信息,间接的访问U盘数据。所以usb设备不是XIP device

如何识别一个存储设备是否是XIP设备? 1.CPU可以直接寻址的设备。 2.看是否有分开的地址总线和数据总线。


CPU通过SPI控制器才能得到spiflash中的数据,所以,spi flash不是XIP device


No os hardware boot chapter1 003.jpg

对于SD card也是类似的,CPU需要通过SD/MMC Controller才能把地址发给SD card,也必须通过SD/MMC Controller得到里面的数据并执行,所以SDcard不是XIP device

第02节_嵌入式系统硬件组成

一句话引出整个嵌入式系统: 支持多种设备启动

问题引出:

a. 系统支持SPI FLASH启动.
   这意味着可以运行SPI FLASH上的代码
   the system can boot from spi flash,
   so it needs to run code on spi flash
   
b. 但是SPI FLASH不是XIP设备, 
   cpu无法直接执行里面的代码
   but the spi flash isn't xip device,
   cpu can't run code on spi flash directly

   问题来了,
   CPU如何执行SPI FLASH上的代码?
   一上电, CPU执行的第1个程序、第1条指令在哪里?
   
   how can the cpu run the code on spi flash ?
   where is the first code run by cpu, when power up ?

答案: a. ARM板子支持多种启动方式:XIP设备启动、非XIP设备启动等等。

  比如:Nor Flash、SD卡、SPI Flash, 甚至支持UART、USB、网卡启动。
  这些设备中,很多都不是XIP设备。
  
  问:既然CPU无法直接运行非XIP设备的代码,为何可以从非XIP设备启动?
  答:上电后,CPU运行的第1条指令、第1个程序,位于片内ROM中,它是XIP设备。
      这个程序会执行必要的初始化,

比如设置时钟、设置内存; 再从"非XIP设备"中把程序读到内存; 最后启动这上程序。

   猜测: ARM芯片内部有很多部件,这是一个片上系统(System on chip),

比如有: cpu rom ram memory controller --- ddr sd/mmc controller --- sd card spi controller --- spi flash usb controller --- usb storage device uart controller ...... interrtupt controller


b. 跟PC的类比

  CPU      ---- 单独的芯片
  启动设备 ---- BIOS芯片
  DDR      ---- 单独的可拔插式模块
  存储设备 ---- SATA硬盘,可拔插
  usb controller ...

第03节_SOC框架

tu 1.............................


主芯片内部有ROM,ROM程序协助从非XIP设备启动。 以SD卡启动为例。

CPU只能运行XIP设备中的程序

ROM程序做什么? 显然:ROM需要把SD卡上的程序读到内存里(片内RAM或是片外的DDR)


ROM程序要做的事情: a. 初始化硬件

  初始化时钟,提高CPU、外设速度
  初始化内存:DDR需要初始化才能使用
  初始化其他硬件,比如看门狗、SD卡控制器等
  

b. 从外设把程序复制到内存,拷贝过程无外乎三个要素:

 
 src()      dest(目的)             len(长度)
 |		  |			|
 |		  |			|->长度需要指定
 |		  |---->拷贝到ram 或者DDR只需要指定一个地址即可
 |			  |b.2 内存那么大,把程序从SD卡等设备,复制到内存哪个位置?复制多长?
 |			  |-->烧写在SD卡等设备上的程序,含有一个头部信息,里面指定了内存地址和长度;或
 |			  |-->不给客户选择,程序被复制到内存固定的位置,长度也固定。
 |---->从哪一个设备拷贝代码
	 |b.1支持那么多的启动方式,SD卡SPI FLASHUSB DISK,怎么选择?
	 |-->通过跳线,选择某个设备;或
	 |-->通过跳线,选择一个设备列表,按列表顺序逐个尝试或
	 |-->不让客户选择,按固定顺序逐个尝试

b.3 程序在SD卡上怎么存?

   原始二进制(raw bin),

或 作为一个文件保存在分区里 解释如下图

假设为1GB SD卡,在512前面的地方有分区表,表示U盘或者SD卡分为几个区

tu2...............


可以把程序或者头部加程序烧写在某一个地址处 row.bin,也可以作为一个文件通过window访问拷贝到某个分区内file.bin


使用那种方式来保存启动代码,由Boot Rom能力决定 如果Boot Rom能力比较强,可以识别分区,解析文件系统,那么他可以读取分区里的程序,就可以支持文件方式存储那些启动程序

如果Boot Rom能力比较弱,只能读取SD卡 U盘里的原始数据,没有能力去解析分区,解析文件系统,那么就支持raw bin方式



c. 执行新程序 跳到目的地执行程序

第04节_具体单板的启动流程