PowerPC P2040启动流程分析
PowerPC P2040启动流程
概述:
P2040采用powerpc架构,总共有四个e500mc核,独有的DPAA数据路径加速架构,5个Gbps或4 2.5 Gbps以太网控制器,支持10Gbps以太网(XAUI)控制器,十个5Ghz的SerDes通道,扩展性很强的Enhanced local bus controller(eLBC),Multicore programmable interrupt controller (PIC),两个4通道的DMA等。芯片资源与框架如下:
e500mc在P2040上支持最大1.2GHz的时钟,在P2041可以达到最大1.5GHz的时钟,P2040除常见的接口外,还支持高速的SRIO接口、eSPI、sDHC等。
启动流程简述:
从芯片手册中可得知,每个核开始执行的第一条指令都在地址0xffff_fffc处,boot window大小总共8MB,地址范围为0xff80_0000 ~ 0xffff_ffff,如下:
当e500mc core上电后,首先是加载PBL image,然后初始化spi,elbc,I2c接口等硬件配置,接着去找RCW source和pre-boot initialization commands(PBI):
1. 如果我们使用的是非硬编码[hard-code]的RCW data,则core去采样RCW配置管脚cfg_rcw_src[0:4]信号;当这个配置为0_1101时,如下图:
则表示rcw数据存放在非易失性的nor flash中(这个nor flash是连接在elbc控制器GPCM上,片选为CS0片选。如果是NAND flash启动,则是elbc FCM),则PBL会配置这个nor flash的对应的接口用作RCW-data和PBI-data接口,然后预引导程序pre-boot loader会elbc gpcm的br0和or0片选选中这个nor flash地址线上的地址为0(这里nor flash的A25被设置为地电平,所以nor flash的地址的bit25始终为0),从而读取外设nor flash地址0处开始的64 bytes的rcw数据到core的RCW状态寄存器RCWSRn中。----------------------------------------从这里,我们明白rcw文件时烧写在nor flash的0地址处的。
为什么pre-boot loader是去这个nor flash的0地址加载数据???见如下文档截图1
附:PBL首先会去加载指定接口非易失性外设中读取PBL image数据(这个PBL image就是RCW-data和PBI-data)。所以,我们的引导设备nor flash的最低地址的0~4K这些位置要放置rcw-data和PBI-data。RCW-data和PBI-data是放在一个文件中的,见下面截图对其格式的描述。
当加载完rcw数据后,PBL程序会根据RCW中的配置数据去配置系统各参数,比如mem rate等,并配置CPC的1M memory用作SRAM(片内RAM)(如果是nand flash启动,这个被用于存放u-boot 前4K代码)。
RCW数据和PBI commands如下:
然后根据RCW中的PBI_SRC的配置去加载PBI commands。这里rcw中,PBI_SRC=29,结合下图不难看出,PBI command 数据存放位置和rcw是在同一个外设。
返回上面的rcw文件的格式,我们也就知道了rcw和PBI数据是放在同一个文件中的,该文件有一个前导头A5A5。
2. 从RCW数据中,我们知道,我们配置的BOOT_LOC=29,即表示引导位置(uboot存放的位置)是在elbc GPCM控制器上,当PBI完成硬件的初始化后,这时候,系统只有L2 MMU的TLB1的entry0是有效的,它能将EA地址(有效地址,或者叫做cpu线性地址)0xfffff000~0xffffffff转换为PA地址(物理地址)0xfffff000~0xffffffff,这就是为什么我们在uboot的最先执行的代码块只能访问cpu最后4K内存的原因。
由于cpu复位后,这个时候,boot-window space(范围0xFF80_0000 ~ 0xFFFF_FFFF)的优先级高于CCSR space,所以这时候的LAW就是boot-window space时了。
那么这个boot-space 的TARGET-ID是谁呢???
我们返回去看rcw数据,这里的BOOT_LOC就告诉了PBL,在引导时访问的外设是eLBC GPCM,所以,只要地址命中这个boot-window space,那么这个操作的控制器就是eLBC(local bus controller)。
很显然。当PBL完成工作后,CPU发出预取指令的地址为0xfffffffc时,经过L2 MMU的TLB1的entry0,这个EA地址0xffffffc就转变成了PA物理地址0xfffffffc,而这个PA物理地址又命中boot-window,所有CPU就将外设片选目的地设为eLBC GPCM controller了。
这个eLBC GPCM controller有4对片选寄存器(基址寄存器和掩码寄存器构成一对),他们分别是BA0 & OR0,BA1 & OR1,BA,2 & OR2,BA,3 & OR03.
在系统reset后,默认片选的是BA0&OR0。
所以,我们要从nor flash上启动,则nor flash的片选必须接在这个BR0&OR0上。(如果是NAND flash,则是接在eLBC FCM controller的BR0&OR0上)。
到这里为止,我们的片选信号已经选中了目的设备nor flash。接下去就是取片内的指令了。
CPU片选后,会向地址总线上发送地址信号0xfffffffc,并且在控制总线上发送读控制信号。由于nor flash有片选信号,则其会对这个控制信号为读,地址为0xfffffffc的信号进行处理。
一般nor flash只有128M,那么这时候nor flash是如何找到cpu请求地址为0xfffffffc处的数据的呢?
这就要看原理图了。
从上图,我们可以看到nor flash(8-bit,64M)的地址线A00~A24分别连着CPU地址线的ADDR00~ADDR24,A25未连,保持低电平。
所以当CPU在地址线上发出地址0xfffffffc时,对于外设nor flash而言,它所看到的访问地址是0x1fffffc,即flash的第一个32M的最后4字节。
这样,CPU就取到了uboot的第一条指令了(是个跳转指令,跳转到这一页的首地址,级uboot的入口start_e500)
3. 接着,系统就开始巡行uboot代码了。
以上纯属个人观点,如有错误,欢迎指正。让我们共同成长,谢谢。
今天看了原理图,对于flash的寻址过程,现在补上。
cpu的地址线和nor flash的地址线的连线草图如下:
使用的flash是xxx系列,是16bit的flash,内存大小为128M,共1024个扇区,每个扇区64K bytes,地址引脚为A00~A25,其他参数,请去官网找这个datasheet。
我们这个图中,nor flash的地址引脚A00~A24分别连到CPU的地址引脚A01~ A25,这里错位连,是因为flash是16位的。
当CPU发出地址信号为0xfffffffc时,flash看到的地址引脚上的值为A24~A3全为1,A2~A0为0b110,A25 = 0b1(A25由拨码开关控制,假设为高电平),那么你索访问的flash的地址为0x3FFFFFE,即剩余2个word(16bit)的首地址,也就是这个flash的最后4个字节。
我们编译出来的u-boot.bin必须烧写在flash的最后512K上,打开u-boot.bin可以看到最后4个字节的值为(hex)4B FF F0 04,这是一条跳转指令,跳转到u-boot的入口start_e500.
下面附上flash芯片的memory-map截图:
上述内容引用了http://blog.chinaunix.net/uid-23782786-id-3944129.html,文章写的很好,在此引用一下。
关于片选基地址的问题,参见eLBC总结