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.
