From Gumstix User Wiki
Revision as of 06:00, 12 February 2010 by Sellis (Talk | contribs) (Added Overo stuff)

Jump to: navigation, search

Overo GPIO

The Overo kernels support the sysfs gpio implementation for accessing GPIO from userspace.

This allows you to control GPIO from the command line this way

root@overo# echo 146 > /sys/class/gpio/export
root@overo:/sys/class/gpio# cat gpio146/direction
root@overo# echo out > /sys/class/gpio/gpio146/direction
root@overo:/sys/class/gpio# cat gpio146/direction
root@overo# cat /sys/class/gpio/gpio146/value
root@overo# echo 1 > /sys/class/gpio/gpio146/value
root@overo# cat /sys/class/gpio/gpio146/value

If you have an expansion card with a 40 pin header, then this will be controlling pin 27. You can use pin 1 for a ground. (If you don't have a meter, a p/n 276-0330 1.8V Red LED from Radio Shack works for testing.)

Schematics and pin-outs for the Gumstix expansion boards can be found here.

How It Works

See the kernel docs gpio.txt for an overview of gpio and the userspace sysfs interface. The "Sysfs Interface for Userspace (OPTIONAL)" section near the end discusses the userspace implementation.

See the OMAP35X Technical Reference Manual Section 7.6.3 PADCONFS Register Description and Table 7.5 Core Control Module PadConf Register Field in Section Pad Multiplexing Register Fields for identifying the possible MUX configuration for each GPIO.

Then see the U-Boot source code, board/overo/overo.h for how the pins on the Overo are actually being muxed. See include/asm-arm/arch-omap3/mux.h in the U-Boot tree for the definitions used in overo.h. The pins in mux mode M4 are already configured for GPIO.

Making Modifications

Currently all the GPIO multiplexing for the Overo's is being done by the bootloader U-Boot, so the conventional way to modify the pin muxing is to edit overo.h and rebuild U-Boot.

You can also change the mux configuration from within Linux. One simple approach is to do it from userspace accessing /dev/mem. A program devmem2 is part of the omap3-console-image and will work. TODO: show an example

If you are writing your own kernel module, you can also read/write the PADCONF registers the way you normally would after an ioremap.

Third, there is a Linux build config option CONFIG_OMAP_MUX, not normally enabled in the Overo configs, that will give you some additional utility functions to simplify mux changes within kernel or module code (see arch/arm/plat-omap/mux.c).

Finally, it looks like the Linux OMAP34xx pin muxing code is getting a complete overhaul. See this thread on the Linux OMAP mailing list. Judging from some posts on the Gumstix lists, it sounds like this will be available in 2.6.33.

Overo Kernel Usage

Just because pins are configured as GPIO in u-boot, doesn't necessarily mean you can use them. If you look at /sys/class/gpio on a default Overo, you'll get something like this.

root@overo:~# ls /sys/class/gpio
export	gpio164  gpio65       gpiochip160  gpiochip64
gpio15	gpio168  gpiochip0    gpiochip192  gpiochip96
gpio16	gpio176  gpiochip128  gpiochip32   unexport

The reason you see some GPIO already exported is because the linux code in arch/arm/mach-omap2/board-overo.c is explicitly exporting these pins for another use. Whether they are being used depends on the hardware you have attached. The kernel also uses pins configured as GPIO that it doesn't export. These depend on the board configuration and the kernel drivers being used.

To be more explicit, look inside board-overo.c, you'll see these definitions

#define OVERO_GPIO_BT_XGATE     15
#define OVERO_GPIO_W2W_NRESET   16
#define OVERO_GPIO_PENDOWN      114
#define OVERO_GPIO_BT_NRESET    164
#define OVERO_GPIO_USBH_CPEN    168
#define OVERO_SMSC911X_GPIO    176
#define OVERO_SMSC911X2_GPIO   65
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145

Follow their usage inside the file and you will be able to explain the /sys/class/gpio output you see above.

Input or Output

Pins configured as GPIO are sometimes also specified as being strictly input or output.

This can happen when they are mux'd or when they are explicitly exported by the kernel.

In either of those cases you won't be able to change the I/O direction from userspace.

Electrical Specifications

Voltage is 1.8v

Current specifications <TODO ???>

Usable Pins

Here's a few GPIO you can use immediately from userspace without any u-boot or kernel changes.

40 Pin Expansion Header

Pin 4 - gpio114
It's the pendown signal on the touchscreen controller but it's available if you aren't using a touchscreen.
Configured as input only when exported by the kernel in board-overo.h. Can't change the direction from userspace without modifying kernel.
Pulled-low, reads 0 with no input, reads 1 with an input applied

Pin 19 - gpio170
The HDQ/1-Wire output. Not used unless you explicitly enable the 1-wire module.
User exportable
Output only - configured this way in the u-boot muxing

Pin 27 - gpio146
Pin 29 - gpio147
User exportable
Direction can be changed
Floating state

Pin 28 - gpio145
Pin 30 - gpio144
Used with LCD, but available if not using an LCD
Configured as output only when exported by the kernel in board-overo.h. Can't change direction from userspace without modifying kernel.
Set to ON by kernel during init (not all configs, see board-overo.c). This could be a problem for real use, but okay for testing.

Palo43 Board

LED D2 - gpio21
LED D3 - gpio22
Userspace exportable, set the direction as out
echo 0 > gpioxx/value to turn on, echo 1 > gpioxx/value to turn off

Switch - gpio14
Switch - gpio23
Userspace exportable, leave direction as in
With the switch open (not pushed) will register a value of 1
Push the switch and the value will be 0

GPIO Software for the Overo

Dave Hylands has written several software packages to facilitate GPIO programming on the Overos.

GPIO Event Driver allows multiple GPIO lines to be monitored from user-space.

User GPIO Driver is a reflection of the kernel's gpiolib API into user space.

More Links

Here is another article BeagleBoardPinMux talking about OMAP3 pin muxing.

Verdex GPIO

GPIO( n )

  • Logic level (3.3V) signals
  • 3-4mA max

all GPIO's information and examples should go here


According to the PXA270 datasheet:,%20Mechanical,%20and%20Thermal%20Specification%20%5b280002-005%5d.pdf most of the pins are limited to 3mA, and a few can go upto 4 mA (see page 5-9)

Accessing GPIO's from userland

If proc-gpio is a module, add it to /etc/modules or do a modprobe proc-gpio.

A number of files exist under /proc/gpio, one for each GPIO on the PXA processor.

If you cat one of these files, you get, eg:

# cat /proc/gpio/GPIO12
12 GPIO in set

That tells you — GPIO number, function (either GPIO, AF 1, AF 2, or AF 3), in|out, set|clear.

You can change any of those values, by writing to the file, eg:

# echo "AF1 out" > /proc/gpio/GPIO12

This sets GPIO12 to AF1, out mode. (In the case of GPIO12, the PXA defines this function as putting out the 32kHz clock signal.) this is currently case-sensitive

If you have the GPIO set to an output, and GPIO mode, you can set or clear the signal:

# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12

The alternative functions are described in the PXA255 Developer's Manual (link should be found in the Featured links-box) section 4.1.2.

Alternative method to access GPIO's from userland

The User GPIO Driver provides a reflection of the kernel's gpiolib library into userspace.

gpio-event driver

The GPIO Event Driver allows gpio changes to be captured from user-space.

Related pages on the old wiki: