I am using DM6446, can I use CCS 3.3 to debug both ARM and DSP?

DM6446 EVM ; CCS v3.3

I have four questions:

1. When I compile DSP code in CCS, I find that CCS uses c16x.exe in C6000 folder.  Why does not C64+ have it's own compilor?


2.After intalling DSPLib and IMGLib for C64+, I find there is nothing but DSPLib and IMGLib in C64+ folder in CCS. I want to know if I want to use ACPY in DSP whether I should use resources in C6000 folder.

   for example:

   #include<c6000\xdais\acpy.h>

  #include<c6000\xdais\idma.h>

 etc. .....


3. I want to know the meaning to develop DSP algorithm in CCS.

   In my opinion, To develop and debug algorithm code in CCS is just a way to verify that your algorithm can run properly. ( To verify that these code does not have grammatical error or other errors.)

   If I finish to debug the code, I need to copy these algorithm code to Linux, and then I need to compile the algorhitm (XDM compliant) in Linux to ensure this algorithm can connect well with my ARM application (just like the relationship between "encodedecode" in ARM and "H.264" in Codec).

In Brief:
   a. In CCS: To develop and debug codec algorithm code.
   b. In Linux: To compile this code and use this code interface in ARM application.
   c. In Linux: To compile the ARM application and Codec algorithm.
   d. In Linux: To burn to EVM board.

   Am I right?


4. In Linux system. After compiling program, how can I burn the "out" file into my EVM board.

   for example:

   I want to burn "encodedecode" into my DM6446 EVM, and after burning, the EVM board can run independently, it does not have to connect with PC which will command the EVM board.

Thanks.

1. This is really just a design decision from the code generation tools team, the C64x+ is an enhancement of existing C6x architectures thus much of the compiler is the same between them, so instead of making a new C64x+ compiler build they updated the existing C6x compiler to handle the C64x+ enhancements by using a compiler flag (-mv6400+).

2. The DSPLib and IMGLib were created before there was Davinci and the ACPY API was created, they do not use DMA resources themselves anyway. I would suggest using ACPY if you are to use DMA resources on the DSP side of a DM6446 application to allow more flexibility/compliance with other codecs and Codec Engine.

3. It seems like you have the right idea, CCS is primarily for debugging the DSP code on its own, once it is stable you can take the DSP code and integrate it into a XDM compliant form so it can be loaded from the ARM using Codec Engine.

4. With Linux you have an actual filesystem available so you do not really just burn an out file to the board like you would in a traditional DSP system. What you would do to get it to act like this is to copy the encodedecode binary into your board's filesystem (HDD, Flash, NFS, etc) and modify an initialization script file (/etc/init.d/) in Linux on your board to run that binary when Linux boots, this is how the board runs the demo interface out of the box.

Looks like Bernie did a great job of answering your questions already; I just want to add a couple of comments with regards to 2 and 3

2) As you probably know, it is required (as opposed to recommended or suggested) that codec be XDM compliant in order to integrate into codec engine framework; this means it cannot use DMA resources directly and should go thru ACPY APIs if it needs DMA resources.  I just wanted to make sure that it was clear that this is not an option, but a requirement.

3) You can build and test your XDM compliant codec all within CCS (do not need to switch to Linux to test XDM compliance).  Then you can drop your codec (in library form) into codec engine framework and produce a codec server executable (.x64P file as opposed to .out) which the ARM application consumes.  As Bernie pointed out, in Linux you make the user application (e.g. encodedecode) along with codec server (x64P file) part of your Linux file system (e.g. can reside in HDD, NAND flash, NOR Flash, SD...)

I hope this helps

EVM6446

I want to use "videnc_copy" as an example to explain my further questions.

In this process function I want to get a matrix which describes one frame of the video and then I'll use my algorithm to deal with this matrix(for example: edge detection or erode...) to get my result.

But I have these questions.

1. I want to know where I can get the value of parameters in process function.( when debug my codec in CCSv3.3)

   for example:

   XDAS_Int32 VIDENCCOPY_TI_process(IVIDENC_Handle h, XDM_BufDesc *inBufs,
    XDM_BufDesc *outBufs, IVIDENC_InArgs *inArgs, IVIDENC_OutArgs *outArgs)

  "inBufs" and "outButs" are all about video stream. When a function call "VIDENCCOPY_TI_process" , it will pass some parameters to this process function.

but  where can I get these video data in CCS. (I mean: How can I read video data using CCSv3.3? I need one of the frames in video data at least as my input parameter).

2. In VIDENCCOPY_TI_process() :

   I want to know whether "inBufs->bufs[curBuf]" in "memcpy(outBufs->bufs[curBuf], inBufs->bufs[curBuf], minSamples);"  describes one of the frames in video stream.

3. In VIDENCCOPY_TI_process (Linux):

   If I use :

        for(i=0;i<minSamples;i++)
    {
        outBufs->bufs[curBuf][i] = inBufs->bufs[curBuf][i] * 1;
    }

  to alternate "memcpy(outBufs->bufs[curBuf], inBufs->bufs[curBuf], minSamples);" or "ACPY".

 I want to know, what does the value represent  in "inBufs->bufs[curBuf][i]".   Is the value a number in RGB format( three dimesion matrix )?  Or Is it a number in YCbCr format? ...

I will decide how to deal with the matrix considering the values.

4.

 To respond to Juan's 3) answer:

 As my example, After compiling, I'll get "videnc_copy.a64P" in CCS, is that right?  And then I'll use it and other archives to get "*.x64P".

I think CCS can not compile an achieve to Linux. Then could you tell me how I can build my XDM compliant codec within CCS in library form?

I think all of these questions are basic for you, but actually I don't master the process of developing DSP yet, so thank you for your time.

Thank you. :)

Could anyone can help me to resolve my questions?   Thanks.

I can try to at least get you an initial response now:

1. From within CCS in general you would load a test image or images to test the codec, either something generated by code on the target board (like color bars or a pattern) or something you load as a file (in a particular format), there is not an easy way to take an arbitrary image or video file and load it to the board through CCS due to formatting.

2. I believe your assertion is correct.

3. The values should be in YCbCr 4:2:2 format typically.

4. CCS generates .out files which are COFF format that you can load directly to the target, this is also known as a .x64p file. You can configure your project to make a library in the project options which would create a .lib file which is also known as .a64p. I believe they just use these alternative extentions in Linux to delinate the type of file it is. Building a XDM compliant codec in library form within CCS is something that is not very simple to explain, there is a lot of documentation at this wiki article that should help you to get started, in particular the Algorithm Creator's Guide.

Thank you for your response, Bernie.

For 1) of your response.

I can load an image using C in CCS, but could you tell me how to convert it into matrix format. I use "fopen" and "fread", but the result is not a real matrix value no matter what the image format is.

I  can not find any functions in ImgLib to support this convertion yet. Could you recommend me some tools to finish this convertion?

otherwise, I need to write a funtion to do it.

Thanks.

Lorry,

Can you expand on what you mean by matrix format?  I am not an expert when it comes to DSP side development, but if you can help me understand the question, I can get the appropriate person to help answer it.

You should be able to read in an image that is in a .bmp format (from MS Paint), that should show up as an array of 24 bit RGB pixel values (with some header data you can ignore or strip out), most any other standard image formats (i.e. JPEG) will be compressed and not easily usable on the DSP. I would bet you could find formatting utilities out there that would generate other color space formats, namely a file containing YCbCr 4:2:2 if that is what you are looking for, but I have not come across any myself.

Hi Juan,

I'll explain what I mean.

you know, all of my algorithm were designed by Matlab.

If you use MatLab, you can find a function named "imread",  one of the returned value of this function is an "Matrix" which describes an image.

for example:

>> f = imread("\home\Lorry\image\s1.jpg");

or

>> f = imread("\home\Lorry\image\s1.bmp");

If my image belongs to Uint8 class, the biggest value should be 255. For example: "f" should be an matrix of 4*4*3; "f" is an 3D matrix including R,G,B.

for example:

R should be an 2D matrix like this below.

240 50 20 30

22  45  52 45

11 223 56 43

35 55 35  0

and then G and B should be the same format with R.

So, "f" is what I want to get in CCS. But I don't know what I should do to get "f" ( "Matrix" in my last post ).  I search in ImgLib and C lib, but I can not find a way to do it.

If I can get this Matrix I can use ImgLib to convert one of frames of video into gray level. And then I can use function of ImgLib to finish my codec algorithm ( for example: edge detection ....).

So, I think one of parameters in "process" function in codec should a frame ( an image ) of video stream. In CCS, when coding my "process" function of codec, I want to pass an frame ( a Matrix or an array) to "process" function, but I don't know how to convert an image file to "matrix" format In CCS using C lib or other lib.

Thanks.

Thanks Bernie.

I think "24 bit RGB pixel value" means any one of values in matrix is 24 bit. Then the biggest value should be "0xffffff". Am I right?

So, I'll try it in my code.

Thanks. :)

CCS does not have an intelligent image loading function like imread, which is what I was getting at earlier that there is no easy way to get an image into a CCS project, since you do not have this automatic formatting capability. CCS can only read in raw data, so you would have to either write code on the DSP to do any formatting changes, or format the file before you load it into your project, neither of which are operations I have examples of. Because of this is why I would suggest using a simple format like BMP, since it has no compression and is already a raw image it should be the easiest to process into a form that your algorithm will be able to use.

I believe the default bitmaps generated by paint are 24 bit interleaved RGB, meaning at some point in that file you should find trios of bytes that contain the red green and blue values for each pixel in the image. A quick test with a paint generated bmp and a hex editor seems to show that the bytes are compacted, meaning that the biggest value would not necessarily be 0x00FFFFFF, in other words you would have to think of it as an array of char (8 bit) and not int (32 bit).

Lorry,

I am afraid Bernie is right and we do not have any functions that will convert image file to matrix format as you suggested.  However, our EDMA3 engine has some nifty features that will let you arrange data in patterns without; I am wondering if you can use these DMA features to convert to matrix format without wasting valuable CPU cycles.  You can see the EDMA User's Guide for more details: http://focus.ti.com/lit/ug/sprue23d/sprue23d.pdf

Yes Bernie, that's my fault, I did not understand the meaning of "color depths". you are right.

Thanks Bernie and Juan, your suggestions help me a lot.

How to revise script in MontaVista Linux to execute program at the beginning.

For this question I recommend this page, it tells us which file we should revise in MontaVista Linux, It uses "encodedecode" as an example.

I hope this will help  someone who does not know which file he should revise in MV.

It is helpful for letting EVM run "encodedecode" without controlling by PC.

1. I've learned "boot and load app without host machine", I found "dvevmdemo" script and created a link name "S88demo" in .../rc.d/rc3.d folder.  But I found that MontaVista Linux always asked me to log in after booting instead of executing "encodedecode" demo automatically. I don't know how to deal with it.

2. After reading "Debugging the DSP side of a CE application on DaVinci using CCS", I think there is something I can not understand.

    a) ARM application is running while debugging CE in CCS, if "COUT 1" in "Switch S3" on EVM is on, CCS can not connect with DSP, so I think CCS can not debug CE while ARM application running.

   b) If CCS can debug CE while ARM application running, in this article it describes "You can ensure that the DSP side waits by putting a "prompt" after Engine_open() in the ARM-side application code", I want to know which functions in CE will be called at this "prompt", I guess the function is like "VIDENCCOPY_TI_initObj" (if I debug "VidEnc_copy").  I think if I want to debug "VIDENCCOPY_TI_process", I should put a "prompt" after " ....process" in ARM application, and then set a break point at "VIDENCCOPY_TI_process" in CCS.  Am I right?

Hi Lorry,

1) As the mail archive above suggests, dvevmdemo script runs automatically, regardless if you log-in or not.  Please note that you will still get the log-in prompt, but this should not prevent demos from running thry the script.  FYI, out-of-the-box, our DM6446 EVM boots from Hard Drive and the 'interface' demo runs automatically via the scripts (script also calls on loadmodules.sh which is necessary before running any demos requiring codec engine).

2) The main reason why wiki article suggests you place prompt after engine open has to do with the DSP state.  You see, normally DSP is in reset state and ARM must take DSP our of reset (similar to what we do with GEL files when ARM is not running Linux).  When ARM is running Linux, we cannot connect to ARM via CCS and use GEL file to take DSP out of reset because connecting to ARM would de-stabilize Linux.   Therefore Engine_open takes DSP out of reset and allows connection to DSP side via CCS; similarly Engine_close places DSP back in reset.  This means that if you are going to connect to DSP while ARM is running Linux, you will need to make sure DSP is out of reset (by having called Engine_open, but not Engine close yet).

Let me know if this helps clear things up

Thanks Juan,

       I still have question about "1)"

         I don't know whether the auto-executed problem is related with flash, because I remember when I got the EVM board I erased NOR flash, after I burn uImage and u-boot.bin into flash ,the demo could not be run automatically. 

          So I think there is something error in u-boot.bin or uImage. It leads to the question. 

          If this is not the main reason, I don't know what other things may affect automatic  execution. Because I 've checked  "dvevmdemo" script, and "S88demo" in .../rc.d/rc3.d in PC and the hard disk on EVM board, Both of them are at correct position.

         I'm sure that the demo could run properly when I command it in minicom.

          To attach the script:

--------------------------------------------------------------------------------------------------------------------------------------------------------

#!/bin/sh

DVEVMDIR=/opt/dvevm
DEMO=interface
OPTS=""

# Load the dsplink and cmem kernel modules
cd $DVEVMDIR
./loadmodules.sh

# Start the web server
echo Starting web server ...
cd $DVEVMDIR/web
./thttpd -c "/cgi-bin/*" -l /dev/null

# Start the demo application
cd $DVEVMDIR
./$DEMO $OPTS > /dev/null 2>&1 &

--------------------------------------------------------------------------------------------------------------------------------------------------------

Thanks.

LorryAstra said:

         I don't know whether the auto-executed problem is related with flash, because I remember when I got the EVM board I erased NOR flash, after I burn uImage and u-boot.bin into flash ,the demo could not be run automatically. 

This sounds interesting.  Please note that for the demos to run automatically

1) You must boot from HDD since this file system has dvevmdemo script; optionally, you can copy the script to your NFS file system.

2) The file system (in HDD or NFS) has to be compatible (from same DVSDK version) as u-boot and uImage.

If you upgrade u-boot but not the file system on HDD, this may explain why demos did not ran automatically.  But if you have done all the necessary steps, then we need to investigate this further (I assume you are using the latest DVSDK v 1.30.00.41).

Also, is the script trying to execute at all (do you see loadmodules.sh being loaded via boot log messages?); if it is and is failing, then it is likely a software compatibility issue (assumed above).  If it is not running at all, then it is an issue of placing the script in the right place.

If all filesys is copied to a SD card by booting via TFTP using NFS File System,

is it possible to boot from Flash using the above SD-card file system?

If it is possible, how to config?

Just change the root=/dev/hda1 to root=/dev/mmcblk0p1  which is described at A.4.1 of GSG?

The above should have worked; things to look into

1) permissions in SD file system

2) I believe that in some cases you may need add a small delay to ensure /dev/mmcblk0p1 is ready.

Juan is correct, though I have not tried it on Davinci, in the case of OMAP3 if you do not have a delay when mounting a SD card as root it fails, you can implement this delay with the bootdelay=n addition to your bootargs, where n is in seconds.

Also when copying a filesystem to the SD card it may be easiest to tar it up and untar it on the SD card, you can use a cp command but I believe you need to use the -h flag to maintain symbolic links.

 When I tried to copy the filesys to the SD card under target which is booted via TFTP using NFS File System,

A lot of errors as following happenned.

...

cp: cannot create symbolic link `./etc/X11/xkb/rules/xfree86-it.lst': Operation
not permitted
cp: cannot create symbolic link `./etc/X11/xkb/rules/xfree86': Operation not per
mitted

...

Command I used

$target mount /dev/mmcblk0p1 on /mnt/sd_card

$target cd /mnt/sd_card

$target cp -R -H / .

Questions:

Maybe the error is concerning with the following points

>>1) permissions in SD file system

How to set the permissions in SD file system? The format of SD is vfat.

>>you can use a cp command but I believe you need to use the -h flag to maintain symbolic links.

The symbolic link cannot be created althoug I add -H with the cp command.
 

Thank you very much

Masaru said:

How to set the permissions in SD file system?

You can set permissions in any Linux file system using chmod. Though I am not sure if this is really a permissions issue or if there is some other reason you cannot perform this sort fo copy (technically you are always root on the target so you should have permissions), I have never tried to copy a currently mounted root filesystem like that, usually you would take a filesystem from the host in the form of a NFS mounted folder or a premade zip file.

Instead of copying the filesystem out of the running target board you may want to try getting the filesystem out of your DVSDK install, there should be a filesystem within /opt/mv_pro_4.0.1/montavista/pro/devikt/arm/v5t_le/target/ that you should be able to copy to the SD card, or if you have already gone through the getting started guide entirely you should have the same filesystem in /home/user/workdir/filesys.

Another question about boot without host machine.

The evm can be booted without host machine now. However, the evm sent the DHCP request continuely during the boot.

The requesting took a lot of time and make the boot procedure a very long long time.

How to stop DHCP requesting?

Instead of the following link,

http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg03896.html

Is the any other document to describe boot without host machine. I can not understant [the attached doc] described at the above link.

-----Original Message-----
From: Mukherjee, Somnath [EMAIL PROTECTED]
Sent: 13 December 2007 09:30
To: Cochrane, Euan; Davinci-Linux-Open-Source (E-mail)
Subject: RE: boot and load app without host machine


Why don't you burn the uImage on the flash itself?
Did you see the attached doc before?

Thanks,
Somnath

Masaru said:

Another question about boot without host machine.

The evm can be booted without host machine now. However, the evm sent the DHCP request continuely during the boot.

The requesting took a lot of time and make the boot procedure a very long long time.

How to stop DHCP requesting?

I think you should set an static ip for your EVM,  so you can set one of variants in your bootargs from "ip = dhcp" to an static ip address (for example: "ip = 192.168.1.1"  etc.)

I believe EVM will not ask DHCP to allocate dynamic ip address any more. I hope it works.

Thank you.

Another way to avoid the DHCP delay is to use ip=off in your bootargs, this should disable the stack all together.

As to booting without the host machine the best reference to start is the getting started guide, it has alternative boot modes in the appendix you can use to boot the device from flash instead of over the network, as well as instructions for restoring the flash contents. What part of the stand alone boot process are you having trouble with?

This means that you can debug ARM at a very low register level

Hi,

I am using DM6446 and ccs3.3.  And I can link DM6446 using ccs 3.3 .

Now , I only link the ARM core  of  DM6446. And  I  want to  debug  ARM  at  a  very  low  register  level.  Which  instruction  can   use  to  write  into  ARM, ARM's  or  DSP's.

I am not sure I understand the question very well, but will try to answer it

If you are writting source code to be debugged on ARM, I would suggest you write C source code; the compilers are very good at optimizing this code for the ARM; however, if you want more complete control and want to program using arm instructions, the you will need to refer to the ARM926EJ-S Technical Reference Manual at www.arm.com  (this is specified in DM6446 data-sheet)  In either case, you should be able to debug ARM using CCS at a low level; at least this is my understanding given my limited CCS expertise.