From: William Hermans <[email protected]>
Reply-To: "[email protected]" <[email protected]>
Date: Wednesday, October 29, 2014 at 8:37 PM
To: "[email protected]" <[email protected]>
Subject: Re: [beagleboard] Re: Memory Mapped Access to /dev/mem GPIO2
fails, GPIO1 OK
>> 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.
you can run the shell script via sudo and have the script export the pins
and then launch your binary
Either way, it is ambiguous. I read it as ³you can run the shell script via
sudo and have that same script export the pins and then have the same shell
script launch your binary². Anyway, my comment was to not run his app as
root and that is still valid.
>
>
> 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.
--
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.
