Re: [Gumstix-users] Question about GPIO pin muxing

The constants you pass to CP() are defined in include/asm/arch/mux.h
They refer to the MODE 0 pad function.
For your example (from mux.h)
...
#define CONTROL_PADCONF_GPMC_A3 0x007E
#define CONTROL_PADCONF_GPMC_A4 0x0080
#define CONTROL_PADCONF_GPMC_A5 0x0082
#define CONTROL_PADCONF_GPMC_A6 0x0084
...
You want GPMC_A5 as the arg to CP() to configure that pad for GPIO_38.
The 32-bit mux registers can be accessed at 16 bit offsets so it all
works.
On Mon, 2011-11-21 at 08:26 -0500, coderdrone@... wrote:
> Hello,
>
> It's been a while since I've attempted to change the pin mux
> configuration of GPIOs on the Gumstix Overo board. I am currently
> attempting to patch overo.h with a few GPIO configurations. This file
> has lines similar to "MUX_VAL(CP(<name>), (IEN | PTU | EN | M4)"
> where <name> is one of the register names from the OMAP35x TRM Table
> 7-4 without the "CONTROL_PADCONF_" part.
>
> I notice each of these PADCONF register entries in the table has
> duplicates for each register, since each register is used for two
> separate pads, or GPIOs. I wanted to enable GPIO 38, which would be
> GPMC_A4. However GPMC_A4 is also GPIO 37 according to the table. How
> do I specify which GPIO I'm trying to reference?
>
> Which GPIO will get enabled with MUX_VAL(CP(GPMC_A4), ( IEN | PTU
> | EN | M4)? If it's GPIO 37 how do I specify GPIO 38?
>
> Thank you for your time,
>
> Wayne
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________ gumstix-users mailing list gumstix-users@... https://lists.sourceforge.net/lists/listinfo/gumstix-users

Thread view

Hello,
It's been a while since I've attempted to change the pin mux configuration
of GPIOs on the Gumstix Overo board. I am currently attempting to patch
overo.h with a few GPIO configurations. This file has lines similar to
"MUX_VAL(CP(<name>), (IEN | PTU | EN | M4)" where <name> is one of the
register names from the OMAP35x TRM Table 7-4 without the
"CONTROL_PADCONF_" part.
I notice each of these PADCONF register entries in the table has duplicates
for each register, since each register is used for two separate pads, or
GPIOs. I wanted to enable GPIO 38, which would be GPMC_A4. However
GPMC_A4 is also GPIO 37 according to the table. How do I specify which
GPIO I'm trying to reference?
Which GPIO will get enabled with MUX_VAL(CP(GPMC_A4), ( IEN | PTU | EN
| M4)? If it's GPIO 37 how do I specify GPIO 38?
Thank you for your time,
Wayne

The constants you pass to CP() are defined in include/asm/arch/mux.h
They refer to the MODE 0 pad function.
For your example (from mux.h)
...
#define CONTROL_PADCONF_GPMC_A3 0x007E
#define CONTROL_PADCONF_GPMC_A4 0x0080
#define CONTROL_PADCONF_GPMC_A5 0x0082
#define CONTROL_PADCONF_GPMC_A6 0x0084
...
You want GPMC_A5 as the arg to CP() to configure that pad for GPIO_38.
The 32-bit mux registers can be accessed at 16 bit offsets so it all
works.
On Mon, 2011-11-21 at 08:26 -0500, coderdrone@... wrote:
> Hello,
>
> It's been a while since I've attempted to change the pin mux
> configuration of GPIOs on the Gumstix Overo board. I am currently
> attempting to patch overo.h with a few GPIO configurations. This file
> has lines similar to "MUX_VAL(CP(<name>), (IEN | PTU | EN | M4)"
> where <name> is one of the register names from the OMAP35x TRM Table
> 7-4 without the "CONTROL_PADCONF_" part.
>
> I notice each of these PADCONF register entries in the table has
> duplicates for each register, since each register is used for two
> separate pads, or GPIOs. I wanted to enable GPIO 38, which would be
> GPMC_A4. However GPMC_A4 is also GPIO 37 according to the table. How
> do I specify which GPIO I'm trying to reference?
>
> Which GPIO will get enabled with MUX_VAL(CP(GPMC_A4), ( IEN | PTU
> | EN | M4)? If it's GPIO 37 how do I specify GPIO 38?
>
> Thank you for your time,
>
> Wayne
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________ gumstix-users mailing list gumstix-users@... https://lists.sourceforge.net/lists/listinfo/gumstix-users

I finished up a patch in u-boot to enable some GPIOs, which seems to be
working fine for GPIOs used as inputs. However, outputs don't seem to be
working. I thought GPIOs get set to "out" if the InputEnable bit is set to
zero in overo.h. One for Input, zero for output.
Also, I'm having difficulty getting GPIOs 14 and 21 configured as output.
The kernel won't even let me export them. I'm also trying to use devmem2
as an alternative way but not much luck there. Does the kernel use 14 and
21 for other purposes?
On Mon, Nov 21, 2011 at 11:17 AM, <coderdrone@...> wrote:
> That makes more sense now. In the TRM, I was looking at the "Register
> Name" column instead of the "mode 0" column to get the pad names. So I was
> confused as to why GPMC_A3, A5, etc were not there.
>
> I'll pass the value that's listed in the "mode 0" column to CP() from now
> on.
>
> Thanks for clearing that up.
>
>
>
> On Mon, Nov 21, 2011 at 9:36 AM, Scott Ellis <scott@...> wrote:
>
>> The constants you pass to CP() are defined in include/asm/arch/mux.h
>> They refer to the MODE 0 pad function.
>>
>> For your example (from mux.h)
>> ...
>> #define CONTROL_PADCONF_GPMC_A3 0x007E
>> #define CONTROL_PADCONF_GPMC_A4 0x0080
>> #define CONTROL_PADCONF_GPMC_A5 0x0082
>> #define CONTROL_PADCONF_GPMC_A6 0x0084
>> ...
>>
>> You want GPMC_A5 as the arg to CP() to configure that pad for GPIO_38.
>>
>> The 32-bit mux registers can be accessed at 16 bit offsets so it all
>> works.
>>
>>
>>
>> On Mon, 2011-11-21 at 08:26 -0500, coderdrone@... wrote:
>> > Hello,
>> >
>> > It's been a while since I've attempted to change the pin mux
>> > configuration of GPIOs on the Gumstix Overo board. I am currently
>> > attempting to patch overo.h with a few GPIO configurations. This file
>> > has lines similar to "MUX_VAL(CP(<name>), (IEN | PTU | EN | M4)"
>> > where <name> is one of the register names from the OMAP35x TRM Table
>> > 7-4 without the "CONTROL_PADCONF_" part.
>> >
>> > I notice each of these PADCONF register entries in the table has
>> > duplicates for each register, since each register is used for two
>> > separate pads, or GPIOs. I wanted to enable GPIO 38, which would be
>> > GPMC_A4. However GPMC_A4 is also GPIO 37 according to the table. How
>> > do I specify which GPIO I'm trying to reference?
>> >
>> > Which GPIO will get enabled with MUX_VAL(CP(GPMC_A4), ( IEN | PTU
>> > | EN | M4)? If it's GPIO 37 how do I specify GPIO 38?
>> >
>> > Thank you for your time,
>> >
>> > Wayne
>> >
>> ------------------------------------------------------------------------------
>> > All the data continuously generated in your IT infrastructure
>> > contains a definitive record of customers, application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-novd2d
>> > _______________________________________________ gumstix-users mailing
>> list gumstix-users@...
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> gumstix-users mailing list
>> gumstix-users@...
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>
>

gpio 14 is button 1
and
gpio 21 is the red led
See your kernel arch/arm/mach-omap2/board-overo.c for details.
Turning these options off in your kernel config and rebuilding should
fix it.
CONFIG_LEDS_GPIO
CONFIG_KEYBOARD_GPIO
Either that or selectively commenting the lines in board-overo.c you
don't want, generating a patch and rebuilding the kernel will work.
I'm looking at a 2.6.36 kernel, but I think later gumstix kernels have
similar board-overo.c code.
On Tue, 2011-11-22 at 07:41 -0500, coderdrone@... wrote:
> I finished up a patch in u-boot to enable some GPIOs, which seems to
> be working fine for GPIOs used as inputs. However, outputs don't seem
> to be working. I thought GPIOs get set to "out" if the InputEnable
> bit is set to zero in overo.h. One for Input, zero for output.
>
> Also, I'm having difficulty getting GPIOs 14 and 21 configured as
> output. The kernel won't even let me export them. I'm also trying to
> use devmem2 as an alternative way but not much luck there. Does the
> kernel use 14 and 21 for other purposes?
>
> On Mon, Nov 21, 2011 at 11:17 AM, <coderdrone@...> wrote:
> That makes more sense now. In the TRM, I was looking at the
> "Register Name" column instead of the "mode 0" column to get
> the pad names. So I was confused as to why GPMC_A3, A5, etc
> were not there.
>
> I'll pass the value that's listed in the "mode 0" column to
> CP() from now on.
>
> Thanks for clearing that up.
>
>
>
> On Mon, Nov 21, 2011 at 9:36 AM, Scott Ellis
> <scott@...> wrote:
> The constants you pass to CP() are defined in
> include/asm/arch/mux.h
> They refer to the MODE 0 pad function.
>
> For your example (from mux.h)
> ...
> #define CONTROL_PADCONF_GPMC_A3 0x007E
> #define CONTROL_PADCONF_GPMC_A4 0x0080
> #define CONTROL_PADCONF_GPMC_A5 0x0082
> #define CONTROL_PADCONF_GPMC_A6 0x0084
> ...
>
> You want GPMC_A5 as the arg to CP() to configure that
> pad for GPIO_38.
>
> The 32-bit mux registers can be accessed at 16 bit
> offsets so it all
> works.
>
>
>
> On Mon, 2011-11-21 at 08:26 -0500,
> coderdrone@... wrote:
> > Hello,
> >
> > It's been a while since I've attempted to change the
> pin mux
> > configuration of GPIOs on the Gumstix Overo board.
> I am currently
> > attempting to patch overo.h with a few GPIO
> configurations. This file
> > has lines similar to "MUX_VAL(CP(<name>), (IEN |
> PTU | EN | M4)"
> > where <name> is one of the register names from the
> OMAP35x TRM Table
> > 7-4 without the "CONTROL_PADCONF_" part.
> >
> > I notice each of these PADCONF register entries in
> the table has
> > duplicates for each register, since each register is
> used for two
> > separate pads, or GPIOs. I wanted to enable GPIO
> 38, which would be
> > GPMC_A4. However GPMC_A4 is also GPIO 37 according
> to the table. How
> > do I specify which GPIO I'm trying to reference?
> >
> > Which GPIO will get enabled with
> MUX_VAL(CP(GPMC_A4), ( IEN | PTU
> > | EN | M4)? If it's GPIO 37 how do I specify GPIO
> 38?
> >
> > Thank you for your time,
> >
> > Wayne
>
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT
> infrastructure
> > contains a definitive record of customers,
> application performance,
> > security threats, fraudulent activity, and more.
> Splunk takes this
> > data and makes sense of it. IT sense. And common
> sense.
> > http://p.sf.net/sfu/splunk-novd2d
> > _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT
> infrastructure
> contains a definitive record of customers, application
> performance,
> security threats, fraudulent activity, and more.
> Splunk takes this
> data and makes sense of it. IT sense. And common
> sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________ gumstix-users mailing list gumstix-users@... https://lists.sourceforge.net/lists/listinfo/gumstix-users

> How do I modify the kernel config? Is there a .config file somewhere that I just turn those two options to "=N"?
There are two ways, assuming you already have it configured. Edit
.config in the source tree root directory or run "make help" and
select the config option of your choice. I'm fond of "make
menuconfig".
> Also, is this specific to one of the carrier boards (summit, tobi, etc) or it would also apply to a custom carrier board developed in house?
As these configuration options are strictly internal to the kernel and
thus the OMAP chip configuration, they only affect the Gumstix. I
would expect it to generalize nicely on a custom carrier board.
Cheers,
Jon

The method I use is here
http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=46&Itemid=54
If you are editing the config manually, set the options this way
CONFIG_LEDS_GPIO=y
and
CONFIG_KEYBOARD_GPIO=y
to
# CONFIG_LEDS_GPIO is not set
and
# CONFIG_KEYBOARD_GPIO is not set
The Gumstix kernels are generic. The buttons and leds configured in the
default kernels don't even exist on most of their boards. Same with all
the LCD display setup and the second NIC configuration. It's unlikely
you want any of that.
It's not hard to go through the board-overo.c file and understand what
it does.
Scott
On Tue, 2011-11-22 at 13:34 -0500, coderdrone@... wrote:
> How do I modify the kernel config? Is there a .config file somewhere
> that I just turn those two options to "=N"?
>
> Also, is this specific to one of the carrier boards (summit, tobi,
> etc) or it would also apply to a custom carrier board developed in
> house?

For some reason when I try 'bitbake -c menuconfig virtual/kernel' it always
fails. It gets to the 'do_menuconfig()' step and fails with '256'.
Simply modifying the .config file as suggested below (and copying it to the
recipe's folder as
$OVEROTOP/org.openembedded.dev/recipes/linux/linux-omap3-2.6.36/defconfig)
also causes it to fail when I 'bitbake virtual/kernel'. It fails at
do_compile() with an error 256.
I'll take a look at board-overo.c and see what that tells me.
On Tue, Nov 22, 2011 at 5:54 PM, Scott Ellis <scott@...> wrote:
> The method I use is here
>
>
> http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=46&Itemid=54
>
> If you are editing the config manually, set the options this way
>
> CONFIG_LEDS_GPIO=y
> and
> CONFIG_KEYBOARD_GPIO=y
>
> to
> # CONFIG_LEDS_GPIO is not set
> and
> # CONFIG_KEYBOARD_GPIO is not set
>
> The Gumstix kernels are generic. The buttons and leds configured in the
> default kernels don't even exist on most of their boards. Same with all
> the LCD display setup and the second NIC configuration. It's unlikely
> you want any of that.
>
> It's not hard to go through the board-overo.c file and understand what
> it does.
>
> Scott
>
> On Tue, 2011-11-22 at 13:34 -0500, coderdrone@... wrote:
> > How do I modify the kernel config? Is there a .config file somewhere
> > that I just turn those two options to "=N"?
> >
> > Also, is this specific to one of the carrier boards (summit, tobi,
> > etc) or it would also apply to a custom carrier board developed in
> > house?
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

I never did solve the issue with using menuconfig, but I got GPIOs 14 and
21 working.
I set both CONFIG_KEYBOARD_GPIO and CONFIG_LEDS_GPIO to "is not set" and
commented them out in .config as suggested above. I also had to comment
out a line of code in board-overo.c that was trying to use a "gpio_leds"
array since that array was defined inside a block of code that gets
disabled by unsetting those two CONFIG_ parameters.
I also made the mistake of adding the patch to linux-omap3_git.bb instead
of linux-omap3-2.6.36.bb. Once I added the patch to the version-specific
recipe, everything worked.
Thanks to all for the help :)
On Mon, Nov 28, 2011 at 11:53 AM, <coderdrone@...> wrote:
> For some reason when I try 'bitbake -c menuconfig virtual/kernel' it
> always fails. It gets to the 'do_menuconfig()' step and fails with '256'.
>
> Simply modifying the .config file as suggested below (and copying it to
> the recipe's folder as
> $OVEROTOP/org.openembedded.dev/recipes/linux/linux-omap3-2.6.36/defconfig)
> also causes it to fail when I 'bitbake virtual/kernel'. It fails at
> do_compile() with an error 256.
>
> I'll take a look at board-overo.c and see what that tells me.
>
>
> On Tue, Nov 22, 2011 at 5:54 PM, Scott Ellis <scott@...> wrote:
>
>> The method I use is here
>>
>>
>> http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=46&Itemid=54
>>
>> If you are editing the config manually, set the options this way
>>
>> CONFIG_LEDS_GPIO=y
>> and
>> CONFIG_KEYBOARD_GPIO=y
>>
>> to
>> # CONFIG_LEDS_GPIO is not set
>> and
>> # CONFIG_KEYBOARD_GPIO is not set
>>
>> The Gumstix kernels are generic. The buttons and leds configured in the
>> default kernels don't even exist on most of their boards. Same with all
>> the LCD display setup and the second NIC configuration. It's unlikely
>> you want any of that.
>>
>> It's not hard to go through the board-overo.c file and understand what
>> it does.
>>
>> Scott
>>
>> On Tue, 2011-11-22 at 13:34 -0500, coderdrone@... wrote:
>> > How do I modify the kernel config? Is there a .config file somewhere
>> > that I just turn those two options to "=N"?
>> >
>> > Also, is this specific to one of the carrier boards (summit, tobi,
>> > etc) or it would also apply to a custom carrier board developed in
>> > house?
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> gumstix-users mailing list
>> gumstix-users@...
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>
>