OK, so 0x27 is
- mode 7 - pullup/pulldown enabled - pulldown selected - reciever enabled /* meaning input I guess */ On Fri, Nov 27, 2015 at 11:10 PM, William Hermans <[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]> > 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]> 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]> 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]> >>> 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]> >>>> 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]> >>>>> 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 <[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]> 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 <[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 >>>>>>> >>> >>>>>>> >>> 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 <[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 >>>>>>> >>> --- >>>>>>> >>> 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. >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> -- >>>>>>> >>> 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. >>>>>>> >>> >>>>>>> >> >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Charles Steinkuehler >>>>>>> > [email protected] >>>>>>> > >>>>>>> > -- >>>>>>> > 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. >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> -- >>> 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. >>> >>> >>> -- >>> 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. >>> >> >> > -- 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.
