$ sudo reboot

Broadcast message from root@beaglebone (pts/0) (Fri Nov 27 22:56:19 2015):
The system is going down for reboot NOW!

$ Agent has been released /* Ok wtf is this ?! Bluetooth agent ? */

login as: william
Debian GNU/Linux 7

BeagleBoard.org Debian Image 2015-03-01

Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

default username:password is [debian:temppwd]

william@192.168.254.167's password:
Last login: Wed Nov 25 23:21:15 2015 from <an IP address ;) >

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 00000027 pinctrl-single

WTF is going on here ? Anyhow seems like a bonafied bug ? Or is this the
default state in which pins come up as auto-magically ?

On Fri, Nov 27, 2015 at 10:55 PM, William Hermans <yyrk...@gmail.com> wrote:

> OK so I thought maybe I forgot to copy the newly compiled overlay over . .
> .
>
> $ ls |grep pin
> pinctrl-test-7-00A0.dtbo
> pinctrl-test-7.dts
>
> $ rm pin*
> $ ls |grep pin
> < No output >
>
> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
>
> /dts-v1/;
>
> / {
>     compatible = "ti,beaglebone", "ti,beaglebone-black";
>     part-number = "pinctrl-test-7";
>
>     fragment@0 {
>         target = <0xdeadbeef>;
>
>         __overlay__ {
>
>             pinctrl_test_7_pins {
>                 pinctrl-single,pins = <0x40 0x27>;
>                 linux,phandle = <0x1>;
>                 phandle = <0x1>;
>             };
>         };
>     };
>
>     fragment@1 {
>         target = <0xdeadbeef>;
>
>         __overlay__ {
>
>             helper {
>                 compatible = "gpio-of-helper";
>                 pinctrl-names = "default";
>                 pinctrl-0 = <0x1>;
>                 status = "okay";
>                 linux,phandle = <0x2>;
>                 phandle = <0x2>;
>             };
>         };
>     };
>
>     __symbols__ {
>         pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
>         test_helper = "/fragment@1/__overlay__/helper";
>     };
>
>     __local_fixups__ {
>
>         fragment@1 {
>
>             __overlay__ {
>
>                 helper {
>                     pinctrl-0 = <0x0>;
>                 };
>             };
>         };
>     };
>
>     __fixups__ {
>         am33xx_pinmux = "/fragment@0:target:0";
>         ocp = "/fragment@1:target:0";
>     };
> };
>
> Ok, so this source mangling seems odd, but just looking things over, it
> seems like it should work. Next, reboot, and reload, then see what happens.
>
> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans <yyrk...@gmail.com>
> wrote:
>
>> Smells of a bug. But perhaps the GPIO pinmux's need to be explicity
>> cleared as I mentioned above ?
>>
>> On Fri, Nov 27, 2015 at 10:39 PM, William Hermans <yyrk...@gmail.com>
>> wrote:
>>
>>> OK so I changed to this:
>>>
>>> fragment@0 {
>>>         target = <&am33xx_pinmux>;
>>>         __overlay__ {
>>>             pinctrl_test: pinctrl_test_7_pins {
>>>                 pinctrl-single,pins = <
>>>                     0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input
>>> Mode7 pullup
>>>                 >;
>>>             };
>>>         };
>>>     };
>>>
>>> Compiled, copied, and then loaded the dtbo file. Then . . .
>>>
>>> $ dmesg |grep pinctrl-test-7
>>> [168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
>>> version 'N/A'
>>> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
>>> Name,00A0,Override Manuf,pinctrl-test-7'
>>> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
>>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
>>> [169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
>>> version 'N/A'
>>> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board
>>> Name,00A0,Override Manuf,pinctrl-test-7'
>>> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo
>>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
>>>
>>> This shows that both device tree overlays have been sucessfully loaded.
>>> Despite the fact that the previously overwritten overlay was never
>>> unloaded. Then . . .
>>>
>>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>>> pin 16 (44e10840.0) 00000017 pinctrl-single
>>>
>>> So . . .
>>> i$ cat /sys/devices/platform/bone_capemgr/slots
>>>  0: PF----  -1
>>>  1: PF----  -1
>>>  2: PF----  -1
>>>  3: PF----  -1
>>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>>
>>> oops, two overlays loaded lets see wha thappens when first one is
>>> unloaded.
>>>
>>> $ sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"
>>> $ cat /sys/devices/platform/bone_capemgr/slots
>>>  0: PF----  -1
>>>  1: PF----  -1
>>>  2: PF----  -1
>>>  3: PF----  -1
>>>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>>> pin 16 (44e10840.0) 00000017 pinctrl-single
>>>
>>> Just as I thought, the original pinmux is persistent. So . . .
>>> $ sudo sh -c "echo '-5' > /sys/devices/platform/bone_capemgr/slots"
>>> $ cat /sys/devices/platform/bone_capemgr/slots
>>>  0: PF----  -1
>>>  1: PF----  -1
>>>  2: PF----  -1
>>>  3: PF----  -1
>>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>>> pin 16 (44e10840.0) 00000017 pinctrl-single
>>>
>>> Ok just as I expected. pinmux's are kept until explicitly changed. Let's
>>> try loading it again.
>>> $ sudo sh -c "echo 'pinctrl-test-7' >
>>> /sys/devices/platform/bone_capemgr/slots"
>>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>>> pin 16 (44e10840.0) 00000017 pinctrl-single
>>>
>>> Whoopsy . . ..
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Nov 27, 2015 at 10:26 PM, William Hermans <yyrk...@gmail.com>
>>> wrote:
>>>
>>>> Here is what I get by following
>>>> https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md,
>>>> and modifying it to reflect one of the pins Riley is using. So, what I
>>>> suggest is that Riley has an overlay loaded that has already claimed these
>>>> pins. Either by experimenting previously with different values, and not
>>>> unloading the previous overlay. Or An overlay unbeknownst to him. I'll
>>>> experiment now with changing up my overlay and see what happens. But the
>>>> only other option really is that something on Riley's system is broken.
>>>>
>>>> /*
>>>>  * Copyright (C) 2012 Texas Instruments Incorporated -
>>>> http://www.ti.com/
>>>>  *
>>>>  * This program is free software; you can redistribute it and/or modify
>>>>  * it under the terms of the GNU General Public License version 2 as
>>>>  * published by the Free Software Foundation.
>>>>  */
>>>> /dts-v1/;
>>>> /plugin/;
>>>>
>>>> / {
>>>>     compatible = "ti,beaglebone", "ti,beaglebone-black";
>>>>
>>>>     /* identification */
>>>>     part-number = "pinctrl-test-7";
>>>>
>>>>     fragment@0 {
>>>>         target = <&am33xx_pinmux>;
>>>>         __overlay__ {
>>>>             pinctrl_test: pinctrl_test_7_pins {
>>>>                 pinctrl-single,pins = <
>>>>                     0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48 Input
>>>> Mode7 pullup
>>>>                 >;
>>>>             };
>>>>         };
>>>>     };
>>>>
>>>>     fragment@1 {
>>>>         target = <&ocp>;
>>>>         __overlay__ {
>>>>             test_helper: helper {
>>>>                 compatible = "gpio-of-helper";
>>>>                 pinctrl-names = "default";
>>>>                 pinctrl-0 = <&pinctrl_test>;
>>>>                 status = "okay";
>>>>             };
>>>>         };
>>>>     };
>>>> };
>>>>
>>>>  $ dtc -O dtb -o pinctrl-test-7-00A0.dtbo -b 0 -@ pinctrl-test-7.dts
>>>>  $ sudo cp pinctrl-test-7-00A0.dtbo /lib/firmware/
>>>>  $ cat /sys/devices/platform/bone_capemgr/slots
>>>>  0: PF----  -1
>>>>  1: PF----  -1
>>>>  2: PF----  -1
>>>>  3: PF----  -1
>>>> $ sudo sh -c "echo 'pinctrl-test-7' >
>>>> /sys/devices/platform/bone_capemgr/slots"
>>>> $ cat /sys/devices/platform/bone_capemgr/slots
>>>> $ cat /sys/devices/platform/bone_capemgr/slots
>>>>  0: PF----  -1
>>>>  1: PF----  -1
>>>>  2: PF----  -1
>>>>  3: PF----  -1
>>>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>>> $ dmesg |grep pinctrl-test-7
>>>> [168784.685978] bone_capemgr bone_capemgr: part_number
>>>> 'pinctrl-test-7', version 'N/A'
>>>> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
>>>> Name,00A0,Override Manuf,pinctrl-test-7'
>>>> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
>>>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
>>>>
>>>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>>>> pin 16 (44e10840.0) 00000017 pinctrl-single
>>>>
>>>> On Fri, Nov 27, 2015 at 10:14 PM, John Syne <john3...@gmail.com> wrote:
>>>>
>>>>> I believe the pinmux gets setup in pinctrl_bind_pins() found in
>>>>> drivers/pinctrl.c.
>>>>>
>>>>> pinctrl_bind_pins() gets called by really_probe(), line 291 of
>>>>> drivers/dd.c and then calls the gpio_of_helper_probe on line 316 or 320, 
>>>>> so
>>>>> I don’t think this has anything to do with gpio-of-helper.c driver.
>>>>> Probably need to setup some debug statements in pinctrl_bind_pins() to see
>>>>> why this does not work.
>>>>>
>>>>> Regards,
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> > On Nov 27, 2015, at 7:25 PM, Charles Steinkuehler <
>>>>> char...@steinkuehler.net> wrote:
>>>>> >
>>>>> > I don't have time to dig into the full details, but IIRC this has
>>>>> > popped up before.  I don't think the gpio-of-helper driver actually
>>>>> > does anything (like setup the pinmux) if you're not actually
>>>>> > _exporting_ any gpios.  But I could be wrong...it's been a while
>>>>> since
>>>>> > I crawled through the code.
>>>>> >
>>>>> > Oh, and your pinmux settings don't match the comments.  If you really
>>>>> > want inputs with the pullup enabled, the value to use is 0x37, *NOT*
>>>>> > 0x17.  It's important to enable the gpio receive buffer (bit 0x20) or
>>>>> > you won't be able to read the value on the GPIO pin (IIRC it will
>>>>> > always return zero).  If you really want outputs and just didn't
>>>>> > update the comments, 0x17 is fine.
>>>>> >
>>>>> > On 11/27/2015 2:14 PM, Riley Porter wrote:
>>>>> >> Yes I am running:
>>>>> >>
>>>>> >> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
>>>>> >> GNU/Linux*
>>>>> >>
>>>>> >> I followed your instructions but still am at a loss.  I was able to
>>>>> update
>>>>> >> the device tree compiler and the kernel which is now:
>>>>> >>
>>>>> >> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50
>>>>> UTC 2015
>>>>> >> armv7l GNU/Linux*
>>>>> >>
>>>>> >> Perhaps describing my exact steps might shed some light on my screw
>>>>> up?
>>>>> >>
>>>>> >>
>>>>> >> *This is the device tree I am testing with:*
>>>>> >>
>>>>> >>
>>>>> >> /*
>>>>> >>> snip for space
>>>>> >>> */
>>>>> >>> /dts-v1/;
>>>>> >>> /plugin/;
>>>>> >>>
>>>>> >>> /{
>>>>> >>>       compatible = "ti,beaglebone", "ti,beaglebone-black";
>>>>> >>>       part-number = "EBB-GPIO-Example";
>>>>> >>>       version = "00A0";
>>>>> >>>
>>>>> >>>       fragment@0 {
>>>>> >>>             target = <&am33xx_pinmux>;
>>>>> >>>
>>>>> >>>
>>>>> >>>             __overlay__ {
>>>>> >>>                  ebb_example: EBB_GPIO_Example {
>>>>> >>>                        pinctrl-single,pins = <
>>>>> >>>
>>>>> >>>
>>>>> >>>                                /*=============  Inputs
>>>>> ================*/
>>>>> >>>                                0x070 0x17  // P9_11 PINS$28
>>>>> GPIO0_30 = 30
>>>>> >>> Input Mode7 pullup
>>>>> >>>                                0x078 0x17  // P9_12 PINS$30
>>>>> GPIO1_28 = 60
>>>>> >>> Input Mode7 pullup
>>>>> >>>                                0x074 0x17  // P9_13 PINS$29
>>>>> GPIO0_31 = 31
>>>>> >>> Input Mode7 pullup
>>>>> >>>                                0x048 0x17  // P9_14 PINS$18
>>>>> GPIO1_18 = 50
>>>>> >>> Input Mode7 pullup
>>>>> >>>                                0x040 0x17  // P9_15 PINS$16
>>>>> GPIO1_16 = 48
>>>>> >>> Input Mode7 pullup
>>>>> >>>                                0x04c 0x17  // P9_16 PINS$19
>>>>> GPIO1_19 = 51
>>>>> >>> Input Mode7 pullup
>>>>> >>>                                0x15c 0x17  // P9_17 PINS$87
>>>>> GPIO0_5  =  5
>>>>> >>> Input Mode7 pullup
>>>>> >>>                                0x158 0x17  // P9_18 PINS$86
>>>>> GPIO0_4  =  4
>>>>> >>> Input Mode7 pullup
>>>>> >>>
>>>>> >>>                                /* OUTPUT  GPIO(mode7) 0x07
>>>>> pulldown, 0x17
>>>>> >>> pullup, 0x?f no pullup/down */
>>>>> >>>                                /* INPUT   GPIO(mode7) 0x27
>>>>> pulldown, 0x37
>>>>> >>> pullup, 0x?f no pullup/down */
>>>>> >>>> ;
>>>>> >>>                  };
>>>>> >>>             };
>>>>> >>>       };
>>>>> >>>
>>>>> >>>       fragment@1 {
>>>>> >>>                target = <&ocp>;
>>>>> >>>                __overlay__ {
>>>>> >>>                        gpio_helper {
>>>>> >>>                                compatible = "gpio-of-helper";
>>>>> >>>                                status = "okay";
>>>>> >>>                                pinctrl-names = "default";
>>>>> >>>                                pinctrl-0 = <&ebb_example>;
>>>>> >>>                        };
>>>>> >>>                };
>>>>> >>>        };
>>>>> >>> };
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> I also removed ALL overlays from my system before doing this below.
>>>>> >> Here is my output from slots and a python program to get the pins i
>>>>> wrote:
>>>>> >>
>>>>> >> *root ~/bbb_stuff # **slots*
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> * 0: PF----  -1  1: PF----  -1  2: PF----  -1  3: PF----  -1  9:
>>>>> P-O-L-   0
>>>>> >> Override Board Name,00A0,Override Manuf,EBB-GPIO-Example*
>>>>> >>
>>>>> >> *root ~/bbb_stuff # ./getpins *
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> *==================================================Reading Pinux
>>>>> >> Pins==================================================*
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> *pin 16 (44e10840.0) 00000027 pinctrl-singlepin 18 (44e10848.0)
>>>>> 00000027
>>>>> >> pinctrl-singlepin 19 (44e1084c.0) 00000027 pinctrl-singlepin 28
>>>>> >> (44e10870.0) 00000017 pinctrl-singlepin 29 (44e10874.0) 00000027
>>>>> >> pinctrl-singlepin 30 (44e10878.0) 00000027 pinctrl-singlepin 86
>>>>> >> (44e10958.0) 00000027 pinctrl-singlepin 87 (44e1095c.0) 00000027
>>>>> >> pinctrl-single*
>>>>> >>
>>>>> >> You can clearly see I have requested them all to be 0x17?
>>>>> >>
>>>>> >> *Here are the alias's I am using:*
>>>>> >>
>>>>> >> *pins='cat
>>>>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins'**slots='cat
>>>>> >> /sys/devices/platform/bone_capemgr/slots'*
>>>>> >>
>>>>> >>
>>>>> >> *This is the command i used to compile the dt.*
>>>>> >> *dtc -O dtb -o EBB-GPIO-Example-00A0.dtbo -b 0 -@
>>>>> EBB-GPIO-Example.dts*
>>>>> >>
>>>>> >> *This is the command I used to install it:*
>>>>> >> *echo  EBB-GPIO-Example-00A0 >
>>>>> "/sys/devices/platform/bone_capemgr/slots"*
>>>>> >>
>>>>> >>
>>>>> >> *This is the dmesg output after installing the overlay:*
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> *[ 2629.259630] bone_capemgr bone_capemgr: part_number
>>>>> >> 'EBB-GPIO-Example-00A0', version 'N/A'[ 2629.259679] bone_capemgr
>>>>> >> bone_capemgr: slot #11: override[ 2629.259700] bone_capemgr
>>>>> bone_capemgr:
>>>>> >> Using override eeprom data at slot 11[ 2629.259722] bone_capemgr
>>>>> >> bone_capemgr: slot #11: 'Override Board Name,00A0,Override
>>>>> >> Manuf,EBB-GPIO-Example'[ 2629.271307] gpio-of-helper
>>>>> ocp:gpio_helper:
>>>>> >> ready[ 2629.271555] bone_capemgr bone_capemgr: slot #11: dtbo
>>>>> >> 'EBB-GPIO-Example-00A0.dtbo' loaded; overlay id #0*
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> So any help guys would be really appreciated!  I am thinking that I
>>>>> must be
>>>>> >> just doing something wrong.  Perhaps the example device tree I am
>>>>> using is
>>>>> >> outdated?  Would someone be willing to share with me a GPIO device
>>>>> tree
>>>>> >> that works with kernel 4.1?  Also I have tried the dt builder
>>>>> online:
>>>>> >>
>>>>> >>
>>>>> http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator#1gpiodto
>>>>> >>
>>>>> >> But this seems to not work also.  Thanks again everyone.
>>>>> >>
>>>>> >>
>>>>> >> Riley
>>>>> >>
>>>>> >> On Thu, Nov 26, 2015 at 2:13 PM, John Syne <john3...@gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >>> That is strange because it seems to be working for everyone else.
>>>>> What is
>>>>> >>> your kernel version?
>>>>> >>>
>>>>> >>> If you are using kernel version 4.1 or higher, then do the
>>>>> following on
>>>>> >>> your BBB
>>>>> >>>
>>>>> >>> git clone https://github.com/RobertCNelson/bb.org-overlays.git
>>>>> >>>
>>>>> >>> Follow the instructions readme.md file. My guess is you don’t
>>>>> have the
>>>>> >>> correct Device Tree Compiler, but this repo will install the
>>>>> correct
>>>>> >>> version.
>>>>> >>>
>>>>> >>> Regards,
>>>>> >>> John
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> On Nov 26, 2015, at 8:35 AM, Riley Porter <rileypor...@gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Hey guys,
>>>>> >>>
>>>>> >>> I have been fighting this for a few days now.  But it seems to me
>>>>> that no
>>>>> >>> matter what I do I cannot get the pinmux'ing to work when applying
>>>>> overlays
>>>>> >>> in debian.  I have tried 7.8 and 8.2 and either is really
>>>>> different.
>>>>> >>>
>>>>> >>> I was looking around to see if I was the only one in this boat and
>>>>> it
>>>>> >>> turns out I found a post on stack exchange that describes my issue
>>>>> >>> perfectly.
>>>>> >>>
>>>>> >>> Unfortunately the "answer" was to install angstrom.  I was hoping
>>>>> someone
>>>>> >>> on the list would have some secret answer as to why applying an
>>>>> overlay was
>>>>> >>> not changing the pinmux's?
>>>>> >>>
>>>>> >>> I would very much like to stick with debian but if the answer is
>>>>> go back
>>>>> >>> angstrom I guess I can live with that.
>>>>> >>>
>>>>> >>> Thanks
>>>>> >>>
>>>>> >>> --
>>>>> >>> For more options, visit http://beagleboard.org/discuss
>>>>> >>> ---
>>>>> >>> You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> >>> "BeagleBoard" group.
>>>>> >>> To unsubscribe from this group and stop receiving emails from it,
>>>>> send an
>>>>> >>> email to beagleboard+unsubscr...@googlegroups.com.
>>>>> >>> For more options, visit https://groups.google.com/d/optout.
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> For more options, visit http://beagleboard.org/discuss
>>>>> >>> ---
>>>>> >>> You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> >>> "BeagleBoard" group.
>>>>> >>> To unsubscribe from this group and stop receiving emails from it,
>>>>> send an
>>>>> >>> email to beagleboard+unsubscr...@googlegroups.com.
>>>>> >>> For more options, visit https://groups.google.com/d/optout.
>>>>> >>>
>>>>> >>
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Charles Steinkuehler
>>>>> > char...@steinkuehler.net
>>>>> >
>>>>> > --
>>>>> > For more options, visit http://beagleboard.org/discuss
>>>>> > ---
>>>>> > You received this message because you are subscribed to the Google
>>>>> Groups "BeagleBoard" group.
>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>> send an email to beagleboard+unsubscr...@googlegroups.com.
>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> For more options, visit http://beagleboard.org/discuss
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "BeagleBoard" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to