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.

How to Build ARM vector table (OMAP-L137)

Other Parts Discussed in Thread: OMAP-L137

Hi

 

   I am a new user of OMAP-L137.    Have learned the quickStartOMAPL1x_rCSL ,    and know how the DSP Core boot   from a external flash using the AISgen.

 

    Now I want Use the ARM Core to do some applications(SPI, EMAC....) without linux or winCE .    Now I can Setup an CCS project to debug the ARM core with GEL Files and the 510plus emulator.   

 

     But what cofuse me is how the ARM core could be boot up using the DSP core. I find in the DSP UBL that , the DSP load a "Dummy" vector table to the ARM local RAM (through the PRUSS ),     then turn on the ARM core . and the ARM core can jump to 0x80000000 to execute .

 

    My question is when the ARM core run, how could it execute an interrupt, because now what in its vector table(0xffff0000) is not the realy vector table. And it can not use it to execute an interrupt. What should I do in my DSP code or ARM code can get an usefullness vector table to execute My ISR ????

 

 Thanks!!

 

 Wenqi

  • Hi

    Wenqi Liu said:
     But what cofuse me is how the ARM core could be boot up using the DSP core. I find in the DSP UBL that , the DSP load a "Dummy" vector table to the ARM local RAM (through the PRUSS ),     then turn on the ARM core . and the ARM core can jump to 0x80000000 to execute .

    OMAPL137 is that it is  DSP Boot device, so the general high level  flow is

    1) DSP comes up first

    2) DSP rom boot loader executes, where the BOOTCFG value is evaluated to determine what is the boot mode etc, it might also have the PRU load a dummy branch to self instruction in the ARM local RAM.

    3) DSP UBL is loaded. It would be the DSP UBL's responsibility to

    a) Load the ARM UBL

    b) Initialize the ARM reset vectors (via PRUSS) so that when ARM is taken out of reset, it will jump to a known location to execute ARM code ( typically placed in shared ram 0x80000000, which is a memory accessible to ARM and DSP (for DSP UBL to load))

    c) Enable the ARM ( clock on etc).

    4) ARM UBL will then load uboot etc and possibly put the DSP in IDLE/Sleep Mode if needed.

    5) Uboot will then load the Linux Kernel etc.

    I believe, it is the Linux kernels responsibility to setup the ARM interrupt vecors, irq dispatcher etc appropriately (e.g arch\arm\mach-davinci\irq.c and other relevant files).

    If you planning to not use Linux, then I think the only examples to setup the interrupt vector table correctly for application interrupts etc, would be the ARM side interrupt examples shown in the quickStartOMAPL1x_rCSL.

    Hope this helps some.

    Regards

    Mukul

  • Hi Mukul

    Mukul Bhatnagar said:

    If you planning to not use Linux, then I think the only examples to setup the interrupt vector table correctly for application interrupts etc, would be the ARM side interrupt examples shown in the quickStartOMAPL1x_rCSL.

     

        That is exactly what I want to know.      The ARM side  quickStartOMAPL1x_rCSL build an  Interrupt table  and   linked to its local RAM(0xffff0000).     But  in the  boot sequence  what  you say above   ,    the DSP UBL load   another  vector table (via.  PRUSS)  to ARM's local  RAM,    I  want to know  how can I  load the realy  vector table( build  in ARM side quickStartOMAPL1x_rCSL   project)  to  this local  RAM,   If  this  work done,  My  interrupt  code  could be  executed  correctly !

        Thanks!

     Regards .

    Wenqi

  • Wenqi Liu said:
    I  want to know  how can I  load the realy  vector table( build  in ARM side quickStartOMAPL1x_rCSL   project)  to  this local  RAM,   If  this  work done,  My  interrupt  code  could be  executed  correctly !

    Once the ARM is up, you can use it to copy whatever you want the ARM RAM contents needs to be, including your own ARM interrupt vector table. I found out that Linux does use the ARM local RAM for vector table. Since the MMU is on, Linux just uses a page (4K Bytes) in external memory for this and maps it to the address 0xFFFF 0000.

     

    Regards

    Mukul