• Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 435 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.

L137 ARM boot sequence

Joseph Woodward
Prodigy 210 points

For anyone trying to get the ARM to boot using the DSP on an L137 (i.e. not using the ARMUBL./DSPUBL to boot Linux), the following information may help:

It's basically the "guts" of the DSUBL/ARMUBL code, and can be used to get the ARM running an application from external RAM.  Any thoughts/comments/missing steps are welcome

Also, is there any documentation on the dMAX (or whatever the hardware block is that the DSPUBL uses to set the vector table in the ARM's internal RAM at address 0xFFFF0000)???

Cheers!


===Step 1===

Initially the ARM:
  - Is powered down (by the PSC).
  - Is held in RESET (by the PSC).
  - Has booting disabled (by the HOST0CFG register).

 It should be noted that the ARM's internal RAM is also powered down (by the PSC).

===Step 2===

When enabled the ARM will boot from it's RESET vector. This defaults to the ARM's internal RAM (at address 0xFFFF0000).

As the DSP cannot write directly to this we have a special dedicated bit of hardware to do this for us (the dMAX).

We first power up the ARM's internal RAM (using the PSC).

Then the dMAX loads a vector table in to the ARM's internal RAM that jumps to the base of the shared L3 RAM (at address 0x80000000) on RESET (and loops to self on all other events).

===Step 3===

The DSP loads the base of the shared L3 RAM (0x80000000) with code that causes the ARM to jump to a known address in external memory.

===Step 4===

The DSP loads this known address in external memory with the ARM's application.

===Step 5===

The DSP powers up the ARM, releases it from RESET and enables it to boot.

===Step 6===

The ARM:
  - Executes the RESET vector from the vector table in it's internal RAM (at address 0xFFFF0000).
    This causes it to jump to the base of shared L3 RAM (at address 0x80000000).
  - Executes the code at the base of shared L3 RAM (at address 0x80000000).
    This causes it to jump to a known address in external RAM.
  - Executes the application in external RAM.
    The application unmaps itself from external RAM to internal RAM (with a new vector table) and shared L3 RAM as required.

The ARM has now booted and is running the application!

 

  • Prodigy 10 points

    Joseph,

    Your information is helpful, but I still have three questions related to the steps you've described...

    (1) In what format must the ARM binary image be written to the SPI FLASH, which is the method that I've configured my booting? Must it be written in the AIS format?

    (2) Is there any existing DSP code available that will perform the function described in the STEP 4 above? What I'm looking for is an easy way, without writing many lines of code, that will translate the ARM application in the AIS format to the equivalent runnable image in the external memory.

    (3)  What is the name of the document that which describes dMAX, or is it just a piece of hardware logic that always fills the ARM vector table with 0x80000000 upon the powering up of its internal RAM?

    Regards!

    CW