Modify

Opened 7 years ago

Closed 7 years ago

Last modified 4 years ago

#9198 closed defect (fixed)

gpioctl does not work in the trunk, but works fine in RC5 on the Atheros build.

Reported by: nj@… Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: base system Version: Trunk
Keywords: Cc:

Description


Attachments (1)

834-gpio_ioctl.patch (702 bytes) - added by lindner_marek@… 7 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 7 years ago by imcbride

I suspect that Ticket #9282 is the same issue.

I ran into this trying to use a build of trunk on an OM1P/MR3201A. Confirmed that it's fine with RC5.

Observed behaviour is that gpioctl 'clear' does not return an error, but 'get' always reports pins as HIGH.

Not being able to manipulate GPIO makes the OM1P with standard Redboot unusable; it reboots every 5 minutes due to hardware watchdog.

I haven't tested extensively, but will try to isolate a changeset beyond RC5 that does work. I do note that RC5 and trunk use different kernel versions.

comment:2 Changed 7 years ago by anonymous

Has there been any movement on this? We've got an OM1P that we would like to get working with an svn build.

comment:3 Changed 7 years ago by nbd

Did you use gpioctl dirout before gpioctl clear?

comment:4 follow-up: Changed 7 years ago by anonymous

Yeah, this is the script which I used to use:

#!/bin/bash
#Heartbeat Script

gpioctl dirout 3 ;
gpioctl clear 3 
gpioctl set 3

Running as a cronjob kept the router alive.

comment:5 in reply to: ↑ 4 Changed 7 years ago by anonymous

Replying to anonymous:

Yeah, this is the script which I used to use:

#!/bin/bash
#Heartbeat Script

gpioctl dirout 3 ;
gpioctl clear 3 
gpioctl set 3

Running as a cronjob kept the router alive.

Maybe I should add that it is an ar2315 chip.

comment:6 Changed 7 years ago by jonbither@…

I can reproduce this issue on an EnGenius ECB3500. One thing that I noticed is that on backfire the GPIO irq is 53 while on trunk the irq is 54. The only thing that came to mind was patch #26554. Hope any of this helps.

comment:7 Changed 7 years ago by anonymous

We also have this problem. Gpioctl seems not to actually control the pins. Does anyone have any real idea what is going wrong? Maybe we can come up with a patch if the devs are busy.

comment:8 Changed 7 years ago by anonymous

I read that we are supposed to use

echo 3 > /sys/class/gpio/export

etc, but we dont seem to have that directory. Instead there is a /sys/class/gpiodev/

Any ideas?

comment:9 Changed 7 years ago by anonymous

Has there been any movement on this? Any fix would be great.

comment:10 Changed 7 years ago by anonymous

I discovered as of 2.6.36 all gpio calls need to be "unlocked_ioctl" vs "ioctl". The kernel char driver has the appropriate changes but the program "gpioctl" does not. I suspect that the program will fail on all platforms with a kernel > 2.6.36 . I am working on a patch to use the new locking / unlocking method but if someone can finish it before me be my guest, at least I think I found our answer.

comment:11 Changed 7 years ago by anonymous

Great! It would be great if you could post the patch here.

comment:12 Changed 7 years ago by anonymous

Are you sure this is what is causing the problem?
I tried reverting the changes but with no luck...

comment:13 Changed 7 years ago by anonymous

If anyone has an update on this, would be great!

comment:14 Changed 7 years ago by davide.garofalo@…

News???

comment:15 Changed 7 years ago by anonymous

This ticket has been quiet for a while now. Has any progress been made?

comment:16 Changed 7 years ago by lindner_marek@…

Hey,

it is your lucky day - I found & fixed the bug. Copy the patch I am going to attach into your target/linux/generic/patches-$(kernel-version)/ directory. It replaces an existing patch. To get this patch applied you have to run "make target/linux/clean" before running "make" again.

Marek

Changed 7 years ago by lindner_marek@…

comment:17 Changed 7 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

fix applied (with modifications) in r27322

comment:18 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.