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.

SECDEVTOOL-OMAPL138C6748: How to wake up ARM from DSP Secondary Bootloader?

Part Number: SECDEVTOOL-OMAPL138C6748
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

Hi everybody,

I am writing a DSP secondary boot loader for secure enabled OMAP-L138 chip, in which I need to wake up ARM core and assign entrypoints to both ARM and DSP.

I have followed the example provided by Rahul (the first link) and read some useful threads in bellow:

 

My booting procedure is as follows:

1. DSP starts first with DSP ROM bootloader loads DSP secondary bootloader (SBL) into memory, transfers the control to DSP SBL and exits in SECUREWITHSK mode

2. DSP SBL load ARM and DSP application images into mDDr, decrypts them using Secure Kernel APIs and retrieve the two entrypoints. The process is in SECUREWITHSK mode

3. DSP SBL runs the PRUSS to write ARM reset vector to 0xFFFF0000, through which it wakes up ARM core and the ARM application starts to run. The process is still in SECUREWITHSK mode

4. DSP SBL switch to NONSECURE mode using SK_switchNonSec() API concurrently with transfering control to DSB user application. Now the entire system operates in non secure world.

The PRU code and ARM code to set the ARM reset vector is the same as in the example of Rahul.

/* PRU code */

unsigned int armBootDmaxCodeConst[] = {
0x24000080, // Load ARM vector table address to r0
0x24ffffc0,
0x24000081, // Load ARM code address to r1
0x240000c1,
0xf500e182, // Read ARM code from *r1 to r2,...
0xe500e082, // Write ARM code from r2,... to *r0
0x79000000, // Self loop
};

/* ARM boot ARM code */

unsigned int armBootArmCodeConst[] = {
0xEA000007, // vt0: B boot
0xEAFFFFFE, // vt0: Self loop
0xEAFFFFFE, // vt0: Self loop
0xEAFFFFFE, // vt0: Self loop
0xEAFFFFFE, // vt0: Self loop
0xEAFFFFFE, // vt0: Self loop
0xEAFFFFFE, // vt0: Self loop
0xEAFFFFFE, // vt0: Self loop
// jump:, DATA:
0x00000000,
// boot:
0xE51F000C, // LDR R0, jump
0xE1A0F000, // MOV PC, R0
};

My problem is that only DSP application runs, it seems that the ARM core has not been woken up yet. It is weird because some people were successful to run Rahul's exam code. My questions are:

1. Is my boot sequence correct?

2. Does the ARM entrypoint need to be in Shared RAM (mine is in DDR)?

3. Should I wake up the ARM core in NONSECURE mode or I can do it in SECUREWITHSK mode?

4. What are the posible solutions I should try?

Thanks in advance,

  • Hi,

    I've notified the RTOS team. Their feedback will be posted here.

    Best Regards,
    Yordan
  • Part Number: SECDEVTOOL-OMAPL138C6748

    Hi there,

    I am writing a DSP secondary bootloader for secure enabled OMAP-L138 chip and having problem with loading code sections to ARM Local RAM from DSP.

    To clarify, when I analyze the content of the ARM+DSP binary application image, there are two sections of code that must be located in ARM local RAM (0xFFFF0000 - 0xFFFFFFFF) during booting process (as showed in bellow).

    However, in the datasheet of OMAP-L138, this region of memory can only be accessed from ARM or PRU core. As showed in table 3-4 (page 24), the gray color indicates that DSP cannot directly read from or write to this range of memory. 

    Therefore, the boot process always suspend when I try to load code/data to ARM local RAM from DSP secondary bootloader (as showed in UART debug screen bellow)

    QUESTIONS:

    1. I know that I can use PRU0 to load data from SHARED_RAM/DDR_RAM to ARM local RAM, but I don't know how to program it. Could anyone provide me with a PRU code to perform this task?

    2. Is there another way to solve this problem, which does not use an ARM secondary bootloader?

    Thanks in advance,

  • Hi Tien,

    I've forwarded this to the OMAP-L13x SW experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • Thank you, Tsvetolin Shulev
  • Hi Yordan,

    Is there any feedback from the RTOS team?
    I'm looking forward to your reply.

    Regard.
  • tien,

    sorry for the delay in getting to this post.

    Can you perform both step 3 and step 4 in non-secure state after decrypting the DSP and ARM images . Other thing to watch for is the ARM and DSP .map files cannot overlap. If both programs use the same memory address, they will overwrite each other and most likely crash. The linker command files should be written to prevent this. Is the ARM binary compiled using TI ARM compiler or GNU compiler? There is no requirement for entry point to be in shared RAM as long as your SBL is initializing the DDR correctly.

    Have you ensured that you are unlocking the KICK register before performing this sequence. I am assuming that you update the entry point when calling the DEVICE_set_ARM_reset_vector(). Have you checked the PSC registers to make sure that ARM RAM And ARM are enabled.

        /* Turn on ARM RAM */
    	DEVICE_LPSCTransition(0, 7, 0, PSC_ENABLE);
    
    	DEVICE_set_ARM_reset_vector(DEVICE_ARM_UBL_LOAD_ADDR);
    
        /* Turn on ARM */
    	DEVICE_LPSCTransition(0, 14, 0, PSC_ENABLE); 
    
    	/* de-assert ARM local reset */
    	PSC0->MDCTL[14] |= 0x100;

    also, check after you decrypt and load the code in DDR that the entry point of the ARM matches your ARM map file.

    Regards,

    Rahul

  • Hi Rahul,

    Thank you for your reply. I would answer your questions as follow

    Can you perform both step 3 and step 4 in non-secure state after decrypting the DSP and ARM images .

    Yes, I was trying to wake up ARM both before and after switching to NONSECURE mode. Some time there are non-stop weird strings "-system_ini" pushed to UART screen after I called the function DEVICE_enable_ARM(ARMBootAdd). But most of the time nothing happened, only the DSP application run (DSP debug strings showed up on UART screen).

    Other thing to watch for is the ARM and DSP .map files cannot overlap.

    I have checked and verified that the two partitions were seperated from each other.

    Is the ARM binary compiled using TI ARM compiler or GNU compiler?

    I have used the TI ARM compiler built in CCS

    Have you ensured that you are unlocking the KICK register before performing this sequence.

    At the beginning of the SBL, I do unlock it in the function DEVICE_Init(). Do I have to do it again?

    I am assuming that you update the entry point when calling the DEVICE_set_ARM_reset_vector(). 

    Yes, you are right.

    Have you checked the PSC registers to make sure that ARM RAM And ARM are enabled.

    I cannot check the PSC register because I cannot run it in debug mode as it is in SECUREWITHSK mode. But I am quite sure PSC registers were set because my SBL did work with a small image of ARM (a blinking led image of ARM and a UART image of DSP combined together). 

    Now I am stuck with a much larger image of ARM, whose the entrypoint is in DRAM, some sections are in SHARED RAM and two small sections are in LOCAL ARM RAM (IRAM). For more information to diagnose, I have examined the two sections in IRAM (through reading binary file of the image), one starting at the address 0xFFFF0000 looked quite similar to armBootArmCodeConst[] array in your example code (the sample is in bellow) . It has an element containing the value of ARM Entrypoint. Therefore, when waking up ARM, I override it with armBootArmCodeConst[]  and then run LOCAL_wakeUpARM()  function. Is that the problem?

    ---> The section starting at 0xFFFF0000 in IRAM:

    [E59FF018; E59FF018; E59FF018; E59FF018;

    E59FF018; E59FF018; E51FFA1C; E51FFA24;

    C1B33CE8 (entrypoint); C1B30E04; C1B30E04; C1B30E04;

    C1B30E6C; C1B30E04; C1B30024; C1B2CC2C]

    I would be grateful for any help.

    Best Regard.

     

  • If you were able to boot with a smaller ARM application code, then I believe the power up sequence should be accurate unless anything other than entry point has changed in the sequence.  Do you have a way to add the LED blink code to the top of ARM application so that the LED will blink as soon as ARM wakes up. I want to understand if the ARM comes up and then gets hung inside some code.

    Another thing to verify is if you unlock the JTAG , if you put the entry point manually into the ARM core if it runs the ARM app correctly, if the PSC is turned on correctly, you should be able to connect to the ARM.

    If you manually put the entry point to the ARM Program counter and run the core and the application doesn`t come up, either the ARM code didn`t load correctly or something is not correct in the ARM decryption stage.

    Is this custom SBL code or have you used the starterware code for this application. is the DSP and ARM code merged as described here?

    tien ngoc said:
    For more information to diagnose, I have examined the two sections in IRAM (through reading binary file of the image), one starting at the address 0xFFFF0000 looked quite similar to armBootArmCodeConst[] array in your example code (the sample is in bellow) . It has an element containing the value of ARM Entrypoint. Therefore, when waking up ARM, I override it with armBootArmCodeConst[]  and then run LOCAL_wakeUpARM()  function. Is that the problem?

    this may have an impact, depending on what the other ARM code is doing. Can you match the armBootArmCodeConst with what you see in the binary file so that only entry point is updated when PRU moves the code to ARM IRAM. Is it possible for you to post the map file for the ARM binary here. From what you are indicating here, your ARM application binary has code in IRAM so when your SBL tries to load code to that section that code will not load as the ARM IRAM PSC is not enabled until DEVICE_enable_ARM is called. 

  • Hi Rahul,

    Thank you for your quick answer,

    It is a great suggestion to put a blinking led code at the beginning of the ARM application. I am trying doing it tomorow when I back to work and will give you detail soon.

    Please keep update with this thread, because I very much need your support.

    Thank you,

    Best Regard.

  • Hi Rahul,

    How do you do? I've back to work after 2 days off.

    Regarding your recommendations on debugging. I have some interesting results, hope it will help you to diagnose the issue.

    1. Placing a blinking led code at the begining of the ARM main()

    The leds had been blinking until the BIOS started (my ARM application has BIOS in it), rather, until the scheduler was initializing somethings. So I think the problem is lining in BIOS. Is there anything I have to care about when working with BIOS on secure enabled OMAPL138?

    2. Another thing to verify is if you unlock the JTAG , if you put the entry point manually into the ARM core if it runs the ARM app correctly, if the PSC is turned on correctly, you should be able to connect to the ARM.

    Yes, everything works properly, since the ARM app now can toogle Leds before being hung.

    But I have a question. When debugging, through memory viewing, I discovered that the write to 2 KICK registers had no effect (e.g. SYSTEM->KICKR[0] = 0x83e70b13 does not change the original zero value of this register). However, I was still able to init PLLs, NAND interface. Moreover, the technical manual of OMAPL138 chip states that "The Kick registers are disabled in silicon revision 2 and later ", and my chip is OMAPL138BE, which is later than that. So, could you verify if unlocking KICKs are still obligatory for either waking up ARM or loading code ARM IRAM, or not?


    3. Is this custom SBL code or have you used the starterware code for this application. is the DSP and ARM code merged as described here?

    It's a customized SBL, the sequence is the similar to what described in your link, with som slight differences. I would illustrate my boot procedure as follow

    1. Buil the ARM and DSP applications in CCS to obtains corresponding .out files

    2. Merge two .out files using out2rprc.exe in "OMAPL138_StarterWare_1_10_04_01\tools\out2rprc\"

    $ out2rprc.exe <dspApp.out> <armApp.out> <mergedApp.bin> (In my SBL, I assign DSP entrypoint first so I put the <dspApp.out> infront of <armApp.out>)

    3. Create Boot Load Module file for secure enabled OMAPL138 (as described in section 3.5 "TMS320C674x/OMAP-L1x Processor Security User's Guide") using LoadModGen_OMAP_L138.exe

    $ LoadModGen_OMAP_L138.exe -ini loadmod_generic.ini -otype binary -o <enc_mergedApp.bin> <mergedApp.bin>

    4. Load <SBL.ais> (previously created using SecureHexAIS_OMAP-L138.exe to encrypt <SBL.out>) and <enc_mergedApp.bin>, in that order, to NAND flash of the board.

    5. Boot from NAND. The <SBL.ais> image is decrypted and run by DSP RBL, then

    5.1. SBL load <enc_mergedApp.bin> to DDRAM, decrypt it using SK_decryptMod() API.

    5.2. SBL parse the image, retrieve the 2 entrypoints and load each section to its specified location (this procedure resembles what happening in ARM SBL provided in Starterware). I confirm that all of the locations do not overlap each other and the decrypted image region also.

    5.3. SBL wakeups ARM and jumps to ARM entrypoint using PRUSS.

    5.4. SBL switchs to NONSECURE and jumps to DSP entrypoint.

    4. Is it possible for you to post the map file for the ARM binary here.

    Here is the memory usage of my ARM application.

    5. From what you are indicating here, your ARM application binary has code in IRAM so when your SBL tries to load code to that section that code will not load as the ARM IRAM PSC is not enabled until DEVICE_enable_ARM is called.

    I have noticed it. I enable ARM IRAM PSC before loading code to it. Then in DEVICE_enable_ARM() it is re-enabled, following which ARM and ARM Int PSCs are also turned on.

    Could you gain any insight from those debug logs?

    I am looking forward to your reply.

    Best Regard.

  • From what I can tell, this is not an issue with your boot up sequence but some issue with BIOS start on ARM9. I don`t have any experience with BIOS On ARM9 on secure parts so it is unclear to me what the root cause of this issue is.

    Does BIOS start work when you unlock JTAG and load and run code on the ARM core ? Could this be some MMU or cache issue when you wake up the ARM. Are you using GNU compiler or TI ARM compiler with BIOS.

    Regards,
    Rahul
  • Hi Rahul,

    To be honest, your enthusiastic supports are very helpful for me to figure out my problem. 

    My answers are:

    Does BIOS start work when you unlock JTAG and load and run code on the ARM core ?

    Yes, when I run the ARM application in debug mode, the BIOS works properly. You might be right about the MMU and cache, I'll check it.

    Are you using GNU compiler or TI ARM compiler with BIOS?

    I use TI compiler. How could  the compiler I've chosen affect the waking up ARM process?

    Best Regard.

  • Hi Rahul,

    Finally I've been able to wake up ARM core and run both applications.
    My problem was that the PRU didn't load the code section in IRAM to its specified location (0xFFFF0000-0xFFFFFFFF), while it was very important to BIOS to initialize the system. So, it always died when coming to initalization in BIOS.
    My solution is DSP loading that section to a specific location in SHARED_RAM, then wakes up ARM and let it do the load by itself.

    Thank you very much for your support Rahul, it did guide me through the steps of debugging my code.
    Best Regard.

  • Thanks for the update and confirming that your issue is resolved. Can you please hit green "this resolves my issue" so that we can close the thread.