OMAP-L138 basic doubts - Valuable suggestions needed

Jayakarthick S said:

As I understand it has two cores ARM and DSP. ARM is a master and C6748 is the slave.

By default, the ARM and DSP cores have equal priority in the system so there is not a true master-slave relationship.  The only time one core has an "advantage" over the other is during boot where ARM controls the boot process.

Jayakarthick S said:

Is it possible to boot DSP without using ARM ?

Unfortunately, no.  OMAP-L138 is configured to boot with the ARM core.  In order to boot the DSP, the ARM will need to release it from reset and configure the starting point for DSP code execution.  OMAP-L137 however, is configured to boot with the DSP core.

Jayakarthick S said:

If no Is it possible to boot DSP manually from ARM without any OS running in it? (Without linux and DSP/BIOS link)

Yes, this is possible.  If you download the OMAP-L138 SDK, there is a UBL Boot Strap application which executes on the ARM and readies the device for Uboot and ultimately Linux.  It is possible to modify the UBL source code to boot the DSP instead of running Uboot.

Jayakarthick S said:

When should one really chose omap l138 over C6748. Does it reduce the time for development or it gets more complex? Since I understand DSP BIOS has drivers and CSL to configure peripherals am I wrong with the selection?

The C6748 DSP BIOS drivers and CSL apply directly to the C674x core on OMAP-L138 so you will have the same DSP software support.  The ARM core has Linux drivers and a kernel built for the EVM.

Bringing another core and OS into the picture will introduce complexity, but it does allow you to implement the shared responsibility system where ARM handles connectivity while the DSP is free to handle real-time signal processing algorithms.

If you believe that your application can run ok with just C6748 alone, you have the option of using the C6748 today, but then upgrading to OMAP-L138 in the future with little or no board modifications.

-Tommy

I am interested in trying to do this, i.e. modify the UBL so as to be able to have the DSP
boot up into an application, and have been looking at the boot-strap and
u-boot folders in  OMAP-L138_arm_1_00_00_11/DaVinci-PSP-SDK-03.20.00.11/src.

UBL calls function SPIBOOT_copy() in order to load u-boot from SPI flash into RAM and then UBL executes
(jumps to) it.

The dspwake() function in u-boot gives a clue as to how to set the DSP running, i.e. power it up and
reset it so as to start execution at memory location 0x80000000. dspwake() has just previously poked
an IDLE instruction into memory location 0x80000000.

So, do I need to replace the u-boot code in SPI with my DSP application code and (in a
modified UBL) after using SPIBOOT_copy() to load it into RAM then do something similar to dspwake()
(without poking an IDLE instruction into 0x80000000) in place of the (ARM) jump to entry point?

What I'm confused about is what format the DSP code would need to be in in the SPI flash. Would it
have to be in AIS format, converted using AISgen?

Is the SPIBOOT_HeaderObj used in function SPIBOOT_copy() a part of the AIS format?

Would SPIBOOT_copy() in its present form be sufficient to copy a DSP application into (multiple
locations in) RAM?

Am I in the right track?

Has this been done before?

Donald,

Yes, I believe that you can replace the u-boot code with DSP code in SPI flash.  The DSP code does not need to be wrapped into AIS format because the boot process will be mastered by the ARM core.  The code that is copied into the target execution memory space just needs to be plain DSP code.

My recollection of the SPIBOOT_copy() function is that it is a very generic byte-for-byte copy function so it should work ok.

-Tommy