Documentation for the i.MX51 SDMA

cancel
Showing results for 
Search instead for 
Did you mean: 

Documentation for the i.MX51 SDMA

1,843 Views
billauer
Contributor II

Hi,

I'm working on a project involving the SDMA core of the imx-51 processor. The reference manual gives two references for additional information in its section 52.25:

(1) The i.MX51 SDMA Scripts User Manual

(2) SDMA Scripts Library—Software Design Specification, with a link to https://www.freescale.com/cgi/doc/154727497/SDMA_SCRIPTS.doc

I have no idea where to look for item (1), and as for item (2), I tried the link (of course) and was told that even though I was authenticated with the Freescale Membership Directory, I'm not a participant in the Compass Extranet Projects. Whatever that means.

Can anyone shed some light on this please? I have no idea where to take it from here.

Thanks in advance,

   Eli

Tags (1)
9 Replies

174 Views
billauer
Contributor II

The question is if and where to these script write in RAM. But I suppose that's a problem I'll have to tackle once it arrives.

Anyhow, my summary of the SDMA issue, as well as the free assembler can be found here:

http://billauer.co.il/blog/2011/10/imx-sdma-howto-memory-map/

Your comments are welcome, of course. The assembler is published in part IV.

0 Kudos

174 Views
StevenPan
Contributor I

For this concern, you could just check the RAM script address in the sdma_script_code_<SoC>.h, and put your script address after the RAM scripts.

0 Kudos

174 Views
billauer
Contributor II

Thanks. But my problem wasn't avoiding cluttering memory when I'm alone on the SDMA core processor, but making sure that my script survives other channels running in parallel. I'm working on a module, not a specific product, so I'm trying to make sure nothing breaks when the built-in scripts are run.

This is a bit difficult to check, because I'm running on a Linux system, which has the entire DMA engine disabled in the kernel by default. So I take it that current Linux kernels don't support DMA at all when communicating with its peripherals. What worries me is what will happen when these built-in scripts are activated sometime in the future. It's a matter of convention which regions are really safe, and I suppose that information is written somewhere in the API documentation. Or not.

0 Kudos

174 Views
StevenPan
Contributor I

It's really fantastic job you've done for the script compiler.

The build-in script won't touch the areas beyond the CCB and BD area. So if you put your ram scripts in one place(that SDMA can reach and non-cacheable), I think you don't worry about if it's overwritten by the script itself. And on the other hand, when you've downloaded the script into SDMA RAM, the user data and script code are handled by the core according to the channel that run your script, so, it's safe.

 


Eli Billauer said:

Thanks for your answers.

I'm working a script of my own. As for the assembler, I wrote a simple one in Perl. With the extremely simple instruction set it was pretty quick, and it gives me C code to use directly. I'll publish it pretty soon. Not something very fancy, but it does the job.

So the only built-in script I use is the Channel 0 script for loading data back and forth. Since the imx-sdma.c Linux kernel module shows how to use it, I'm pretty much covered.

As a matter of fact, I've managed to run a little piece of code already.

The only thing I'm worried about right now is interoperability. I have no idea what regions in the RAM the built-in scripts may write to, and hence I'm not really sure where I can put my own stuff safely.

Maybe someone could tip me off on this? What piece of the RAM is considered absolutely safe for user data and scripts?

Thanks,

   Eli

0 Kudos

174 Views
billauer
Contributor II

Thanks for your answers.

I'm working a script of my own. As for the assembler, I wrote a simple one in Perl. With the extremely simple instruction set it was pretty quick, and it gives me C code to use directly. I'll publish it pretty soon. Not something very fancy, but it does the job.

So the only built-in script I use is the Channel 0 script for loading data back and forth. Since the imx-sdma.c Linux kernel module shows how to use it, I'm pretty much covered.

As a matter of fact, I've managed to run a little piece of code already.

The only thing I'm worried about right now is interoperability. I have no idea what regions in the RAM the built-in scripts may write to, and hence I'm not really sure where I can put my own stuff safely.

Maybe someone could tip me off on this? What piece of the RAM is considered absolutely safe for user data and scripts?

Thanks,

   Eli

0 Kudos

174 Views
StevenPan
Contributor I

The SDMA script user manual is to tell you the function and usage of the SDMA scripts that released. Like the configuration of channel context and buffer descriptor.

 

Unfortunately I either can't find this manual on outside web. From MX53 on, this manual will be presented as appendix of the SoC Reference Manual. Maybe you could look to the MX53 RM for the usage of some common scripts, like memory to peripheral and peripheral to memory... They're not changed between MX51 and MX53.

 

If you would like to, you could compare the header files of the script code for MX51 and MX53, compare the size of each script, if the script with same name and same size, they're possibly the same.

0 Kudos

174 Views
KarlLu
Contributor I

Are you going to use the existing scripts or your want to develop a new script on my own? If you want to develop the new script, you need to request the assembler and linker for SDMA core coding.

0 Kudos

174 Views
billauer
Contributor II

Hmmm... I could actually see that answer coming.

It looks like I'm going to rely on reverse engineering. This is what I've been doing so far anyhow, even with regards to things for which I apparently have all documentation available. Judging from the Reference Manual and the datasheet, I'm not sure how much these extra docs are going to help.

And given that I'm going to release my work on the web, signing an NDA is not necessarily the right thing to do.

Thanks for your answer anyhow.

0 Kudos

174 Views
daiane_angolini
NXP Employee
NXP Employee
Please, contact your local FSL representative or create an SR. You will need NDA if you want to see the docs.