This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

some confusions from omapl137

Firstly I want to confirm the following points with your help

1, DSP UBL (AIS format)

        From TI's webs and documents I achieveed ,DSP UBL is just  a small loader for ARM UBL. right?

       So when power on omapl137,DSP Boots from on-chip ROM .Then according the BOOTCFG it loads DSP ubl to L2 Ram and execute it there? 

       DSP ubl would copy ARM ubl to L2 Ram and execute ARM ubl in L2  too? 

     Could we define DSP ubl  ourself? Any rules to follow? 

2、ARM UBL

       PLL initial ...  copy U-Boot  to L2  and execute uboot there?

      What's the exacte fuction of ARM ubl? Or we could define it ourself?

 

3、U-BOOT

     I got the uboot1.3.3,and it's  defined as the real bootloader for linux. So whether we could leave out of DSP ubl and ARM ubl? and  just  locate Uboot in the  external nandflash .     I have a try  of that  by the provided board_utilities\flash_writers\nand_writer,and omapl137 could boot and execute UBoot.

 

In  the datasheet of omapl137 ,

 EMIFA
* NOR (8-/16-Bit-Wide Data)
* NAND (8-/16-Bit-Wide Data)
* 16-Bit SDRAM With 128MB Address 

and  the Address :0x4000 0000 0x5FFF FFFF 512M EMIFA SDRAM data ,

So is it 128MB or 512MB?


Space
EMIFB
* 32-Bit or 16-Bit SDRAM With 256MB

0xC000 0000 0xDFFF FFFF 512M EMIFB SDRAM Data

256MB or 512MB?

Maybe I missed some comments

 

 

 

 

 

 

  • I believe your interpretation of the boot process is correct.

    Please note that ROM Boot loader (RBL) is the only piece of this puzzle that comes with the OMAP-L1 silicon (it cannot be changed); the partivular RBL included with OMAP-L1 is written such that DSP loads first (hence DSP UBL) and then loads ARM (hence ARM UBL); although you can write these UBLs yourself (and you may have to if you use different NAND flash part), you probrably do not need to.  That said, I must confess I am not too familiar with the DSP UBL, but I can explain a little about the ARM UBL (I Imagine DSP UBL story may be similar). 

    From an ARM boot-loader perspective, if you are using execute in place type memory (NOR flash), you can get rid of ARM UBL and load u-boot directly.  However, if you are using NAND flash (non-xecute in place memory), there is some basic configuration that needs to happen and hence UBL is required.  Normally, this UBL is quite small (~14KB), does minimal initialization and then loads u-boot to do the rest.

  • Hi Juan

                 As you said " you may have to if you use different NAND flash part",I have to write a nand flash based DSP UBL and  ARM UBL myself? Any examples or documents to support that task?

    Because the 137EVM only has SPI flash based  UBLs.

               Another little question I mentioned up : EMIFA has 128MB or 512MB adress for SDRAM  

     *                                                                               EMIFB has 256MB or 512MB address for SDRAM

  • Levone said:

                 As you said " you may have to if you use different NAND flash part",I have to write a nand flash based DSP UBL and  ARM UBL myself? Any examples or documents to support that task?

    This should be coming soon as mentioned in http://e2e.ti.com/forums/p/4843/17995.aspx#17995

    Levone said:

               Another little question I mentioned up : EMIFA has 128MB or 512MB adress for SDRAM  

     *                                                                               EMIFB has 256MB or 512MB address for SDRAM

    Thank you for pointing out thid discrepancy, after doing a little investigative work it appears this is a known issue and our data-sheet will get updated to reflect the appropriate size limitations, 128 MB for EMIFA abd 256 MB for EMIFB.