From: <cod...@gm...> - 2011-11-21 13:26:47
|
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 |
From: Scott E. <sc...@ju...> - 2011-11-21 14:36:38
|
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, cod...@gm... 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 gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: <cod...@gm...> - 2011-11-21 16:17:17
|
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 <sc...@ju...> 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, cod...@gm... 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 gum...@li... > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: <cod...@gm...> - 2011-11-22 12:41:58
|
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, <cod...@gm...> 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 <sc...@ju...> 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, cod...@gm... 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 gum...@li... >> 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 >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > |
From: Scott E. <sc...@ju...> - 2011-11-22 13:30:35
|
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, cod...@gm... 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, <cod...@gm...> 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 > <sc...@ju...> 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, > cod...@gm... 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 > gum...@li... > 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 > gum...@li... > 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 gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: <cod...@gm...> - 2011-11-22 18:34:56
|
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? On Tue, Nov 22, 2011 at 8:30 AM, Scott Ellis <sc...@ju...> wrote: > 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, cod...@gm... 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, <cod...@gm...> 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 > > <sc...@ju...> 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, > > cod...@gm... 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 > > gum...@li... > > > 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 > > gum...@li... > > > 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 gum...@li... > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Jonathan K. <jon...@gm...> - 2011-11-22 18:54:03
|
> 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 |
From: Scott E. <sc...@ju...> - 2011-11-22 22:54:10
|
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, cod...@gm... 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? |
From: <cod...@gm...> - 2011-11-28 16:53:47
|
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 <sc...@ju...> 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, cod...@gm... 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: <cod...@gm...> - 2011-12-01 19:24:00
|
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, <cod...@gm...> 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 <sc...@ju...> 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, cod...@gm... 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 >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > |