[linux-sh:03440] Re: sh-linux mmap problem
"Kristoffer Ericson" <[email protected]> Thu, 25 May 2006 00:59:40 +0000
| Newsgroups | gmane.linux.ports.sh.general |
|---|---|
| Message-ID | <[email protected]> |
Greetings, This list is more or less dead, you will probobly have more luck to talk to www.linux-sh.org or on freenode (irc) #linux-sh. Best wishes Kristoffer www.jlime.com >From: "Mohit Jain" <[email protected]> >To: [email protected] >Subject: [linux-sh:03439] sh-linux mmap problem >Date: Thu, 25 May 2006 09:44:22 +0900 > >Hi all, > >I have been working on sh4-Linux. I have got some >register (4 Byte each) in my SRAM that is in P2 area (non cacheable). >To Read write >those registers, I have mapped the pages containing registers in user >space. When I access these registers everything goes OK except for 2 >registers lodged at address 0xb8000030 and 0xb8000038. This page is >mapped as write only, problem persist even if the page is mapped as >read-write(read is OK write causes problem). Whenever I try to write >anything on these registers, screen goes blank. > >When I tried to debug out the problem, I got the following observation: >When I write something(even a byte) on virtual memory, at least 32 >bytes of physical memory is refreshed. > >say old data is:(L is Location (address), Old and New are Data) >*L1= Old1, *L2= Old2, *L3=Old3 .....................*L32=Old 32 > >and I overwrite Old2 with New2, In physical memory L2 = Old2 should happen. > >But actual picture is: >*L1 = Old1 >*L2 = New2 >*L3 = Old3 >. >. >. >*L32=Old32 > >that is all locations are refreshed. If I write some data at >0xb8000030, memory locations from 0xb8000020 to 0xb800003f are >refreshed). Address 0xb8000020 contains the video reset register and >if it is overwritten, even by the same data, video display goes blank. > >Please help if anybody can reply. >Code I am using is(for read and write): >[Compiler used is sh4-linux-gcc, generates no warning in the code when >compiled with options -Wall -Wcast-align] > >physical address stored in a variable pa = 0xb8000000 > >{ > fd = open ("/dev/mem", O_RDWR | O_SYNC); > if (fd == -1) return fd; > map_base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, >fd, pa & ~MAP_MASK); > if(map_base[tmp] == (void *) -1) > { > fclose(fd); > return -1; > } > addr = map_base + (pa & MAP_MASK); > buf = (char *)addr; > buf[30] = 'A'; > msync (addr, MAP_SIZE, MS_SYNC); > return 0; >} > >I have been digging out the sh4 manual to see if there is some setting >problem in hardware. >Data is reaching at proper place (Physical location) because: >1. All other registers are working well. >2. To solve the problem temporarily and continue the development, I >have lodged register (by changing FPGA data) at some other place >(0xa7000030, still in P2 area, still write only registers), and the >board is working well. > >But as per final specification and our requirement I need to shift it >back to where they were when problem appeared. >I use /dev/mem for just mapping (physical to user space). I want to >know who copies the data from mapped (virtual) memory actual >(physical) memory. Whether it is some daemon in OS which continuously >copies the data from virtual (mapped) memory to physical whenever >there is some change in virtual memory (Done by OS) or mapping does >some entry in MMU part of CPU so what ever we try to write on mapped >area is written directly over translated (physical) memory locations >(Done by CPU). >Screen still (after changing FPGA data) goes blank when I try to >writing on video reset (0xb8000020) register, or even any memory >location from 0xb8000020 to 0xb800003f. > >Being from electronics stream, I'm not very good in operating systems. >I'm just learning OS. Please tell if you know about any such daemon or >the file(s) of kernel responsible for it, so that I may recompile it. >I'm still looking if it is a hardware issue. > >One more thing I want to ask is: can I use DMA to transfer this 4 byte >of data, as DMA has direct access to physical address space. > >Thanks in advance. > >Regards, >Mohit > >