Is it posible for the 64x DSP inside the Omap to directly accsess the pheripherals like the I2C, UART etc?
If we run Linux, must we then tell Linux that the ARM core no longer can use these devices?
Terje
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Yes on your first question! I have been successful using McBSP, McSPI, GPIO, timers, and hardware interrupts from the 64x side. Unfortunately there was no BIOSPSP with peripheral support for OMAP3530, so I had to do the low level programming using the technical reference manual info instead. This was very disappointing at first, but I got everything working eventually.
If you are using OMAPL13x, it looks like it has a BIOSPSP with drivers for UART, I2C, etc. I think you will have a much easier time accessing peripherals from 64x on OMAPL13x rather than OMAP3530.
Yes on your second question. You need to modify your Linux board support to ignore any busses that you want to control from your DSP instead of ARM.
Debugging the peripherals from the DSP side in Code Composer w/ JTAG emulator is fairly easy, and I prefer that environment since I am not a Linux driver guru.
Chris,
This may be a thread hijack, but it is on-topic and continues the theme, at least.
With a customer, I have been trying to get the McBSP1 TX working with EDMA3 from the DSP side. This has actually been on the DM3730, but this portion of the two chips should be identical.
Did you get the McBSP TX interface running with DMA support on the C64x+? If so, I would certainly enjoy seeing your setup code. We get a single event to the EDMA3CC immediately after bringing the XRST bit out of reset, but we never get a second event.
I adapted register-level CSL from another device, mainly for the register overlay structure to make debugging easier. I would be glad to post that for you here in return for your helpful files, or just in return for your interest in receiving the register-level CSL. Like your code, this is not official TI code and is not supported by anyone, but it might be helpful as-is.
Regards,
RandyP
Hi Randy,
My McBSP routine is for the receive direction, and it reads out the FIFO in an HWI, so unfortunately I do not have an EDMA example for these SoC's (yet).
I created a register overlay that sounds similar to yours. I adapted cslr_mcbsp.h, soc.h, clsr.h, and tistdtypes.h from the pspdrivers of dm6437. I would definitely be interested in seeing your files. I have often wondered if an open-source collaboration on a CSL would be a viable project for the ARM+DSP SoC's that are missing an official CSL from TI. Not sure how many of us are programming peripherals from the DSP side, but seems wasteful if we're all repeating the same porting of code.
Cheers!
Chris Norris
Chris,
Here is my csl_dm3730.zip file. It is targeted at EDMA3 in particular, although I almost added cache support. There is a folder "inc" with the files we have used, "inc_notready" with additional files that have not been manually scanned for being ready to use.
My comments describe the fact that these started from C6472 and these files are not supported. Please let me know what you would prefer to be changed.
Your mcbsp file would be helpful to me.
Regards,
RandyP
Hi Randy,
I posted a ZIP with my McBSP files. cslr_mcbsp.h contains my register overlay and soc.h contains the base addresses for the 5 McBSP ports of the OMAP3530. In these 2 files, my approach was to comment out all the definitions, then uncomment the ones I'm using after reviewing against the OMAP3530 TRM and making corrections. This conversion is far from complete, I'm doing a little at a time as my customer requirements evolve.
I'll take a look at your dm3730 CSL.
Thanks!
Chris Norris
Hi all,
The topic is very interesting.
I would like to extend it.
Did anybody tried to get data from the camera ISP directly to the DSP side of the OMAP?
Thanks in advance,
Roman