From: <cod...@gm...> - 2009-12-21 20:46:53
|
Hello, I'm working on a C++ project to read button presses via GPIO pins from the Gumstix board and am running into some issues. As I understand it, there are two different ways to read GPIO lines: 1.) reading through an API, or 2.) standard filesystem commands like cat and echo. We are currently using filesystem commands. So far, I've just been trying to read the pins on the commandline via, for example, 'cat /sys/class/gpio/gpioN' where N is the GPIO number. As I understand it, this gpio directory lists all the GPIO pins that have been 'exported' by the kernel to userspace. However, if I export other GPIOs, I can't seem to successfully read them. Is there a way to change the configuration of the kernel to make more GPIO pins available? Could the kernel be reserving certain pins for other uses so I can't actually read button presses with them? Am I just making this more complicated than it needs to be? The Gumstix board is mounted on a summit board, which has a 40-pin connector as referenced at http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Summit-board-40-pin-header-SV1/112.html.<http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Summit-board-40-pin-header-SV1/112.html> However, the GPIO pins listed on that chart don't match the GPIO pins that exist in /sys/class/gpio when I boot the system. For example, GPIO114 exists in the filesystem, but GPIO171 does not. If I attach a button to the pins for GPIO114, the button appears to work (gpio114/value changes between 0 and 1). I can 'echo 171 > export' to gain access to GPIO 171, but when I read the value of that pin via 'cat gpio171/value' it always stays at 0 whether the attached button is pressed or not. Any thoughts? |
From: Steve S. <sa...@gm...> - 2009-12-21 21:22:43
|
On Mon, Dec 21, 2009 at 12:46 PM, <cod...@gm...> wrote: > Hello, > > I'm working on a C++ project to read button presses via GPIO pins from the > Gumstix board and am running into some issues. As I understand it, there > are two different ways to read GPIO lines: 1.) reading through an API, or > 2.) standard filesystem commands like cat and echo. We are currently using > filesystem commands. > > So far, I've just been trying to read the pins on the commandline via, for > example, 'cat /sys/class/gpio/gpioN' where N is the GPIO number. As I > understand it, this gpio directory lists all the GPIO pins that have been > 'exported' by the kernel to userspace. However, if I export other GPIOs, I > can't seem to successfully read them. Is there a way to change the > configuration of the kernel to make more GPIO pins available? Could the > kernel be reserving certain pins for other uses so I can't actually read > button presses with them? Am I just making this more complicated than it > needs to be? > > The Gumstix board is mounted on a summit board, which has a 40-pin connector > as referenced at > http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Summit-board-40-pin-header-SV1/112.html. > > However, the GPIO pins listed on that chart don't match the GPIO pins that > exist in /sys/class/gpio when I boot the system. For example, GPIO114 > exists in the filesystem, but GPIO171 does not. If I attach a button to the > pins for GPIO114, the button appears to work (gpio114/value changes between > 0 and 1). I can 'echo 171 > export' to gain access to GPIO 171, but when I > read the value of that pin via 'cat gpio171/value' it always stays at 0 > whether the attached button is pressed or not. > > Any thoughts? You will note that pin is labeled: GPIO171_SPI1_CLK This means it is a pin that can have 2 functions, either gpio_171 or spi1_clk Since the Gumstix Palo and Chestnut boards use the spi bus for the touchscreen controller, this pin is configured by u-boot for the spi function and not the gpio function. This is why you are not able to use in successfully in that mode. If you want to use it in gpio mode you will need to modify the u-boot pinmux setup. Of course spi will no longer work then, so you should make sure that whatever expansion board you are using doesn't require spi. Steve > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: <cod...@gm...> - 2009-12-22 00:39:24
|
Steve, Thank you for that information. I'm not very familiar with u-boot, but I've seen environment variables in there before. Can I assume that any of the multi-function pins (like 171 for example) on the 40-pin connector can be configured for one function or the other in u-boot? 171 shouldn't be a problem since we won't be using a touchscreen controller in this system. I've never heard of Palo and Chestnut. This board is Overo, or at least I believe Overo is the board name. I'm still trying to get used to the naming conventions. On Mon, Dec 21, 2009 at 4:22 PM, Steve Sakoman <sa...@gm...> wrote: > On Mon, Dec 21, 2009 at 12:46 PM, <cod...@gm...> wrote: > > Hello, > > > > I'm working on a C++ project to read button presses via GPIO pins from > the > > Gumstix board and am running into some issues. As I understand it, there > > are two different ways to read GPIO lines: 1.) reading through an API, or > > 2.) standard filesystem commands like cat and echo. We are currently > using > > filesystem commands. > > > > So far, I've just been trying to read the pins on the commandline via, > for > > example, 'cat /sys/class/gpio/gpioN' where N is the GPIO number. As I > > understand it, this gpio directory lists all the GPIO pins that have been > > 'exported' by the kernel to userspace. However, if I export other GPIOs, > I > > can't seem to successfully read them. Is there a way to change the > > configuration of the kernel to make more GPIO pins available? Could the > > kernel be reserving certain pins for other uses so I can't actually read > > button presses with them? Am I just making this more complicated than it > > needs to be? > > > > The Gumstix board is mounted on a summit board, which has a 40-pin > connector > > as referenced at > > > http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Summit-board-40-pin-header-SV1/112.html > . > > > > However, the GPIO pins listed on that chart don't match the GPIO pins > that > > exist in /sys/class/gpio when I boot the system. For example, GPIO114 > > exists in the filesystem, but GPIO171 does not. If I attach a button to > the > > pins for GPIO114, the button appears to work (gpio114/value changes > between > > 0 and 1). I can 'echo 171 > export' to gain access to GPIO 171, but when > I > > read the value of that pin via 'cat gpio171/value' it always stays at 0 > > whether the attached button is pressed or not. > > > > Any thoughts? > > You will note that pin is labeled: GPIO171_SPI1_CLK > > This means it is a pin that can have 2 functions, either gpio_171 or > spi1_clk > > Since the Gumstix Palo and Chestnut boards use the spi bus for the > touchscreen controller, this pin is configured by u-boot for the spi > function and not the gpio function. This is why you are not able to > use in successfully in that mode. > > If you want to use it in gpio mode you will need to modify the u-boot > pinmux setup. Of course spi will no longer work then, so you should > make sure that whatever expansion board you are using doesn't require > spi. > > Steve > > > > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and > easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Steve S. <sa...@gm...> - 2009-12-22 00:53:48
|
On Mon, Dec 21, 2009 at 4:30 PM, <cod...@gm...> wrote: > Steve, > > Thank you for that information. I'm not very familiar with u-boot, but I've > seen environment variables in there before. Can I assume that any of the > multi-function pins (like 171 for example) on the 40-pin connector can be > configured for one function or the other in u-boot? Yes. To be clear, though, this will require modifying the overo.h file in the sources and rebuilding u-boot. > 171 shouldn't be a > problem since we won't be using a touchscreen controller in this system. > I've never heard of Palo and Chestnut. This board is Overo, or at least I > believe Overo is the board name. I'm still trying to get used to the naming > conventions. See the Gumstix website -- both Palo and Chestnut links can be found here: http://gumstix.com/store/catalog/index.php?cPath=31 Steve > On Mon, Dec 21, 2009 at 4:22 PM, Steve Sakoman <sa...@gm...> wrote: >> >> On Mon, Dec 21, 2009 at 12:46 PM, <cod...@gm...> wrote: >> > Hello, >> > >> > I'm working on a C++ project to read button presses via GPIO pins from >> > the >> > Gumstix board and am running into some issues. As I understand it, >> > there >> > are two different ways to read GPIO lines: 1.) reading through an API, >> > or >> > 2.) standard filesystem commands like cat and echo. We are currently >> > using >> > filesystem commands. >> > >> > So far, I've just been trying to read the pins on the commandline via, >> > for >> > example, 'cat /sys/class/gpio/gpioN' where N is the GPIO number. As I >> > understand it, this gpio directory lists all the GPIO pins that have >> > been >> > 'exported' by the kernel to userspace. However, if I export other >> > GPIOs, I >> > can't seem to successfully read them. Is there a way to change the >> > configuration of the kernel to make more GPIO pins available? Could the >> > kernel be reserving certain pins for other uses so I can't actually read >> > button presses with them? Am I just making this more complicated than >> > it >> > needs to be? >> > >> > The Gumstix board is mounted on a summit board, which has a 40-pin >> > connector >> > as referenced at >> > >> > http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Summit-board-40-pin-header-SV1/112.html. >> > >> > However, the GPIO pins listed on that chart don't match the GPIO pins >> > that >> > exist in /sys/class/gpio when I boot the system. For example, GPIO114 >> > exists in the filesystem, but GPIO171 does not. If I attach a button to >> > the >> > pins for GPIO114, the button appears to work (gpio114/value changes >> > between >> > 0 and 1). I can 'echo 171 > export' to gain access to GPIO 171, but >> > when I >> > read the value of that pin via 'cat gpio171/value' it always stays at 0 >> > whether the attached button is pressed or not. >> > >> > Any thoughts? >> >> You will note that pin is labeled: GPIO171_SPI1_CLK >> >> This means it is a pin that can have 2 functions, either gpio_171 or >> spi1_clk >> >> Since the Gumstix Palo and Chestnut boards use the spi bus for the >> touchscreen controller, this pin is configured by u-boot for the spi >> function and not the gpio function. This is why you are not able to >> use in successfully in that mode. >> >> If you want to use it in gpio mode you will need to modify the u-boot >> pinmux setup. Of course spi will no longer work then, so you should >> make sure that whatever expansion board you are using doesn't require >> spi. >> >> Steve >> >> >> > >> > ------------------------------------------------------------------------------ >> > This SF.Net email is sponsored by the Verizon Developer Community >> > Take advantage of Verizon's best-in-class app development support >> > A streamlined, 14 day to market process makes app distribution fast and >> > easy >> > Join now and get one step closer to millions of Verizon customers >> > http://p.sf.net/sfu/verizon-dev2dev >> > _______________________________________________ >> > gumstix-users mailing list >> > gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > >> > >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: <cod...@gm...> - 2009-12-22 15:20:32
|
Where do I get the sources for this? When I search my entire overo-oe directory for overo.h, I find about 7 copies under overo-oe/tmp/(work or staging) but not the original file. I do have an overo-oe/sources directory with a bunch of items, but nothing with uboot. On Mon, Dec 21, 2009 at 7:53 PM, Steve Sakoman <sa...@gm...> wrote: > On Mon, Dec 21, 2009 at 4:30 PM, <cod...@gm...> wrote: > > Steve, > > > > Thank you for that information. I'm not very familiar with u-boot, but > I've > > seen environment variables in there before. Can I assume that any of the > > multi-function pins (like 171 for example) on the 40-pin connector can be > > configured for one function or the other in u-boot? > > Yes. To be clear, though, this will require modifying the overo.h > file in the sources and rebuilding u-boot. > > > 171 shouldn't be a > > problem since we won't be using a touchscreen controller in this system. > > I've never heard of Palo and Chestnut. This board is Overo, or at least > I > > believe Overo is the board name. I'm still trying to get used to the > naming > > conventions. > > See the Gumstix website -- both Palo and Chestnut links can be found here: > > http://gumstix.com/store/catalog/index.php?cPath=31 > > Steve > > > On Mon, Dec 21, 2009 at 4:22 PM, Steve Sakoman <sa...@gm...> > wrote: > >> > >> On Mon, Dec 21, 2009 at 12:46 PM, <cod...@gm...> wrote: > >> > Hello, > >> > > >> > I'm working on a C++ project to read button presses via GPIO pins from > >> > the > >> > Gumstix board and am running into some issues. As I understand it, > >> > there > >> > are two different ways to read GPIO lines: 1.) reading through an API, > >> > or > >> > 2.) standard filesystem commands like cat and echo. We are currently > >> > using > >> > filesystem commands. > >> > > >> > So far, I've just been trying to read the pins on the commandline via, > >> > for > >> > example, 'cat /sys/class/gpio/gpioN' where N is the GPIO number. As I > >> > understand it, this gpio directory lists all the GPIO pins that have > >> > been > >> > 'exported' by the kernel to userspace. However, if I export other > >> > GPIOs, I > >> > can't seem to successfully read them. Is there a way to change the > >> > configuration of the kernel to make more GPIO pins available? Could > the > >> > kernel be reserving certain pins for other uses so I can't actually > read > >> > button presses with them? Am I just making this more complicated than > >> > it > >> > needs to be? > >> > > >> > The Gumstix board is mounted on a summit board, which has a 40-pin > >> > connector > >> > as referenced at > >> > > >> > > http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Summit-board-40-pin-header-SV1/112.html > . > >> > > >> > However, the GPIO pins listed on that chart don't match the GPIO pins > >> > that > >> > exist in /sys/class/gpio when I boot the system. For example, GPIO114 > >> > exists in the filesystem, but GPIO171 does not. If I attach a button > to > >> > the > >> > pins for GPIO114, the button appears to work (gpio114/value changes > >> > between > >> > 0 and 1). I can 'echo 171 > export' to gain access to GPIO 171, but > >> > when I > >> > read the value of that pin via 'cat gpio171/value' it always stays at > 0 > >> > whether the attached button is pressed or not. > >> > > >> > Any thoughts? > >> > >> You will note that pin is labeled: GPIO171_SPI1_CLK > >> > >> This means it is a pin that can have 2 functions, either gpio_171 or > >> spi1_clk > >> > >> Since the Gumstix Palo and Chestnut boards use the spi bus for the > >> touchscreen controller, this pin is configured by u-boot for the spi > >> function and not the gpio function. This is why you are not able to > >> use in successfully in that mode. > >> > >> If you want to use it in gpio mode you will need to modify the u-boot > >> pinmux setup. Of course spi will no longer work then, so you should > >> make sure that whatever expansion board you are using doesn't require > >> spi. > >> > >> Steve > >> > >> > >> > > >> > > ------------------------------------------------------------------------------ > >> > This SF.Net email is sponsored by the Verizon Developer Community > >> > Take advantage of Verizon's best-in-class app development support > >> > A streamlined, 14 day to market process makes app distribution fast > and > >> > easy > >> > Join now and get one step closer to millions of Verizon customers > >> > http://p.sf.net/sfu/verizon-dev2dev > >> > _______________________________________________ > >> > gumstix-users mailing list > >> > gum...@li... > >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users > >> > > >> > > >> > >> > >> > ------------------------------------------------------------------------------ > >> This SF.Net email is sponsored by the Verizon Developer Community > >> Take advantage of Verizon's best-in-class app development support > >> A streamlined, 14 day to market process makes app distribution fast and > >> easy > >> Join now and get one step closer to millions of Verizon customers > >> http://p.sf.net/sfu/verizon-dev2dev > >> _______________________________________________ > >> gumstix-users mailing list > >> gum...@li... > >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and > easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: <cod...@gm...> - 2009-12-30 16:22:43
|
I found some information online about rebuilding u-boot. Basically I just ran $ bitbake u-boot $ bitbake -c devshell u-boot Which brought me into a development shell. I modified ./board/omap3/overo/overo.h and added lines at the end of the file for the desired GPIO pins. Save, exit, and bitbake continues through the rebuild. Now I just need to find where the rebuilt u-boot went and how to actually put it on the board. :) On Tue, Dec 22, 2009 at 10:20 AM, <cod...@gm...> wrote: > Where do I get the sources for this? When I search my entire overo-oe > directory for overo.h, I find about 7 copies under overo-oe/tmp/(work or > staging) but not the original file. I do have an overo-oe/sources directory > with a bunch of items, but nothing with uboot. > > > On Mon, Dec 21, 2009 at 7:53 PM, Steve Sakoman <sa...@gm...> wrote: > >> On Mon, Dec 21, 2009 at 4:30 PM, <cod...@gm...> wrote: >> > Steve, >> > >> > Thank you for that information. I'm not very familiar with u-boot, but >> I've >> > seen environment variables in there before. Can I assume that any of >> the >> > multi-function pins (like 171 for example) on the 40-pin connector can >> be >> > configured for one function or the other in u-boot? >> >> Yes. To be clear, though, this will require modifying the overo.h >> file in the sources and rebuilding u-boot. >> >> > 171 shouldn't be a >> > problem since we won't be using a touchscreen controller in this system. >> > I've never heard of Palo and Chestnut. This board is Overo, or at least >> I >> > believe Overo is the board name. I'm still trying to get used to the >> naming >> > conventions. >> >> See the Gumstix website -- both Palo and Chestnut links can be found here: >> >> http://gumstix.com/store/catalog/index.php?cPath=31 >> >> Steve >> >> > On Mon, Dec 21, 2009 at 4:22 PM, Steve Sakoman <sa...@gm...> >> wrote: >> >> >> >> On Mon, Dec 21, 2009 at 12:46 PM, <cod...@gm...> wrote: >> >> > Hello, >> >> > >> >> > I'm working on a C++ project to read button presses via GPIO pins >> from >> >> > the >> >> > Gumstix board and am running into some issues. As I understand it, >> >> > there >> >> > are two different ways to read GPIO lines: 1.) reading through an >> API, >> >> > or >> >> > 2.) standard filesystem commands like cat and echo. We are currently >> >> > using >> >> > filesystem commands. >> >> > >> >> > So far, I've just been trying to read the pins on the commandline >> via, >> >> > for >> >> > example, 'cat /sys/class/gpio/gpioN' where N is the GPIO number. As >> I >> >> > understand it, this gpio directory lists all the GPIO pins that have >> >> > been >> >> > 'exported' by the kernel to userspace. However, if I export other >> >> > GPIOs, I >> >> > can't seem to successfully read them. Is there a way to change the >> >> > configuration of the kernel to make more GPIO pins available? Could >> the >> >> > kernel be reserving certain pins for other uses so I can't actually >> read >> >> > button presses with them? Am I just making this more complicated >> than >> >> > it >> >> > needs to be? >> >> > >> >> > The Gumstix board is mounted on a summit board, which has a 40-pin >> >> > connector >> >> > as referenced at >> >> > >> >> > >> http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Summit-board-40-pin-header-SV1/112.html >> . >> >> > >> >> > However, the GPIO pins listed on that chart don't match the GPIO pins >> >> > that >> >> > exist in /sys/class/gpio when I boot the system. For example, >> GPIO114 >> >> > exists in the filesystem, but GPIO171 does not. If I attach a button >> to >> >> > the >> >> > pins for GPIO114, the button appears to work (gpio114/value changes >> >> > between >> >> > 0 and 1). I can 'echo 171 > export' to gain access to GPIO 171, but >> >> > when I >> >> > read the value of that pin via 'cat gpio171/value' it always stays at >> 0 >> >> > whether the attached button is pressed or not. >> >> > >> >> > Any thoughts? >> >> >> >> You will note that pin is labeled: GPIO171_SPI1_CLK >> >> >> >> This means it is a pin that can have 2 functions, either gpio_171 or >> >> spi1_clk >> >> >> >> Since the Gumstix Palo and Chestnut boards use the spi bus for the >> >> touchscreen controller, this pin is configured by u-boot for the spi >> >> function and not the gpio function. This is why you are not able to >> >> use in successfully in that mode. >> >> >> >> If you want to use it in gpio mode you will need to modify the u-boot >> >> pinmux setup. Of course spi will no longer work then, so you should >> >> make sure that whatever expansion board you are using doesn't require >> >> spi. >> >> >> >> Steve >> >> >> >> >> >> > >> >> > >> ------------------------------------------------------------------------------ >> >> > This SF.Net email is sponsored by the Verizon Developer Community >> >> > Take advantage of Verizon's best-in-class app development support >> >> > A streamlined, 14 day to market process makes app distribution fast >> and >> >> > easy >> >> > Join now and get one step closer to millions of Verizon customers >> >> > http://p.sf.net/sfu/verizon-dev2dev >> >> > _______________________________________________ >> >> > gumstix-users mailing list >> >> > gum...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > >> >> > >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> This SF.Net email is sponsored by the Verizon Developer Community >> >> Take advantage of Verizon's best-in-class app development support >> >> A streamlined, 14 day to market process makes app distribution fast and >> >> easy >> >> Join now and get one step closer to millions of Verizon customers >> >> http://p.sf.net/sfu/verizon-dev2dev >> >> _______________________________________________ >> >> gumstix-users mailing list >> >> gum...@li... >> >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > >> > >> > >> ------------------------------------------------------------------------------ >> > This SF.Net email is sponsored by the Verizon Developer Community >> > Take advantage of Verizon's best-in-class app development support >> > A streamlined, 14 day to market process makes app distribution fast and >> easy >> > Join now and get one step closer to millions of Verizon customers >> > http://p.sf.net/sfu/verizon-dev2dev >> > _______________________________________________ >> > gumstix-users mailing list >> > gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > >> > >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > |
From: ScottEllis <sco...@gm...> - 2009-12-31 17:31:32
|
I think u-boot-omap3 is the version you want to be using. scott@quad:~/overo-oe/org.openembedded.dev/conf$ grep -r u-boot * | grep overo machine/overo.conf:PREFERRED_PROVIDER_virtual/bootloader = "u-boot-omap3" machine/omap3.conf:# there is no generic omap3 u-boot, so just build the overo one You might want to manage your changes with a patch file so it fits smoothly into the OE framework. Go ahead and build u-boot-omap3 once so that the source gets extracted into $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 (The version info after u-boot-omap3 might change.) (TMPDIR is defined in ~/overo-oe/build/conf/site.conf) Then to modify git/board/overo/overo.h file, you could do the following $ cd $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 $ cp git/board/overo/overo.h git/board/overo/overo.h-orig $ vi git/board/overo/overo.h $ [make your changes and save it] $ git diff git/board/overo/overo.h-orig git/board/overo/overo.h > my-pin-mux.patch $ cp my-pin-mux.patch ~/overo-oe/org.openembedded.dev/recipes/u-boot/u-boot-omap3-git/ (Note that it is u-boot-omap3<dash>git) Now edit the u-boot-omap3_git.bb recipe to include the patch. $ cd ~/overo-oe $ vi org.openembedded.dev/recipes/u-boot/u-boot-omap3_git.bb (Note that it is u-boot-omap3<underscore>git.bb) ... SRC_URI = "git://git.denx.de/u-boot.git;protocol=git \ file://fw_env.config \ file://tincan.patch;patch=1 \ file://gpmc-net.patch;patch=1 \ + file://my-pin-mux.patch;patch=1 \ " ... When you don't want the patch applied just remove the line you added from the recipe. Then rebuild u-boot $ cd ~/overo-oe The clean will remove the $TMPDIR/work/overo-angstrom-linux-gnueabi/u-boot... directory $ bitbake -c clean u-boot-omap3 The rebuild will apply the patches after extraction $ bitbake -c rebuild u-boot-omap3 If it works you'll have a new u-boot-overo.bin file here $TMPDIR/deploy/glibc/images/overo/u-boot-overo.bin Seems like a lot of work at first, but at the end you only have to manage the patch file or files if you have different versions. It also makes it easy to move around among different build machines. You can put the new u-boot on a microSD card using these instructions http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html or first copy it to the overo filesystem and then use the mtd tools to copy it to nand using these instructions http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html -- View this message in context: http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p26980554.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: <cod...@gm...> - 2010-01-01 14:05:50
|
Steve - Thanks for the instructions on this. I guess the way I was doing it, namely $ bitbake u-boot $ bitbake -c devshell u-boot $ [make changes to overo.h, save, exit vi, exit devshell] was changing the original u-boot files, which we wouldn't necessarily want, and a patch would be better? Would I have to repeat my above steps first to restore overo.h to its original first before performing the patch steps below? Or does OE preserve the original overo.h when I used my above method? I'll give this a shot after the holiday when I get back to the office. On Thu, Dec 31, 2009 at 12:31 PM, ScottEllis <sco...@gm... > wrote: > > I think u-boot-omap3 is the version you want to be using. > > scott@quad:~/overo-oe/org.openembedded.dev/conf$ grep -r u-boot * | grep > overo > machine/overo.conf:PREFERRED_PROVIDER_virtual/bootloader = "u-boot-omap3" > machine/omap3.conf:# there is no generic omap3 u-boot, so just build the > overo one > > You might want to manage your changes with a patch file so it fits smoothly > into the OE framework. > > Go ahead and build u-boot-omap3 once so that the source gets extracted into > > > $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 > > (The version info after u-boot-omap3 might change.) > > (TMPDIR is defined in ~/overo-oe/build/conf/site.conf) > > Then to modify git/board/overo/overo.h file, you could do the following > > $ cd > > $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 > > $ cp git/board/overo/overo.h git/board/overo/overo.h-orig > > $ vi git/board/overo/overo.h > > $ [make your changes and save it] > > $ git diff git/board/overo/overo.h-orig git/board/overo/overo.h > > my-pin-mux.patch > > $ cp my-pin-mux.patch > ~/overo-oe/org.openembedded.dev/recipes/u-boot/u-boot-omap3-git/ > (Note that it is u-boot-omap3<dash>git) > > Now edit the u-boot-omap3_git.bb recipe to include the patch. > > $ cd ~/overo-oe > > $ vi org.openembedded.dev/recipes/u-boot/u-boot-omap3_git.bb > (Note that it is u-boot-omap3<underscore>git.bb) > > ... > SRC_URI = "git://git.denx.de/u-boot.git;protocol=git \ > file://fw_env.config \ > file://tincan.patch;patch=1 \ > file://gpmc-net.patch;patch=1 \ > + file://my-pin-mux.patch;patch=1 \ > " > ... > > When you don't want the patch applied just remove the line you added from > the recipe. > > Then rebuild u-boot > > $ cd ~/overo-oe > > The clean will remove the > $TMPDIR/work/overo-angstrom-linux-gnueabi/u-boot... directory > $ bitbake -c clean u-boot-omap3 > > The rebuild will apply the patches after extraction > $ bitbake -c rebuild u-boot-omap3 > > If it works you'll have a new u-boot-overo.bin file here > > $TMPDIR/deploy/glibc/images/overo/u-boot-overo.bin > > Seems like a lot of work at first, but at the end you only have to manage > the patch > file or files if you have different versions. It also makes it easy to move > around > among different build machines. > > You can put the new u-boot on a microSD card using these instructions > > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html > > or first copy it to the overo filesystem and then use the mtd tools to copy > it to nand using these instructions > > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html > > > -- > View this message in context: > http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p26980554.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Scott E. <sco...@gm...> - 2010-01-01 14:52:05
|
It's Scott :-) Everytime you run bitbake -c clean u-boot-omap3 your changes will be gone since the entire directory is removed. When you build again it is downloaded if need be, and then unpacked into the tmp/work dir again. I haven't figured out how to make changes to source files in the TMPDIR/work and get bitbake to notice a change and just recompile like make, so I always do the bitbake -c clean, bitbake -c rebuild cycle. For u-boot it only takes a few minutes, so it's not that big a deal. For generating the patch, use git diff --no-prefix or you have to go in and pull the a/ .. b/ .. prefixes out of the diff manually. On 1/1/10, cod...@gm... <cod...@gm...> wrote: > Steve - Thanks for the instructions on this. I guess the way I was doing > it, namely > > $ bitbake u-boot > $ bitbake -c devshell u-boot > $ [make changes to overo.h, save, exit vi, exit devshell] > > was changing the original u-boot files, which we wouldn't necessarily want, > and a patch would be better? > > Would I have to repeat my above steps first to restore overo.h to its > original first before performing the patch steps below? Or does OE preserve > the original overo.h when I used my above method? > > I'll give this a shot after the holiday when I get back to the office. > > On Thu, Dec 31, 2009 at 12:31 PM, ScottEllis <sco...@gm... >> wrote: > >> >> I think u-boot-omap3 is the version you want to be using. >> >> scott@quad:~/overo-oe/org.openembedded.dev/conf$ grep -r u-boot * | grep >> overo >> machine/overo.conf:PREFERRED_PROVIDER_virtual/bootloader = "u-boot-omap3" >> machine/omap3.conf:# there is no generic omap3 u-boot, so just build the >> overo one >> >> You might want to manage your changes with a patch file so it fits >> smoothly >> into the OE framework. >> >> Go ahead and build u-boot-omap3 once so that the source gets extracted >> into >> >> >> $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 >> >> (The version info after u-boot-omap3 might change.) >> >> (TMPDIR is defined in ~/overo-oe/build/conf/site.conf) >> >> Then to modify git/board/overo/overo.h file, you could do the following >> >> $ cd >> >> $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 >> >> $ cp git/board/overo/overo.h git/board/overo/overo.h-orig >> >> $ vi git/board/overo/overo.h >> >> $ [make your changes and save it] >> >> $ git diff git/board/overo/overo.h-orig git/board/overo/overo.h > >> my-pin-mux.patch >> >> $ cp my-pin-mux.patch >> ~/overo-oe/org.openembedded.dev/recipes/u-boot/u-boot-omap3-git/ >> (Note that it is u-boot-omap3<dash>git) >> >> Now edit the u-boot-omap3_git.bb recipe to include the patch. >> >> $ cd ~/overo-oe >> >> $ vi org.openembedded.dev/recipes/u-boot/u-boot-omap3_git.bb >> (Note that it is u-boot-omap3<underscore>git.bb) >> >> ... >> SRC_URI = "git://git.denx.de/u-boot.git;protocol=git \ >> file://fw_env.config \ >> file://tincan.patch;patch=1 \ >> file://gpmc-net.patch;patch=1 \ >> + file://my-pin-mux.patch;patch=1 \ >> " >> ... >> >> When you don't want the patch applied just remove the line you added from >> the recipe. >> >> Then rebuild u-boot >> >> $ cd ~/overo-oe >> >> The clean will remove the >> $TMPDIR/work/overo-angstrom-linux-gnueabi/u-boot... directory >> $ bitbake -c clean u-boot-omap3 >> >> The rebuild will apply the patches after extraction >> $ bitbake -c rebuild u-boot-omap3 >> >> If it works you'll have a new u-boot-overo.bin file here >> >> $TMPDIR/deploy/glibc/images/overo/u-boot-overo.bin >> >> Seems like a lot of work at first, but at the end you only have to manage >> the patch >> file or files if you have different versions. It also makes it easy to >> move >> around >> among different build machines. >> >> You can put the new u-boot on a microSD card using these instructions >> >> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html >> >> or first copy it to the overo filesystem and then use the mtd tools to >> copy >> it to nand using these instructions >> >> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html >> >> >> -- >> View this message in context: >> http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p26980554.html >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > |
From: Philip B. <ph...@ba...> - 2010-01-01 14:56:50
|
On 01/01/2010 09:51 AM, Scott Ellis wrote: > It's Scott :-) > > Everytime you run bitbake -c clean u-boot-omap3 your changes will be > gone since the entire directory is removed. When you build again it is > downloaded > if need be, and then unpacked into the tmp/work dir again. > > I haven't figured out how to make changes to source files in the > TMPDIR/work and get bitbake to notice a change and just recompile > like make, so I always do the bitbake -c clean, bitbake -c rebuild > cycle. For u-boot it only takes a few minutes, so it's not that big a > deal. This might give you some ideas: http://www.xora.org.uk/2009/12/10/openembeddedangstrom-kernel-workflow/ Philip > > For generating the patch, use git diff --no-prefix or you have to go in and pull > the a/ .. b/ .. prefixes out of the diff manually. > > On 1/1/10, cod...@gm...<cod...@gm...> wrote: >> Steve - Thanks for the instructions on this. I guess the way I was doing >> it, namely >> >> $ bitbake u-boot >> $ bitbake -c devshell u-boot >> $ [make changes to overo.h, save, exit vi, exit devshell] >> >> was changing the original u-boot files, which we wouldn't necessarily want, >> and a patch would be better? >> >> Would I have to repeat my above steps first to restore overo.h to its >> original first before performing the patch steps below? Or does OE preserve >> the original overo.h when I used my above method? >> >> I'll give this a shot after the holiday when I get back to the office. >> >> On Thu, Dec 31, 2009 at 12:31 PM, ScottEllis<sco...@gm... >>> wrote: >> >>> >>> I think u-boot-omap3 is the version you want to be using. >>> >>> scott@quad:~/overo-oe/org.openembedded.dev/conf$ grep -r u-boot * | grep >>> overo >>> machine/overo.conf:PREFERRED_PROVIDER_virtual/bootloader = "u-boot-omap3" >>> machine/omap3.conf:# there is no generic omap3 u-boot, so just build the >>> overo one >>> >>> You might want to manage your changes with a patch file so it fits >>> smoothly >>> into the OE framework. >>> >>> Go ahead and build u-boot-omap3 once so that the source gets extracted >>> into >>> >>> >>> $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 >>> >>> (The version info after u-boot-omap3 might change.) >>> >>> (TMPDIR is defined in ~/overo-oe/build/conf/site.conf) >>> >>> Then to modify git/board/overo/overo.h file, you could do the following >>> >>> $ cd >>> >>> $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 >>> >>> $ cp git/board/overo/overo.h git/board/overo/overo.h-orig >>> >>> $ vi git/board/overo/overo.h >>> >>> $ [make your changes and save it] >>> >>> $ git diff git/board/overo/overo.h-orig git/board/overo/overo.h> >>> my-pin-mux.patch >>> >>> $ cp my-pin-mux.patch >>> ~/overo-oe/org.openembedded.dev/recipes/u-boot/u-boot-omap3-git/ >>> (Note that it is u-boot-omap3<dash>git) >>> >>> Now edit the u-boot-omap3_git.bb recipe to include the patch. >>> >>> $ cd ~/overo-oe >>> >>> $ vi org.openembedded.dev/recipes/u-boot/u-boot-omap3_git.bb >>> (Note that it is u-boot-omap3<underscore>git.bb) >>> >>> ... >>> SRC_URI = "git://git.denx.de/u-boot.git;protocol=git \ >>> file://fw_env.config \ >>> file://tincan.patch;patch=1 \ >>> file://gpmc-net.patch;patch=1 \ >>> + file://my-pin-mux.patch;patch=1 \ >>> " >>> ... >>> >>> When you don't want the patch applied just remove the line you added from >>> the recipe. >>> >>> Then rebuild u-boot >>> >>> $ cd ~/overo-oe >>> >>> The clean will remove the >>> $TMPDIR/work/overo-angstrom-linux-gnueabi/u-boot... directory >>> $ bitbake -c clean u-boot-omap3 >>> >>> The rebuild will apply the patches after extraction >>> $ bitbake -c rebuild u-boot-omap3 >>> >>> If it works you'll have a new u-boot-overo.bin file here >>> >>> $TMPDIR/deploy/glibc/images/overo/u-boot-overo.bin >>> >>> Seems like a lot of work at first, but at the end you only have to manage >>> the patch >>> file or files if you have different versions. It also makes it easy to >>> move >>> around >>> among different build machines. >>> >>> You can put the new u-boot on a microSD card using these instructions >>> >>> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html >>> >>> or first copy it to the overo filesystem and then use the mtd tools to >>> copy >>> it to nand using these instructions >>> >>> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html >>> >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p26980554.html >>> Sent from the Gumstix mailing list archive at Nabble.com. >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: <cod...@gm...> - 2010-01-05 01:06:57
|
Scott, I got the name right this time. HA! I looked at the wrong line in my inbox when replying. Sorry :-P Thanks for the updated info. I'll have to try this out. I'll be in touch on here if I run into any other issues with this rebuild of u-boot. On Thu, Dec 31, 2009 at 12:31 PM, ScottEllis <sco...@gm... > wrote: > > I think u-boot-omap3 is the version you want to be using. > > scott@quad:~/overo-oe/org.openembedded.dev/conf$ grep -r u-boot * | grep > overo > machine/overo.conf:PREFERRED_PROVIDER_virtual/bootloader = "u-boot-omap3" > machine/omap3.conf:# there is no generic omap3 u-boot, so just build the > overo one > > You might want to manage your changes with a patch file so it fits smoothly > into the OE framework. > > Go ahead and build u-boot-omap3 once so that the source gets extracted into > > > $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 > > (The version info after u-boot-omap3 might change.) > > (TMPDIR is defined in ~/overo-oe/build/conf/site.conf) > > Then to modify git/board/overo/overo.h file, you could do the following > > $ cd > > $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 > > $ cp git/board/overo/overo.h git/board/overo/overo.h-orig > > $ vi git/board/overo/overo.h > > $ [make your changes and save it] > > $ git diff git/board/overo/overo.h-orig git/board/overo/overo.h > > my-pin-mux.patch > > $ cp my-pin-mux.patch > ~/overo-oe/org.openembedded.dev/recipes/u-boot/u-boot-omap3-git/ > (Note that it is u-boot-omap3<dash>git) > > Now edit the u-boot-omap3_git.bb recipe to include the patch. > > $ cd ~/overo-oe > > $ vi org.openembedded.dev/recipes/u-boot/u-boot-omap3_git.bb > (Note that it is u-boot-omap3<underscore>git.bb) > > ... > SRC_URI = "git://git.denx.de/u-boot.git;protocol=git \ > file://fw_env.config \ > file://tincan.patch;patch=1 \ > file://gpmc-net.patch;patch=1 \ > + file://my-pin-mux.patch;patch=1 \ > " > ... > > When you don't want the patch applied just remove the line you added from > the recipe. > > Then rebuild u-boot > > $ cd ~/overo-oe > > The clean will remove the > $TMPDIR/work/overo-angstrom-linux-gnueabi/u-boot... directory > $ bitbake -c clean u-boot-omap3 > > The rebuild will apply the patches after extraction > $ bitbake -c rebuild u-boot-omap3 > > If it works you'll have a new u-boot-overo.bin file here > > $TMPDIR/deploy/glibc/images/overo/u-boot-overo.bin > > Seems like a lot of work at first, but at the end you only have to manage > the patch > file or files if you have different versions. It also makes it easy to move > around > among different build machines. > > You can put the new u-boot on a microSD card using these instructions > > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html > > or first copy it to the overo filesystem and then use the mtd tools to copy > it to nand using these instructions > > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html > > > -- > View this message in context: > http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p26980554.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Jonmoz <jmo...@gm...> - 2010-01-26 18:07:56
|
Hi, I'm attempting to do something somewhat similar. Essentially I need to be able to drive some of the GPIO ports from the kernel (specifically ports 144, 145, 146, 147, and 151). I have located overo.h and am looking through it. I'm not exactly sure how to enable these GPIOs, and am slightly hesitant to muck (mux? :D) up the code without being fairly sure what I'm doing. So this question should be pretty easy: What lines do I change in overo.h to enable these GPIOs? For example, I see MUX_VAL(CP(UART2_CTS), (IEN | PTD | DIS | M4)) /*GPIO_144 - LCD_EN*/\ MUX_VAL(CP(UART2_RTS), (IEN | PTD | DIS | M4)) /*GPIO_145*/\ MUX_VAL(CP(UART2_TX), (IEN | PTD | DIS | M4)) /*GPIO_146*/\ MUX_VAL(CP(UART2_RX), (IEN | PTD | DIS | M4)) /*GPIO_147*/\ But have no idea whether changing DIS to EN by itself would do the trick, or whether I have to change the MUX value itself, or the mode. As always, any help is appreciated, Jon coderdrone wrote: > >> >> I think u-boot-omap3 is the version you want to be using. >> >> scott@quad:~/overo-oe/org.openembedded.dev/conf$ grep -r u-boot * | grep >> overo >> machine/overo.conf:PREFERRED_PROVIDER_virtual/bootloader = "u-boot-omap3" >> machine/omap3.conf:# there is no generic omap3 u-boot, so just build the >> overo one >> >> You might want to manage your changes with a patch file so it fits >> smoothly >> into the OE framework. >> >> Go ahead and build u-boot-omap3 once so that the source gets extracted >> into >> >> >> $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 >> >> (The version info after u-boot-omap3 might change.) >> >> (TMPDIR is defined in ~/overo-oe/build/conf/site.conf) >> >> Then to modify git/board/overo/overo.h file, you could do the following >> >> $ cd >> >> $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 >> >> $ cp git/board/overo/overo.h git/board/overo/overo.h-orig >> >> $ vi git/board/overo/overo.h >> >> $ [make your changes and save it] >> >> $ git diff git/board/overo/overo.h-orig git/board/overo/overo.h > >> my-pin-mux.patch >> >> $ cp my-pin-mux.patch >> ~/overo-oe/org.openembedded.dev/recipes/u-boot/u-boot-omap3-git/ >> (Note that it is u-boot-omap3<dash>git) >> >> Now edit the u-boot-omap3_git.bb recipe to include the patch. >> >> $ cd ~/overo-oe >> >> $ vi org.openembedded.dev/recipes/u-boot/u-boot-omap3_git.bb >> (Note that it is u-boot-omap3<underscore>git.bb) >> >> ... >> SRC_URI = "git://git.denx.de/u-boot.git;protocol=git \ >> file://fw_env.config \ >> file://tincan.patch;patch=1 \ >> file://gpmc-net.patch;patch=1 \ >> + file://my-pin-mux.patch;patch=1 \ >> " >> ... >> >> When you don't want the patch applied just remove the line you added from >> the recipe. >> >> Then rebuild u-boot >> >> $ cd ~/overo-oe >> >> The clean will remove the >> $TMPDIR/work/overo-angstrom-linux-gnueabi/u-boot... directory >> $ bitbake -c clean u-boot-omap3 >> >> The rebuild will apply the patches after extraction >> $ bitbake -c rebuild u-boot-omap3 >> >> If it works you'll have a new u-boot-overo.bin file here >> >> $TMPDIR/deploy/glibc/images/overo/u-boot-overo.bin >> >> Seems like a lot of work at first, but at the end you only have to manage >> the patch >> file or files if you have different versions. It also makes it easy to >> move >> around >> among different build machines. >> >> You can put the new u-boot on a microSD card using these instructions >> >> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html >> >> or first copy it to the overo filesystem and then use the mtd tools to >> copy >> it to nand using these instructions >> >> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html >> >> >> -- >> View this message in context: >> http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p26980554.html >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > -- View this message in context: http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p27327104.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Tyler S. <sou...@gm...> - 2010-01-26 19:05:38
|
I'm attempting to set the pin muxes to allow GPIO on the SPI and PWM pins. I'm in the process of following Scott's walkthrough above, but I'm confused as to what to change in the overo.h file to switch the mux over. Could someone provide a short example of changing, say, some SPI pin to be GPIO? Thanks, Tyler coderdrone wrote: > > Scott, > > I got the name right this time. HA! I looked at the wrong line in my > inbox > when replying. Sorry :-P > > Thanks for the updated info. I'll have to try this out. I'll be in touch > on here if I run into any other issues with this rebuild of u-boot. > > On Thu, Dec 31, 2009 at 12:31 PM, ScottEllis > <sco...@gm... >> wrote: > >> >> I think u-boot-omap3 is the version you want to be using. >> >> scott@quad:~/overo-oe/org.openembedded.dev/conf$ grep -r u-boot * | grep >> overo >> machine/overo.conf:PREFERRED_PROVIDER_virtual/bootloader = "u-boot-omap3" >> machine/omap3.conf:# there is no generic omap3 u-boot, so just build the >> overo one >> >> You might want to manage your changes with a patch file so it fits >> smoothly >> into the OE framework. >> >> Go ahead and build u-boot-omap3 once so that the source gets extracted >> into >> >> >> $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 >> >> (The version info after u-boot-omap3 might change.) >> >> (TMPDIR is defined in ~/overo-oe/build/conf/site.conf) >> >> Then to modify git/board/overo/overo.h file, you could do the following >> >> $ cd >> >> $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 >> >> $ cp git/board/overo/overo.h git/board/overo/overo.h-orig >> >> $ vi git/board/overo/overo.h >> >> $ [make your changes and save it] >> >> $ git diff git/board/overo/overo.h-orig git/board/overo/overo.h > >> my-pin-mux.patch >> >> $ cp my-pin-mux.patch >> ~/overo-oe/org.openembedded.dev/recipes/u-boot/u-boot-omap3-git/ >> (Note that it is u-boot-omap3<dash>git) >> >> Now edit the u-boot-omap3_git.bb recipe to include the patch. >> >> $ cd ~/overo-oe >> >> $ vi org.openembedded.dev/recipes/u-boot/u-boot-omap3_git.bb >> (Note that it is u-boot-omap3<underscore>git.bb) >> >> ... >> SRC_URI = "git://git.denx.de/u-boot.git;protocol=git \ >> file://fw_env.config \ >> file://tincan.patch;patch=1 \ >> file://gpmc-net.patch;patch=1 \ >> + file://my-pin-mux.patch;patch=1 \ >> " >> ... >> >> When you don't want the patch applied just remove the line you added from >> the recipe. >> >> Then rebuild u-boot >> >> $ cd ~/overo-oe >> >> The clean will remove the >> $TMPDIR/work/overo-angstrom-linux-gnueabi/u-boot... directory >> $ bitbake -c clean u-boot-omap3 >> >> The rebuild will apply the patches after extraction >> $ bitbake -c rebuild u-boot-omap3 >> >> If it works you'll have a new u-boot-overo.bin file here >> >> $TMPDIR/deploy/glibc/images/overo/u-boot-overo.bin >> >> Seems like a lot of work at first, but at the end you only have to manage >> the patch >> file or files if you have different versions. It also makes it easy to >> move >> around >> among different build machines. >> >> You can put the new u-boot on a microSD card using these instructions >> >> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html >> >> or first copy it to the overo filesystem and then use the mtd tools to >> copy >> it to nand using these instructions >> >> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html >> >> >> -- >> View this message in context: >> http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p26980554.html >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p27327967.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: <cod...@gm...> - 2010-01-31 20:31:52
|
Tyler, I'm sure there is likely a better way to do this, but I just searched for the GPIO I want on Google. I might do a search for "overo.h GPIO_171" to find diff patches online that mention those GPIOs. I just pasted the results at the end of gpio.h and modified them. For example, a line at the end of my overo.h similar to: MUX_VAL(CP(MCSPI1_CLK), (IEN | PTU | EN | M4)) /*GPIO_171*/\ would enable GPIO 171. Other than adding several lines similar to the above to the end of overo.h, I didn't make any other changes. Actually, those went in as a patch following Scott's walkthrough. I too would like to get a better understanding about those lines, rather than just blindly adding them because someone else's overo.h has them. :) On Tue, Jan 26, 2010 at 2:05 PM, Tyler Southard <sou...@gm...>wrote: > > I'm attempting to set the pin muxes to allow GPIO on the SPI and PWM pins. > I'm in the process of following Scott's walkthrough above, but I'm confused > as to what to change in the overo.h file to switch the mux over. Could > someone provide a short example of changing, say, some SPI pin to be GPIO? > > Thanks, > Tyler > > > coderdrone wrote: > > > > Scott, > > > > I got the name right this time. HA! I looked at the wrong line in my > > inbox > > when replying. Sorry :-P > > > > Thanks for the updated info. I'll have to try this out. I'll be in > touch > > on here if I run into any other issues with this rebuild of u-boot. > > > > On Thu, Dec 31, 2009 at 12:31 PM, ScottEllis > > <sco...@gm... > >> wrote: > > > >> > >> I think u-boot-omap3 is the version you want to be using. > >> > >> scott@quad:~/overo-oe/org.openembedded.dev/conf$ grep -r u-boot * | > grep > >> overo > >> machine/overo.conf:PREFERRED_PROVIDER_virtual/bootloader = > "u-boot-omap3" > >> machine/omap3.conf:# there is no generic omap3 u-boot, so just build the > >> overo one > >> > >> You might want to manage your changes with a patch file so it fits > >> smoothly > >> into the OE framework. > >> > >> Go ahead and build u-boot-omap3 once so that the source gets extracted > >> into > >> > >> > >> > $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 > >> > >> (The version info after u-boot-omap3 might change.) > >> > >> (TMPDIR is defined in ~/overo-oe/build/conf/site.conf) > >> > >> Then to modify git/board/overo/overo.h file, you could do the following > >> > >> $ cd > >> > >> > $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 > >> > >> $ cp git/board/overo/overo.h git/board/overo/overo.h-orig > >> > >> $ vi git/board/overo/overo.h > >> > >> $ [make your changes and save it] > >> > >> $ git diff git/board/overo/overo.h-orig git/board/overo/overo.h > > >> my-pin-mux.patch > >> > >> $ cp my-pin-mux.patch > >> ~/overo-oe/org.openembedded.dev/recipes/u-boot/u-boot-omap3-git/ > >> (Note that it is u-boot-omap3<dash>git) > >> > >> Now edit the u-boot-omap3_git.bb recipe to include the patch. > >> > >> $ cd ~/overo-oe > >> > >> $ vi org.openembedded.dev/recipes/u-boot/u-boot-omap3_git.bb > >> (Note that it is u-boot-omap3<underscore>git.bb) > >> > >> ... > >> SRC_URI = "git://git.denx.de/u-boot.git;protocol=git \ > >> file://fw_env.config \ > >> file://tincan.patch;patch=1 \ > >> file://gpmc-net.patch;patch=1 \ > >> + file://my-pin-mux.patch;patch=1 \ > >> " > >> ... > >> > >> When you don't want the patch applied just remove the line you added > from > >> the recipe. > >> > >> Then rebuild u-boot > >> > >> $ cd ~/overo-oe > >> > >> The clean will remove the > >> $TMPDIR/work/overo-angstrom-linux-gnueabi/u-boot... directory > >> $ bitbake -c clean u-boot-omap3 > >> > >> The rebuild will apply the patches after extraction > >> $ bitbake -c rebuild u-boot-omap3 > >> > >> If it works you'll have a new u-boot-overo.bin file here > >> > >> $TMPDIR/deploy/glibc/images/overo/u-boot-overo.bin > >> > >> Seems like a lot of work at first, but at the end you only have to > manage > >> the patch > >> file or files if you have different versions. It also makes it easy to > >> move > >> around > >> among different build machines. > >> > >> You can put the new u-boot on a microSD card using these instructions > >> > >> > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html > >> > >> or first copy it to the overo filesystem and then use the mtd tools to > >> copy > >> it to nand using these instructions > >> > >> > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html > >> > >> > >> -- > >> View this message in context: > >> > http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p26980554.html > >> Sent from the Gumstix mailing list archive at Nabble.com. > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> This SF.Net email is sponsored by the Verizon Developer Community > >> Take advantage of Verizon's best-in-class app development support > >> A streamlined, 14 day to market process makes app distribution fast and > >> easy > >> Join now and get one step closer to millions of Verizon customers > >> http://p.sf.net/sfu/verizon-dev2dev > >> _______________________________________________ > >> gumstix-users mailing list > >> gum...@li... > >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > >> > > > > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and > > easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > -- > View this message in context: > http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p27327967.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: <cod...@gm...> - 2010-01-31 18:51:16
|
Jonmoz, You might not need to modify u-boot at all. By what you posted below, it looks like GPIOs 144, 145, 146, and 147 are already enabled. Do these GPIOs show up at all in /sys/class/gpio? If not, try running the following: $ echo "number" > /sys/class/gpio/export where number is the GPIO number you want to export from the kernel. You'll have to export each GPIO separately. If this works, then you'll have a separate 'gpioXXX' folder under /sys/class/gpio for each number you export. Can't hurt to try this before reconfiguring u-boot. On Tue, Jan 26, 2010 at 1:07 PM, Jonmoz <jmo...@gm...> wrote: > > Hi, > > I'm attempting to do something somewhat similar. Essentially I need to be > able to drive some of the GPIO ports from the kernel (specifically ports > 144, 145, 146, 147, and 151). I have located overo.h and am looking > through > it. > > I'm not exactly sure how to enable these GPIOs, and am slightly hesitant to > muck (mux? :D) up the code without being fairly sure what I'm doing. > > So this question should be pretty easy: > > What lines do I change in overo.h to enable these GPIOs? For example, I > see > > MUX_VAL(CP(UART2_CTS), (IEN | PTD | DIS | M4)) /*GPIO_144 > - LCD_EN*/\ > MUX_VAL(CP(UART2_RTS), (IEN | PTD | DIS | M4)) > /*GPIO_145*/\ > MUX_VAL(CP(UART2_TX), (IEN | PTD | DIS | M4)) > /*GPIO_146*/\ > MUX_VAL(CP(UART2_RX), (IEN | PTD | DIS | M4)) > /*GPIO_147*/\ > > But have no idea whether changing DIS to EN by itself would do the trick, > or > whether I have to change the MUX value itself, or the mode. > > As always, any help is appreciated, > Jon > > coderdrone wrote: > > > >> > >> I think u-boot-omap3 is the version you want to be using. > >> > >> scott@quad:~/overo-oe/org.openembedded.dev/conf$ grep -r u-boot * | > grep > >> overo > >> machine/overo.conf:PREFERRED_PROVIDER_virtual/bootloader = > "u-boot-omap3" > >> machine/omap3.conf:# there is no generic omap3 u-boot, so just build the > >> overo one > >> > >> You might want to manage your changes with a patch file so it fits > >> smoothly > >> into the OE framework. > >> > >> Go ahead and build u-boot-omap3 once so that the source gets extracted > >> into > >> > >> > >> > $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 > >> > >> (The version info after u-boot-omap3 might change.) > >> > >> (TMPDIR is defined in ~/overo-oe/build/conf/site.conf) > >> > >> Then to modify git/board/overo/overo.h file, you could do the following > >> > >> $ cd > >> > >> > $TMPDIR/work/over-angstrom-linux-gnueabi/u-boot-omap3-1_2009.11+r1+git87d93a1ba2ae23550e1370adb7a3b00af0831165-r1 > >> > >> $ cp git/board/overo/overo.h git/board/overo/overo.h-orig > >> > >> $ vi git/board/overo/overo.h > >> > >> $ [make your changes and save it] > >> > >> $ git diff git/board/overo/overo.h-orig git/board/overo/overo.h > > >> my-pin-mux.patch > >> > >> $ cp my-pin-mux.patch > >> ~/overo-oe/org.openembedded.dev/recipes/u-boot/u-boot-omap3-git/ > >> (Note that it is u-boot-omap3<dash>git) > >> > >> Now edit the u-boot-omap3_git.bb recipe to include the patch. > >> > >> $ cd ~/overo-oe > >> > >> $ vi org.openembedded.dev/recipes/u-boot/u-boot-omap3_git.bb > >> (Note that it is u-boot-omap3<underscore>git.bb) > >> > >> ... > >> SRC_URI = "git://git.denx.de/u-boot.git;protocol=git \ > >> file://fw_env.config \ > >> file://tincan.patch;patch=1 \ > >> file://gpmc-net.patch;patch=1 \ > >> + file://my-pin-mux.patch;patch=1 \ > >> " > >> ... > >> > >> When you don't want the patch applied just remove the line you added > from > >> the recipe. > >> > >> Then rebuild u-boot > >> > >> $ cd ~/overo-oe > >> > >> The clean will remove the > >> $TMPDIR/work/overo-angstrom-linux-gnueabi/u-boot... directory > >> $ bitbake -c clean u-boot-omap3 > >> > >> The rebuild will apply the patches after extraction > >> $ bitbake -c rebuild u-boot-omap3 > >> > >> If it works you'll have a new u-boot-overo.bin file here > >> > >> $TMPDIR/deploy/glibc/images/overo/u-boot-overo.bin > >> > >> Seems like a lot of work at first, but at the end you only have to > manage > >> the patch > >> file or files if you have different versions. It also makes it easy to > >> move > >> around > >> among different build machines. > >> > >> You can put the new u-boot on a microSD card using these instructions > >> > >> > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html > >> > >> or first copy it to the overo filesystem and then use the mtd tools to > >> copy > >> it to nand using these instructions > >> > >> > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html > >> > >> > >> -- > >> View this message in context: > >> > http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p26980554.html > >> Sent from the Gumstix mailing list archive at Nabble.com. > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> This SF.Net email is sponsored by the Verizon Developer Community > >> Take advantage of Verizon's best-in-class app development support > >> A streamlined, 14 day to market process makes app distribution fast and > >> easy > >> Join now and get one step closer to millions of Verizon customers > >> http://p.sf.net/sfu/verizon-dev2dev > >> _______________________________________________ > >> gumstix-users mailing list > >> gum...@li... > >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > >> > > > > > > -- > View this message in context: > http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p27327104.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: ScottEllis <sco...@gm...> - 2010-02-01 11:16:18
|
Like coderdrone says 144,145,146 and 147 are already configured for gpio so you don't have to change the u-boot muxing for them. 144 and 145 are used for the displays though so better get rid of that stuff in the linux code ../arch/arm/mach-omap2/board-overo.c if you want to complete control about how they initialize. --- from board-overo.c #define OVERO_GPIO_LCD_EN 144 #define OVERO_GPIO_LCD_BL 145 Look for all the places those constants are used. That's why you see 144 and 145 in sys/class/gpio exported already and you don't see 146 and 147. Also when you enable 146 and 147, with the "echo xxx > sys/class/gpio/export" you might need to echo "out" > sys/class/gpioxxx>direction if you want to use them as outputs. -- View this message in context: http://old.nabble.com/-Gumstix-Users--GPIO-pin-usage-tp26879785p27402662.html Sent from the Gumstix mailing list archive at Nabble.com. |