Yeah, you are right, but he also tested on 870, which doesn’t have this conflict. I’m just trying to avoid any other problems that might influence this issue.
Regards, John > On Nov 27, 2015, at 10:22 PM, William Hermans <[email protected]> wrote: > > As per Riley's overlay source, I only copy pasted it. But changed the pinmux > from 0x17, to 0x27 as a test. > > 0x040 0x27 // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pullup > > On Fri, Nov 27, 2015 at 11:18 PM, John Syne <[email protected] > <mailto:[email protected]>> wrote: > P9_15A 16 0x840/040 GPIO1_16 48 > P9_15B 34 0x888/088 GPIO1_16 64 > > Regards, > John > > > > >> On Nov 27, 2015, at 10:10 PM, William Hermans <[email protected] >> <mailto:[email protected]>> wrote: >> >> Or, more correctly I suppose . . . >> >> Pin value = 32 * GPIO bank + pin number. >> >> Where. . . >> >> GPIO Bank == 0-3 >> Pin number == 0-31 >> >> On Fri, Nov 27, 2015 at 11:07 PM, William Hermans <[email protected] >> <mailto:[email protected]>> wrote: >> BTW, 840 is connected to 888, so that pin might not be the best pin to test. >> Either way, I don’t understand why the Overlay manager doesn’t complain >> about a pin conflict. >> >> Ok you're going to have to explain that. Since the pin I checked changed. >> And I've always understood that . . . 32*<GPIO bank >+<GPIO bank pin #>=pin >> value >> >> On Fri, Nov 27, 2015 at 11:03 PM, John Syne <[email protected] >> <mailto:[email protected]>> wrote: >> Hi William, >> >> I think you are right, there must be some sort of conflict on Riley’s >> system. BTW, 840 is connected to 888, so that pin might not be the best pin >> to test. Either way, I don’t understand why the Overlay manager doesn’t >> complain about a pin conflict. >> >> Regards, >> John >> >> >> >> >>> On Nov 27, 2015, at 9:55 PM, William Hermans <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> Here is what I get by following >>> https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md >>> >>> <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/ >>> <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 <[email protected] >>> <mailto:[email protected]>> 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 >>> > <[email protected] <mailto:[email protected]>> 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 >>> >> >>> >> <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 <[email protected] >>> >> <mailto:[email protected]>> 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 >>> >>> <https://github.com/RobertCNelson/bb.org-overlays.git> >>> >>> >>> >>> Follow the instructions readme.md <http://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 <[email protected] >>> >>> <mailto:[email protected]>> 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 >>> >>> <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 [email protected] >>> >>> <mailto:beagleboard%[email protected]>. >>> >>> For more options, visit https://groups.google.com/d/optout >>> >>> <https://groups.google.com/d/optout>. >>> >>> >>> >>> >>> >>> -- >>> >>> For more options, visit http://beagleboard.org/discuss >>> >>> <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 [email protected] >>> >>> <mailto:beagleboard%[email protected]>. >>> >>> For more options, visit https://groups.google.com/d/optout >>> >>> <https://groups.google.com/d/optout>. >>> >>> >>> >> >>> > >>> > >>> > -- >>> > Charles Steinkuehler >>> > [email protected] <mailto:[email protected]> >>> > >>> > -- >>> > For more options, visit http://beagleboard.org/discuss >>> > <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 [email protected] >>> > <mailto:beagleboard%[email protected]>. >>> > For more options, visit https://groups.google.com/d/optout >>> > <https://groups.google.com/d/optout>. >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> <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 [email protected] >>> <mailto:beagleboard%[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >>> >>> >>> >>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> <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 [email protected] >>> <mailto:[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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 [email protected] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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 [email protected] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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 [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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 [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
