Andy Ngo wrote: > Thanks, but how do I set the range uncacheable? I don't see such an > option for mmap. Please advise. Thanks! does it help to open /dev/mem with O_SYNC? > > Regards, > Andy > > ----- Original Message ---- > From: YunChuan Qin <[EMAIL PROTECTED]> > To: Andy Ngo <[EMAIL PROTECTED]> > Sent: Thursday, May 10, 2007 9:38:46 PM > Subject: Re: mmap issue > > set this memory range uncacheable may solve your problem. > > 2007/5/11, Andy Ngo <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>: > > Hi, > > This is more of a Linux question than anything. Hopefully someone > can help me. Our custom board has the Davinci exchanging data > with a Xilinx Virtex 5 Pro FPGA Microblaze processor via a shared > (Dual-Port) RAM interface. The shared RAM is 128Kb and is hooked > us to CS4 on the AEMIF. In order to access this shared RAM memory > space (physical address is 0x06000000), our application is using > mmap to map it to a virtual address space. Here's a snippet of > the mmap initialization: > > int fd; > unsigned char *shareRamPtr; > > fd = open("/dev/mem", O_RDWR); > sharedRamPtr = (unsigned char *)mmap(0, 0x20000 /* 128 Kb */, > PROT_READ | PROT_WRITE, > MAP_SHARED, fd, 0x06000000); > > It seems to work but not quite. We have a interrupt processing > handler that needs access (writes as well as reads) this space in > real-time every 2ms. Sometimes, when the FPGA Microblaze write > values to the shared RAM, and when our ARM processor on the > Davinci reads them during the interrupt processing, the data looks > staled (as though from previous reads). I googled and found that > writes require a call to msync to flush writes to the actual > shared RAM interface. So here are my questions: > > 1) If I need the writes to be real-time (immediately flushed out > to the shared RAM), do I have to call msync every single time I do > a write? If this is the case, isn't this very inefficient? Does > msync have to check the whole 0x20000 range to check what bytes > need to be flushed? > 2) How about for reads? As mentioned above, I seem to get stale > data sometimes during reads. Since the Microblaze is constantly > writing to shared RAM, what needs to be done so that when the ARM > reads the data at those locations, they are what the Microblaze wrote? > 3) I tried using MAP_PRIVATE and it doesn't seem to map to the > shared RAM space at all (mmap doesn't return an error but I can't > write or read from it). Is there anyway to force the mechanism > behind mmap (driver for /dev/mem ?) to force a flush everytime the > ARM writes to shared RAM without having to call msync? > > Please advise. Thanks. > > Regards, > Andy > > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > <mailto:[email protected]> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > <http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source> > > > > > -- > blog site:blog.csdn.net/freasy <http://blog.csdn.net/freasy> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >
-- * Matthias Welwarsky Project Manager Software Germany * ____________________________________________________________________________ This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. E-mail messages are not necessarily secure. Archos does not accept responsibility for any changes made to this message after it was sent.
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
