• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 2014 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.

Boot process on OMAP-L137

mdanek
Prodigy 50 points

Other Parts Discussed in Thread: OMAP-L137, SYSBIOS, OMAP-L138

Hello, I am currently working on the new controller based on OMAP-L137. The aim of my work is to provide technical and SW background for the main application. It among others means, to create bootloader, that will be able to run the final application on both DSP and ARM cores.

I work with CCS 5.2.1 (latest version) and SYS/BIOS 6.33.5.46. I also uses EDMA3 low lever driver, NDK and PSP.

I imagine the process of booting by this way:

1) DSP will start the DSP bootloader from the first SPI flash.

2) Bootloader starts as SYS/BIOS application, configures FPGA, displays some information on LCD and it waits for any communication on ethernet or etherCAT communication channels. Using of the communication makes possible to upgrade main application SW stored in the second SPI flash (or another media).

3) If no communication occured, bootloader downloads main app for DSP and ARM from the second SPI flash (or another media).

4) Bootloader enables ARM and thus the main application in ARM core.

5) Bootloader jumps to the main application in DSP core.

6) Not, the main application is executed in both ARM and DSP core.

It looks quite simple, but there are some problems to solve:

There is already running SYS/BIOS bootloader application in DSP core. How to start a new SYS/BIOS main application?:
- how to generate the images of those DSP and ARM main aplications? I suppose, they must be realocated to a different RAM area. How to do it?
- how to exit bootloader SYS/BIOS application properly and start a new SYS/BIOS main application? And simmillary for ARM core (but for ARM, the procedure is descibed on http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L137)

So I think, I will need:

1) A tool to generate image (.bin) (that is allocated to a specific RAM address space) file from elf (or COFF) file. May be, this will require some changes in linker command file, but it is autogenerated from the template linkcmd.xdt and can not be directly modified.
2) A procedure, how to properly stop SYS/BIOS app in order to start another one. Is it even possible?

Thanks in advance.

  • 0
    TI__Guru** 116830 points

    Michael,

    A SYSBIOS application uses RTSC tools and a cfg file to create the linker command file (which contains memory map for the application). The linker.cmd is auto generated based on configuration specified in the .cfg file. Once you build the .out file, you can generate the .bin file or .ais file using AISGen tools provided from the wiki you are refering.

    I moving the question to the BIOS forums to seek answers for your BIOS questions.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 50 points

    Rahul,

    thank you very much for your response, but unfortunately it caused more questions than answers:-).

    I did not find any specific description for the AISGen tool. I suppose, it generates the raw binary file from the .out (ELF or COFF) file, but according to the memory allocation defined in linker command file. Is that so?

    If I want to change the final memory allocation of the binary image, is it possible to do it using AISGen tool, or do I have to change something else (I guess the platform definitions?).

    I assume, that AISGen tool generates startup code too. This startup code, except settings of peripherals, move the application to the final location in the memory and then executes jump to this program. Am I correct? Can I use the same tool for the ARM core? Will the tool generate different startup code? Or is it possible to generate image file with no startup code?

    The other question is. If I generate the image file using AISGen tool and I want to start it from already running code, how do I do that? Is it OK to simply use jump or branch instruction to the image in memory? Where the image should be located in memory?

    And the final and the most important question: how do I exit sysbios properly and start another sysbios application? May be, Hwi_disable() and jump to the binary image can be enough?

    Thank you in advance (I marked my questions).


    Michal Danek


  • 0 in reply to mdanek
    Prodigy 50 points

    OK, I made some research and test about exiting SYS/BIOS application and starting another one.

    To do this operation, calling Hwi_disable() and jump to the entry point _c_int00 of the application is enough? Am I correct?

    Thanks in advance.

  • 0 in reply to mdanek
    TI__Mastermind 20480 points

    Hi Michal,

    I'm not quite sure how the AISGen tool works. Have you looked at the OMAP-L138 Bootloader wiki page?

    From looking at the OMAP-L138 (which probably is similar to the OMAP-L137), you'll have to boot with the ARM core first, as it needs to bring the DSP out of a reset state.

    To start the execution of a SYS/BIOS image, from SYS/BIOS functionality is concerned you should be OK to call c_int00 function. There are several precautions to bare in mind here:

    1. Reset state: When you call c_int00, it assumes the hardware registers are in their default state. This includes clock PLL registers, flash wait-states, etc...
    2. Interrupts: Interrupts need to be disabled before you try modifying (e.i. loading your new application) the interrupt vector table for your new SYS/BIOS application.
  • 0 in reply to Tom Kopriva
    Prodigy 50 points

    Hi Tom,

    Thanks for your answer. OMAP-L137 is a DSP-boot device, it means, DSP boot first and ARM the second. No problem here.

    I have already taken a look at wiki page.

    I am able to create boot image for my custom DSP bootloader. This bootloader should start the main application for ARM and DSP core. It means it should provide loading of the app image to the correct memory location. And this might be a problem. This image I can create by two ways:

    1) using AISGen tool (or HexAIS), in this file a lot of redundant information is inserted. To properly reallocate this image I need the starting offset of the raw application data in this file (by using reverse enginnering I can do it) and the address of the c_int00 function (again reverse enginnering can help me). But is this correct to help myself by this way?

    2) using hex6x tool, the problem is, that this tool can not generate variable images according to the variability of the final application. Another problem is, that no information about the entry point (c_int00) is available.

    I thinks, that the right solution would be to generate image using AISGen (HexAIS) tool, but with any specification of the AIS image for OMAP-L137.

    And I found it here:

    http://www.ti.com/lit/an/sprab04g/sprab04g.pdf

  • 0 in reply to mdanek
    Guru 26430 points

    I was under the impression that AISGen is required only for images read by the ROM bootloader. On the OMAP-L137, I've only used AISGen on the DSPUBL (.out to .bin). DSPUBL loads ARMUBL, a .bin file. The ARMUBL project uses hex470.exe to convert .out to .bin. I haven't ever flashed in a DSP BIOS app. Can't say about that. I think the problem with the .bin format is that the load address and entry point is lost. The loader has to use a hard-coded addresses. The image must be built with the same hard-coded addresses. I think the .out file has the load and entry addresses. Parsing the .out at boot time is probably more work than it's worth.

  • 0 in reply to Norman Wong
    Prodigy 50 points

    Parsing the .out file is out of the question. It is too complicated. However, .bin image, that ganerates AISGen tool or HexAIS tool is fine for me, because the file is in AIS image format and this format is described in the document above. There are addresses, content and the address to jump to the application. Everything should work.

    Hex470.exe and hex6x.exe do not make the same as you said. There are no addresses and the resulted image could be quite big with useless content if the command file is not build suited for the specific application (.out file).

    So, the AIS image is OK for me, to process this file is not difficult and there is basic security.