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




View this message in context: Re: Disabling led_gpio pins in kernel or U-boot on Overo Fire COM (Omap3530)
Sent from the Gumstix mailing list archive at Nabble.com.