hi,
I am new to ARM and also to Linux. I am using OLIMEX BOARD (AT91SAM9260). its working good i have ported linux in it and wrote simple programs lik hello world. I don’t know how to access the GPIO pin (port a, port b and c) in linux. please can any one help me. thank you 
rajalakshmi.nr:
hi,I am new to ARM and also to Linux. I am using OLIMEX BOARD (AT91SAM9260). its working good i have ported linux in it and wrote simple programs lik hello world. I don’t know how to access the GPIO pin (port a, port b and c) in linux. please can any one help me. thank you
Hi,I am also trying to work out how to do this- I have managed to get cross compiled modules to load into the AT91SAM9260 running linux- now I just need to know how to get the GPIO pins working.
chopley:
Hi,I am also trying to work out how to do this- I have managed to get cross compiled modules to load into the AT91SAM9260 running linux- now I just need to know how to get the GPIO pins working.
if i compile the test code given i m getting many errors… so i modified the code then compiled… after tat i loaded the output file to at91sam9260 but its giving segmentation fault 
I’m also looking fo help on how to get started with this. Any suggestions would be greatly appreciated.
You can’t modify GPIO pins willy-nilly from a user-space program which is what I suspect is happening here - that’s what the MMU is for. You’ll get a seg fault because you’re not supposed to be able to do that.
To do this you must interact with the kernel to get that kind of access. You could do this through a kernel module for example. That might make sense if you want to write a driver for the device on the GPIO pins that your apps can use: use the module to create a level of abstraction.
(Think about how your general-purpose PC works. Apps don’t work with hardware. Drivers in the kernel do. The same principle applies here and has been used in the PC since the MMU was introduced in the 386 years ago and the use of operating systems like Windows NT and desktop Linux.)
It looks like you can also map physical memory into an app’s virtual memory without writing any kernel-level code; that would work too. See http://www.simtec.co.uk/appnotes/AN0014/. That looks like a run-around of the traditional app-interacts-with-driver model to save a little time.
If you’re still a little lost I recommend reading up on what an MMU does. To summarize, you’re not working with a flat memory space anymore like with ucLinux or a small real-time executive RTOS - every app has its own memory space which increases system stability and flexibility (e.g. an OS can swap pages to hard disk, the stack and heap for an app can be placed at opposite ends of the 32-bit memory space, eliminating the chance of the stack overwriting the heap and vice versa [well there are some other tricks used there too, enabled by use of MMU]: if too much memory is used you’d get out-of-memory error and not a random crash caused by corruption of data). Only the kernel gets full access to the physical memory space.
[Here is a sample kernel module for working with I/O pins. I have not tested it myself, yet.](http://limpens.net/cgi-bin/trac+sam91.cgi/wiki/KernelModule)