• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 1789 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

UBL and sfh_OMAP-l138.exe utility for C6748

Michael Greenspan
Intellectual 575 points
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

I am using the C6748 on a board of our own design.  So far, using and evaluation card with lots of memory, I have used UBL and u-boot and it all works very well.  However, on our custom card, I will not be able to used u-boot.   My question is if the UBL is of any use, or whether I simply start from scratch.   I cannot find any documentation that says what the UBL actually does.  Is there any documentation of UBL itself?

My hope here is to use the standard UBL and that in place of u-boot, I can place my application use of  sfh_OMAP-l138.exe to burn it to SPI Flash.

There are two specific questions.

 1) Is there a way to update just the application without erasing and reprogramming the UBL?  According to the command line help, it looks like I have to reflash the UBL every time I update the application (u-boot or other) even if the UBL has not changed.  Is this correct? If so, is there any reason for this?  In the wiki located at

http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138#Serial_Flasher_Options

there is a cryptic statement:

"Flash the memory with a UBL and application image - This will place a UBL at address 0x0 of the flash and an application image, such as u-boot, at address 0x10000. In general, a UBL is not required, and this mode is only used when restoring the default flash contents, as explained in the following section"

..\sfh_OMAP-L138.exe -flash <UBL binary file> <binary application file>

What does that mean "in general, a UBL is not required"?

2) Can you give any hints as to the format required for the binary application file?  Is it just a binary image of what will be place in memory? 

3) Is the bootloader in the starterware similar or the same as the UBL?

Thanks,

  • 0
    TI__Guru** 116100 points
    Hi,
    You don't want to use UBL, we can use u-boot directly from flash.
    Download the latest MCSDK Linux (kernel 3.3) package for OMAPL138.
    Just build the uboot with SPI/NAND flash support as per your custom board configuration and need to convert u-boot.bin to u-boot.a is file to flash either SPI or NAND flash.
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 575 points

    Perhaps I was not clear enough in my original post.

    We do not wish to use u-boot.  It is not possible on our target board.

    What we wish to do is to use sfh_OMAP-L138 with the -flash flag, which, according to the help, will write two files to our SPI flash.  The first being a UBL (secondary boot loader) in AIS format and the second being an application image in binary format. 

    This process works very nicely, as long as the binary application image is u-boot.bin that was built to work with our evaluation module.  It writes the UBL to SPI flash starting at address 0, and the u-boot.bin it writes to SPI flash at address 0x100014, with a 20-byte header at 0x10000.  Now, there are two things that are not clear to me, and so I am asking two questions.

    First question...is there a way to use sfh_OMAP-L138.exe to write only the binary application image, without touching the UBL which was already written into the SPI flash.

    Second question...can you provide details about the standard UBL that you provide. What exactly can it do?  If I understand correctly, it reads the application image from SPI flash to the load address specified, then transfers control to the entry point specified?  Can the UBL with the OMAP-L138 also be used to load and run code for the DSP, or only for the ARM? 

    Thanks.

  • 0 in reply to Michael Greenspan
    TI__Guru** 116100 points
    Sure, I will read completely and reply to you.
    Before that, are you running Linux OS or ARM application or DSP application ?
    Linux OS with DSP application through DSP/LINK or SYS/LINK or IPC ?
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 575 points
    We are not running any Linux. The entire application is running on the DSP. The ARM has no function other than to boot and start the DSP. In the final application, will use C674x, but for development we had to use OMAP L138.

    My question is really a very simple one.
  • 0 in reply to Michael Greenspan
    TI__Guru** 116100 points
    Thanks, it helped me to understand your requirement.


    Second question...can you provide details about the standard UBL that you provide. What exactly can it do? If I understand correctly, it reads the application image from SPI flash to the load address specified, then transfers control to the entry point specified? Can the UBL with the OMAP-L138 also be used to load and run code for the DSP, or only for the ARM?

    To understand more about UBL stuff, you have to know about the boot sequence of ARM boot device for linux booting.

    ROM code will be copied into internal RAM once you booted the device, ROM code read the boot pins and initialize the peripheral according to boot mode. And RBL code read the content from selected flash devices like NAND,NOR,SPI etc., and copy the UBL code into internal RAM.

    UBL code will be built in small size which could run in internal RAM and needs to be initialize the external RAM say, DDR, to run big size applications like u-boot, kernel etc.,

    In your case, UBL should wake the DSP and initialize the DDR, so linux based UBL is not mandatory here.

    Please refer to the following wikis.

    omappedia.org/.../Bootloader_Project
    processors.wiki.ti.com/.../Boot_Sequence


    We are not running any Linux. The entire application is running on the DSP. The ARM has no function other than to boot and start the DSP. In the final application, will use C674x, but for development we had to use OMAP L138.


    If this is the case, then I would like you to suggest to use the "starterware bootloader" to boot the DSP application.
    Here, starterware ARM bootloader would initialize the DSP & wakeup, DDR initialization then it would run the DSP app on DDR.

    Please refer to the following TI wiki page.

    processors.wiki.ti.com/.../OMAPL138_StarterWare_Booting_And_Flashing

    Starterware download:

    software-dl.ti.com/.../index_FDS.html

    Please let me know if any additional questions.