obm实际加载流程

虽然在NTIM中指定了obm加载地址为DDR地址0x80000000,同时固化在tavor cpu内部rom中的起机自检加载程序也能够识别出nand以及根据NTIM的ddr配置域对DDR做了正确的初始化,但是tavor cpu内部rom中的固化程序,仍然会先将nand读取出来的obm加载到tavor cpu的内部sram,所以这样直接导致了你的obm不能超过sram规定的53k大小,否则因为obm不能将自己完全加载到DDR中,因此好多工作应该交给blob去做,但是如果你非要在OBM中完成一些必须的工作的话,为了消除obm存在53k大小限制,特地制作了fattach工具,
1.首先生成一个几十k的trampoline,可以直接基于obm修改,主要完成将真正的大obm加载到DDR中
2.生成真正的obm
3.将trampoline汇编起始代码obm_startup.s的MajorMinor域前面一个NOP指令填入trampoline自己的大小,以便能够结合NTIM数据计算真正obm大小,进而完成加载工作
4.执行填充指令,将trampoline.bin的0x20偏移处填入trampoline.bin长度,
  随后追加4字节TAVOR_LINUX_NTOBM.bin长度,所以为TAVOR_LINUX_NTOBM.bin的原始内容,将上面的结果输入到TAVOR_LINUX_NTOBM.bin.out:
  fattach TAVOR_LINUX_NTOBM.bin.out -r0x20 trampoline.bin -a TAVOR_LINUX_NTOBM.bin

trampoline汇编起始代码obm_startup.s部分代码如下：
    ENTRY
        B ResetHandler
        B UndefinedHandler
        B SwiHandler
        B PrefetchHandler
        B AbortHandler
        NOP                        ; Reserved Vector
        B SaveProgramState         ; B IRQ Interrupt SaveProgramState
        B FiqHandler ; FIQ interrupts not anabled
    NOP
    DCD    MajorMinor, Date, Processor
    NOP

fattach工具网址：http://blog.chinaunix.net/u1/38994/showart_723573.html

以上理解有误：
tavor cpu就是根据NTIM的0x80000000地址对OBM进行直接加载的，至于为什么62k的OBM不能起机，问题还在查找中...
错误出在这里：

0x80000000 ~ 0x80040000    ---> DDR_DKB_OBM    ( 4*64=256K)    0 ~ 0x40000
0x80040000 ~ 0x80100000   ---> DDR_TLB        (12*64=768K)    0x80040000 ~ 0x80100000
0x80100000 ~ 0xC0000000   ---> DDR_Memory     (1023*1M)       没有作任何映射
添加gunzip2.c之后,
会定义
    #define __malloc_heap_buffer_max    (1024*1024)
    static long __malloc_heap_buffer[__malloc_heap_buffer_max/4];
    __malloc_heap_start = (char*)__malloc_heap_buffer;
    __malloc_heap_end = (char*)&__malloc_heap_buffer[__malloc_heap_buffer_max/4];
    #endif
有1M的0数据段空间,
在OBM/Build/startup.lds链接文件中:
...
    . = 0x5c009000;
    __bss_start = .;
        .bss : { *(.bss) }
    __bss_end = .;
...
所以这1M的数据空间__malloc_heap_buffer将在0x5c009000开始处,这明显示不可能的,
如果将0x5c009000去掉,变成如下方式：
/*    . = 0x5c009000;*/
    . = ALIGN(4);
    __bss_start = .;
        .bss : { *(.bss) }
    __bss_end = .;
同样存在问题,因为
这样将导致数据区在0x80040000~0x80100000之间,也就是在obm初始化bbs数据段，填充0时,将直接覆盖
MMU区域，所以也是不可行的，因此，对于大数据的分配，只能使用固定地址方式，没办法，唉！！！[gliethttp_20080603]