Quantcast

Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb
Hello,

I am working on a real time systems project utilizing the Overo Fire COM as an embedded device. Part of that implementation includes using 5 GPIO pins (14,17,21,22,23) to bit-bang an on-board FPGA and program it.
This is simply done by sending each bit on the fpgas PROG line while toggling it's clock line.
I searched this list for suggestions and after starting with system calls I moved on to MMAP as detailed on both a Water COM (http://gumstix.8.x6.nabble.com/Direct-register-access-control-of-GPIO-ARM-interface-on-Overo-Water-TOBI-SOLVED-td4965117.html) and a Verdex( http://gumstix.8.x6.nabble.com/GPIO-manipulation-from-a-user-space-C-program-td657129i40.html). This resulted in speeds of close to 430ns per cycle or ~2MHz which is right in the ball park for what I need.

My next problem though is due mostly to an unfamiliarity with building kernels.
According to jumpnow's  article on the button and LED controls (http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=80&Itemid=92) in order to use GPIO21 and GPIO22 as GPIO and not as LEDs (I will not be using an expansion board on the final implementation) I have to disable CONFIG_LEDS_GPIO in the kernel and rebuild it.

I have never built a kernel (though I have read through the yocto getting started) and as such am struggling with what exactly I need to do to disable CONFIG_LEDS_GPIO and would appreciate any information that can be provided.  While I'm in the process of modifying the kernel/u-boot parameters I would also like to disable/remove the Wi/Fi, Bluetooth, and Touch Screen configurations as we will only be using the console port and an ethernet connection and as fast a boot time as is possible is desired.

Thank you very much for all your input and advice!
Ben
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

Chris Whittenburg



On Thu, Jan 2, 2014 at 12:40 PM, bstromb <[hidden email]> wrote:
 
My next problem though is due mostly to an unfamiliarity with building
kernels.
According to jumpnow's  article on the button and LED controls
(http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=80&Itemid=92)
in order to use GPIO21 and GPIO22 as GPIO and not as LEDs (I will not be
using an expansion board on the final implementation) I have to disable
CONFIG_LEDS_GPIO in the kernel and rebuild it.

I have never built a kernel (though I have read through the yocto getting
started) and as such am struggling with what exactly I need to do to disable
CONFIG_LEDS_GPIO and would appreciate any information that can be provided.
While I'm in the process of modifying the kernel/u-boot parameters I would
also like to disable/remove the Wi/Fi, Bluetooth, and Touch Screen
configurations as we will only be using the console port and an ethernet
connection and as fast a boot time as is possible is desired.

I would just edit the board-overo file, which is a little different than what Scott talks about in that posting.  That would still leave the blue LED working.  I'm assuming you already worked thru the instructions on building the gumstix console image, listed here:


If that worked for you, then you can go into your build/tmp/overo-poky-linux-gnueabi/linux-gumstix-3.5-x directory.  In that directory is a "git" directory where the kernel source is built.  You want to modify the board-overo.c file, which is in arch/arm/mach-omap2.

Remove the references in the gpio_led_gpio_leds[] struct which relate to the gpio 21 and 22.  You can also disable some of the other items you mentioned in this same file. 

Now force a re-compile of the kernel with "bitbake -c compile -f virtual/kernel".  The new uImage file will be in git/arch/arm/boot.

If you want to get more involved, before you edit board-overo.c, you can do a "quilt new my-changes.patch" and "quilt add arch/arm/mach-omap2/board-overo.c" before you edit the file.  Then after editing, do a "quilt refresh" and you will end up with a patch file that can be added to the existing kernel recipe to always apply your changes before building the kernel.

-chris


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb
Chris, 

Thank you for getting back to me so quickly. I had not seen the specific instructions you posted though I had been through Scott's as well as many others and had become a little overwhelmed with OE and Yocto. 
I followed the manifest instructions and made it all the way to the bitbake stage before erroring out. I am using the latest stable image for repo.
 
As a disclaimer I am using Fedora19 and I see that it is not on the tested distribution list, however I don't believe the error I encountered has anything to do with that. 
When I ran ' bitbake gumstix-console-image' it loaded the cache (2027 from dependency cache)
Parsing recipes is listed as 100% however  the next line is 

Parsing of 1651 .bb files complete ( 1650 cached, 1 parsed). 2027 targets, 41 skipped, 0 masked, 0 errors. 
ERROR: No recipes available for:  / home/bstromberg/poky/meta-ros/recipes-support/boost/boost_1.54.0.bbappend
ERROR: Command execution failed: Exited with 1 

I followed the links to the quick start and know that I have all the necessary packages installed 
(sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath 
ccache perl-Data-Dumper perl-Text-ParseWords SDL-devel xterm) are the ones listed. 
I have successfully used the boost libraries with Wt without issue and while I tried to troubleshoot my way out I am still a novice and am unsure of how to proceed. 

Thank you again for your time and input,
Ben


On Thu, Jan 2, 2014 at 12:57 PM, Chris Whittenburg [via Gumstix] <[hidden email]> wrote:



On Thu, Jan 2, 2014 at 12:40 PM, bstromb <[hidden email]> wrote:
 
My next problem though is due mostly to an unfamiliarity with building
kernels.
According to jumpnow's  article on the button and LED controls
(http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=80&Itemid=92)
in order to use GPIO21 and GPIO22 as GPIO and not as LEDs (I will not be
using an expansion board on the final implementation) I have to disable
CONFIG_LEDS_GPIO in the kernel and rebuild it.

I have never built a kernel (though I have read through the yocto getting
started) and as such am struggling with what exactly I need to do to disable
CONFIG_LEDS_GPIO and would appreciate any information that can be provided.
While I'm in the process of modifying the kernel/u-boot parameters I would
also like to disable/remove the Wi/Fi, Bluetooth, and Touch Screen
configurations as we will only be using the console port and an ethernet
connection and as fast a boot time as is possible is desired.

I would just edit the board-overo file, which is a little different than what Scott talks about in that posting.  That would still leave the blue LED working.  I'm assuming you already worked thru the instructions on building the gumstix console image, listed here:


If that worked for you, then you can go into your build/tmp/overo-poky-linux-gnueabi/linux-gumstix-3.5-x directory.  In that directory is a "git" directory where the kernel source is built.  You want to modify the board-overo.c file, which is in arch/arm/mach-omap2.

Remove the references in the gpio_led_gpio_leds[] struct which relate to the gpio 21 and 22.  You can also disable some of the other items you mentioned in this same file. 

Now force a re-compile of the kernel with "bitbake -c compile -f virtual/kernel".  The new uImage file will be in git/arch/arm/boot.

If you want to get more involved, before you edit board-overo.c, you can do a "quilt new my-changes.patch" and "quilt add arch/arm/mach-omap2/board-overo.c" before you edit the file.  Then after editing, do a "quilt refresh" and you will end up with a patch file that can be added to the existing kernel recipe to always apply your changes before building the kernel.

-chris


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users



To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530), click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

Chris Whittenburg
On Thu, Jan 2, 2014 at 5:41 PM, bstromb <[hidden email]> wrote:

Parsing of 1651 .bb files complete ( 1650 cached, 1 parsed). 2027 targets, 41 skipped, 0 masked, 0 errors. 
ERROR: No recipes available for:  / home/bstromberg/poky/meta-ros/recipes-support/boost/boost_1.54.0.bbappend
ERROR: Command execution failed: Exited with 1 

Well, I did a fresh build, and got the same error.  I haven't looked into it much, but my first question would be why Gumstix added the meta-ros layer? 

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb
Chris, 
I still need to thank you for getting the ball rolling for me. It gave me an entry point and I very much appreciate that. 
I successfully built Scott's boot image ('pansenti-boot-image' though admittedly kernel 3.2 not 3.5) last night and am currently building his console image. Whether it succeeds or not, I now have a starting point and again greatly appreciate your help. 
Especially as you helped iron out my confusion over the next steps to open up the GPIO pins I need. 

Do I modify the pins MUX settings in the board-overo.c file as well or do I need to do that in uboot?

Thanks again,
Ben


On Fri, Jan 3, 2014 at 9:54 AM, Chris Whittenburg [via Gumstix] <[hidden email]> wrote:
On Thu, Jan 2, 2014 at 5:41 PM, bstromb <[hidden email]> wrote:

Parsing of 1651 .bb files complete ( 1650 cached, 1 parsed). 2027 targets, 41 skipped, 0 masked, 0 errors. 
ERROR: No recipes available for:  / home/bstromberg/poky/meta-ros/recipes-support/boost/boost_1.54.0.bbappend
ERROR: Command execution failed: Exited with 1 

Well, I did a fresh build, and got the same error.  I haven't looked into it much, but my first question would be why Gumstix added the meta-ros layer? 

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users



To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530), click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

Chris Whittenburg

On Fri, Jan 3, 2014 at 11:34 AM, bstromb <[hidden email]> wrote:

Do I modify the pins MUX settings in the board-overo.c file as well or do I need to do that in uboot?

I usually modify pinmux settings in uboot, but if you are just re-using the LED pins, they should already be configured as GPIO outputs.

 

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

Scott Ellis
In reply to this post by bstromb
meta-pansenti should build okay.

I pulled from all the upstream repos a week or so ago to upgrade to Yocto 1.4.3,
Poky 9.0.3.

I did have to add a bbappend for bc-native (meta-pansenti/recipes-extended)
because of an upstream Yocto kernel recipe dependency change.  But that was
the only issue I remember.

I built and booted all the images Overo, Duovero, BeagleBone and Wandboards
when I did.  I ran my standard test, the syntrolcam streaming video app and all
the boards worked fine (minus the normal BBB USB  detection flakiness).

I'm also working on some meta-pansenti derived layers right now and not
having any issues.

So if you do have problems, let me know and I'll try to help.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb
Scott,

I just this second got your boot image for the 3.2 kernel up and running on my gumstix after spending most the day fighting my development laptop to mount the sd card. Moved to my desktop and everything copied without incident.
However, I cannot ping outside my local network nor get opkg to find gcc or any other generic package (nano). ifconfig gives a valid IP address that is showing up on my router so I am at a bit of a loss why it would appear I have no network access. I may have shot myself in the foot though as I did modify the local.conf file in an attempt to get a faster boot.

I removed 'wifi' and 'screen' from the lines below as I am using direct ethernet connection and will not be using the touch screen. Would that likely cause my problem?
DISTRO_FEATURES = 'ext2 keyboard usbhost wifi ${DISTRO_FEATURES_LIBC}"
MACHINE_FEATURES_forcevariable = "ext2 screen serial usbhost"

I am currenlty re-running the bitbake pansenti-boot-image with 'wifi' and 'screen' added back into the local.conf and am hoping that is indeed my problem.

Should I be using the console image instead?
Thank you again to everyone for your input and advice. I recognize I am making a mess of things and greatly appreciate all the input and help I am getting.
Ben


On Fri, Jan 3, 2014 at 2:49 PM, Scott Ellis [via Gumstix] <[hidden email]> wrote:
meta-pansenti should build okay.

I pulled from all the upstream repos a week or so ago to upgrade to Yocto 1.4.3,
Poky 9.0.3.

I did have to add a bbappend for bc-native (meta-pansenti/recipes-extended)
because of an upstream Yocto kernel recipe dependency change.  But that was
the only issue I remember.

I built and booted all the images Overo, Duovero, BeagleBone and Wandboards
when I did.  I ran my standard test, the syntrolcam streaming video app and all
the boards worked fine (minus the normal BBB USB  detection flakiness).

I'm also working on some meta-pansenti derived layers right now and not
having any issues.

So if you do have problems, let me know and I'll try to help.



To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530), click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

Scott Ellis
Yes use the console image. The boot image is very minimal.

Your changes to the local.conf shouldn't make any difference and won't
help your boot time.

Boots should be around 10 seconds for the console image. Any longer then
that and it's because you have a slow microSD card. Fix that first ;-)

You can get a faster boot with some more intrusive changes, but I'd make
sure you get a 10 second boot with the vanilla image first.

You can use opkg from the console image. I've never tried pulling from
repos that were not my own, so you are on your own with that.

There is no guarantee that packages from someone else were built
with the same compiler assumptions in the meta-pansenti image.

It's not hard to setup you own package repository.

I typically build all the upstream packages I want directly into the image.

I only use opkg for updates in the field for custom software that we write.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

Scott Ellis
The pansenti-console-image has nano and the standard C/C++ tools.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb
Scott,

Thanks as always for the rapid responses, and even more so for your invaluable resources on jumpnow! I will follow your advice on the vanilla boot first. Is that ~10 seconds including the autoboot countdown?

I apologize for the length of this response and will try to group the topics.

I actually would love to use the Wt image as I am using Wt for our GUI on the system and have had great success with it and will need to install it regardless of the image used.  However my most recent attempt just now with the 3.2 kernel had 2 tasks fail. With 3.5 it also failed.
Summary: 2 tasks failed:
  /home/bstromberg/poky-dylan/meta-pansenti/recipes-misc/wt/wt_3.3.0.bb, do_patch
  /home/bstromberg/poky-dylan/meta/recipes-qt/qt4/qt4-embedded_4.8.4.bb, do_install

ERROR: Command Error: exit status: 1  Output:
Applying patch custom-cmakelists.patch
patching file CMakeLists.txt
Hunk #1 FAILED at 91.
1 out of 1 hunk FAILED -- rejects in file CMakeLists.txt
Patch custom-cmakelists.patch does not apply (enforce with -f)
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: /home/bstromberg/pansenti-overo/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/wt/3.3.0-3/temp/log.do_patch.30305
ERROR: Task 918 (/home/bstromberg/poky-dylan/meta-pansenti/recipes-misc/wt/wt_3.3.0.bb, do_patch) failed with exit code '1'

ERROR: Task 836 (/home/bstromberg/poky-dylan/meta/recipes-qt/qt4/qt4-embedded_4.8.4.bb, do_install) failed with exit code '1'

The note was that Attempted 1892 tasks which 1885 didn't need to be rerun and 2 failed. I was curious though if I am missing something in the build configuration as it shows blanks for meta-oe and meta.
BB_VERSION        = "1.18.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Fedora-19"
TARGET_SYS        = "arm-poky-linux-gnueabi"
MACHINE           = "overo"
DISTRO            = "poky"
DISTRO_VERSION    = "1.4.3"
TUNE_FEATURES     = "armv7a vfp neon"
TARGET_FPU        = "vfp-neon"
meta             
meta-yocto        = "dylan:eb3598d2480ca6b2a22d7b280906acb113abddc8"
meta-oe          
meta-networking   = "dylan:44754206632dd5b0725aeb43e99e4ff9e0245dca"
meta-fsl-arm      = "master:82907f64b32924854b63a342d9932d66f2dafe07"
meta-fsl-arm-extra = "master:50f73837d7ed8026ef9e31f1e0feba5e1427ccbf"
meta-gumstix      = "dylan:f10408773c2e81cc520c5a022c8bbe232a7b26aa"
common-bsp        = "master:b5c709b2b6bd3bf236df923fa8f245a00fbb1b60"
meta-pansenti     = "master:248dca95a45ef76e26f69c1cbdced915f43fd8da"


I then tried running the console image which errored out when using Kernel 3.5
| ERROR: oe_runmake failed
| ERROR: Function failed: do_install (see /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/temp/log.do_install.30983 for further information)
ERROR: Task 695 (/home/bstromberg/poky-dylan/meta-gumstix/recipes-kernel/linux/linux-gumstix_3.5.7.bb, do_install) failed with exit code '1'


But worked perfectly fine with Kernel 3.2 and I am transferring the files to the SD card as I type.

Lastly could you elaborate a little on the compiler assumption part of your comments on opkg. Previously with the generic angstrom image I had used opkg and a USB drive to install Wt, boost, and gcc/g++. Is that not going to be possible without building them into the image?

Thank you again so very much for your aid in this and for slogging through this nightmare of a post. I don't know how to repay it, but I owe you one haha
Ben


On Fri, Jan 3, 2014 at 3:51 PM, Scott Ellis [via Gumstix] <[hidden email]> wrote:
The pansenti-console-image has nano and the standard C/C++ tools.



To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530), click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

Scott Ellis
It's 10 seconds not including the u-boot countdown. You can
disable the countdown in u-boot environment when you are
done with development.

The Wt recipe was broken by an upstream commit at the end of
November. It was a CMakelist.txt change that broke a custom
patch of mine. I just now committed a fix for it to meta-pansenti.

(I have GraphicsMagic, Haru, Pango, Postgresql, MySQL and Qt4
modules disabled in my Wt build since we weren't using any of
them. I did a quick test and Wt built fine with those packages
enabled using the default CMakelist.txt in case you want to use
that instead.)

I also pulled the latest from Yocto and meta-fsl-arm as those both
got some minor commits last week. You already have those
commits.

After those changes the pansenti-wt-image built okay.

I posted  binaries here if you want to try them out before
you build yourself.

http://www.pansenti.com/overo

The kernel is 3.5.7

The pansenti images are what I consider developer images.
All include  gcc/g++ and associated tools and git. The qte image
includes the Qt4 headers and qmake. The wt image includes the
boost libraries that Wt needs, etc...

You might be able to use someone elses package repository.
They might not have built their packages with the same compiler
options  (hard/soft float for example) or with the same upstream
package versions that are on  your custom built system.

Also, there is no guarantee those same packages are going to be
there when you put together the second or third system. I prefer
to maintain my own  packages on a per project basis.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb

Scott,

Again a million thanks for all you have and continue to do :)

I don't actually need any of the packages that you disabled so that is a perfect binary for me :)

Would I be able to change the board overo file to open up pins 21, 22, and 23 as gpio and then recompile as per your instructions on jumpknow from those binaries or would I need to build it on my own first?

Thank you again for all your help.
Is managing your own packages and  repositories just keeping copies of them on your local machine so you still have them even if they change?

Ben

On Jan 4, 2014 3:06 AM, "Scott Ellis [via Gumstix]" <[hidden email]> wrote:
It's 10 seconds not including the u-boot countdown. You can
disable the countdown in u-boot environment when you are
done with development.

The Wt recipe was broken by an upstream commit at the end of
November. It was a CMakelist.txt change that broke a custom
patch of mine. I just now committed a fix for it to meta-pansenti.

(I have GraphicsMagic, Haru, Pango, Postgresql, MySQL and Qt4
modules disabled in my Wt build since we weren't using any of
them. I did a quick test and Wt built fine with those packages
enabled using the default CMakelist.txt in case you want to use
that instead.)

I also pulled the latest from Yocto and meta-fsl-arm as those both
got some minor commits last week. You already have those
commits.

After those changes the pansenti-wt-image built okay.

I posted  binaries here if you want to try them out before
you build yourself.

http://www.pansenti.com/overo

The kernel is 3.5.7

The pansenti images are what I consider developer images.
All include  gcc/g++ and associated tools and git. The qte image
includes the Qt4 headers and qmake. The wt image includes the
boost libraries that Wt needs, etc...

You might be able to use someone elses package repository.
They might not have built their packages with the same compiler
options  (hard/soft float for example) or with the same upstream
package versions that are on  your custom built system.

Also, there is no guarantee those same packages are going to be
there when you put together the second or third system. I prefer
to maintain my own  packages on a per project basis.





To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530), click here.
NAML
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

Scott Ellis
I haven't tried that stuff on my website for a few years so no guarantee,  
but this is the code from the board file I was suggesting you want to disable

==== from board-overo.c ====
...
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
#include <linux/leds.h>

static struct gpio_led gpio_leds[] = {
        {
                .name                   = "overo:red:gpio21",
                .default_trigger        = "heartbeat",
                .gpio                   = 21,
                .active_low             = true,
        },
        {
                .name                   = "overo:blue:gpio22",
                .default_trigger        = "none",
                .gpio                   = 22,
                .active_low             = true,
        },
        {
                .name                   = "overo:blue:COM",
                .default_trigger        = "mmc0",
                .gpio                   = -EINVAL,      /* gets replaced */
                .active_low             = true,
        },
};

static struct gpio_led_platform_data gpio_leds_pdata = {
        .leds           = gpio_leds,
        .num_leds       = ARRAY_SIZE(gpio_leds),
};

static struct platform_device gpio_leds_device = {
        .name   = "leds-gpio",
        .id     = -1,
        .dev    = {
                .platform_data  = &gpio_leds_pdata,
        },
};

static void __init overo_init_led(void)
{
        platform_device_register(&gpio_leds_device);
}

#else
static inline void __init overo_init_led(void) { return; }
#endif
...
========

The default kernel config has this
CONFIG_LEDS_GPIO=y

So if you change it to this
# CONFIG_LEDS_GPIO is not set

then the code will run the noop case.

If for some reason that doesn't work, there are other ways to get those
pins back as simple GPIO pins. As Chris indicated it's not a particularly
difficult thing to do.

After the change you do have to rebuild the kernel and then you'll want to
rebuild the image to get the new modules installed. You could copy over the
modules manually, but you don't want to be doing that all the time, so best
to just get it all done in one shot.

You really need to slog through building your system once though and
from then on tweaking things and doing rebuilds like this will be easy
and relatively quick.


I usually host the packages I want remotely upgradable on a public web server
I control putting the path to this server in a conf file in the /etc/opkg directory.

You could do it in a ROOTFS_POSTPROCESS_COMMAND in an image recipe
like this

...
wandboard_opkg_repo_setup() {
    echo src/gz symotes http://www.pansenti.com/ipk/wandboard > ${IMAGE_ROOTFS}/etc/opkg/symotes.conf
}

ROOTFS_POSTPROCESS_COMMAND_wandboard_quad += " \
    wandboard_opkg_repo_setup ; \
 "
...

I have a separate scripts that prep the packages I want placed on the server.

I should write up a HOWTO on this since I'm doing a little hand waving here.
It took some searching to figure it out the first time.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb
Scott,

Sorry to bother you again but I still had a failure on the Wt build for the Overo using the 3.5 kernel. I had started over and removed all the directories from my work machine for the builds and followed your webiste verbatim to get all the newest versions and ran into this error.

| make[1]: *** No rule to make target `/home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/./', needed by `/home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/ti_3410.fw'.  Stop.
| make[1]: *** Waiting for unfinished jobs....
|   MKDIR   /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/kaweth/
| make: *** [_modinst_post] Error 2
| ERROR: oe_runmake failed
| ERROR: Function failed: do_install (see /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/temp/log.do_install.10358 for further information)
ERROR: Task 708 (/home/bstromberg/poky-dylan/meta-gumstix/recipes-kernel/linux/linux-gumstix_3.5.7.bb, do_install) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1293 tasks of which 297 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

I checked the log cited and just found a copy of the same output.
I am now attempting to build the 3.2 version and hope that it succeeds.

Is there a chance that I'm running into issue because I used the getting started article on yocto/repo and have some type of build conflict? That seems a long shot as everything in the build stream references the panseti image, but if it fails I might just start over with the generic gumstix supplied kernel as I have been able to add in Wt and gcc/g++ and really need to just get access to those GPIO pins.

Thank you again for all your help in this process, it has been greatly appreciated!


On Sat, Jan 4, 2014 at 1:00 PM, Scott Ellis [via Gumstix] <[hidden email]> wrote:
I haven't tried that stuff on my website for a few years so no guarantee,  
but this is the code from the board file I was suggesting you want to disable

==== from board-overo.c ====
...
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
#include <linux/leds.h>

static struct gpio_led gpio_leds[] = {
        {
                .name                   = "overo:red:gpio21",
                .default_trigger        = "heartbeat",
                .gpio                   = 21,
                .active_low             = true,
        },
        {
                .name                   = "overo:blue:gpio22",
                .default_trigger        = "none",
                .gpio                   = 22,
                .active_low             = true,
        },
        {
                .name                   = "overo:blue:COM",
                .default_trigger        = "mmc0",
                .gpio                   = -EINVAL,      /* gets replaced */
                .active_low             = true,
        },
};

static struct gpio_led_platform_data gpio_leds_pdata = {
        .leds           = gpio_leds,
        .num_leds       = ARRAY_SIZE(gpio_leds),
};

static struct platform_device gpio_leds_device = {
        .name   = "leds-gpio",
        .id     = -1,
        .dev    = {
                .platform_data  = &gpio_leds_pdata,
        },
};

static void __init overo_init_led(void)
{
        platform_device_register(&gpio_leds_device);
}

#else
static inline void __init overo_init_led(void) { return; }
#endif
...
========

The default kernel config has this
CONFIG_LEDS_GPIO=y

So if you change it to this
# CONFIG_LEDS_GPIO is not set

then the code will run the noop case.

If for some reason that doesn't work, there are other ways to get those
pins back as simple GPIO pins. As Chris indicated it's not a particularly
difficult thing to do.

After the change you do have to rebuild the kernel and then you'll want to
rebuild the image to get the new modules installed. You could copy over the
modules manually, but you don't want to be doing that all the time, so best
to just get it all done in one shot.

You really need to slog through building your system once though and
from then on tweaking things and doing rebuilds like this will be easy
and relatively quick.


I usually host the packages I want remotely upgradable on a public web server
I control putting the path to this server in a conf file in the /etc/opkg directory.

You could do it in a ROOTFS_POSTPROCESS_COMMAND in an image recipe
like this

...
wandboard_opkg_repo_setup() {
    echo src/gz symotes http://www.pansenti.com/ipk/wandboard > ${IMAGE_ROOTFS}/etc/opkg/symotes.conf
}

ROOTFS_POSTPROCESS_COMMAND_wandboard_quad += " \
    wandboard_opkg_repo_setup ; \
 "
...

I have a separate scripts that prep the packages I want placed on the server.

I should write up a HOWTO on this since I'm doing a little hand waving here.
It took some searching to figure it out the first time.




To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530), click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb
In reply to this post by Scott Ellis
Looking back through our thread, do I need to do anything with the
'bbappend for bc-native (meta-pansenti/recipes-extended)' that you referenced?

I have learned a lot already and was ecstatic to get your console image up and running over the past couple days as it freed me up to developing the FPGA GPIO pin programs and I am much more confident in my programming than kernel building. I know I would be very lost without all you and Chris have suggested and am extremely thankful.
Ben


On Sun, Jan 5, 2014 at 4:52 PM, Benjamin Stromberg <[hidden email]> wrote:
Scott,

Sorry to bother you again but I still had a failure on the Wt build for the Overo using the 3.5 kernel. I had started over and removed all the directories from my work machine for the builds and followed your webiste verbatim to get all the newest versions and ran into this error.

| make[1]: *** No rule to make target `/home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/./', needed by `/home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/ti_3410.fw'.  Stop.
| make[1]: *** Waiting for unfinished jobs....
|   MKDIR   /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/kaweth/
| make: *** [_modinst_post] Error 2
| ERROR: oe_runmake failed
| ERROR: Function failed: do_install (see /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/temp/log.do_install.10358 for further information)
ERROR: Task 708 (/home/bstromberg/poky-dylan/meta-gumstix/recipes-kernel/linux/linux-gumstix_3.5.7.bb, do_install) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1293 tasks of which 297 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

I checked the log cited and just found a copy of the same output.
I am now attempting to build the 3.2 version and hope that it succeeds.

Is there a chance that I'm running into issue because I used the getting started article on yocto/repo and have some type of build conflict? That seems a long shot as everything in the build stream references the panseti image, but if it fails I might just start over with the generic gumstix supplied kernel as I have been able to add in Wt and gcc/g++ and really need to just get access to those GPIO pins.

Thank you again for all your help in this process, it has been greatly appreciated!


On Sat, Jan 4, 2014 at 1:00 PM, Scott Ellis [via Gumstix] <[hidden email]> wrote:
I haven't tried that stuff on my website for a few years so no guarantee,  
but this is the code from the board file I was suggesting you want to disable

==== from board-overo.c ====
...
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
#include <linux/leds.h>

static struct gpio_led gpio_leds[] = {
        {
                .name                   = "overo:red:gpio21",
                .default_trigger        = "heartbeat",
                .gpio                   = 21,
                .active_low             = true,
        },
        {
                .name                   = "overo:blue:gpio22",
                .default_trigger        = "none",
                .gpio                   = 22,
                .active_low             = true,
        },
        {
                .name                   = "overo:blue:COM",
                .default_trigger        = "mmc0",
                .gpio                   = -EINVAL,      /* gets replaced */
                .active_low             = true,
        },
};

static struct gpio_led_platform_data gpio_leds_pdata = {
        .leds           = gpio_leds,
        .num_leds       = ARRAY_SIZE(gpio_leds),
};

static struct platform_device gpio_leds_device = {
        .name   = "leds-gpio",
        .id     = -1,
        .dev    = {
                .platform_data  = &gpio_leds_pdata,
        },
};

static void __init overo_init_led(void)
{
        platform_device_register(&gpio_leds_device);
}

#else
static inline void __init overo_init_led(void) { return; }
#endif
...
========

The default kernel config has this
CONFIG_LEDS_GPIO=y

So if you change it to this
# CONFIG_LEDS_GPIO is not set

then the code will run the noop case.

If for some reason that doesn't work, there are other ways to get those
pins back as simple GPIO pins. As Chris indicated it's not a particularly
difficult thing to do.

After the change you do have to rebuild the kernel and then you'll want to
rebuild the image to get the new modules installed. You could copy over the
modules manually, but you don't want to be doing that all the time, so best
to just get it all done in one shot.

You really need to slog through building your system once though and
from then on tweaking things and doing rebuilds like this will be easy
and relatively quick.


I usually host the packages I want remotely upgradable on a public web server
I control putting the path to this server in a conf file in the /etc/opkg directory.

You could do it in a ROOTFS_POSTPROCESS_COMMAND in an image recipe
like this

...
wandboard_opkg_repo_setup() {
    echo src/gz symotes http://www.pansenti.com/ipk/wandboard > ${IMAGE_ROOTFS}/etc/opkg/symotes.conf
}

ROOTFS_POSTPROCESS_COMMAND_wandboard_quad += " \
    wandboard_opkg_repo_setup ; \
 "
...

I have a separate scripts that prep the packages I want placed on the server.

I should write up a HOWTO on this since I'm doing a little hand waving here.
It took some searching to figure it out the first time.




To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530), click here.
NAML


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb
In reply to this post by Scott Ellis
The 3.2 kernel failed as well on the same step (Error Task 708)
It also had two other Errors but did not list them in the error count at the end of the build.
ERROR: Function failed: do_install (see /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.2-r1/temp/log.do_install.15547 for further information)
ERROR: Logfile of failure stored in: /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.2-r1/temp/log.do_install.15547
I am assuming they are one and the same as the Task 708 is a do_install error.

The logfile has many many INSTALLs and the errors arise after INSTALL sound/usb/caiaq/snd-usb-caiaq.ko:
ERROR: Function failed: do_install (see /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.2-r1/temp/log.do_install.15547 for further information)
ERROR: Logfile of failure stored in: /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.2-r1/temp/log.do_install.15547


I'm building the console image to move forward for the time being.

Thanks again,
Ben


On Sun, Jan 5, 2014 at 4:57 PM, Benjamin Stromberg <[hidden email]> wrote:
Looking back through our thread, do I need to do anything with the
'bbappend for bc-native (meta-pansenti/recipes-extended)' that you referenced?

I have learned a lot already and was ecstatic to get your console image up and running over the past couple days as it freed me up to developing the FPGA GPIO pin programs and I am much more confident in my programming than kernel building. I know I would be very lost without all you and Chris have suggested and am extremely thankful.
Ben


On Sun, Jan 5, 2014 at 4:52 PM, Benjamin Stromberg <[hidden email]> wrote:
Scott,

Sorry to bother you again but I still had a failure on the Wt build for the Overo using the 3.5 kernel. I had started over and removed all the directories from my work machine for the builds and followed your webiste verbatim to get all the newest versions and ran into this error.

| make[1]: *** No rule to make target `/home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/./', needed by `/home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/ti_3410.fw'.  Stop.
| make[1]: *** Waiting for unfinished jobs....
|   MKDIR   /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/kaweth/
| make: *** [_modinst_post] Error 2
| ERROR: oe_runmake failed
| ERROR: Function failed: do_install (see /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/temp/log.do_install.10358 for further information)
ERROR: Task 708 (/home/bstromberg/poky-dylan/meta-gumstix/recipes-kernel/linux/linux-gumstix_3.5.7.bb, do_install) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1293 tasks of which 297 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

I checked the log cited and just found a copy of the same output.
I am now attempting to build the 3.2 version and hope that it succeeds.

Is there a chance that I'm running into issue because I used the getting started article on yocto/repo and have some type of build conflict? That seems a long shot as everything in the build stream references the panseti image, but if it fails I might just start over with the generic gumstix supplied kernel as I have been able to add in Wt and gcc/g++ and really need to just get access to those GPIO pins.

Thank you again for all your help in this process, it has been greatly appreciated!


On Sat, Jan 4, 2014 at 1:00 PM, Scott Ellis [via Gumstix] <[hidden email]> wrote:
I haven't tried that stuff on my website for a few years so no guarantee,  
but this is the code from the board file I was suggesting you want to disable

==== from board-overo.c ====
...
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
#include <linux/leds.h>

static struct gpio_led gpio_leds[] = {
        {
                .name                   = "overo:red:gpio21",
                .default_trigger        = "heartbeat",
                .gpio                   = 21,
                .active_low             = true,
        },
        {
                .name                   = "overo:blue:gpio22",
                .default_trigger        = "none",
                .gpio                   = 22,
                .active_low             = true,
        },
        {
                .name                   = "overo:blue:COM",
                .default_trigger        = "mmc0",
                .gpio                   = -EINVAL,      /* gets replaced */
                .active_low             = true,
        },
};

static struct gpio_led_platform_data gpio_leds_pdata = {
        .leds           = gpio_leds,
        .num_leds       = ARRAY_SIZE(gpio_leds),
};

static struct platform_device gpio_leds_device = {
        .name   = "leds-gpio",
        .id     = -1,
        .dev    = {
                .platform_data  = &gpio_leds_pdata,
        },
};

static void __init overo_init_led(void)
{
        platform_device_register(&gpio_leds_device);
}

#else
static inline void __init overo_init_led(void) { return; }
#endif
...
========

The default kernel config has this
CONFIG_LEDS_GPIO=y

So if you change it to this
# CONFIG_LEDS_GPIO is not set

then the code will run the noop case.

If for some reason that doesn't work, there are other ways to get those
pins back as simple GPIO pins. As Chris indicated it's not a particularly
difficult thing to do.

After the change you do have to rebuild the kernel and then you'll want to
rebuild the image to get the new modules installed. You could copy over the
modules manually, but you don't want to be doing that all the time, so best
to just get it all done in one shot.

You really need to slog through building your system once though and
from then on tweaking things and doing rebuilds like this will be easy
and relatively quick.


I usually host the packages I want remotely upgradable on a public web server
I control putting the path to this server in a conf file in the /etc/opkg directory.

You could do it in a ROOTFS_POSTPROCESS_COMMAND in an image recipe
like this

...
wandboard_opkg_repo_setup() {
    echo src/gz symotes http://www.pansenti.com/ipk/wandboard > ${IMAGE_ROOTFS}/etc/opkg/symotes.conf
}

ROOTFS_POSTPROCESS_COMMAND_wandboard_quad += " \
    wandboard_opkg_repo_setup ; \
 "
...

I have a separate scripts that prep the packages I want placed on the server.

I should write up a HOWTO on this since I'm doing a little hand waving here.
It took some searching to figure it out the first time.




To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530), click here.
NAML



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb
In reply to this post by Scott Ellis
Console with a 3.2 kernel had the same do_install failure (Task 708).


On Sun, Jan 5, 2014 at 10:51 PM, Benjamin Stromberg <[hidden email]> wrote:
The 3.2 kernel failed as well on the same step (Error Task 708)
It also had two other Errors but did not list them in the error count at the end of the build.
ERROR: Function failed: do_install (see /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.2-r1/temp/log.do_install.15547 for further information)
ERROR: Logfile of failure stored in: /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.2-r1/temp/log.do_install.15547
I am assuming they are one and the same as the Task 708 is a do_install error.

The logfile has many many INSTALLs and the errors arise after INSTALL sound/usb/caiaq/snd-usb-caiaq.ko:
ERROR: Function failed: do_install (see /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.2-r1/temp/log.do_install.15547 for further information)
ERROR: Logfile of failure stored in: /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.2-r1/temp/log.do_install.15547


I'm building the console image to move forward for the time being.

Thanks again,
Ben


On Sun, Jan 5, 2014 at 4:57 PM, Benjamin Stromberg <[hidden email]> wrote:
Looking back through our thread, do I need to do anything with the
'bbappend for bc-native (meta-pansenti/recipes-extended)' that you referenced?

I have learned a lot already and was ecstatic to get your console image up and running over the past couple days as it freed me up to developing the FPGA GPIO pin programs and I am much more confident in my programming than kernel building. I know I would be very lost without all you and Chris have suggested and am extremely thankful.
Ben


On Sun, Jan 5, 2014 at 4:52 PM, Benjamin Stromberg <[hidden email]> wrote:
Scott,

Sorry to bother you again but I still had a failure on the Wt build for the Overo using the 3.5 kernel. I had started over and removed all the directories from my work machine for the builds and followed your webiste verbatim to get all the newest versions and ran into this error.

| make[1]: *** No rule to make target `/home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/./', needed by `/home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/ti_3410.fw'.  Stop.
| make[1]: *** Waiting for unfinished jobs....
|   MKDIR   /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/image/lib/firmware/kaweth/
| make: *** [_modinst_post] Error 2
| ERROR: oe_runmake failed
| ERROR: Function failed: do_install (see /home/bstromberg/pansenti-overo/build/tmp/work/overo-poky-linux-gnueabi/linux-gumstix/3.5.7-r3/temp/log.do_install.10358 for further information)
ERROR: Task 708 (/home/bstromberg/poky-dylan/meta-gumstix/recipes-kernel/linux/linux-gumstix_3.5.7.bb, do_install) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1293 tasks of which 297 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

I checked the log cited and just found a copy of the same output.
I am now attempting to build the 3.2 version and hope that it succeeds.

Is there a chance that I'm running into issue because I used the getting started article on yocto/repo and have some type of build conflict? That seems a long shot as everything in the build stream references the panseti image, but if it fails I might just start over with the generic gumstix supplied kernel as I have been able to add in Wt and gcc/g++ and really need to just get access to those GPIO pins.

Thank you again for all your help in this process, it has been greatly appreciated!


On Sat, Jan 4, 2014 at 1:00 PM, Scott Ellis [via Gumstix] <[hidden email]> wrote:
I haven't tried that stuff on my website for a few years so no guarantee,  
but this is the code from the board file I was suggesting you want to disable

==== from board-overo.c ====
...
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
#include <linux/leds.h>

static struct gpio_led gpio_leds[] = {
        {
                .name                   = "overo:red:gpio21",
                .default_trigger        = "heartbeat",
                .gpio                   = 21,
                .active_low             = true,
        },
        {
                .name                   = "overo:blue:gpio22",
                .default_trigger        = "none",
                .gpio                   = 22,
                .active_low             = true,
        },
        {
                .name                   = "overo:blue:COM",
                .default_trigger        = "mmc0",
                .gpio                   = -EINVAL,      /* gets replaced */
                .active_low             = true,
        },
};

static struct gpio_led_platform_data gpio_leds_pdata = {
        .leds           = gpio_leds,
        .num_leds       = ARRAY_SIZE(gpio_leds),
};

static struct platform_device gpio_leds_device = {
        .name   = "leds-gpio",
        .id     = -1,
        .dev    = {
                .platform_data  = &gpio_leds_pdata,
        },
};

static void __init overo_init_led(void)
{
        platform_device_register(&gpio_leds_device);
}

#else
static inline void __init overo_init_led(void) { return; }
#endif
...
========

The default kernel config has this
CONFIG_LEDS_GPIO=y

So if you change it to this
# CONFIG_LEDS_GPIO is not set

then the code will run the noop case.

If for some reason that doesn't work, there are other ways to get those
pins back as simple GPIO pins. As Chris indicated it's not a particularly
difficult thing to do.

After the change you do have to rebuild the kernel and then you'll want to
rebuild the image to get the new modules installed. You could copy over the
modules manually, but you don't want to be doing that all the time, so best
to just get it all done in one shot.

You really need to slog through building your system once though and
from then on tweaking things and doing rebuilds like this will be easy
and relatively quick.


I usually host the packages I want remotely upgradable on a public web server
I control putting the path to this server in a conf file in the /etc/opkg directory.

You could do it in a ROOTFS_POSTPROCESS_COMMAND in an image recipe
like this

...
wandboard_opkg_repo_setup() {
    echo src/gz symotes http://www.pansenti.com/ipk/wandboard > ${IMAGE_ROOTFS}/etc/opkg/symotes.conf
}

ROOTFS_POSTPROCESS_COMMAND_wandboard_quad += " \
    wandboard_opkg_repo_setup ; \
 "
...

I have a separate scripts that prep the packages I want placed on the server.

I should write up a HOWTO on this since I'm doing a little hand waving here.
It took some searching to figure it out the first time.




To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530), click here.
NAML




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

Scott Ellis
Send me the log.do_install.15547 off list

When I last used Fedora (around 16 I think), I know there was a problem
with one of the default system tools that needed to be replaced to get
a good Yocto build. I forget the details and it may have been fixed long
ago. I'm using Ubuntu.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)

bstromb
Scott,

Sorry for the delay, I re-ran the Wt with 3.5 build to make sure I had the full selection of log files as I had been playing with 3.5 and 3.2 builds of console, boot, and Wt without success.

The warnings this time included a 'bad checksum' that I haven't seen before.
WARNING: Failed to fetch URL ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.0.26.tar.bz2, attempting MIRRORS if available
WARNING: Failed to fetch URL http://downloads.sourceforge.net/project/libpng/libpng16/1.6.0/libpng-1.6.0.tar.xz, attempting MIRRORS if available
WARNING: Checksum failure encountered with download of http://releases.qt-project.org/qt4/source/qt-everywhere-opensource-src-4.8.4.tar.gz - will attempt other sources if available
WARNING: Renaming /home/bstromberg/pansenti-overo/build/downloads/qt-everywhere-opensource-src-4.8.4.tar.gz to /home/bstromberg/pansenti-overo/build/downloads/qt-everywhere-opensource-src-4.8.4.tar.gz_bad-checksum_c56e090de833b0fa040b804ec177cebc
WARNING: Failed to fetch URL http://oss.metaparadigm.com/json-c/json-c-0.9.tar.gz, attempting MIRRORS if available

These are the only log files that were in the folder for the most recent attempted build of Wt with the 3.5 kernel. I couldn't find the 15547 you requested but hopefully the error one (13624) is what you need. The only local.conf setting I changed from the overo sample is for a 64 bit machine development machine vs. i386.  Could there be a bad build environment variable set from using the
TEMPLATECONF=meta-gumstix-extras/conf source ./poky/oe-init-build-env
that I started with (as per the gumstix 'how to' instructions) before using your jumpnow instructions ( I do run source oe from poky-dylan every time)?

There were more install files for the 3.2 but I had been trying boot, console, and wt there all failing the do_install. But again none that matched the 15547 you requested. 

I greatly appreciate your time and help as the boost_library failure for the generic angstrom image would have me dead in the water without your assistance.
I am re-partitioning a drive for a Ubuntu install as we speak. What current distro are you running?

Thanks again,
Ben


On Mon, Jan 6, 2014 at 3:56 AM, Scott Ellis [via Gumstix] <[hidden email]> wrote:
Send me the log.do_install.15547 off list

When I last used Fedora (around 16 I think), I know there was a problem
with one of the default system tools that needed to be replaced to get
a good Yocto build. I forget the details and it may have been fixed long
ago. I'm using Ubuntu.




To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530), click here.
NAML


log.do_install (14K) Download Attachment
log.do_install.11324 (14K) Download Attachment
log.do_install.13624 (14K) Download Attachment
run.do_install.11324 (15K) Download Attachment
run.do_install.13624 (15K) Download Attachment
12
Loading...