date:20160418

>
> *Oh, just a step by step set of instructions like:*
>
>
> *https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green
> *
>
> *Just not as pretty. ;)*
>
> *Regards,*
>

Ah, so in other words, pretty much what I already do. Except I use txt
files.  It can be a lot of tedious manual copy / paste though.

@Mike, Yes, I know of script, and I do not remember why I do not use it,
but decided against it a few years back for some reason . . . most probably
it did not format what actually happen at the console well.



On Mon, Apr 18, 2016 at 7:08 PM, Robert Nelson 
wrote:

>
>
> On Mon, Apr 18, 2016 at 9:06 PM, William Hermans 
> wrote:
>
>> *eewiki.net . ;)  There's lot of private pages i
>>> haven't pushed... *
>>>
>>> *before that i ran mediawiki on one of my arm boards at work...*
>>>
>>> *Regards,*
>>>
>>
>> I understood that, but what is the technology you used ? git is easy to
>> understand, at least for me. You push, and add a comment. that is self
>> explanatory. But  a wiki . . . I never used one, so not really familiar
>> with how that would work.
>>
>
> Oh, just a step by step set of instructions like:
>
>
> https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green
>
> Just not as pretty. ;)
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> 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/CAOCHtYjmtQYK8CWWQ6C1tBwQGuUUg3C9WWS8_MJZLjq3TpXivw%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/CALHSORpcB%3DkkTNb5Y%3DLWD%2B7tbfrUiy30VYpODgW0rDLbD2CEiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Black-vs-Green DTBs

On Mon, Apr 18, 2016 at 9:06 PM, William Hermans  wrote:

> *eewiki.net . ;)  There's lot of private pages i
>> haven't pushed... *
>>
>> *before that i ran mediawiki on one of my arm boards at work...*
>>
>> *Regards,*
>>
>
> I understood that, but what is the technology you used ? git is easy to
> understand, at least for me. You push, and add a comment. that is self
> explanatory. But  a wiki . . . I never used one, so not really familiar
> with how that would work.
>

Oh, just a step by step set of instructions like:

https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green

Just not as pretty. ;)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYjmtQYK8CWWQ6C1tBwQGuUUg3C9WWS8_MJZLjq3TpXivw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Black-vs-Green DTBs

2016-04-18 Thread Mike

On 04/18/2016 10:01 PM, William Hermans wrote:
So this got me thinking. You *could* write up a quick Nodejs or 
AngularJS app, that is exactly like the example todo app tutorials out 
there. Except, in reverse( if that makes sense ).

What I'd really prefer though is some way my console is automatically 
recorded, that does not introduce a lot of gibberish, like puTTY likes 
to do . . .

man script

Mike
On Mon, Apr 18, 2016 at 6:58 PM, William Hermans > wrote:

/Or a private internal wiki../

Care to elaborate on that Robert ?

On Mon, Apr 18, 2016 at 6:39 PM, Robert Nelson
> wrote:

On Mon, Apr 18, 2016 at 8:32 PM, William Hermans
> wrote:

Force yourself to write a diary every day. Or worklog if
you prefer that term.

On Mon, Apr 18, 2016 at 6:17 PM, Rick Mann
> wrote:

It used to work, even in some early 4.0.x or 4.1.x
kernels, I thought. Not sure, though; been a while.
I'm not very good about documenting each change and
recording the outcome (it's hard when you're in a
trial-and-error cycle, and then walk away for days or
weeks). I end up repeating experiments a lot :-(

+ push everything you do a private git tree..  Or a private
internal wiki..

There's many times i've found something i tried years ago, but
finally figured it out..  Even if initially looked like crap,
keep it..

my short term memory is pretty much toast, writing it down is
the only way my mind remembers..

Regards,

-- 
Robert Nelson

https://rcn-ee.com/
-- 
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/CAOCHtYgvEt80jPyhXfEaUBQUt3jwdWK6A9i_wySMzDdv5iUuTA%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/CALHSORrnb78G8zbjasczp5te-QTb95Dry052nVHXKxPhXTN3fw%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/57159292.4090804%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Black-vs-Green DTBs

>
> *eewiki.net . ;)  There's lot of private pages i
> haven't pushed... *
>
> *before that i ran mediawiki on one of my arm boards at work...*
>
> *Regards,*
>

I understood that, but what is the technology you used ? git is easy to
understand, at least for me. You push, and add a comment. that is self
explanatory. But  a wiki . . . I never used one, so not really familiar
with how that would work.

On Mon, Apr 18, 2016 at 7:02 PM, Robert Nelson 
wrote:

>
>
> On Mon, Apr 18, 2016 at 8:58 PM, William Hermans 
> wrote:
>
>> *Or a private internal wiki..*
>>>
>>
>> Care to elaborate on that Robert ?
>>
>
> eewiki.net. ;)  There's lot of private pages i haven't pushed...
>
> before that i ran mediawiki on one of my arm boards at work...
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> 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/CAOCHtYiHYipVxd6TVUYb0uvxEz84fngQeh3Rv0XiMh_Q5yrCPA%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/CALHSORo_f4NnoQT5_QPXB424qnLVKeG-vEMspsZj3wqeVJ_ktg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Black-vs-Green DTBs

On Mon, Apr 18, 2016 at 8:58 PM, William Hermans  wrote:

> *Or a private internal wiki..*
>>
>
> Care to elaborate on that Robert ?
>

eewiki.net. ;)  There's lot of private pages i haven't pushed...

before that i ran mediawiki on one of my arm boards at work...

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYiHYipVxd6TVUYb0uvxEz84fngQeh3Rv0XiMh_Q5yrCPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Loading on Beaglebone Black Boot Pins?

I was attempting to emulate the PRU cape, which uses P8_44 as a PRU output.

However, the PRU cape uses a FET switch, gate connected to P8_44.  It does 
not load the pin during boot.
I used a BJT with resistor in series with the base, which was enough to 
disable the board!

I've changed the series base resistor to 47Kohm and now it works.  However, 
I suspect it might be a bit marginal.
So I need to get some FETs!  Too bad, I've got a lot of 2Ns, they will 
have to be put to work elsewhere.

Greg

On Monday, April 18, 2016 at 8:24:41 PM UTC-4, Chris Morgan wrote:
>
> On Mon, Apr 18, 2016 at 8:12 PM, Greg  
> wrote: 
> > I'm trouble shooting a problem on a simple cape for a BeagleBone Black. 
> > 
> > I have a bipolar switch for an LED, very similar to that used for the 
> "User 
> > LEDS". 
> > So I have added an approximately 10Kohm load to one of the "boot pins", 
> > which 
> > in header lingo is P8_44. 
> > 
> > P8_44 is also one of the "boot" pins.  I'm interesting in using the PRU 
> > connection mode of this pin. 
> > 
> > The System Reference Manuals says the boot pins must not be driven prior 
> to 
> > coming out of reset (SYS_RESET goes high). 
> > 
> > So maybe my understanding of the term "driven" in this context is 
> incorrect, 
> > and it could also be interpreted as "loading", 
> > as in excessive resistive loading? 
> > 
> > I tried an experiment on both BBB and BBG with a 10kohm resistor to 
> ground 
> > on P8_44.  Both refused to boot up and run. 
> > So is it a requirement to keep resistive loads off this pin during the 
> boot 
> > process? 
> > 
> > Regards, 
> > Greg 
> > 
>
> Yes. 
>
> You should avoid applying any voltage to any pin before SYS_RESET goes 
> high, or you'll likely permanently break something. In your case it 
> looks like you are changing the boot pin configuration (maybe it 
> defaults to an internal weak pullup?) and preventing your system from 
> booting. If that isn't what you intended you'll want to avoid loading 
> the pin until after SYS_RESET goes high. 
>
> What are you trying to accomplish with your cape and that io pin? 
> There are approaches that may let you both use the pin and avoiid 
> changing the boot strapping but it would really help to see the 
> circuit you are trying to use with that pin. 
>
> Chris 
>

-- 
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/3f3b9860-f48a-49dd-989d-ba272f3f1f31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Black-vs-Green DTBs

So this got me thinking. You *could* write up a quick Nodejs or AngularJS
app, that is exactly like the example todo app tutorials out there. Except,
in reverse( if that makes sense ).

What I'd really prefer though is some way my console is automatically
recorded, that does not introduce a lot of gibberish, like puTTY likes to
do . . .

On Mon, Apr 18, 2016 at 6:58 PM, William Hermans  wrote:

> *Or a private internal wiki..*
>>
>
> Care to elaborate on that Robert ?
>
> On Mon, Apr 18, 2016 at 6:39 PM, Robert Nelson 
> wrote:
>
>>
>>
>> On Mon, Apr 18, 2016 at 8:32 PM, William Hermans 
>> wrote:
>>
>>> Force yourself to write a diary every day. Or worklog if you prefer that
>>> term.
>>>
>>> On Mon, Apr 18, 2016 at 6:17 PM, Rick Mann 
>>> wrote:
>>>
 It used to work, even in some early 4.0.x or 4.1.x kernels, I thought.
 Not sure, though; been a while. I'm not very good about documenting each
 change and recording the outcome (it's hard when you're in a
 trial-and-error cycle, and then walk away for days or weeks). I end up
 repeating experiments a lot :-(

>>>
>> + push everything you do a private git tree..  Or a private internal
>> wiki..
>>
>> There's many times i've found something i tried years ago, but finally
>> figured it out..  Even if initially looked like crap, keep it..
>>
>> my short term memory is pretty much toast, writing it down is the only
>> way my mind remembers..
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> --
>> 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/CAOCHtYgvEt80jPyhXfEaUBQUt3jwdWK6A9i_wySMzDdv5iUuTA%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/CALHSORrnb78G8zbjasczp5te-QTb95Dry052nVHXKxPhXTN3fw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Black-vs-Green DTBs

>
> *Or a private internal wiki..*
>

Care to elaborate on that Robert ?

On Mon, Apr 18, 2016 at 6:39 PM, Robert Nelson 
wrote:

>
>
> On Mon, Apr 18, 2016 at 8:32 PM, William Hermans 
> wrote:
>
>> Force yourself to write a diary every day. Or worklog if you prefer that
>> term.
>>
>> On Mon, Apr 18, 2016 at 6:17 PM, Rick Mann  wrote:
>>
>>> It used to work, even in some early 4.0.x or 4.1.x kernels, I thought.
>>> Not sure, though; been a while. I'm not very good about documenting each
>>> change and recording the outcome (it's hard when you're in a
>>> trial-and-error cycle, and then walk away for days or weeks). I end up
>>> repeating experiments a lot :-(
>>>
>>
> + push everything you do a private git tree..  Or a private internal wiki..
>
> There's many times i've found something i tried years ago, but finally
> figured it out..  Even if initially looked like crap, keep it..
>
> my short term memory is pretty much toast, writing it down is the only way
> my mind remembers..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> 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/CAOCHtYgvEt80jPyhXfEaUBQUt3jwdWK6A9i_wySMzDdv5iUuTA%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/CALHSORocrwAHzNSN8RzUbnAu_8r9Y0O9Pza7zecJ1eX6S_vP%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Loading on Beaglebone Black Boot Pins?

Thanks!  It never would have occurred to me that a resistive load in this 
context is a "driver".  Lesson learned!

Greg

On Monday, April 18, 2016 at 8:26:47 PM UTC-4, Harvey White wrote:
>
> On Mon, 18 Apr 2016 17:12:37 -0700 (PDT), you wrote: 
>
> >I'm trouble shooting a problem on a simple cape for a BeagleBone Black. 
> > 
> >I have a bipolar switch for an LED, very similar to that used for the 
> "User 
> >LEDS". 
> >So I have added an approximately 10Kohm load to one of the "boot pins", 
> >which 
> >in header lingo is P8_44. 
> > 
> >P8_44 is also one of the "boot" pins.  I'm interesting in using the PRU 
> >connection mode of this pin. 
> > 
> >The System Reference Manuals says the boot pins must not be *driven* 
> prior 
> >to coming out of reset (SYS_RESET goes high). 
> > 
> >So maybe my understanding of the term "driven" in this context is 
> >incorrect, and it could also be interpreted as "loading", 
> >as in excessive resistive loading? 
>
> Driven in this case (and lots of others) means a signal connected to 
> that pin. 
>
> A resistor going to VCC or ground does indeed "drive" that signal.   
>
> BOOT pins must completely float until the boot process is done, *then* 
> you can do something with them. 
>
> A good idea is to avoid boot pins 
> Another good idea is to use tri-state drivers on those pins, and turn 
> them on ONLY when the boot process is done. 
>
> There are a number of threads discussing this. 
>
> However, nobody has specifically said that resistors effectively drive 
> boot pins.  They do. 
>
> Harvey 
>
>
> > 
> >I tried an experiment on both BBB and BBG with a 10kohm resistor to 
> ground 
> >on P8_44.  Both refused to boot up and run. 
> >So is it a requirement to keep resistive loads off this pin during the 
> boot 
> >process? 
> > 
> >Regards, 
> >Greg 
>
>

-- 
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/63732160-6bec-4da7-8c65-2a38d1451d0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Black-vs-Green DTBs

On Mon, Apr 18, 2016 at 8:32 PM, William Hermans  wrote:

> Force yourself to write a diary every day. Or worklog if you prefer that
> term.
>
> On Mon, Apr 18, 2016 at 6:17 PM, Rick Mann  wrote:
>
>> It used to work, even in some early 4.0.x or 4.1.x kernels, I thought.
>> Not sure, though; been a while. I'm not very good about documenting each
>> change and recording the outcome (it's hard when you're in a
>> trial-and-error cycle, and then walk away for days or weeks). I end up
>> repeating experiments a lot :-(
>>
>
+ push everything you do a private git tree..  Or a private internal wiki..

There's many times i've found something i tried years ago, but finally
figured it out..  Even if initially looked like crap, keep it..

my short term memory is pretty much toast, writing it down is the only way
my mind remembers..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYgvEt80jPyhXfEaUBQUt3jwdWK6A9i_wySMzDdv5iUuTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Black-vs-Green DTBs

Force yourself to write a diary every day. Or worklog if you prefer that
term.

On Mon, Apr 18, 2016 at 6:17 PM, Rick Mann  wrote:

> It used to work, even in some early 4.0.x or 4.1.x kernels, I thought. Not
> sure, though; been a while. I'm not very good about documenting each change
> and recording the outcome (it's hard when you're in a trial-and-error
> cycle, and then walk away for days or weeks). I end up repeating
> experiments a lot :-(
>
>
> > On Apr 18, 2016, at 17:59 , Robert Nelson 
> wrote:
> >
> > I'm just lazy, I'd like to figure out how to make the "extra" in
> am335x-boneblack-audio-emmc.dts work in the overlay... (thus we would not
> need the special "dtb"..)
> >
> > Regards,
> >
> > On Mon, Apr 18, 2016 at 7:23 PM, Rick Mann 
> wrote:
> > Update: I think *I* created am335x-boneblack-audio-emmc.dts, adding to
> my own confusion. Sorry about that.
> > -
> > There's not quite a 1-1 correspondence between black and green DTS
> files. I wouldn't expect there to be, except where the hardware on the two
> overlap.
> >
> > In this specific case, I noticed that while there is a
> am335x-boneblack-audio-emmc.dts, there's no corresponding
> am335x-bonegreen-audio-emmc.dts. It seems the boneblack one is equivalent
> to the am335x-bonegreen.dts plus two entries for clk_mcasp0. I assume the
> lack of an explicit am335x-bonegreen-audio-emmc.dts is just a minor
> oversight? I can imagine it gets unwieldy to try to have every possible
> .dts for each of the boards.
> >
> > I just wanted to make sure there wasn't a more specific reason why the
> green version of the file doesn't exist.
> >
> > I used am335x-boneblack-audio-emmc.dts, and it seems to work fine in
> 4.4.7-bone-rt-r9 (aside from the other audio issues that arise).
> >
> > --
> > Rick Mann
> > rm...@latencyzero.com
> >
> >
> > --
> > 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/095C0B5B-31DB-4D54-A310-96A87507A9F3%40latencyzero.com
> .
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > Robert Nelson
> > https://rcn-ee.com/
> >
> > --
> > 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/CAOCHtYgPUQmNe5ZY0Cg09a9b8KB6JXr%3Dnvazcxio69HD%2BYufRg%40mail.gmail.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
> --
> 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/998E3319-B184-4F78-87EE-2ABE2656A663%40latencyzero.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/CALHSORowCtUj0jMGa%3Dhoq7OzLgFuQCKUiFNAce9FKeDNWsR2UA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown

>
> *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  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  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> 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> 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> 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> 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
>>>
>>> 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

Re: [beagleboard] How can I bring my 'bone completely back to as-delivered status?

On Mon, Apr 18, 2016 at 8:05 PM, blues man  wrote:

> My BBB's eMMC is apparently filled with useless junk after 2+ years of
> playing around with Ubuntu, Debian, Angstrom, Daphile, RuneAudio, JRiver
> etc etc etc. I tried to go back to the latest Debian image and reinstall
> JRiver Media Center but I'm getting multiple "no more room on device" error
> messages.  I know how to restore the defaults but I can't find any info on
> a complete reset that removes all files and data except the original
> content of the eMMC. I did have JRMC running fine last year, but like an
> idiot I decided to try Ubuntu and it's never been the same. I'm running MPD
> until I can fix this.
>

Well, if it's a Rev C: (4gb eMMC)

it was shipped from the factory with:

2014-05-14

http://beagleboard.org/latest-images

If it's a Rev A/B:
 2013-09-04

http://beagleboard.org/latest-images

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYh-riAHGFEJq1xSCceBD%2BcxqS6VGec1bY7Fc0gc1V3HQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How can I bring my 'bone completely back to as-delivered status?

2016-04-18 Thread blues man

My BBB's eMMC is apparently filled with useless junk after 2+ years of 
playing around with Ubuntu, Debian, Angstrom, Daphile, RuneAudio, JRiver 
etc etc etc. I tried to go back to the latest Debian image and reinstall 
JRiver Media Center but I'm getting multiple "no more room on device" error 
messages.  I know how to restore the defaults but I can't find any info on 
a complete reset that removes all files and data except the original 
content of the eMMC. I did have JRMC running fine last year, but like an 
idiot I decided to try Ubuntu and it's never been the same. I'm running MPD 
until I can fix this.

David

-- 
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/d9eb9a91-c653-4f7b-a4b8-1bda79fd533d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Black-vs-Green DTBs

I'm just lazy, I'd like to figure out how to make the "extra"
in am335x-boneblack-audio-emmc.dts work in the overlay... (thus we would
not need the special "dtb"..)

Regards,

On Mon, Apr 18, 2016 at 7:23 PM, Rick Mann  wrote:

> Update: I think *I* created am335x-boneblack-audio-emmc.dts, adding to my
> own confusion. Sorry about that.
> -
> There's not quite a 1-1 correspondence between black and green DTS files.
> I wouldn't expect there to be, except where the hardware on the two overlap.
>
> In this specific case, I noticed that while there is a
> am335x-boneblack-audio-emmc.dts, there's no corresponding
> am335x-bonegreen-audio-emmc.dts. It seems the boneblack one is equivalent
> to the am335x-bonegreen.dts plus two entries for clk_mcasp0. I assume the
> lack of an explicit am335x-bonegreen-audio-emmc.dts is just a minor
> oversight? I can imagine it gets unwieldy to try to have every possible
> .dts for each of the boards.
>
> I just wanted to make sure there wasn't a more specific reason why the
> green version of the file doesn't exist.
>
> I used am335x-boneblack-audio-emmc.dts, and it seems to work fine in
> 4.4.7-bone-rt-r9 (aside from the other audio issues that arise).
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
> --
> 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/095C0B5B-31DB-4D54-A310-96A87507A9F3%40latencyzero.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYgPUQmNe5ZY0Cg09a9b8KB6JXr%3Dnvazcxio69HD%2BYufRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Loading on Beaglebone Black Boot Pins?

2016-04-18 Thread Harvey White

On Mon, 18 Apr 2016 17:12:37 -0700 (PDT), you wrote:

>I'm trouble shooting a problem on a simple cape for a BeagleBone Black.
>
>I have a bipolar switch for an LED, very similar to that used for the "User 
>LEDS".
>So I have added an approximately 10Kohm load to one of the "boot pins", 
>which
>in header lingo is P8_44.
>
>P8_44 is also one of the "boot" pins.  I'm interesting in using the PRU 
>connection mode of this pin.
>
>The System Reference Manuals says the boot pins must not be *driven* prior 
>to coming out of reset (SYS_RESET goes high).
>
>So maybe my understanding of the term "driven" in this context is 
>incorrect, and it could also be interpreted as "loading",
>as in excessive resistive loading?

Driven in this case (and lots of others) means a signal connected to
that pin.

A resistor going to VCC or ground does indeed "drive" that signal.  

BOOT pins must completely float until the boot process is done, *then*
you can do something with them.

A good idea is to avoid boot pins
Another good idea is to use tri-state drivers on those pins, and turn
them on ONLY when the boot process is done.

There are a number of threads discussing this.

However, nobody has specifically said that resistors effectively drive
boot pins.  They do.

Harvey


>
>I tried an experiment on both BBB and BBG with a 10kohm resistor to ground 
>on P8_44.  Both refused to boot up and run.
>So is it a requirement to keep resistive loads off this pin during the boot 
>process?
>
>Regards,
>Greg

-- 
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/jkuahbpu3i94tkjuam7ifbc77hpue29nn4%404ax.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Loading on Beaglebone Black Boot Pins?

2016-04-18 Thread Chris Morgan

On Mon, Apr 18, 2016 at 8:12 PM, Greg  wrote:
> I'm trouble shooting a problem on a simple cape for a BeagleBone Black.
>
> I have a bipolar switch for an LED, very similar to that used for the "User
> LEDS".
> So I have added an approximately 10Kohm load to one of the "boot pins",
> which
> in header lingo is P8_44.
>
> P8_44 is also one of the "boot" pins.  I'm interesting in using the PRU
> connection mode of this pin.
>
> The System Reference Manuals says the boot pins must not be driven prior to
> coming out of reset (SYS_RESET goes high).
>
> So maybe my understanding of the term "driven" in this context is incorrect,
> and it could also be interpreted as "loading",
> as in excessive resistive loading?
>
> I tried an experiment on both BBB and BBG with a 10kohm resistor to ground
> on P8_44.  Both refused to boot up and run.
> So is it a requirement to keep resistive loads off this pin during the boot
> process?
>
> Regards,
> Greg
>

Yes.

You should avoid applying any voltage to any pin before SYS_RESET goes
high, or you'll likely permanently break something. In your case it
looks like you are changing the boot pin configuration (maybe it
defaults to an internal weak pullup?) and preventing your system from
booting. If that isn't what you intended you'll want to avoid loading
the pin until after SYS_RESET goes high.

What are you trying to accomplish with your cape and that io pin?
There are approaches that may let you both use the pin and avoiid
changing the boot strapping but it would really help to see the
circuit you are trying to use with that pin.

Chris

-- 
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/CAAPegz1YBbVrb-4Lbvf%3DMS40UjizfZxArtm%3DCRv_EQXc4368Lg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Black-vs-Green DTBs

2016-04-18 Thread Rick Mann

Update: I think *I* created am335x-boneblack-audio-emmc.dts, adding to my own 
confusion. Sorry about that.
-
There's not quite a 1-1 correspondence between black and green DTS files. I 
wouldn't expect there to be, except where the hardware on the two overlap.

In this specific case, I noticed that while there is a 
am335x-boneblack-audio-emmc.dts, there's no corresponding 
am335x-bonegreen-audio-emmc.dts. It seems the boneblack one is equivalent to 
the am335x-bonegreen.dts plus two entries for clk_mcasp0. I assume the lack of 
an explicit am335x-bonegreen-audio-emmc.dts is just a minor oversight? I can 
imagine it gets unwieldy to try to have every possible .dts for each of the 
boards.

I just wanted to make sure there wasn't a more specific reason why the green 
version of the file doesn't exist.

I used am335x-boneblack-audio-emmc.dts, and it seems to work fine in 
4.4.7-bone-rt-r9 (aside from the other audio issues that arise).

-- 
Rick Mann
rm...@latencyzero.com


-- 
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/095C0B5B-31DB-4D54-A310-96A87507A9F3%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Loading on Beaglebone Black Boot Pins?

I'm trouble shooting a problem on a simple cape for a BeagleBone Black.

I have a bipolar switch for an LED, very similar to that used for the "User 
LEDS".
So I have added an approximately 10Kohm load to one of the "boot pins", 
which
in header lingo is P8_44.

P8_44 is also one of the "boot" pins.  I'm interesting in using the PRU 
connection mode of this pin.

The System Reference Manuals says the boot pins must not be *driven* prior 
to coming out of reset (SYS_RESET goes high).

So maybe my understanding of the term "driven" in this context is 
incorrect, and it could also be interpreted as "loading",
as in excessive resistive loading?

I tried an experiment on both BBB and BBG with a 10kohm resistor to ground 
on P8_44.  Both refused to boot up and run.
So is it a requirement to keep resistive loads off this pin during the boot 
process?

Regards,
Greg


-- 
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/6081856f-8c49-453c-97b9-887bc89ad0fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Black-vs-Green DTBs

2016-04-18 Thread Rick Mann

There's not quite a 1-1 correspondence between black and green DTS files. I 
wouldn't expect there to be, except where the hardware on the two overlap.

In this specific case, I noticed that while there is a 
am335x-boneblack-audio-emmc.dts, there's no corresponding 
am335x-bonegreen-audio-emmc.dts. It seems the boneblack one is equivalent to 
the am335x-bonegreen.dts plus two entries for clk_mcasp0. I assume the lack of 
an explicit am335x-bonegreen-audio-emmc.dts is just a minor oversight? I can 
imagine it gets unwieldy to try to have every possible .dts for each of the 
boards.

I just wanted to make sure there wasn't a more specific reason why the green 
version of the file doesn't exist.

I used am335x-boneblack-audio-emmc.dts, and it seems to work fine in 
4.4.7-bone-rt-r9 (aside from the other audio issues that arise).

-- 
Rick Mann
rm...@latencyzero.com


-- 
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/501C88C3-6DDE-44C6-BD6A-2D17CE92BE56%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

Or wait, I guess I was comparing the white's eeprom to the blacks eeprom,
so they look the same. Yeah, writing a white eeprom to a black eeprom would
be bad haha :/

On Mon, Apr 18, 2016 at 3:12 PM, William Hermans  wrote:

> Thanks Gerald, and Robert. So yeah it does look different, however . . . I
> can not think of a reason why a beagleboard.org eeprom would fail on an
> element14 board. I mean they both have exactly the same hardware as far as
> device tree goes, yeah ?
>
> I mean, in the long run, I'm not sure this is really an important
> question, but is something I think is good to know. Also I was expecting
> something more complex for an eeprom "string", but heh, serves me right for
> "thinking" ;)
>
> On Mon, Apr 18, 2016 at 3:06 PM, Robert Nelson 
> wrote:
>
>>
>>
>> On Mon, Apr 18, 2016 at 5:03 PM, William Hermans 
>> wrote:
>>
>>>
 *Oh they are there, too... But since the 'blank' eeprom flasher's
 overwrite the board eeprom, the oem's need to contact me directly.. and i
 can point them directly to the image and tweak they need to do..*

 *With all the clones today, the days of just "BeagleBone Black" 100%
 clone blank eeprom are over. ;)*

 *Regards,*
>>>
>>> Yeah, I read the instructions above. So I'm curious though. Is the
>>> eeprom any different between say circuitco, and element14 BBB's ? I suppose
>>> I could dump, and diff ( if i was sure I knew how to dump correctly ).
>>>
>>
>> Here is the full list:
>>
>> https://github.com/beagleboard/image-builder/blob/master/readme.md
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> --
>> 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/CAOCHtYgcRgYTzugWHz7%3DSvrVKP2q7ObD7y_0Poz%2Bk2AsykAf8Q%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/CALHSORrswb3PeAcUmMuS23gcz4%3DayCbDcsB_DerEFC36NwQShQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

Thanks Gerald, and Robert. So yeah it does look different, however . . . I
can not think of a reason why a beagleboard.org eeprom would fail on an
element14 board. I mean they both have exactly the same hardware as far as
device tree goes, yeah ?

I mean, in the long run, I'm not sure this is really an important question,
but is something I think is good to know. Also I was expecting something
more complex for an eeprom "string", but heh, serves me right for
"thinking" ;)

On Mon, Apr 18, 2016 at 3:06 PM, Robert Nelson 
wrote:

>
>
> On Mon, Apr 18, 2016 at 5:03 PM, William Hermans 
> wrote:
>
>>
>>> *Oh they are there, too... But since the 'blank' eeprom flasher's
>>> overwrite the board eeprom, the oem's need to contact me directly.. and i
>>> can point them directly to the image and tweak they need to do..*
>>>
>>> *With all the clones today, the days of just "BeagleBone Black" 100%
>>> clone blank eeprom are over. ;)*
>>>
>>> *Regards,*
>>
>> Yeah, I read the instructions above. So I'm curious though. Is the eeprom
>> any different between say circuitco, and element14 BBB's ? I suppose I
>> could dump, and diff ( if i was sure I knew how to dump correctly ).
>>
>
> Here is the full list:
>
> https://github.com/beagleboard/image-builder/blob/master/readme.md
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> 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/CAOCHtYgcRgYTzugWHz7%3DSvrVKP2q7ObD7y_0Poz%2Bk2AsykAf8Q%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/CALHSORpUikn-djDJxw09mM%3DuZ%3DFGc2fqcjww9zZ6EjaMjwxGog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

2016-04-18 Thread Gerald Coley

It should not be. But, then again.

Gerald


On Mon, Apr 18, 2016 at 5:03 PM, William Hermans  wrote:

>
>> *Oh they are there, too... But since the 'blank' eeprom flasher's
>> overwrite the board eeprom, the oem's need to contact me directly.. and i
>> can point them directly to the image and tweak they need to do..*
>>
>> *With all the clones today, the days of just "BeagleBone Black" 100%
>> clone blank eeprom are over. ;)*
>>
>> *Regards,*
>
> Yeah, I read the instructions above. So I'm curious though. Is the eeprom
> any different between say circuitco, and element14 BBB's ? I suppose I
> could dump, and diff ( if i was sure I knew how to dump correctly ).
>
> On Mon, Apr 18, 2016 at 1:16 PM, Robert Nelson 
> wrote:
>
>>
>>
>> On Mon, Apr 18, 2016 at 3:04 PM, William Hermans 
>> wrote:
>>
>>> Robert, so which is the blank eeprom flasher ?
>>>
>>
>> Oh they are there, too... But since the 'blank' eeprom flasher's
>> overwrite the board eeprom, the oem's need to contact me directly.. and i
>> can point them directly to the image and tweak they need to do..
>>
>> With all the clones today, the days of just "BeagleBone Black" 100% clone
>> blank eeprom are over. ;)
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> --
>> 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/CAOCHtYizQDRCRp7Su85EPj2_30z5Hs99CGjbx%3Dp2cM60QP7FPw%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/CALHSORqTKJzJLYi-7KMXqKZ46dRxZsyafXTB68g8p3tiAYc9CA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.com

-- 
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/CAHK_S%2BfRPx7sV6px7EnuQT30SVe0R7vgv1Ou5aUERd-TZqcxZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

On Mon, Apr 18, 2016 at 5:03 PM, William Hermans  wrote:

>
>> *Oh they are there, too... But since the 'blank' eeprom flasher's
>> overwrite the board eeprom, the oem's need to contact me directly.. and i
>> can point them directly to the image and tweak they need to do..*
>>
>> *With all the clones today, the days of just "BeagleBone Black" 100%
>> clone blank eeprom are over. ;)*
>>
>> *Regards,*
>
> Yeah, I read the instructions above. So I'm curious though. Is the eeprom
> any different between say circuitco, and element14 BBB's ? I suppose I
> could dump, and diff ( if i was sure I knew how to dump correctly ).
>

Here is the full list:

https://github.com/beagleboard/image-builder/blob/master/readme.md

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYgcRgYTzugWHz7%3DSvrVKP2q7ObD7y_0Poz%2Bk2AsykAf8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

>
>
> *Oh they are there, too... But since the 'blank' eeprom flasher's
> overwrite the board eeprom, the oem's need to contact me directly.. and i
> can point them directly to the image and tweak they need to do..*
>
> *With all the clones today, the days of just "BeagleBone Black" 100% clone
> blank eeprom are over. ;)*
>
> *Regards,*

Yeah, I read the instructions above. So I'm curious though. Is the eeprom
any different between say circuitco, and element14 BBB's ? I suppose I
could dump, and diff ( if i was sure I knew how to dump correctly ).

On Mon, Apr 18, 2016 at 1:16 PM, Robert Nelson 
wrote:

>
>
> On Mon, Apr 18, 2016 at 3:04 PM, William Hermans 
> wrote:
>
>> Robert, so which is the blank eeprom flasher ?
>>
>
> Oh they are there, too... But since the 'blank' eeprom flasher's overwrite
> the board eeprom, the oem's need to contact me directly.. and i can point
> them directly to the image and tweak they need to do..
>
> With all the clones today, the days of just "BeagleBone Black" 100% clone
> blank eeprom are over. ;)
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> 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/CAOCHtYizQDRCRp7Su85EPj2_30z5Hs99CGjbx%3Dp2cM60QP7FPw%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/CALHSORqTKJzJLYi-7KMXqKZ46dRxZsyafXTB68g8p3tiAYc9CA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown

2016-04-18 Thread Mike

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 > 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 > 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 > 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
> 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
> 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

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
> 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>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

Re: [beagleboard] BBB ubuntu chronodot

2016-04-18 Thread Mike


On 04/18/2016 03:18 PM, b2256 wrote:
Using Beaglebone Black(BBB)Rev C, Chronodot(ds3231) rtc via i2c, and 
Ubuntu 14.04 armhf 4.4.0-armv7-x2 (Robert Nelson's armhf site).



I can get i2c recognition by BBB at 0x68 as expected with i2cdetect.  
Registration seems to work using echo to new device on i2c-2, since it 
comes up with a cat command.  I can set hwclock and check with cat   
/sys/class/rtc/rtc1 file and all seems fine, until I do a cold 
reboot.  Then everything reverts to Jan 15 01:01:00 2016.  I am 
booting from an SD disk instead of onboard.


With regard to rtc, a check on dmesg gives me a reversion back to the 
rtc0 ,


"[ 3.748545] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc 
as rtc0"


then

"[ 3.867388] PM: bootloader does not support rtc-only!"


[ 4.220591] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 
00:00:01 UTC (946684801)



Here you can see my manual entries:


[ 2481.604507] rtc-ds1307 2-0068: SET TIME!

[ 2481.608512] rtc-ds1307 2-0068: rtc core: registered ds3231 as rtc1

[ 2481.608866] i2c i2c-2: new_device: Instantiated device ds3231 at 0x68



My questions :  Why or how does the rtc instance get written over
at boot? 

Could this be a bootloader issue? 


Is it a driver issue with Ubuntu non-support(states same as ds1307)?

  I2c issue?

  Or will the Chronodot simply not work with BBB and Ubuntu?

Note:  Skill set- advanced newbie; not fresh newbie, but too hacking 
dangerous to ever be an expert!

Thank you in advance for any insight that you may have.

B2256



I hit this sometime back with Debian moving to systemd.  I haven't a 
clue if Ubuntu images are using systemd or not.  If so "unless changed" 
systemd only supports rtc0.  The answer I received from systemd mailing 
list was set the clock from userspace not kernel space.  I disagree, yet 
pretty much got nowhere with that debate.


Really not an answer, maybe a bit of help...

Mike

--
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/571550BF.9050906%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

On Mon, Apr 18, 2016 at 3:04 PM, William Hermans  wrote:

> Robert, so which is the blank eeprom flasher ?
>

Oh they are there, too... But since the 'blank' eeprom flasher's overwrite
the board eeprom, the oem's need to contact me directly.. and i can point
them directly to the image and tweak they need to do..

With all the clones today, the days of just "BeagleBone Black" 100% clone
blank eeprom are over. ;)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYizQDRCRp7Su85EPj2_30z5Hs99CGjbx%3Dp2cM60QP7FPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

Robert, so which is the blank eeprom flasher ?

On Mon, Apr 18, 2016 at 12:05 PM, Robert Nelson 
wrote:

>
>
> On Mon, Apr 18, 2016 at 1:46 PM, Phil Mills  wrote:
>
>> Thanks!  Turns out my manufacturing folks were having some PEBKAC errors
>> anyway, but thanks for pointing me to the new host.
>> Is there any substantive difference between the USB Flasher images from
>> various points in the Testing directory tree?
>>
>
> Oh, just weekly snapshots...  The latest the better...
>
> We are getting close to cutting a new jessie/v4.1.x/lxqt release for
> seeed..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> 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/CAOCHtYimSNrwEhW%2B1ZgaUFSUmrO2T7M7RXP_6u8G7KDakF9-Pg%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/CALHSORooba5SU7aYPG3%3DuO-_0%2BwHzD-x37%3DP_FZQMMypL%3DTAig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown

2016-04-18 Thread John Syne

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




> On Apr 18, 2016, at 11:31 AM, William Hermans  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  > 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 > > 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 > > 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 
 > 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
>  
> 
> 
> 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 > > 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 > 
>> wrote:
>> Yeah I recognize

Re: [beagleboard] Re: Beagle Board outdoors?

2016-04-18 Thread Graham Haddock

The problem is, that if it is not perfectly airtight, then the next time
you open it, you find the little silica gel packets floating in a puddle of
water.  :-)

If it is not perfectly airtight, then every time it rains, or a cold front
passes, the box cools and it sucks in a little wet air (or rain).  If the
leak is not at the bottom of the box, then the condensation builds up as
water there.  It takes a year or so.

It is easier to drill a little 2 or 3 mm hole in the center of the bottom
of the box, than to make something perfectly airtight.  Particularly if you
have wires going into and out of the box.


--- Graham

==


On Mon, Apr 18, 2016 at 12:32 PM, evilwulfie  wrote:

> Or if your sure the box is sealed and there is no chance of water getting
> in use some silica jell in the little pouches that will absorb all the
> moisture that is in the box.
>
>
>
> On 4/18/2016 7:36 AM, Graham wrote:
>
>
>
> On Monday, April 18, 2016 at 7:49:09 AM UTC-5, Gerald wrote:
>>
>> Put it in a watertight box. Google NEMA boxes.
>>
>> Gerald
>>
>>
>> Put it in a watertight NEMA box, but always make sure there is a 'weep
> hole' in the bottom of the box.
> Otherwise the humidity inside the box when you closed it will condense out
> on the components when the temperature drops.
>
> The 'weep hole' needs to be big enough to let humidity equalize between
> the inside and out side, small enough to not let insects get inside, and
> somewhere in the central bottom where rain will never hit the hole.
>
> --- Graham
>
> ==
>
>
> --
> 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/95b1f388-34d3-4d48-8fd4-956c3827169b%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/uPEfixR3rrQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/57151A32.5090105%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/CANN_KV5jWuFQzbHZohQ5VRgvLWWLqEB6pyqprJ%3Dtv-kY8SyHtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB ubuntu chronodot

2016-04-18 Thread b2256

Using Beaglebone Black(BBB)Rev C, Chronodot(ds3231) rtc via i2c, and Ubuntu 
14.04 armhf 4.4.0-armv7-x2 (Robert Nelson's armhf site). 


I can get i2c recognition by BBB at 0x68 as expected with i2cdetect.  
Registration seems to work using echo to new device on i2c-2, since it 
comes up with a cat command.  I can set hwclock and check with cat   
/sys/class/rtc/rtc1 file and all seems fine, until I do a cold reboot.  
Then everything reverts to Jan 15 01:01:00 2016.  I am booting from an SD 
disk instead of onboard.

With regard to rtc, a check on dmesg gives me a reversion back to the rtc0 
, 

"[ 3.748545] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as 
rtc0"
then

"[ 3.867388] PM: bootloader does not support rtc-only!"


[ 4.220591] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 
00:00:01 UTC (946684801) 


Here you can see my manual entries:


[ 2481.604507] rtc-ds1307 2-0068: SET TIME! 

[ 2481.608512] rtc-ds1307 2-0068: rtc core: registered ds3231 as rtc1 

[ 2481.608866] i2c i2c-2: new_device: Instantiated device ds3231 at 0x68 



My questions :  Why or how does the rtc instance get written over at boot?  

Could this be a bootloader issue?  

Is it a driver issue with Ubuntu non-support(states same as ds1307)?

  I2c issue?

  Or will the Chronodot simply not work with BBB and Ubuntu?

Note:  Skill set- advanced newbie; not fresh newbie, but too hacking 
dangerous to ever be an expert!
Thank you in advance for any insight that you may have.

B2256

-- 
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/9e613420-9644-4603-81e6-f4d0e1171f7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

On Mon, Apr 18, 2016 at 1:46 PM, Phil Mills  wrote:

> Thanks!  Turns out my manufacturing folks were having some PEBKAC errors
> anyway, but thanks for pointing me to the new host.
> Is there any substantive difference between the USB Flasher images from
> various points in the Testing directory tree?
>

Oh, just weekly snapshots...  The latest the better...

We are getting close to cutting a new jessie/v4.1.x/lxqt release for seeed..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYimSNrwEhW%2B1ZgaUFSUmrO2T7M7RXP_6u8G7KDakF9-Pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

2016-04-18 Thread Phil Mills

Thanks!  Turns out my manufacturing folks were having some PEBKAC errors
anyway, but thanks for pointing me to the new host.
Is there any substantive difference between the USB Flasher images from
various points in the Testing directory tree?

On Mon, Apr 18, 2016 at 8:59 AM Robert Nelson 
wrote:

> On Mon, Apr 18, 2016 at 9:51 AM, Phil Mills  wrote:
>
>> Robert,
>>
>> It's been a while on this, but can you re-post the flasher img.xz
>> someplace (bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz
>> 
>> )?
>>
>> I see you've taken it down from your website and my backup copy no longer
>> validates correctly.  Since this is actually a pretty valuable tool, is
>> there a way that it could be posted up permanantly on one of the Beaglebone
>> websites or GitHub pages?
>>
>
> Hi Phil,
>
> I have an archive site now hosted at dreamhost: (taking full advantage of
> their "unlimited" space...)
>
> https://rcn-ee.online/rootfs/bb.org/
>
> to relieve "disk space" pressure on my linode host (rcn-ee.net)..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>

-- 
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/CAOCPF%2BtpYKMpvEuvrf7VBaKMOSXEThtjG%2B3bwzj06YT-Xn8ZjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown

#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  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  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  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> 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
>>
>> 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  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> 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.
>>>
>>>
>>>
>>
>>
>> 
>>  Virus-free.
>> www.avast.com
>> 
>>
>> --
>> 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/571443FC.6020505%40gmail.com

Re: [beagleboard] CDC_ETHER in Debian 3.8.13-bone70

2016-04-18 Thread Matt99eo

Ok I see it now with lsusb:

lsusb
Bus 001 Device 004: ID 1e2d:00a0  
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

And in my dmesg log I see it registering:

dmesg |grep cdc_ether
[0.709427] usbcore: registered new interface driver cdc_ether
[1.859965] cdc_ether 1-1:1.0: usb_probe_interface
[1.859981] cdc_ether 1-1:1.0: usb_probe_interface - got id
[1.885585] cdc_ether 1-1:1.0 usb0: register 'cdc_ether' at 
usb-musb-hdrc.1.auto-1, CDC Ethernet Device, 02:80:70:00:04:70

What am I missing to establish the Ethernet over USB connection? 


On Monday, April 18, 2016 at 9:03:22 AM UTC-7, RobertCNelson wrote:
>
>
>
> On Mon, Apr 18, 2016 at 10:57 AM, Matt99eo  > wrote:
>
>> Hi RC,
>>
>> Sorry for the limited information. Just got word the document I am 
>> working with is public (attached)
>>
>> The device I am working with is a Skywire LTE CAT1 Module (Gemalto ELS35).
>>
>> Here is what the helpful support is telling me:
>> 
>>
>> CDC_ETH is a device support class that allows for the modem to act as LAN 
>> connection over USB. There isn't a VIP/PID that needs to be added for the 
>> kernel to support it, the Kernel needs to be built to support the CDC_ETH 
>> class.
>>
>> When the device is loaded as a CDC_ETH device you will see it enumerate 
>> in your system as something like this: 
>>
>> [ 17.90] cdc_ether 1-1:1.0 usb0: register 'cdc_ether' at 
>> usb-ehci-platform-1, CDC Ethernet Device, 02:10:81:64:89:60
>> _
>>
>> When I use lsusb I don't see the device listed (believe I should see  Bus 
>> 001 Device 001: ID 1d6b:0002)
>>
>
> That's the root hub: http://www.linux-usb.org/usb.ids
>
> 1d6b Linux Foundation
>
>   0001  1.1 root hub
>   0002  2.0 root hub
>   0003  3.0 root hub
>   0100  PTP Gadget
>   0101  Audio Gadget
>   0102  EEM Gadget
>   0103  NCM (Ethernet) Gadget
>   0104  Multifunction Composite Gadget
>   0105  FunctionFS Gadget
>   0200  Qemu Audio Device
>
> run "lsusb" again. ;)
>
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

-- 
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/39d5ea0a-120b-44e1-a200-c090a166505d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle Board outdoors?

2016-04-18 Thread evilwulfie

Or if your sure the box is sealed and there is no chance of water
getting in use some silica jell in the little pouches that will absorb
all the moisture that is in the box.



On 4/18/2016 7:36 AM, Graham wrote:
>
>
> On Monday, April 18, 2016 at 7:49:09 AM UTC-5, Gerald wrote:
>
> Put it in a watertight box. Google NEMA boxes.
>
> Gerald
>
>
> Put it in a watertight NEMA box, but always make sure there is a 'weep
> hole' in the bottom of the box.
> Otherwise the humidity inside the box when you closed it will condense
> out on the components when the temperature drops.
>
> The 'weep hole' needs to be big enough to let humidity equalize
> between the inside and out side, small enough to not let insects get
> inside, and somewhere in the central bottom where rain will never hit
> the hole.
>
> --- Graham
>
> ==
>
>
> -- 
> 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/95b1f388-34d3-4d48-8fd4-956c3827169b%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

-- 
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/57151A32.5090105%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown

2016-04-18 Thread John Syne

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  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  > 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 
>>> > 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
  
 
 
 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  > 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 > 
> 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.
> 
> 
>>> 
>>> 
>>>  
>>> 
>>>   Virus-free. www.avast.com 
>>> 
>>> 
>>> -- 
>>> 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

Re: [beagleboard] Re: Beagle Board outdoors?

2016-04-18 Thread CEinTX

We use boxes from Polycase for some of our projects.
They have a family of Nema boxes that should be suited, with a little work, 
to using with the BBB.
Look here:  http://www.polycase.com/waterproof-nema-gasket

GL,
Matt

On Monday, April 18, 2016 at 10:35:40 AM UTC-5, Specialcomp wrote:
>
> Special Computing has various BBB clones for Industrial temp (-40 to 85 
> deg C)
>
> https://specialcomp.com/beaglebone
> On Apr 18, 2016 3:42 AM, "Greg"  
> wrote:
>
>> I've also got an outdoor application.  I want to run a BBG mounted to the 
>> outside of my house.
>>
>> Did you find any good solution for this?
>>
>> Regards,
>> Greg
>>
>>
>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/72046c9e-6b53-4fef-b2b9-5c205ebbab0c%40googlegroups.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/aa3fe70d-0c91-418a-b84c-ef59370fad52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] CDC_ETHER in Debian 3.8.13-bone70

On Mon, Apr 18, 2016 at 10:57 AM, Matt99eo 
wrote:

> Hi RC,
>
> Sorry for the limited information. Just got word the document I am working
> with is public (attached)
>
> The device I am working with is a Skywire LTE CAT1 Module (Gemalto ELS35).
>
> Here is what the helpful support is telling me:
> 
>
> CDC_ETH is a device support class that allows for the modem to act as LAN
> connection over USB. There isn't a VIP/PID that needs to be added for the
> kernel to support it, the Kernel needs to be built to support the CDC_ETH
> class.
>
> When the device is loaded as a CDC_ETH device you will see it enumerate in
> your system as something like this:
>
> [ 17.90] cdc_ether 1-1:1.0 usb0: register 'cdc_ether' at
> usb-ehci-platform-1, CDC Ethernet Device, 02:10:81:64:89:60
> _
>
> When I use lsusb I don't see the device listed (believe I should see  Bus
> 001 Device 001: ID 1d6b:0002)
>

That's the root hub: http://www.linux-usb.org/usb.ids

1d6b Linux Foundation

0001  1.1 root hub
0002  2.0 root hub
0003  3.0 root hub
0100  PTP Gadget
0101  Audio Gadget
0102  EEM Gadget
0103  NCM (Ethernet) Gadget
0104  Multifunction Composite Gadget
0105  FunctionFS Gadget
0200  Qemu Audio Device

run "lsusb" again. ;)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYi%3Dv76nC%2B1C6fM_D8p3th0XCEvZXkTA7%3D%3D8kfiDthKmZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown

2016-04-18 Thread John Syne

The way I read this is all you have to do is set ALARM2 when the AC line fails. 
If there is no ALARM2, it switches off 15uS later. 

Regards,
John




> On Apr 17, 2016, at 11:06 PM, William Hermans  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  > 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 
>>> > 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
  
 
 
 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  > 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 > 
> 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.
> 
> 
>>> 
>>> 
>>>  
>>> 
>>>   Virus-free. www.avast.com 
>>> 
>>> 
>>> -- 
>>> 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/571443FC.6020505%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

Re: [beagleboard] Re: Beagle Board outdoors?

2016-04-18 Thread Special Computing

Special Computing has various BBB clones for Industrial temp (-40 to 85 deg
C)

https://specialcomp.com/beaglebone
On Apr 18, 2016 3:42 AM, "Greg"  wrote:

> I've also got an outdoor application.  I want to run a BBG mounted to the
> outside of my house.
>
> Did you find any good solution for this?
>
> Regards,
> Greg
>
>
> --
> 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/72046c9e-6b53-4fef-b2b9-5c205ebbab0c%40googlegroups.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/CAMPEx0dwtES%2BS6nc%2B1PrVa8PHVzdpTgCp1%2BgKB4iHDfPTja%3DUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

2016-04-18 Thread Phil Mills

Robert,

It's been a while on this, but can you re-post the flasher img.xz someplace 
(bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz 

)?

I see you've taken it down from your website and my backup copy no longer 
validates correctly.  Since this is actually a pretty valuable tool, is 
there a way that it could be posted up permanantly on one of the Beaglebone 
websites or GitHub pages?

-phil

On Tuesday, September 8, 2015 at 3:30:18 PM UTC-6, RobertCNelson wrote:
>
> On Tue, Sep 8, 2015 at 4:15 PM, Phil Mills  > wrote: 
> > I have inherited responsibility for a bunch of 3rd-party direct clones 
> of a 
> > Beaglebone Black C5 (only known change is in silkscreening). 
> > 
> > Since none of these have any contents written to the onboard EEPROM, 
> they 
> > fail to boot with "C" written to the serial console with no uSD 
> card, 
> > and 
> > 
> >> 
> >> U-Boot SPL 2015.01-1-gb2412df (Jan 29 2015 - 15:01:06) 
> >> Incorrect magic number (0x) in EEPROM 
> >> Could not get board ID. 
> >> Incorrect magic number (0x) in EEPROM 
> >> Could not get board ID. 
> >> Unknown board, cannot configure pinmux.### ERROR ### Please RESET the 
> >> board ### 
> > 
> > 
> > ...written to the console when I try to boot it from a uSD cards with a 
> > stock BBB image (the 2015-03-01 Debian 7.8 image).  So clearly I need to 
> get 
> > some good contents into the EEPROM. 
> > 
> > 
> > I've been trying to hunt down instructions for how to access the U-Boot 
> > prompt to manually write the EEPROM via the i2c bus, but haven't hit any 
> > luck there. 
> > 
> > 
> > Robert Nelson's posted links in the past to what he's described as the 
> > "factory images for flashing boards with blank EEPROMs", but those links 
> (to 
> > rcn-ee.org) are stale/dead or behind apparently access-controlled 
> folders on 
> > his server. 
> > 
> > 
> > 
> > Could anyone provide a good set of instructions for getting access to a 
> > uBoot prompt from a stock flasher image OR provide current links to the 
> > blank-EEPROM manufacturing images (or equivalents) that RCN's 
> referenced? 
>
> So the "blank-flasher" (did everything by default) went away.  Instead 
> we now have a "usbflasher".. 
>
> Step 1: (microSD) 
>
>
> http://rcn-ee.com/rootfs/bb.org/testing/2015-09-06/usbflasher/BBB-blank-debian-8.1-usbflasher-armhf-2015-09-06-2gb.bmap
>  
>
> http://rcn-ee.com/rootfs/bb.org/testing/2015-09-06/usbflasher/BBB-blank-debian-8.1-usbflasher-armhf-2015-09-06-2gb.img.xz
>  
>
> (bmaptools 3.2) 
> sudo bmaptools copy --bmap *.bmap *.img.xz /dev/sdX 
>
> Step 2: (usb drive) 
> Format it as fat32, 2 or 3 files "custom: job.txt" and the image files.. 
>
> For example: 
>
> to flash: 2015-03-01 
>
> First download the base image: 
>
>
> http://rcn-ee.com/rootfs/bb.org/release/2015-03-01/lxde-4gb/bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz
>  
>
> Then the "eeprom" 
>
>
> https://raw.githubusercontent.com/RobertCNelson/boot-scripts/master/device/bone/bbb-eeprom.dump
>  
>
> finally crate the "job.txt" file 
>
> abi=aaa 
> conf_eeprom_file=bbb-eeprom.dump 
> conf_eeprom_compare=335 
> conf_image=bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz 
> conf_resize=enable 
> conf_partition1_startmb=1 
> conf_partition1_fstype=0xE 
> conf_partition1_endmb=96 
> conf_partition2_fstype=0x83 
> conf_root_partition=2 
>
> Step 3: (flashing) 
>
> Insert "microSD" with usbflasher image bmap'ed to it.. 
> Insert "usb flash drive" with 
> bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz, bbb-eeprom.dump 
> & job.txt all in the base directory 
> GND TP4 (write protect on eeprom) 
> Power board 
>
> Serial Log the first one to make sure it correctly flashes.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
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/819ae9e3-b827-4227-9291-4009016cd450%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Working links to blank-EEPROM flasher image?

On Mon, Apr 18, 2016 at 9:51 AM, Phil Mills  wrote:

> Robert,
>
> It's been a while on this, but can you re-post the flasher img.xz
> someplace (bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz
> 
> )?
>
> I see you've taken it down from your website and my backup copy no longer
> validates correctly.  Since this is actually a pretty valuable tool, is
> there a way that it could be posted up permanantly on one of the Beaglebone
> websites or GitHub pages?
>

Hi Phil,

I have an archive site now hosted at dreamhost: (taking full advantage of
their "unlimited" space...)

https://rcn-ee.online/rootfs/bb.org/

to relieve "disk space" pressure on my linode host (rcn-ee.net)..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYhwpb34bm%2BNfFrQY2Q5hy6AVhXjZpOpDtWjj%3DapkkkgyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle Board outdoors?

2016-04-18 Thread Graham



On Monday, April 18, 2016 at 7:49:09 AM UTC-5, Gerald wrote:
>
> Put it in a watertight box. Google NEMA boxes.
>
> Gerald
>
>
> Put it in a watertight NEMA box, but always make sure there is a 'weep 
hole' in the bottom of the box.
Otherwise the humidity inside the box when you closed it will condense out 
on the components when the temperature drops.

The 'weep hole' needs to be big enough to let humidity equalize between the 
inside and out side, small enough to not let insects get inside, and 
somewhere in the central bottom where rain will never hit the hole.

--- Graham

==


-- 
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/95b1f388-34d3-4d48-8fd4-956c3827169b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Instructions to get OpenGL ES acceleration on BeagleBone Black running Debian

2016-04-18 Thread Jean-Sebastien Stoezel

Hi Juozapas:

Thank you for sharing your experience. I have been cross compiling widget 
based applications with LinuxFB for the BeagleBone and I would like to 
switch to Qt Quick2. I am guessing that since you got Qt Quick to run on 
the BBB you may also know how to compile Qt Quick.

So far, whenever I compile for eglfs I get an error message along the 
lines: "openGL is not configured or available for this platform". I have 
googled around and I have people reporting the same issue, though I have 
yet to find a solution for this.

Would it be possible for you to share how you got to compile Qt with Qt 
Quick and eglfs?

Regards,
JS


On Wednesday, October 14, 2015 at 1:45:41 PM UTC-5, Juozapas Adomaitis 
wrote:
>
> Hello,
>
> I have been researching the possibility to run Qt Quick 2
> applications directly on BeagleBoard Black rev. C with the
> display connected to HDMI. In the process I have put together
> instructions to get OpenGL ES acceleration working (which is a
> required by Qt Quick 2). I am posting them here in the hope that
> they can be useful to someone.
>
> Regarding my experiments, the HDMI port worked with 2 monitors
> out of 4 I have tried - disappointing. Qt Quick 2 was impossibly
> slow using software rendering under X in 24bpp mode. I couldn't
> get it to run in 16bpp mode; it displayed this error:
>Cant find EGLConfig, returning null config
>Unable to find an X11 visual which matches EGL config 0
>Could not initialize OpenGL
> It worked ok in fullscreen mode (EGLFS) after installing the
> drivers.
>
> ==
> 3 steps to get hardware OpenGL ES acceleration on BeagleBone
> Black running Debian (tested 2015-10 on wheezy, jessie and sid).
>
> Note that after following the steps you will be able to run a
> single fullscreen OpenGL ES application (e.g. Qt Quick 2 in EGLFS
> mode) and nothing else, meaning:
> * 3D acceleration in X server doesn't work on BBB and apparently
>   won't work anytime in the future
> * Wayland can run with accelerating compositing (window drawing
>   handled by the GPU chip), but starting OpenGL applications
>   won't work. For this to work the graphics driver must have
>   built-in Wayland support, exposing the EGL_EXT_platform_wayland
>   EGL extension. Robert Nelson mentioned on IRC that TI is
>   working on this and progress can be followed here:
>   
> http://git.ti.com/gitweb/?p=graphics/omap5-sgx-ddk-um-linux.git;a=summary
>
> 1. First pick a kernel version from this list of kernel modules
>for the GPU (the packages are from the
>http://repos.rcn-ee.com/debian/ repo):
>$ apt-cache search ti-sgx-es8-modules
>Then install the kernel together with the modules. For
>example, if you picked ti-sgx-es8-modules-3.14.54-ti-r77, run:
>$ apt-get install -y 
> {ti-sgx-es8-modules,linux-image,linux-firmware-image}-3.14.54-ti-r77
> 2. On an x86 Linux computer run this (an x86 host is needed
>because an x86 binary installer from TI will be unpacked):
>$ git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git
>$ cd ti-linux-kernel-dev
>$ ./sgx_create_package.sh
>$ scp deploy/GFX_*_es8.x.tar.gz :/tmp/
> 3. Now install the utilities on your BBB and reboot:
>$ cd /
>$ sudo tar zxf /tmp/GFX_*_es8.x.tar.gz
>$ sudo /opt/gfxinstall/sgx-install.sh
>
> Qt Quick 2 fullscreen programs can be launched from the terminal
> or within Wayland by exporting these variables:
> $ export QT_QPA_PLATFORM=eglfs
> $ export QT_QPA_EVDEV_KEYBOARD_PARAMETERS="grab=1"
> $ export QT_QPA_EVDEV_MOUSE_PARAMETERS="grab=1"
>
> Wayland with accelerated compositing (but without the possibility
> to launch windowed OpenGL programs) can be run like this:
> $ weston-launch -- --backend=fbdev-backend.so --use-gl
>
>

-- 
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/dc720efc-7fb9-448c-8241-3ccf9b7ce730%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle Board outdoors?

2016-04-18 Thread Gerald Coley

Put it in a watertight box. Google NEMA boxes.

Gerald

On Mon, Apr 18, 2016 at 5:42 AM, Greg  wrote:

> I've also got an outdoor application.  I want to run a BBG mounted to the
> outside of my house.
>
> Did you find any good solution for this?
>
> Regards,
> Greg
>
>
> --
> 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/72046c9e-6b53-4fef-b2b9-5c205ebbab0c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.com

-- 
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/CAHK_S%2Bcz6ZKfNqeH097zaC7m2HjiSO-xuS%2Bx0XUMx7xWwBS%2BKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beagle Board outdoors?

I've also got an outdoor application.  I want to run a BBG mounted to the 
outside of my house.

Did you find any good solution for this?

Regards,
Greg


-- 
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/72046c9e-6b53-4fef-b2b9-5c205ebbab0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Battery shutdown