[Linux-Xtensa] Re: Audio Driver - applied your git patch, I'm looking into buildingyour config on an LX200...

Piet Delaney pdelaney at tensilica.com
Wed Sep 15 01:59:21 PDT 2010


Tong Wang wrote:
>   Hi, Piet
> 
> I re-packed Truby's attachment as a .zip file,  hope it's OK this time.
> 
> any problem, please let me know.

Thanks Tong. I've got their driver install in my DC_233L LX200
board and I copied the test code to an exported directory that's
mounted by the board. I added:

	#define uint8_t  unsigned char
	#define uint16_t unsigned short
	#define uint32_t unsigned int


to cbm60xx_dsp.h and typed make and it builds fine.
I think I need to add a inode in /dev for the device.
------------------------------------------------------
[root at DC_C_233L test]# ./dsp_test
open dsp dev
init oss device:3 ok

open audio dsp dev
open: No such file or directory
--------------------------------------------------------

You may want to try it out Tong. You can ssh to 192.168.11.105,
it's the LX60 on my desk.
	Login: root
	Password: linux1
	
	cd /home/default/Chipbanks/test
	make

Piece of cake.
-------------------------------------------------------------------------------
[root at DC_C_233L test]# make
make: Warning: File `Makefile' has modification time 1.3e+09 s in the future
gcc dsp_test.c -o dsp_test
make: warning:  Clock skew detected.  Your build may be incomplete.
[root at DC_C_233L test]# ./dsp_test
open dsp dev
init oss device:3 ok

open audio dsp dev
open: No such file or directory
[root at DC_C_233L test]#
--------------------------------------------------------------------------------

Once I have a config for their board I'll make an
identical environment with gcc, gdb, and most of the
development tools we tend to expect on a linux system.

I'm going to look thru Truby's readme and find that mknod
that I'm missing and then we might see some kernel printk's
about the CPENABLE bit not being correct.

-piet

> 
> Best regards,
> Tong
> 
> On 2010-9-15 16:02, Piet Delaney wrote:
>> truby.zhuang wrote:
>>
>> Morning Truby:
>>
>>> Hi,piet:
>>>
>>> Thx for your reply.
>>>
>>> *1. About the git*
>>>
>>> Consider that I do not know If it is ok to push my codes to the git you
>>> give me last time,
>>> I just make a patch which include dirver code of 507T only;
>>> *I have send a tar package to Twang a long time ago*, which includes the
>>> other part of codes
>>> (dsp_code and test routine).
>>>
>>> I agree that we use the same git(*xtensa-2.6.29-smp-chipsbank.git*), I
>>> am polling it down now,
>>> and commit all codes in drivers/media/audio.
>> Great; nice to have another linux-xtensa developer on board.
>> I see you included Benn, Leeking, and Mark. Should I add
>> them to linux-xtensa.org in the ChipsBank user group?
>>
>>> Since it will take hours to clone the git.
>> Actually, since the git repos are  identical you could just change the
>> name of the config in you .git/config file and save the time
>> of downloading the same thing you already have. I do it a lot,
>> it's very safe.
>>
>> You can just change this line:
>>
>>       url = git+ssh://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp.git
>> to
>>
>>       url = git+ssh://git.linux-xtensa.org/git/kernel/xtensa-2.6.29-smp-chipsbank.git
>>
>> make sure you have the git+ssh, this will make it possible to push to the repo.
>> 1st push may be a problem, I might not have the permissions 100% right. Since
>> you own the git repo you can also ssh to linux-xtensa.org and fix it. You
>> just 'cd ~git' and then down into the kernel directory.
>>
>>
>>
>>
>>> *Attached with the previous
>>> package*.
>>> audio/test/dsp_test.c is the test routine you need.
>> I just put it in my ~/Notes/Chipsbank dir and it came up empty again.
>> Perhaps due to a laim security attempt by the lovely folks in Portland.
>>
>> -rw-r--r--  1 piet tensilica     0 2010-09-15 00:35 audio_ver0_03_2010_09_03_2nd_try.tar
>> -rw-r--r--  1 piet tensilica     0 2010-09-15 00:32 audio_ver0_03_2010_09_03.tar
>>
>> How about you just check it somewhere in buildroot;
>> seems like a good place for it. Could also put it
>> in my home dir on linux-xtensa.org or send it as
>> a .zip file. Tong just sent me a .zip file and
>> MicroSofty didn't mess with it.
>>
>>> Would you please test the routines in this package first.
>> I'm trying to build a dual processor config that very closely
>> matches your configs. Just adding LX200 board support and other
>> stuff required by the same CCBUILD tool we used to build the
>> three core HiF-2 LX200 board.
>>
>> At this point once I have the tar ball I could only
>> test it on a DC233 core which has TIE queues that don't
>> go any where. Once I get the configs ready and ask Marc
>> to check it I'll try your driver with the DC233 and your
>> audio driver and we can see what happens. I can check for
>> the printk's they you mentioned as indicating that the I/O
>> port protection change wasn't working.
>>
>>
>>
>>> The dsp_code and test codes are the same as this package.
>> Right, and I'm missing the test program that runs on
>> the 570T core and opens the driver. If it doesn't use
>> TIE instructions I can just ssh to my DC_233l core, compile
>> it with gcc and try it with your driver. The driver won't have anything
>> to send data to for a while. Might get far enough to demonstrate
>> a problem.
>>
>>> *2. How to use the mp3_dec lib*
>>> the dsp code should be set up as a Xplorer project, currently, I do not
>>> write a Makefile manual,
>>> and just simply link the mp3_dec lib to dsp_code binary.
>> Ok, I think I can manage that. I'll need a bitstream with
>> both of your cores before I can use this. Get me the test
>> source code, perhaps vie buildroot or just scp it to my
>> home dir at linux-xtensa.org. Maybe if you make it a gzip
>> file MicroSofty won't zap it.
>>
>>
>>>   Files in dsp_code dir is the dsp codes we developed, create a project with
>>>        Xplorer, while the rlt330lsp is the lsp and set up the project
>>> setting as follow:
>>>        include path:
>>>        $(PROJECT_HOME)/inc,$(PROJECT_HOME)/base_vns
>>>
>>>   Defines:
>>>        RTLSIM        : set up running environment as RTL simulation
>>> (necesaary!)
>>>        DEBUG_LOG  : enable print log information (if you want to see
>>> debug info)
>>>
>>>   Custom LSP:
>>>        $(PROJECT_HOME)/rtl330lsp
>>>
>>>   Linker Flags:
>>>        -lc  *$(PROJECT_HOME)/lib/xa_mp3_dec.a* -mlsp=$(PROJECT_HOME)/rtl330ls
>>>
>>>
>>>   Please let me konw if you get any confuse about our driver.
>> I'm not a heavy Xplorer user. I tend to just use the base
>> tools. I think I can just compile you dsp code with XCC
>> XCC with the linker script for the Avnet board and it should work.
>> I'll worry about that after I have a LX200 board running a
>> bitstream with your cores on it. Start it with xt-gdb
>> after the primary takes it out of run-stall.
>>
>> This may take a few days as I first have to get the base
>> config working with CCBUILD and then have our hardware
>> superstar, Steve, help me merge in a FIFO between the
>> two cores. Currently we can only do this with automated
>> tools with XTSC simulations.
>>
>> -piet
>>
>>>
>>> -------------------------------------------------------
>>> With Regards,
>>> Truby.Zong
>>>   ???
>>> -------------------------------------------------------
>>> ????????????
>>> Chipsbank Microelectronic LTD.
>>> ??:??????????????12??7?
>>>          No.701-712,Building No.12,Keji Central Road 2,
>>>          Software Park,High-tech Industrial Park,Shenzhen,
>>>          P.R. China 518057
>>> Tel: +86-755-86169650  ext 831  Fax: +86-755-86169690
>>> WebSite:www.chipsbank.com<http://www.chipsbank.com/>
>>> Email:    truby.zhuang at chipsbank.com<mailto:truby.zhuang at chipsbank.com>
>>> ------------------------------------------------------------------------
>>> *???:* Piet Delaney
>>> *????:* 2010-09-15  13:54:12
>>> *???:* truby.zhuang at chipsbank.com
>>> *??:* linux-xtensa at linux-xtensa.org; MarcGauthier; Tong Wang; Sarang
>>> Shelke
>>> *??:* Audio Driver - applied your git patch, I'm looking into
>>> buildingyour config on an LX200...
>>> Hi Truby:
>>>
>>> I Applied your patch with 'git apply':
>>> ----------------------------------------------------------------------------------
>>> [piet at pdelaney_fc9 xtensa-2.6.29-smp]$ git apply ../git_patch_chipsbank_10_09_08
>>> ../git_patch_chipsbank_10_09_08:18: trailing whitespace.
>>>            This is the driver of the Audio dsp (decoders and encoders )
>>> ../git_patch_chipsbank_10_09_08:62: trailing whitespace.
>>>    @Brief:  driver for cbm60xx audio dsp module
>>> ../git_patch_chipsbank_10_09_08:91: trailing whitespace.
>>> /**
>>> ../git_patch_chipsbank_10_09_08:107: trailing whitespace.
>>>       if ((id != chan->index) || (fmt == chan->format))
>>> ../git_patch_chipsbank_10_09_08:109: trailing whitespace.
>>>      return -1;
>>> warning: squelched 696 whitespace errors
>>> warning: 701 lines add whitespace errors.
>>> [piet at pdelaney_fc9 xtensa-2.6.29-smp]$
>>> -------------------------------------------------------------------------------------
>>> I didn't expect any errors to be reported.
>>>
>>> My current 'git status' is:
>>> .......................................................................................
>>> $ git status
>>> # On branch IO_PORTS_Piggy_Back_On_Coprocessor_Infrastructure_Proposal
>>> # Changes to be committed:
>>> #   (use "git reset HEAD<file>..." to unstage)
>>> #
>>> # modified:   drivers/media/Kconfig
>>> # modified:   drivers/media/Makefile
>>> # new file:   drivers/media/audio/Kconfig
>>> # new file:   drivers/media/audio/Makefile
>>> # new file:   drivers/media/audio/audio_dsp.c
>>> # new file:   drivers/media/audio/audio_dsp.h
>>> # new file:   drivers/media/audio/buffer.c
>>> # new file:   drivers/media/audio/buffer.h
>>> # new file:   drivers/media/audio/cbm60xx_dsp.c
>>> # new file:   drivers/media/audio/cbm60xx_dsp.h
>>> # new file:   drivers/media/audio/mailbox.c
>>> # new file:   drivers/media/audio/mailbox.h
>>> # new file:   drivers/media/audio/readme
>>> ....................................................................................
>>>
>>> I made a copy of 2.6.29-smp at linux-xtensa.org and called it "xtensa-2.6.29-smp-chipsbank.git".
>>> I made you the owner with group access by folks in the chipsbank group.
>>>
>>> As you can see the files are not accessible vie the git web access:
>>>
>>> http://git.linux-xtensa.org/cgi-bin/git.cgi
>>>
>>> it's only accessible by you and other members of the 'chipsbank'
>>> group. I added Marc and myself as members of the group.
>>>
>>> This approach allows our customers to keep their code un-published
>>> until they are ready to push their changes to kernel.org.
>>>
>>> Would it be ok for me to push your patch that I just applied there
>>> so we are all on the same page? Feel free to push it your self;
>>> which would really be a bit better. I recommend we make a branch
>>> off of the proposed "IO_PORTS_Piggy_Back_On_Coprocessor_Infrastructure_Proposal"
>>> branch.
>>>
>>> In the mean time I'll try configuring it in and starting builds to put
>>> together a bitstream for the LX200 with your cores on it.
>>>
>>> So far it appears you git patch includes only the code run on the CB570TMMU.
>>> Did I miss the code intended to run on the DC_330HiFi core?
>>>
>>> The readme at the end of the git patch mentions dsp code and an application.
>>> The dsp code is suppose to be in a 'dsp_code' dir. Looks like your using
>>> the same xa_mp3_dec.a library that we use in the HiFi-2 SMP LX200 board:
>>> http://wiki.linux-xtensa.org/index.php/Mplayer_Hifi_2_Codec_Development_Board
>>>
>>> If ya go about 3/4 down the page to the section on compiling the Mplayer Plugins:
>>>
>>>   Compiling the Mplayer Plugins and linking them with MPEG-1 Audio Layer 3 (MP3) and MPEG-4 AAC Codecs
>>>
>>> you will see how we mount the codes's in an NFS mounted directory on the target
>>> and then let the Makefile patch Mplayer with the codec library plugins.
>>>
>>> In your case the Linux system isn't running with the HiFI-2 TIE instructions
>>> and we have to do everything on our workstations. Do you have a makefile
>>> to easily link the coded librarys to your test program? I suppose your
>>> saying I should just make a trivial Makefile for your application and
>>> have it link directly to the codec library's. If you have a tar ball
>>> with the audio/test src and Makefile it would be good to send it
>>> once I've got you cores running on an LX200. Looks like I'll have
>>> a handful already with building the bitstream and messing around with
>>> the KERNELOFFSET and LOAD_MEMORY_ADDRESS.
>>>
>>> -piet
>>>
>>>



More information about the linux-xtensa mailing list