* Reg. virtual address space in embedded linux
@ 2006-07-22 5:55 jagannathanjay
2006-07-25 4:03 ` David H. Lynch Jr.
0 siblings, 1 reply; 2+ messages in thread
From: jagannathanjay @ 2006-07-22 5:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 958 bytes --]
Hi all
We are porting third party driver code from vxworks to Embedded linux in MPC 8260 under a evaluation platform from Embedded Planet in linux kernel space.
The first step we carried out was reading the chip id and we were able to read the chip id correctly. For reading the chip id we used the routine ChipReadMemory in the attached text and we were able to retrive the chip id successfully. Subsequently when we write and read from Chip Specific Control Status registers ,it didn't work. I checked the manual and the Chip Specific Control Status registers have RW access. Any inputs on how to check if the write we made to virtual address succeeds? Is there a way to dump the linux virtual address and examine the write we made ?
Regards
Jay
________________________________________________________________________
Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection.
[-- Attachment #1.2: Type: text/html, Size: 2129 bytes --]
[-- Attachment #2: RWroutines.txt --]
[-- Type: text/plain, Size: 831 bytes --]
int ChipReadMemory(unsigned int arg_phys_addr,unsigned int *memValue)
{
void *virt_addr = NULL;
unsigned int phys_addr = 0;
phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
virt_addr = ioremap(phys_addr, 4);
if(virt_addr == NULL)
{
printk("ChipReadMemory: unable to perform ioremap \n");
return -1;
}
*memValue = readl(virt_addr);
iounmap(virt_addr);
return 0;
}
int ChipWriteMemory(unsigned int arg_phys_addr, unsigned int arg_val)
{
void *virt_addr = NULL;
unsigned int phys_addr = 0;
phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
virt_addr = ioremap(phys_addr, 4);
if(virt_addr == NULL)
{
printk("ChipWriteMemory : unable to perform ioremap \n");
return -1;
}
writel(arg_val,virt_addr);
iounmap(virt_addr);
return 0;
}
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Reg. virtual address space in embedded linux
2006-07-22 5:55 Reg. virtual address space in embedded linux jagannathanjay
@ 2006-07-25 4:03 ` David H. Lynch Jr.
0 siblings, 0 replies; 2+ messages in thread
From: David H. Lynch Jr. @ 2006-07-25 4:03 UTC (permalink / raw)
To: jagannathanjay, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3255 bytes --]
Is there a reason you need to map and unmap physical/virtual memory
every time you do a read or write ?
I think the norm is to map the physical region in your device driver
in its initialization code and unmap it if the driver exits.
After that you should be able to read and write your chip as you
wish. If the registers are RW then you should be able to "dump" them by
reading them at whatever later time you choose.
jagannathanjay@aim.com wrote:
> Hi all
>
> We are porting third party driver code from vxworks to Embedded linux
> in MPC 8260 under a evaluation platform from Embedded Planet in linux
> kernel space.
>
> The first step we carried out was reading the chip id and we were able
> to read the chip id correctly.
>
> For reading the chip id we used the routine ChipReadMemory in the
> attached text and we were able to retrive the chip id successfully.
>
> Subsequently when we write and read from Chip Specific Control Status
> registers ,it didn't work.
>
> I checked the manual and the Chip Specific Control Status registers
> have RW access.
>
> Any inputs on how to check if the write we made to virtual address
> succeeds?
>
> Is there a way to dump the linux virtual address and examine the write
> we made ?
>
> Regards
> Jay
>
>
> ------------------------------------------------------------------------
> *Check Out the new free AIM(R) Mail*
> <http://pr.atwola.com/promoclk/100122638x1081283466x1074645346/aol?redir=http%3A%2F%2Fwww%2Eaim%2Ecom%2Ffun%2Fmail%2F>
> -- 2 GB of storage and industry-leading spam and email virus protection.
> ------------------------------------------------------------------------
>
> int ChipReadMemory(unsigned int arg_phys_addr,unsigned int *memValue)
> {
> void *virt_addr = NULL;
> unsigned int phys_addr = 0;
>
> phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
> virt_addr = ioremap(phys_addr, 4);
> if(virt_addr == NULL)
> {
> printk("ChipReadMemory: unable to perform ioremap \n");
> return -1;
> }
> *memValue = readl(virt_addr);
> iounmap(virt_addr);
> return 0;
> }
>
>
> int ChipWriteMemory(unsigned int arg_phys_addr, unsigned int arg_val)
> {
> void *virt_addr = NULL;
> unsigned int phys_addr = 0;
> phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
> virt_addr = ioremap(phys_addr, 4);
> if(virt_addr == NULL)
> {
> printk("ChipWriteMemory : unable to perform ioremap \n");
> return -1;
> }
> writel(arg_val,virt_addr);
> iounmap(virt_addr);
> return 0;
> }
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 4965 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-07-25 4:03 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-22 5:55 Reg. virtual address space in embedded linux jagannathanjay
2006-07-25 4:03 ` David H. Lynch Jr.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).