Sharing large buffers between A5 and M4 in Vybrid VF6xx

cancel
Showing results for 
Search instead for 
Did you mean: 

Sharing large buffers between A5 and M4 in Vybrid VF6xx

Jump to solution
1,948 Views
rbarris
Contributor I

[reposting, had it in the wrong forum before..]

Say a userspace process on Linux on the A5 downloads a large signal file into memory (DDR3).  I make the assumption that because this is Linux, there is an MMU active, the the underlying physical memory backing the allocation may not be contiguous..

what's involved in enabling the M4 to look into that buffer and play back the signal through the DAC?

Is there a path whereby the process on A5 side can explicitly allocate a chunk of contiguous memory that is linearly mapped, populate it, and then inform the M4 where it is in physical RAM.

I am sure I have some faulty assumptions here; the underlying idea is can I have both processors able to access a single large buffer in DDR3.

Labels (4)
0 Kudos
1 Solution
274 Views
anthony_huereca
NXP Employee
NXP Employee

Hi Rob,

  By default the shared memory space used by MCC is in the internal SRAM. That would be modifiable by changing the source though. But to your larger question, yes, the M4 has access to all the DDR memory space that the A5 has access to.

-Anthony

View solution in original post

0 Kudos
12 Replies
274 Views
anthony_huereca
NXP Employee
NXP Employee

Hi Rob,

  This is what MCC was created for. You can modify the size of the default buffer so that it can fit your data. From the Vybrid FAQ:

What is this Multi-Core Communication (MCC) I hear about?

It's an API developed between Freescale and Timesys to provide easy communication between the A5 and M4 cores. You can use it to transfer data between Linux on A5 and MQX on M4, or between MQX on both cores. You are not required to use it, as it is just a software option, but it will probably make your coding easier. Documentation on it can be found on the Timesys website and in the MQX release in the "docs" folder

-Anthony

0 Kudos
274 Views
rbarris
Contributor I

I may be missing something, but it seems like everything in this doc refers to a block of memory which resides in the onchip SRAM.  Is it possible for the M4 to access data in the DDR3 (off chip) memory ?  For example if the A5 core loads a 16MB lookup table into DDR3 memory, how can the M4 gain access to it?

0 Kudos
275 Views
anthony_huereca
NXP Employee
NXP Employee

Hi Rob,

  By default the shared memory space used by MCC is in the internal SRAM. That would be modifiable by changing the source though. But to your larger question, yes, the M4 has access to all the DDR memory space that the A5 has access to.

-Anthony

View solution in original post

0 Kudos
274 Views
johannestraxler
Contributor III

Dear Anthony,

I'm interested in accessing the DDR from the M4 core. I have a buffer (~24kByte) that is constantly updated by a Linux application running on A5 core, but the M4 only needs to read some parts of this buffer from time to time. From my sight it would be a good choice to directly access the buffer without using MCC. Is there an example available for reading from DDR with M4 and can you advice how to find out the correct start address of the buffer for M4?

Thanks,

Johannes

0 Kudos
274 Views
anthony_huereca
NXP Employee
NXP Employee

Hi Johannes,

  There's no "trick" to have the M4 read the DDR space, you would read it just like any other memory address. The full DDR space starting at 0x8000_0000 is accessible to both cores, using the same address.

  The only thing to keep in mind is any cache that the A5/Linux might be using, as the cache would need to be flushed out and written to DDR before the M4 could access it.

-Anthony

0 Kudos
274 Views
jackblather
Senior Contributor I

Can one *execute* a program in DDR on the M4? Or does the system allow only data accesses? Yes, the A5 and M4 would have to compete for bus time for the external DDR3 memory, but is it possible?

0 Kudos
274 Views
rbarris
Contributor I

It sounds simple enough, until you start up a userspace process on the A5 in Linux, and allocate some memory and put data in it, and then need to communicate the physical address to the M4.  There is a scatter-gather and a logical->physical problem here, am I right ?

As I understand it the M4 only sees physical addresses, and an app running in Linux is only going to see logical addresses (and the physical pages backing that may not be contiguous).

So a different tack on this question is, what steps can an app take on A5/Linux side, to do these things:

a) allocate a chunk of memory which is physically contiguous and has monotonic V->P mapping for each of its pages

b) obtain the physical address of the base of that memory

c) ensure that this memory stays wired and doesn't get relocated / paged out / etc

If these things can be done, then it should be easy to communicate to the M4 where the bits actually are.

(Unless I'm completely wrong and the M4 has an MMU that can follow along with whatever V->P mapping the Linux kernel is arranging for the app)

0 Kudos
274 Views
johannestraxler
Contributor III

@Rob: Exactly, that's why I continue this thread, since I was wondering if anybody already tried it. I am thinking of a shared memory which gets created and initialized from linux user space. This ensures your question c) and I think also partly a).

For b) I hope that there is the option to fetch the start physical address, which then can be for example transmitted to the M4 via MCC. This also allows some sort of synchronization in case of updating the memory content from A5 side. But as far as I've seen right now it is not possible to get the physical address within the program running in user space.

0 Kudos
274 Views
ed_nash
Contributor III

Hi-

What you want to do is very doable as follows:

1. Limit the upper end of RAM (DDR) that Linux has access to via the uboot argument mem=. Assume you have 1 gig of memory (0x40000000) and lets assume you want to use 64MEG (0x4000000) for shared. Then you would add mem=0x3c000000 to your bootargs.

2. on LInux use mmap and /dev/mem to get a user-space pointer to the address - because you are treating it as if it were a device.

int fd = open( "/dev/mem", O_RDWR | O_SYNC );

unsigned char * data_p = (int *)(mmap(0,MAPPED_SIZE,PROT_READ|PROT_WRITE,MAP_SHARED, fd, 0x3c000000));


3. On MQX you can simple use the physical address as a pointer.


Since you are not using SRAM, you can still use MCC for communication.


Hope this helps,

Ed

0 Kudos
274 Views
johannestraxler
Contributor III

Dear Ed,

thank you very much - this is indeed a good method which should be possible!

BR, Johannes

0 Kudos
274 Views
ed_nash
Contributor III

One last point-

the mem= limits the size of memory, not the last address (as in my example). ram may not be mapped starting at 0 (probably not). if you cat /proc/iomem you'll see the physical address of system ram. So you may have to adjust your physical address in the mmap call (i.e., subtract 64M from what proc/iomem shows as the top).

Ed

0 Kudos
274 Views
anthony_huereca
NXP Employee
NXP Employee

Timesys Support might be able to weigh in here and what is possible.

0 Kudos