From: bstromb <bst...@gm...> - 2014-01-02 18:41:21
|
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 -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Chris W. <whi...@gm...> - 2014-01-02 19:53:09
|
On Thu, Jan 2, 2014 at 12:40 PM, bstromb <bst...@gm...> 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: https://github.com/gumstix/Gumstix-YoctoProject-Repo 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 |
From: Scott E. <sc...@ju...> - 2014-01-04 10:02:34
|
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. -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968506.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-06 16:21:23
|
I done goofed it up again even with ubuntu :/ Should I reinstall with distro 13.04? I didn't see it on their home download site ( I did see the 12.04 LTS though). ben@ubuntuDev:~/pansenti-overo/build$ bitbake pansenti-wt-image Pseudo is not present but is required, building this first before the main build WARNING: Host distribution "Ubuntu-13.10" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Loading cache: 100% |###################| ETA: 00:00:00 Loaded 1698 entries from dependency cache. Parsing recipes: 100% |####################| Time: 00:00:00 Parsing of 1340 .bb files complete (1328 cached, 12 parsed). 1709 targets, 156 skipped, 19 masked, 0 errors. ERROR: Command execution failed: Traceback (most recent call last): File "/home/ben/poky-dylan/bitbake/lib/bb/command.py", line 92, in runAsyncCommand self.cooker.updateCache() File "/home/ben/poky-dylan/bitbake/lib/bb/cooker.py", line 1341, in updateCache if not self.parser.parse_next(): File "/home/ben/poky-dylan/bitbake/lib/bb/cooker.py", line 1783, in parse_next self.shutdown() File "/home/ben/poky-dylan/bitbake/lib/bb/cooker.py", line 1753, in shutdown bb.codeparser.parser_cache_savemerge(self.cooker.configuration.data) File "/home/ben/poky-dylan/bitbake/lib/bb/codeparser.py", line 84, in parser_cache_savemerge codeparsercache.save_merge(d) File "/home/ben/poky-dylan/bitbake/lib/bb/cache.py", line 813, in save_merge extradata, version = p.load() ValueError: could not convert string to int On Mon, Jan 6, 2014 at 7:17 AM, Benjamin Stromberg <bst...@gm...>wrote: > I never would have found that so thank you again immensely! > > After this weekend I'm about ready to swear off ever even wearing one with > a nice suit again just because of the namesake haha. > > I have Ubuntu being installed on a separate partition as we speak :) > > > > On Mon, Jan 6, 2014 at 6:59 AM, Scott Ellis [via Gumstix] < > ml-...@n6...> wrote: > >> That's the problem. >> >> Trevor Woerner documented this here already >> >> http://gumstix.8.x6.nabble.com/yocto-build-notes-td4966774.html >> >> I believe I downgraded my Make version a few years ago when I >> encountered it. >> >> There are some patches to the Yocto recipes out there >> >> http://permalink.gmane.org/gmane.linux.embedded.yocto.meta-ti/27 >> >> I don't really want to incorporate them to try them. You could. >> >> Or... how special is running Fedora to you? ;-) >> >> Ubuntu 13.10 is still using make 3.81. I'm building on a 13.04 system. >> >> >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968523.html >> To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo >> Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> >> . >> NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >> > > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968526.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-02 23:42:09
|
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] < ml-...@n6...> wrote: > > > > On Thu, Jan 2, 2014 at 12:40 PM, bstromb <[hidden email]<http://user/SendEmail.jtp?type=node&node=4968489&i=0> > > 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: > > https://github.com/gumstix/Gumstix-YoctoProject-Repo > > 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] <http://user/SendEmail.jtp?type=node&node=4968489&i=1> > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968489.html > To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo > Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> > . > NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968492.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-04 19:00:26
|
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]" < ml-...@n6...> 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. > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968506.html > To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo > Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> > . > NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968507.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-01-06 16:40:32
|
I have a fresh 13.10 install on a laptop. Let me give it a try. -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968527.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Chris W. <whi...@gm...> - 2014-01-03 16:49:39
|
On Thu, Jan 2, 2014 at 5:41 PM, bstromb <bst...@gm...> 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? |
From: Scott E. <sc...@ju...> - 2014-01-04 19:58:07
|
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. -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968508.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-05 23:53:40
|
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] < ml-...@n6...> 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. > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968508.html > To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo > Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> > . > NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968510.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-05 23:57:56
|
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 <bst...@gm...>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] < > ml-...@n6...> 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. >> >> >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968508.html >> To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo >> Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> >> . >> NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >> > > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968511.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-06 05:52:32
|
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 <bst...@gm...>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 <bst...@gm...>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] < >> ml-...@n6...> 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. >>> >>> >>> >>> ------------------------------ >>> If you reply to this email, your message will be added to the >>> discussion below: >>> >>> http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968508.html >>> To unsubscribe from Disabling led_gpio pins in kernel or U-boot on >>> Overo Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> >>> . >>> NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >>> >> >> > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968512.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-01-06 17:31:35
|
Maybe it's just not meant to be for you ;-) It's building fine here. Ubuntu 13.10 64-bit. Did you do the sudo dpgk-reconfigure dash thing to change the default shell to bash? I'd already done that so I didn't check the error if any if you don't do that. -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968528.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-03 17:35:26
|
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] < ml-...@n6...> wrote: > On Thu, Jan 2, 2014 at 5:41 PM, bstromb <[hidden email]<http://user/SendEmail.jtp?type=node&node=4968496&i=0> > > 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] <http://user/SendEmail.jtp?type=node&node=4968496&i=1> > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968496.html > To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo > Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> > . > NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968497.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Chris W. <whi...@gm...> - 2014-01-03 19:21:31
|
On Fri, Jan 3, 2014 at 11:34 AM, bstromb <bst...@gm...> 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. |
From: bstromb <bst...@gm...> - 2014-01-06 07:02:53
|
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 <bst...@gm...>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 <bst...@gm...>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 <bst...@gm...>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] < >>> ml-...@n6...> 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. >>>> >>>> >>>> >>>> ------------------------------ >>>> If you reply to this email, your message will be added to the >>>> discussion below: >>>> >>>> http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968508.html >>>> To unsubscribe from Disabling led_gpio pins in kernel or U-boot on >>>> Overo Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> >>>> . >>>> NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >>>> >>> >>> >> > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968513.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-06 17:45:26
|
It's only frustrating in that I have the mmap program ready to go. Not for me is a tough one to swallow and even harder on a work project haha I did do that dpkg actually. Total bummer. I'll check yocto and your sight again to make sure I have all necessary packages. On Jan 6, 2014 10:35 AM, "Scott Ellis [via Gumstix]" < ml-...@n6...> wrote: > Maybe it's just not meant to be for you ;-) > > It's building fine here. Ubuntu 13.10 64-bit. > > Did you do the sudo dpgk-reconfigure dash thing to change the default > shell to bash? > > I'd already done that so I didn't check the error if any if you don't do > that. > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968528.html > To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo > Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> > . > NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968529.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-01-03 21:47:00
|
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. -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968499.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-01-06 10:53:52
|
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. -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968517.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-01-06 17:50:27
|
Contact me off list. I'll send you the package list for everything installed on my workstation and you can compare. scott at pansenti dot com -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968530.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-15 17:52:52
|
Scott, I'm very happy to report that I successfully got our FPGA to boot from my userspace c code on Monday :) Thank you so very much for all your continued help in this process. While I know I have not setup my own source environment or anything yet I feel I have learned a great deal and it is all due to your help. Thank you thank you thank you a million times over. If people on the list would like the code I can copy it up as mmap is very straightforward and it is not that large a code snippet. I was going to try and use similar (mmap) code to access the gpmc cs6 channel as the fpga is tied into those lines, but keep reading online about people writing kernel drivers. Is it necessary to use Steve Sakohman's board file that I keep finding all over the interwebs or can I just change the pin muxing and then use mmap? Ben On Mon, Jan 6, 2014 at 10:53 AM, Scott Ellis [via Gumstix] < ml-...@n6...> wrote: > Contact me off list. I'll send you the package list for everything > installed > on my workstation and you can compare. > scott at pansenti dot com > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968530.html > To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo > Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> > . > NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968578.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-03 22:24:31
|
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] < ml-...@n6...> 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. > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968499.html > To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo > Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> > . > NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968500.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bstromb <bst...@gm...> - 2014-01-06 12:14:47
|
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] < ml-...@n6...> 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. > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968517.html > To unsubscribe from Disabling led_gpio pins in kernel or U-boot on Overo > Fire COM (Omap3530), click here<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4968488&code=YnN0cm9tYjIxQGdtYWlsLmNvbXw0OTY4NDg4fC00NTg0OTA2NQ==> > . > NAML<http://gumstix.8.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > log.do_install (14K) <http://gumstix.8.x6.nabble.com/attachment/4968519/0/log.do_install> log.do_install.11324 (14K) <http://gumstix.8.x6.nabble.com/attachment/4968519/1/log.do_install.11324> log.do_install.13624 (14K) <http://gumstix.8.x6.nabble.com/attachment/4968519/2/log.do_install.13624> run.do_install.11324 (15K) <http://gumstix.8.x6.nabble.com/attachment/4968519/3/run.do_install.11324> run.do_install.13624 (15K) <http://gumstix.8.x6.nabble.com/attachment/4968519/4/run.do_install.13624> -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968519.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-01-03 22:45:57
|
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. -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968501.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2014-01-06 13:30:18
|
What version of make is installed? For example on my system scott@hex:~/Projects/enable_arm_pmu/ko$ make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for x86_64-pc-linux-gnu -- View this message in context: http://gumstix.8.x6.nabble.com/Disabling-led-gpio-pins-in-kernel-or-U-boot-on-Overo-Fire-COM-Omap3530-tp4968488p4968521.html Sent from the Gumstix mailing list archive at Nabble.com. |