Building the codec servers (x64P files)

Palatis said:

I'm having "cmem_1_02", "codec_engine_1_10_01", "codec_servers_1_23", "dsplink_1_30_08_02", "bios_5_20_05", "xdais_5_10", and "xdc_2_94" under /opt/dvevm_1_20.

These are really old software components.  Normally, the first thing you would need to do is request the codec libraries (not included in DVSDK) so that you can rebuild codec server; however, since these software is so old, when you request codec libraries, you will likely get libraies that are not compatible with this build.  Our codecs have improved quite a bit in performance and quality since the software release you are using, but unfortunately require newer software releases of the software components you listed above.  I would recommend you upgrade to the latest DVSDK software before trying to rebuild DSP server.

yes, but the problem is that i'm working on an davinci dm6446 dvevm clone which doesn't boot with 2.6.18 kernel in DVSDK 2.0.

what i'm not trying to rebuild the codec from scratch, i'm just trying to relink the l64P packages into a x64P package with my modified memory map.

Is C6000CGT6.1.13 enough? or what else the tools do I need?

there's a dspon.ko module which comes with the board, but there's no source for it. without it, the encode/decode demos would fail loading codec server. is it available somewhere on the TI website? because I've downloaded everything I can find on the website but just couldn't find it anywhere.

also, there seems to be an directfb kernel module (c64x) which uses the dsp's bitblit to accelerate directfb rendering, but it requires a dsp binary as firmware. where or how can i get it?

thanks for your fast answer, Juan!

Palatis said:

what i'm not trying to rebuild the codec from scratch, i'm just trying to relink the l64P packages into a x64P package with my modified memory map.

Do you have the codec libraries (l64P) necessary for rebuilding the server (x64P)?  I am not sure what software you have available for our EVM clone, if any; but the software we provide for our EVM (normally referred to as DVSDK) does not include the codec libraries by default; these have to e requested separately.  The problem you will likely face is that if you requests these libraries, you will likely get versions of the codec which are new.  All codec libraries will include release notes (among other docs); the release notes indicate which of the other software components this particular codec library is compatible with.  What I am afraid you may encounter is that the newer codec will require newer versions of the other software components you listed on your first post and may even require newer versions of CGT tools.

To answer your other questions, I have never heard of dspon.ko; the ko extension normally describes loadable kernel module but to my knowledge we do not provide any module named dspon.ko.  Where did you get or hear about this?  With regards to directfb, again I would be interested in knowing where you heard this.  I seem to recall hearing something similar a couple of years ago, but perhaps if you can tell me where you heard this, I can follow up and see what else I can find out.

The FAE of the hardware company (Vanhelsing) has successfully build decodeCombo.x64P, encodeCombo.x64P, and loopbackCombo.x64P for 128MB memory map. What I'm trying to do is that we now have to add aac codecs into it which are not included in the codec combos.

about the dspon.ko, I don't know where did it come from either. I mailed the hardware for sources but looks like the mail just goes to nowhere. modinfo tells me

filename:       ./dspon.ko
license:        GPL
description:    Davinci DSP ON Driver
author:         SHoW
depends:       
vermagic:       2.6.10_mvl401-davinci_evm preempt ARMv5 gcc-3.4

and "ls dspon.ko -l" showed

-r--r--r-- 1 palatis users 2677 Mar 31  2008 dspon.ko

as for the directfb driver, it's under DirectFB-1.4.2/gfxdrivers/davinci/kernel-module/c64x. I successfully build it, but it need some c64x_drv.bin during insmod and refuse to load. i'm wondering where could i get that c64x_drv.bin.

Palatis said:

The FAE of the hardware company (Vanhelsing) has successfully build decodeCombo.x64P, encodeCombo.x64P, and loopbackCombo.x64P for 128MB memory map. What I'm trying to do is that we now have to add aac codecs into it which are not included in the codec combos.

This is certainly possible assuming you have the right codec libraries; the challenging part may be getting these libraries, if you already have them then you are in a great position. 

Palatis said:

about the dspon.ko, I don't know where did it come from either. I mailed the hardware for sources but looks like the mail just goes to nowhere. modinfo tells me

filename:       ./dspon.ko
license:        GPL
description:    Davinci DSP ON Driver
author:         SHoW
depends:       
vermagic:       2.6.10_mvl401-davinci_evm preempt ARMv5 gcc-3.4

and "ls dspon.ko -l" showed

-r--r--r-- 1 palatis users 2677 Mar 31  2008 dspon.ko

as for the directfb driver, it's under DirectFB-1.4.2/gfxdrivers/davinci/kernel-module/c64x. I successfully build it, but it need some c64x_drv.bin during insmod and refuse to load. i'm wondering where could i get that c64x_drv.bin.

Unfortunately, neither dspon.ko or the directfb driver you described below are modules developed by TI and hence there is not much we can do to help you there.  I would suggest contacting the vendor that provided you this software originally and see if they can help.

is there any tool that extract the l64P packages from a x64P package, so we can modify the tcf for memory map and then generate a x64P package back again?

or, isn't the codec server source files enough for generating a l64P package? i can see there are sources in my codec_server directories, and on compile they requires C6000CGT6.1.11 to compile, but they're not giving me any l64P files.

typing "make all" and found out that not all getting maked later is actually pretty disappointing.

and for the dspon.ko and directfb parts... Ooops, that's too bad~ XD

Palatis said:

is there any tool that extract the l64P packages from a x64P package, so we can modify the tcf for memory map and then generate a x64P package back again?

No.  A server is a linked executable - the linker will pull in just the fxns required, and there's no way to reconstitute all the contents of a library (.l64P) from a linked executable (.x64P).  And in reality, you need more than just the libraries, as the codec packages include docs, headers, and other packaging details which the build/config of the Server utilize.

Palatis said:

or, isn't the codec server source files enough for generating a l64P package? i can see there are sources in my codec_server directories, and on compile they requires C6000CGT6.1.11 to compile, but they're not giving me any l64P files.

Yes, there are a few sources in the codec_server directories, but they're likely just for the Server's main() fxn.  You do need a toolchain to compile them - main.c -> main.o64P which gets linked into your executable (.x64P), but these aren't the sources/libraries you're looking for.

If curious, there's a little more background on the inputs and outputs of a Codec, Server and ultimately, the App here:

http://tiexpressdsp.com/index.php/Codec_Engine_Roles

Chris