Omap_l138 boot from external FLASH using DSP ROM

For OMAP-L138, the bootloader will always execute from the ARM. You could create a secondary boot loader for the DSP but the initial loading from NOR will have to be done from the ARM.

Jeff

Thank you, Jeff for your respond.

I have some extra questions:

1.  According to data sheet (doc SLVSAQ9) page 105 - DSP is enabled after reset but ARM is disabled. Is this correct?

2.  Manual (doc SPRUGM7D) page 269 - "Following de-assertion of reset, the DSP initializes the ARM296 so that it can execute the ARM ROM bootloader".

That means - the DSP is doing all PLL[0:1] setup and then initializes ARM. is it correct?

3.  The bootloader is executed from ARM ROM by ARM. ARM will start loading from the external FLASH (on EMIFA - CS2).

4.  Can ARM just transfer the bootloading function to DSP? And DSP will disabled ARM and continue the loading from external FLASH to DDR2 SDRAM (in our case).

5.  After loading the SW from external FLASH to SDRAM - DSP will execute SW from DDR2 SDRAM. Is this the correct approach?

 

Thank you for your help,

Boris Ruvinsky

 

 

1. Yes correct

2. Yes, but the DSP is not configuring the PLLs, and the ARM bootloader still has the PLLs running in bypass mode.

3. Yes

4. No you will always have to create a secondary boot loader than runs on the ARM. The following wiki might be helpful: http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138#Booting_DSP_Binaries

5. That will depend on the reset vector of the DSP. More information is in the wiki above.

Jeff

Hi Jeff.

Thank you for your respond and help.

I looked on your wiki link but still have some questions:

1.   What is the ARM initialization (by DSP after reset) consist of?

2.  What was the reason to have ARM in disabled mode after reset if only ARM can start boot-loading?

3.  Boot usually includes the PLLs setup. That means ARM is doing initial PLL[0:1] setup?

4.  At what point ARM can be disabled and DSP can continue to run his application?

5.  Can DSP run all his applications with ARM disabled?

6.  Can DSP (not ARM) change PLL frequencies by changing "post-dividers" on the fly? 

7.  After initial boot-loading - the ARM can change the reset vector of the DSP. Is it correct?

8.  For DSP to use this new reset vector - DSP must be reset by ARM (not by external Power-on-reset). Because Power-on-reset will return the reset vector to the original value (0x00700000).  Is this correct?

Thank you for your help,

Boris 802-877-4978

 

1. Waking up the ARM and setting the reset vector

2. This is how the hardware was architected

3. The PLLs are not normally initialized unless done so by AIS. They are running in bypass mode

4. The DSP is disabled once the ARM starts booting. Your loaded program can enable the DSP to run code immediately, as shown here

5. Yes

6. Yes

7. Yes, please see the example in the link on #4

8. The DSP is always held reset after booting until the ARM wakes it up.

Jeff

Hello Jef. Thank you for your help. I have one more question. Who is reading the "boot" bits - 8 bits which defined the boot mode? According to my understanding - DSP reads these 8 "boot" bits to set the correct reset vector to the ARM based on the boot mode. Is it correct? Thank you for your help, Boris Ruvinsky 802-877-4978

Hello Jef.

Thank you for your help.

I have another question about Emulation Debug Boot.

In the document Using the OMAP-L138 Bootloader  (SPRAB41C) Appendix A "Emulation debug" and Section 3.3 "Emulation Debug Boot" describes the emulator connection to OMAP-L138.

It looks like the "boot bits" must be set to 0001 1110 before the Emulator is connected to JTAG.

Is this true?

We plan to boot from NOR FLASH.

We don't plan to have any switches on PCB.

We can add some logic which is activated when the Emulator is plugged in.

Will this work?

We have boot bits set to NOR FLASH but when we connect the emulator - the boot mode switches to Emulator Debug mode.

Will it be OK?

This is a little surprising feature - we need to change the HW before connecting to JTAG interface.

Usually the processors do not require that.

Thank you for your help,

Boris Ruvinsky

 

 

 

 

Hi all,

I just want to summarized what I have learned so far and please correct me if I am wrong:

 

1 - Power is applied, DSP wakes up and enable the ARM9 processor.  This is done by hardware and it cannot be modified by a user/developer.

2 - ARM9 ROM Bootloader startups and disable the DSP.  This is done by the Bootloader in the ARM9 Processor ROM.

3 - At this point the ARM9 user boot loader (UBL) is executed.  It is the responsibility of the ARM9 UBL to initialize the HOST1CFG register to set the DSP clock rate and address of the DSP UBL. 

4 - The ARM9 UBL resets the DSP and the DSP Application will execute.

 

The ARM9 ROM Bootloader knows where the UBL based on the Boot Mode (e.g. if Boot Mode is NOR, then ARM9 UBL needs to be at 0x6000000, the UBL copied to 0x8000_0004). Depending on the Boot Mode and Method (i.e. with AIS or without AIS), the function can be controlled by the user.  If AIS is not configured/used then the UBL takes over and executes its user programmed processing (e.g. setting up the DSP Clock Rate, Starting Address, HOST1CFG, copying DSP Application into RAM, DSP Application startup).  If the AIS is use, by following its protocol, the AIS allows copying of data into specified memory locations and startup of the DSP Application.

 

Again, please correct me if I got it wrong or left out any important details.

 

I also have two questions:

1 - Can the AIS set the DSP Clock Rate?  If so how.  Is it through the Fill Command?

2 - The 0001_1110 "Emulation Debug".  Is this mode setting required for a JTAG Emulator to connect to the OMAP-L138 chipset?  Probably, but I want to make sure.

 

Thank you,

 

L Pham

Lam Pham said:

1 - Can the AIS set the DSP Clock Rate?  If so how.  Is it through the Fill Command?

2 - The 0001_1110 "Emulation Debug".  Is this mode setting required for a JTAG Emulator to connect to the OMAP-L138 chipset?  Probably, but I want to make sure.

You can use the AIS PLL0CFG Function Exexcute command to change the device operating frequencies during boot.  If you change the ARM core to operate at a particular frequency, the DSP will also operate at the same frequency (there is an enforced 1:1 ratio for the clocks).

The Emulation Debug boot mode is used when you want to connect an emulator to the device and access the ARM or DSP cores, with the cores doing nothing.  This is the ideal device state to connect and load code (for either the ARM or DSP) from within CCS.  If you have the boot mode set to something else, the ARM will be trying to boot and run, while the DSP will be held in reset.  This is not the best state for connecting, since you may not be sure what the ARM is doing and the DSP is not accessible, but you should still be able to connect to the ARM with the emulator and halt its execution.

Regards, Daniel