OMAP L138 and DSP C6478 usage...

Hi Atmapuri

IMO, you should be able to work with the OMAPL138 experimenter kit. While OMAPL138 is an ARM+DSP device , and c6748 is a DSP only device, you have the same peripheral set/features and functionality on both these devices (except ARM9 core). The primary difference that you might need to worry about is would be developing your boot software.  For OMAPL138 you would need to write your bootloading software from the ARM side, where as on c6748 you would need to develop your boot software from the DSP side. 

On OMAPL138 the DSP comes up clock gated and in reset by default, but the board support package includes gel files that should allow you to wake up the DSP and then from that point on , say using Code Composer Studio as your development environment, you could be developing DSP side code and functionality seamlessly on the OMAPL138 Experimenter Kit.

Also, please note that you mention c6743 as your final development processor, in that case you are you also aware of the the Spectrum Digital OMAPL137/c6747 DSK

http://www.spectrumdigital.com/product_info.php?products_id=223 ?

From an architecture/device family standpoint the c6743 is closer to c6747 (c6747 can be considered a superset device for c6743, and c6748 a superset device for c6742). E.g from an audio standpoint , c6747 as 3 McASP , c6743 has 2 McASP , whereas c6748 has only 1 McASP.

Additionally  the OMAPL137/c6747/c6745/c6743 family of devices all require DSP side boot software , so you could have a more homogenous development environment even if you were using OMAPL137 as your development processor. So I would definitely recommend looking at the OMAPL137/c6747 DSK , since you plan to develop for c6743.

The links to the various boot loader appnotes

OMAPL138 http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprab41b

c6748/46/42 http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spraat2b

OMAPL137/c6747/c6745/c6743 http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprab04c

Hope this helps.

Regards

Mukul

I see that you were mentioning booting the DSP or the ARM.

How then would I manage to get both booted up on the omap L138.    From some reading I see that one of the boot loaders for the arm is run out of the shared ram at 0x80000000,  but this space is also the starting point for the dsp and they cant both use the same code space. 

I am assuming that using U-Boot I could copy the file containing all the code for the DSP into that space but I dont know what file I would use as an image, how I would avoid the conflict with the ARM, and how I would get the DSP to start running the code.

Any insights would be appreciated

Curtis

Hi Curtis

In the prior post, most of the mention on boot loading was w.r.t to the ROM boot loader etc. So assuming, you are using OMAP L138, it is an ARM boot device. There could be several ways to bring the DSP out of reset and start executing code from a desired location , however, in general the common way our software collateral enables you to do this is via DSPLINK.
So roughly the sequence would be as follows

1. ARM ROM Boot Loader
2. ARM UBL (user/secondary boot loader)
   
   • ARM UBL will load and run ARM uboot
3. UBOOT load Linux
4. Linux can then run DSPLINK to load a DSP side .out file/image and once the coded is loaded, release the DSP from reset to start executing from the desired location

Currently I think in step 3, Uboot has a dspwake function that will essentially insert an idle instruction at 0x80000000 and  then enable the  DSP via PSC. It should also be noted that you can change the location from where you want to start executing DSP code prior to enabling the DSP re-programming the SYSCFG.HOST1CFG register (described the System Guide )

While the user boot loader or ARM UBL could be making use of the Shared RAM, once it is completed, and Uboot is running, it can "re-use" the starting location of the shared RAM.

Hope this makes sense. Let us know if you have more questions on this.

Regards

Mukul

I've taken a look at the dsplink, it seems geared toward the communication between the two processors, but involves a lot of overhead.  Its taken a long time to find which functions actually load the executable code but I still haven't figured out which part actually copies the memory, it just goes deeper and deeper until there are no more links that can be followed.

It seems to me that the idea is to simply copy the .out image file to the memory location which the DSP starts at then set the bit high thats starts the dsp. correct me if I'm wrong.

I'm not too keen on re building the linux image, nor adding the overhead to what is supposed to be a lean processing code on the DSP.

To perform a low tech communication between processors, I can simply allocate a piece of memory which both have access to and use it as a buffer.

Hi Curtis,

I would recommend:

1) For OMAP-L138, the ARM boots the DSP, so if you want to use C6748/6, and If you did not get the full L138 EVM board that comes with the C6748 SOM-> than you develop with the L138 SOM for now and then when you move to your custom board you can make the boot loader work. That will save you some time, if you are not using Linux, it is not worth to learn it just for that.

2) For OMAP-L137, the DSP boots the ARM. So if you preffer to use the C6747/5/3, than you are fine as even if the EVM comes with the OMAP-L137 part, because you can use the DSP boot without any Linux, it works like the C6747 part for booting.

3) If you are using the DSP and the ARM:

   a) if you are not use the DSP drivers (recommended if you do not need it) than use iUniversal.

   b) If you need to use the DSP drivers, then use DSPLink,and start with tis simple example for L137 or this example for L138. Basically you are going to have the DSP executable in the Linux filesystem and use DSPLink to load it and communicate between DSP and ARM.

Curtis,

The DA8XXGEM_write function in file: dsplink\gpp\src\arch\DA8XXGEM\da8xxgem.c is responsible for doing the final memcpy to the slave. The DSP executable is present in the Linux file system. The COFF parser in DSPLink parses the executable and loads it section by section to the slave memory. This file (i.e. da8xxgem.c) is also responsible for the lowest level of the DSP management (reset/power control, interrupts etc.). Other files in this folder (dsplink\gpp\src\arch\DA8XXGEM) have the code to take care of this.

For inter-processor communication, at the lowest level is the IPC interrupt, encapsulated with the s/w module NOTIFY, which abstracts this physical interrupt into mutiple logical events. These events enable us to have upper level modules independently and in a modular way, make use of the single physical interrupt for multiple purposes. Other IPC protocols such as MSGQ (message passing), POOL (memory management), MPCS (Multi-processor Critical Section) etc. enable management of the shared memory used between the two cores for IPC purposes.

Regards,
Mugdha

Hi!

If I read this right, it is not possible to access the DSP without first booting the ARM with Linux OS? I also have no plan to run an OS on my final chip. I would like to reach point where there is a main() function so that I can start writing the code for the DSP side of the OMAP.

Thanks!
Atmapuri

Hi Atmapuri

Have you decided which device you plan to use for your end application and what development platform (EVM) you want to you use for development? From your previous post, it would look like you wanted to go with the c6743?

It is important to understand that, so that the right engineering solutions could be suggested for your development/end application work.

Regards

Mukul

Thanks for the tip,  I forgot about the sections,  If any of the memory sections spill over into another area of ram, my idea of directly copying the file will fail horribly.

Does anyone have prebuilt and functioning kernels with dsplink along with the versions of dspbios that they run with,  I've seen a number of people on this forum struggle trying to get all the correct versions together and build files together to make it happen.  I'm just starting the struggle, but it would be much nicer if I could take the audio example which was provided by TI and test it right out of the box. Then I can get started actually developing software to run on it, rather than tracking down all the bits and pieces necessary to simply make it run.   Maybe the kernel that was used for that example program should be provided.

Another question, maybe everyone thats done it before knows already,  When building a filesystem for the embedded kernel, how does the kernel know where to find the file system, how does it know how big it is,  Maybe there was some documentation on this I just haven't found yet.

Curtis

Hi Mukul,

The future may bring what it may, but currently I have my hands on OMAP L138 Experimenter board. I tried running the CCS3.3 that comes with the board but got dll/init loading message both times. No support for Win7 or Vista or 64/32bit either. So I tried and went with CCS4. I followed through the "hello world" example provided in the start. I defined XDS100v2  USB emulator as the target device and specified OMAP L138 as the chip. The connection seems to work, because I can see the execution pointer at 0x8000000 executing IDLE, but there are NOP instructions before and after. Currently I am only trying to get the ARM9 to produce the "hello world" and the error message displayed. In the Debug window I can see three items listed (shortened description):

+TI XDS100v2 USB / C674x [Non-Project debug session]
+TI XDS100v2 USB /ETB11_0 [Non-Project debug session]
+Hello [Debug]

When I click the last Item I can see the error message:

ARM9_0: File Loader: Data verification failed at address 0x00000020 Please verify target memory and memory map.
ARM9_0: Unable to terminate memory download: 0x00000004/-2030 @ marker 1026 Error during: Register,  Access to an unknown or invalid register was attempted. 
Error found during data verification.
Ensure the linker command file matches the memory map.

What does that mean? How to fix it? I also tried to boot the board and watch the serial out only
(the default). Here is what I got:

U-Boot 2009.01 (Jul 30 2009 - 11:58:01)

DRAM:  64 MB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
ARM Clock : 300000000 Hz
DDR Clock : 300000000 Hz
Ethernet PHY: GENERIC @ 0x00
Hit any key to stop autoboot:  0
U-Boot >

Thanks!
Atmapuri

I think I can help you on all 3 of those issues,

1. CCS is not compatible with anything above WINXP, I got blue screens until I switched back

2. As far as I can tell you cant load an arm program with CCS, although ccs4 might be able to, it only connects to the DSP

3. As was the case in mine,  your linux kernal image is corrupt,  you need to find the steps that tell you how to restore the image.  This will require you find the image uImage in the linux sdk, I recommend using the kernal version that it ships with, I tried later versions and the sata wouldn't work properly, and get tftp server to transfer it to the chip.  I contacted logicpd, they sent me the instructions, but I think there are other instructions floating around the web.

Curtis

Hi Atmapuri

Thanks for providing the details on your current setup and environment.

If you are using CCSv4 and XDSv100 v2 , you should be able to connect to ARM and get the setup working (even on Windows 7 AFAIK).

Please see if some of the following wiki topics on CCSv4 and XDS100V2 help

http://tiexpressdsp.com/index.php/XDS100#Q:_My_XDS100v2_does_not_work_reliabily_with_the_OMAPL138_.2F_DM365_.2F_ARM926_core.

http://tiexpressdsp.com/index.php/How_to_connect_to_the_OMAP-L138/C6748_EVM_board_using_CCS%3F

http://tiexpressdsp.com/index.php/FAQ_-_CCSv4#Q:_Is_Windows_7_supported.3F

Another thing that I have seen some time come in play when using CCS based development environment to develop and debug ARM side, if you had Linux kernel booted up (say from the SPI flash etc), then the ARM MMU is in play, and to have the gel scripts and code run properly you need to disable the ARM MMU (if the ARM MMU is enabled this should be visible in the CCS status bar, at the bottom). To disable

Tools->ARM Advanced Features. This should open a new window and MMU enable/disable check box should be near the top

Please see if this helps.
Regards

Mukul

Hi Curtis,

Curtis Zaiss said:

 

Another question, maybe everyone thats done it before knows already,  When building a filesystem for the embedded kernel, how does the kernel know where to find the file system, how does it know how big it is,  Maybe there was some documentation on this I just haven't found yet.

The kernel knows where to find the root filesystem from the 'root=' parameter given in the bootargs. How the size of files is determined and how the inodes are laid out depends on filesystem to filesystem. The code to understand the inner workings of each filesystem is contained in the kernel itself (under the fs/ directory).

Thanks,

Sekhar

Does anyone have a working configuration combination of the kernel, dsplink, bios, tools etc for the omap l138

Someone that has gotten it to work prefferably.

If so, could you post the configuration and possibly the links.  Maybe also the steps you used, changes to makefiles and stuff.  

 I'm still having problems building u-boot,   some problems in the board.c file   declarations of weak

cant use menuconfig   because it cant find ncurses libraries

 dsplink doesn't seem to work and thus cant use the sample programs.

Hi!

Here is what I figured out. The programming with Linux requires some development IDE with remote debugger capability. I haven't done any browsing yet on the internet about what that could be, but sure is strange that there is no link even to a list of it available. The development for ARM is not supported by Code Composer Studio. There will be Windows CE support for the OMAP L1xx in the future and development for that works with Visual Studio. (Done that before and it is a really nice experience.) The OMAP L138 Experimenter requires that the following is entered (at the current time) at U-Boot prompt:

setenv bootargs 'mem=32M console=ttyS2,115200n8 root=/dev/ram0 rw initrd=0xc1180000,4M ip=off'
setenv bootcmd 'sf probe 0;sf read 0xc0700000 0x80000 0x200000;sf read 0xc1180000 0x280000 0x300000;bootm 0xc0700000'
saveenv

in order to get the Linux running. It is mentioned in the release notes. I was actually able to browse around with this thing a little, saw the memory and flash usage and so on. The DSP chip side is enabled automatically as soon as the U-Boot is interrupted from booting to Linux. Using CCS4 to make a hello world, however takes some time. The hello world application example is available on the front Welcome page of the CCS v4. I followed that through and configured a new target using XDS100v2 and OMAPL138 (generic) as shipped with CCSv4. That did not work. Then I noticed I can configure script for each node in the target configurator and pointed the DSP and ARM nodes to the GEL files available for download from the Logic website (after you login in to your account). That was not enough. Further linker command file is needed to specify where should the program be located, otherwise you get errors that the memory is not writable:

C674X_0: Loader: One or more sections of your program falls into a memory region that is not writable.  These regions will not actually be written to the target.  Check your linker configuration and/or memory map.
C674X_0: Trouble Writing Register PC: Error 0x00000006/-1176 Error during: Memory, Register,  The IM memory request is not serviced by the HW memory system.  This could be caused by the memory address specified does not exist in the specified  memory/cache level.  

That linker .cmd file is also included with the BSL (basic support library?) from logic and fixes this if specified in build options. Now I can finally run the debugger on the DSP with Hello World displayed in the Console. I also added the evmomapl138_bsl.lib file to the project. Question's that remain:

1.) How can I route the printf command to the default RS232 port?

2.) How can I burn the Hello World program to the flash?

3.) How can the U-Boot be configured to start the Hello World program from that flash?

I was also looking but did not find any option to:

- Show the code size and memory usage of the program while in flash and when loaded.

Thanks!
Atmapuri

Hello Curtis,

Curtis Zaiss said:

 I'm still having problems building u-boot,   some problems in the board.c file   declarations of weak

Are you using CodeSourcery 2009-q1 which is the recommended toolchain for the PSP? This problem can come if you are using a later toolchain. The fix for this is available in the upstream U-Boot. Please see this patch: http://git.denx.de/?p=u-boot.git;a=commitdiff;h=f865fcbbb35851e75fee9c3a3fa8e0f71d9e6463

Curtis Zaiss said:

cant use menuconfig   because it cant find ncurses libraries

You can edit the existing .config file in the kernel top level directory and then run 'make oldconfig ARCH=arm' to reconfigure the kernel. This will not need ncurses.

Thanks,

Sekhar

Thanks for the advice,  I am not sure if its q1 but I'll check,  does this cause any problems with other parts of the build.

I will try the other 2 recomendations,

As for DSPLINK not working,  I am still betting that the various versions of kernel, dsplink and bios do not play nice together, I'm going to try rebuilding with a different combination, unless someone can tell me otherwise.

Curtis

I did finally get it to work, and the sata worked after disabling PM support in the kernel.

Im trying now to build a dsp application with dsplink from CCS3.3 

I have made a new project containing the source, header and config files from the readwrite program and have linked all the includes and libraries I can think of and it still is missing a whole bunch of stuff.   Is there any way to figure out exactly which libraries, includes, etc were used to build the dsplink programs.  Normally I would just look in the makefile and it would contain it, however in this case the build is spread over at least a couple dozen of them with many branching options of which I cant totally be sure which it used either.

Curtis

There is an example of a DSPLink project converted to CCS3 at:

http://tiexpressdsp.com/index.php/CCS_Project_OMAP-L137_HelloDSP_DSPLINK_example

The steps used for the conversion are described as well.

Thanks,  I was missing the 50 words of predefines, now I got it to compile.

Now another question, is there anyway to debug a dsp side program which is using dsplink and for all likelyhood was loaded from linux using dsplink.  I was trying to connect to the dsp using CCS but as soon as dsplink grabs ahold of it CCS cant even connect to it anymore.  It would be enough simply to see the memory display, although having step by step debug would be great.

Curtis

Curtis,

This should help:

http://wiki.davincidsp.com/index.php/Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP-L137_using_CCS

In general, you should be able to find an answer for many of your common doubts here: http://wiki.davincidsp.com/index.php/Category:BIOSLink

Regards,

Mugdha

Hi Mugdha

Along the same lines of trying to unhitch the dsp side build from the extensive network of makefiles.  Is there a way to list all the makefiles the make procedure goes through to build the gpp side sample.  I want to develop a new application, outside the dsplink directory structure. I copied one of the samples to another directory  but I see that the output still gets sent to where the samples did.

Curtis

Hi Curtis,

The examples below have DSPLink applications that are installed in different directories than the examples that come with DSP Link:

http://processors.wiki.ti.com/index.php/Example_application_using_DSP_Link_on_OMAPL1x

http://processors.wiki.ti.com/index.php/Audio_Soc_example