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.
