to use expansion port for GPIO

I am using Beagleboard-xM revC.

I'm want to use the GPIO expansion port.

According to the manual Beagleboard, Beagleboard use MUX at the
expansion prot.
By default, Is the port register setted mode0
To use expansion port for GPIO, I need to set the Mode 4 register?
Also, Can I know the current mode ?

Hello Taku,
to control the expansion header using shell script and use the pins as
GPIO can be seen in the following websites:
http://bbfordummies.blogspot.com/2009/07/1.html
http://blog.makezine.com/archive/2009/02/blinking-leds-with-the-beagle-board.html

If you want to write a C code to do that. You can follow this one:
http://linuxjunk.blogspot.com/2009/01/beagleboard-gpio-input-driverless.html

Good luck!
Frederico

Hello, freddyglima
Thankyou for reply.

I have already tried what you told me how to.
I tried a test in Angstrom that come to with Beagleboard.
Between pin 28 and pin 24, insert the multimeter measured the voltage.
Voltage was 1.5 volts.

by mainicom login at root
cd / sys / class / gpio
echo 168 > export
cd gpio168
echo “low” > direction
However, the voltage remains high.
cat value
0
echo “higt”> direction
Voltage is still high.
cat value
1

The value that has changed, the voltage don’t changed.

cd / sys / class / gpio
echo 168 > export
cd gpio168
echo "low" > direction

By default the pins are configured as input. You have to explicitly set them as an output and that's what direction is for. I don't think that your line above did what you wanted to do.

I guess you wanted to set it to an output:
echo "out" > direction

and then set the value of the output to "low":
echo 0 > value

right?

Hello Niederer
Thank you fo reply.

I have already tried that way also, the results were the same.
Value was changed but the voltage did not change.

Because of the difference between what the environment?
What is your environment like?

Again, as asked in the beginning, I think needs to be set in the Mux register?

Between pin 28 and pin 24, insert the multimeter measured the voltage.
Voltage was 1.5 volts.

Actually, the voltage measured here should be 1.8V

The following command lines should change the voltage between pins 28
and 24 to 0V:
cd /sys/class/gpio
echo 168 > export
cd /sys/class/gpio/gpio168
echo "low" > direction

I guess you wanted to set it to an output:
echo "out" > direction

and then set the value of the output to "low":
echo 0 > value

I have never tested these command lines above but they seem to be
false.
"high" would turn to the GPIO to high level (1.8V) and "low" to low
level (0V).

Again, as asked in the beginning, I think needs to be set in the Mux
register?

If you problem it in C, for example, it is necessary to set the MUX
register.
However, this is not necessary, doing the way mentioned above.

Quoting freddyglima <freddyglima@googlemail.com>:

I have never tested these command lines above but they seem to be
false.

You should have tested it before posting. :wink:
For me my suggested lines worked earlier. But you may be happy to
read, we are both right (from gpiolib.c, Kernel 2.6.39):
199 * /direction
200 * * MAY BE OMITTED if kernel won't allow direction changes
201 * * is read/write as "in" or "out"
202 * * may also be written as "high" or "low", initializing
203 * output value as specified ("out" implies "low")

But anyway:
Changing the direction is no solution for manipulating the voltage
level of the GPIO, although it may change the voltage level by chance
(e.g. due to Pull-Up resistors).

After setting the pin's direction, you should use following interface
for manipulating the voltage level (from the source noted above):

204 * /value
205 * * always readable, subject to hardware behavior
206 * * may be writable, as zero/nonzero

So my suggested lines have to be correct. Just test it yourself by lighting up one of the green user LEDs.

ueli

Hi again

Quoting taku <aspect.rt@gmail.com>:

I have already tried that way also, the results were the same.
Value was changed but the voltage did not change.

Ok, taking this into account I'd guess it's a pinmux issue too.

Because of the difference between what the environment?
What is your environment like?

My environment is a rowboat kernel (linux including android patches) and an u-boot image from the validation card. If I got that right, you're playing with the angstrom validation image right?
Are you able to light up the LED D7 (GPIO 149, near the SD-Slot on xM from userspace using the linse suggested earlier?

Again, as asked in the beginning, I think needs to be set in the Mux
register?

I guess you're right. There are a several ways to do pinmux. You can either change pinmux in the u-boot loader or in the kernel or bot. I did not find any answer to my question which method is the "preferrable". For me it seems that following guideline would be correct:
- If have pinmux settings the kernel needs to run, do them in the bootloader (logical, isn't it? :wink: )
- All the Pinmux stuff you need rather for the applications and drivers than for the kernel, should be done in board-init in the kernel as it's done for the expansion boards for example.

What I did not find yet is any kind of subsystem that lets me change the pinmux e.g. through the init of a kernel module or something. I think such a subsystem does not exist (yet). So I think you'll have to modify either u-boot or the kernels board init.

If you want to do the latter, following thread could give you some pointers:
http://groups.google.com/group/beagleboard/browse_thread/thread/60272ffc937c4829/96ea7398aaa0ee6a?#96ea7398aaa0ee6a

regards
Ueli

You should have tested it before posting. :wink:

You haven't understood it right. I have tested my solution, not yours.

Hi Freddy

Quoting freddyglima <freddyglima@googlemail.com>:

You should have tested it before posting. :wink:

You haven't understood it right. I have tested my solution, not yours.

Due to the fact that you repeat your latest answer, I think you wait for an answer of me. As english is obviously not my mother tongue, there is a good chance, that i misunderstood you. So let me explain:

You quoted my lines just above the statement, that "above lines seem to be false". So I thought you are calling my suggested shellcommands "false" what appearently isn't correct. That's why I said you should have tested my lines before calling them false.

Anyway, clearing up this misunderstanding will not help taku in solving his problem. :slight_smile: So if you want to discuss this point further, I suggest we do this bilaterally.

regards
Ueli

I’m poor at English. so I’m Japanese.
Sorry for the slow reply.

Fast, I’v tried to light up the LED D7.
Result
root@omap:/sys/class/gpio# echo 149 > export
bash: echo: write error: Device or resource busy

Second
There was miss discription.
Vaoltage between pin24 to pin28 is 1.25V.

I’v got LED. and I set it between pin24 to pin28 on expansion port(P9). Boot on
But the LED never light up.
This mean that value of multimeter is not high.

Third
According Build an Ubuntu root file system with RootStock in eLinux
http://elinux.org/BeagleBoardUbuntu#Build_an_Ubuntu_root_file_system_with_RootStock
I made Basic Natty (11.04) Beagleboard minimal image.
And boot it. But the LED not light up.

Next
git clone git://gitorious.org/u-boot-omap3/mainline.git u-boot-omap3
cd u-boot-omap3
git checkout --track -b omap3-dev origin/omap3-dev
make CROSS_COMPILE=arm-linux- mrproper
make CROSS_COMPILE=arm-linux- omap3_beagle_config
make CROSS_COMPILE=arm-linux-
cp u-boot.bin /media/boot/

And boot on
the LED light up while uInitrd. the LED light off when uImage start.

What advice do you have?

Hi everyone.

Correction
The LED light up while Loading uImage and uInitrd.
And the LED light off when process move init of kernel.

Voltage is 1.8V while lingt on.

And I wrote that the LED light on at u-boot-omap3.
But I’v rewrotn /u-boot-omap3/board/ti/beagle/beagle.h.

265 MUX_VAL(CP(I2C2_SCL), (IEN | PTU | EN | M0)) /I2C2_SCL/
to
265 MUX_VAL(CP(I2C2_SCL), (IEN | PTU | EN | M4)) /I2C2_SCL/\

The LED don’t light on when rewrite M0.

I guess that u-boot set pinmux register for GPIO.
After kernel reset pinmux?

Hi Everyone
Thank you for your advice

I can’t control expasionport yet.
I will study pinmux by kernel.
So I will close this thread.

Thank you and see you agein.

Quoting taku <aspect.rt@gmail.com>:

And I wrote that the LED light on at u-boot-omap3.
But I'v rewrotn /u-boot-omap3/board/ti/beagle/beagle.h.
265 MUX_VAL(CP(I2C2_SCL), (IEN | PTU | EN | M0)) /*I2C2_SCL*/\
to
265 MUX_VAL(CP(I2C2_SCL), (IEN | PTU | EN | M4)) /*I2C2_SCL*/\
[...]
I guess that u-boot set pinmux register for GPIO.
After kernel reset pinmux?

Actually there is a chance, the board init reinitializes these pinmux settings for the i2c driver. Have you tried other GPIOs than the I2C2 ones on the Expansion Connector?

Hi Niederer
Thank you for your advice.

I have tried at pin 3.
According to the article, Pin3 is MMC2_DAT7 and GPIO139.
Pin 3 defined as follows for beagle.h of u-boot.
MUX_VAL (CP (MMC2_DAT7), (IEN | PTU | EN | M1)) / * MMC2_CLKIN * / \

When I start Beagleboard, the voltage between pin 3 and pin 28 was 7.6V.

cd/sys/class/gpio
echo 139> export
cd gpio139
echo out> direction
At this time, has changed the voltage to 0V.
echo 1> value
Has changed the voltage to 1.8V.
echo 0> value
Has changed the voltage to 0V.

Next, I edited the beagle.h.
MUX_VAL (CP (MMC2_DAT7), (IEN | PTU | EN | M4)) / * MMC2_CLKIN * / \

However, result were the same.

From these results, the next thing I know.
GPIO control with sysfs is regardless of setting pinmux

And as you say, seems to initialize the port i2c.
dmesg | grep i2c
[ 0.099884] omap_hwmod: i2c1: softreset failed (waited 10000 usec)
[ 0.112487] omap_hwmod: i2c2: softreset failed (waited 10000 usec)
[ 0.125091] omap_hwmod: i2c3: softreset failed (waited 10000 usec)
[ 0.234558] omap_i2c omap_i2c.1: bus 1 rev4.0 at 2600 kHz
[ 0.254638] omap_i2c omap_i2c.2: bus 2 rev4.0 at 400 kHz
[ 0.254943] omap_i2c omap_i2c.3: bus 3 rev4.0 at 100 kHz
[ 4.173797] input: twl4030_pwrbutton as /devices/platform/omap/omap_i2c.1/i2c-1/1-0049/twl4030_pwrbutton/input/input0
[ 4.185516] i2c /dev entries driver

One step forward.
I’ll examine for the kernel initialization.

Do you have something connected to pin 3? Do you me 7.6mV? If it is indeed 7.6V and you are successful in getting the pin to “go to 1.8V” I don’t think you will have much luck using the board after that event due to the blown processor. The highest voltage allowed on these pins is 1.8V.

Gerald

Sorry
It is 0.76V

Thank you

OK. That is better. So that is basically a float condition meaning the pin is in the SAFE mode or high impedance.

Gerald