• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 382 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.

OMAP137 programming/bootloading

nickb
Prodigy 190 points

1)  Our current plan would be to conifgure the SPI1 interface to download the AIS image from an SPI flash device at startup.  Though we are not sure about how we would program this flash initially.  Would we be required to program it before board assembly or is there an accepted practice for programming it in circuit, such as with the JTAG interface using a tool such as this.  http://ricreations.com/JTAG-Software-Downloads.htm

2)  My assumption is that a single AIS image would be loaded into FLASH and subsequently RAM which will contain the code for both the ARM and DSP cores.  Looking at the AISgen tool, I don't see any way to include 2 object files.  So my second assumption is that a single object file must be generated in CCS for both core applications.  Is there documentation that described how to do this?

3) If there is only one image and one corresponding object file for both core applications, how is the "line of demarcation " set in the code to seperate what code belongs to the DSP and what belongs to the ARM?  Is this handled by the linker?  Is there documentation to support this as well?

4) Once the bootloader pulls in the code from ROM, what memory location is it saved to?  Does the code begin in the  256K L2 RAM of the DSP or the 128K shared ram?   And does it automatically overflow in to external SDRAM?

5) Where can I find documentation about how the DSP should instruct the ARM to start up?  How does the ARM know what memory address to begin execution at?

5) We are also not planning to use Linux as an OS for the ARM core but rather plan to use the separate instances of SYS/BIOS (DSP/BOIS) for each core.  We do not have a need for a file system, etc.  Is there documentation that would help us get started with building an application for the ARM core using the SYS/BIOS?

  • 0
    Prodigy 190 points

    I've looked through more of the documentation, and here is what I "think" I understand:

    With the conventional Linux install method, the external ROM contains 3 "files":  An AIS image of the DSP Boot loader, a binary ARM bootloader, and a binary of UBoot.

    After coming out of reset, the bootloader in the DSP ROM (which is not accessible to either application) checks the boot pin configuration in the BOOTCFG register in the SYSCFG module.  In our situation, it would begin to load the DSP UBL AIS file from the beginning of the SPI Flash in to the DSP L2 cache/RAM.  

    The DSP UBL will copy the binary ARM UBL from the next block in the SPI Flash into RAM, sets the ARM reset vector and starts up the ARM core.  What memory location is this saved to and how does the DSP UBL know where in the SPI flash to start copying the ARM UBL?

    I think the DSP is disabled and the ARM starts at its reset vector after having been enabled.  The ARM UBL then sets up the PLLs and SDRAM.  It copies the Uboot from the SPI Flash into SDRAM and transfers control to the Uboot.

    At this point a user must instruct the Uboot to download the Linux image via Tftp over a Ethernet connection.  Is there a way to automate this processes if user interaction is not possible?  Can the Linux image be sourced from an external flash as well?

    Then I assume Uboot transfers control to Linux and somehow the Linux application must load the DSP application and start up the DSP core again.  Is this correct?  If so, how is this done?

     

    If I'm going to get away with not using Linux, then I would have to modify the DSP and ARM UBLs.  I have found the source in the Linux Platform Support Package, so I assume this is doable.  I'd like to modify the DSP UBL so that instead of going to sleep/disable when turning on the ARM, it will then copy the DSP application image from the SPI flash into SDRAM and begin execution there.  

    The ARM UBL would then just download the ARM application binary instead of Uboot and begin its execution there.

     

    Is this a more correct understanding of how the boot process works/could work and is all of this feasible?

     

  • 0 in reply to nickb
    TI__Mastermind 27585 points

    "The DSP UBL will copy the binary ARM UBL from the next block in the SPI Flash into RAM, sets the ARM reset vector and starts up the ARM core.  What memory location is this saved to and how does the DSP UBL know where in the SPI flash to start copying the ARM UBL?"

    You can find that in the source for the DSP ubl. In the device.h there are the following #defines:

    #define DEVICE_ARM_UBL_LOAD_ADDR        (0x80000000)
    #define DEVICE_SPI_BOOT_ARM_UBL_OFFSET    (8*1024)
    #define DEVICE_SPI_BOOT_ARM_UBL_SIZE    (16*1024)

    "At this point a user must instruct the Uboot to download the Linux image via Tftp over a Ethernet connection.  Is there a way to automate this processes if user interaction is not possible?  Can the Linux image be sourced from an external flash as well?"

    You should be able to put those commands in the environment variables that get executed automatically by Uboot. Yes as long as the Linux image can fit in the SPI flash, you can load the Linux image from there.

    Your approach of having both the DSP and ARM load executables without using Linux would work as well.


    Jeff