当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截图：
