[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
>
>