Chinaunix首页 | 论坛 | 博客
  • 博客访问: 772974
  • 博文数量: 215
  • 博客积分: 291
  • 博客等级: 二等列兵
  • 技术积分: 1031
  • 用 户 组: 普通用户
  • 注册时间: 2010-05-12 18:17
文章分类

全部博文(215)

文章存档

2016年(16)

2015年(16)

2014年(123)

2013年(60)

分类: 嵌入式

2013-10-13 09:55:29

e500mc core上电后,首先是加载PBL image,然后初始化spi,elbc,I2c接口等硬件配置,接着去找RCW sourcepre-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-dataPBI-data接口,然后预引导程序pre-boot loader会elbc gpcm的br0和or0片选选中这个nor flash地址线上的地址为0(这里nor flash的A25被设置为地电平,所以nor flash的地址的bit25始终为0),从而读取外设nor flash地址0处开始的64 bytes的rcw数据到coreRCW状态寄存器RCWSRn中。----------------------------------------从这里,我们明白rcw文件时烧写在nor flash的0地址处的。

为什么pre-boot loader是去这个nor flash0地址加载数据???见如下文档截图1


附:PBL首先会去加载指定接口非易失性外设中读取PBL image数据(这个PBL image就是RCW-dataPBI-data)。所以,我们的引导设备nor flash的最低地址的0~4K这些位置要放置rcw-dataPBI-dataRCW-dataPBI-data是放在一个文件中的,见下面截图对其格式的描述。



当加载完rcw数据后,PBL程序会根据RCW中的配置数据去配置系统各参数,比如mem rate等,并配置CPC1M 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截图:

阅读(8336) | 评论(3) | 转发(2) |
给主人留下些什么吧!~~

yunyuaner2014-03-20 22:00:36

shaohui973 你好,文章分析的很好。
唯一有点疑问的是,你提到“我们返回去看rcw数据,这里的BOOT_LOC就告诉了PBL,在引导时访问的外设是eLBC GPCM,所以,只要地址命中这个boot-window space,那么这个操作的控制器就是eLBC(local bus controller)。”,我也是这样考虑的,但是在P2040RM手册中好像找不到确切的描述。你能否具体的分析一下?非常感谢你。

shaohui9732014-01-21 12:25:47

gaborfilter:顶一下!
我最近也在debug P2040板子。现在的问题是把soft-code RCW, u-boot, dtb...等Images烧到NOR flash后,如果是hard-coded RCW模式下加电, 在串口终端可以看到u-boot的启动信息,但是如果切换到soft-code的RCW模式下(BOOT_LOC = 1_1101 eLBC GPCM 16-bit NOR Flash),在TeraTerm下看不到任何东西。 我们自己编写生成的soft-code RCW 应该没有什么问题,因为在以前的板子是跑的通的。查看NOR flash上的内容,各个Image应该都已经写上了。 请问博主,如果假定RCW没有问题的话,有没有其他什么地方需要去检查? 

谢谢!

既然硬编码是好的,而软编码看来是Uboot还没起来,九成是软编码的配置问题引起的,你再仔细看看有关软编码的相关芯片资料。我对软编码的过程没研究过.

回复 | 举报

gaborfilter2014-01-14 03:12:26

顶一下!
我最近也在debug P2040板子。现在的问题是把soft-code RCW, u-boot, dtb...等Images烧到NOR flash后,如果是hard-coded RCW模式下加电, 在串口终端可以看到u-boot的启动信息,但是如果切换到soft-code的RCW模式下(BOOT_LOC = 1_1101 eLBC GPCM 16-bit NOR Flash),在TeraTerm下看不到任何东西。 我们自己编写生成的soft-code RCW 应该没有什么问题,因为在以前的板子是跑的通的。查看NOR flash上的内容,各个Image应该都已经写上了。 请问博主,如果假定RCW没有问题的话,有没有其他什么地方需要去检查? 

谢谢!