Except that running those commands as root at startup( init scripts ) has no detrimental effect.
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.
