>
> *I just don’t understand what you are asking for. The code is self
> explanatory and with a little effort, you can make it work. My guess is you
> want me to add the include headers and create the Makefile and Kconfig
> files. If that is what you want, I can do it for you, but I thought you
> would know how to do this yourself. Take a book and read about sigaction.
> I’m sure you will find examples just like the ones I sent you. I’ve pulled
> code like this together for year to understand how comms works between the
> kernel and user space.  *
> *Regards,*
>
*John*

Dont do it for me, because I do not need it. Do it for all those interested
people you mentioned before.

You say it's easy, and you're pasting in random code here in there, but
I've yet to see you come up with a real, and solid solution. You keep
talking around the subject like it's simple . . .so put your money where
your mouth is.

Either that, or stop "talking", because you're not helping anyone.


On Wed, Apr 20, 2016 at 12:59 AM, John Syne <john3...@gmail.com> wrote:

> I just don’t understand what you are asking for. The code is self
> explanatory and with a little effort, you can make it work. My guess is you
> want me to add the include headers and create the Makefile and Kconfig
> files. If that is what you want, I can do it for you, but I thought you
> would know how to do this yourself. Take a book and read about sigaction.
> I’m sure you will find examples just like the ones I sent you. I’ve pulled
> code like this together for year to understand how comms works between the
> kernel and user space.
>
> Regards,
> John
>
>
>
>
> On Apr 20, 2016, at 12:45 AM, William Hermans <yyrk...@gmail.com> wrote:
>
> 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 <john3...@gmail.com> wrote:
>
>>
>> On Apr 19, 2016, at 9:28 PM, William Hermans <yyrk...@gmail.com> 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 <john3...@gmail.com> 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 <yyrk...@gmail.com> wrote:
>>>
>>> Good, now add it.
>>>
>>> On Tue, Apr 19, 2016 at 5:16 PM, John Syne <john3...@gmail.com> 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 <yyrk...@gmail.com> 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 <yyrk...@gmail.com>
>>>> 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 <bellyac...@gmail.com> 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 <yyrk...@gmail.com>
>>>>>> 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 < <john3...@gmail.com>
>>>>>> john3...@gmail.com> 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 < <yyrk...@gmail.com>
>>>>>>> yyrk...@gmail.com> 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 <
>>>>>>> <evilwul...@gmail.com>evilwul...@gmail.com> 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 < <evilwul...@gmail.com>
>>>>>>>> evilwul...@gmail.com> 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 < <yyrk...@gmail.com>
>>>>>>>> yyrk...@gmail.com> 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 <
>>>>>>>> <yyrk...@gmail.com>yyrk...@gmail.com> 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  <beagleboard+unsubscr...@googlegroups.com>
>>>>>>>> beagleboard+unsubscr...@googlegroups.com.
>>>>>>>> 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  <beagleboard+unsubscr...@googlegroups.com>
>>>>>>>> beagleboard+unsubscr...@googlegroups.com.
>>>>>>>> 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  <beagleboard+unsubscr...@googlegroups.com>
>>>>>>>> beagleboard+unsubscr...@googlegroups.com.
>>>>>>>> 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  <beagleboard+unsubscr...@googlegroups.com>
>>>>>>> beagleboard+unsubscr...@googlegroups.com.
>>>>>>> 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  <beagleboard+unsubscr...@googlegroups.com>
>>>>>>> beagleboard+unsubscr...@googlegroups.com.
>>>>>>> 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 beagleboard+unsubscr...@googlegroups.com.
>>>>>> 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 beagleboard+unsubscr...@googlegroups.com.
>>>>>> 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 beagleboard+unsubscr...@googlegroups.com.
>>>>>> 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 beagleboard+unsubscr...@googlegroups.com.
>>>> 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 beagleboard+unsubscr...@googlegroups.com.
>>>> 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 beagleboard+unsubscr...@googlegroups.com.
>>> 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 beagleboard+unsubscr...@googlegroups.com.
>>> 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 beagleboard+unsubscr...@googlegroups.com.
>> 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 beagleboard+unsubscr...@googlegroups.com.
>> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CALHSORoHsyHaqMnzK1C_E2Rt2zQcWE1PMASS0S6vgDxDiOxCGw%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CALHSORoHsyHaqMnzK1C_E2Rt2zQcWE1PMASS0S6vgDxDiOxCGw%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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/C3044AEC-BE7C-4510-B7D7-CF5B97E47806%40gmail.com
> <https://groups.google.com/d/msgid/beagleboard/C3044AEC-BE7C-4510-B7D7-CF5B97E47806%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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORq1byP6i%2Bq8%3D_4H6REasjJDjGzcqZho5pHD8x2xaGN1Mg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to