DIMM size

Thank you for your reply, David!

I am a bit confused, cause I learned that ARM and DSP shared the DIMM in KeyStone II, right? 

dzhou said:

Hello Cheng,

free is showing the memory used by ARM

mem_reserve is reserving the memory used by C66x(DSP).

So total ARM + DSP = 0.5G + 1.5 G = 2 G.

regards,

David

Cheng,

U-Boot has mem_reserve env variable to reserve DDR3 memory at the end of the 32 bit address space. This will be useful for reserving memory for DSP. Based on the memory availability on the board, the address range of this region will change. So any users of this feature need to make sure the address match with what is reserved through this mechanism. Otherwise the user application can step into kernel memory space and cause kernel crash during system operation. By default 512M memory is reserved at the end of the address space. To change the default size, user need to update this env variable and save the configuration using saveenv command.

regards,

David

Thanks, David,

By modifying the 

setenv mem_reserve

I could finally configure a larger memory size for the ARM.

But I am still not clear that ARM and DSP shared the physical DIMM, isn't it? Why I have to split the memory into ARM and DSP side? 

For instance, for the EVM with 8G memory. I could only create up to 4GByte data on the ARM and move it to DSPs, right?

Thanks

Hi Cheng,

ARM and DSP share physical memory not virtual memory. In this case, when you reserve 512 MB for ARM, it means you are reserving that memory for ARM Linux. If you cat /proc/iomem, this becomes quite clear:

800000000-81fffffff : System RAM
  800008000-8006b178f : Kernel code
  800704000-800775f33 : Kernel data

TI provides the cmem module that is used by both OpenCL and OpenMPAcc to allocate contiguous chunks of memory that are available for use to both the ARM and DSP. This cmem region is outside of ARM Linux memory range. When your cmem kernel module is loaded, you will be able to see this again from /proc/iomem:

0c040000-0c4fffff : CMEM - This is in MSMC SRAM

823000000-87fffffff : CMEM - This is in DDR 

Of course, the cmem range may differ based on the parameters that were used while loading the kernel module.  

So if you wanted to create a 4Gbyte shared buffer (using OpenCL or OpenMPAcc) between the ARM and DSP, this would be created in cmem and no data movement would be required.  

Gaurav

Hi Gaurav,

Thanks for your reply. It did reply my question. 

Just a follow up question: 

If I created a memory at the Host, e.g., 

double *data = (double *) malloc (size_t * sizeof(double));

#pragma omp target map (to:data[0: size_t)

#pragma omp parallel for

for(int i=0; i< size_t; i++)

     data[i] ...

So what happened on the memory allocation? 

I suppose in this case the array of "data" is allocated on the host, which is at the memory region of the Linux on ARM, right? 

Hi Cheng,

Yes. In this case:

1. *data is allocated in a heap within ARM Linux host memory
2. #pragma omp target map(to:data[0:size_t]) performs a memcpy from *data in ARM Linux host memory to a DSP device buffer in CMEM
3. #pragma omp parallel region operates on this DSP device buffer
4. If you had a map(from:data[0:size_t]) or specified tofrom instead of to initially, the DSP device buffer would be memcpy'd out to *data in ARM Linux host memory

Gaurav

Thanks Gaurav,

So using __TI_omp_device_alloc() could avoid the data copies from host to device, and verse vera... and will yield to better performance, right?

Thanks

Cheng

That is correct Cheng.

Gaurav

Thanks for your patience, Gaurav,

I appreciate it!!

Cheng