I'm not 100% sure if the above mentioned items can play a role on your error messages. It is simply a guess. I would not think the kernel / kernel modules should be a problem here. But I suppose they could be. However, with that said.
$ cat /var/log/syslog Nov 24 06:25:11 beaglebone rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1984" x-info="http://www.rsyslog.com";] rsyslogd was HUPed Nov 24 07:17:01 beaglebone /USR/SBIN/CRON[3560]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Nov 24 08:17:01 beaglebone /USR/SBIN/CRON[3573]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Nov 24 09:17:01 beaglebone /USR/SBIN/CRON[3586]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Nov 24 10:17:01 beaglebone /USR/SBIN/CRON[3599]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Nov 24 11:17:01 beaglebone /USR/SBIN/CRON[3613]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Nov 24 12:17:01 beaglebone /USR/SBIN/CRON[3626]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Nov 24 13:17:01 beaglebone /USR/SBIN/CRON[3637]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Nov 24 14:17:01 beaglebone /USR/SBIN/CRON[3645]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Nov 24 15:17:01 beaglebone /USR/SBIN/CRON[3652]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) So, can you give me an order of things you've done in order to get you error messages, and I'll try to duplicate them. Short of installing more stuff on my rootfs, which is already large enough as it is . . . On Tue, Nov 24, 2015 at 3:50 PM, William Hermans <[email protected]> wrote: > Which file system are you using ? Whats the output of . . . > > $ cat /etc/dogtag > BeagleBoard.org Debian Image 2015-03-01 > > So keep this in mind. My base debian rootsfs is Wheezy 7.8. I also disable > systemd through uEnv.txt. So I use SYSV versus systemd as an init daemon. > > > > On Tue, Nov 24, 2015 at 3:19 PM, Erik Stauber <[email protected]> > wrote: > >> Those systemd-udevd entries appear as soon as the pru is enabled with the >> device tree overlay.. totally independant of my program that later utilizes >> the PRU. >> >> Erik >> >> On Tuesday, November 24, 2015 at 2:06:36 PM UTC-8, William Hermans wrote: >>> >>> You're not firing an interrupt every program loop are you ? >>> >>> On Tue, Nov 24, 2015 at 2:54 PM, William Hermans <[email protected]> >>> wrote: >>> >>>> Just tell me in high level terms what your program loop does. >>>> >>>> On Tue, Nov 24, 2015 at 2:52 PM, William Hermans <[email protected]> >>>> wrote: >>>> >>>>> *William, * >>>>>> >>>>>> *Have you seen this.... when I enable the PRU with a device tree >>>>> overlay, I get this if I type top: (something to do with the interrupts >>>>> taking up tons of CPU)* >>>>> >>>>> >>>>> No I haven't, since I have not been looking. Perhaps the interrupts >>>>> can be disabled ? I'll have to look into it, but I do not really have any >>>>> code / binaries built to use both PRUs. What are you doing exactly ? >>>>> >>>>> On Tue, Nov 24, 2015 at 2:23 PM, Erik Stauber <[email protected]> >>>>> wrote: >>>>> >>>>>> William, >>>>>> >>>>>> Have you seen this.... when I enable the PRU with a device tree >>>>>> overlay, I get this if I type *top*: (something to do with the >>>>>> interrupts taking up tons of CPU) >>>>>> >>>>>> >>>>>> >>>>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ >>>>>> COMMAND >>>>>> 678 root 20 0 72872 21368 6372 S 11.2 4.2 0:03.56 >>>>>> node >>>>>> 687 root 20 0 11324 2252 1552 R 6.2 0.4 0:00.43 >>>>>> systemd-udevd >>>>>> 691 root 20 0 11324 1644 948 R 6.2 0.3 0:00.42 >>>>>> systemd-udevd >>>>>> 692 root 20 0 11324 1644 948 R 6.2 0.3 0:00.41 >>>>>> systemd-udevd >>>>>> 685 root 20 0 11324 2312 1612 R 5.9 0.5 0:00.43 >>>>>> systemd-udevd >>>>>> 686 root 20 0 11324 2252 1552 R 5.9 0.4 0:00.43 >>>>>> systemd-udevd >>>>>> 689 root 20 0 11324 2188 1488 R 5.9 0.4 0:00.43 >>>>>> systemd-udevd >>>>>> 690 root 20 0 11324 2188 1488 R 5.9 0.4 0:00.42 >>>>>> systemd-udevd >>>>>> 693 root 20 0 11324 1644 948 R 5.9 0.3 0:00.41 >>>>>> systemd-udevd >>>>>> 680 root 20 0 8076 3524 3040 S 3.6 0.7 0:00.23 >>>>>> laserlux >>>>>> 3 root 20 0 0 0 0 R 2.6 0.0 0:00.37 >>>>>> ksoftirqd/0 >>>>>> 103 root 20 0 0 0 0 S 0.3 0.0 0:00.04 >>>>>> usb-storage >>>>>> 696 root 20 0 2980 1644 1288 R 0.3 0.3 0:00.06 top >>>>>> 1 root 20 0 21836 3204 2120 S 0.0 0.6 0:06.05 >>>>>> systemd >>>>>> 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 >>>>>> kthreadd >>>>>> 4 root 20 0 0 0 0 S 0.0 0.0 0:00.02 >>>>>> kworker/0:0 >>>>>> 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 >>>>>> kworker/0:0H >>>>>> 6 root 20 0 0 0 0 S 0.0 0.0 0:00.33 >>>>>> kworker/u2:0 >>>>>> 7 root rt 0 0 0 0 S 0.0 0.0 0:00.00 >>>>>> watchdog/0 >>>>>> 8 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 >>>>>> khelper >>>>>> 9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 >>>>>> kdevtmpfs >>>>>> 10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 >>>>>> netns >>>>>> 11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 >>>>>> kswork >>>>>> 12 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 >>>>>> perf >>>>>> 13 root 20 0 0 0 0 S 0.0 0.0 0:00.04 >>>>>> kworker/0:1 >>>>>> 14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 >>>>>> khungtaskd >>>>>> 15 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 >>>>>> writeback >>>>>> 16 root 25 5 0 0 0 S 0.0 0.0 0:00.00 >>>>>> ksmd >>>>>> 17 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 >>>>>> crypto >>>>>> 18 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 >>>>>> kintegrityd >>>>>> 19 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 >>>>>> bioset >>>>>> 20 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 >>>>>> kblockd >>>>>> >>>>>> >>>>>> Then after a couple minutes, those processes disappear and this >>>>>> appears in /var/log/syslog >>>>>> >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [679] >>>>>> /devices/platform/ocp/4a300000.pruss/uio/uio0 timeout; kill it >>>>>> Nov 24 13:15:15 beaglebone rsyslogd-2007: action 'action 17' >>>>>> suspended, next retry is Tue Nov 24 13:15:45 2015 [try >>>>>> http://www.rsyslog.com/e/2007 ] >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: seq 2030 >>>>>> '/devices/platform/ocp/4a300000.pruss/uio/uio0' killed >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [680] >>>>>> /devices/platform/ocp/4a300000.pruss/uio/uio1 timeout; kill it >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: seq 2036 >>>>>> '/devices/platform/ocp/4a300000.pruss/uio/uio1' killed >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [681] >>>>>> /devices/platform/ocp/4a300000.pruss/uio/uio2 timeout; kill it >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: seq 2037 >>>>>> '/devices/platform/ocp/4a300000.pruss/uio/uio2' killed >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [683] >>>>>> /devices/platform/ocp/4a300000.pruss/uio/uio3 timeout; kill it >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: seq 2038 >>>>>> '/devices/platform/ocp/4a300000.pruss/uio/uio3' killed >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [684] >>>>>> /devices/platform/ocp/4a300000.pruss/uio/uio4 timeout; kill it >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: seq 2039 >>>>>> '/devices/platform/ocp/4a300000.pruss/uio/uio4' killed >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [685] >>>>>> /devices/platform/ocp/4a300000.pruss/uio/uio5 timeout; kill it >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: seq 2040 >>>>>> '/devices/platform/ocp/4a300000.pruss/uio/uio5' killed >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [686] >>>>>> /devices/platform/ocp/4a300000.pruss/uio/uio6 timeout; kill it >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: seq 2041 >>>>>> '/devices/platform/ocp/4a300000.pruss/uio/uio6' killed >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [687] >>>>>> /devices/platform/ocp/4a300000.pruss/uio/uio7 timeout; kill it >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: seq 2042 >>>>>> '/devices/platform/ocp/4a300000.pruss/uio/uio7' killed >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [681] >>>>>> terminated by signal 9 (Killed) >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [683] >>>>>> terminated by signal 9 (Killed) >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [679] >>>>>> terminated by signal 9 (Killed) >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [680] >>>>>> terminated by signal 9 (Killed) >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [684] >>>>>> terminated by signal 9 (Killed) >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [685] >>>>>> terminated by signal 9 (Killed) >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [686] >>>>>> terminated by signal 9 (Killed) >>>>>> Nov 24 13:15:15 beaglebone systemd-udevd[172]: worker [687] >>>>>> terminated by signal 9 (Killed) >>>>>> Nov 24 13:16:10 beaglebone systemd-timesyncd[209]: >>>>>> interval/delta/delay/jitter/drift 256s/-0.005s/0.075s/0.261s/-34ppm >>>>>> Nov 24 13:16:10 beaglebone rsyslogd-2007: action 'action 17' >>>>>> suspended, next retry is Tue Nov 24 13:16:40 2015 [try >>>>>> http://www.rsyslog.com/e/2007 ] >>>>>> Nov 24 13:16:56 beaglebone rsyslogd-2007: action 'action 17' >>>>>> suspended, next retry is Tue Nov 24 13:17:26 2015 [try >>>>>> http://www.rsyslog.com/e/2007 ] >>>>>> Nov 24 13:17:01 beaglebone CRON[1650]: (root) CMD ( cd / && >>>>>> run-parts --report /etc/cron.hourly) >>>>>> >>>>>> >>>>>> What's odd is my program continues to operate normally, and is using >>>>>> both PRU0 and PRU1 interrupts.. >>>>>> >>>>>> Erik >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Monday, November 23, 2015 at 12:03:04 PM UTC-8, William Hermans >>>>>> wrote: >>>>>>> >>>>>>> Micka, >>>>>>> >>>>>>> TI 4.x kernels will not work with "traditional" PRU stuff. TI >>>>>>> kernels have remoteproc enabled. . . which takes over the PRU in a >>>>>>> different way. >>>>>>> >>>>>>> On Mon, Nov 23, 2015 at 9:41 AM, Micka <[email protected]> wrote: >>>>>>> >>>>>>>> Hi, did you managed to make this kernel working with the PRU ? >>>>>>>> Because I got that : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.mail-archive.com/[email protected]/msg32826.html >>>>>>>> >>>>>>>> >>>>>>>> Micka, >>>>>>>> >>>>>>>> Le lun. 23 nov. 2015 17:38, Erik Stauber <[email protected]> a >>>>>>>> écrit : >>>>>>>> >>>>>>>>> William, >>>>>>>>> >>>>>>>>> I installed the 4.1.13-bone-rt-r16 kernel, and the /dev/uioX >>>>>>>>> entires showed up. I guess I'll try using this one. Thanks for the >>>>>>>>> help! >>>>>>>>> >>>>>>>>> Erik >>>>>>>>> >>>>>>>>> >>>>>>>>> On Saturday, November 21, 2015 at 9:44:14 PM UTC-8, William >>>>>>>>> Hermans wrote: >>>>>>>>> >>>>>>>>>> By the way, I had to make my own device tree overlay for the PRU. >>>>>>>>>> It's pretty simple. . . . >>>>>>>>>> >>>>>>>>>> /dts-v1/; >>>>>>>>>> /plugin/; >>>>>>>>>> >>>>>>>>>> / { >>>>>>>>>> compatible = "ti,beaglebone", "ti,beaglebone-black"; >>>>>>>>>> >>>>>>>>>> /* identification */ >>>>>>>>>> part-number = "pru_enable"; >>>>>>>>>> version = "00A0"; >>>>>>>>>> >>>>>>>>>> fragment@0 { >>>>>>>>>> target = <&pruss>; >>>>>>>>>> __overlay__ { >>>>>>>>>> status = "okay"; >>>>>>>>>> >>>>>>>>>> }; >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> $ dtc -O dtb -o pru_enable-00A0.dtbo -b 0 -@ pru_enable-00A0.dts >>>>>>>>>> $ sudo cp pru_enable-00A0.dtbo /lib/firmware/ >>>>>>>>>> $ sudo sh -c "echo 'pru_enable' > >>>>>>>>>> /sys/devices/platform/bone_capemgr/slots" >>>>>>>>>> $ dmesg | grep pru_enable >>>>>>>>>> [ 886.921624] bone_capemgr bone_capemgr: part_number >>>>>>>>>> 'pru_enable', version 'N/A' >>>>>>>>>> [ 886.941686] bone_capemgr bone_capemgr: slot #6: 'Override >>>>>>>>>> Board Name,00A0,Override Manuf,pru_enable' >>>>>>>>>> [ 886.981959] bone_capemgr bone_capemgr: slot #6: dtbo >>>>>>>>>> 'pru_enable-00A0.dtbo' loaded; overlay id #0 >>>>>>>>>> >>>>>>>>>> On Sat, Nov 21, 2015 at 10:36 PM, William Hermans < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>> bone-rt has real time enhancements. I do not know all the >>>>>>>>>>> differences, but the kernel latency seems to be reduced. >>>>>>>>>>> >>>>>>>>>>> Anyway, you do not see what ? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Sat, Nov 21, 2015 at 7:08 PM, Erik Stauber < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> hmmm, i don't see that on 4.1.13-bone16. Maybe I need to use >>>>>>>>>>>> 4.1.13-bone-rt-r16? What is the difference between the bone and >>>>>>>>>>>> bone-rt? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Friday, November 20, 2015 at 2:26:38 PM UTC-8, William >>>>>>>>>>>> Hermans wrote: >>>>>>>>>>>> >>>>>>>>>>>>> The kernel I'm using by the way . . . >>>>>>>>>>>>> >>>>>>>>>>>>> $ uname -a >>>>>>>>>>>>> Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC >>>>>>>>>>>>> 2015 armv7l GNU/Linux >>>>>>>>>>>>> >>>>>>>>>>>>> $ ls /dev/ |grep uio >>>>>>>>>>>>> uio >>>>>>>>>>>>> uio0 >>>>>>>>>>>>> uio1 >>>>>>>>>>>>> uio2 >>>>>>>>>>>>> uio3 >>>>>>>>>>>>> uio4 >>>>>>>>>>>>> uio5 >>>>>>>>>>>>> uio6 >>>>>>>>>>>>> uio7 >>>>>>>>>>>>> >>>>>>>>>>>>> $ ./lsuio >>>>>>>>>>>>> uio7: name=pruss_evt7, version=1.0, events=0 >>>>>>>>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>>>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>>>>>>>> uio6: name=pruss_evt6, version=1.0, events=0 >>>>>>>>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>>>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>>>>>>>> uio5: name=pruss_evt5, version=1.0, events=0 >>>>>>>>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>>>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>>>>>>>> uio4: name=pruss_evt4, version=1.0, events=0 >>>>>>>>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>>>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>>>>>>>> uio3: name=pruss_evt3, version=1.0, events=0 >>>>>>>>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>>>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>>>>>>>> uio2: name=pruss_evt2, version=1.0, events=0 >>>>>>>>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>>>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>>>>>>>> uio1: name=pruss_evt1, version=1.0, events=0 >>>>>>>>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>>>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>>>>>>>> uio0: name=pruss_evt0, version=1.0, events=0 >>>>>>>>>>>>> map[0]: addr=0x4A300000, size=524288 >>>>>>>>>>>>> map[1]: addr=0x9E880000, size=262144 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Nov 20, 2015 at 2:59 PM, William Hermans < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> The TI kernels have remoteproc enabled in the kernel, which >>>>>>>>>>>>>> will interfere with uio_pruss. You need to switch to a *bone* >>>>>>>>>>>>>> kernel. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Nov 20, 2015 at 9:59 AM, Erik Stauber < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm trying to migrate to 4.1 from 3.8, and it seems as if >>>>>>>>>>>>>>> the PRU is up and running on the latest 4.1 kernel. However, a >>>>>>>>>>>>>>> difference >>>>>>>>>>>>>>> is the I'm not getting the 8 uioX (x=0-8) entries in the /dev >>>>>>>>>>>>>>> directory, >>>>>>>>>>>>>>> and therefore the prussdrv library errors out when it can't >>>>>>>>>>>>>>> find those >>>>>>>>>>>>>>> files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The prussdrv is looking for this: >>>>>>>>>>>>>>> sprintf(name, "/dev/uio%d", host_interrupt); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The dmesg output on 4.1.13-ti-r33 reports that it is >>>>>>>>>>>>>>> skipping intr mapping... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *[ 20.830764] pru-rproc 4a334000.pru0: version 0 >>>>>>>>>>>>>>> event_chnl_map_size 1 event_chnl_map 0000039c* >>>>>>>>>>>>>>> *[ 20.830799] pru-rproc 4a334000.pru0: sysevt-to-ch[60] -> >>>>>>>>>>>>>>> 0* >>>>>>>>>>>>>>> *[ 20.830812] pru-rproc 4a334000.pru0: chnl-to-host[0] -> >>>>>>>>>>>>>>> 0* >>>>>>>>>>>>>>> *[ 20.830823] pru-rproc 4a334000.pru0: skip intr mapping >>>>>>>>>>>>>>> for chnl 1* >>>>>>>>>>>>>>> *[ 20.830833] pru-rproc 4a334000.pru0: skip intr mapping >>>>>>>>>>>>>>> for chnl 2* >>>>>>>>>>>>>>> *[ 20.830844] pru-rproc 4a334000.pru0: skip intr mapping >>>>>>>>>>>>>>> for chnl 3* >>>>>>>>>>>>>>> *[ 20.830854] pru-rproc 4a334000.pru0: skip intr mapping >>>>>>>>>>>>>>> for chnl 4* >>>>>>>>>>>>>>> *[ 20.830864] pru-rproc 4a334000.pru0: skip intr mapping >>>>>>>>>>>>>>> for chnl 5* >>>>>>>>>>>>>>> *[ 20.830875] pru-rproc 4a334000.pru0: skip intr mapping >>>>>>>>>>>>>>> for chnl 6* >>>>>>>>>>>>>>> *[ 20.830885] pru-rproc 4a334000.pru0: skip intr mapping >>>>>>>>>>>>>>> for chnl 7* >>>>>>>>>>>>>>> *[ 20.830896] pru-rproc 4a334000.pru0: skip intr mapping >>>>>>>>>>>>>>> for chnl 8* >>>>>>>>>>>>>>> *[ 20.830906] pru-rproc 4a334000.pru0: skip intr mapping >>>>>>>>>>>>>>> for chnl 9* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does anyone know how to not skip that? Or a way for me to >>>>>>>>>>>>>>> map them manually? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Erik >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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. >>>>>> >>>>> >>>>> >>>> >>> -- >> 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.
