[beagleboard] Connect Through MiniUSB

[Nezzers]

Hello, 

Full disclosure, I know very very little about the Beagle Bone, and have 
never used anything like it before. I literally cannot be underestimated. 
Anyway.

Following instructions on this page, 
https://github.com/foosel/OctoPrint/wiki/Setup-BeagleBone-Black-Rev-C-(Jessie) 
I flashed an image to my beaglebone. Except I cannot get it to display 
anything. When I connect it to an ethernet cable it doesn't show up on the 
network. When I connect it to my laptop via mini it doesn't show up. (After 
installing the 64 bit drivers for it and following the instructions on this 
page https://www.mail-archive.com/beagleboard@googlegroups.com/msg04529.html

I'm at a loss. I simply cannot find this device anyway I try and I'm 
becoming very frustrated.


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

Re: [beagleboard] Re: Using BeagleBoneBlack to emulate USB keyboard?

[William Park]

Thank you.  It's been bookmarked and downloaded.  I'll start reading.  I'm
encouraged by the fact that you can script this.
-- 
William

On Tue, Dec 1, 2015 at 5:02 PM, William Hermans  wrote:

> SO, the companion slides to go with those files:
> https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Phil-Polstra-One-device-to-Pwn-them-all.pdf
> related material starts at page 22.
>
> Great job Phil. I did not realize creating a faux USB HID device was so
> easy. Well, "easy" when one lays out in great detail how it's done ;)
>
> On Tue, Dec 1, 2015 at 2:18 PM, William Hermans  wrote:
>
>> So Phil . . . if you're going to send files to others on the group, you
>> may want to leave out files such as "attackWindows.py" . . .heh ! ;)
>>
>> On Tue, Dec 1, 2015 at 1:36 PM, Philip Polstra 
>> wrote:
>>
>>> I did a talk about how to do this at DEFCON this year.   One device to
>>> pwn them all.  Files you need here
>>> https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Phil-Polstra-Extras.rar
>>>
>>> On Tue, Dec 1, 2015 at 2:12 PM Ed of the Mountain 
>>> wrote:
>>>

 Linux Gadget Drivers + BeagleBone hardware should allow you to emulate
 a USB keyboard.
 http://www.armadeus.com/wiki/index.php?title=USB_Gadget

 If you are emulating a keyboard, no PC driver is needed.

 -Ed


 On Monday, November 30, 2015 at 8:49:57 AM UTC-6, William Park wrote:
>
> Hi,
>
> I have an old BeagleBone Black (A5A, 2GB version), and I would like to
> use it to emulate an external USB keyboard.  I was thinking... I would
> SSH into BBB and run some commands to send keymap data to PC through
> - either mini-USB port
> - or debug serial-to-USB cable.
> As far as PC is concerned, it's receiving key presses.
>
> Is this possible?
> Where can I start my reading?
> --
> William
>
 --
 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.
 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.
>>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Connect Through MiniUSB

[Robert Nelson]

On Wed, Dec 2, 2015 at 9:20 AM, Nezzers  wrote:
> Hello,
>
> Full disclosure, I know very very little about the Beagle Bone, and have
> never used anything like it before. I literally cannot be underestimated.
> Anyway.
>
> Following instructions on this page,
> https://github.com/foosel/OctoPrint/wiki/Setup-BeagleBone-Black-Rev-C-(Jessie)
> I flashed an image to my beaglebone. Except I cannot get it to display
> anything. When I connect it to an ethernet cable it doesn't show up on the
> network. When I connect it to my laptop via mini it doesn't show up. (After
> installing the 64 bit drivers for it and following the instructions on this
> page https://www.mail-archive.com/beagleboard@googlegroups.com/msg04529.html
>
> I'm at a loss. I simply cannot find this device anyway I try and I'm
> becoming very frustrated.

Please state the file name of the file you flashed to the eMMC..

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

[beagleboard] Connect Through MiniUSB

[WZ9V]

I helped write those instructions.  Before you try to get the whole OctoPrint 
system going I'd get familiar with the plain BeagleBone first.  Start with the 
recommended image from BeagleBoard.org and connect to that and get familiar 
with it first.

Full disclosure, I switched over to a Raspberry Pi2 using the OctoPi image.  
Those instructions were for what is an old Wheezy image nowadays and may need 
some tweaking if used with a newer Wheezy or Jessie image.

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

[beagleboard] Re: Using gpio2[4] as chip select 2 for SPI1

[Joe]

It turns that the spi-omap2 driver in Linux 4.1 does not support GPIO chip 
selects.  However, Linux 4.3 rc7 supports it with a patch.  I wrote up 
details on using the mikroBUS Cape with 4 SPI devices here: 
 
http://dev.iachieved.it/iachievedit/adventures-in-beaglebone-black-device-overlays-and-spi/

and explain the patch to the spi-omap2 driver here: 
 http://dev.iachieved.it/iachievedit/gpio-chip-selects-with-the-beaglebone/

Hopefully it's useful to someone wrestling with multiple SPI devices on the 
BeagleBone.

Joe


On Sunday, November 15, 2015 at 10:45:06 PM UTC-6, Joe wrote:
>
>
> Howdy.
>
> I came into possession of a mikroBUS Cape (
> http://beagleboard.org/project/mikrobus) and have been using it to learn 
> how to write a .dts overlay.  Since there are 4 slots for clickboards on 
> the cape and I have 4 SPI boards (4-20mA T Click), I figured I'd try to 
> create a single .dts that exposed all 4 as SPI devices.
>
> Ignoring SPI0 (routed to "Host 3" on the mikroBUS Cape) for now, I have 
> Host 1 and Host 2 working.  These map directly to SPI1.0 and SPI1.1, but I 
> cannot get a "SPI1.2" enabled (Host4).  The mikroBUS Cape schematic shows 
> that chipselect for Host 4 is routed to P8.10, so I thought I could add 
> that pin (gpio2_4) as OUTPUT_PULLUP | MODE 7, and then simply add a third 
> fragment for the third chipselect.
>
>   spi1@2 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "spidev";
> reg = <2>;
> spi-max-frequency = <1600>;
> spi-cpol;
> spi-cpha;
>   };
>
> Unfortunately this fails with a "cs2 >= max2" error when I load the 
> overlay.
>
> Reading around I'm trying to figure out, okay, how do I increase the 
> number of SPI devices on the SPI1 bus.  I've read about:
>
> num-cs
> num-chipselects
> cs-gpios
>
> When using cs-gpios like this:
>
>   cs-gpios = <0>, <1>, < 4 0>;
>
> I get 
>
> [  171.494015] /ocp/spi@481a: could not get #gpio-cells for 
> /ocp/interrupt-controller@4820
>
> My complete dts is at http://pastebin.com/BvxZ3fa2
>
> TL;DR:  How can I enable a 3rd chipselect for SPI1 where the CS is mapped 
> to P8.11 (gpio2[4])?
>

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

[beagleboard] Battery powered USB HUB on a custom cape

[Iñigo Martínez]

Hi,

We have build a custom cape, with an USB 2514 hub chip[0], with several 
devices connected not powered by the USB, and a socket for an external 
battery as a power source backup.

With this scenario, we are testing the cape when power source is missing 
(just unpluging the 5V power source), but the hub starts to fail stating 
that there is no power, even with the battery connected. This are the 
messages we see on battery power:

Dec  2 16:18:38 baliza1 kernel: [ 2631.231775] musb-hdrc musb-hdrc.1.auto: 
VBUS_ERROR in a_host (91, 

Re: [beagleboard] Connect Through MiniUSB

[nezzers]

BBB-eMMC-flasher-debian-8.2-lxqt-4gb-armhf-2015-11-29-4gb.img

On Wednesday, December 2, 2015 at 10:45:09 AM UTC-5, RobertCNelson wrote:
>
> On Wed, Dec 2, 2015 at 9:20 AM, Nezzers  
> wrote: 
> > Hello, 
> > 
> > Full disclosure, I know very very little about the Beagle Bone, and have 
> > never used anything like it before. I literally cannot be 
> underestimated. 
> > Anyway. 
> > 
> > Following instructions on this page, 
> > 
> https://github.com/foosel/OctoPrint/wiki/Setup-BeagleBone-Black-Rev-C-(Jessie)
>  
> > I flashed an image to my beaglebone. Except I cannot get it to display 
> > anything. When I connect it to an ethernet cable it doesn't show up on 
> the 
> > network. When I connect it to my laptop via mini it doesn't show up. 
> (After 
> > installing the 64 bit drivers for it and following the instructions on 
> this 
> > page 
> https://www.mail-archive.com/beagleboard@googlegroups.com/msg04529.html 
> > 
> > I'm at a loss. I simply cannot find this device anyway I try and I'm 
> > becoming very frustrated. 
>
> Please state the file name of the file you flashed to the eMMC.. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Battery powered USB HUB on a custom cape

[Gerald Coley]

Sounds like you may have a HW issue. But that is only a guess based on a
few sentences from you. A schematic could help in understanding this issue.

Gerald


On Wed, Dec 2, 2015 at 10:41 AM, Iñigo Martínez 
wrote:

>
> Hi,
>
> We have build a custom cape, with an USB 2514 hub chip[0], with several
> devices connected not powered by the USB, and a socket for an external
> battery as a power source backup.
>
> With this scenario, we are testing the cape when power source is missing
> (just unpluging the 5V power source), but the hub starts to fail stating
> that there is no power, even with the battery connected. This are the
> messages we see on battery power:
>
> Dec  2 16:18:38 baliza1 kernel: [ 2631.231775] musb-hdrc musb-hdrc.1.auto:
> VBUS_ERROR in a_host (91,  Dec  2 16:18:38 baliza1 kernel: [ 2631.449402] musb-hdrc musb-hdrc.1.auto:
> VBUS_ERROR in a_wait_vrise (91,  Dec  2 16:18:38 baliza1 kernel: [ 2631.601845] musb-hdrc musb-hdrc.1.auto:
> VBUS_ERROR in a_wait_vrise (91,  Dec  2 16:18:39 baliza1 kernel: [ 2631.754267] musb-hdrc musb-hdrc.1.auto:
> VBUS_ERROR in a_wait_vrise (90, 
> Looking at the messages looks like that even with external power, it
> powers off the hub and the different devices connected to it. Is there any
> setup/workaround that we can do to avoid this problem ?
>
> Best regards,
>
> [0]
> http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=EVB-USB2514B-FS
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/

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

[beagleboard] Re: GPIO 1 28 on Debian

[Joe]

It sounds like the line is configured to be a clock signal, perhaps it is 
in MODE 6 (mcasp0_aclkr_mux3)?

What dtb/overlays are you using when booting?

On Tuesday, December 1, 2015 at 1:30:56 PM UTC-6, rshiel...@gmail.com wrote:
>
> After booting Debian for Beaglebone Black I looked at P9 pin 12 (GPIO 1 
> 28) on an oscilloscope, their is a positive 65ms wide positive pulse that 
> repeats approximately every second. 
>
> Is this pin not set up as a GPIO pin? 
>
> I tried 
>
> echo 60 > /sys/class/gpio/export
>
>
> However when I tried 
>
> ls -al /sys/class/gpio
>
>
> after this gpio60 did not show up. 
>

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

Re: [beagleboard] Re: Out yet?

[Jason Kridner]

I'm around here. Not much to add except those are all bogus purchase
links. On the official product page (http://beagleboard.org/x15), we
have nothing but a "register your interest" link right now. Once the
board reaches production and I have an official list of distributors
who will have boards in stock in the first production run, I'll update
the page with a drop-down list of distributors and send out a
notification e-mail to all those who have registered interest.

For serious contributors to open source projects, I've got a small
stash of boards I've been handing out. It requires that you actually
engage the lists and make public commitments to what you are going to
contribute. For those paying attention, it shouldn't be that hard.
"I'll test it out" isn't a significant contribution.

On Wed, Dec 2, 2015 at 1:53 PM, Gerald Coley  wrote:
> I suggest that you contact Jason Kridner. He might be able to help.
>
> Gerald
>
>
> On Wed, Dec 2, 2015 at 12:31 PM,  wrote:
>>
>> I have tried order from both of those places, both ended up telling me not
>> in stock, and canceled my order. They both told me 12 week lead time with is
>> same as everywhere else. My Master degree project has been highly delayed
>> due to this, I dont even know how to finish my project in time, before next
>> feb
>>
>> On Sunday, November 29, 2015 at 9:05:03 AM UTC-8, Graham wrote:
>>>
>>> I found another one:
>>>
>>> http://www.nextwarehouse.com/item/?2221755_g10e
>>>
>>> Claims they have one in stock.
>>>
>>> I am sure they will say they have just sold it to someone else if you
>>> order it, and your waiting time for the next delivery is 8 weeks.
>>> Except that they will keep forgetting to take that one available off the
>>> website.
>>>
>>> I had Element 14 do that to me during one of the BBB shortages.
>>> I initially thought it was an honest mistake, but after a few weeks of
>>> that one unit in stock still being advertised for sale, I wrote to them
>>> telling them what I thought of their marketing practices.
>>> They wrote back apologizing, and pretty much admitting that is what had
>>> happened, that it was some kind of administrative error, and was not
>>> intentional, etc., etc.
>>> But they still did not take that one non-existant unit off their webpage
>>> for several more weeks.
>>>
>>> I don't buy from them anymore, either.
>>>
>>> I guess the good news, is that it means a lot of people are interested in
>>> the X-15, and it will be a success.
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>>
>>>
>>> On Sun, Nov 29, 2015 at 10:19 AM, David Culp  wrote:

 Here is one place:
 http://www.neutronusa.com/prod.cfm/2368628/glb?gclid=CJXhrIOEtskCFQaJaQod5iII_A

 i have never heard of the place before.  I saw at least one other place
 claiming to have boards in stock but they are not coming up in a google
 search right now.


 On Sunday, November 29, 2015 at 8:43:41 AM UTC-6, Graham wrote:
>
> David:
> Who is saying they have stock?
> I am always looking for scumbag vendors to NEVER buy from.
> --- Graham
>
> ==
>
> On Saturday, November 28, 2015 at 11:41:29 PM UTC-6, David Culp wrote:
>>
>> I didn't think it was due out until mid-December.  I'm seeing one or
>> two places on the net that claim to have stock.

 --
 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/vMJsTDIIvIA/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard...@googlegroups.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.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/

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

Re: [beagleboard] Re: Out yet?

[Gerald Coley]

I suggest that you contact Jason Kridner. He might be able to help.

Gerald


On Wed, Dec 2, 2015 at 12:31 PM,  wrote:

> I have tried order from both of those places, both ended up telling me not
> in stock, and canceled my order. They both told me 12 week lead time with
> is same as everywhere else. My Master degree project has been highly
> delayed due to this, I dont even know how to finish my project in time,
> before next feb
>
> On Sunday, November 29, 2015 at 9:05:03 AM UTC-8, Graham wrote:
>>
>> I found another one:
>>
>> http://www.nextwarehouse.com/item/?2221755_g10e
>>
>> Claims they have one in stock.
>>
>> I am sure they will say they have just sold it to someone else if you
>> order it, and your waiting time for the next delivery is 8 weeks.
>> Except that they will keep forgetting to take that one available off the
>> website.
>>
>> I had Element 14 do that to me during one of the BBB shortages.
>> I initially thought it was an honest mistake, but after a few weeks of
>> that one unit in stock still being advertised for sale, I wrote to them
>> telling them what I thought of their marketing practices.
>> They wrote back apologizing, and pretty much admitting that is what had
>> happened, that it was some kind of administrative error, and was not
>> intentional, etc., etc.
>> But they still did not take that one non-existant unit off their webpage
>> for several more weeks.
>>
>> I don't buy from them anymore, either.
>>
>> I guess the good news, is that it means a lot of people are interested in
>> the X-15, and it will be a success.
>>
>> --- Graham
>>
>> ==
>>
>>
>>
>> On Sun, Nov 29, 2015 at 10:19 AM, David Culp  wrote:
>>
>>> Here is one place:
>>> http://www.neutronusa.com/prod.cfm/2368628/glb?gclid=CJXhrIOEtskCFQaJaQod5iII_A
>>>
>>> i have never heard of the place before.  I saw at least one other place
>>> claiming to have boards in stock but they are not coming up in a google
>>> search right now.
>>>
>>>
>>> On Sunday, November 29, 2015 at 8:43:41 AM UTC-6, Graham wrote:

 David:
 Who is saying they have stock?
 I am always looking for scumbag vendors to NEVER buy from.
 --- Graham

 ==

 On Saturday, November 28, 2015 at 11:41:29 PM UTC-6, David Culp wrote:
>
> I didn't think it was due out until mid-December.  I'm seeing one or
> two places on the net that claim to have stock.
>
 --
>>> 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/vMJsTDIIvIA/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> beagleboard...@googlegroups.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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/

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

Re: [beagleboard] Re: Out yet?

[Xiang Gao]

Hi Jason,

I am a Master student in electrical engineering in Cal State Long Beach. My
graduate project is camera detection safety device. For example preventing
car collision. Last year, I have tried beagleboard xm, which is a great
board for this purpose. However, it runs slowly even at low resolution 15
fps at 640*480. My professor was not satisfied with it. I need a new
solution, the X15, which is a beast comparing to xm. No need to point out
the improvement on x15, almost everything. I can't wait to see it gives me
high resolution at high fps result. My goal is 1240*1024 at 24 or 30 fps,
or FHD if possible.  I am currently optimizing my algorithm on XM, but
honestly, there is not much potential to jump up. Also I have tried BBB as
alternative, but no luck as I expected. There are some other board
available in the market, which are either too expensive or much less
resources, Beagleboard x15 is the only one that suits me my need.

My project due late Feb 2016, I really dont have much time to wait for
official release. You are my last chance to get my project done in time.

Thank you for your help.

Peter

On Wed, Dec 2, 2015 at 11:03 AM, Jason Kridner  wrote:

> I'm around here. Not much to add except those are all bogus purchase
> links. On the official product page (http://beagleboard.org/x15), we
> have nothing but a "register your interest" link right now. Once the
> board reaches production and I have an official list of distributors
> who will have boards in stock in the first production run, I'll update
> the page with a drop-down list of distributors and send out a
> notification e-mail to all those who have registered interest.
>
> For serious contributors to open source projects, I've got a small
> stash of boards I've been handing out. It requires that you actually
> engage the lists and make public commitments to what you are going to
> contribute. For those paying attention, it shouldn't be that hard.
> "I'll test it out" isn't a significant contribution.
>
> On Wed, Dec 2, 2015 at 1:53 PM, Gerald Coley 
> wrote:
> > I suggest that you contact Jason Kridner. He might be able to help.
> >
> > Gerald
> >
> >
> > On Wed, Dec 2, 2015 at 12:31 PM,  wrote:
> >>
> >> I have tried order from both of those places, both ended up telling me
> not
> >> in stock, and canceled my order. They both told me 12 week lead time
> with is
> >> same as everywhere else. My Master degree project has been highly
> delayed
> >> due to this, I dont even know how to finish my project in time, before
> next
> >> feb
> >>
> >> On Sunday, November 29, 2015 at 9:05:03 AM UTC-8, Graham wrote:
> >>>
> >>> I found another one:
> >>>
> >>> http://www.nextwarehouse.com/item/?2221755_g10e
> >>>
> >>> Claims they have one in stock.
> >>>
> >>> I am sure they will say they have just sold it to someone else if you
> >>> order it, and your waiting time for the next delivery is 8 weeks.
> >>> Except that they will keep forgetting to take that one available off
> the
> >>> website.
> >>>
> >>> I had Element 14 do that to me during one of the BBB shortages.
> >>> I initially thought it was an honest mistake, but after a few weeks of
> >>> that one unit in stock still being advertised for sale, I wrote to them
> >>> telling them what I thought of their marketing practices.
> >>> They wrote back apologizing, and pretty much admitting that is what had
> >>> happened, that it was some kind of administrative error, and was not
> >>> intentional, etc., etc.
> >>> But they still did not take that one non-existant unit off their
> webpage
> >>> for several more weeks.
> >>>
> >>> I don't buy from them anymore, either.
> >>>
> >>> I guess the good news, is that it means a lot of people are interested
> in
> >>> the X-15, and it will be a success.
> >>>
> >>> --- Graham
> >>>
> >>> ==
> >>>
> >>>
> >>>
> >>> On Sun, Nov 29, 2015 at 10:19 AM, David Culp  wrote:
> 
>  Here is one place:
> 
> http://www.neutronusa.com/prod.cfm/2368628/glb?gclid=CJXhrIOEtskCFQaJaQod5iII_A
> 
>  i have never heard of the place before.  I saw at least one other
> place
>  claiming to have boards in stock but they are not coming up in a
> google
>  search right now.
> 
> 
>  On Sunday, November 29, 2015 at 8:43:41 AM UTC-6, Graham wrote:
> >
> > David:
> > Who is saying they have stock?
> > I am always looking for scumbag vendors to NEVER buy from.
> > --- Graham
> >
> > ==
> >
> > On Saturday, November 28, 2015 at 11:41:29 PM UTC-6, David Culp
> wrote:
> >>
> >> I didn't think it was due out until mid-December.  I'm seeing one or
> >> two places on the net that claim to have stock.
> 
>  --
>  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.
>  

Re: [beagleboard] Re: Out yet?

[petergao89]

I have tried order from both of those places, both ended up telling me not 
in stock, and canceled my order. They both told me 12 week lead time with 
is same as everywhere else. My Master degree project has been highly 
delayed due to this, I dont even know how to finish my project in time, 
before next feb

On Sunday, November 29, 2015 at 9:05:03 AM UTC-8, Graham wrote:
>
> I found another one:
>
> http://www.nextwarehouse.com/item/?2221755_g10e
>
> Claims they have one in stock.
>
> I am sure they will say they have just sold it to someone else if you 
> order it, and your waiting time for the next delivery is 8 weeks.
> Except that they will keep forgetting to take that one available off the 
> website.
>
> I had Element 14 do that to me during one of the BBB shortages.
> I initially thought it was an honest mistake, but after a few weeks of 
> that one unit in stock still being advertised for sale, I wrote to them 
> telling them what I thought of their marketing practices.
> They wrote back apologizing, and pretty much admitting that is what had 
> happened, that it was some kind of administrative error, and was not 
> intentional, etc., etc.
> But they still did not take that one non-existant unit off their webpage 
> for several more weeks.
>
> I don't buy from them anymore, either.
>
> I guess the good news, is that it means a lot of people are interested in 
> the X-15, and it will be a success.
>
> --- Graham
>
> ==
>
>
>
> On Sun, Nov 29, 2015 at 10:19 AM, David Culp  > wrote:
>
>> Here is one place: 
>> http://www.neutronusa.com/prod.cfm/2368628/glb?gclid=CJXhrIOEtskCFQaJaQod5iII_A
>>  
>>
>> i have never heard of the place before.  I saw at least one other place 
>> claiming to have boards in stock but they are not coming up in a google 
>> search right now.
>>
>>
>> On Sunday, November 29, 2015 at 8:43:41 AM UTC-6, Graham wrote:
>>>
>>> David:
>>> Who is saying they have stock?
>>> I am always looking for scumbag vendors to NEVER buy from.
>>> --- Graham
>>>
>>> ==
>>>
>>> On Saturday, November 28, 2015 at 11:41:29 PM UTC-6, David Culp wrote:

 I didn't think it was due out until mid-December.  I'm seeing one or 
 two places on the net that claim to have stock.

>>> -- 
>> 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/vMJsTDIIvIA/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Out yet?

[Robert Nelson]

On Wed, Dec 2, 2015 at 2:12 PM, Xiang Gao  wrote:

> Hi Jason,
>
> I am a Master student in electrical engineering in Cal State Long Beach.
> My graduate project is camera detection safety device. For example
> preventing car collision. Last year, I have tried beagleboard xm, which is
> a great board for this purpose. However, it runs slowly even at low
> resolution 15 fps at 640*480. My professor was not satisfied with it. I
> need a new solution, the X15, which is a beast comparing to xm. No need to
> point out the improvement on x15, almost everything. I can't wait to see it
> gives me high resolution at high fps result. My goal is 1240*1024 at 24 or
> 30 fps, or FHD if possible.  I am currently optimizing my algorithm on XM,
> but honestly, there is not much potential to jump up. Also I have tried BBB
> as alternative, but no luck as I expected. There are some other board
> available in the market, which are either too expensive or much less
> resources, Beagleboard x15 is the only one that suits me my need.
>

Sounds like a good project to use the x15's dsp..

Here's ti's opencl docs:

http://downloads.ti.com/mctools/esd/docs/opencl/intro.html

With the right graphics gpu, you could prototype this today. ;)

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

[beagleboard] BBB frozen, how to reset?

[Jonathan Ross]

Once in a blue moon one of my beaglebones will get into a state where it 
has power (the power LED is lit), but it is not booted. Normally this would 
be fine, just hit the power button to reset. But in this weird state the 
power button does nothing. The reset button does nothing.
I checked the power and reset button pins on the header, the power was low, 
the reset was high.
The only way to get the board out of this state was to pull the 5V power.
I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via 
power and/or reset buttons on the header if the BB stops sending checkins 
over uart. This has been working great, except for the rare case where the 
board ends up in this state where the power and reset buttons are not 
functioning.
Any ideas how the BB could get into this state, and if there's any other 
way to force a reboot other than physically pulling the 5v power?
Thanks,
JR

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

Re: [beagleboard] BBB frozen, how to reset?

[Gerald Coley]

I would start with your cape design and try and rule that out first.

The reset is an input pin read by the processor, not actually a HW power
reset. If the SW is locked up, this could happen.

If you hold the power button for a 8 seconds or more the board should power
cycle.

When it is in this state, what do the voltages read?

Gerald


On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross  wrote:

> Once in a blue moon one of my beaglebones will get into a state where it
> has power (the power LED is lit), but it is not booted. Normally this would
> be fine, just hit the power button to reset. But in this weird state the
> power button does nothing. The reset button does nothing.
> I checked the power and reset button pins on the header, the power was
> low, the reset was high.
> The only way to get the board out of this state was to pull the 5V power.
> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via
> power and/or reset buttons on the header if the BB stops sending checkins
> over uart. This has been working great, except for the rare case where the
> board ends up in this state where the power and reset buttons are not
> functioning.
> Any ideas how the BB could get into this state, and if there's any other
> way to force a reboot other than physically pulling the 5v power?
> Thanks,
> JR
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/

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

[beagleboard] Could not find symbol mcasp0_pins

[Cad Soft]

Hello all,

When trying to apply the Device tree overlay below, I get the error 
mentioned in the subject above. This was taken from a pre-existing overlay 
but perhaps the lastest Debian image calls it something else. Before anyone 
mentions the commented line at the bottom of the overlay I'm trying two 
variations one with the line commented the other without the line 
commented. Both yield the same error in dmesg.

Here's the image I am using:

Debian Image 2015-11-03 for BeagleBone Black

Thanks in advanced for any asistance provided.

Best Regards,
Jorge Garcia


/* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Purpose License Version 2 as
* published by the Free Software Foundation
*
* Original from: 
github.com/jadonk/validation-scripts/blob/master/test-capemgr/ 
*
* Modified by Jorge Garcia for the purposes of running my audio cape. This 
one disables using 9.27 as the clock
*/

/dts-v1/;
/plugin/;

/{
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "jorge-audio-cape-normal";
version = "00A0";
   
fragment@0 {
target = <>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <_pins>;

status = "okay";

op-mode = <0>;  /* MCASP_IIS_MODE */
tdm-slots = <2>;
num-serializer = <16>;
serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
0 0 1 0
0 0 0 0
0 0 0 0
0 0 0 0
>;
tx-num-evt = <1>;
rx-num-evt = <1>;
};
};

fragment@1 {
target = <>;
__overlay__ {
sound {
compatible = "ti,am33xx-beaglebone-black";
ti,model = "TI BeagleBone Black";
ti,audio-codec = <>;
ti,mcasp-controller = <>;
ti,codec-clock-rate = <2457600>;
/* mcasp_clock_enable = < 27 0>; BeagleBone Black Clk 
enable on GPIO1_27, not necessary for my shield */
};
};
};
};

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

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

By the way, last night I initially presses the boot button just to confirm
what I've already "known". Which is that once the board enters this state,
you need to remove power for a few seconds. Anyway, the USR LEDs all flash
on, like at normal power up, but then that is it. Nothing else.

I'm assuming this is a software "issue", but honestly, I really do not
know. One thing I do know for sure, is that this has happened since . . .
forever. That is to say I seem to remember this happening since ~may 2013
when we got our first boards. The only difference I notice is that when
using *reboot* versus *shutdown now -r *this problem seems to rear it's
head less often, but is not completely suppressed.



On Wed, Dec 2, 2015 at 3:26 PM, William Hermans  wrote:

> Gerald, it's like the board hangs at power down, but I can not be 100%
> sure. The reason why I "assume" it's at power down, is that the heartbeat
> blink stops, but the rest of the LEDs stay on, and the ethernet port light
> still blinks.
>
> The board I experienced this on last night is an Element14 RevC, but I do
> also have a circuitco A5A that exhibits the same thing.
>
> On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley 
> wrote:
>
>> Is this on power up or is this state happening some time later? If it is
>> on power up, then the power supply most likely is the issue based on the
>> ramp requirements of the PMIC.
>>
>> If the power LED is on, then the PMIC is on and ramped up. That is why I
>> asked for the voltages.
>>
>> It also could be a boot pin read issue where it misreads the boot pins.
>> If that is the case you should see that from the serial port.
>>
>> Gerald
>>
>>
>> On Wed, Dec 2, 2015 at 4:15 PM, William Hermans 
>> wrote:
>>
>>> For what it's worth Gerald, this happens with nothing connected to the
>>> board as well. This just happened to me last night after issuing a reboot
>>> command from the command line.
>>>
>>> I remember at some point you all were talking about something about the
>>> "ramp time" of the PMIC or something.
>>>
>>> On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley 
>>> wrote:
>>>
 I would start with your cape design and try and rule that out first.

 The reset is an input pin read by the processor, not actually a HW
 power reset. If the SW is locked up, this could happen.

 If you hold the power button for a 8 seconds or more the board should
 power cycle.

 When it is in this state, what do the voltages read?

 Gerald


 On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
 wrote:

> Once in a blue moon one of my beaglebones will get into a state where
> it has power (the power LED is lit), but it is not booted. Normally this
> would be fine, just hit the power button to reset. But in this weird state
> the power button does nothing. The reset button does nothing.
> I checked the power and reset button pins on the header, the power was
> low, the reset was high.
> The only way to get the board out of this state was to pull the 5V
> power.
> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it
> via power and/or reset buttons on the header if the BB stops sending
> checkins over uart. This has been working great, except for the rare case
> where the board ends up in this state where the power and reset buttons 
> are
> not functioning.
> Any ideas how the BB could get into this state, and if there's any
> other way to force a reboot other than physically pulling the 5v power?
> Thanks,
> JR
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Gerald

 ger...@beagleboard.org
 http://beagleboard.org/

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

Re: [beagleboard] BBB frozen, how to reset?

[Gerald Coley]

Hmm, not sure what is going on. Sounds like the processor has stopped
running the code and halted but it forgot to turn off the lights.

Gerald

On Wed, Dec 2, 2015 at 4:26 PM, William Hermans  wrote:

> Gerald, it's like the board hangs at power down, but I can not be 100%
> sure. The reason why I "assume" it's at power down, is that the heartbeat
> blink stops, but the rest of the LEDs stay on, and the ethernet port light
> still blinks.
>
> The board I experienced this on last night is an Element14 RevC, but I do
> also have a circuitco A5A that exhibits the same thing.
>
> On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley 
> wrote:
>
>> Is this on power up or is this state happening some time later? If it is
>> on power up, then the power supply most likely is the issue based on the
>> ramp requirements of the PMIC.
>>
>> If the power LED is on, then the PMIC is on and ramped up. That is why I
>> asked for the voltages.
>>
>> It also could be a boot pin read issue where it misreads the boot pins.
>> If that is the case you should see that from the serial port.
>>
>> Gerald
>>
>>
>> On Wed, Dec 2, 2015 at 4:15 PM, William Hermans 
>> wrote:
>>
>>> For what it's worth Gerald, this happens with nothing connected to the
>>> board as well. This just happened to me last night after issuing a reboot
>>> command from the command line.
>>>
>>> I remember at some point you all were talking about something about the
>>> "ramp time" of the PMIC or something.
>>>
>>> On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley 
>>> wrote:
>>>
 I would start with your cape design and try and rule that out first.

 The reset is an input pin read by the processor, not actually a HW
 power reset. If the SW is locked up, this could happen.

 If you hold the power button for a 8 seconds or more the board should
 power cycle.

 When it is in this state, what do the voltages read?

 Gerald


 On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
 wrote:

> Once in a blue moon one of my beaglebones will get into a state where
> it has power (the power LED is lit), but it is not booted. Normally this
> would be fine, just hit the power button to reset. But in this weird state
> the power button does nothing. The reset button does nothing.
> I checked the power and reset button pins on the header, the power was
> low, the reset was high.
> The only way to get the board out of this state was to pull the 5V
> power.
> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it
> via power and/or reset buttons on the header if the BB stops sending
> checkins over uart. This has been working great, except for the rare case
> where the board ends up in this state where the power and reset buttons 
> are
> not functioning.
> Any ideas how the BB could get into this state, and if there's any
> other way to force a reboot other than physically pulling the 5v power?
> Thanks,
> JR
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Gerald

 ger...@beagleboard.org
 http://beagleboard.org/

 --
 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.
 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@beagleboard.org
>> http://beagleboard.org/
>>
>> --
>> 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.
>> 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 

[beagleboard] Re: Establish and maintain PPP connection on boot, BBB Debian 3.8.13-bone70

[Matt Maher Peterson]

Another not here is that when if I simply put the pon verizon command in a 
shell script:

#!/bin/bash
pon verizon

and execute the script see everthing connect but I it immediately 
terminates the connection as I can see in /var/messages after it gets its 
IP with a Hangup (SIGHUP)

 pppd[1846]: PAP authentication succeeded
 pppd[1846]: Could not determine remote IP address: defaulting to 
10.64.64.64
 pppd[1846]: local  IP address 166.154.48.36
 pppd[1846]: remote IP address 10.64.64.64
 pppd[1846]: primary   DNS address 198.224.173.135
 pppd[1846]: secondary DNS address 198.224.174.135
 pppd[1860]: Hangup (SIGHUP)
 pppd[1860]: Modem hangup
 pppd[1860]: Connect time 0.0 minutes.
 pppd[1860]: Sent 0 bytes, received 0 bytes.
 pppd[1860]: Connection terminated.


On Tuesday, November 24, 2015 at 8:17:19 AM UTC-8, Matt Maher Peterson 
wrote:
>
> Hi,
>
> I am using a Skywire LE910-SVG cellular modem   
> with a BBB.
>
> I have writting chatscripts and PPP/peers provider scripts that are 
> working well.  If I let the BBB boot up normaly I can ssh to the device and 
> 'pon verizon' to establish a ppp connection manully.  Everything works 
> great.
>
> The issue I am trying to resolve is automating this on boot.  What is the 
> best way to do this?
>
> Tried adding it to /etc/network/interfaces with:
>
> auto verizon
> iface verizon inet ppp0
>   provider verizon
>
> Does not seam to do anything.
>
> Any solutions out there?
>
> Kind Regards,
>
> Matt
>

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

[beagleboard] Re: Could not find symbol mcasp0_pins

[Cad Soft]

I apologize I think I accidentally posted this in multiple places, sorry.

On Wednesday, December 2, 2015 at 5:25:12 PM UTC-5, Cad Soft wrote:
>
> Hello all,
>
> When trying to apply the Device tree overlay below, I get the error 
> mentioned in the subject above. This was taken from a pre-existing overlay 
> but perhaps the lastest Debian image calls it something else. Before anyone 
> mentions the commented line at the bottom of the overlay I'm trying two 
> variations one with the line commented the other without the line 
> commented. Both yield the same error in dmesg.
>
> Here's the image I am using:
>
> Debian Image 2015-11-03 for BeagleBone Black
>
> Thanks in advanced for any asistance provided.
>
> Best Regards,
> Jorge Garcia
>
>
> /* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Purpose License Version 2 as
> * published by the Free Software Foundation
> *
> * Original from: 
> github.com/jadonk/validation-scripts/blob/master/test-capemgr/ 
> *
> * Modified by Jorge Garcia for the purposes of running my audio cape. This 
> one disables using 9.27 as the clock
> */
>
> /dts-v1/;
> /plugin/;
>
> /{
> compatible = "ti,beaglebone", "ti,beaglebone-black";
> part-number = "jorge-audio-cape-normal";
> version = "00A0";
>
> fragment@0 {
> target = <>;
> __overlay__ {
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
>
> status = "okay";
>
> op-mode = <0>;  /* MCASP_IIS_MODE */
> tdm-slots = <2>;
> num-serializer = <16>;
> serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
> 0 0 1 0
> 0 0 0 0
> 0 0 0 0
> 0 0 0 0
> >;
> tx-num-evt = <1>;
> rx-num-evt = <1>;
> };
> };
>
> fragment@1 {
> target = <>;
> __overlay__ {
> sound {
> compatible = "ti,am33xx-beaglebone-black";
> ti,model = "TI BeagleBone Black";
> ti,audio-codec = <>;
> ti,mcasp-controller = <>;
> ti,codec-clock-rate = <2457600>;
> /* mcasp_clock_enable = < 27 0>; BeagleBone Black 
> Clk enable on GPIO1_27, not necessary for my shield */
> };
> };
> };
> };
>

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

Re: [beagleboard] Re: Could not find symbol mcasp0_pins

[William Hermans]

I was reading on various device tree topics last week, and seem to recall
the most well known cause for this complaint from dtc is: You have the
wrong device tree compiler.

So, what is the output of


*dtc --version*?

On Wed, Dec 2, 2015 at 3:31 PM, Cad Soft  wrote:

> I apologize I think I accidentally posted this in multiple places, sorry.
>
>
> On Wednesday, December 2, 2015 at 5:25:12 PM UTC-5, Cad Soft wrote:
>>
>> Hello all,
>>
>> When trying to apply the Device tree overlay below, I get the error
>> mentioned in the subject above. This was taken from a pre-existing overlay
>> but perhaps the lastest Debian image calls it something else. Before anyone
>> mentions the commented line at the bottom of the overlay I'm trying two
>> variations one with the line commented the other without the line
>> commented. Both yield the same error in dmesg.
>>
>> Here's the image I am using:
>>
>> Debian Image 2015-11-03 for BeagleBone Black
>>
>> Thanks in advanced for any asistance provided.
>>
>> Best Regards,
>> Jorge Garcia
>>
>>
>> /* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>> *
>> * This program is free software; you can redistribute it and/or modify
>> * it under the terms of the GNU General Purpose License Version 2 as
>> * published by the Free Software Foundation
>> *
>> * Original from:
>> github.com/jadonk/validation-scripts/blob/master/test-capemgr/
>> *
>> * Modified by Jorge Garcia for the purposes of running my audio cape.
>> This one disables using 9.27 as the clock
>> */
>>
>> /dts-v1/;
>> /plugin/;
>>
>> /{
>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>> part-number = "jorge-audio-cape-normal";
>> version = "00A0";
>>
>> fragment@0 {
>> target = <>;
>> __overlay__ {
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>>
>> status = "okay";
>>
>> op-mode = <0>;  /* MCASP_IIS_MODE */
>> tdm-slots = <2>;
>> num-serializer = <16>;
>> serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
>> 0 0 1 0
>> 0 0 0 0
>> 0 0 0 0
>> 0 0 0 0
>> >;
>> tx-num-evt = <1>;
>> rx-num-evt = <1>;
>> };
>> };
>>
>> fragment@1 {
>> target = <>;
>> __overlay__ {
>> sound {
>> compatible = "ti,am33xx-beaglebone-black";
>> ti,model = "TI BeagleBone Black";
>> ti,audio-codec = <>;
>> ti,mcasp-controller = <>;
>> ti,codec-clock-rate = <2457600>;
>> /* mcasp_clock_enable = < 27 0>; BeagleBone Black
>> Clk enable on GPIO1_27, not necessary for my shield */
>> };
>> };
>> };
>> };
>>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Could not find symbol mcasp0_pins

[William Hermans]

Additionally, searching through my own de-compiled am335x-boneblack.dtb
board file. *mcasp0_pins *does not exist.

On Wed, Dec 2, 2015 at 3:46 PM, William Hermans  wrote:

> I was reading on various device tree topics last week, and seem to recall
> the most well known cause for this complaint from dtc is: You have the
> wrong device tree compiler.
>
> So, what is the output of
>
>
> *dtc --version*?
>
> On Wed, Dec 2, 2015 at 3:31 PM, Cad Soft  wrote:
>
>> I apologize I think I accidentally posted this in multiple places, sorry.
>>
>>
>> On Wednesday, December 2, 2015 at 5:25:12 PM UTC-5, Cad Soft wrote:
>>>
>>> Hello all,
>>>
>>> When trying to apply the Device tree overlay below, I get the error
>>> mentioned in the subject above. This was taken from a pre-existing overlay
>>> but perhaps the lastest Debian image calls it something else. Before anyone
>>> mentions the commented line at the bottom of the overlay I'm trying two
>>> variations one with the line commented the other without the line
>>> commented. Both yield the same error in dmesg.
>>>
>>> Here's the image I am using:
>>>
>>> Debian Image 2015-11-03 for BeagleBone Black
>>>
>>> Thanks in advanced for any asistance provided.
>>>
>>> Best Regards,
>>> Jorge Garcia
>>>
>>>
>>> /* Copyright (C) 2012 Texas Instruments Incorporated -
>>> http://www.ti.com/
>>> *
>>> * This program is free software; you can redistribute it and/or modify
>>> * it under the terms of the GNU General Purpose License Version 2 as
>>> * published by the Free Software Foundation
>>> *
>>> * Original from:
>>> github.com/jadonk/validation-scripts/blob/master/test-capemgr/
>>> *
>>> * Modified by Jorge Garcia for the purposes of running my audio cape.
>>> This one disables using 9.27 as the clock
>>> */
>>>
>>> /dts-v1/;
>>> /plugin/;
>>>
>>> /{
>>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>> part-number = "jorge-audio-cape-normal";
>>> version = "00A0";
>>>
>>> fragment@0 {
>>> target = <>;
>>> __overlay__ {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_pins>;
>>>
>>> status = "okay";
>>>
>>> op-mode = <0>;  /* MCASP_IIS_MODE */
>>> tdm-slots = <2>;
>>> num-serializer = <16>;
>>> serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
>>> 0 0 1 0
>>> 0 0 0 0
>>> 0 0 0 0
>>> 0 0 0 0
>>> >;
>>> tx-num-evt = <1>;
>>> rx-num-evt = <1>;
>>> };
>>> };
>>>
>>> fragment@1 {
>>> target = <>;
>>> __overlay__ {
>>> sound {
>>> compatible = "ti,am33xx-beaglebone-black";
>>> ti,model = "TI BeagleBone Black";
>>> ti,audio-codec = <>;
>>> ti,mcasp-controller = <>;
>>> ti,codec-clock-rate = <2457600>;
>>> /* mcasp_clock_enable = < 27 0>; BeagleBone Black
>>> Clk enable on GPIO1_27, not necessary for my shield */
>>> };
>>> };
>>> };
>>> };
>>>
>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] ppp establish connection on boot debian beaglebone black

[Matt Maher Peterson]

Hi,

I am using a Skywire LE910-SVG cellular modem   
with a BBB.

I have writting chatscripts and PPP/peers provider scripts that are working 
well.  If I let the BBB boot up normally I can ssh to the device and 'pon 
verizon' to establish a ppp connection manully.  Everything works great.

The issue I am trying to resolve is automating this on boot.  What is the 
best way to do this?

Tried adding it to /etc/network/interfaces with:

auto verizon
iface verizon inet ppp0
  provider verizon

Does not seam to do anything.

Have also tried to running a simple bash script to do this after the BBB 
boots

#!/bin/bash
pon verizon

When I execute the script I can see everything connect but I it immediately 
terminates the connection as I can see in the output with Hangup (SIGHUP)

 pppd[1846]: PAP authentication succeeded
 pppd[1846]: Could not determine remote IP address: defaulting to 
10.64.64.64
 pppd[1846]: local  IP address 166.154.48.36
 pppd[1846]: remote IP address 10.64.64.64
 pppd[1846]: primary   DNS address 198.224.173.135
 pppd[1846]: secondary DNS address 198.224.174.135
 pppd[1860]: *Hangup (SIGHUP)*
 pppd[1860]: Modem hangup
 pppd[1860]: Connect time 0.0 minutes.
 pppd[1860]: Sent 0 bytes, received 0 bytes.
 pppd[1860]: Connection terminated.


Any solutions out there?

Kind Regards,

Matt

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

Re: [beagleboard] BBB frozen, how to reset?

[Gerald Coley]

Is this on power up or is this state happening some time later? If it is on
power up, then the power supply most likely is the issue based on the ramp
requirements of the PMIC.

If the power LED is on, then the PMIC is on and ramped up. That is why I
asked for the voltages.

It also could be a boot pin read issue where it misreads the boot pins. If
that is the case you should see that from the serial port.

Gerald


On Wed, Dec 2, 2015 at 4:15 PM, William Hermans  wrote:

> For what it's worth Gerald, this happens with nothing connected to the
> board as well. This just happened to me last night after issuing a reboot
> command from the command line.
>
> I remember at some point you all were talking about something about the
> "ramp time" of the PMIC or something.
>
> On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley 
> wrote:
>
>> I would start with your cape design and try and rule that out first.
>>
>> The reset is an input pin read by the processor, not actually a HW power
>> reset. If the SW is locked up, this could happen.
>>
>> If you hold the power button for a 8 seconds or more the board should
>> power cycle.
>>
>> When it is in this state, what do the voltages read?
>>
>> Gerald
>>
>>
>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
>> wrote:
>>
>>> Once in a blue moon one of my beaglebones will get into a state where it
>>> has power (the power LED is lit), but it is not booted. Normally this would
>>> be fine, just hit the power button to reset. But in this weird state the
>>> power button does nothing. The reset button does nothing.
>>> I checked the power and reset button pins on the header, the power was
>>> low, the reset was high.
>>> The only way to get the board out of this state was to pull the 5V power.
>>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via
>>> power and/or reset buttons on the header if the BB stops sending checkins
>>> over uart. This has been working great, except for the rare case where the
>>> board ends up in this state where the power and reset buttons are not
>>> functioning.
>>> Any ideas how the BB could get into this state, and if there's any other
>>> way to force a reboot other than physically pulling the 5v power?
>>> Thanks,
>>> JR
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@beagleboard.org
>> http://beagleboard.org/
>>
>> --
>> 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.
>> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/

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

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

Gerald, it's like the board hangs at power down, but I can not be 100%
sure. The reason why I "assume" it's at power down, is that the heartbeat
blink stops, but the rest of the LEDs stay on, and the ethernet port light
still blinks.

The board I experienced this on last night is an Element14 RevC, but I do
also have a circuitco A5A that exhibits the same thing.

On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley  wrote:

> Is this on power up or is this state happening some time later? If it is
> on power up, then the power supply most likely is the issue based on the
> ramp requirements of the PMIC.
>
> If the power LED is on, then the PMIC is on and ramped up. That is why I
> asked for the voltages.
>
> It also could be a boot pin read issue where it misreads the boot pins. If
> that is the case you should see that from the serial port.
>
> Gerald
>
>
> On Wed, Dec 2, 2015 at 4:15 PM, William Hermans  wrote:
>
>> For what it's worth Gerald, this happens with nothing connected to the
>> board as well. This just happened to me last night after issuing a reboot
>> command from the command line.
>>
>> I remember at some point you all were talking about something about the
>> "ramp time" of the PMIC or something.
>>
>> On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley 
>> wrote:
>>
>>> I would start with your cape design and try and rule that out first.
>>>
>>> The reset is an input pin read by the processor, not actually a HW power
>>> reset. If the SW is locked up, this could happen.
>>>
>>> If you hold the power button for a 8 seconds or more the board should
>>> power cycle.
>>>
>>> When it is in this state, what do the voltages read?
>>>
>>> Gerald
>>>
>>>
>>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
>>> wrote:
>>>
 Once in a blue moon one of my beaglebones will get into a state where
 it has power (the power LED is lit), but it is not booted. Normally this
 would be fine, just hit the power button to reset. But in this weird state
 the power button does nothing. The reset button does nothing.
 I checked the power and reset button pins on the header, the power was
 low, the reset was high.
 The only way to get the board out of this state was to pull the 5V
 power.
 I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it
 via power and/or reset buttons on the header if the BB stops sending
 checkins over uart. This has been working great, except for the rare case
 where the board ends up in this state where the power and reset buttons are
 not functioning.
 Any ideas how the BB could get into this state, and if there's any
 other way to force a reboot other than physically pulling the 5v power?
 Thanks,
 JR

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

>>>
>>>
>>>
>>> --
>>> Gerald
>>>
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>>
>>> --
>>> 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.
>>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

One more thing of note. I do not run systemd - Ever. I run SYSV as an init
daemon. I only mention this as I think Robert said something about systemd
lessening this issue.

On Wed, Dec 2, 2015 at 3:36 PM, Gerald Coley  wrote:

> Hmm, not sure what is going on. Sounds like the processor has stopped
> running the code and halted but it forgot to turn off the lights.
>
> Gerald
>
> On Wed, Dec 2, 2015 at 4:26 PM, William Hermans  wrote:
>
>> Gerald, it's like the board hangs at power down, but I can not be 100%
>> sure. The reason why I "assume" it's at power down, is that the heartbeat
>> blink stops, but the rest of the LEDs stay on, and the ethernet port light
>> still blinks.
>>
>> The board I experienced this on last night is an Element14 RevC, but I do
>> also have a circuitco A5A that exhibits the same thing.
>>
>> On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley 
>> wrote:
>>
>>> Is this on power up or is this state happening some time later? If it is
>>> on power up, then the power supply most likely is the issue based on the
>>> ramp requirements of the PMIC.
>>>
>>> If the power LED is on, then the PMIC is on and ramped up. That is why I
>>> asked for the voltages.
>>>
>>> It also could be a boot pin read issue where it misreads the boot pins.
>>> If that is the case you should see that from the serial port.
>>>
>>> Gerald
>>>
>>>
>>> On Wed, Dec 2, 2015 at 4:15 PM, William Hermans 
>>> wrote:
>>>
 For what it's worth Gerald, this happens with nothing connected to the
 board as well. This just happened to me last night after issuing a reboot
 command from the command line.

 I remember at some point you all were talking about something about the
 "ramp time" of the PMIC or something.

 On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley 
 wrote:

> I would start with your cape design and try and rule that out first.
>
> The reset is an input pin read by the processor, not actually a HW
> power reset. If the SW is locked up, this could happen.
>
> If you hold the power button for a 8 seconds or more the board should
> power cycle.
>
> When it is in this state, what do the voltages read?
>
> Gerald
>
>
> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
> wrote:
>
>> Once in a blue moon one of my beaglebones will get into a state where
>> it has power (the power LED is lit), but it is not booted. Normally this
>> would be fine, just hit the power button to reset. But in this weird 
>> state
>> the power button does nothing. The reset button does nothing.
>> I checked the power and reset button pins on the header, the power
>> was low, the reset was high.
>> The only way to get the board out of this state was to pull the 5V
>> power.
>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it
>> via power and/or reset buttons on the header if the BB stops sending
>> checkins over uart. This has been working great, except for the rare case
>> where the board ends up in this state where the power and reset buttons 
>> are
>> not functioning.
>> Any ideas how the BB could get into this state, and if there's any
>> other way to force a reboot other than physically pulling the 5v power?
>> Thanks,
>> JR
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
>
> --
> 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.
> 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.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Gerald
>>>
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are 

Re: [beagleboard] BBB frozen, how to reset?

[John Syne]

Sounds to me that like BBB has gone into sleep mode and there is no trigger to 
wake it up. Is there a way to measure the current consumption? 

Regards,
John




> On Dec 2, 2015, at 2:40 PM, William Hermans  wrote:
> 
> One more thing of note. I do not run systemd - Ever. I run SYSV as an init 
> daemon. I only mention this as I think Robert said something about systemd 
> lessening this issue.
> 
> On Wed, Dec 2, 2015 at 3:36 PM, Gerald Coley  > wrote:
> Hmm, not sure what is going on. Sounds like the processor has stopped running 
> the code and halted but it forgot to turn off the lights.
> 
> Gerald
> 
> On Wed, Dec 2, 2015 at 4:26 PM, William Hermans  > wrote:
> Gerald, it's like the board hangs at power down, but I can not be 100% sure. 
> The reason why I "assume" it's at power down, is that the heartbeat blink 
> stops, but the rest of the LEDs stay on, and the ethernet port light still 
> blinks.
> 
> The board I experienced this on last night is an Element14 RevC, but I do 
> also have a circuitco A5A that exhibits the same thing.
> 
> On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley  > wrote:
> Is this on power up or is this state happening some time later? If it is on 
> power up, then the power supply most likely is the issue based on the ramp 
> requirements of the PMIC. 
> 
> If the power LED is on, then the PMIC is on and ramped up. That is why I 
> asked for the voltages.
> 
> It also could be a boot pin read issue where it misreads the boot pins. If 
> that is the case you should see that from the serial port.
> 
> Gerald
> 
> 
> On Wed, Dec 2, 2015 at 4:15 PM, William Hermans  > wrote:
> For what it's worth Gerald, this happens with nothing connected to the board 
> as well. This just happened to me last night after issuing a reboot command 
> from the command line.
> 
> I remember at some point you all were talking about something about the "ramp 
> time" of the PMIC or something.
> 
> On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley  > wrote:
> I would start with your cape design and try and rule that out first.
> 
> The reset is an input pin read by the processor, not actually a HW power 
> reset. If the SW is locked up, this could happen.
> 
> If you hold the power button for a 8 seconds or more the board should power 
> cycle.
> 
> When it is in this state, what do the voltages read?
> 
> Gerald
> 
> 
> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross  > wrote:
> Once in a blue moon one of my beaglebones will get into a state where it has 
> power (the power LED is lit), but it is not booted. Normally this would be 
> fine, just hit the power button to reset. But in this weird state the power 
> button does nothing. The reset button does nothing.
> I checked the power and reset button pins on the header, the power was low, 
> the reset was high.
> The only way to get the board out of this state was to pull the 5V power.
> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via 
> power and/or reset buttons on the header if the BB stops sending checkins 
> over uart. This has been working great, except for the rare case where the 
> board ends up in this state where the power and reset buttons are not 
> functioning.
> Any ideas how the BB could get into this state, and if there's any other way 
> to force a reboot other than physically pulling the 5v power?
> Thanks,
> JR
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/ 
> 
> -- 
> 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 
> .
> 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 

[beagleboard] BeagleBone Black has 4 LEDs flashing at the same time every time I try and flash the eMMC. Help!

[Bill Dussault]

I have a flasher image of Debian (7.9) and have it the BBB hooked up to a 
5V 2A power supply and nothing else. I hold the boot button down with the 
Scan Disc Card inserted and wait for the four blue LED's to light at the 
same time. I release and it looks like it loads Ten minutes later all four 
lights are flashing at the same time and it will not boot ...once again 
What in the Hell am I doing wrong? Flashing this damn thing is infuriating. 
Can someone help?

Thanks

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[Jonathan Ross]

Element14 revC.
I think what you are describing is the power ramp issue. I don't think what 
I'm experiencing is the same thing. I've been through the power ramp issue 
and I just use my external KL16 to toggle the BBB pwr button a few seconds 
after power is applied, which kicks the board into boot.
Jon

On Wednesday, December 2, 2015 at 4:27:49 PM UTC-8, William Hermans wrote:
>
> Which board revision Jonathon ? This board I noticed this on last night is 
> an Element14 RevC. But on our A5A's I never noticed the USR LEDs cycling 
> like that.
>
> On Wed, Dec 2, 2015 at 4:59 PM, Jonathan Ross  > wrote:
>
>> Got you on the script front. My issue is slightly different, when I get 
>> into my magic state, pressing the power button does nothing.
>>
>> On Wednesday, December 2, 2015 at 3:51:42 PM UTC-8, William Hermans wrote:
>>>
>>>
 *In my case linux is not booted at this time(none of the 4 user leds 
 lit), so a script would not help. This is why I'm doing an external 
 watchdog circuit.*
>>>
>>>
>>> Exactly. So here is what I mean. The USR LEDs cycle on for me *if* and 
>>> only *if* I press the power button on the board. After that, nothing 
>>> changes. Otherwise the LEDs are off, well the power LED is on, and the 
>>> ethernet port lights are on too, and potentially blinking.
>>>
>>> The script, would just be to reboot the board in an attempt to put the 
>>> board back into the bad state. For troubleshooting . . .
>>>
>>> On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross  
>>> wrote:
>>>
 In my case linux is not booted at this time(none of the 4 user leds 
 lit), so a script would not help. This is why I'm doing an external 
 watchdog circuit.

 On Wednesday, December 2, 2015 at 3:41:32 PM UTC-8, William Hermans 
 wrote:
>
> *I didn't test the 8 second holddown of the power button but I doubt 
>> it would help, and unfortunately it's not a reproducible issue. I'll 
>> have 
>> to wait for it to happen again.*
>>
>
> I know what you mean, e.g. this happens so erratically, it's hard to 
> tell when it'll happen next. But, I could possibly whip up a script, and 
> a 
> means to automate resetting the system. Really, you could probably do the 
> same as well. Just put "sudo reboot" in a bash script, and run it through 
> rc.d
>
> With that said, I'm not 100% sure this is good for the board.
>
>
>
> On Wed, Dec 2, 2015 at 4:31 PM, Jonathan Ross  
> wrote:
>
>> I didn't test the 8 second holddown of the power button but I doubt 
>> it would help, and unfortunately it's not a reproducible issue. I'll 
>> have 
>> to wait for it to happen again.
>> From my notes, I was seeing zero volts on power, 5V on reset.
>> The zero volts on power was very weird. From the KL16 I'm "toggling" 
>> my own effective power button that is a transistor between the power pin 
>> on 
>> the header and ground. The KL16 pin was not driven high (I checked), so 
>> I 
>> don't think it was the transistor on the cape that was pulling pwr to 
>> ground on the BBB. And the physical button wasn't pressed in. It was as 
>> if 
>> the pullup at the PMIC wasn't active, yet the power LED was on. Is that 
>> possible?
>> Wish I hadn't pulled the 5V power to reset, then I could do more 
>> testing.
>>
>> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
>>>
>>> I would start with your cape design and try and rule that out first.
>>>
>>> The reset is an input pin read by the processor, not actually a HW 
>>> power reset. If the SW is locked up, this could happen.
>>>
>>> If you hold the power button for a 8 seconds or more the board 
>>> should power cycle.
>>>
>>> When it is in this state, what do the voltages read?
>>>
>>> Gerald
>>>
>>>
>>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross  
>>> wrote:
>>>
 Once in a blue moon one of my beaglebones will get into a state 
 where it has power (the power LED is lit), but it is not booted. 
 Normally 
 this would be fine, just hit the power button to reset. But in this 
 weird 
 state the power button does nothing. The reset button does nothing.
 I checked the power and reset button pins on the header, the power 
 was low, the reset was high.
 The only way to get the board out of this state was to pull the 5V 
 power.
 I'm using a KL16 on a cape to do a watchdog on the BB, and reboot 
 it via power and/or reset buttons on the header if the BB stops 
 sending 
 checkins over uart. This has been working great, except for the rare 
 case 
 where the board ends up in this state where the power and reset 
 

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

>
> *Element14 revC.*
> *I think what you are describing is the power ramp issue. I don't think
> what I'm experiencing is the same thing. I've been through the power ramp
> issue and I just use my external KL16 to toggle the BBB pwr button a few
> seconds after power is applied, which kicks the board into boot.*
> *Jon*
>

Not trying to be difficult, or argumentative . . . but no, I think we're
experiencing the same thing. Only because the board will not boot up Linux
at all after it gets into this state. The LEDs will cycle on, then off, but
then nothing. I have to physically remove the power from the board for a
few seconds, before it'll boot again. Passed that, sometimes, the processes
of removing the power may have to be repeated a few times before the board
does finally boot. However this last part seems to mostly apply to our
A5A's mostly. I do not recall the Element14 RevC's doing this.

On Wed, Dec 2, 2015 at 5:32 PM, Jonathan Ross  wrote:

> Element14 revC.
> I think what you are describing is the power ramp issue. I don't think
> what I'm experiencing is the same thing. I've been through the power ramp
> issue and I just use my external KL16 to toggle the BBB pwr button a few
> seconds after power is applied, which kicks the board into boot.
> Jon
>
> On Wednesday, December 2, 2015 at 4:27:49 PM UTC-8, William Hermans wrote:
>>
>> Which board revision Jonathon ? This board I noticed this on last night
>> is an Element14 RevC. But on our A5A's I never noticed the USR LEDs cycling
>> like that.
>>
>> On Wed, Dec 2, 2015 at 4:59 PM, Jonathan Ross 
>> wrote:
>>
>>> Got you on the script front. My issue is slightly different, when I get
>>> into my magic state, pressing the power button does nothing.
>>>
>>> On Wednesday, December 2, 2015 at 3:51:42 PM UTC-8, William Hermans
>>> wrote:


> *In my case linux is not booted at this time(none of the 4 user leds
> lit), so a script would not help. This is why I'm doing an external
> watchdog circuit.*


 Exactly. So here is what I mean. The USR LEDs cycle on for me *if* and
 only *if* I press the power button on the board. After that, nothing
 changes. Otherwise the LEDs are off, well the power LED is on, and the
 ethernet port lights are on too, and potentially blinking.

 The script, would just be to reboot the board in an attempt to put the
 board back into the bad state. For troubleshooting . . .

 On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross 
 wrote:

> In my case linux is not booted at this time(none of the 4 user leds
> lit), so a script would not help. This is why I'm doing an external
> watchdog circuit.
>
> On Wednesday, December 2, 2015 at 3:41:32 PM UTC-8, William Hermans
> wrote:
>>
>> *I didn't test the 8 second holddown of the power button but I doubt
>>> it would help, and unfortunately it's not a reproducible issue. I'll 
>>> have
>>> to wait for it to happen again.*
>>>
>>
>> I know what you mean, e.g. this happens so erratically, it's hard to
>> tell when it'll happen next. But, I could possibly whip up a script, and 
>> a
>> means to automate resetting the system. Really, you could probably do the
>> same as well. Just put "sudo reboot" in a bash script, and run it through
>> rc.d
>>
>> With that said, I'm not 100% sure this is good for the board.
>>
>>
>>
>> On Wed, Dec 2, 2015 at 4:31 PM, Jonathan Ross 
>> wrote:
>>
>>> I didn't test the 8 second holddown of the power button but I doubt
>>> it would help, and unfortunately it's not a reproducible issue. I'll 
>>> have
>>> to wait for it to happen again.
>>> From my notes, I was seeing zero volts on power, 5V on reset.
>>> The zero volts on power was very weird. From the KL16 I'm "toggling"
>>> my own effective power button that is a transistor between the power 
>>> pin on
>>> the header and ground. The KL16 pin was not driven high (I checked), so 
>>> I
>>> don't think it was the transistor on the cape that was pulling pwr to
>>> ground on the BBB. And the physical button wasn't pressed in. It was as 
>>> if
>>> the pullup at the PMIC wasn't active, yet the power LED was on. Is that
>>> possible?
>>> Wish I hadn't pulled the 5V power to reset, then I could do more
>>> testing.
>>>
>>> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:

 I would start with your cape design and try and rule that out first.

 The reset is an input pin read by the processor, not actually a HW
 power reset. If the SW is locked up, this could happen.

 If you hold the power button for a 8 seconds or more the board
 should power cycle.

 When it is in this state, what do 

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

So just in case this is helpful to the whole process:

william@beaglebone:~$ uname -a
Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC 2015 armv7l
GNU/Linux
william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01
william@beaglebone:~$ pstree
init-+-bluetoothd
 |-cron
 |-dbus-daemon
 |-7*[getty]
 |-rpc.idmapd
 |-rpc.statd
 |-rpcbind
 |-rsyslogd---3*[{rsyslogd}]
 |-sshd---sshd---sshd---bash---pstree
 `-udevd---2*[udevd]

The output of pstree is just to show that I'm not running systemd, but
instead sysv.

On Wed, Dec 2, 2015 at 5:38 PM, William Hermans  wrote:

> *Element14 revC.*
>> *I think what you are describing is the power ramp issue. I don't think
>> what I'm experiencing is the same thing. I've been through the power ramp
>> issue and I just use my external KL16 to toggle the BBB pwr button a few
>> seconds after power is applied, which kicks the board into boot.*
>> *Jon*
>>
>
> Not trying to be difficult, or argumentative . . . but no, I think we're
> experiencing the same thing. Only because the board will not boot up Linux
> at all after it gets into this state. The LEDs will cycle on, then off, but
> then nothing. I have to physically remove the power from the board for a
> few seconds, before it'll boot again. Passed that, sometimes, the processes
> of removing the power may have to be repeated a few times before the board
> does finally boot. However this last part seems to mostly apply to our
> A5A's mostly. I do not recall the Element14 RevC's doing this.
>
> On Wed, Dec 2, 2015 at 5:32 PM, Jonathan Ross 
> wrote:
>
>> Element14 revC.
>> I think what you are describing is the power ramp issue. I don't think
>> what I'm experiencing is the same thing. I've been through the power ramp
>> issue and I just use my external KL16 to toggle the BBB pwr button a few
>> seconds after power is applied, which kicks the board into boot.
>> Jon
>>
>> On Wednesday, December 2, 2015 at 4:27:49 PM UTC-8, William Hermans wrote:
>>>
>>> Which board revision Jonathon ? This board I noticed this on last night
>>> is an Element14 RevC. But on our A5A's I never noticed the USR LEDs cycling
>>> like that.
>>>
>>> On Wed, Dec 2, 2015 at 4:59 PM, Jonathan Ross 
>>> wrote:
>>>
 Got you on the script front. My issue is slightly different, when I get
 into my magic state, pressing the power button does nothing.

 On Wednesday, December 2, 2015 at 3:51:42 PM UTC-8, William Hermans
 wrote:
>
>
>> *In my case linux is not booted at this time(none of the 4 user leds
>> lit), so a script would not help. This is why I'm doing an external
>> watchdog circuit.*
>
>
> Exactly. So here is what I mean. The USR LEDs cycle on for me *if* and
> only *if* I press the power button on the board. After that, nothing
> changes. Otherwise the LEDs are off, well the power LED is on, and the
> ethernet port lights are on too, and potentially blinking.
>
> The script, would just be to reboot the board in an attempt to put the
> board back into the bad state. For troubleshooting . . .
>
> On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross 
> wrote:
>
>> In my case linux is not booted at this time(none of the 4 user leds
>> lit), so a script would not help. This is why I'm doing an external
>> watchdog circuit.
>>
>> On Wednesday, December 2, 2015 at 3:41:32 PM UTC-8, William Hermans
>> wrote:
>>>
>>> *I didn't test the 8 second holddown of the power button but I doubt
 it would help, and unfortunately it's not a reproducible issue. I'll 
 have
 to wait for it to happen again.*

>>>
>>> I know what you mean, e.g. this happens so erratically, it's hard to
>>> tell when it'll happen next. But, I could possibly whip up a script, 
>>> and a
>>> means to automate resetting the system. Really, you could probably do 
>>> the
>>> same as well. Just put "sudo reboot" in a bash script, and run it 
>>> through
>>> rc.d
>>>
>>> With that said, I'm not 100% sure this is good for the board.
>>>
>>>
>>>
>>> On Wed, Dec 2, 2015 at 4:31 PM, Jonathan Ross 
>>> wrote:
>>>
 I didn't test the 8 second holddown of the power button but I doubt
 it would help, and unfortunately it's not a reproducible issue. I'll 
 have
 to wait for it to happen again.
 From my notes, I was seeing zero volts on power, 5V on reset.
 The zero volts on power was very weird. From the KL16 I'm
 "toggling" my own effective power button that is a transistor between 
 the
 power pin on the header and ground. The KL16 pin was not driven high (I
 checked), so I don't think it was the transistor on the cape that was
 

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

Which board revision Jonathon ? This board I noticed this on last night is
an Element14 RevC. But on our A5A's I never noticed the USR LEDs cycling
like that.

On Wed, Dec 2, 2015 at 4:59 PM, Jonathan Ross  wrote:

> Got you on the script front. My issue is slightly different, when I get
> into my magic state, pressing the power button does nothing.
>
> On Wednesday, December 2, 2015 at 3:51:42 PM UTC-8, William Hermans wrote:
>>
>>
>>> *In my case linux is not booted at this time(none of the 4 user leds
>>> lit), so a script would not help. This is why I'm doing an external
>>> watchdog circuit.*
>>
>>
>> Exactly. So here is what I mean. The USR LEDs cycle on for me *if* and
>> only *if* I press the power button on the board. After that, nothing
>> changes. Otherwise the LEDs are off, well the power LED is on, and the
>> ethernet port lights are on too, and potentially blinking.
>>
>> The script, would just be to reboot the board in an attempt to put the
>> board back into the bad state. For troubleshooting . . .
>>
>> On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross 
>> wrote:
>>
>>> In my case linux is not booted at this time(none of the 4 user leds
>>> lit), so a script would not help. This is why I'm doing an external
>>> watchdog circuit.
>>>
>>> On Wednesday, December 2, 2015 at 3:41:32 PM UTC-8, William Hermans
>>> wrote:

 *I didn't test the 8 second holddown of the power button but I doubt it
> would help, and unfortunately it's not a reproducible issue. I'll have to
> wait for it to happen again.*
>

 I know what you mean, e.g. this happens so erratically, it's hard to
 tell when it'll happen next. But, I could possibly whip up a script, and a
 means to automate resetting the system. Really, you could probably do the
 same as well. Just put "sudo reboot" in a bash script, and run it through
 rc.d

 With that said, I'm not 100% sure this is good for the board.



 On Wed, Dec 2, 2015 at 4:31 PM, Jonathan Ross 
 wrote:

> I didn't test the 8 second holddown of the power button but I doubt it
> would help, and unfortunately it's not a reproducible issue. I'll have to
> wait for it to happen again.
> From my notes, I was seeing zero volts on power, 5V on reset.
> The zero volts on power was very weird. From the KL16 I'm "toggling"
> my own effective power button that is a transistor between the power pin 
> on
> the header and ground. The KL16 pin was not driven high (I checked), so I
> don't think it was the transistor on the cape that was pulling pwr to
> ground on the BBB. And the physical button wasn't pressed in. It was as if
> the pullup at the PMIC wasn't active, yet the power LED was on. Is that
> possible?
> Wish I hadn't pulled the 5V power to reset, then I could do more
> testing.
>
> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
>>
>> I would start with your cape design and try and rule that out first.
>>
>> The reset is an input pin read by the processor, not actually a HW
>> power reset. If the SW is locked up, this could happen.
>>
>> If you hold the power button for a 8 seconds or more the board should
>> power cycle.
>>
>> When it is in this state, what do the voltages read?
>>
>> Gerald
>>
>>
>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
>> wrote:
>>
>>> Once in a blue moon one of my beaglebones will get into a state
>>> where it has power (the power LED is lit), but it is not booted. 
>>> Normally
>>> this would be fine, just hit the power button to reset. But in this 
>>> weird
>>> state the power button does nothing. The reset button does nothing.
>>> I checked the power and reset button pins on the header, the power
>>> was low, the reset was high.
>>> The only way to get the board out of this state was to pull the 5V
>>> power.
>>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it
>>> via power and/or reset buttons on the header if the BB stops sending
>>> checkins over uart. This has been working great, except for the rare 
>>> case
>>> where the board ends up in this state where the power and reset buttons 
>>> are
>>> not functioning.
>>> Any ideas how the BB could get into this state, and if there's any
>>> other way to force a reboot other than physically pulling the 5v power?
>>> Thanks,
>>> JR
>>>
>>> --
>>> 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.
>>> For more options, visit 

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

>
>
>
> *Gerald, I do not have this setup yet, but perhaps in the future may have
> the means. Is this something that might be easily checkable via JTAG ? I've
> never used JTAG before, and do not have the header in place, but do have a
> JTAG emulator.*
> *One thing that has been stopping me from seriously considering this as a
> debugging option, is that I do not know if there is an open source ( gcc -
> as in GNU compiler collection - Not the compiler its self ) tool. Passed
> that, it's all new to me, and probably a steep learning curve initially.*
>

I'll take the "sound of crickets" reaction as this is too complicated a
question to answer ;) I'll look into it on my own at some point . . .

On Wed, Dec 2, 2015 at 5:27 PM, William Hermans  wrote:

> Which board revision Jonathon ? This board I noticed this on last night is
> an Element14 RevC. But on our A5A's I never noticed the USR LEDs cycling
> like that.
>
> On Wed, Dec 2, 2015 at 4:59 PM, Jonathan Ross 
> wrote:
>
>> Got you on the script front. My issue is slightly different, when I get
>> into my magic state, pressing the power button does nothing.
>>
>> On Wednesday, December 2, 2015 at 3:51:42 PM UTC-8, William Hermans wrote:
>>>
>>>
 *In my case linux is not booted at this time(none of the 4 user leds
 lit), so a script would not help. This is why I'm doing an external
 watchdog circuit.*
>>>
>>>
>>> Exactly. So here is what I mean. The USR LEDs cycle on for me *if* and
>>> only *if* I press the power button on the board. After that, nothing
>>> changes. Otherwise the LEDs are off, well the power LED is on, and the
>>> ethernet port lights are on too, and potentially blinking.
>>>
>>> The script, would just be to reboot the board in an attempt to put the
>>> board back into the bad state. For troubleshooting . . .
>>>
>>> On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross 
>>> wrote:
>>>
 In my case linux is not booted at this time(none of the 4 user leds
 lit), so a script would not help. This is why I'm doing an external
 watchdog circuit.

 On Wednesday, December 2, 2015 at 3:41:32 PM UTC-8, William Hermans
 wrote:
>
> *I didn't test the 8 second holddown of the power button but I doubt
>> it would help, and unfortunately it's not a reproducible issue. I'll have
>> to wait for it to happen again.*
>>
>
> I know what you mean, e.g. this happens so erratically, it's hard to
> tell when it'll happen next. But, I could possibly whip up a script, and a
> means to automate resetting the system. Really, you could probably do the
> same as well. Just put "sudo reboot" in a bash script, and run it through
> rc.d
>
> With that said, I'm not 100% sure this is good for the board.
>
>
>
> On Wed, Dec 2, 2015 at 4:31 PM, Jonathan Ross 
> wrote:
>
>> I didn't test the 8 second holddown of the power button but I doubt
>> it would help, and unfortunately it's not a reproducible issue. I'll have
>> to wait for it to happen again.
>> From my notes, I was seeing zero volts on power, 5V on reset.
>> The zero volts on power was very weird. From the KL16 I'm "toggling"
>> my own effective power button that is a transistor between the power pin 
>> on
>> the header and ground. The KL16 pin was not driven high (I checked), so I
>> don't think it was the transistor on the cape that was pulling pwr to
>> ground on the BBB. And the physical button wasn't pressed in. It was as 
>> if
>> the pullup at the PMIC wasn't active, yet the power LED was on. Is that
>> possible?
>> Wish I hadn't pulled the 5V power to reset, then I could do more
>> testing.
>>
>> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
>>>
>>> I would start with your cape design and try and rule that out first.
>>>
>>> The reset is an input pin read by the processor, not actually a HW
>>> power reset. If the SW is locked up, this could happen.
>>>
>>> If you hold the power button for a 8 seconds or more the board
>>> should power cycle.
>>>
>>> When it is in this state, what do the voltages read?
>>>
>>> Gerald
>>>
>>>
>>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
>>> wrote:
>>>
 Once in a blue moon one of my beaglebones will get into a state
 where it has power (the power LED is lit), but it is not booted. 
 Normally
 this would be fine, just hit the power button to reset. But in this 
 weird
 state the power button does nothing. The reset button does nothing.
 I checked the power and reset button pins on the header, the power
 was low, the reset was high.
 The only way to get the board out of this state was to pull the 5V
 power.
 I'm using a 

Re: [beagleboard] BeagleBone Black has 4 LEDs flashing at the same time every time I try and flash the eMMC. Help!

[Robert Nelson]

On Wed, Dec 2, 2015 at 6:18 PM, Bill Dussault  wrote:
> I have a flasher image of Debian (7.9) and have it the BBB hooked up to a 5V
> 2A power supply and nothing else. I hold the boot button down with the Scan
> Disc Card inserted and wait for the four blue LED's to light at the same
> time. I release and it looks like it loads Ten minutes later all four lights
> are flashing at the same time and it will not boot ...once again What in the
> Hell am I doing wrong? Flashing this damn thing is infuriating. Can someone
> help?

Which revision of the Beagle Bone Black are you currently trying to flash?

and what's the name of the file your are flashing with?

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

[beagleboard] Re: BeagleBone Black has 4 LEDs flashing at the same time every time I try and flash the eMMC. Help!

[Bill Dussault]

It's a Rev B version

Thank you

Bill

On Wednesday, December 2, 2015 at 6:18:15 PM UTC-6, Bill Dussault wrote:
>
> I have a flasher image of Debian (7.9) and have it the BBB hooked up to a 
> 5V 2A power supply and nothing else. I hold the boot button down with the 
> Scan Disc Card inserted and wait for the four blue LED's to light at the 
> same time. I release and it looks like it loads Ten minutes later all four 
> lights are flashing at the same time and it will not boot ...once again 
> What in the Hell am I doing wrong? Flashing this damn thing is infuriating. 
> Can someone help?
>
> Thanks
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[evilwulfie]

After reading all about the WDT inside the sitara the only way to cold
reset the processor is to power cycle it OR
pull PMIC_PGOOD low which pulls PORZ low which will cold reset the IC.
IT seems to me that there is some shortsightedness of TI not allowing
the cold reset to be pulsed from a WDT.
In case of a processor hang where a warm reset cannot allow the IC to
recover.

So you may want to find that signal on the board and tie your external
WDT to it and see if this solves your problem.
Maybe in the next rev of the BBB this can be some how made available for
an external WDT.





On 12/2/2015 5:42 PM, William Hermans wrote:
> So just in case this is helpful to the whole process:
>
> william@beaglebone:~$ uname -a
> Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC 2015
> armv7l GNU/Linux
> william@beaglebone:~$ cat /etc/dogtag
> BeagleBoard.org Debian Image 2015-03-01
> william@beaglebone:~$ pstree
> init-+-bluetoothd
>  |-cron
>  |-dbus-daemon
>  |-7*[getty]
>  |-rpc.idmapd
>  |-rpc.statd
>  |-rpcbind
>  |-rsyslogd---3*[{rsyslogd}]
>  |-sshd---sshd---sshd---bash---pstree
>  `-udevd---2*[udevd]
>
> The output of pstree is just to show that I'm not running systemd, but
> instead sysv.
>
> On Wed, Dec 2, 2015 at 5:38 PM, William Hermans  > wrote:
>
> /Element14 revC./
> /I think what you are describing is the power ramp issue. I
> don't think what I'm experiencing is the same thing. I've been
> through the power ramp issue and I just use my external KL16
> to toggle the BBB pwr button a few seconds after power is
> applied, which kicks the board into boot./
> /Jon/
>
>
> Not trying to be difficult, or argumentative . . . but no, I think
> we're experiencing the same thing. Only because the board will not
> boot up Linux at all after it gets into this state. The LEDs will
> cycle on, then off, but then nothing. I have to physically remove
> the power from the board for a few seconds, before it'll boot
> again. Passed that, sometimes, the processes of removing the power
> may have to be repeated a few times before the board does finally
> boot. However this last part seems to mostly apply to our A5A's
> mostly. I do not recall the Element14 RevC's doing this.
>
> On Wed, Dec 2, 2015 at 5:32 PM, Jonathan Ross
> > wrote:
>
> Element14 revC.
> I think what you are describing is the power ramp issue. I
> don't think what I'm experiencing is the same thing. I've been
> through the power ramp issue and I just use my external KL16
> to toggle the BBB pwr button a few seconds after power is
> applied, which kicks the board into boot.
> Jon
>
> On Wednesday, December 2, 2015 at 4:27:49 PM UTC-8, William
> Hermans wrote:
>
> Which board revision Jonathon ? This board I noticed this
> on last night is an Element14 RevC. But on our A5A's I
> never noticed the USR LEDs cycling like that.
>
> On Wed, Dec 2, 2015 at 4:59 PM, Jonathan Ross
>  wrote:
>
> Got you on the script front. My issue is slightly
> different, when I get into my magic state, pressing
> the power button does nothing.
>
> On Wednesday, December 2, 2015 at 3:51:42 PM UTC-8,
> William Hermans wrote:
>
> /In my case linux is not booted at this
> time(none of the 4 user leds lit), so a script
> would not help. This is why I'm doing an
> external watchdog circuit.
> /
>
>
> Exactly. So here is what I mean. The USR LEDs
> cycle on for me *if* and only *if* I press the
> power button on the board. After that, nothing
> changes. Otherwise the LEDs are off, well the
> power LED is on, and the ethernet port lights are
> on too, and potentially blinking.
>
> The script, would just be to reboot the board in
> an attempt to put the board back into the bad
> state. For troubleshooting . . .
>
> On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross
>  wrote:
>
> In my case linux is not booted at this
> time(none of the 4 user leds lit), so a script
> would not help. This is why I'm doing an
> external watchdog circuit.
>
> On Wednesday, December 2, 2015 at 3:41:32 PM
> UTC-8, William Hermans wrote:
>
>

Re: [beagleboard] Re: BeagleBone Black has 4 LEDs flashing at the same time every time I try and flash the eMMC. Help!

[Robert Nelson]

On Wed, Dec 2, 2015 at 7:11 PM, Bill Dussault  wrote:
> It's a Rev B version

Okay, so the Rev B is only 2GB, can we assume you've been flashing an
image with the word "2GB" in it, or did you try to flash a "4GB"
image?

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

Re: [beagleboard] BBB frozen, how to reset?

[John Syne]

I’m not sure why, but 

echo mem > /sys/power/state

does not return from suspend when I press any key on the keyboard; however

echo standby > /sys/power/state

does work correctly and returns to running state when I press any key on the 
keyboard. Also, pressing the power button (1 second) also returns to run mode. 


Regards,
John




> On Dec 2, 2015, at 6:48 PM, Jonathan Ross  wrote:
> 
> Got it into broken state again. My notes were incorrect, I see 5V on the 
> power button, and 0V on the reset button. Holding down power button for 8 
> seconds results in a blip on USR2, but no boot.
> I'm thinking it's got to be cape-based, and I'm holding a pin high that 
> shouldn't be high until after boot. But I'm not using any of the EMMC pins or 
> boot pins (or any P8 pins for that matter).
> 
> On Wednesday, December 2, 2015 at 3:31:17 PM UTC-8, Jonathan Ross wrote:
> I didn't test the 8 second holddown of the power button but I doubt it would 
> help, and unfortunately it's not a reproducible issue. I'll have to wait for 
> it to happen again.
> From my notes, I was seeing zero volts on power, 5V on reset.
> The zero volts on power was very weird. From the KL16 I'm "toggling" my own 
> effective power button that is a transistor between the power pin on the 
> header and ground. The KL16 pin was not driven high (I checked), so I don't 
> think it was the transistor on the cape that was pulling pwr to ground on the 
> BBB. And the physical button wasn't pressed in. It was as if the pullup at 
> the PMIC wasn't active, yet the power LED was on. Is that possible?
> Wish I hadn't pulled the 5V power to reset, then I could do more testing.
> 
> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
> I would start with your cape design and try and rule that out first.
> 
> The reset is an input pin read by the processor, not actually a HW power 
> reset. If the SW is locked up, this could happen.
> 
> If you hold the power button for a 8 seconds or more the board should power 
> cycle.
> 
> When it is in this state, what do the voltages read?
> 
> Gerald
> 
> 
> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross > wrote:
> Once in a blue moon one of my beaglebones will get into a state where it has 
> power (the power LED is lit), but it is not booted. Normally this would be 
> fine, just hit the power button to reset. But in this weird state the power 
> button does nothing. The reset button does nothing.
> I checked the power and reset button pins on the header, the power was low, 
> the reset was high.
> The only way to get the board out of this state was to pull the 5V power.
> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via 
> power and/or reset buttons on the header if the BB stops sending checkins 
> over uart. This has been working great, except for the rare case where the 
> board ends up in this state where the power and reset buttons are not 
> functioning.
> Any ideas how the BB could get into this state, and if there's any other way 
> to force a reboot other than physically pulling the 5v power?
> Thanks,
> JR
> 
> -- 
> 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 <>.
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> Gerald
>  
> ger...@beagleboard.org <>
> http://beagleboard.org/ 
> 
> -- 
> 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 
> .
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[John Syne]

We can speculate all day long, but measuring the 5V current consumption will 
tell us a lot more about the power mode state than anything else.

Regards,
John




> On Dec 2, 2015, at 3:19 PM, William Hermans  wrote:
> 
> If the software is locked up, the USR LEDs would not cycle as if the system 
> is attempting to restart.
> 
> On Wed, Dec 2, 2015 at 4:08 PM, John Syne  > wrote:
> From what Gerald said previously in this thread:
> 
> "The reset is an input pin read by the processor, not actually a HW power 
> reset. If the SW is locked up, this could happen.”
> 
> Regards,
> John
> 
> 
> 
> 
>> On Dec 2, 2015, at 2:55 PM, William Hermans > > wrote:
>> 
>> If the board was in sleep, then why wont the reset button reset ? Passed 
>> that, why would the USR cycle( flash on then off ) then nothing ?
>> 
>> On Wed, Dec 2, 2015 at 3:47 PM, John Syne > > wrote:
>> Sounds to me that like BBB has gone into sleep mode and there is no trigger 
>> to wake it up. Is there a way to measure the current consumption? 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Dec 2, 2015, at 2:40 PM, William Hermans >> > wrote:
>>> 
>>> One more thing of note. I do not run systemd - Ever. I run SYSV as an init 
>>> daemon. I only mention this as I think Robert said something about systemd 
>>> lessening this issue.
>>> 
>>> On Wed, Dec 2, 2015 at 3:36 PM, Gerald Coley >> > wrote:
>>> Hmm, not sure what is going on. Sounds like the processor has stopped 
>>> running the code and halted but it forgot to turn off the lights.
>>> 
>>> Gerald
>>> 
>>> On Wed, Dec 2, 2015 at 4:26 PM, William Hermans >> > wrote:
>>> Gerald, it's like the board hangs at power down, but I can not be 100% 
>>> sure. The reason why I "assume" it's at power down, is that the heartbeat 
>>> blink stops, but the rest of the LEDs stay on, and the ethernet port light 
>>> still blinks.
>>> 
>>> The board I experienced this on last night is an Element14 RevC, but I do 
>>> also have a circuitco A5A that exhibits the same thing.
>>> 
>>> On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley >> > wrote:
>>> Is this on power up or is this state happening some time later? If it is on 
>>> power up, then the power supply most likely is the issue based on the ramp 
>>> requirements of the PMIC. 
>>> 
>>> If the power LED is on, then the PMIC is on and ramped up. That is why I 
>>> asked for the voltages.
>>> 
>>> It also could be a boot pin read issue where it misreads the boot pins. If 
>>> that is the case you should see that from the serial port.
>>> 
>>> Gerald
>>> 
>>> 
>>> On Wed, Dec 2, 2015 at 4:15 PM, William Hermans >> > wrote:
>>> For what it's worth Gerald, this happens with nothing connected to the 
>>> board as well. This just happened to me last night after issuing a reboot 
>>> command from the command line.
>>> 
>>> I remember at some point you all were talking about something about the 
>>> "ramp time" of the PMIC or something.
>>> 
>>> On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley >> > wrote:
>>> I would start with your cape design and try and rule that out first.
>>> 
>>> The reset is an input pin read by the processor, not actually a HW power 
>>> reset. If the SW is locked up, this could happen.
>>> 
>>> If you hold the power button for a 8 seconds or more the board should power 
>>> cycle.
>>> 
>>> When it is in this state, what do the voltages read?
>>> 
>>> Gerald
>>> 
>>> 
>>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross >> > wrote:
>>> Once in a blue moon one of my beaglebones will get into a state where it 
>>> has power (the power LED is lit), but it is not booted. Normally this would 
>>> be fine, just hit the power button to reset. But in this weird state the 
>>> power button does nothing. The reset button does nothing.
>>> I checked the power and reset button pins on the header, the power was low, 
>>> the reset was high.
>>> The only way to get the board out of this state was to pull the 5V power.
>>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via 
>>> power and/or reset buttons on the header if the BB stops sending checkins 
>>> over uart. This has been working great, except for the rare case where the 
>>> board ends up in this state where the power and reset buttons are not 
>>> functioning.
>>> Any ideas how the BB could get into this state, and if there's any other 
>>> way to force a reboot other than physically pulling the 5v power?
>>> Thanks,
>>> JR
>>> 
>>> -- 
>>> For more options, visit 

Re: [beagleboard] BBB frozen, how to reset?

[John Syne]

We are just trying to debug the problem. This is a process of elimination so 
that we can narrow down the problem. 

I have two BBB Rev A5A and I have never seen this problem. Admittedly, I boot 
these boards over NFS and I use SystemD. I also use this device to switch the 
power to the BBB on/off:

http://www.hardkernel.com/main/products/prdt_info.php?g_code=G137361754360 


With the 5V adapter always on, this ODroid Smart Power does a clean power-on 
via an electronic switch.

Regards,
John




> On Dec 2, 2015, at 6:48 PM, Jonathan Ross  wrote:
> 
> Got it into broken state again. My notes were incorrect, I see 5V on the 
> power button, and 0V on the reset button. Holding down power button for 8 
> seconds results in a blip on USR2, but no boot.
> I'm thinking it's got to be cape-based, and I'm holding a pin high that 
> shouldn't be high until after boot. But I'm not using any of the EMMC pins or 
> boot pins (or any P8 pins for that matter).
> 
> On Wednesday, December 2, 2015 at 3:31:17 PM UTC-8, Jonathan Ross wrote:
> I didn't test the 8 second holddown of the power button but I doubt it would 
> help, and unfortunately it's not a reproducible issue. I'll have to wait for 
> it to happen again.
> From my notes, I was seeing zero volts on power, 5V on reset.
> The zero volts on power was very weird. From the KL16 I'm "toggling" my own 
> effective power button that is a transistor between the power pin on the 
> header and ground. The KL16 pin was not driven high (I checked), so I don't 
> think it was the transistor on the cape that was pulling pwr to ground on the 
> BBB. And the physical button wasn't pressed in. It was as if the pullup at 
> the PMIC wasn't active, yet the power LED was on. Is that possible?
> Wish I hadn't pulled the 5V power to reset, then I could do more testing.
> 
> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
> I would start with your cape design and try and rule that out first.
> 
> The reset is an input pin read by the processor, not actually a HW power 
> reset. If the SW is locked up, this could happen.
> 
> If you hold the power button for a 8 seconds or more the board should power 
> cycle.
> 
> When it is in this state, what do the voltages read?
> 
> Gerald
> 
> 
> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross > wrote:
> Once in a blue moon one of my beaglebones will get into a state where it has 
> power (the power LED is lit), but it is not booted. Normally this would be 
> fine, just hit the power button to reset. But in this weird state the power 
> button does nothing. The reset button does nothing.
> I checked the power and reset button pins on the header, the power was low, 
> the reset was high.
> The only way to get the board out of this state was to pull the 5V power.
> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via 
> power and/or reset buttons on the header if the BB stops sending checkins 
> over uart. This has been working great, except for the rare case where the 
> board ends up in this state where the power and reset buttons are not 
> functioning.
> Any ideas how the BB could get into this state, and if there's any other way 
> to force a reboot other than physically pulling the 5v power?
> Thanks,
> JR
> 
> -- 
> 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 <>.
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> Gerald
>  
> ger...@beagleboard.org <>
> http://beagleboard.org/ 
> 
> -- 
> 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 
> .
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Newest Debian images from eLinux missing ntp and other packages

[Robert Nelson]

On Wed, Dec 2, 2015 at 10:34 PM, Doyle S  wrote:
> Thanks so much for the fast response!
>
> I'm helping my coworker out, so I had to ask him which images he used.
>
> But I did a bit of research and confirmed your comments back, and it all
> makes perfect sense now. =)
>
> We were using the
> "BBB-eMMC-flasher-debian-7.9-console-armhf-2015-11-03-2gb.img" image, which,
> as you pointed as, is a console release.
> Thanks for clarifying this - I totally understand and appreciate the need
> for a lightweight image, so I didn't mean to suggest these things should be
> added to the console release.
> Same goes for wireless-tools.
>
> With the above image, I confirmed the lack of sbin and wrong date on boot
> up, no biggie.

sbin:

install patch: (sudo apt-get install patch)

sudo su
cd /
patch -p1 < /opt/scripts/mods/debian-add-sbin-usr-sbin-to-default-path.diff

date on boot:

wheezy:
we rely on ntpdate, which needs the network setup first, so if you
search journalctl  you'll notice ntpdate failing..

jessie:
we can use systemd-timesync, since systemd knows when the network is
connected, it'll automatically sync the time, plus it'll backup the
clock between reboots. So it's the most accurate..

Overal, we preseed the date so the "2015-11-03" image will always have
a clock after "2015-11-03" and not 1970...

> I tried syncing the time, but I got command not found and didn't find it in
> sbin, but installing some version of ntp seems to resolve that.
>
> As for the issue we faced with DNS issues and issues updating the repo, it
> was the exact same issue in this post -
> https://groups.google.com/forum/#!category-topic/beagleboard/ubuntu/DjFqxreT1AA
> At the time, I had to hard code the IP for the missing repos (I think it was
> also the ports.ubuntu repo) and it worked.
> But I just tested this on a fresh flash and wasn't able to recreate the
> issue, so in my test case, everything worked great.
> I'll dig a bit more on this but I think this may have been a weird "freak"
> occurrence.

For that, i'd just run:

sudo ifconfig -a
sudo dhclient eth0

in the wheezy/lxde we have wicd setting up eth0 automaticly (and in
jessie/lxqt we have connman)

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

Re: [beagleboard] BBB frozen, how to reset?

[Robert Nelson]

On Wed, Dec 2, 2015 at 11:11 PM, John Syne  wrote:
> I’m not sure why, but
>
> echo mem > /sys/power/state
>
> does not return from suspend when I press any key on the keyboard; however

If i remember right, in v4.1.x the usarts are not enabled by default
as a wakeup source anymore.

so make sure you enable it:

http://elinux.org/OMAP_Power_Management

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

[beagleboard] Re: setting priority of two ethernet connections

[cfordonez]

Hi,

I my case, I use two interfaces  eth0 (to local network access) and wlan0 
(to get internet),   the eth0 blocks wlan0, and I don't get internet, when 
Unplugged the cable, I get internet again.  How I set Priority in the 
interfaces?? the most important for me is  wlan0  to have internet,  the 
second one  eth0.

I tried with IFMETRIC, but my BBB omit everything. 
When I reboot, use a few seconds the wlan0, but a moment after, eth0 blocks 
again.

with route -n ,  I see the routing,  Despite of set metric 0 or 1 to the 
wlan0,  and metric 5, 10 or higher,  the eth0 appers with  a metric 0  ???

This procedures work fine with the Rasberry pi.

any ideas, or help in this topic.



On Sunday, July 20, 2014 at 5:43:49 AM UTC-5, nebius wrote:
>
> Hi,
> here Nevio, from Italy. I'm new in the forum.
> I'm playing with a BeagleBone Black C with debian 7.5 2014-07-06 version.
> The BBB is connected to the local network with internet access, and I run 
> it with ssh.
> I have connected also a usb internet-key (Huawei E3131) that work out of 
> the box. This internet key is different from the others because it is seen 
> as an ethernet device, not usb device.
> I am having trouble with configuring which internet connection the system 
> has to use.
> In particular I would like the BBB use the internet connection via LAN if 
> the internet via LAN is up, else the other connection (via usb internet 
> key).
> I have configured the two eth connections with different priorities 
> (/etc/network/interfaces), however if the LAN has no internet connection 
> the system don't use the usb-key.
> I post my config file.
>
> eth0 = wired connection, gateway 192.168.0.1
> eth1 = via usb internet key, gateway 192.168.1.1
>
> debian@arm:~$ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> From 192.168.0.1 icmp_seq=1 Destination Net Unreachable
> From 192.168.0.1 icmp_seq=2 Destination Net Unreachable
> From 192.168.0.1 icmp_seq=3 Destination Net Unreachable
> From 192.168.0.1 icmp_seq=4 Destination Net Unreachable
> From 192.168.0.1 icmp_seq=5 Destination Net Unreachable
> ^C
> --- 8.8.8.8 ping statistics ---
> 9 packets transmitted, 0 received, +9 errors, 100% packet loss, time 
> 8012ms
>
>
> debian@arm:~$ ping -I eth1 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) from 192.168.0.14 eth1: 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_req=3 ttl=43 time=658 ms
> 64 bytes from 8.8.8.8: icmp_req=2 ttl=43 time=1687 ms
> 64 bytes from 8.8.8.8: icmp_req=1 ttl=43 time=2687 ms
> 64 bytes from 8.8.8.8: icmp_req=4 ttl=43 time=47.6 ms
> ^C
> --- 8.8.8.8 ping statistics ---
> 8 packets transmitted, 7 received, 12% packet loss, time 7003ms
> rtt min/avg/max/mdev = 47.670/899.876/2687.464/921.850 ms, pipe 3
>
>
> debian@arm:~$ sudo route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse 
> Iface
> 0.0.0.0 192.168.0.1 0.0.0.0 UG0  00 
> eth0
> 0.0.0.0 192.168.1.1 0.0.0.0 UG10 00 
> eth1
> 192.168.0.0 0.0.0.0 255.255.255.0   U 0  00 
> eth0
> 192.168.1.0 0.0.0.0 255.255.255.0   U 0  00 
> eth1
> 192.168.7.0 0.0.0.0 255.255.255.252 U 0  00 
> usb0
>
>
> debian@arm:~$ nano /etc/network/interfaces
>
>
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
>
> # The loopback network interface
> auto lo
> iface lo inet loopback
>
>
> # The primary network interface
> auto eth0
> iface eth0 inet static
> address 192.168.0.14
> netmask 255.255.255.0
> gateway 192.168.0.1
>
>
> # Example to keep MAC address between reboots
> #hwaddress ether DE:AD:BE:EF:CA:FE
>
>
> # The secondary network interface
> auto eth1
> allow-hotplug eth1
> #allow-auto eth1
> iface eth1 inet static
> address 192.168.1.100
> netmask 255.255.255.0
> gateway 192.168.1.1
> metric 10
>
>
> # WiFi Example
> #auto wlan0
> #iface wlan0 inet dhcp
> #wpa-ssid "essid"
> #wpa-psk  "password"
>
>
> # Ethernet/RNDIS gadget (g_ether)
> # ... or on host side, usbnet and random hwaddr
> # Note on some boards, usb0 is automaticly setup with an init script
> iface usb0 inet static
> address 192.168.7.2
> netmask 255.255.255.0
> network 192.168.7.0
> gateway 192.168.7.1
>
>
-- 

--
*Universidad del Cauca: Calidad académica con compromiso regional y 
nacional.*

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

Re: [beagleboard] BBB frozen, how to reset?

[John Syne]

Kernel version 4.1.13-ti-r33
BBB V A5A

After logging in, BBB 5V current is ~375mA

echo -n “mem” > /sys/power/state

BBB 5V current is 56mA

USR LED’s are all off
PWR LED on

Power Button press has no effect (1 second)
Reset Button press has no effect

***
Power Cycle BBB

After logging in, BBB 5V current is ~375mA

echo -n “mem” > /sys/power/state

BBB 5V current is 56mA

USR LED’s are all off
PWR LED on

Press Space Bar

BBB 5V current is 131mA

Power Button press has no effect (1 second)
Reset Button press reboots BBB

Regards,
John




> On Dec 2, 2015, at 7:19 PM, evilwulfie  wrote:
> 
> 
>  You can measure power all you want but if there is no way to reset the 
> processor what good is the device in a remote location. I have had things on 
> a remote mountain top at a transmitter site in winter that if things were 
> unresponsive
> would ruin  2 or 3 days trying to get there to reset the device on a 
> snowmobile. 
> 
> Fail-safe computers are desirable. Hangs with no way to reboot a system are 
> not.
> 
> On 12/2/2015 7:58 PM, John Syne wrote:
>> We can speculate all day long, but measuring the 5V current consumption will 
>> tell us a lot more about the power mode state than anything else.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Dec 2, 2015, at 3:19 PM, William Hermans >> > wrote:
>>> 
>>> If the software is locked up, the USR LEDs would not cycle as if the system 
>>> is attempting to restart.
>>> 
>>> On Wed, Dec 2, 2015 at 4:08 PM, John Syne < 
>>> john3...@gmail.com > 
>>> wrote:
>>> From what Gerald said previously in this thread:
>>> 
>>> "The reset is an input pin read by the processor, not actually a HW power 
>>> reset. If the SW is locked up, this could happen.”
>>> 
>>> Regards,
>>> John
>>> 
>>> 
>>> 
>>> 
 On Dec 2, 2015, at 2:55 PM, William Hermans < 
 yyrk...@gmail.com > 
 wrote:
 
 If the board was in sleep, then why wont the reset button reset ? Passed 
 that, why would the USR cycle( flash on then off ) then nothing ?
 
 On Wed, Dec 2, 2015 at 3:47 PM, John Syne < 
 john3...@gmail.com > 
 wrote:
 Sounds to me that like BBB has gone into sleep mode and there is no 
 trigger to wake it up. Is there a way to measure the current consumption? 
 
 Regards,
 John
 
 
 
 
> On Dec 2, 2015, at 2:40 PM, William Hermans < 
> yyrk...@gmail.com > 
> wrote:
> 
> One more thing of note. I do not run systemd - Ever. I run SYSV as an 
> init daemon. I only mention this as I think Robert said something about 
> systemd lessening this issue.
> 
> On Wed, Dec 2, 2015 at 3:36 PM, Gerald Coley < 
> ger...@beagleboard.org 
> > wrote:
> Hmm, not sure what is going on. Sounds like the processor has stopped 
> running the code and halted but it forgot to turn off the lights.
> 
> Gerald
> 
> On Wed, Dec 2, 2015 at 4:26 PM, William Hermans < 
> yyrk...@gmail.com > 
> wrote:
> Gerald, it's like the board hangs at power down, but I can not be 100% 
> sure. The reason why I "assume" it's at power down, is that the heartbeat 
> blink stops, but the rest of the LEDs stay on, and the ethernet port 
> light still blinks.
> 
> The board I experienced this on last night is an Element14 RevC, but I do 
> also have a circuitco A5A that exhibits the same thing.
> 
> On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley < 
> ger...@beagleboard.org 
> > wrote:
> Is this on power up or is this state happening some time later? If it is 
> on power up, then the power supply most likely is the issue based on the 
> ramp requirements of the PMIC. 
> 
> If the power LED is on, then the PMIC is on and ramped up. That is why I 
> asked for the voltages.
> 
> It also could be a boot pin read issue where it misreads the boot pins. 
> If that is the case you should see that from the serial port.
> 
> Gerald
> 
> 
> On Wed, Dec 2, 2015 at 4:15 PM, William Hermans < 
> yyrk...@gmail.com > 
> wrote:
> For what it's worth Gerald, this happens with nothing connected to the 
> board as well. This just happened to me last night after issuing a reboot 
> command from the command line.
> 
> I remember at some point you all were talking about something about the 
> "ramp time" of the PMIC or something.
> 
> 

Re: [beagleboard] Newest Debian images from eLinux missing ntp and other packages

[Doyle S]

Thanks so much for the fast response!  

I'm helping my coworker out, so I had to ask him which images he used.

But I did a bit of research and confirmed your comments back, and it all 
makes perfect sense now. =)

We were using the 
"BBB-eMMC-flasher-debian-7.9-console-armhf-2015-11-03-2gb.img" image, 
which, as you pointed as, is a console release.
Thanks for clarifying this - I totally understand and appreciate the need 
for a lightweight image, so I didn't mean to suggest these things *should* 
be added to the console release.
Same goes for wireless-tools.

With the above image, I confirmed the lack of sbin and wrong date on boot 
up, no biggie.
I tried syncing the time, but I got command not found and didn't find it in 
sbin, but installing some version of ntp seems to resolve that.

As for the issue we faced with DNS issues and issues updating the repo, it 
was the exact same issue in this post - 
https://groups.google.com/forum/#!category-topic/beagleboard/ubuntu/DjFqxreT1AA
At the time, I had to hard code the IP for the missing repos (I think it 
was also the ports.ubuntu repo) and it worked.
But I just tested this on a fresh flash and wasn't able to recreate the 
issue, so in my test case, everything worked great.
I'll dig a bit more on this but I think this may have been a weird "freak" 
occurrence.

Thanks again for your response and help, now back to my BBB!

Have a good one, Robert

On Wednesday, December 2, 2015 at 5:48:23 PM UTC-8, RobertCNelson wrote:
>
> On Wed, Dec 2, 2015 at 6:33 PM,   wrote: 
> > I have been working the BBB Rev B and C for over a year, and I've been 
> using 
> > the Debian images provided by eLinux and Beagleboard, available from - 
> > 
> > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Releases 
> > 
> > and http://beagleboard.org/latest-images 
> > 
> > In the most recent builds from 2015-11-03, I've been having a lot of 
> trouble 
> > with missing system tools and packages. 
> > Some examples include - 
>
> Please include the file name, there's dozen images... 
>
> > - wrong date and time set due to ntp service not being installed, 
> installing 
> > ntp resolves this issue 
>
> wheezy: ntpdate 
> jessie: systemd-timesync 
>
> > - inability to connect using supported wifi adapter due to missing 
> > wireless-tools package 
>
> your using the "console" image... 
>
> > - missing DNS support which causes apt-get to fail as it is unable to 
> > correctly resolve the IP addresses for the rcn.ee repos included in the 
> > builds 
>
> okay, this is od.. 
>
>
> > - missing /sbin directory in PATH, including missing ifconfig command, 
> > adding /sbin to path resolves these issues 
>
> yeap, this is the "console" image, can't fix this as patch isn't 
> installed.. 
>
> > Did I miss some announcement or release notes about these releases that 
> says 
> > they are lighter than previous builds? 
> > 
> > Why didn't I have most of these issues with previous builds? 
> > IIRC, all the builds I used before included ntp, /sbin in the PATH, and 
> DNS 
> > support, and wireless worked OOTB (after editing 
> /etc/network/interfaces) 
>
> Based on that, it sounds like your using the "console" over the 
> "lxde/lxqt" image.  The goal with the "console" image was to be as 
> small but yet "flash" the eMMC..  Not everyone likes to "apt-get 
> remove xyz" instead they want something very small, and wireless tools 
> are not on that requirement list.. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] ssh keygen on boot

[Robert Nelson]

On Wed, Dec 2, 2015 at 10:25 PM, Josh Datko  wrote:
> On Wed, 2015-12-02 at 19:41 -0600, Robert Nelson wrote:
>> On Wed, Dec 2, 2015 at 7:24 PM, Josh Datko  wrote:
>
>> #Regenerate ssh host keys
>> if [ -f /etc/ssh/ssh.regenerate ] ; then
>> rm -rf /etc/ssh/ssh_host_* || true
>> dpkg-reconfigure openssh-server
>> sync
>> if [ -s /etc/ssh/ssh_host_ecdsa_key.pub ] ; then
>> rm -f /etc/ssh/ssh.regenerate || true
>> sync
>> fi
>> if [ -f /etc/init.d/ssh ] ; then
>> /etc/init.d/ssh restart
>> fi
>> fi
>>
>> https://github.com/RobertCNelson/omap-image-builder/blob/master/target/init_scripts/generic-debian.sh#L41-L53
>>
>
> So, it's a bit late, and I'm a bit grogy but I think this is where the
> issue might be. It's not good enough just to call regenerate if the
> entropy pool isn't properly seeded, otherwise the key generated will be
> predictable.
>
> And while the hwrng is enable I don't think it actively contributes to
> the kernel entropy pool. I *thought* that is where there is the user
> space rngd daemon, but again... tired...
>
> The issue is the creation of /var/lib/systemd/random-seed, which
> could/should be done by dd'ing from /dev/hwrng to this file. If software
> creates this, then it will be predictable.

and i'm not an expert either, so with 4.1.13-ti-r34:

debian@test-bbb-3:~$ uname -r
4.1.13-ti-r34
debian@test-bbb-3:~$ journalctl | grep entropy
Dec 02 04:15:42 test-bbb-3 kernel: random: systemd-udevd urandom read
with 10 bits of entropy available

That's before the init script runs...

>> So ignoring the root login over 22 with no password...  or
>> nodejs/bonescript/etc..  At least the key is safe. ;)
>
> touche, we are plugging a leak while water is pouring over our heads :)
> I still advocate removing the the no password root login thing.

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

Re: [beagleboard] BBB frozen, how to reset?

[John Syne]

Hi Robert,

cat /sys/devices/platform/ocp/44e09000.serial/power/wakeup
enabled

Strange that it works for standby and not mem.

Regards,
John




> On Dec 2, 2015, at 9:16 PM, Robert Nelson  wrote:
> 
> On Wed, Dec 2, 2015 at 11:11 PM, John Syne  wrote:
>> I’m not sure why, but
>> 
>> echo mem > /sys/power/state
>> 
>> does not return from suspend when I press any key on the keyboard; however
> 
> If i remember right, in v4.1.x the usarts are not enabled by default
> as a wakeup source anymore.
> 
> so make sure you enable it:
> 
> http://elinux.org/OMAP_Power_Management
> 
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleBone Black has 4 LEDs flashing at the same time every time I try and flash the eMMC. Help!

[Bill Dussault]

That was it... Yeah It's on me thanks!


On Wednesday, December 2, 2015 at 6:18:15 PM UTC-6, Bill Dussault wrote:
>
> I have a flasher image of Debian (7.9) and have it the BBB hooked up to a 
> 5V 2A power supply and nothing else. I hold the boot button down with the 
> Scan Disc Card inserted and wait for the four blue LED's to light at the 
> same time. I release and it looks like it loads Ten minutes later all four 
> lights are flashing at the same time and it will not boot ...once again 
> What in the Hell am I doing wrong? Flashing this damn thing is infuriating. 
> Can someone help?
>
> Thanks
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[Jonathan Ross]

Got it into broken state again. My notes were incorrect, I see 5V on the 
power button, and 0V on the reset button. Holding down power button for 8 
seconds results in a blip on USR2, but no boot.
I'm thinking it's got to be cape-based, and I'm holding a pin high that 
shouldn't be high until after boot. But I'm not using any of the EMMC pins 
or boot pins (or any P8 pins for that matter).

On Wednesday, December 2, 2015 at 3:31:17 PM UTC-8, Jonathan Ross wrote:
>
> I didn't test the 8 second holddown of the power button but I doubt it 
> would help, and unfortunately it's not a reproducible issue. I'll have to 
> wait for it to happen again.
> From my notes, I was seeing zero volts on power, 5V on reset.
> The zero volts on power was very weird. From the KL16 I'm "toggling" my 
> own effective power button that is a transistor between the power pin on 
> the header and ground. The KL16 pin was not driven high (I checked), so I 
> don't think it was the transistor on the cape that was pulling pwr to 
> ground on the BBB. And the physical button wasn't pressed in. It was as if 
> the pullup at the PMIC wasn't active, yet the power LED was on. Is that 
> possible?
> Wish I hadn't pulled the 5V power to reset, then I could do more testing.
>
> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
>>
>> I would start with your cape design and try and rule that out first.
>>
>> The reset is an input pin read by the processor, not actually a HW power 
>> reset. If the SW is locked up, this could happen.
>>
>> If you hold the power button for a 8 seconds or more the board should 
>> power cycle.
>>
>> When it is in this state, what do the voltages read?
>>
>> Gerald
>>
>>
>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross  
>> wrote:
>>
>>> Once in a blue moon one of my beaglebones will get into a state where it 
>>> has power (the power LED is lit), but it is not booted. Normally this would 
>>> be fine, just hit the power button to reset. But in this weird state the 
>>> power button does nothing. The reset button does nothing.
>>> I checked the power and reset button pins on the header, the power was 
>>> low, the reset was high.
>>> The only way to get the board out of this state was to pull the 5V power.
>>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via 
>>> power and/or reset buttons on the header if the BB stops sending checkins 
>>> over uart. This has been working great, except for the rare case where the 
>>> board ends up in this state where the power and reset buttons are not 
>>> functioning.
>>> Any ideas how the BB could get into this state, and if there's any other 
>>> way to force a reboot other than physically pulling the 5v power?
>>> Thanks,
>>> JR
>>>
>>> -- 
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Gerald
>>  
>> ger...@beagleboard.org
>> http://beagleboard.org/
>>
>

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

Re: [beagleboard] BBB frozen, how to reset?

[evilwulfie]

 You can measure power all you want but if there is no way to reset the
processor what good is the device in a remote location. I have had
things on a remote mountain top at a transmitter site in winter that if
things were unresponsive
would ruin  2 or 3 days trying to get there to reset the device on a
snowmobile.

Fail-safe computers are desirable. Hangs with no way to reboot a system
are not.

On 12/2/2015 7:58 PM, John Syne wrote:
> We can speculate all day long, but measuring the 5V current
> consumption will tell us a lot more about the power mode state than
> anything else.
>
> Regards,
> John
>
>
>
>
>> On Dec 2, 2015, at 3:19 PM, William Hermans > > wrote:
>>
>> If the software is locked up, the USR LEDs would not cycle as if the
>> system is attempting to restart.
>>
>> On Wed, Dec 2, 2015 at 4:08 PM, John Syne > > wrote:
>>
>> From what Gerald said previously in this thread:
>>
>> "The reset is an input pin read by the processor, not actually a
>> HW power reset. If the SW is locked up, this could happen.”
>>
>> Regards,
>> John
>>
>>
>>
>>
>>> On Dec 2, 2015, at 2:55 PM, William Hermans >> > wrote:
>>>
>>> If the board was in sleep, then why wont the reset button reset
>>> ? Passed that, why would the USR cycle( flash on then off ) then
>>> nothing ?
>>>
>>> On Wed, Dec 2, 2015 at 3:47 PM, John Syne >> > wrote:
>>>
>>> Sounds to me that like BBB has gone into sleep mode and
>>> there is no trigger to wake it up. Is there a way to measure
>>> the current consumption? 
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
 On Dec 2, 2015, at 2:40 PM, William Hermans
 > wrote:

 One more thing of note. I do not run systemd - Ever. I run
 SYSV as an init daemon. I only mention this as I think
 Robert said something about systemd lessening this issue.

 On Wed, Dec 2, 2015 at 3:36 PM, Gerald Coley
 > wrote:

 Hmm, not sure what is going on. Sounds like the
 processor has stopped running the code and halted but
 it forgot to turn off the lights.

 Gerald

 On Wed, Dec 2, 2015 at 4:26 PM, William Hermans
 > wrote:

 Gerald, it's like the board hangs at power down,
 but I can not be 100% sure. The reason why I
 "assume" it's at power down, is that the heartbeat
 blink stops, but the rest of the LEDs stay on, and
 the ethernet port light still blinks.

 The board I experienced this on last night is an
 Element14 RevC, but I do also have a circuitco A5A
 that exhibits the same thing.

 On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley
 > wrote:

 Is this on power up or is this state happening
 some time later? If it is on power up, then the
 power supply most likely is the issue based on
 the ramp requirements of the PMIC. 

 If the power LED is on, then the PMIC is on and
 ramped up. That is why I asked for the voltages.

 It also could be a boot pin read issue where it
 misreads the boot pins. If that is the case you
 should see that from the serial port.

 Gerald


 On Wed, Dec 2, 2015 at 4:15 PM, William Hermans
 >
 wrote:

 For what it's worth Gerald, this happens
 with nothing connected to the board as
 well. This just happened to me last night
 after issuing a reboot command from the
 command line.

 I remember at some point you all were
 talking about something about the "ramp
 time" of the PMIC or something.

 On Wed, Dec 2, 2015 at 3:11 PM, Gerald
 Coley > wrote:

Re: [beagleboard] ssh keygen on boot

[Josh Datko]

On Wed, 2015-12-02 at 19:41 -0600, Robert Nelson wrote:
> On Wed, Dec 2, 2015 at 7:24 PM, Josh Datko  wrote:

> #Regenerate ssh host keys
> if [ -f /etc/ssh/ssh.regenerate ] ; then
> rm -rf /etc/ssh/ssh_host_* || true
> dpkg-reconfigure openssh-server
> sync
> if [ -s /etc/ssh/ssh_host_ecdsa_key.pub ] ; then
> rm -f /etc/ssh/ssh.regenerate || true
> sync
> fi
> if [ -f /etc/init.d/ssh ] ; then
> /etc/init.d/ssh restart
> fi
> fi
> 
> https://github.com/RobertCNelson/omap-image-builder/blob/master/target/init_scripts/generic-debian.sh#L41-L53
> 

So, it's a bit late, and I'm a bit grogy but I think this is where the
issue might be. It's not good enough just to call regenerate if the
entropy pool isn't properly seeded, otherwise the key generated will be
predictable.

And while the hwrng is enable I don't think it actively contributes to
the kernel entropy pool. I *thought* that is where there is the user
space rngd daemon, but again... tired...

The issue is the creation of /var/lib/systemd/random-seed, which
could/should be done by dd'ing from /dev/hwrng to this file. If software
creates this, then it will be predictable.


> So ignoring the root login over 22 with no password...  or
> nodejs/bonescript/etc..  At least the key is safe. ;)

touche, we are plugging a leak while water is pouring over our heads :)
I still advocate removing the the no password root login thing.



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

Re: [beagleboard] BBB frozen, how to reset?

[John Syne]

I’m using:

http://processors.wiki.ti.com/index.php/AM335x_Linux_Power_Management_User_Guide

Regards,
John




> On Dec 2, 2015, at 9:16 PM, Robert Nelson  wrote:
> 
> On Wed, Dec 2, 2015 at 11:11 PM, John Syne  wrote:
>> I’m not sure why, but
>> 
>> echo mem > /sys/power/state
>> 
>> does not return from suspend when I press any key on the keyboard; however
> 
> If i remember right, in v4.1.x the usarts are not enabled by default
> as a wakeup source anymore.
> 
> so make sure you enable it:
> 
> http://elinux.org/OMAP_Power_Management
> 
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[John Syne]

>From what Gerald said previously in this thread:

"The reset is an input pin read by the processor, not actually a HW power 
reset. If the SW is locked up, this could happen.”

Regards,
John




> On Dec 2, 2015, at 2:55 PM, William Hermans  wrote:
> 
> If the board was in sleep, then why wont the reset button reset ? Passed 
> that, why would the USR cycle( flash on then off ) then nothing ?
> 
> On Wed, Dec 2, 2015 at 3:47 PM, John Syne  > wrote:
> Sounds to me that like BBB has gone into sleep mode and there is no trigger 
> to wake it up. Is there a way to measure the current consumption? 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Dec 2, 2015, at 2:40 PM, William Hermans > > wrote:
>> 
>> One more thing of note. I do not run systemd - Ever. I run SYSV as an init 
>> daemon. I only mention this as I think Robert said something about systemd 
>> lessening this issue.
>> 
>> On Wed, Dec 2, 2015 at 3:36 PM, Gerald Coley > > wrote:
>> Hmm, not sure what is going on. Sounds like the processor has stopped 
>> running the code and halted but it forgot to turn off the lights.
>> 
>> Gerald
>> 
>> On Wed, Dec 2, 2015 at 4:26 PM, William Hermans > > wrote:
>> Gerald, it's like the board hangs at power down, but I can not be 100% sure. 
>> The reason why I "assume" it's at power down, is that the heartbeat blink 
>> stops, but the rest of the LEDs stay on, and the ethernet port light still 
>> blinks.
>> 
>> The board I experienced this on last night is an Element14 RevC, but I do 
>> also have a circuitco A5A that exhibits the same thing.
>> 
>> On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley > > wrote:
>> Is this on power up or is this state happening some time later? If it is on 
>> power up, then the power supply most likely is the issue based on the ramp 
>> requirements of the PMIC. 
>> 
>> If the power LED is on, then the PMIC is on and ramped up. That is why I 
>> asked for the voltages.
>> 
>> It also could be a boot pin read issue where it misreads the boot pins. If 
>> that is the case you should see that from the serial port.
>> 
>> Gerald
>> 
>> 
>> On Wed, Dec 2, 2015 at 4:15 PM, William Hermans > > wrote:
>> For what it's worth Gerald, this happens with nothing connected to the board 
>> as well. This just happened to me last night after issuing a reboot command 
>> from the command line.
>> 
>> I remember at some point you all were talking about something about the 
>> "ramp time" of the PMIC or something.
>> 
>> On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley > > wrote:
>> I would start with your cape design and try and rule that out first.
>> 
>> The reset is an input pin read by the processor, not actually a HW power 
>> reset. If the SW is locked up, this could happen.
>> 
>> If you hold the power button for a 8 seconds or more the board should power 
>> cycle.
>> 
>> When it is in this state, what do the voltages read?
>> 
>> Gerald
>> 
>> 
>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross > > wrote:
>> Once in a blue moon one of my beaglebones will get into a state where it has 
>> power (the power LED is lit), but it is not booted. Normally this would be 
>> fine, just hit the power button to reset. But in this weird state the power 
>> button does nothing. The reset button does nothing.
>> I checked the power and reset button pins on the header, the power was low, 
>> the reset was high.
>> The only way to get the board out of this state was to pull the 5V power.
>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via 
>> power and/or reset buttons on the header if the BB stops sending checkins 
>> over uart. This has been working great, except for the rare case where the 
>> board ends up in this state where the power and reset buttons are not 
>> functioning.
>> Any ideas how the BB could get into this state, and if there's any other way 
>> to force a reboot other than physically pulling the 5v power?
>> Thanks,
>> JR
>> 
>> -- 
>> 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 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
>> 
>> 
>> 
>> -- 
>> Gerald
>>  
>> ger...@beagleboard.org 
>> http://beagleboard.org/ 

Re: [beagleboard] Re: Could not find symbol mcasp0_pins

[Cad Soft]

>
>
> Or just add them in your overlay..
>
>
> https://github.com/beagleboard/linux/blob/3.8/firmware/capes/cape-boneblack-hdmi-00A0.dts#L82-L90
>
>
> Regards, 
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

Hi Robert,

Thank you for taking the time to respond to me. Looking at that example, 
I'm correct in thinking that I should add an additional fragment to my 
overlay that targets am33x-pinmux and include the lines you mentioned?

If that's the case then I think I got it.

Best Regards, 
Jorge Garcia

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

[beagleboard] Re: Could not find symbol mcasp0_pins

[William Hermans]

william@ds64:~/ramfs/bb-kernel/KERNEL/arch/arm/boot/dts$ git grep -inIE --
color=ALWAYS "mcasp0_pins"
. . .
am335x-cape-bbb-exp-c.dtsi:63:  mcasp0_pins: pinmux_mcasp0_pins {
am335x-cape-bbb-exp-c.dtsi:113: pinctrl-0 = <_pins>;
am335x-cape-bbb-exp-r.dtsi:56:  mcasp0_pins: pinmux_mcasp0_pins {
am335x-cape-bbb-exp-r.dtsi:92:  pinctrl-0 = <_pins>;
. . .


So, I have not looked into either of these device tree include files . . . 
However if you include one of these, or copy the mcasp0_pins or if you  
copy this definition section from one of those file, into your device tree 
overlay. The problem should be fixed. Of course, it would behoove you to 
make sure the pinmux / pins are correct for your situation . . .

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

Re: [beagleboard] Re: Could not find symbol mcasp0_pins

[Cad Soft]

On Wednesday, December 2, 2015 at 5:46:55 PM UTC-5, William Hermans wrote:
>
> I was reading on various device tree topics last week, and seem to recall 
> the most well known cause for this complaint from dtc is: You have the 
> wrong device tree compiler. 
>
> So, what is the output of 
>
>
> *dtc --version*?
>
>
> DTC 1.4.0 

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

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

Gerald, I do not have this setup yet, but perhaps in the future may have
the means. Is this something that might be easily checkable via JTAG ? I've
never used JTAG before, and do not have the header in place, but do have a
JTAG emulator.

One thing that has been stopping me from seriously considering this as a
debugging option, is that I do not know if there is an open source ( gcc -
as in GNU compiler collection - Not the compiler its self ) tool. Passed
that, it's all new to me, and probably a steep learning curve initially.

On Wed, Dec 2, 2015 at 4:21 PM, William Hermans  wrote:

> Also, at POR, it would help to understand at which point the USR LEDs( all
> 4 at once ) come on, then go off again.
>
> I'm assuming this is not done in uboot, but I really do not know.
>
> On Wed, Dec 2, 2015 at 4:19 PM, William Hermans  wrote:
>
>> If the software is locked up, the USR LEDs would not cycle as if the
>> system is attempting to restart.
>>
>> On Wed, Dec 2, 2015 at 4:08 PM, John Syne  wrote:
>>
>>> From what Gerald said previously in this thread:
>>>
>>> "The reset is an input pin read by the processor, not actually a HW
>>> power reset. If the SW is locked up, this could happen.”
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Dec 2, 2015, at 2:55 PM, William Hermans  wrote:
>>>
>>> If the board was in sleep, then why wont the reset button reset ? Passed
>>> that, why would the USR cycle( flash on then off ) then nothing ?
>>>
>>> On Wed, Dec 2, 2015 at 3:47 PM, John Syne  wrote:
>>>
 Sounds to me that like BBB has gone into sleep mode and there is no
 trigger to wake it up. Is there a way to measure the current consumption?

 Regards,
 John




 On Dec 2, 2015, at 2:40 PM, William Hermans  wrote:

 One more thing of note. I do not run systemd - Ever. I run SYSV as an
 init daemon. I only mention this as I think Robert said something about
 systemd lessening this issue.

 On Wed, Dec 2, 2015 at 3:36 PM, Gerald Coley 
 wrote:

> Hmm, not sure what is going on. Sounds like the processor has stopped
> running the code and halted but it forgot to turn off the lights.
>
> Gerald
>
> On Wed, Dec 2, 2015 at 4:26 PM, William Hermans 
> wrote:
>
>> Gerald, it's like the board hangs at power down, but I can not be
>> 100% sure. The reason why I "assume" it's at power down, is that the
>> heartbeat blink stops, but the rest of the LEDs stay on, and the ethernet
>> port light still blinks.
>>
>> The board I experienced this on last night is an Element14 RevC, but
>> I do also have a circuitco A5A that exhibits the same thing.
>>
>> On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley 
>> wrote:
>>
>>> Is this on power up or is this state happening some time later? If
>>> it is on power up, then the power supply most likely is the issue based 
>>> on
>>> the ramp requirements of the PMIC.
>>>
>>> If the power LED is on, then the PMIC is on and ramped up. That is
>>> why I asked for the voltages.
>>>
>>> It also could be a boot pin read issue where it misreads the boot
>>> pins. If that is the case you should see that from the serial port.
>>>
>>> Gerald
>>>
>>>
>>> On Wed, Dec 2, 2015 at 4:15 PM, William Hermans 
>>> wrote:
>>>
 For what it's worth Gerald, this happens with nothing connected to
 the board as well. This just happened to me last night after issuing a
 reboot command from the command line.

 I remember at some point you all were talking about something about
 the "ramp time" of the PMIC or something.

 On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley <
 ger...@beagleboard.org> wrote:

> I would start with your cape design and try and rule that out
> first.
>
> The reset is an input pin read by the processor, not actually a HW
> power reset. If the SW is locked up, this could happen.
>
> If you hold the power button for a 8 seconds or more the board
> should power cycle.
>
> When it is in this state, what do the voltages read?
>
> Gerald
>
>
> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross <
> jonr...@nephology.org> wrote:
>
>> Once in a blue moon one of my beaglebones will get into a state
>> where it has power (the power LED is lit), but it is not booted. 
>> Normally
>> this would be fine, just hit the power button to reset. But in this 
>> weird
>> state the power button does nothing. The reset button does nothing.
>> I checked the 

[beagleboard] Re: Could not find symbol mcasp0_pins

[Cad Soft]

On Wednesday, December 2, 2015 at 6:09:51 PM UTC-5, William Hermans wrote:
>
> william@ds64:~/ramfs/bb-kernel/KERNEL/arch/arm/boot/dts$ git grep -inIE --
> color=ALWAYS "mcasp0_pins"
> . . .
> am335x-cape-bbb-exp-c.dtsi:63:  mcasp0_pins: pinmux_mcasp0_pins {
> am335x-cape-bbb-exp-c.dtsi:113: pinctrl-0 = <_pins>;
> am335x-cape-bbb-exp-r.dtsi:56:  mcasp0_pins: pinmux_mcasp0_pins {
> am335x-cape-bbb-exp-r.dtsi:92:  pinctrl-0 = <_pins>;
> . . .
>
>
> So, I have not looked into either of these device tree include files . . . 
> However if you include one of these, or copy the mcasp0_pins or if you  
> copy this definition section from one of those file, into your device tree 
> overlay. The problem should be fixed. Of course, it would behoove you to 
> make sure the pinmux / pins are correct for your situation . . .
>

Hi William,

Thank you for taking the time to respond, I really appreciate it. My 
endgoal here is to re-enable the default HDMI audio because the LCD cape 
I'm using disables it. That's what got me into this whole mess in the first 
place.

These files that you are referencing are not on the BBB itself, correct? 
Would it be as simple as adding an include statement to my overlay? I would 
obviously confirm that the pins are muxed properly.

Thanks again for your help.

Best Regards,
Jorge Garcia

>  
>

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

Re: [beagleboard] Re: Could not find symbol mcasp0_pins

[William Hermans]

Ok, I jumped the gun on that answer. I assumed that you had that alias in
place, but apparently you do not. That alias is not included in the stock
board device tree file.

On Wed, Dec 2, 2015 at 4:22 PM, Cad Soft  wrote:

>
>
> On Wednesday, December 2, 2015 at 5:46:55 PM UTC-5, William Hermans wrote:
>>
>> I was reading on various device tree topics last week, and seem to recall
>> the most well known cause for this complaint from dtc is: You have the
>> wrong device tree compiler.
>>
>> So, what is the output of
>>
>>
>> *dtc --version*?
>>
>>
>> DTC 1.4.0
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[Jonathan Ross]

I didn't test the 8 second holddown of the power button but I doubt it 
would help, and unfortunately it's not a reproducible issue. I'll have to 
wait for it to happen again.
>From my notes, I was seeing zero volts on power, 5V on reset.
The zero volts on power was very weird. From the KL16 I'm "toggling" my own 
effective power button that is a transistor between the power pin on the 
header and ground. The KL16 pin was not driven high (I checked), so I don't 
think it was the transistor on the cape that was pulling pwr to ground on 
the BBB. And the physical button wasn't pressed in. It was as if the pullup 
at the PMIC wasn't active, yet the power LED was on. Is that possible?
Wish I hadn't pulled the 5V power to reset, then I could do more testing.

On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
>
> I would start with your cape design and try and rule that out first.
>
> The reset is an input pin read by the processor, not actually a HW power 
> reset. If the SW is locked up, this could happen.
>
> If you hold the power button for a 8 seconds or more the board should 
> power cycle.
>
> When it is in this state, what do the voltages read?
>
> Gerald
>
>
> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross  > wrote:
>
>> Once in a blue moon one of my beaglebones will get into a state where it 
>> has power (the power LED is lit), but it is not booted. Normally this would 
>> be fine, just hit the power button to reset. But in this weird state the 
>> power button does nothing. The reset button does nothing.
>> I checked the power and reset button pins on the header, the power was 
>> low, the reset was high.
>> The only way to get the board out of this state was to pull the 5V power.
>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via 
>> power and/or reset buttons on the header if the BB stops sending checkins 
>> over uart. This has been working great, except for the rare case where the 
>> board ends up in this state where the power and reset buttons are not 
>> functioning.
>> Any ideas how the BB could get into this state, and if there's any other 
>> way to force a reboot other than physically pulling the 5v power?
>> Thanks,
>> JR
>>
>> -- 
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
>

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

Re: [beagleboard] BBB frozen, how to reset?

[Jonathan Ross]

In my case linux is not booted at this time(none of the 4 user leds lit), 
so a script would not help. This is why I'm doing an external watchdog 
circuit.

On Wednesday, December 2, 2015 at 3:41:32 PM UTC-8, William Hermans wrote:
>
> *I didn't test the 8 second holddown of the power button but I doubt it 
>> would help, and unfortunately it's not a reproducible issue. I'll have to 
>> wait for it to happen again.*
>>
>
> I know what you mean, e.g. this happens so erratically, it's hard to tell 
> when it'll happen next. But, I could possibly whip up a script, and a means 
> to automate resetting the system. Really, you could probably do the same as 
> well. Just put "sudo reboot" in a bash script, and run it through rc.d
>
> With that said, I'm not 100% sure this is good for the board.
>
>
>
> On Wed, Dec 2, 2015 at 4:31 PM, Jonathan Ross  > wrote:
>
>> I didn't test the 8 second holddown of the power button but I doubt it 
>> would help, and unfortunately it's not a reproducible issue. I'll have to 
>> wait for it to happen again.
>> From my notes, I was seeing zero volts on power, 5V on reset.
>> The zero volts on power was very weird. From the KL16 I'm "toggling" my 
>> own effective power button that is a transistor between the power pin on 
>> the header and ground. The KL16 pin was not driven high (I checked), so I 
>> don't think it was the transistor on the cape that was pulling pwr to 
>> ground on the BBB. And the physical button wasn't pressed in. It was as if 
>> the pullup at the PMIC wasn't active, yet the power LED was on. Is that 
>> possible?
>> Wish I hadn't pulled the 5V power to reset, then I could do more testing.
>>
>> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
>>>
>>> I would start with your cape design and try and rule that out first.
>>>
>>> The reset is an input pin read by the processor, not actually a HW power 
>>> reset. If the SW is locked up, this could happen.
>>>
>>> If you hold the power button for a 8 seconds or more the board should 
>>> power cycle.
>>>
>>> When it is in this state, what do the voltages read?
>>>
>>> Gerald
>>>
>>>
>>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross  
>>> wrote:
>>>
 Once in a blue moon one of my beaglebones will get into a state where 
 it has power (the power LED is lit), but it is not booted. Normally this 
 would be fine, just hit the power button to reset. But in this weird state 
 the power button does nothing. The reset button does nothing.
 I checked the power and reset button pins on the header, the power was 
 low, the reset was high.
 The only way to get the board out of this state was to pull the 5V 
 power.
 I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it 
 via power and/or reset buttons on the header if the BB stops sending 
 checkins over uart. This has been working great, except for the rare case 
 where the board ends up in this state where the power and reset buttons 
 are 
 not functioning.
 Any ideas how the BB could get into this state, and if there's any 
 other way to force a reboot other than physically pulling the 5v power?
 Thanks,
 JR

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

>>>
>>>
>>>
>>> -- 
>>> Gerald
>>>  
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>>
>> -- 
>> 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 .
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

>
>
> *In my case linux is not booted at this time(none of the 4 user leds lit),
> so a script would not help. This is why I'm doing an external watchdog
> circuit.*


Exactly. So here is what I mean. The USR LEDs cycle on for me *if* and only
*if* I press the power button on the board. After that, nothing changes.
Otherwise the LEDs are off, well the power LED is on, and the ethernet port
lights are on too, and potentially blinking.

The script, would just be to reboot the board in an attempt to put the
board back into the bad state. For troubleshooting . . .

On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross  wrote:

> In my case linux is not booted at this time(none of the 4 user leds lit),
> so a script would not help. This is why I'm doing an external watchdog
> circuit.
>
> On Wednesday, December 2, 2015 at 3:41:32 PM UTC-8, William Hermans wrote:
>>
>> *I didn't test the 8 second holddown of the power button but I doubt it
>>> would help, and unfortunately it's not a reproducible issue. I'll have to
>>> wait for it to happen again.*
>>>
>>
>> I know what you mean, e.g. this happens so erratically, it's hard to tell
>> when it'll happen next. But, I could possibly whip up a script, and a means
>> to automate resetting the system. Really, you could probably do the same as
>> well. Just put "sudo reboot" in a bash script, and run it through rc.d
>>
>> With that said, I'm not 100% sure this is good for the board.
>>
>>
>>
>> On Wed, Dec 2, 2015 at 4:31 PM, Jonathan Ross 
>> wrote:
>>
>>> I didn't test the 8 second holddown of the power button but I doubt it
>>> would help, and unfortunately it's not a reproducible issue. I'll have to
>>> wait for it to happen again.
>>> From my notes, I was seeing zero volts on power, 5V on reset.
>>> The zero volts on power was very weird. From the KL16 I'm "toggling" my
>>> own effective power button that is a transistor between the power pin on
>>> the header and ground. The KL16 pin was not driven high (I checked), so I
>>> don't think it was the transistor on the cape that was pulling pwr to
>>> ground on the BBB. And the physical button wasn't pressed in. It was as if
>>> the pullup at the PMIC wasn't active, yet the power LED was on. Is that
>>> possible?
>>> Wish I hadn't pulled the 5V power to reset, then I could do more testing.
>>>
>>> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:

 I would start with your cape design and try and rule that out first.

 The reset is an input pin read by the processor, not actually a HW
 power reset. If the SW is locked up, this could happen.

 If you hold the power button for a 8 seconds or more the board should
 power cycle.

 When it is in this state, what do the voltages read?

 Gerald


 On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
 wrote:

> Once in a blue moon one of my beaglebones will get into a state where
> it has power (the power LED is lit), but it is not booted. Normally this
> would be fine, just hit the power button to reset. But in this weird state
> the power button does nothing. The reset button does nothing.
> I checked the power and reset button pins on the header, the power was
> low, the reset was high.
> The only way to get the board out of this state was to pull the 5V
> power.
> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it
> via power and/or reset buttons on the header if the BB stops sending
> checkins over uart. This has been working great, except for the rare case
> where the board ends up in this state where the power and reset buttons 
> are
> not functioning.
> Any ideas how the BB could get into this state, and if there's any
> other way to force a reboot other than physically pulling the 5v power?
> Thanks,
> JR
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Gerald

 ger...@beagleboard.org
 http://beagleboard.org/

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

Re: [beagleboard] BBB frozen, how to reset?

[Jonathan Ross]

Got you on the script front. My issue is slightly different, when I get 
into my magic state, pressing the power button does nothing.

On Wednesday, December 2, 2015 at 3:51:42 PM UTC-8, William Hermans wrote:
>
>
>> *In my case linux is not booted at this time(none of the 4 user leds 
>> lit), so a script would not help. This is why I'm doing an external 
>> watchdog circuit.*
>
>
> Exactly. So here is what I mean. The USR LEDs cycle on for me *if* and 
> only *if* I press the power button on the board. After that, nothing 
> changes. Otherwise the LEDs are off, well the power LED is on, and the 
> ethernet port lights are on too, and potentially blinking.
>
> The script, would just be to reboot the board in an attempt to put the 
> board back into the bad state. For troubleshooting . . .
>
> On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross  > wrote:
>
>> In my case linux is not booted at this time(none of the 4 user leds lit), 
>> so a script would not help. This is why I'm doing an external watchdog 
>> circuit.
>>
>> On Wednesday, December 2, 2015 at 3:41:32 PM UTC-8, William Hermans wrote:
>>>
>>> *I didn't test the 8 second holddown of the power button but I doubt it 
 would help, and unfortunately it's not a reproducible issue. I'll have to 
 wait for it to happen again.*

>>>
>>> I know what you mean, e.g. this happens so erratically, it's hard to 
>>> tell when it'll happen next. But, I could possibly whip up a script, and a 
>>> means to automate resetting the system. Really, you could probably do the 
>>> same as well. Just put "sudo reboot" in a bash script, and run it through 
>>> rc.d
>>>
>>> With that said, I'm not 100% sure this is good for the board.
>>>
>>>
>>>
>>> On Wed, Dec 2, 2015 at 4:31 PM, Jonathan Ross  
>>> wrote:
>>>
 I didn't test the 8 second holddown of the power button but I doubt it 
 would help, and unfortunately it's not a reproducible issue. I'll have to 
 wait for it to happen again.
 From my notes, I was seeing zero volts on power, 5V on reset.
 The zero volts on power was very weird. From the KL16 I'm "toggling" my 
 own effective power button that is a transistor between the power pin on 
 the header and ground. The KL16 pin was not driven high (I checked), so I 
 don't think it was the transistor on the cape that was pulling pwr to 
 ground on the BBB. And the physical button wasn't pressed in. It was as if 
 the pullup at the PMIC wasn't active, yet the power LED was on. Is that 
 possible?
 Wish I hadn't pulled the 5V power to reset, then I could do more 
 testing.

 On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
>
> I would start with your cape design and try and rule that out first.
>
> The reset is an input pin read by the processor, not actually a HW 
> power reset. If the SW is locked up, this could happen.
>
> If you hold the power button for a 8 seconds or more the board should 
> power cycle.
>
> When it is in this state, what do the voltages read?
>
> Gerald
>
>
> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross  
> wrote:
>
>> Once in a blue moon one of my beaglebones will get into a state where 
>> it has power (the power LED is lit), but it is not booted. Normally this 
>> would be fine, just hit the power button to reset. But in this weird 
>> state 
>> the power button does nothing. The reset button does nothing.
>> I checked the power and reset button pins on the header, the power 
>> was low, the reset was high.
>> The only way to get the board out of this state was to pull the 5V 
>> power.
>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it 
>> via power and/or reset buttons on the header if the BB stops sending 
>> checkins over uart. This has been working great, except for the rare 
>> case 
>> where the board ends up in this state where the power and reset buttons 
>> are 
>> not functioning.
>> Any ideas how the BB could get into this state, and if there's any 
>> other way to force a reboot other than physically pulling the 5v power?
>> Thanks,
>> JR
>>
>> -- 
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org
> http://beagleboard.org/
>
 -- 
 For more options, visit http://beagleboard.org/discuss
 --- 
 You received this message because you are subscribed to the Google 
 Groups 

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

Also, at POR, it would help to understand at which point the USR LEDs( all
4 at once ) come on, then go off again.

I'm assuming this is not done in uboot, but I really do not know.

On Wed, Dec 2, 2015 at 4:19 PM, William Hermans  wrote:

> If the software is locked up, the USR LEDs would not cycle as if the
> system is attempting to restart.
>
> On Wed, Dec 2, 2015 at 4:08 PM, John Syne  wrote:
>
>> From what Gerald said previously in this thread:
>>
>> "The reset is an input pin read by the processor, not actually a HW power
>> reset. If the SW is locked up, this could happen.”
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Dec 2, 2015, at 2:55 PM, William Hermans  wrote:
>>
>> If the board was in sleep, then why wont the reset button reset ? Passed
>> that, why would the USR cycle( flash on then off ) then nothing ?
>>
>> On Wed, Dec 2, 2015 at 3:47 PM, John Syne  wrote:
>>
>>> Sounds to me that like BBB has gone into sleep mode and there is no
>>> trigger to wake it up. Is there a way to measure the current consumption?
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Dec 2, 2015, at 2:40 PM, William Hermans  wrote:
>>>
>>> One more thing of note. I do not run systemd - Ever. I run SYSV as an
>>> init daemon. I only mention this as I think Robert said something about
>>> systemd lessening this issue.
>>>
>>> On Wed, Dec 2, 2015 at 3:36 PM, Gerald Coley 
>>> wrote:
>>>
 Hmm, not sure what is going on. Sounds like the processor has stopped
 running the code and halted but it forgot to turn off the lights.

 Gerald

 On Wed, Dec 2, 2015 at 4:26 PM, William Hermans 
 wrote:

> Gerald, it's like the board hangs at power down, but I can not be 100%
> sure. The reason why I "assume" it's at power down, is that the heartbeat
> blink stops, but the rest of the LEDs stay on, and the ethernet port light
> still blinks.
>
> The board I experienced this on last night is an Element14 RevC, but I
> do also have a circuitco A5A that exhibits the same thing.
>
> On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley 
> wrote:
>
>> Is this on power up or is this state happening some time later? If it
>> is on power up, then the power supply most likely is the issue based on 
>> the
>> ramp requirements of the PMIC.
>>
>> If the power LED is on, then the PMIC is on and ramped up. That is
>> why I asked for the voltages.
>>
>> It also could be a boot pin read issue where it misreads the boot
>> pins. If that is the case you should see that from the serial port.
>>
>> Gerald
>>
>>
>> On Wed, Dec 2, 2015 at 4:15 PM, William Hermans 
>> wrote:
>>
>>> For what it's worth Gerald, this happens with nothing connected to
>>> the board as well. This just happened to me last night after issuing a
>>> reboot command from the command line.
>>>
>>> I remember at some point you all were talking about something about
>>> the "ramp time" of the PMIC or something.
>>>
>>> On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley >> > wrote:
>>>
 I would start with your cape design and try and rule that out first.

 The reset is an input pin read by the processor, not actually a HW
 power reset. If the SW is locked up, this could happen.

 If you hold the power button for a 8 seconds or more the board
 should power cycle.

 When it is in this state, what do the voltages read?

 Gerald


 On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross <
 jonr...@nephology.org> wrote:

> Once in a blue moon one of my beaglebones will get into a state
> where it has power (the power LED is lit), but it is not booted. 
> Normally
> this would be fine, just hit the power button to reset. But in this 
> weird
> state the power button does nothing. The reset button does nothing.
> I checked the power and reset button pins on the header, the power
> was low, the reset was high.
> The only way to get the board out of this state was to pull the 5V
> power.
> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot
> it via power and/or reset buttons on the header if the BB stops 
> sending
> checkins over uart. This has been working great, except for the rare 
> case
> where the board ends up in this state where the power and reset 
> buttons are
> not functioning.
> Any ideas how the BB could get into this state, and if there's any
> other way to force a reboot other than physically pulling the 5v 
> power?

Re: [beagleboard] Re: Could not find symbol mcasp0_pins

[William Hermans]

>
> *These files that you are referencing are not on the BBB itself, correct?
> Would it be as simple as adding an include statement to my overlay? I would
> obviously confirm that the pins are muxed properly.*
>

It could be yes, but you'll have to double check everything. You're very
likely to have conflicts between overlays with stock settings.

DO also keep in mind that I'm not an expert with device tree files, and am
still learning myself. But this sort of thing is what I've learned in the
last couple weeks . . .

So, *.dtsi files, are *d*evice *t*ree *s*ource *i*nclude files . . .

On Wed, Dec 2, 2015 at 4:29 PM, William Hermans  wrote:

> Ok, I jumped the gun on that answer. I assumed that you had that alias in
> place, but apparently you do not. That alias is not included in the stock
> board device tree file.
>
> On Wed, Dec 2, 2015 at 4:22 PM, Cad Soft  wrote:
>
>>
>>
>> On Wednesday, December 2, 2015 at 5:46:55 PM UTC-5, William Hermans wrote:
>>>
>>> I was reading on various device tree topics last week, and seem to
>>> recall the most well known cause for this complaint from dtc is: You have
>>> the wrong device tree compiler.
>>>
>>> So, what is the output of
>>>
>>>
>>> *dtc --version*?
>>>
>>>
>>> DTC 1.4.0
>>
>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

>
> *I didn't test the 8 second holddown of the power button but I doubt it
> would help, and unfortunately it's not a reproducible issue. I'll have to
> wait for it to happen again.*
>

I know what you mean, e.g. this happens so erratically, it's hard to tell
when it'll happen next. But, I could possibly whip up a script, and a means
to automate resetting the system. Really, you could probably do the same as
well. Just put "sudo reboot" in a bash script, and run it through rc.d

With that said, I'm not 100% sure this is good for the board.



On Wed, Dec 2, 2015 at 4:31 PM, Jonathan Ross  wrote:

> I didn't test the 8 second holddown of the power button but I doubt it
> would help, and unfortunately it's not a reproducible issue. I'll have to
> wait for it to happen again.
> From my notes, I was seeing zero volts on power, 5V on reset.
> The zero volts on power was very weird. From the KL16 I'm "toggling" my
> own effective power button that is a transistor between the power pin on
> the header and ground. The KL16 pin was not driven high (I checked), so I
> don't think it was the transistor on the cape that was pulling pwr to
> ground on the BBB. And the physical button wasn't pressed in. It was as if
> the pullup at the PMIC wasn't active, yet the power LED was on. Is that
> possible?
> Wish I hadn't pulled the 5V power to reset, then I could do more testing.
>
> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
>>
>> I would start with your cape design and try and rule that out first.
>>
>> The reset is an input pin read by the processor, not actually a HW power
>> reset. If the SW is locked up, this could happen.
>>
>> If you hold the power button for a 8 seconds or more the board should
>> power cycle.
>>
>> When it is in this state, what do the voltages read?
>>
>> Gerald
>>
>>
>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
>> wrote:
>>
>>> Once in a blue moon one of my beaglebones will get into a state where it
>>> has power (the power LED is lit), but it is not booted. Normally this would
>>> be fine, just hit the power button to reset. But in this weird state the
>>> power button does nothing. The reset button does nothing.
>>> I checked the power and reset button pins on the header, the power was
>>> low, the reset was high.
>>> The only way to get the board out of this state was to pull the 5V power.
>>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via
>>> power and/or reset buttons on the header if the BB stops sending checkins
>>> over uart. This has been working great, except for the rare case where the
>>> board ends up in this state where the power and reset buttons are not
>>> functioning.
>>> Any ideas how the BB could get into this state, and if there's any other
>>> way to force a reboot other than physically pulling the 5v power?
>>> Thanks,
>>> JR
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@beagleboard.org
>> http://beagleboard.org/
>>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

And, of course, in order to remove that the sdcard would need to be put
into aother linux system to remove that file heh !

On Wed, Dec 2, 2015 at 4:41 PM, William Hermans  wrote:

> *I didn't test the 8 second holddown of the power button but I doubt it
>> would help, and unfortunately it's not a reproducible issue. I'll have to
>> wait for it to happen again.*
>>
>
> I know what you mean, e.g. this happens so erratically, it's hard to tell
> when it'll happen next. But, I could possibly whip up a script, and a means
> to automate resetting the system. Really, you could probably do the same as
> well. Just put "sudo reboot" in a bash script, and run it through rc.d
>
> With that said, I'm not 100% sure this is good for the board.
>
>
>
> On Wed, Dec 2, 2015 at 4:31 PM, Jonathan Ross 
> wrote:
>
>> I didn't test the 8 second holddown of the power button but I doubt it
>> would help, and unfortunately it's not a reproducible issue. I'll have to
>> wait for it to happen again.
>> From my notes, I was seeing zero volts on power, 5V on reset.
>> The zero volts on power was very weird. From the KL16 I'm "toggling" my
>> own effective power button that is a transistor between the power pin on
>> the header and ground. The KL16 pin was not driven high (I checked), so I
>> don't think it was the transistor on the cape that was pulling pwr to
>> ground on the BBB. And the physical button wasn't pressed in. It was as if
>> the pullup at the PMIC wasn't active, yet the power LED was on. Is that
>> possible?
>> Wish I hadn't pulled the 5V power to reset, then I could do more testing.
>>
>> On Wednesday, December 2, 2015 at 2:11:58 PM UTC-8, Gerald wrote:
>>>
>>> I would start with your cape design and try and rule that out first.
>>>
>>> The reset is an input pin read by the processor, not actually a HW power
>>> reset. If the SW is locked up, this could happen.
>>>
>>> If you hold the power button for a 8 seconds or more the board should
>>> power cycle.
>>>
>>> When it is in this state, what do the voltages read?
>>>
>>> Gerald
>>>
>>>
>>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
>>> wrote:
>>>
 Once in a blue moon one of my beaglebones will get into a state where
 it has power (the power LED is lit), but it is not booted. Normally this
 would be fine, just hit the power button to reset. But in this weird state
 the power button does nothing. The reset button does nothing.
 I checked the power and reset button pins on the header, the power was
 low, the reset was high.
 The only way to get the board out of this state was to pull the 5V
 power.
 I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it
 via power and/or reset buttons on the header if the BB stops sending
 checkins over uart. This has been working great, except for the rare case
 where the board ends up in this state where the power and reset buttons are
 not functioning.
 Any ideas how the BB could get into this state, and if there's any
 other way to force a reboot other than physically pulling the 5v power?
 Thanks,
 JR

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

>>>
>>>
>>>
>>> --
>>> Gerald
>>>
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>>
>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Could not find symbol mcasp0_pins

[Robert Nelson]

On Wed, Dec 2, 2015 at 5:28 PM, Cad Soft  wrote:

>
>
> On Wednesday, December 2, 2015 at 6:09:51 PM UTC-5, William Hermans wrote:
>>
>> william@ds64:~/ramfs/bb-kernel/KERNEL/arch/arm/boot/dts$ git grep -inIE
>> --color=ALWAYS "mcasp0_pins"
>> . . .
>> am335x-cape-bbb-exp-c.dtsi:63:  mcasp0_pins: pinmux_mcasp0_pins {
>> am335x-cape-bbb-exp-c.dtsi:113: pinctrl-0 = <_pins>;
>> am335x-cape-bbb-exp-r.dtsi:56:  mcasp0_pins: pinmux_mcasp0_pins {
>> am335x-cape-bbb-exp-r.dtsi:92:  pinctrl-0 = <_pins>;
>> . . .
>>
>>
>> So, I have not looked into either of these device tree include files . .
>> . However if you include one of these, or copy the mcasp0_pins or if
>> you  copy this definition section from one of those file, into your device
>> tree overlay. The problem should be fixed. Of course, it would behoove you
>> to make sure the pinmux / pins are correct for your situation . . .
>>
>
> Hi William,
>
> Thank you for taking the time to respond, I really appreciate it. My
> endgoal here is to re-enable the default HDMI audio because the LCD cape
> I'm using disables it. That's what got me into this whole mess in the first
> place.
>
> These files that you are referencing are not on the BBB itself, correct?
> Would it be as simple as adding an include statement to my overlay? I would
> obviously confirm that the pins are muxed properly.
>
>
Or just add them in your overlay..

https://github.com/beagleboard/linux/blob/3.8/firmware/capes/cape-boneblack-hdmi-00A0.dts#L82-L90


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

Re: [beagleboard] Re: Could not find symbol mcasp0_pins

[Robert Nelson]

> Hi Robert,
>
> Thank you for taking the time to respond to me. Looking at that example, I'm
> correct in thinking that I should add an additional fragment to my overlay
> that targets am33x-pinmux and include the lines you mentioned?
>
> If that's the case then I think I got it.

Yeap, you can target am33x-pinmux and add all the aditional pinmux you need.

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

Re: [beagleboard] why eSATA in X-15?

[Taceant Omnes]

On 1 December 2015 at 21:43, Robert Nelson  wrote:
> On Tue, Dec 1, 2015 at 3:41 PM, William Hermans  wrote:
>> Or, how about using an eSATA enclosure ? they're not that expensive . .
>> .http://www.amazon.com/Anker%C2%AE-Aluminum-External-Enclosure-12-5mm/dp/B005B5G4S6
>>
>> eSATA enclosures also usually double as an USB enclosure as well. While on
>> the subject. eSATA is usually more performant when compared to USB, but that
>> can depend on the host controller as well.
>
> Or these:
>
> http://www.amazon.com/gp/product/B002MKKTWA
>
> pair up with an ssd, perfect for the x15..

Hi Robert,

Is the port on the X-15 eSATA or eSATAp [1]? The picture [2] says
eSATA, though since Gerald said USB 2 is also supported I guess it is
eSATAp.

If it is indeed an eSATAp port then the cable you suggested is the
best solution in my view because it provides power.
The follow-up question is how much power can the X-15 provide at 5 V
and at 12 V.

[1] https://en.wikipedia.org/wiki/ESATAp
[2] http://beagleboard.org/newsletter/2015-11/

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

[beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black

[rudydeloreantide]

Had a similar problem following the same tutorial, used Emile's answer, the 
DT overlay loads every time.
To check:
cat /sys/devices/bone_capemgr.*/slots

root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI0-01



On Wednesday, June 17, 2015 at 12:39:14 AM UTC+10, Brendan Merna wrote:
>
> I'm trying to  enable SPI on boot up on my Beaglebone Black. I followed 
> the wiki link below under the title 
> SPI1 D1 Output and D0 Input
>
> I created the .dts file and compiled it. I then moved it to /lib/firmware/ 
> and then enabled the device overlay tree. Finally, I changed the uenv.txt 
> file by adding the text shown and I removed a pound sign at the end of the 
> document. I did this because the boot command to enable the SPI wasn't 
> working and I thought it wasn't reading the last command because of the 
> pound sign. Unfortunately, now that I removed it, I reset my Beaglebone 
> Black and it gets stuck in a state with the Power LED and USR0,USR1, USR2, 
> and USR3 all stuck on. No blinking and my computer doesn't recognize its 
> there. I'm powering through the USB port and have tried resetting and 
> powering down numerous times. This same state keeps coming up. Can anyone 
> help?
>
> Tutorial Link:
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
>

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

[beagleboard] Beaglebone black: problem with edt-ft5x06: no platform data

[flantschi]

Hi all. I have some problems when I try to use the touchscreen driver 
edt-ft5x06 with a device tree overlay on my beaglebone black.
I work with the 3.8.13 kernel and a Debian distribution. This is the device 
tree overlay I am using:

/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "BB-BONE-TOUCH";
version = "00A0";

exclusive-use =
/* the pin header uses */
"P9.17",/* i2c1_scl */
"P9.18",/* i2c1_sda */
"P9.21", /*wake up from host am33  to slave ft5x"
"P9.25", /*interrupt, def state mcasp0_ahclkx, 
change to input pin gpio3_21*/

/* the hardware ip uses */
"i2c1";

fragment@0 {
target = <_pinmux>;
__overlay__
   {
  bb_i2c1_pins: pinmux_bb_i2c1_pins
   {
pinctrl-single,pins = <
0x15c 0x74  /* i2c1_scl */
0x158 0x74  /* i2c1_sda*/
>;
   } ;

  edt_ft5x06_pins: pinmux_edt_ft5x06_pins
  {
   pinctrl-single,pins = <
   0x08C 0x37 /* pin interrupt P8.18 (GPIO2_1) mode7 as 
gpio, enable input, enable input pullup*/
   0x044 0x17 /* wake up pin control to slave from 
host: pullup,mode7 p9.23,gpio1_17 */
   >;
  };
 };
};

fragment@1 {
  target = <>;   /* i2c1 is numbered correctly */
__overlay__
 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_i2c1_pins>;
clock-frequency = <40>;
#address-cells = <1>;
#size-cells = <0>;

edt-ft5x06@38
{
status =  "okay";
compatible = "edt,edt-ft5x06","edt,edt-ft5206";
pinctrl-names="default";
pinctrl-0=<_ft5x06_pins>;
reg = <0x38>;
interrupt-parent = <>;
interrupts = <1 1>;
wake-gpios = < 17 0>; //3rd para:0 - active 
hig, 1-active low
reset-gpios = < 17 1>;
touchscreen-size-x = <800>;
touchscreen-size-y = <480>;
};

 };
  };
};

When I load it into the capemanager I get the following error:

[   11.024611] edt_ft5x06 1-0038: no platform data?


I'm quite lost here. Can anyone help?

Thank you

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

Re: [beagleboard] why eSATA in X-15?

[Gerald Coley]

Only 5V is supplied. There is no 12V. Feel free to look at the schematic.

http://elinux.org/Beagleboard:BeagleBoard-X15


Gerald

On Wed, Dec 2, 2015 at 5:35 AM, Taceant Omnes  wrote:

> On 1 December 2015 at 21:43, Robert Nelson 
> wrote:
> > On Tue, Dec 1, 2015 at 3:41 PM, William Hermans 
> wrote:
> >> Or, how about using an eSATA enclosure ? they're not that expensive . .
> >> .
> http://www.amazon.com/Anker%C2%AE-Aluminum-External-Enclosure-12-5mm/dp/B005B5G4S6
> >>
> >> eSATA enclosures also usually double as an USB enclosure as well. While
> on
> >> the subject. eSATA is usually more performant when compared to USB, but
> that
> >> can depend on the host controller as well.
> >
> > Or these:
> >
> > http://www.amazon.com/gp/product/B002MKKTWA
> >
> > pair up with an ssd, perfect for the x15..
>
> Hi Robert,
>
> Is the port on the X-15 eSATA or eSATAp [1]? The picture [2] says
> eSATA, though since Gerald said USB 2 is also supported I guess it is
> eSATAp.
>
> If it is indeed an eSATAp port then the cable you suggested is the
> best solution in my view because it provides power.
> The follow-up question is how much power can the X-15 provide at 5 V
> and at 12 V.
>
> [1] https://en.wikipedia.org/wiki/ESATAp
> [2] http://beagleboard.org/newsletter/2015-11/
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/

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

Re: [beagleboard] why eSATA in X-15?

[Taceant Omnes]

On 2 December 2015 at 12:40, Gerald Coley  wrote:
> Only 5V is supplied. There is no 12V. Feel free to look at the schematic.
>
> http://elinux.org/Beagleboard:BeagleBoard-X15

Thanks.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

press, and hold the reset button, remove power. A few seconds later,
reapply power.

On Wed, Dec 2, 2015 at 2:54 PM, Jonathan Ross  wrote:

> Once in a blue moon one of my beaglebones will get into a state where it
> has power (the power LED is lit), but it is not booted. Normally this would
> be fine, just hit the power button to reset. But in this weird state the
> power button does nothing. The reset button does nothing.
> I checked the power and reset button pins on the header, the power was
> low, the reset was high.
> The only way to get the board out of this state was to pull the 5V power.
> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via
> power and/or reset buttons on the header if the BB stops sending checkins
> over uart. This has been working great, except for the rare case where the
> board ends up in this state where the power and reset buttons are not
> functioning.
> Any ideas how the BB could get into this state, and if there's any other
> way to force a reboot other than physically pulling the 5v power?
> Thanks,
> JR
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

For what it's worth Gerald, this happens with nothing connected to the
board as well. This just happened to me last night after issuing a reboot
command from the command line.

I remember at some point you all were talking about something about the
"ramp time" of the PMIC or something.

On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley  wrote:

> I would start with your cape design and try and rule that out first.
>
> The reset is an input pin read by the processor, not actually a HW power
> reset. If the SW is locked up, this could happen.
>
> If you hold the power button for a 8 seconds or more the board should
> power cycle.
>
> When it is in this state, what do the voltages read?
>
> Gerald
>
>
> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
> wrote:
>
>> Once in a blue moon one of my beaglebones will get into a state where it
>> has power (the power LED is lit), but it is not booted. Normally this would
>> be fine, just hit the power button to reset. But in this weird state the
>> power button does nothing. The reset button does nothing.
>> I checked the power and reset button pins on the header, the power was
>> low, the reset was high.
>> The only way to get the board out of this state was to pull the 5V power.
>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it via
>> power and/or reset buttons on the header if the BB stops sending checkins
>> over uart. This has been working great, except for the rare case where the
>> board ends up in this state where the power and reset buttons are not
>> functioning.
>> Any ideas how the BB could get into this state, and if there's any other
>> way to force a reboot other than physically pulling the 5v power?
>> Thanks,
>> JR
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB frozen, how to reset?

[William Hermans]

If the board was in sleep, then why wont the reset button reset ? Passed
that, why would the USR cycle( flash on then off ) then nothing ?

On Wed, Dec 2, 2015 at 3:47 PM, John Syne  wrote:

> Sounds to me that like BBB has gone into sleep mode and there is no
> trigger to wake it up. Is there a way to measure the current consumption?
>
> Regards,
> John
>
>
>
>
> On Dec 2, 2015, at 2:40 PM, William Hermans  wrote:
>
> One more thing of note. I do not run systemd - Ever. I run SYSV as an init
> daemon. I only mention this as I think Robert said something about systemd
> lessening this issue.
>
> On Wed, Dec 2, 2015 at 3:36 PM, Gerald Coley 
> wrote:
>
>> Hmm, not sure what is going on. Sounds like the processor has stopped
>> running the code and halted but it forgot to turn off the lights.
>>
>> Gerald
>>
>> On Wed, Dec 2, 2015 at 4:26 PM, William Hermans 
>> wrote:
>>
>>> Gerald, it's like the board hangs at power down, but I can not be 100%
>>> sure. The reason why I "assume" it's at power down, is that the heartbeat
>>> blink stops, but the rest of the LEDs stay on, and the ethernet port light
>>> still blinks.
>>>
>>> The board I experienced this on last night is an Element14 RevC, but I
>>> do also have a circuitco A5A that exhibits the same thing.
>>>
>>> On Wed, Dec 2, 2015 at 3:22 PM, Gerald Coley 
>>> wrote:
>>>
 Is this on power up or is this state happening some time later? If it
 is on power up, then the power supply most likely is the issue based on the
 ramp requirements of the PMIC.

 If the power LED is on, then the PMIC is on and ramped up. That is why
 I asked for the voltages.

 It also could be a boot pin read issue where it misreads the boot pins.
 If that is the case you should see that from the serial port.

 Gerald


 On Wed, Dec 2, 2015 at 4:15 PM, William Hermans 
 wrote:

> For what it's worth Gerald, this happens with nothing connected to the
> board as well. This just happened to me last night after issuing a reboot
> command from the command line.
>
> I remember at some point you all were talking about something about
> the "ramp time" of the PMIC or something.
>
> On Wed, Dec 2, 2015 at 3:11 PM, Gerald Coley 
> wrote:
>
>> I would start with your cape design and try and rule that out first.
>>
>> The reset is an input pin read by the processor, not actually a HW
>> power reset. If the SW is locked up, this could happen.
>>
>> If you hold the power button for a 8 seconds or more the board should
>> power cycle.
>>
>> When it is in this state, what do the voltages read?
>>
>> Gerald
>>
>>
>> On Wed, Dec 2, 2015 at 3:54 PM, Jonathan Ross 
>> wrote:
>>
>>> Once in a blue moon one of my beaglebones will get into a state
>>> where it has power (the power LED is lit), but it is not booted. 
>>> Normally
>>> this would be fine, just hit the power button to reset. But in this 
>>> weird
>>> state the power button does nothing. The reset button does nothing.
>>> I checked the power and reset button pins on the header, the power
>>> was low, the reset was high.
>>> The only way to get the board out of this state was to pull the 5V
>>> power.
>>> I'm using a KL16 on a cape to do a watchdog on the BB, and reboot it
>>> via power and/or reset buttons on the header if the BB stops sending
>>> checkins over uart. This has been working great, except for the rare 
>>> case
>>> where the board ends up in this state where the power and reset buttons 
>>> are
>>> not functioning.
>>> Any ideas how the BB could get into this state, and if there's any
>>> other way to force a reboot other than physically pulling the 5v power?
>>> Thanks,
>>> JR
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@beagleboard.org
>> http://beagleboard.org/
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

Re: [beagleboard] BBB frozen, how to reset?

[Gerald Coley]

We could do that. I just need some information on which pin to remove from
the expansion header.

Gerald


On Wed, Dec 2, 2015 at 7:15 PM, evilwulfie  wrote:

> After reading all about the WDT inside the sitara the only way to cold
> reset the processor is to power cycle it OR
> pull PMIC_PGOOD low which pulls PORZ low which will cold reset the IC.
> IT seems to me that there is some shortsightedness of TI not allowing the
> cold reset to be pulsed from a WDT.
> In case of a processor hang where a warm reset cannot allow the IC to
> recover.
>
> So you may want to find that signal on the board and tie your external WDT
> to it and see if this solves your problem.
> Maybe in the next rev of the BBB this can be some how made available for
> an external WDT.
>
>
>
>
>
>
> On 12/2/2015 5:42 PM, William Hermans wrote:
>
> So just in case this is helpful to the whole process:
>
> william@beaglebone:~$ uname -a
> Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC 2015 armv7l
> GNU/Linux
> william@beaglebone:~$ cat /etc/dogtag
> BeagleBoard.org Debian Image 2015-03-01
> william@beaglebone:~$ pstree
> init-+-bluetoothd
>  |-cron
>  |-dbus-daemon
>  |-7*[getty]
>  |-rpc.idmapd
>  |-rpc.statd
>  |-rpcbind
>  |-rsyslogd---3*[{rsyslogd}]
>  |-sshd---sshd---sshd---bash---pstree
>  `-udevd---2*[udevd]
>
> The output of pstree is just to show that I'm not running systemd, but
> instead sysv.
>
> On Wed, Dec 2, 2015 at 5:38 PM, William Hermans  wrote:
>
>> *Element14 revC.*
>>> *I think what you are describing is the power ramp issue. I don't think
>>> what I'm experiencing is the same thing. I've been through the power ramp
>>> issue and I just use my external KL16 to toggle the BBB pwr button a few
>>> seconds after power is applied, which kicks the board into boot.*
>>> *Jon*
>>>
>>
>> Not trying to be difficult, or argumentative . . . but no, I think we're
>> experiencing the same thing. Only because the board will not boot up Linux
>> at all after it gets into this state. The LEDs will cycle on, then off, but
>> then nothing. I have to physically remove the power from the board for a
>> few seconds, before it'll boot again. Passed that, sometimes, the processes
>> of removing the power may have to be repeated a few times before the board
>> does finally boot. However this last part seems to mostly apply to our
>> A5A's mostly. I do not recall the Element14 RevC's doing this.
>>
>> On Wed, Dec 2, 2015 at 5:32 PM, Jonathan Ross < 
>> jonr...@nephology.org> wrote:
>>
>>> Element14 revC.
>>> I think what you are describing is the power ramp issue. I don't think
>>> what I'm experiencing is the same thing. I've been through the power ramp
>>> issue and I just use my external KL16 to toggle the BBB pwr button a few
>>> seconds after power is applied, which kicks the board into boot.
>>> Jon
>>>
>>> On Wednesday, December 2, 2015 at 4:27:49 PM UTC-8, William Hermans
>>> wrote:

 Which board revision Jonathon ? This board I noticed this on last night
 is an Element14 RevC. But on our A5A's I never noticed the USR LEDs cycling
 like that.

 On Wed, Dec 2, 2015 at 4:59 PM, Jonathan Ross 
 wrote:

> Got you on the script front. My issue is slightly different, when I
> get into my magic state, pressing the power button does nothing.
>
> On Wednesday, December 2, 2015 at 3:51:42 PM UTC-8, William Hermans
> wrote:
>>
>>
>>> *In my case linux is not booted at this time(none of the 4 user leds
>>> lit), so a script would not help. This is why I'm doing an external
>>> watchdog circuit. *
>>
>>
>> Exactly. So here is what I mean. The USR LEDs cycle on for me *if*
>> and only *if* I press the power button on the board. After that, nothing
>> changes. Otherwise the LEDs are off, well the power LED is on, and the
>> ethernet port lights are on too, and potentially blinking.
>>
>> The script, would just be to reboot the board in an attempt to put
>> the board back into the bad state. For troubleshooting . . .
>>
>> On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross 
>> wrote:
>>
>>> In my case linux is not booted at this time(none of the 4 user leds
>>> lit), so a script would not help. This is why I'm doing an external
>>> watchdog circuit.
>>>
>>> On Wednesday, December 2, 2015 at 3:41:32 PM UTC-8, William Hermans
>>> wrote:

 *I didn't test the 8 second holddown of the power button but I
> doubt it would help, and unfortunately it's not a reproducible issue. 
> I'll
> have to wait for it to happen again.*
>

 I know what you mean, e.g. this happens so erratically, it's hard
 to tell when it'll happen next. But, I could possibly whip up a 
 script, and
 a 

[beagleboard] Newest Debian images from eLinux missing ntp and other packages

[kyleps]

I have been working the BBB Rev B and C for over a year, and I've been 
using the Debian images provided by eLinux and Beagleboard, available from 
- 

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Releases

and http://beagleboard.org/latest-images

In the most recent builds from 2015-11-03, I've been having a lot of 
trouble with missing system tools and packages.
Some examples include - 

- wrong date and time set due to ntp service not being installed, 
installing ntp resolves this issue
- inability to connect using supported wifi adapter due to missing 
wireless-tools package
- missing DNS support which causes apt-get to fail as it is unable to 
correctly resolve the IP addresses for the rcn.ee repos included in the 
builds
- missing /sbin directory in PATH, including missing ifconfig command, 
adding /sbin to path resolves these issues


Did I miss some announcement or release notes about these releases that 
says they are lighter than previous builds?

Why didn't I have most of these issues with previous builds?  
IIRC, all the builds I used before included ntp, /sbin in the PATH, and DNS 
support, and wireless worked OOTB (after editing /etc/network/interfaces)

Thanks all for any help or guidance offered.

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

Re: [beagleboard] ssh keygen on boot

[Robert Nelson]

On Wed, Dec 2, 2015 at 7:24 PM, Josh Datko  wrote:
> I just saw this:
> http://www.theregister.co.uk/2015/12/02/raspberry_pi_weak_ssh_keys/
>
> I think that /dev/hwrng support has been in the image for a while now,
> but I'm bit out-of-touch of where the latest code is.
>
> Can somebody either verify the BeagleBone's code is correct (for ssh
> host key creation) or point me to the repo and I'll take a look?

So going back to our old 3.8 kernel:

CONFIG_HW_RANDOM_OMAP=m

With the way we create images, the first ssh key is removed: (initial
debootstrap ssh key)

if [ -d "${tempdir}/etc/ssh/" -a "x${keep_ssh_keys}" = "x" ] ; then
#Remove pre-generated ssh keys, these will be regenerated on first bootup...
sudo rm -rf "${tempdir}"/etc/ssh/ssh_host_* || true
sudo touch "${tempdir}/etc/ssh/ssh.regenerate" || true
fi

https://github.com/RobertCNelson/omap-image-builder/blob/master/scripts/chroot.sh#L1146-L1151

Then the init script will generate a new key on bootup:

#Regenerate ssh host keys
if [ -f /etc/ssh/ssh.regenerate ] ; then
rm -rf /etc/ssh/ssh_host_* || true
dpkg-reconfigure openssh-server
sync
if [ -s /etc/ssh/ssh_host_ecdsa_key.pub ] ; then
rm -f /etc/ssh/ssh.regenerate || true
sync
fi
if [ -f /etc/init.d/ssh ] ; then
/etc/init.d/ssh restart
fi
fi

https://github.com/RobertCNelson/omap-image-builder/blob/master/target/init_scripts/generic-debian.sh#L41-L53

and the flasher makes sure the eMMC will have different keys, then
your boot microSD:

if [ -d /tmp/rootfs/etc/ssh/ ] ; then
#ssh keys will now get regenerated on the next bootup
touch /tmp/rootfs/etc/ssh/ssh.regenerate
flush_cache
fi

https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh#L367-L371

Now... if we had a battery backed rtc, it would be better..  But i
think we are in pretty good shape..

So ignoring the root login over 22 with no password...  or
nodejs/bonescript/etc..  At least the key is safe. ;)


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

Re: [beagleboard] BBB frozen, how to reset?

[Gerald Coley]

We can do that. Nothing pending that calls for a design update. So, it will
be a while.

Gerald

On Wed, Dec 2, 2015 at 7:58 PM, evilwulfie  wrote:

> Just do it like the battery inputs allow a pin/hole for later population
> if required.
> I doubt anybody would give up any I/O pins without a fight.
>
>
>
>
>
> On 12/2/2015 6:32 PM, Gerald Coley wrote:
>
> We could do that. I just need some information on which pin to remove from
> the expansion header.
>
> Gerald
>
>
> On Wed, Dec 2, 2015 at 7:15 PM, evilwulfie  wrote:
>
>> After reading all about the WDT inside the sitara the only way to cold
>> reset the processor is to power cycle it OR
>> pull PMIC_PGOOD low which pulls PORZ low which will cold reset the IC.
>> IT seems to me that there is some shortsightedness of TI not allowing the
>> cold reset to be pulsed from a WDT.
>> In case of a processor hang where a warm reset cannot allow the IC to
>> recover.
>>
>> So you may want to find that signal on the board and tie your external
>> WDT to it and see if this solves your problem.
>> Maybe in the next rev of the BBB this can be some how made available for
>> an external WDT.
>>
>>
>>
>>
>>
>>
>> On 12/2/2015 5:42 PM, William Hermans wrote:
>>
>> So just in case this is helpful to the whole process:
>>
>> william@beaglebone:~$ uname -a
>> Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC 2015 armv7l
>> GNU/Linux
>> william@beaglebone:~$ cat /etc/dogtag
>> BeagleBoard.org Debian Image 2015-03-01
>> william@beaglebone:~$ pstree
>> init-+-bluetoothd
>>  |-cron
>>  |-dbus-daemon
>>  |-7*[getty]
>>  |-rpc.idmapd
>>  |-rpc.statd
>>  |-rpcbind
>>  |-rsyslogd---3*[{rsyslogd}]
>>  |-sshd---sshd---sshd---bash---pstree
>>  `-udevd---2*[udevd]
>>
>> The output of pstree is just to show that I'm not running systemd, but
>> instead sysv.
>>
>> On Wed, Dec 2, 2015 at 5:38 PM, William Hermans < 
>> yyrk...@gmail.com> wrote:
>>
>>> *Element14 revC.*
 *I think what you are describing is the power ramp issue. I don't think
 what I'm experiencing is the same thing. I've been through the power ramp
 issue and I just use my external KL16 to toggle the BBB pwr button a few
 seconds after power is applied, which kicks the board into boot.*
 *Jon*

>>>
>>> Not trying to be difficult, or argumentative . . . but no, I think we're
>>> experiencing the same thing. Only because the board will not boot up Linux
>>> at all after it gets into this state. The LEDs will cycle on, then off, but
>>> then nothing. I have to physically remove the power from the board for a
>>> few seconds, before it'll boot again. Passed that, sometimes, the processes
>>> of removing the power may have to be repeated a few times before the board
>>> does finally boot. However this last part seems to mostly apply to our
>>> A5A's mostly. I do not recall the Element14 RevC's doing this.
>>>
>>> On Wed, Dec 2, 2015 at 5:32 PM, Jonathan Ross < 
>>> jonr...@nephology.org> wrote:
>>>
 Element14 revC.
 I think what you are describing is the power ramp issue. I don't think
 what I'm experiencing is the same thing. I've been through the power ramp
 issue and I just use my external KL16 to toggle the BBB pwr button a few
 seconds after power is applied, which kicks the board into boot.
 Jon

 On Wednesday, December 2, 2015 at 4:27:49 PM UTC-8, William Hermans
 wrote:
>
> Which board revision Jonathon ? This board I noticed this on last
> night is an Element14 RevC. But on our A5A's I never noticed the USR LEDs
> cycling like that.
>
> On Wed, Dec 2, 2015 at 4:59 PM, Jonathan Ross < 
> jon...@nephology.org> wrote:
>
>> Got you on the script front. My issue is slightly different, when I
>> get into my magic state, pressing the power button does nothing.
>>
>> On Wednesday, December 2, 2015 at 3:51:42 PM UTC-8, William Hermans
>> wrote:
>>>
>>>
 *In my case linux is not booted at this time(none of the 4 user
 leds lit), so a script would not help. This is why I'm doing an 
 external
 watchdog circuit. *
>>>
>>>
>>> Exactly. So here is what I mean. The USR LEDs cycle on for me *if*
>>> and only *if* I press the power button on the board. After that, nothing
>>> changes. Otherwise the LEDs are off, well the power LED is on, and the
>>> ethernet port lights are on too, and potentially blinking.
>>>
>>> The script, would just be to reboot the board in an attempt to put
>>> the board back into the bad state. For troubleshooting . . .
>>>
>>> On Wed, Dec 2, 2015 at 4:46 PM, Jonathan Ross <
>>> jon...@nephology.org> wrote:
>>>
 In my case linux is not booted at this time(none of the 4 user leds
 lit), so a script would not help. This is 

[beagleboard] ssh keygen on boot

[Josh Datko]

I just saw this:
http://www.theregister.co.uk/2015/12/02/raspberry_pi_weak_ssh_keys/

I think that /dev/hwrng support has been in the image for a while now,
but I'm bit out-of-touch of where the latest code is.

Can somebody either verify the BeagleBone's code is correct (for ssh
host key creation) or point me to the repo and I'll take a look?

Josh



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

Re: [beagleboard] Newest Debian images from eLinux missing ntp and other packages

[Robert Nelson]

On Wed, Dec 2, 2015 at 6:33 PM,   wrote:
> I have been working the BBB Rev B and C for over a year, and I've been using
> the Debian images provided by eLinux and Beagleboard, available from -
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Releases
>
> and http://beagleboard.org/latest-images
>
> In the most recent builds from 2015-11-03, I've been having a lot of trouble
> with missing system tools and packages.
> Some examples include -

Please include the file name, there's dozen images...

> - wrong date and time set due to ntp service not being installed, installing
> ntp resolves this issue

wheezy: ntpdate
jessie: systemd-timesync

> - inability to connect using supported wifi adapter due to missing
> wireless-tools package

your using the "console" image...

> - missing DNS support which causes apt-get to fail as it is unable to
> correctly resolve the IP addresses for the rcn.ee repos included in the
> builds

okay, this is od..


> - missing /sbin directory in PATH, including missing ifconfig command,
> adding /sbin to path resolves these issues

yeap, this is the "console" image, can't fix this as patch isn't installed..

> Did I miss some announcement or release notes about these releases that says
> they are lighter than previous builds?
>
> Why didn't I have most of these issues with previous builds?
> IIRC, all the builds I used before included ntp, /sbin in the PATH, and DNS
> support, and wireless worked OOTB (after editing /etc/network/interfaces)

Based on that, it sounds like your using the "console" over the
"lxde/lxqt" image.  The goal with the "console" image was to be as
small but yet "flash" the eMMC..  Not everyone likes to "apt-get
remove xyz" instead they want something very small, and wireless tools
are not on that requirement list..

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

Re: [beagleboard] BBB frozen, how to reset?

[evilwulfie]

Just do it like the battery inputs allow a pin/hole for later population
if required.
I doubt anybody would give up any I/O pins without a fight.




On 12/2/2015 6:32 PM, Gerald Coley wrote:
> We could do that. I just need some information on which pin to remove
> from the expansion header.
>
> Gerald
>
>
> On Wed, Dec 2, 2015 at 7:15 PM, evilwulfie  > wrote:
>
> After reading all about the WDT inside the sitara the only way to
> cold reset the processor is to power cycle it OR
> pull PMIC_PGOOD low which pulls PORZ low which will cold reset the IC.
> IT seems to me that there is some shortsightedness of TI not
> allowing the cold reset to be pulsed from a WDT.
> In case of a processor hang where a warm reset cannot allow the IC
> to recover.
>
> So you may want to find that signal on the board and tie your
> external WDT to it and see if this solves your problem.
> Maybe in the next rev of the BBB this can be some how made
> available for an external WDT.
>
>
>
>
>
>
> On 12/2/2015 5:42 PM, William Hermans wrote:
>> So just in case this is helpful to the whole process:
>>
>> william@beaglebone:~$ uname -a
>> Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC 2015
>> armv7l GNU/Linux
>> william@beaglebone:~$ cat /etc/dogtag
>> BeagleBoard.org Debian Image 2015-03-01
>> william@beaglebone:~$ pstree
>> init-+-bluetoothd
>>  |-cron
>>  |-dbus-daemon
>>  |-7*[getty]
>>  |-rpc.idmapd
>>  |-rpc.statd
>>  |-rpcbind
>>  |-rsyslogd---3*[{rsyslogd}]
>>  |-sshd---sshd---sshd---bash---pstree
>>  `-udevd---2*[udevd]
>>
>> The output of pstree is just to show that I'm not running
>> systemd, but instead sysv.
>>
>> On Wed, Dec 2, 2015 at 5:38 PM, William Hermans
>> > wrote:
>>
>> /Element14 revC./
>> /I think what you are describing is the power ramp issue.
>> I don't think what I'm experiencing is the same thing.
>> I've been through the power ramp issue and I just use my
>> external KL16 to toggle the BBB pwr button a few seconds
>> after power is applied, which kicks the board into boot./
>> /Jon/
>>
>>
>> Not trying to be difficult, or argumentative . . . but no, I
>> think we're experiencing the same thing. Only because the
>> board will not boot up Linux at all after it gets into this
>> state. The LEDs will cycle on, then off, but then nothing. I
>> have to physically remove the power from the board for a few
>> seconds, before it'll boot again. Passed that, sometimes, the
>> processes of removing the power may have to be repeated a few
>> times before the board does finally boot. However this last
>> part seems to mostly apply to our A5A's mostly. I do not
>> recall the Element14 RevC's doing this.
>>
>> On Wed, Dec 2, 2015 at 5:32 PM, Jonathan Ross
>> > wrote:
>>
>> Element14 revC.
>> I think what you are describing is the power ramp issue.
>> I don't think what I'm experiencing is the same thing.
>> I've been through the power ramp issue and I just use my
>> external KL16 to toggle the BBB pwr button a few seconds
>> after power is applied, which kicks the board into boot.
>> Jon
>>
>> On Wednesday, December 2, 2015 at 4:27:49 PM UTC-8,
>> William Hermans wrote:
>>
>> Which board revision Jonathon ? This board I noticed
>> this on last night is an Element14 RevC. But on our
>> A5A's I never noticed the USR LEDs cycling like that.
>>
>> On Wed, Dec 2, 2015 at 4:59 PM, Jonathan Ross
>> >
>> wrote:
>>
>> Got you on the script front. My issue is slightly
>> different, when I get into my magic state,
>> pressing the power button does nothing.
>>
>> On Wednesday, December 2, 2015 at 3:51:42 PM
>> UTC-8, William Hermans wrote:
>>
>> /In my case linux is not booted at this
>> time(none of the 4 user leds lit), so a
>> script would not help. This is why I'm
>> doing an external watchdog circuit.
>> /
>>
>>
>> Exactly. So here is what I mean. The USR LEDs
>> cycle on for me *if* and only *if* I press
>> the power button on the board. After that,
>>