DM368 CMEM setting over 128MB area

Woo-Seung Yeo35126

Other Parts Discussed in Thread: OMAP3530

Dear Champs,

I tried to assign CMEM area over 128MB on DM368 but DM368 IPNC got stuck. It has not responded in console since then. Even it doesn’t respond to “ctrl-C”.

Details of DM368 IPNC configuration and the issue are as follows.

1. How to set CMEM area over 128MB.

1. ex) insmod modules/cmemk.ko phys_start=0x88000000 phys_end=0x8C000000 pools=1x362880

2. Symptom of the issue : System got stuck while running insmod. (No response in console. IPNC doesn’t respond to even ‘Ctrl-C’.)

3. Assigned Kernel memory size is 96MB.

4. Direct memory read/write over 128MB by application does have no issue. To check direct memory access, m_pUserPtr memory pointer was used as result of mmap() using i_dwPhyAddr = 0x88000000 and i_dwLength = 0x01000000.

m_fdMem = open("/dev/mem", O_RDWR);

m_pUserPtr = (unsigned char*)mmap(NULL, i_dwLength, PROT_READ|PROT_WRITE, MAP_PRIVATE, m_fdMem, i_dwPhyAddr);

5. IPNC environment

1. DM368

2. DVSDK: 2.10.1.18

3. linuxutils 2.24.03

To verify that linuxutils support CMEM area setting over 128M, I referred to the link:

http://wiki.davincidsp.com/index.php/HOWTO_Change_the_Linux_Kernel_Start_Address#Updating_CMEM_Memory_Region

In other source, I found out the same issue on DM365.

http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg16768.html

I want to get confirmed that DM368 has no problem in setting CMEM over 128M and to get the detail information of how to set it if the link above has some broken information for DM368.

WS Yeo

over 15 years ago

0 Robert Tivy over 15 years ago

TI__Mastermind 18260 points

CMEM shouldn't care about the actual physical address, so I don't know what could be the problem. Hopefully someone with more knowledge of Linux on DM365 can offer some clue.

To help us help you, could you build a debug version of cmemk.ko, try that out, and send us CMEM's console output (until it gets stuck)? You can build the debug cmemk.ko by going to your Linux Utils package directory and:
% cd ti/sdo/linuxutils/cmem/src/module
% make debug
This assumes you have the ability to build CMEM for your Linux version (which requires editing Rules.make to point LINUXKERNEL_INSTALL_DIR to your Linux).

You've demonstrated that an mmap()ed pointer through /dev/mem can access it, perhaps /dev/mem is doing something to enable accesses past 128MB. Maybe a good thing to try would be to give the Linux kernel some small portion of this 2nd 128MB and let it initialize it properly (could be accomplished by setting mem=132M, for example, and starting CMEM @ 0x88400000.

Regards,

- Rob

0 Woo-Seung Yeo35126 over 15 years ago in reply to Robert Tivy

TI__Intellectual 1890 points

Hello Robert,

Robert Tivy said:

CMEM shouldn't care about the actual physical address, so I don't know what could be the problem. Hopefully someone with more knowledge of Linux on DM365 can offer some clue.

To help us help you, could you build a debug version of cmemk.ko, try that out, and send us CMEM's console output (until it gets stuck)? You can build the debug cmemk.ko by going to your Linux Utils package directory and:
% cd ti/sdo/linuxutils/cmem/src/module
% make debug
This assumes you have the ability to build CMEM for your Linux version (which requires editing Rules.make to point LINUXKERNEL_INSTALL_DIR to your Linux).

I rebuild debug version of cmemk.ko and tried to install cmemk.ko with parameters of phys_start=0x88000000 and phys_end=0x89C00000.

But DM368 IP Netcam got stuck again without printing any log message.

Robert Tivy said:

You've demonstrated that an mmap()ed pointer through /dev/mem can access it, perhaps /dev/mem is doing something to enable accesses past 128MB. Maybe a good thing to try would be to give the Linux kernel some small portion of this 2nd 128MB and let it initialize it properly (could be accomplished by setting mem=132M, for example, and starting CMEM @ 0x88400000.

For kernel address space setting mem=132M, the system locked up after printing "Uncompressing Linux..... done, booting the kernel."

I tried some more test using different memory size from 132M to 256MB, every setting made system lock-up.

1. It looks that exact point of lock-up in the booting process is different depending mem size.

2. With many trials using same mem size, Lock up point looks the same.

3. I tried the test again using another board. It also locked up at the same point in the booting.

To check memory access over 128MB in hardware perspective, I tried to read/write the memory region using JTAG emulator. I couldn't find any problem in that access.

You said that CMEM shouldn't care about the actual physical address. It's somewhat strange in the kernel memory test result.

But mmap() and JTAG test have no issue in the memory access over 128MB.

I wonder that there is any requirement in kernel configuration or device driver setting to access memory over 128MB.

Thank you.

0 Robert Tivy over 15 years ago in reply to Woo-Seung Yeo35126

TI__Mastermind 18260 points

I think we should eliminate CMEM as a culprit here. I wasn't able to find a DM365 or DM368 w/ 256 MB DRAM but I did find an OMAP3530 with 256 MB, and CMEM worked fine on that when insmod'ing phys_start=0x88000000 and phys_end=0x89000000. I could even do a "%cat /proc/iomem" after the insmod and it showed CMEM owning that range of phys mem.

Have you tried your cmemk.ko while using memory below 128 MB? Perhaps there is something fundamentally wrong with your cmemk.ko build, and trying this would validate your cmemk.ko.

The fact that the kernel can't boot with mem=132M (or greater) indicates something fundamentally wrong with the memory (unless the Linux kernel is known to not be able to handle memory above 128 MB, but I'm not aware of such a limitation). The fact that JTAG can access it doesn't really tell us much, since JTAG is a much slower access method and uses a different path to the memory (i.e., not the CPU). The fact that the /dev/mem mmap() method works is interesting, but given everything else we know about this situation, I wouldn't be surprised to find out that the mmap() was not actually mapping the memory that you requested it to map (it might have *though* it was mapping to 0x88000000, but instead mapped to some other valid mem).

As far as we (TI) know, cmemk.ko is doing everything it needs to do to map the requested memory range. I have to suppose that any problem when using CMEM with phys mem above 0x88000000 is due to inherent problems inside the Linux kernel.

That's about as far as I can help here, since my Linux kernel knowledge doesn't extend much beyond what Linux Utils modules are doing. CMEM often gets blamed because it is being the messenger of a problem that lies elsewhere (not to say that CMEM has no problems, just that it gets blamed often even when the problem lies elsewhere).

Regards,

- Rob

0 Hongfeng Wang over 14 years ago

Genius 3925 points

So what have you eventually found out with your problem? Could you share the solution with me?

I have same problem with memory. If I only use lower 128MB, everything looks normal, the kernel and cmem all work fine.

But if I try to use anything beyond that, either in Kernel or cmem, they will hang without any output.

I can r/w to the upper 128MB memory in uboot without any obvious problem.

Processors

Processors forum

DM368 CMEM setting over 128MB area