Well that is not how I'd do things, and I suppose that code if complete and integrated into the tps65217.c file, it might work . . .
But as I said that code is not complete, and is what looks like example code out of some Documentation/*txt file. On Tue, Apr 19, 2016 at 10:14 PM, John Syne <[email protected]> wrote: > > On Apr 19, 2016, at 9:28 PM, William Hermans <[email protected]> wrote: > > That's not what I was saying at all. I'm saying if all this is that easy > for you, then you should add this functionality, and be the community hero. > > This sort of thing is definitely not above my pay grade, but I am not a > kernel hacker, and I do not know the file structure all that well. So it > would take me a while to to figure out everything I need to know, about > everything I'd need. So if this thing is really that easy for you, why > don't you make a new LKM, something that takes an argument, or two. LIke > g_multi where you pass in a path for the g_mass_storage bit of the driver. > Except of course, you want to be able to set a time out for a shutdown. > > Second, a kernel module should not require a specific init daemon. That > goes against the whole point of Linux. > > > FYI I could do this entirely in userspace, really easily. Except I would > have to poll, instead of using an interrupt, and I pretty much be writing > duplicate code, or code that does a duplicate job. But passed that I really > do not have to time for this, or to read through, and understand all the > required Linux kernel, and LKMs to do this "properly". It's a lot of work > for someone who really doesn't know what they're doing. > > Yep, it can be done in user space as well. Simply add sigaction to the > tps65217 mfd driver. Here is an example of a standalone KM with a user > space app. So now we do not use input key, but send events via kernel > signals (similar to kill -9 pid or ctrl-c). > > Kernel Code: > > === > #define SIG_TEST 44 // we choose 44 as our signal number (real-time > signals are in the range of 33 to 64) > > struct dentry *file; > > static ssize_t write_pid(struct file *file, const char __user *buf, > size_t count, loff_t *ppos) > { > char mybuf[10]; > int pid = 0; > int ret; > struct siginfo info; > struct task_struct *t; > /* read the value from user space */ > if(count > 10) > return -EINVAL; > copy_from_user(mybuf, buf, count); > sscanf(mybuf, "%d", &pid); > printk("pid = %d\n", pid); > > /* send the signal */ > memset(&info, 0, sizeof(struct siginfo)); > info.si_signo = SIG_TEST; > info.si_code = SI_QUEUE; // this is bit of a trickery: SI_QUEUE is > normally used by sigqueue from user space, > // and kernel space should use SI_KERNEL. But if SI_KERNEL is used the > real_time data > // is not delivered to the user space signal handler function. > info.si_int = 1234; //real time signals may have 32 bits of data. > > rcu_read_lock(); > // t = find_task_by_pid_type(PIDTYPE_PID, pid); //find the task_struct > associated with this pid > t = pid_task(find_pid_ns(pid, &init_pid_ns), PIDTYPE_PID); > if(t == NULL){ > printk("no such pid\n"); > rcu_read_unlock(); > return -ENODEV; > } > rcu_read_unlock(); > ret = send_sig_info(SIG_TEST, &info, t); //send the signal > if (ret < 0) { > printk("error sending signal\n"); > return ret; > } > return count; > } > > static const struct file_operations my_fops = { > .write = write_pid, > }; > > static int __init signalexample_module_init(void) > { > /* we need to know the pid of the user space process > * -> we use debugfs for this. As soon as a pid is written to > * this file, a signal is sent to that pid > */ > /* only root can write to this file (no read) */ > file = debugfs_create_file("signalconfpid", 0200, NULL, NULL, &my_fops); > return 0; > } > static void __exit signalexample_module_exit(void) > { > debugfs_remove(file); > > } > > === > > > User Space Code: > > === > #define SIG_TEST 44 /* we define our own signal, hard coded since SIGRTMIN > is different in user and in kernel space */ > > void receiveData(int n, siginfo_t *info, void *unused) { > printf("received value %i\n", info->si_int); > } > > int main ( int argc, char **argv ) > { > int configfd; > char buf[10]; > /* setup the signal handler for SIG_TEST > * SA_SIGINFO -> we want the signal handler function with 3 arguments > */ > struct sigaction sig; > sig.sa_sigaction = receiveData; > sig.sa_flags = SA_SIGINFO; > sigaction(SIG_TEST, &sig, NULL); > > /* kernel needs to know our pid to be able to send us a signal -> > * we use debugfs for this -> do not forget to mount the debugfs! > */ > configfd = open("/sys/kernel/debug/signalconfpid", O_WRONLY); > if(configfd < 0) { > perror("open"); > return -1; > } > sprintf(buf, "%i", getpid()); > if (write(configfd, buf, strlen(buf) + 1) < 0) { > perror("fwrite"); > return -1; > } > > return 0; > } > === > > > Lastly, when I say "really easily" I mean that I know it is possible and I > know how to go about doing it. I'd just have to research many things to > bring it all together. So would also take me a little while. Maybe a week, > maybe two. Assuming I had the time. > > On Tue, Apr 19, 2016 at 8:51 PM, John Syne <[email protected]> wrote: > >> Here is the problem with that. You use a different kernel to me and you >> don’t like to use systemd. Hence I will explain how to get this working, >> but you are going to have to do the coding and testing. To start with, >> which kernel are you using? >> >> From the TPS65217 datasheet the ACI bit in the INT register (0x02) will >> be a 1 if the power status changed (either power on or power fail). The >> state of the power is in the status register (0xA) which is 0 for no power >> and 1 for power in valid range. So looking at the Interrupt routing, both >> events are reported. I would recommend changing the input key to something >> different to KEY_POWER because we do not want to modify the pwr button >> behavior. >> >> >> if (int_reg & TPS65217_INT_ACI) { >> /* Handle AC power status change */ >> dev_dbg(tps->dev, "AC power status change\n"); >> /* Press KEY_POWER when AC not present */ >> input_report_key(tps->pwr_but, KEY_POWER, >> ~status_reg & TPS65217_STATUS_ACPWR); >> input_sync(tps->pwr_but); >> } >> >> You might have to change input_report_key to input_report_switch as I’m >> not sure if we can extract the status from EV_KEY. >> Using udev, the input key is linked to this systemd service >> poweroff.target >> >> === >> # This file is part of systemd. >> # >> # systemd is free software; you can redistribute it and/or modify it >> # under the terms of the GNU Lesser General Public License as published >> by >> # the Free Software Foundation; either version 2.1 of the License, or >> # (at your option) any later version. >> >> [Unit] >> Description=Power-Off >> Documentation=man:systemd.special(7) >> DefaultDependencies=no >> Requires=systemd-poweroff.service >> After=systemd-poweroff.service >> AllowIsolate=yes >> >> [Install] >> Alias=ctrl-alt-del.target >> === >> >> Which in turn runs the systemd-poweroff.service >> >> === >> # This file is part of systemd. >> # >> # systemd is free software; you can redistribute it and/or modify it >> # under the terms of the GNU Lesser General Public License as published >> by >> # the Free Software Foundation; either version 2.1 of the License, or >> # (at your option) any later version. >> >> [Unit] >> Description=Power-Off >> Documentation=man:systemd-halt.service(8) >> DefaultDependencies=no >> Requires=shutdown.target umount.target final.target >> After=shutdown.target umount.target final.target >> >> [Service] >> Type=oneshot >> ExecStart=/bin/systemctl --force poweroff >> === >> >> Which powers down the board. >> >> So here is what you need to do. When you receive a input key assigned to >> AC_Power, with a status of fail, start a daemon with a timer. If the timer >> expires, do the same systemctl poweroff or shutdown -h now. If you get a >> input key for AC_Power with status of power_good before the timer expires, >> either kill the daemon or cancel the timer. >> >> Hope this helps. >> >> Regards, >> John >> >> >> >> >> On Apr 19, 2016, at 6:29 PM, William Hermans <[email protected]> wrote: >> >> Good, now add it. >> >> On Tue, Apr 19, 2016 at 5:16 PM, John Syne <[email protected]> wrote: >> >>> In my last e-mail on this issue, I said "Also, the interrupt routine >>> does not report power good, so that would have to be added”. It is a simple >>> thing to add. >>> >>> Regards, >>> John >>> >>> >>> >>> >>> On Apr 19, 2016, at 3:30 PM, William Hermans <[email protected]> wrote: >>> >>> So there is apparently a bug related to this whole situation. Once the >>> input power goes away, whatever it may be. You lose USB, because the PMIC >>> is not longer able to supply 5V. You even get a kernel message in relation >>> to this from musb. >>> >>> The problem is, once input power is restored, I see no indication that >>> 5V is restored to USB. So If you tail -f /var/log/messages, you'll see one >>> musb message when pulling power, but you will not see a corresponding >>> message when plugging power back in. Additionally if you pull power >>> multiple times. Only the first message is displayed. >>> >>> What this tells me is that the current kernel modules are not written to >>> deal / handle this yet. So for now, unless I'm wrong ( which i doubt ). >>> It's best just to power down period. After input power goes away, and >>> simply use an R/C network to "time" system up's, in case power goes up / >>> down rapidly. One, or more times consecutively. >>> >>> On Mon, Apr 18, 2016 at 6:26 PM, William Hermans <[email protected]> >>> wrote: >>> >>>> *I have an interest in this. It's way above my pay grade from a >>>>> programming perspective...* >>>>> >>>>> *Mike* >>>>> >>>> >>>> Hi Mike, >>>> >>>> This is actually something I'm personally very interested in too. >>>> However, at this moment in time, my buddy and I are actually in the process >>>> of making two different capes for the beaglebone. So this is one of those >>>> situations where you have to have priorities . . . and while I obviously do >>>> not know everything involved to get this certain thing done, it is not >>>> above my pay grade. >>>> >>>> So perhaps in the future, it may be something I'll revisit, and would >>>> be something I'd contribute back to the community. >>>> >>>> On Mon, Apr 18, 2016 at 2:26 PM, Mike <[email protected]> wrote: >>>> >>>>> On 04/18/2016 03:31 PM, John Syne wrote: >>>>> >>>>> That is OK if this doesn’t work for you, but there are other BBB users >>>>> who might find this helpful. Currently the powerfail uses the same key >>>>> function as the pwr button, so the first place to start would be changing >>>>> the key function to something else. Also, the interrupt routine does not >>>>> report power good, so that would have to be added. After that, a systemd >>>>> service could take care of the rest. >>>>> >>>>> Regards, >>>>> John >>>>> >>>>> >>>>> >>>>> I have an interest in this. It's way above my pay grade from a >>>>> programming perspective... >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> On Apr 18, 2016, at 11:31 AM, William Hermans <[email protected]> >>>>> wrote: >>>>> >>>>> #1 >>>>> william@beaglebone:~$ ls /etc/udev/rules.d/ >>>>> 50-hidraw.rules 50-spi.rules 60-omap-tty.rules >>>>> 70-persistent-net.rules uio.rules >>>>> >>>>> #2 >>>>> We do not care about the button press. We *did* care about what >>>>> happens when power is removed, while a battery is connected. >>>>> >>>>> Now we do not care. We're not going to bother with it. It's too much >>>>> hassle for a result that is not really all that important. So what if the >>>>> power down routine is inefficient . . . it works. >>>>> >>>>> On Mon, Apr 18, 2016 at 10:29 AM, John Syne < <[email protected]> >>>>> [email protected]> wrote: >>>>> >>>>>> I asked Robert how the pwr button is processed and interestingly it >>>>>> is done via udev and systemd. Also, there is some new code going >>>>>> mainstream >>>>>> for the pwr button and battery charger. Perhaps you can implement the >>>>>> timer >>>>>> delay via a custom systemd service. Here is what Robert sent me: >>>>>> >>>>>> Oh this is finally getting upstreamed: >>>>>> >>>>>> https://www.spinics.net/lists/linux-omap/msg127184.html >>>>>> >>>>>> I need to switch to their version, vs our 3.8.13 erra hack that's >>>>>> been forward ported for years. ;) >>>>>> >>>>>> Behind the scenes's that patch is reporting a key-event to systemd... >>>>>> >>>>>> >>>>>> https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/src/login/70-power-switch.rules#L13 >>>>>> >>>>>> Regards, >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Apr 17, 2016, at 11:06 PM, William Hermans < <[email protected]> >>>>>> [email protected]> wrote: >>>>>> >>>>>> There is no timer in that code. The timer would have to be added, and >>>>>> careful consideration would have to be given to exactly how that was >>>>>> implemented. >>>>>> >>>>>> So in other words, you would, or should write a completely new kernel >>>>>> module, that is meant to replace what already exists - As an option. >>>>>> >>>>>> On Sun, Apr 17, 2016 at 10:25 PM, evilwulfie < <[email protected]> >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Where in the code do you set that timer ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/17/2016 7:50 PM, John Syne wrote: >>>>>>> >>>>>>> One more thing, the power down sequence uses the RTC framework >>>>>>> (described earlier in this thread), so it will be possible to set a >>>>>>> timer >>>>>>> for the shutdown and the wait for the power to return event to cancel >>>>>>> the >>>>>>> timer. If the power on event does not occur, the shutdown will occur. >>>>>>> >>>>>>> Regards, >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Apr 17, 2016, at 7:18 PM, evilwulfie < <[email protected]> >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> Interesting. Too bad if you want the battery to act as a UPS it >>>>>>> cant some how notify the kernel that AC has been removed >>>>>>> and have a routine to just chill a while to see if power comes back. >>>>>>> >>>>>>> Be nice to have a variable that is user settable for the time >>>>>>> between loss of AC and shutdown. >>>>>>> >>>>>>> As it is now it sees the AC removed, shuts down and no easy way to >>>>>>> restart on power restored. Requiring some other IC to monitor power >>>>>>> and then press the pwr_but to restart the processor. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/17/2016 7:10 PM, John Syne wrote: >>>>>>> >>>>>>> Yep, it is in the BB kernel: >>>>>>> >>>>>>> >>>>>>> <https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch> >>>>>>> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.1/patches/beaglebone/dts/0006-tps65217-Enable-KEY_POWER-press-on-AC-loss-PWR_BUT.patch >>>>>>> >>>>>>> So again, on line 164 is the Interrupt routing. It is this line: >>>>>>> >>>>>>> + input_report_key(tps->pwr_but, KEY_POWER, >>>>>>> >>>>>>> + ~status_reg & TPS65217_STATUS_ACPWR); >>>>>>> that send a power button pressed as an input key when the AC 5V >>>>>>> power is removed. >>>>>>> >>>>>>> Regards, >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Apr 17, 2016, at 4:52 PM, William Hermans < <[email protected]> >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> The real reason why our source trees do not match up. My source tree >>>>>>> is based on 4.1.x, and yours seems to be 3.8.x. The patch you showed >>>>>>> above >>>>>>> would probably botch up my source tree . . . >>>>>>> >>>>>>> On Sun, Apr 17, 2016 at 4:33 PM, William Hermans < >>>>>>> <[email protected]>[email protected]> wrote: >>>>>>> >>>>>>>> Yeah I recognize that code from source code not written by TI >>>>>>>> employees. The file is called tps65217_charger.c, and is written by an >>>>>>>> employee of another company. >>>>>>>> >>>>>>>> Anyway, I think we're going to blow this off. The idea was to wait >>>>>>>> around without power for 5 minutes, to see if power comes back up. >>>>>>>> Before >>>>>>>> issuing a shutdown. Then, on the power up end, using a simple R/C >>>>>>>> circuit >>>>>>>> to ramp up voltage to 5v over a specific time period. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2109-v2-a> >>>>>>> Virus-free. >>>>>>> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2109-v2-a> >>>>>>> www.avast.com >>>>>>> >>>>>>> -- >>>>>>> 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]> >>>>>>> [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> <https://groups.google.com/d/msgid/beagleboard/571443FC.6020505%40gmail.com> >>>>>>> https://groups.google.com/d/msgid/beagleboard/571443FC.6020505%40gmail.com >>>>>>> . >>>>>>> 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]> >>>>>>> [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> <https://groups.google.com/d/msgid/beagleboard/2CC5F218-6933-45E8-8B84-2CEE08263AF5%40gmail.com> >>>>>>> https://groups.google.com/d/msgid/beagleboard/2CC5F218-6933-45E8-8B84-2CEE08263AF5%40gmail.com >>>>>>> . >>>>>>> For more options, visit <https://groups.google.com/d/optout> >>>>>>> https://groups.google.com/d/optout. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2109-v2-a> >>>>>>> Virus-free. >>>>>>> <https://www.avast.com/en-us/lp-safe-emailing-2109?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2109-v2-a> >>>>>>> www.avast.com >>>>>>> >>>>>>> -- >>>>>>> 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]> >>>>>>> [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> <https://groups.google.com/d/msgid/beagleboard/57146FB7.5000301%40gmail.com?utm_medium=email&utm_source=footer> >>>>>>> https://groups.google.com/d/msgid/beagleboard/57146FB7.5000301%40gmail.com >>>>>>> . >>>>>>> >>>>>>> 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]> >>>>>> [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/beagleboard/CALHSORqGgChYUiW8na9wJqDQNW3_tOXn4YW4Rrhqe0UyCzDGWg%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/beagleboard/CALHSORqGgChYUiW8na9wJqDQNW3_tOXn4YW4Rrhqe0UyCzDGWg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> 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]> >>>>>> [email protected]. >>>>>> To view this discussion on the web visit >>>>>> <https://groups.google.com/d/msgid/beagleboard/8482E576-E05F-4B45-8F30-87B0AFA8D211%40gmail.com?utm_medium=email&utm_source=footer> >>>>>> https://groups.google.com/d/msgid/beagleboard/8482E576-E05F-4B45-8F30-87B0AFA8D211%40gmail.com >>>>>> . >>>>>> >>>>>> 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]. >>>>> To view this discussion on the web visit >>>>> <https://groups.google.com/d/msgid/beagleboard/CALHSORqf9j0x91u0XAM1KJLBrc9zMwk_-yzvLMhT3LGagnahyQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> https://groups.google.com/d/msgid/beagleboard/CALHSORqf9j0x91u0XAM1KJLBrc9zMwk_-yzvLMhT3LGagnahyQ%40mail.gmail.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 [email protected]. >>>>> To view this discussion on the web visit >>>>> <https://groups.google.com/d/msgid/beagleboard/053B71E7-CF39-4B7C-A7A5-615C9EB197E7%40gmail.com?utm_medium=email&utm_source=footer> >>>>> https://groups.google.com/d/msgid/beagleboard/053B71E7-CF39-4B7C-A7A5-615C9EB197E7%40gmail.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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/beagleboard/5715510F.8000408%40gmail.com >>>>> <https://groups.google.com/d/msgid/beagleboard/5715510F.8000408%40gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> 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]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beagleboard/CALHSORr_TRRtZSnUmo-xQFmh%2B8u_RcDXU5zEJjw7ONpg4eOZ5w%40mail.gmail.com >>> <https://groups.google.com/d/msgid/beagleboard/CALHSORr_TRRtZSnUmo-xQFmh%2B8u_RcDXU5zEJjw7ONpg4eOZ5w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> 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]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beagleboard/3FE12548-00AA-458C-9CB2-A47F0C8AB5A9%40gmail.com >>> <https://groups.google.com/d/msgid/beagleboard/3FE12548-00AA-458C-9CB2-A47F0C8AB5A9%40gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> 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]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/CALHSORogR8Ahz1hmp0NAohsLGCO3XqTUowDPmAiPE0azY2AgdQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/beagleboard/CALHSORogR8Ahz1hmp0NAohsLGCO3XqTUowDPmAiPE0azY2AgdQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> 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]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/D0317723-FE78-4873-87FD-1DE8C5FAE57B%40gmail.com >> <https://groups.google.com/d/msgid/beagleboard/D0317723-FE78-4873-87FD-1DE8C5FAE57B%40gmail.com?utm_medium=email&utm_source=footer> >> . >> >> 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CALHSORrfjv%3DQcrLP%3DpbphSJAFe%2Bf%2B2seAQd%2Bpuq7gGomdM1UuQ%40mail.gmail.com > <https://groups.google.com/d/msgid/beagleboard/CALHSORrfjv%3DQcrLP%3DpbphSJAFe%2Bf%2B2seAQd%2Bpuq7gGomdM1UuQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/E4F48D04-8F9A-4B26-8439-10E878DE2767%40gmail.com > <https://groups.google.com/d/msgid/beagleboard/E4F48D04-8F9A-4B26-8439-10E878DE2767%40gmail.com?utm_medium=email&utm_source=footer> > . > > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORoHsyHaqMnzK1C_E2Rt2zQcWE1PMASS0S6vgDxDiOxCGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
