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.

OMAPL138 User Boot Loader (UBL)

Other Parts Discussed in Thread: OMAPL138, OMAP-L138

My question is regarding the User Bootloader to boot the OMAP L138 SoC from Logic PD's.  I have been experimenting with two different UBL. 

 

Method 1: Serial Flashing Utility

When using the Serial Flashing utility, I use the prebuilt ubl_OMAPL138_SPI_MEM.bin under OMAP-L138/GNU/ubl/ obtained from the download package obtained from the following site (http://sourceforge.net/projects/dvflashutils/files/OMAP-L138/v2.25/OMAP-L138_FlashAndBootUtils_2_25.tar.gz/download).  When using this UBL, I have no problems booting the ARM/DSP and executing ARM and DSP applications using peripheral drivers. 

 

Method 2: Code Composer Studio

When using the CCS method, I use the prebuilt ubl file included in the Davinci-PSP-SDK-03.20.00.12 package (images/bootstrap/omapl138/arm-spi-ais.bin), With this UBL, the ARM boots fine but the device peripherals (UPP is one of them) do not work properly.  This prebuild ubl file seems to not be built properly, so I'm trying to rebuild it now properly and would like some thelp in doing so.

Following the instructions from (http://processors.wiki.ti.com/index.php/GSG:_Building_Software_Components_for_OMAP-L1#Rebuilding_the_ARM_Side_User_Boot_Loader), I was able to successfully rebuild the ubl-spi.out object file.  Now, I'm not sure what settings to use on the format generator tool when converting to AIS format .  Maybe the prebuilt one was not built with the proper settings.  Should I check any of the boxes (i.e. Configure DDR, PLL1, etc) within the AIS Tool?  Is there a known good configuration I can use to get UPP peripheral working properly? 

 

Please advice.

 

  • Joe

    We are looking in to this. My initial suspect would be maybe the two ubls have different peripheral/modules that are being initialized in the device.c. It could be that the UBL with the Davinci-PSP-SDK-*  does not enable clocks to uPP , as uPP Linux drivers are not supported?

    When you say uPP is not reliably working, can you poke the UPP MMR to see if you are able to read back the UPPID register (offset 0x0) correctly in Method 2 (just trying to make sure that the uPP module clocks are enabled).


    Regards

    Mukul

  • You may be right, I am unable to read the UPPID register when booting the method 2 UBL form the Davinci-PSP-SDK package.  As expected, I was able to read it when booting with the UBL from method 1.   How do I enable the UPP module clocks, do I do this from the source code when buiding the UBL object file in CCS or is this done within the AIS format convertor tool?    

    Method 1 UBL: UPPID = 0x44231100

    Method 2 UBL: UPPID = 0x00000000

     

     

  • Ok, I'd recommend trying to enable uPP via the AISGEN tools , there is a check box General ( Configure PSC), on checking this you will get another tab to allow you to feed in the PSC arguments as specified in section 5.3.5 in the bootloader appnote

     

  • Thanks for suggestion, the UBL is now enabling UPP module.   

    I had an additional question about the U-Boot header.  The Uboot image header includes the following items:

    magicNum: 0xa1ace000

    entryPoint: 0xc1080000

    appSize: image Size

    memAddress: 0

    LdAddres: 0xc1080000

    I'm curious as to what the entryPoint and LdAddress represent? Does this represent the address of SDRAM where uboot gets copied to before it is executed? Can someone explain?