>
> echo 5 > /sys/class/gpio/export
> echo 65 > /sys/class/gpio/export
> echo 105 > /sys/class/gpio/export
>
> I do the same with Android in the init.{ro.hardware}.rc file:
>
> write /sys/class/gpio/export 5
> write /sys/class/gpio/export 65
> write /sys/class/gpio/export 105
>
> As for running those commands under Linux, I usually place the commands to
export the pins into a shell script that also launches the application that
uses the GPIOs. Since you have to be root to mmap() the pages with GPIO
control registers, you can run the shell script via sudo and have the
script export the pins and then launch your binary. You could also place
the commands in the /etc/rc.local startup script or the like, if you want.
Read carefully.
On Wed, Oct 29, 2014 at 8:00 PM, John Syn <[email protected]> wrote:
>
> From: William Hermans <[email protected]>
> Reply-To: "[email protected]" <[email protected]>
> Date: Wednesday, October 29, 2014 at 4:07 PM
> To: "[email protected]" <[email protected]>
> Subject: Re: [beagleboard] Re: Memory Mapped Access to /dev/mem GPIO2
> fails, GPIO1 OK
>
> Except that running those commands as root at startup( init scripts ) has
> no detrimental effect.
>
> He is running the script as root and in that script, he is launching his
> application, so his application is running as root.
>
>
>
> On Wed, Oct 29, 2014 at 1:37 PM, John Syn <[email protected]> wrote:
>
>>
>> From: Andrew Henderson <[email protected]>
>> Reply-To: "[email protected]" <[email protected]>
>> Date: Wednesday, October 29, 2014 at 11:40 AM
>> To: "[email protected]" <[email protected]>
>> Subject: [beagleboard] Re: Memory Mapped Access to /dev/mem GPIO2 fails,
>> GPIO1 OK
>>
>> I have found that accessing GPIOs via mmap() of /dev/mem works without
>> accessing additional control register settings if you export one GPIO pin
>> in each bank so that the GPIO kernel driver "unlocks" each bank and wakes
>> it up. GPIO1 is awake by default, but you can get the other GPIO0, GPIO2,
>> and GPIO3 working via the following commands:
>>
>> echo 5 > /sys/class/gpio/export
>> echo 65 > /sys/class/gpio/export
>> echo 105 > /sys/class/gpio/export
>>
>> I do the same with Android in the init.{ro.hardware}.rc file:
>>
>> write /sys/class/gpio/export 5
>> write /sys/class/gpio/export 65
>> write /sys/class/gpio/export 105
>>
>> As for running those commands under Linux, I usually place the commands
>> to export the pins into a shell script that also launches the application
>> that uses the GPIOs. Since you have to be root to mmap() the pages with
>> GPIO control registers, you can run the shell script via sudo and have the
>> script export the pins and then launch your binary. You could also place
>> the commands in the /etc/rc.local startup script or the like, if you want.
>>
>> Running applications as root is a very bad idea. if you change the group
>> for /dev/mem and add your userid to that group, you don’t have to run your
>> app as root.
>>
>> Regards,
>> John
>>
>>
>> Andrew
>>
>> On Wednesday, October 29, 2014 1:49:16 PM UTC-4, Nic Cyn wrote:
>>>
>>> Success!!! Thank you very much! - this works. I really appreciate your
>>> advice. I absolutely would not have got this sorted without it.
>>>
>>> I am going to write up a summary and post it on this thread so that
>>> anybody else that runs into this issue can find it. However I do have a
>>> couple more questions - if you (or anybody) have the time to provide any
>>> insights you might have.
>>>
>>>
>>> - The CM_PER_GPIO1_CLKCTRL at 0x44e00000[0xac] for Bank GPIO1 is
>>> already set, yet the equivalents for GPIO2 and GPIO3 are not. Any idea
>>> how
>>> CM_PER_GPIO1_CLKCTRL got set?
>>> - Are there any Device Tree settings that you know of that can set
>>> the CLKCTRLs for GPIO2 and GPIO3 at boot up?
>>> - There is no CM_PER_GPIO0_CLKCTRL for the GPIO0 bank. I gather
>>> GPIO0 is something of a special case due to the wakeup capabilities it
>>> contains. Is the GPIO0 bank always enabled? Any thoughts on why GPIO0 is
>>> not there?
>>> - Your example OR'ed with 0x40002 - presumably to place it in
>>> standby - rather than fully active. I am curious - under what
>>> circumstances
>>> would you want to put a CLKCTRL in standby mode?
>>> - Do you have any idea why /dev/mem would fail to access GPIO3 if
>>> the CLKCTRL was not set and yet SYSFS can read the GPIO states on GPIO3?
>>> Obviously SYSFS is a device driver and does not need to hit /dev/mem but
>>> even so it appears the CLKCTRL is used to transfer the state off the
>>> physical pin and into the GPIO bank so why would SYSFS work if the clock
>>> is
>>> disabled.
>>> - You must have run into this issue yourself. How on earth did you
>>> figure out that it was the CLKCTRL registers? The reason I ask I I would
>>> like to know how to diagnose this sort of thing myself and it all seems
>>> such a mystery at the moment.
>>>
>>>
>>> Once again.... many thanks.
>>>
>>>
>>>
>>> On Tuesday, 28 October 2014 21:28:19 UTC, [email protected] wrote:
>>>>
>>>> This is out of a program I use -
>>>> Enter code here...
>>>> uint32_t *clock_gpio3;
>>>> clock_gpio3 = (uint32_t *) mmap(NULL, 0x1000, PROT_READ | PROT_WRITE,
>>>> MAP_SHARED, fd, 0x44E00000);
>>>> clock_gpio3[0x2d] |= 0x40002; // 2d is b4 divide by 4 because it is a
>>>> byte offset
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
