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 ?
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
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).
I have never tested these command lines above but they seem to be
false.
You should have tested it before posting.
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.
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? )
- 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.
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. So if you want to discuss this point further, I suggest we do this bilaterally.
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.
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.
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?
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.