Changing McBSP Registers in embedded Linux Kernel on Beagleboard xM
 

Hi everybody,

I hope this is the rate place for this question on which gives me a realy hard time.
I have a Beagleboard xM running Ubuntu (installed via Matlab Simulink Support Package), which is connected to a CS42448 audiocodecboard. To communicate with that codec I will have to change the McBSP-Registers on the DM3730 Processor, which is of the OMAP3 Family. (If it helps: McBSP is nothing else then the I2S-Version of Texas Instruments, which is a bus for serial audio data)

To do so I think I will have to change the kernel, but how can I find the right files and how can I change the kernel? The Kernel I'm running is 3.2.0-23-omap
Furthermore I could find in 'usr/src/linux-headers-3.2.0-23/sound/soc/omap/' a makefile and the Kconfig which includes the following (and much more)

-config OMAP_MCBSP
tristate
depends on ARCH_OMAP

config SND_OMAP_SOC_MCBSP
tristate
select OMAP_MCBSP

I don't want to post to much and I can't really tell what information is relevant and what not. I'm quite new to linux and would be really really happy if you guys could give a few tipps and tricks or probably a ruff list of things I have to do, to change these Register to what I want them to be.

Thank you very much allready!

Regards,

Lenni

I'm not sure how much you'll have to do here. McBSP is one of those things that's supported in the processor, but AFAIK there are no modules that use it out of the box.

The company I work for has a product that includes a TI DSP doing some custom signal processing and pumping data into the McBSP port of a Gumstix Overo (DM3730). I had to write a custom kernel module for the interface from scratch, since there was nothing out of the box that I could use. Having never written a kernel module before, I was able to piece together scraps from here or there on the web and get it up and running in about two weeks.

Being a proprietary product whose development was funded by my employer, I can't post the source here, but I can point you to the resources I found useful when I was working on it. It's related to the Gumstix, but since it's the same processor I'm sure the vast majority of it will apply to your board as well. FYI - the kernel I was developing for was also 3.2.0.

http://gumstix.8.x6.nabble.com/DMA-M...-td667552.html

If you do end up having to write your own kernel module, you're going to have to do a LOT of reading up on the matter. This is a little dated, but gives a basic overview of the layout of a kernel module, how to compile it, etc:
http://www.tldp.org/LDP/lkmpg/2.6/lkmpg.pdf

Wow not bad. I can understand you're not allowed to post the source code. Let me just tell you my regrets anyways ;) Including the DSP would have been the next step to go for, since that actually is what I chosed the BBxM for. Two weeks sounds really quick to me. I looked for it on a couple of evening after work and was only running in circles yelling "I have no clue about what to do" ... probably with my arms waving over my head :P Did you do Linux programming before or is "getting the first experience" included in those two weeks?

The pdf you gave me looks really interesting. Guess that's going to be the job for today. Did the Gumstix used the McBSP-Interface before you wrote your Kernel? I'm a little bit scared that I have to delete the current McBSP Settings so that I wouldn't end up with trouble when I just change the registers.

I guess you don't know of any easier way to set these register. Like a *.c file that I cross compile and execute on the embedded linux?

Thanks for your infos. That is exactly what I was looking for!

Cheerio,

Lenni

Edit: I just looked into the link of the guy with the DMA-Problem and saw this arch/... folder again. I can't find any folder called arch on my system. Should I see it from root? Does it stand for something else or do you know where I can find it?


Edit2: Some informations that are probably worth mentioning is this file: http://tomoyo.sourceforge.jp/cgi-bin...p/omap-mcbsp.c which probably is the current Kernel Module for the McBSP-Interface? and this: http://lkml.iu.edu/hypermail/linux/k...3.2/02551.html which is supposed to be a patch for exactly my codec. The only question left is: how can I install it?

I was already very experienced with Linux and programming before diving into this, I had just never done a kernel module before.

You won't be writing or modifying the kernel itself, just writing a module that loads into the kernel that tells it how to use that specific McBSP interface (McBSP3 in my case), not McBSP in general. Whatever you do, you won't affect any other McBSP devices on your system (I think the built in audio interface might also use McBSP, at least it does on the Gumstix, but it's a different port (McBSP1 or 2 I think)). Anything you change on your McBSP interface will not affect the other McBSP interfaces on the system, whether or not they're in use.

All of this is assuming you're going to be plugging this board into an unused McBSP interface on the BeagleBoard, if that's not the case then some/all of what I've said may not apply.

The directory structure referenced in that link is the cross-compilation directory structure provided by the OpenEmbedded build system. It's not a directory on the target board itself.

All I can do is tell you what I had to do to get my DM3730 to interface with an external DSP over McBSP using an unused port and a custom protocol that's particular to that device. How much of that applies to using an external audio board over McBSP, I'm afraid I can't answer, including whether or not there might already be built-in support.

That actually doesn't sound to bad. I cam across devmem2 and it seams like I can change the values of any register from the terminal and therefore should work from a c program as well.
Unfortunately the McBSP2 Interface is allready in use. Allthough, when I start up my Beagleboard there is no activity on the McBSP-Lines but according to a all these configs I had seen lately it is set up somehow. When I use Simulink to access the onboard audiocodec (Simulink is able to do that with the appropriate support package installed) the McBSP2-Pins suddenly start alternating. I could allready figure out that this support package must make changes to the registers when it's compiling so I suggest that the McBSP2-Interface is sort of deactivated by default.

Anyways: I think I have found two possibilities to start with. One is the devmem2 tool and the second the kernel module.
Did you had a look on this link http://lkml.iu.edu/hypermail/linux/k...3.2/02551.html ? It is supposed to be patch. Can you tell whether it is and how I get it into a file that I could actually patch the kernel with?

Well you could just copy and paste the text to get a patch file, but I don't think it would be of much use. That's for an unknown kernel on an AT91 processor, and only deals with I2C communcation with the CS42448 control port.

Allright. Thanks for gettings that information out of it :P I was allready wondering how this is supposed to work. I better forget about it ^^

Hi there,

I was sitting together with a prof of my university who does a lot of embedded linux stuff but just as me, never touched the kernel. We could figure out that the CS42448 is implemented as a soc sound device for the 3.19 kernel. With that in mind we now tried to build an omap specific kernel according to this tutorial: ( https://eewiki.net/display/linuxonar...-Ubuntu14.04.1 ) and changed the sound driver from the onboard sound device to the CS42448. Do you think this might work?

Did you used Alsa when you implemented your project? We tried to gather some information about this, hoping that ALSA would make everthing easy, but it seems like you must know everything about ALSA in order to use it. We checked a bunch of sourcecodes and couldn't find anything that looked like it would set any registers. Do you have any tipps for me regarding this?

It's certainly worth a shot

No - ALSA is for sound, my application had nothing to do with sound. I wrote the kernel module from scratch (well, piecing together examples I could find online and adding some of my own), it doesn't use any pre-existing modules, it is its own module. It just uses the raw "omap_mcbsp_reg_cfg", "omap_mcbsp_request", "omap_mcbsp_start/stop", etc. function calls that are made available in the source. Eg:
http://lxr.free-electrons.com/source...c/omap/mcbsp.h

It was a basic matter of requesting the mcbsp device (mcbsp3 in my case), configuring it, configuring DMA, starting it, using the DMA callbacks to dump the data into a circular buffer, and then writing a user-space application in C to pull the data out of the kernel module buffer. This just gives the raw data from the mcbsp interface though (which is what I wanted), it doesn't interface with the sound system in the OS at all.

If you can find a way to pull in and use an existing sound module designed for that card, that's where I would start.

Allright, thanks for your assesment. I could allready compile the new kernel but sort of having trouble with getting it on a sd-card (I discuss that problem here if you're interestedhttp://www.linuxquestions.org/questi...30#post5327830 )

If that wouldn't work (what I expect it to) I will probably check out your way. It sounds quite possible to do actually and allthough Alsa-support would be grate, it probably isn't necessary.

Hi Suicidaleggroll,

my plan with that CS42448 driver didn't work out so well. I got it so far that the appropriate modules were running but they didn't do anything. So I think it's actually gonna happen, I will have to write my own Kernel module.

Do you know of any documentation of the mcbsp modules, that tell me how to use the functions you were talking about?

Thank you so much btw. for your help! I really appreciate it!

The link I posted earlier to gumstix.nabble has a link to a github project with an example mcbsp kernel module. That's what I built my module off of. It had a couple of quirks, one of them was register addressing which I posted about in that link, but for the most part it was pretty solid. I don't know how you would get the audio system to use that kernel module though, since that's something I've never explored.

Oh allright. Then I'll start digging in there I guess ;) The audio system will be another problem to fix. I first will go for the "a lot of reading" you mentioned earlier ;) Starting with the mcbsp stuff and than go over to alsa. Guess as soon as I will try to handle the DMA I will come back to you.