Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[xmacleod]

The BB uses the TPS65217 power management IC.  Per the data sheet, it will 
not turn on if the applied power has a ramp of greater than 50 mSec.

On Thursday, August 1, 2013 at 5:07:13 PM UTC-4, dennis.c...@gmail.com 
wrote:
>
> Yes, I checked the Wiki.  The 2A wall wart from Adafruit was purchased 
> because the Wiki pointed at it and said it was a power supply that worked.
>
> So I have three perfectly working boards and one not-working board, and 
> I'm using a power supply recommended by the Wiki.  If that recommendation 
> was in error and there's another one which will work better I'm all ears.
>
> On the other hand, is it not possible that the problem might not always be 
> the power supply but in fact might sometimes be the board?
>
> Dennis Ferguson
>
> On Thursday, August 1, 2013 8:37:36 AM UTC-4, Gerald wrote:
>>
>> Did you check the Wiki? We have power supplies listed there 
>> under accessories. Just because a distributor recommends it, does not make 
>> it so.
>>
>> http://circuitco.com/support/BeagleBoneBlack
>>
>>
>> Again, it is not an amperage question.
>>
>> Gerald
>>
>>
>> On Wed, Jul 31, 2013 at 11:23 PM,  wrote:
>>
>>> Which power supply is the right one?
>>>
>>> I have four boards and three different power supplies.  Three of the 
>>> boards always boot, on any of those supplies, when the AC is turned on or 
>>> when the power connector is plugged in.  The fourth board never does with 
>>> any of the power supplies.
>>>
>>> The fourth board will boot 100% of the time if the reset button is 
>>> pushed after it has failed to boot on power up.  When I connected the 
>>> serial cable to see if I could find out what it was doing when it didn't 
>>> boot I also discovered it would boot 100% of the time when powered up with 
>>> the serial cable connected.  When the serial cable is disconnected it stops 
>>> booting.
>>>
>>> I run NetBSD from an SD card currently, the original Linux is still on 
>>> the internal flash.  It doesn't boot on power up with the SD card plugged 
>>> in and it doesn't boot with it taken out.  The other three boards always do.
>>>
>>> The three supplies I've got are a 2A wall wart from either Newark or 
>>> Adafruit which was recommended for the BBB, a 5A supply with 4 USB outputs 
>>> and an old HP bench supply.  It behaves the same with all of them.
>>>
>>> I need the cards to recover from power failures on their own so it's a 
>>> concern. It certainly seems that not all BBB cards are created equal.  If 
>>> there's a particular power supply that fixes all problems, however, I'd be 
>>> interested in knowing which.
>>>
>>> Dennis Ferguson
>>>
>>> On Wednesday, July 31, 2013 11:15:23 PM UTC-4, Gerald wrote:
>>> > The PORz, PMIC_PGOOD, is programmable via a register setting in the 
>>> TPS65217C.
>>> >
>>> >
>>> > Get the right power supply, and the issue should not exist.
>>> >
>>> >
>>> > Gerald
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Jul 31, 2013 at 10:09 PM, evilwulfie  
>>> wrote:
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > for an embedded device that does not
>>> >   have the reset button visable
>>> >
>>> >   this poses an issue, is there something that can be done in
>>> >   hardware to hold the reset low longer ?
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >   On 7/31/2013 7:56 PM, Gerald Coley wrote:
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > This is what I mentioned earlier. This was one of
>>> > the reasons I added the power button. Using that to turn on and
>>> > off helps this issue. The SW handles it OK, but it takes a
>>> > little too long to shut down.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Gerald
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Jul 31, 2013 at 9:40 PM, David
>>> >   Lambert 
>>> >   wrote:
>>> >
>>> >   I have
>>> > found that both BBB and BBB seem to be rather sensitive to
>>> > the rise time of the DC power supply. I did some tests with
>>> > a controlled rate power circuit and found that if the rise
>>> > time was greater than around 500uS, then certain of our
>>> > boards would not start. My solution was to hold reset until
>>> > the power was stable, then release it. Now we get 100%
>>> > success. I thought the PMIC chip was designed to be 
>>> tolerant
>>> > to slowly rising power, but I have not had time to
>>> > investigate further.
>>> >
>>> >
>>> >
>>> > HTH,
>>> >
>>> >
>>> >
>>> > Dave.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On 13-07-31 04:48 PM, duckhunt...@gmail.com wrote:
>>> >
>>> >
>>> >   Hi guys,
>>> >
>>> >
>>> >
>>> >   we have a problem with our Beagle Bone Black (A5C). 
>>> We
>>> >   are using Ubuntu Raring 13.04 armhf v3.8.13-bone21
>>> >   (2013-06-14) on the eMMC (no SD Card). The Beagle 
>>>

Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Mikkel Kirkgaard Nielsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there Martin.

On 2015-01-14 18:05, martin.zol...@spotme.com wrote:
> Just as a +1 to Andrew's findings: In summary, this software fix is
>  still highly useful.

Glad you were able to solve your issue.
I'm just wondering if Andrew's autoboot solution/hack hasn't
propagated to the official software yet?

Seems odd if not, since so many has been bitten by it and it is now 15
months since it was first described (2013-10-28:
https://groups.google.com/forum/#!msg/beagleboard/aXv6An1xfqI/2_tLa7oWQBIJ).


I haven't studied the u-boot source before but I just took a sniff at
the mainline repository (http://git.denx.de/u-boot.git).
I found that for BBB (really am335x) u-boot still defaults to aborting
autoboot if any characters are received on the serial console and then
waiting forever for further commands.

Below is a patch mitigating this situation in mainline master
(binaries at
http://www.mikini.dk/wp-content/uploads/2015/01/u-boot_mainline_BBB-autoboot-patch_201501151.zip).
It requires typing more characters ("stop") to abort and uses a new(?)
config feature to reset the board if autoboot is aborted but no
commands are entered (for 30 sec).
Except for the 30 sec timeout, which doesn't kick in for some unknown
reason, it seems to behave ok.

Disclaimer: this is mostly an experiment, there is a lot of u-boot
trees and patches floating around for the BBB (like
https://github.com/beagleboard/u-boot), so probably mainline hasn't
got the most recent stuff for BBB yet.


diff --git a/include/configs/ti_am335x_common.h
b/include/configs/ti_am335x_common.h
index 5ed86d9..c58f467 100644
- --- a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -12,6 +12,12 @@
 #ifndef __CONFIG_TI_AM335X_COMMON_H__
 #define __CONFIG_TI_AM335X_COMMON_H__

+#define CONFIG_AUTOBOOT_KEYED
+#define CONFIG_AUTOBOOT_STOP_STR "stop"
+#define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds (type '%s' to
abort)\n",bootdelay,CONFIG_AUTOBOOT_STOP_STR
+#define CONFIG_BOOT_RETRY_TIME 30
+#define CONFIG_RESET_TO_RETRY
+
 #define CONFIG_AM33XX
 #define CONFIG_ARCH_CPU_INIT
 #define CONFIG_SYS_CACHELINE_SIZE   64
@@ -102,4 +108,7 @@
 /* Now bring in the rest of the common code. */
 #include 

+#undef  CONFIG_BOOTDELAY
+#define CONFIG_BOOTDELAY   5
+
 #endif /* __CONFIG_TI_AM335X_COMMON_H__ */


> Thank you Andrew and Guglielmo for your work!

Thumbs up, also for Guillermo ;).

- -- 
Mikkel
  ,= ,-_-. =.
 ((_/)o o(\_))
  `-'(. .)`-'
  \_/
keybase.io/mikini
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUt9HnAAoJEJ2luFWzaTSaqCoH/2cuFepOVkHGM0gGaGV5U8Dg
/Z3O4Cb1zGyasSeYLZbU5XfOms6k66hbLmbQiDYIKkMv/KS0gcjjkuFaZBE2NdVJ
xFnaPS/XPd8MJcwWQMVScFafNJE1E4KLHe437FeenPZLEBcgtZc/AsTFX+mybKhC
oQfaUmrA9gT2KGmFoGB8Sp+4q4reciXicHRfet78aEF8g9FdqprQvf4xjfcZYgxL
0cNNbXh+mmT+AjSCB4CEze25V5yitvfT744WUUHFznfRWXkRVvKpiVeiDwdswKcs
AaV5yjCqxb0F3iM4leRxdDy3FhuMjxmyZxk9HpwO/sLKExigNktpd3aRjuHO7ds=
=jU44
-END PGP SIGNATURE-

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Patrick Schmidt]

Mikkel,

I just found this forum after a couple beaglebones I have starting 
displaying the same problem discussed here. I figured I would reply to you 
since I saw you just posted. I have a question on how to implement Andrew's 
solution. I am able to download and build the u-boot, everything is working 
fine there. Then I have two files, MLO and u-boot.img that I can copy into 
the boot directory (/boot/uboot I am using Debian and booting from the 
eMMC). My question is when are we suppose to edit the config.h file? After 
I build and move the 2 files? I'm wondering because in Andrew's post he 
mentions that he edited the config.h file then rebuilt the u-boot. But when 
I try this it just overwrites the config.h file back to the original. So I 
assume the process should be first download and build the u-boot, then move 
the MLO and u-boot.img to the boot directory, finally edit the config.h 
file. Is this correct? I have tried everything I can think of but my board 
is still hanging on boots about 1 out of 20. Forgive me because I am not 
too familiar with Debian. Thank you for any help you can provide!

On Thursday, January 15, 2015 at 8:43:07 AM UTC-6, Mikkel Kirkgaard Nielsen 
wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA1 
>
> Hi there Martin. 
>
> On 2015-01-14 18:05, martin...@spotme.com  wrote: 
> > Just as a +1 to Andrew's findings: In summary, this software fix is 
> >  still highly useful. 
>
> Glad you were able to solve your issue. 
> I'm just wondering if Andrew's autoboot solution/hack hasn't 
> propagated to the official software yet? 
>
> Seems odd if not, since so many has been bitten by it and it is now 15 
> months since it was first described (2013-10-28: 
> https://groups.google.com/forum/#!msg/beagleboard/aXv6An1xfqI/2_tLa7oWQBIJ). 
>
>
>
> I haven't studied the u-boot source before but I just took a sniff at 
> the mainline repository (http://git.denx.de/u-boot.git). 
> I found that for BBB (really am335x) u-boot still defaults to aborting 
> autoboot if any characters are received on the serial console and then 
> waiting forever for further commands. 
>
> Below is a patch mitigating this situation in mainline master 
> (binaries at 
>
> http://www.mikini.dk/wp-content/uploads/2015/01/u-boot_mainline_BBB-autoboot-patch_201501151.zip).
>  
>
> It requires typing more characters ("stop") to abort and uses a new(?) 
> config feature to reset the board if autoboot is aborted but no 
> commands are entered (for 30 sec). 
> Except for the 30 sec timeout, which doesn't kick in for some unknown 
> reason, it seems to behave ok. 
>
> Disclaimer: this is mostly an experiment, there is a lot of u-boot 
> trees and patches floating around for the BBB (like 
> https://github.com/beagleboard/u-boot), so probably mainline hasn't 
> got the most recent stuff for BBB yet. 
>
>
> diff --git a/include/configs/ti_am335x_common.h 
> b/include/configs/ti_am335x_common.h 
> index 5ed86d9..c58f467 100644 
> - --- a/include/configs/ti_am335x_common.h 
> +++ b/include/configs/ti_am335x_common.h 
> @@ -12,6 +12,12 @@ 
>  #ifndef __CONFIG_TI_AM335X_COMMON_H__ 
>  #define __CONFIG_TI_AM335X_COMMON_H__ 
>
> +#define CONFIG_AUTOBOOT_KEYED 
> +#define CONFIG_AUTOBOOT_STOP_STR "stop" 
> +#define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds (type '%s' to 
> abort)\n",bootdelay,CONFIG_AUTOBOOT_STOP_STR 
> +#define CONFIG_BOOT_RETRY_TIME 30 
> +#define CONFIG_RESET_TO_RETRY 
> + 
>  #define CONFIG_AM33XX 
>  #define CONFIG_ARCH_CPU_INIT 
>  #define CONFIG_SYS_CACHELINE_SIZE   64 
> @@ -102,4 +108,7 @@ 
>  /* Now bring in the rest of the common code. */ 
>  #include  
>
> +#undef  CONFIG_BOOTDELAY 
> +#define CONFIG_BOOTDELAY   5 
> + 
>  #endif /* __CONFIG_TI_AM335X_COMMON_H__ */ 
>
>
> > Thank you Andrew and Guglielmo for your work! 
>
> Thumbs up, also for Guillermo ;). 
>
> - -- 
> Mikkel 
>   ,= ,-_-. =. 
>  ((_/)o o(\_)) 
>   `-'(. .)`-' 
>   \_/ 
> keybase.io/mikini 
> -BEGIN PGP SIGNATURE- 
> Version: GnuPG v1 
>
> iQEcBAEBAgAGBQJUt9HnAAoJEJ2luFWzaTSaqCoH/2cuFepOVkHGM0gGaGV5U8Dg 
> /Z3O4Cb1zGyasSeYLZbU5XfOms6k66hbLmbQiDYIKkMv/KS0gcjjkuFaZBE2NdVJ 
> xFnaPS/XPd8MJcwWQMVScFafNJE1E4KLHe437FeenPZLEBcgtZc/AsTFX+mybKhC 
> oQfaUmrA9gT2KGmFoGB8Sp+4q4reciXicHRfet78aEF8g9FdqprQvf4xjfcZYgxL 
> 0cNNbXh+mmT+AjSCB4CEze25V5yitvfT744WUUHFznfRWXkRVvKpiVeiDwdswKcs 
> AaV5yjCqxb0F3iM4leRxdDy3FhuMjxmyZxk9HpwO/sLKExigNktpd3aRjuHO7ds= 
> =jU44 
> -END PGP SIGNATURE- 
>

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Andrew Glen]

Hi Patrick,

Ensure you modify config.h after running the clean and configure steps
before compiling, otherwise it will re-copy the default configuration file.

Only once you have compiled with the correct config file should the u-boot
image be copied over.

BTW there is a run-time config file for u-boot that can be used to achieve
the same effect (i.e. without the need to rebuild and copy over u-boot) -
this might be worth investigating as a lower-risk option.


Cheers,
Andrew.

On 16 January 2015 at 11:20, Patrick Schmidt  wrote:

> Mikkel,
>
> I just found this forum after a couple beaglebones I have starting
> displaying the same problem discussed here. I figured I would reply to you
> since I saw you just posted. I have a question on how to implement Andrew's
> solution. I am able to download and build the u-boot, everything is working
> fine there. Then I have two files, MLO and u-boot.img that I can copy into
> the boot directory (/boot/uboot I am using Debian and booting from the
> eMMC). My question is when are we suppose to edit the config.h file? After
> I build and move the 2 files? I'm wondering because in Andrew's post he
> mentions that he edited the config.h file then rebuilt the u-boot. But when
> I try this it just overwrites the config.h file back to the original. So I
> assume the process should be first download and build the u-boot, then move
> the MLO and u-boot.img to the boot directory, finally edit the config.h
> file. Is this correct? I have tried everything I can think of but my board
> is still hanging on boots about 1 out of 20. Forgive me because I am not
> too familiar with Debian. Thank you for any help you can provide!
>
> On Thursday, January 15, 2015 at 8:43:07 AM UTC-6, Mikkel Kirkgaard
> Nielsen wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi there Martin.
>>
>> On 2015-01-14 18:05, martin...@spotme.com wrote:
>> > Just as a +1 to Andrew's findings: In summary, this software fix is
>> >  still highly useful.
>>
>> Glad you were able to solve your issue.
>> I'm just wondering if Andrew's autoboot solution/hack hasn't
>> propagated to the official software yet?
>>
>> Seems odd if not, since so many has been bitten by it and it is now 15
>> months since it was first described (2013-10-28:
>> https://groups.google.com/forum/#!msg/beagleboard/
>> aXv6An1xfqI/2_tLa7oWQBIJ).
>>
>>
>> I haven't studied the u-boot source before but I just took a sniff at
>> the mainline repository (http://git.denx.de/u-boot.git).
>> I found that for BBB (really am335x) u-boot still defaults to aborting
>> autoboot if any characters are received on the serial console and then
>> waiting forever for further commands.
>>
>> Below is a patch mitigating this situation in mainline master
>> (binaries at
>> http://www.mikini.dk/wp-content/uploads/2015/01/u-
>> boot_mainline_BBB-autoboot-patch_201501151.zip).
>> It requires typing more characters ("stop") to abort and uses a new(?)
>> config feature to reset the board if autoboot is aborted but no
>> commands are entered (for 30 sec).
>> Except for the 30 sec timeout, which doesn't kick in for some unknown
>> reason, it seems to behave ok.
>>
>> Disclaimer: this is mostly an experiment, there is a lot of u-boot
>> trees and patches floating around for the BBB (like
>> https://github.com/beagleboard/u-boot), so probably mainline hasn't
>> got the most recent stuff for BBB yet.
>>
>>
>> diff --git a/include/configs/ti_am335x_common.h
>> b/include/configs/ti_am335x_common.h
>> index 5ed86d9..c58f467 100644
>> - --- a/include/configs/ti_am335x_common.h
>> +++ b/include/configs/ti_am335x_common.h
>> @@ -12,6 +12,12 @@
>>  #ifndef __CONFIG_TI_AM335X_COMMON_H__
>>  #define __CONFIG_TI_AM335X_COMMON_H__
>>
>> +#define CONFIG_AUTOBOOT_KEYED
>> +#define CONFIG_AUTOBOOT_STOP_STR "stop"
>> +#define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds (type '%s' to
>> abort)\n",bootdelay,CONFIG_AUTOBOOT_STOP_STR
>> +#define CONFIG_BOOT_RETRY_TIME 30
>> +#define CONFIG_RESET_TO_RETRY
>> +
>>  #define CONFIG_AM33XX
>>  #define CONFIG_ARCH_CPU_INIT
>>  #define CONFIG_SYS_CACHELINE_SIZE   64
>> @@ -102,4 +108,7 @@
>>  /* Now bring in the rest of the common code. */
>>  #include 
>>
>> +#undef  CONFIG_BOOTDELAY
>> +#define CONFIG_BOOTDELAY   5
>> +
>>  #endif /* __CONFIG_TI_AM335X_COMMON_H__ */
>>
>>
>> > Thank you Andrew and Guglielmo for your work!
>>
>> Thumbs up, also for Guillermo ;).
>>
>> - --
>> Mikkel
>>   ,= ,-_-. =.
>>  ((_/)o o(\_))
>>   `-'(. .)`-'
>>   \_/
>> keybase.io/mikini
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJUt9HnAAoJEJ2luFWzaTSaqCoH/2cuFepOVkHGM0gGaGV5U8Dg
>> /Z3O4Cb1zGyasSeYLZbU5XfOms6k66hbLmbQiDYIKkMv/KS0gcjjkuFaZBE2NdVJ
>> xFnaPS/XPd8MJcwWQMVScFafNJE1E4KLHe437FeenPZLEBcgtZc/AsTFX+mybKhC
>> oQfaUmrA9gT2KGmFoGB8Sp+4q4reciXicHRfet78aEF8g9FdqprQvf4xjfcZYgxL
>> 0cNNbXh+mmT+AjSCB4CEze25V5yitvfT744WUUHFznfRWXkRVvKpiVeiDwdswKcs
>> AaV5yjCqxb0F3iM4leRxdDy3FhuMjxmyZxk9HpwO/sLKExi

Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Patrick Schmidt]

>
> Hi Andrew,
>>
> Thank you for your reply. I feel like this is steering me in the right 
direction but I have one more question. After I do the clean and configure 
steps, I am looking for the /include/config.h file but I don't see it 
anywhere. I do see it after I do the compile step so it must be created 
after the compilation. Maybe I am missing something and looking for the 
wrong thing. Once I get this worked out it is going to save me a lot of 
frustration so thank you for all your help. Oh and also the runtime config 
file sounds like something I want to check out but a google search didn't 
help me much. Which file would I be editing for this? 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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[martin . zoller]

Hi Mikkel,

I'm just wondering if Andrew's autoboot solution/hack hasn't 
> propagated to the official software yet? 
>
It's been a while that I haven't looked at the preinstalled software of a 
BBB since I get them pre-flashed with my own image...
The official Angstrom image releases for BBB seem to be 
at http://elinux.org/Beagleboard:Updating_The_Software (the page title is 
slightly misleading).
The most recent image dates from 2013-09-04, and the u-boot files on its 
boot partition are from 2013-06-19. This corresponds to the latest 
modification of [1], where apparently the u-boot patches for BBB are stored.
Clearly there is no fix yet! It looks like that repository is maintained by 
Koen Kooi, so maybe you can send him your patch.
Changing the upstream u-boot source probably doesn't make sense since the 
issue does not apply to other am335x-based systems.

Thumbs up, also for Guillermo ;). 
>
Indeed, I noticed that typo this morning. My apologies!

Thanks,
Martin

[1] 
- 
https://github.com/beagleboard/meta-beagleboard/tree/master/common-bsp/recipes-bsp/u-boot/u-boot-denx

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[patch914]

Mikkel,

I just found this forum after having these same boot problems with a couple 
beaglebones I have. I figured I would reply to you since I noticed you just 
posted a reply. I am a little confused on how to apply the fix Andrew 
provided. I am able to follow the instructions on downloading and building 
the u-boot, everything seems to work fine there. Then I have a MLO and 
u-boot.img file that I copy to the /boot/uboot directory ( I am using 
Debian booting off the eMMC). My question is when are the #DEFINES suppose 
to be added to the config.h file? Andrew mentions that he made the changes 
to the config.h file and rebuilt the u-boot, but when I do that it just 
overwrites the config.h file back to the original. So I assume the process 
should be first download and build the u-boot, then move MLO and u-boot.img 
into the uboot directory (/boot/uboot), then modify the config.h file 
adding in the #DEFINES Andrew provides. Is this correct? I have tried 
everything I can think of, but I you will have to forgive me because I am 
not too familiar with Debian. Thank you for any help you can provide! 

On Thursday, January 15, 2015 at 8:43:07 AM UTC-6, Mikkel Kirkgaard Nielsen 
wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA1 
>
> Hi there Martin. 
>
> On 2015-01-14 18:05, martin...@spotme.com  wrote: 
> > Just as a +1 to Andrew's findings: In summary, this software fix is 
> >  still highly useful. 
>
> Glad you were able to solve your issue. 
> I'm just wondering if Andrew's autoboot solution/hack hasn't 
> propagated to the official software yet? 
>
> Seems odd if not, since so many has been bitten by it and it is now 15 
> months since it was first described (2013-10-28: 
> https://groups.google.com/forum/#!msg/beagleboard/aXv6An1xfqI/2_tLa7oWQBIJ). 
>
>
>
> I haven't studied the u-boot source before but I just took a sniff at 
> the mainline repository (http://git.denx.de/u-boot.git). 
> I found that for BBB (really am335x) u-boot still defaults to aborting 
> autoboot if any characters are received on the serial console and then 
> waiting forever for further commands. 
>
> Below is a patch mitigating this situation in mainline master 
> (binaries at 
>
> http://www.mikini.dk/wp-content/uploads/2015/01/u-boot_mainline_BBB-autoboot-patch_201501151.zip).
>  
>
> It requires typing more characters ("stop") to abort and uses a new(?) 
> config feature to reset the board if autoboot is aborted but no 
> commands are entered (for 30 sec). 
> Except for the 30 sec timeout, which doesn't kick in for some unknown 
> reason, it seems to behave ok. 
>
> Disclaimer: this is mostly an experiment, there is a lot of u-boot 
> trees and patches floating around for the BBB (like 
> https://github.com/beagleboard/u-boot), so probably mainline hasn't 
> got the most recent stuff for BBB yet. 
>
>
> diff --git a/include/configs/ti_am335x_common.h 
> b/include/configs/ti_am335x_common.h 
> index 5ed86d9..c58f467 100644 
> - --- a/include/configs/ti_am335x_common.h 
> +++ b/include/configs/ti_am335x_common.h 
> @@ -12,6 +12,12 @@ 
>  #ifndef __CONFIG_TI_AM335X_COMMON_H__ 
>  #define __CONFIG_TI_AM335X_COMMON_H__ 
>
> +#define CONFIG_AUTOBOOT_KEYED 
> +#define CONFIG_AUTOBOOT_STOP_STR "stop" 
> +#define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds (type '%s' to 
> abort)\n",bootdelay,CONFIG_AUTOBOOT_STOP_STR 
> +#define CONFIG_BOOT_RETRY_TIME 30 
> +#define CONFIG_RESET_TO_RETRY 
> + 
>  #define CONFIG_AM33XX 
>  #define CONFIG_ARCH_CPU_INIT 
>  #define CONFIG_SYS_CACHELINE_SIZE   64 
> @@ -102,4 +108,7 @@ 
>  /* Now bring in the rest of the common code. */ 
>  #include  
>
> +#undef  CONFIG_BOOTDELAY 
> +#define CONFIG_BOOTDELAY   5 
> + 
>  #endif /* __CONFIG_TI_AM335X_COMMON_H__ */ 
>
>
> > Thank you Andrew and Guglielmo for your work! 
>
> Thumbs up, also for Guillermo ;). 
>
> - -- 
> Mikkel 
>   ,= ,-_-. =. 
>  ((_/)o o(\_)) 
>   `-'(. .)`-' 
>   \_/ 
> keybase.io/mikini 
> -BEGIN PGP SIGNATURE- 
> Version: GnuPG v1 
>
> iQEcBAEBAgAGBQJUt9HnAAoJEJ2luFWzaTSaqCoH/2cuFepOVkHGM0gGaGV5U8Dg 
> /Z3O4Cb1zGyasSeYLZbU5XfOms6k66hbLmbQiDYIKkMv/KS0gcjjkuFaZBE2NdVJ 
> xFnaPS/XPd8MJcwWQMVScFafNJE1E4KLHe437FeenPZLEBcgtZc/AsTFX+mybKhC 
> oQfaUmrA9gT2KGmFoGB8Sp+4q4reciXicHRfet78aEF8g9FdqprQvf4xjfcZYgxL 
> 0cNNbXh+mmT+AjSCB4CEze25V5yitvfT744WUUHFznfRWXkRVvKpiVeiDwdswKcs 
> AaV5yjCqxb0F3iM4leRxdDy3FhuMjxmyZxk9HpwO/sLKExigNktpd3aRjuHO7ds= 
> =jU44 
> -END PGP SIGNATURE- 
>

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Mikkel Kirkgaard Nielsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi again Patrick.

On 2015-01-16 16:01, Patrick Schmidt wrote:
> After I do the clean and configure steps, I am looking for the 
> /include/config.h file but I don't see it anywhere.

You could do like in my mainline patch, add the options to a specific
am335x file (I used /include/configs/ti_am335x_common.h). What tree
are you building from?

> Oh and also the runtime config file sounds like something I want to
>  check out but a google search didn't help me much. Which file
> would I be editing for this? Thank you!

This option puzzled me too, hadn't thought this was possible, mostly
because in the boot sequence it seems like the environment is loaded
after the autoboot prompt.

I haven't tried it yet, but if you got the full source tree look for the
autoboot documentation in README and doc/README.autoboot.

In Denx's master you can use the env vars "bootdelaykey" or
"bootstopkey" to disable "any key" autoboot abort. But be sure u-boot is
built with CONFIG_AUTOBOOT_KEYED defined or else these options will not
be enabled.


Environment vars are what can be used at boot time to define how u-boot
should commence booting the OS, besides the options set at compile time.
The environment is read from the uEnv.txt file residing besides MLO and
u-boot typically on eMMC/flash or the SD-card. Normally BBB first tries
the eMMC, then SD. If the boot switch is depressed at powerup (not
reset) eMMC is skipped (actually SPI is tried instead) and u-boot on
the SD-card is used.


Anybody know if these options are available and enabled in u-boot on the
stock BBB images?

- -- 
Mikkel
  ,= ,-_-. =.
 ((_/)o o(\_))
  `-'(. .)`-'
  \_/
keybase.io/mikini
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUuTIFAAoJEJ2luFWzaTSans8IAOqtPsx4kfmA/gs8tDpw5/7r
UxNa0GK/jMyNSZTZraaJEjA9tUQRJw+f23i3Yj9SLzncpQ8l7f8sHKl7JcCrsbNi
8P+G/QWnvDq2mZdlW8VjB+OwO6tqlYTna0xy72tQJlY8CpVcUVneKjqMFMJxV60E
yLlHGCLF+NGiMDPW+AlqaqhQz0+iE6rnUZYTPOyAvHXl/yyAA3rFlgKa+zhFGVEG
QAvvMB95ljTpl7Z3cJdUFe/9L+IKPKiFHPUb4XzJAAjGP44UiiCkXUye1cJzO6vj
jL7Bv1lJh7qwuWXlghKv69Iz917hblNxXgqR//ZzGS4wCDbT26kGPSR3A4hmVVI=
=Pz4n
-END PGP SIGNATURE-

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Robert Nelson]

On Fri, Jan 16, 2015 at 9:45 AM, Mikkel Kirkgaard Nielsen
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi again Patrick.
>
> On 2015-01-16 16:01, Patrick Schmidt wrote:
>> After I do the clean and configure steps, I am looking for the
>> /include/config.h file but I don't see it anywhere.
>
> You could do like in my mainline patch, add the options to a specific
> am335x file (I used /include/configs/ti_am335x_common.h). What tree
> are you building from?
>
>> Oh and also the runtime config file sounds like something I want to
>>  check out but a google search didn't help me much. Which file
>> would I be editing for this? Thank you!
>
> This option puzzled me too, hadn't thought this was possible, mostly
> because in the boot sequence it seems like the environment is loaded
> after the autoboot prompt.
>
> I haven't tried it yet, but if you got the full source tree look for the
> autoboot documentation in README and doc/README.autoboot.
>
> In Denx's master you can use the env vars "bootdelaykey" or
> "bootstopkey" to disable "any key" autoboot abort. But be sure u-boot is
> built with CONFIG_AUTOBOOT_KEYED defined or else these options will not
> be enabled.
>
>
> Environment vars are what can be used at boot time to define how u-boot
> should commence booting the OS, besides the options set at compile time.
> The environment is read from the uEnv.txt file residing besides MLO and
> u-boot typically on eMMC/flash or the SD-card. Normally BBB first tries
> the eMMC, then SD. If the boot switch is depressed at powerup (not
> reset) eMMC is skipped (actually SPI is tried instead) and u-boot on
> the SD-card is used.
>
>
> Anybody know if these options are available and enabled in u-boot on the
> stock BBB images?

The patch-delta used in the BBB images is available here:

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.01/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

It's built against the "am335x_evm" u-boot target..

Regards,

-- 
Robert Nelson
http://www.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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Patrick Schmidt]

Hi Mikkel,

I am trying to follow Andrew's post as close as I can. The tree I am 
building from is git://git.denx.de/u-boot.git, the one provided in Andrew's 
post.

RESOLVED:
>
> Upon investigating the u-boot output we found we were facing the same 
> problem reported earlier in this thread by duckhunter: u-boot was detecting 
> spurious data on uart0 and entering the u-boot console on about 1/20 
> power-ups.
>
> Rather than making any hardware mods I decided to reconfigured u-boot to 
> look for a specific key sequence before entering the u-boot console. To do 
> this I firstly downloaded and rebuilt u-boot following instructions here: 
> http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot.
>  
> (Testing with the default config produced the same 'failure' rate)
> I then modified '/include/config.h' in the u-boot source files, adding the 
> following:
>
> #define CONFIG_AUTOBOOT_KEYED 1 
> #define CONFIG_AUTOBOOT_DELAY_STR "uboot"
>
> This now forces a user to enter the string 'uboot' before entering the 
> u-boot console, otherwise the device will boot up normally.
>
> Rebuilding with this configuration still gave the same failure rate 
> however. This is when I learned that the boot files on the eMMC flash are 
> still loading before jumping to the files on the sd card I am using. So 
> upon deleting the MLO file on the eMMC flash I had more luck.
>
> We setup a programmable power supply and a script looking at the output of 
> uart0 to detect whether the device had successfully booted or had become 
> stuck in u-boot, and then left it cycling power. We were then able to get 
> many hundreds of consecutive successful boots - we only stopped the test 
> because we decided it would probably never fail.
>
> So in the end it all came down to spurious data on uart0 - along with 
> disabling booting from the eMMC. (we could have simply reconfigured u-boot 
> on the eMMC in the same way, but disabling it drops a few seconds off the 
> boot time).
>
>
> Thanks for all your help Gerald (and duckhunter).
>
> Regards,
> Andrew Glen.
>

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Mikkel Kirkgaard Nielsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hellow Martin.

On 2015-01-15 17:43, martin.zol...@spotme.com wrote:
> I'm just wondering if Andrew's autoboot solution/hack hasn't 
> propagated to the official software yet? It's been a while that I
> haven't looked at the preinstalled software of a BBB since I get
> them pre-flashed with my own image...

I haven't looked that much either since I settled on using the, then
latest, Debian 7.5 build from 2014-05-14 as base for our production
systems (which is still in limited deployment testing stage though).

But I see that this build is still regarded as the latest.

> The official Angstrom image releases for BBB seem to be at
> http://elinux.org/Beagleboard:Updating_The_Software (the page
> title is slightly misleading).

- From my perspective that page and Ångström is obsolete!

Debian is touted everywhere on the official pages as the most recent
distribution and also the one flashed on current BBB production HW
(look at http://beagleboard.org/latest-images instead).
Also it is my experience that Debian is a lot easier to work with and
has fewer issues than the Ängström images.

It seems like this is the documentation on the official Beagleboard
Debian images complete with testing builds (most recent is 2014-12-31);
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian. It also points
to how you can roll your own from github here;
https://github.com/beagleboard/image-builder.

I'll try this out, and prepare a patch for Roger et. al. if it isn't
there yet.

> Changing the upstream u-boot source probably doesn't make sense
> since the issue does not apply to other am335x-based systems.

Well, it wont't hurt them, just delay boot(!) a bit ;).
I thought it might be done upstream by enabling CONFIG_AUTOBOOT_KEYED
by default, thus a BBB specific uEnv.txt could configure a stop/delay
string using "bootdelaykey"/"bootstopkey" at boot time. This shouldn't
affect other systems.

That being said, I still regard this as a hardware issue on BBB. Hope
some of the hardware guys are following the discussion trying to
figure out from where the spurious characters are originating.

- -- 
Mikkel
  ,= ,-_-. =.
 ((_/)o o(\_))
  `-'(. .)`-'
  \_/
keybase.io/mikini
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUu49zAAoJEJ2luFWzaTSaWaIIAOo0euGW8SLIAO8oDdIk1QZj
wNhT9mY18D1ea0dFe2aRf47JeqmoRWSQwxq56o3YqC2OkVCFp9+uD/JvcY8nnb9G
z/damkIF2IJl9jApqPFPvc6BGDQSM2vYf9CKAxI7m5QBDyPkMn2UVQhSJJriZLyD
YY/InL489Q+ajB0igUPw+M0iLVewg0vBAnxvnBaYFPtCnsoNWGWu+4IoeyhSUkhx
VZfFn0wX3Q3bjIyM4v7ZSNPn5dhtJ3RIQRlAtuS6KNK7+QwKOqzR9rcMPlp4gJLV
m8S7UZlJzNyJ/8so0VNydwX/NtnsKr1rUJXX6x6NCDFFkjqPZH4EnJGxDAKtZnc=
=n+CV
-END PGP SIGNATURE-

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[ivan . wunderlin]

P.S. It just happened again - so this time I connected the serial debug cable. 
Indeed I seem to have installed the "uboot" workaround wrongly - I get a 
"U-Boot#" shell prompt. If I type "boot" the board starts 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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[ivan . wunderlin]

Hi guys,

I am facing the same problem (power LED on, user LED off and board not booting).

It only happens occasionally. I wrote a script that reboots the board every 60s 
(using "shutdown -r now") to reproduce.

I then installed the "MLO" and "u-boot.img" files that are available in 
"https://www.dropbox.com/sh/98xacnk466xfpza/uTlii1hrsg"; but the problem still 
happens occasionally.

I am not sure though I installed "MLO" and "u-boot.img" correctly - exactly 
which folder do these files have to be copied into?
I found existing "MLO" and "u-boot.img"files in "/opt/backup/uboot" so I copied 
the new files to that location. Or do I have to copy them to "/boot/uboot" 
instead?

Sorry if this seems to be a silly question - I am still quite new to the BBB 
and have been struggling with several issues. This issue is one of them; eth0 
occasionally not connecting after reboot if static IP settings is another one 
(but that will be a separate post).

Thanks for all help; I am a bit in a desperate situation as my system (based on 
BBB) will be installed in an unattended environment where power failures are 
possible - so it is crucial that the boot rate is 100.00%!

Regards
Ivan

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[AQG Chris]

We are dealing with the same issue - we found another complaint of the same 
thing, in which the user identifies phantom characters on the UART during 
startup causing the board to go into u-boot.  If you don't have a display 
attached or a serial connection available, u-boot looks a lot like a solid 
power LED and nothing else.  link to that thread:
http://andicelabs.com/2014/07/beaglebone-black-boot-issues/

That user apparently was able to modify u-boot to look for a certain 
character instead of any keystroke.  In the limiting testing I've done, it 
seems that the problem also doesn't occur if you have a serial connection 
hooked up to UART0.  I'm now experimenting with jumping the RX line of 
UART0 to 3.3v, and so far haven't had the issue again.

On Wednesday, June 3, 2015 at 6:27:26 AM UTC-7, ivan.wu...@gmail.com wrote:
>
> Hi guys, 
>
> I am facing the same problem (power LED on, user LED off and board not 
> booting). 
>
> It only happens occasionally. I wrote a script that reboots the board 
> every 60s (using "shutdown -r now") to reproduce. 
>
> I then installed the "MLO" and "u-boot.img" files that are available in "
> https://www.dropbox.com/sh/98xacnk466xfpza/uTlii1hrsg"; but the problem 
> still happens occasionally. 
>
> I am not sure though I installed "MLO" and "u-boot.img" correctly - 
> exactly which folder do these files have to be copied into? 
> I found existing "MLO" and "u-boot.img"files in "/opt/backup/uboot" so I 
> copied the new files to that location. Or do I have to copy them to 
> "/boot/uboot" instead? 
>
> Sorry if this seems to be a silly question - I am still quite new to the 
> BBB and have been struggling with several issues. This issue is one of 
> them; eth0 occasionally not connecting after reboot if static IP settings 
> is another one (but that will be a separate post). 
>
> Thanks for all help; I am a bit in a desperate situation as my system 
> (based on BBB) will be installed in an unattended environment where power 
> failures are possible - so it is crucial that the boot rate is 100.00%! 
>
> Regards 
> Ivan 
>

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[ivan . wunderlin]

Hi Chris,

Thanks a lot for you response. I would have hoped for the software solution to 
work - I also tested copying u-boot.img and MLO to /boot/uboot but I still get 
the dreaded u-boot prompt.

I now hardwired the Rx line to +3.3V because I don't require u-boot anyway. I 
can still listen to the serial data with Tx; just must not forget not to 
connect the Rx pin ...

I hope that the board still starts up at in a few hours; the 1st 20 attempts or 
so have been successful.

Thinking about it hardwiring the Rx line might also prevent issues after the 
startup. It is certainly not ideal if there are ghost characters coming from 
the serial part even after startup?! If I am extremely lucky (so far my BBB 
experience has been a very rocky road ...) this also solves the issue that the 
eth0 occasionally can't be reached (this also happens after a reboot). I use 
static IP settings and have wicd deinstalled (because wicd caused IP static 
settings to changed when the network disconnected and re-connected).

Regards
Ivan

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Mikkel Kirkgaard Nielsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Ivan & Chris.

I've also struggled with BBB boot reliability and done extensive
testing using different hardware fixes as I thought (and still thinks)
this ought to be resolved close to hardware. Read about it at
http://www.mikini.dk/index.php/category/beaglebone-black/boot-issue.

A patch and build of u-boot mainline (from January) can be found at
http://www.mikini.dk/index.php/2015/01/beaglebone-black-periodic-boot-failure-patching-mainline-u-boot.
It looks for a specific string ("stop") to break boot and dump into
the u-boot prompt, instead of any one character.


On 2015-06-04 00:26, ivan.wunder...@gmail.com wrote:
> I would have hoped for the software solution to work - I also 
> tested copying u-boot.img and MLO to /boot/uboot but I still get 
> the dreaded u-boot prompt.

MLO and u-boot.img needs to be in the root directory of the boot device.

It is actually internal microcode of the processor itself that fetches
the MLO file, this process can't be modified externally. MLO contains
code to set up the hardware which makes main RAM available, loads
u-boot.img into this and executes it (more details at
http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Two_stage_U-Boot_design).

Specific requirements are imposed on the MMC/SD boot devices (onboard
MMC is interfaced as it was a SD-card) and the way they are setup to be
able to load the MLO file, most importantly;
"The image used by the booting procedure is taken from a specific
booting file named “MLO”. This file has to be located in the root
directory on an active primary partition of type FAT12/16 or FAT32."
(details in chapter 26.1.7.5.6 of the AM335x Technical Reference
Manual at http://www.ti.com/lit/pdf/spruh73).


When experimenting with u-boot, it can be confusing to have multiple
sets of MLO/u-boot.img on MMC and external SD. To assure that boot
always occur from the set on the SD-card, you can rename the MLO file in
the root of the onboard MMC. This way boot will fail when the processor
determines MMC bootability in the boot order and the SD-card is always
used.


> Thinking about it hardwiring the Rx line might also prevent issues
>  after the startup. It is certainly not ideal if there are ghost 
> characters coming from the serial part even after startup?!

That would be bad. In my experience it is not an issue after powerup.
I think the spurious character(s) are caused by conditions during
early power up that can cause fluctuations on UART0_RX which are
buffered in the uart until somebody (like u-boot) looks for it.

Removing the buffer chip U15 gets rid of them
(http://www.mikini.dk/index.php/2014/10/beaglebone-black-periodic-boot-failure-establishing-failure-rate-and-possible-cause),
so maybe it is a question of driving 1OE_ input of U15 appropriately
timed to when the am3358 uart behind UART0_RX is ready?

> If I am extremely lucky (so far my BBB experience has been a very 
> rocky road ...) this also solves the issue that the eth0 
> occasionally can't be reached (this also happens after a reboot).

Sorry to say, but it seems unlikely to me that those issues are related.


Good luck.
- -- 
Mikkel
keybase.io/mikini
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJVcDtkAAoJEJ2luFWzaTSanSsH/2TqSTM4C8JJ+SoU/kpgI9t9
/CYFpJDEmjuyalauBlqB3Zx2JGuQlVt6KbrKPei8WP5TOmPfJsyPFFd1HpUHCLAX
oDKvXDi2AbR7Lsbq9rPEH4uJuAKgHVFQA6qBFghIgdxXSyKNpZtzLadogUJWOU4I
tANrjSxZG5uAb8tUim/buv8+imZI2tc74qEW1Zqqbn34vrHBHAAvSJMaEz4zN7rk
18a9VAALpQPH203ZcZP4lLFgZqrQdOSB+weknLTET7zm61zQJjDWxc4t89voMo+N
cVavDNBYsa9z94EVacT6+r/mWyhPBF8EdYoxeg3gFyTLCSR7knTG1v7yy2wqm8c=
=O+/V
-END PGP SIGNATURE-

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[peterlarsen8600]

Hi guys

thank you all for putting your thoughts and experience online. I have the 
exact same issue as discussed here.
Running RCN's latest Ubuntu image on BBB rev C. 

After reading Mikkels detailed reply, I tried out the/his compiled version 
om U-boot. Might save some time instead of having to patch and recompile.
Sadly the BBB did not event start after this :) Luckily booting up with SD 
card, copying back my backup (!!) to the EMMC, got it back to normal.
Consulting Mikkel in private, he adviced me to debug using the serial port 
J1 with a TTL/USB dongle 5V. I used Putty for terminal connection at 
115.200 baud.
Now output of "before" OS startup showed up and the debug process can be 
initiated - yay.

This is the output:

U-Boot SPL 2015.01-00160-gbd5053f-dirty (Jan 15 2015 - 15:06:38)
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2015.01-00160-gbd5053f-dirty (Jan 15 2015 - 15:06:38)

   Watchdog enabled
I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Error - No Valid Environment Area found
*** Warning - bad CRC, using default environment

Net:not set. Validating first E-fuse MAC
cpsw, usb_ether
autoboot in 5 seconds (type 'stop' to abort)
Card did not respond to voltage select!
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1(part 0) is current device
SD/MMC found on device 1
reading boot.scr
** Unable to read file boot.scr **
reading uEnv.txt
** Unable to read file uEnv.txt **
** File not found /boot/zImage **
Booting from nand ...

no devices available

no devices available
Bad Linux ARM zImage magic!
U-Boot#

Might be obious to someone what the fix is. Mikkel adviced to do the 
patch/recompile of the U-Boot so unless a quick'n'dirty trick is to be 
suggested, I'll get on with that.

cheers

Peter





Den torsdag den 4. juni 2015 kl. 13.50.13 UTC+2 skrev Mikkel Kirkgaard 
Nielsen:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA1 
>
> Hello Ivan & Chris. 
>
> I've also struggled with BBB boot reliability and done extensive 
> testing using different hardware fixes as I thought (and still thinks) 
> this ought to be resolved close to hardware. Read about it at 
> http://www.mikini.dk/index.php/category/beaglebone-black/boot-issue. 
>
> A patch and build of u-boot mainline (from January) can be found at 
>
> http://www.mikini.dk/index.php/2015/01/beaglebone-black-periodic-boot-failure-patching-mainline-u-boot.
>  
>
> It looks for a specific string ("stop") to break boot and dump into 
> the u-boot prompt, instead of any one character. 
>
>
> On 2015-06-04 00:26, ivan.wu...@gmail.com  wrote: 
> > I would have hoped for the software solution to work - I also 
> > tested copying u-boot.img and MLO to /boot/uboot but I still get 
> > the dreaded u-boot prompt. 
>
> MLO and u-boot.img needs to be in the root directory of the boot device. 
>
> It is actually internal microcode of the processor itself that fetches 
> the MLO file, this process can't be modified externally. MLO contains 
> code to set up the hardware which makes main RAM available, loads 
> u-boot.img into this and executes it (more details at 
>
> http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Two_stage_U-Boot_design).
>  
>
>
> Specific requirements are imposed on the MMC/SD boot devices (onboard 
> MMC is interfaced as it was a SD-card) and the way they are setup to be 
> able to load the MLO file, most importantly; 
> "The image used by the booting procedure is taken from a specific 
> booting file named “MLO”. This file has to be located in the root 
> directory on an active primary partition of type FAT12/16 or FAT32." 
> (details in chapter 26.1.7.5.6 of the AM335x Technical Reference 
> Manual at http://www.ti.com/lit/pdf/spruh73). 
>
>
> When experimenting with u-boot, it can be confusing to have multiple 
> sets of MLO/u-boot.img on MMC and external SD. To assure that boot 
> always occur from the set on the SD-card, you can rename the MLO file in 
> the root of the onboard MMC. This way boot will fail when the processor 
> determines MMC bootability in the boot order and the SD-card is always 
> used. 
>
>
> > Thinking about it hardwiring the Rx line might also prevent issues 
> >  after the startup. It is certainly not ideal if there are ghost 
> > characters coming from the serial part even after startup?! 
>
> That would be bad. In my experience it is not an issue after powerup. 
> I think the spurious character(s) are caused by conditions during 
> early power up that can cause fluctuations on UART0_RX which are 
> buffered in the uart until somebody (like u-boot) looks for it. 
>
> Removing the buffer chip U15 gets rid of them 
> (
> http://www.mikini.dk/index.php/2014/10/beaglebone-black-periodic-boot-failure-establishing-failure-rate-and-possible-cause),
>  
>
> so maybe it is a question of driving 1OE_ input of U15 appropriately 
> timed to when the am3358 u

Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[peterlarsen8600]

Hi guys

thank you all for putting your thoughts and experience online. I have the 
exact same issue as discussed here.
Running RCN's latest Ubuntu image on BBB rev C. 

After reading Mikkels detailed reply, I tried out the/his compiled version 
om U-boot. Might save some time instead of having to patch and recompile.
Sadly the BBB did not event start after this :) Luckily booting up with SD 
card, copying back my backup (!!) to the EMMC, got it back to normal.
Consulting Mikkel in private, he adviced me to debug using the serial port 
J1 with a TTL/USB dongle 5V. I used Putty for terminal connection at 
115.200 baud.
Now output of "before" OS startup showed up and the debug process can be 
initiated - yay.

This is the output:

U-Boot SPL 2015.01-00160-gbd5053f-dirty (Jan 15 2015 - 15:06:38)
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2015.01-00160-gbd5053f-dirty (Jan 15 2015 - 15:06:38)

   Watchdog enabled
I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Error - No Valid Environment Area found
*** Warning - bad CRC, using default environment

Net:not set. Validating first E-fuse MAC
cpsw, usb_ether
autoboot in 5 seconds (type 'stop' to abort)
Card did not respond to voltage select!
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1(part 0) is current device
SD/MMC found on device 1
reading boot.scr
** Unable to read file boot.scr **
reading uEnv.txt
** Unable to read file uEnv.txt **
** File not found /boot/zImage **
Booting from nand ...

no devices available

no devices available
Bad Linux ARM zImage magic!
U-Boot#

Might be obious to someone what the fix is. Mikkel adviced to do the 
patch/recompile of the U-Boot so unless a quick'n'dirty trick is to be 
suggested, I'll get on with that.

cheers

Peter





Den torsdag den 4. juni 2015 kl. 13.50.13 UTC+2 skrev Mikkel Kirkgaard 
Nielsen:-BEGIN PGP SIGNED MESSAGE- 
Hash: SHA1 

Hello Ivan & Chris. 

I've also struggled with BBB boot reliability and done extensive 
testing using different hardware fixes as I thought (and still thinks) 
this ought to be resolved close to hardware. Read about it at 
http://www.mikini.dk/index.php/category/beaglebone-black/boot-issue. 

A patch and build of u-boot mainline (from January) can be found at 
http://www.mikini.dk/index.php/2015/01/beaglebone-black-periodic-boot-failure-patching-mainline-u-boot.
 

It looks for a specific string ("stop") to break boot and dump into 
the u-boot prompt, instead of any one character. 


On 2015-06-04 00:26, ivan.wu...@gmail.com wrote: 
> I would have hoped for the software solution to work - I also 
> tested copying u-boot.img and MLO to /boot/uboot but I still get 
> the dreaded u-boot prompt. 

MLO and u-boot.img needs to be in the root directory of the boot device. 

It is actually internal microcode of the processor itself that fetches 
the MLO file, this process can't be modified externally. MLO contains 
code to set up the hardware which makes main RAM available, loads 
u-boot.img into this and executes it (more details at 
http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Two_stage_U-Boot_design).
 


Specific requirements are imposed on the MMC/SD boot devices (onboard 
MMC is interfaced as it was a SD-card) and the way they are setup to be 
able to load the MLO file, most importantly; 
"The image used by the booting procedure is taken from a specific 
booting file named “MLO”. This file has to be located in the root 
directory on an active primary partition of type FAT12/16 or FAT32." 
(details in chapter 26.1.7.5.6 of the AM335x Technical Reference 
Manual at http://www.ti.com/lit/pdf/spruh73). 


When experimenting with u-boot, it can be confusing to have multiple 
sets of MLO/u-boot.img on MMC and external SD. To assure that boot 
always occur from the set on the SD-card, you can rename the MLO file in 
the root of the onboard MMC. This way boot will fail when the processor 
determines MMC bootability in the boot order and the SD-card is always 
used. 


> Thinking about it hardwiring the Rx line might also prevent issues 
>  after the startup. It is certainly not ideal if there are ghost 
> characters coming from the serial part even after startup?! 

That would be bad. In my experience it is not an issue after powerup. 
I think the spurious character(s) are caused by conditions during 
early power up that can cause fluctuations on UART0_RX which are 
buffered in the uart until somebody (like u-boot) looks for it. 

Removing the buffer chip U15 gets rid of them 
(
http://www.mikini.dk/index.php/2014/10/beaglebone-black-periodic-boot-failure-establishing-failure-rate-and-possible-cause),
 

so maybe it is a question of driving 1OE_ input of U15 appropriately 
timed to when the am3358 uart behind UART0_RX is ready? 

> If I am extremely lucky (so far my BBB experience has been a very 
> rocky road ...) this a

Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[peterlarsen8600]

Hi again :)

quick follow up. I did the recompile-uboot-solution.
Found 
https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot
 
which described the process pretty well. A lot easier than worst fears :)
I just picked the latest version of U-Boot from the DENX repo, checked out 
the v2015.04 and applied latest patches from RCN (also in the fine guide).
Without using Mikkels patch-file, I then compiled and put on the newly 
built MLO and u-boot.img.

Luckily the recompiled U-Boot now lets the BBB and Ubuntu OS start up 
without (critical) errors. I have been powercycling the BBB all day and not 
a single "can't start"-issue.

Haven't digged much deeper into Mikkels patch and the repo version+RCN 
patch but could very well be that either U-Boot or RCN's patch fixes what 
Mikkels did.

Will stay on the cycle, fingers crossed and keep you posted. Thanks again 
for sharing!

cheers 

Peter
Den mandag den 8. juni 2015 kl. 21.00.41 UTC+2 skrev peterla...@gmail.com:
>
> Hi guys
>
> thank you all for putting your thoughts and experience online. I have the 
> exact same issue as discussed here.
> Running RCN's latest Ubuntu image on BBB rev C. 
>
> After reading Mikkels detailed reply, I tried out the/his compiled version 
> om U-boot. Might save some time instead of having to patch and recompile.
> Sadly the BBB did not event start after this :) Luckily booting up with SD 
> card, copying back my backup (!!) to the EMMC, got it back to normal.
> Consulting Mikkel in private, he adviced me to debug using the serial port 
> J1 with a TTL/USB dongle 5V. I used Putty for terminal connection at 
> 115.200 baud.
> Now output of "before" OS startup showed up and the debug process can be 
> initiated - yay.
>
> This is the output:
>
> U-Boot SPL 2015.01-00160-gbd5053f-dirty (Jan 15 2015 - 15:06:38)
> reading args
> spl_load_image_fat_os: error reading image args, err - -1
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2015.01-00160-gbd5053f-dirty (Jan 15 2015 - 15:06:38)
>
>Watchdog enabled
> I2C:   ready
> DRAM:  512 MiB
> NAND:  0 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Error - No Valid Environment Area found
> *** Warning - bad CRC, using default environment
>
> Net:not set. Validating first E-fuse MAC
> cpsw, usb_ether
> autoboot in 5 seconds (type 'stop' to abort)
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> switch to partitions #0, OK
> mmc1(part 0) is current device
> SD/MMC found on device 1
> reading boot.scr
> ** Unable to read file boot.scr **
> reading uEnv.txt
> ** Unable to read file uEnv.txt **
> ** File not found /boot/zImage **
> Booting from nand ...
>
> no devices available
>
> no devices available
> Bad Linux ARM zImage magic!
> U-Boot#
>
> Might be obious to someone what the fix is. Mikkel adviced to do the 
> patch/recompile of the U-Boot so unless a quick'n'dirty trick is to be 
> suggested, I'll get on with that.
>
> cheers
>
> Peter
>
>
>
>
>
> Den torsdag den 4. juni 2015 kl. 13.50.13 UTC+2 skrev Mikkel Kirkgaard 
> Nielsen:
>>
>> -BEGIN PGP SIGNED MESSAGE- 
>> Hash: SHA1 
>>
>> Hello Ivan & Chris. 
>>
>> I've also struggled with BBB boot reliability and done extensive 
>> testing using different hardware fixes as I thought (and still thinks) 
>> this ought to be resolved close to hardware. Read about it at 
>> http://www.mikini.dk/index.php/category/beaglebone-black/boot-issue. 
>>
>> A patch and build of u-boot mainline (from January) can be found at 
>>
>> http://www.mikini.dk/index.php/2015/01/beaglebone-black-periodic-boot-failure-patching-mainline-u-boot.
>>  
>>
>> It looks for a specific string ("stop") to break boot and dump into 
>> the u-boot prompt, instead of any one character. 
>>
>>
>> On 2015-06-04 00:26, ivan.wu...@gmail.com wrote: 
>> > I would have hoped for the software solution to work - I also 
>> > tested copying u-boot.img and MLO to /boot/uboot but I still get 
>> > the dreaded u-boot prompt. 
>>
>> MLO and u-boot.img needs to be in the root directory of the boot device. 
>>
>> It is actually internal microcode of the processor itself that fetches 
>> the MLO file, this process can't be modified externally. MLO contains 
>> code to set up the hardware which makes main RAM available, loads 
>> u-boot.img into this and executes it (more details at 
>>
>> http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Two_stage_U-Boot_design).
>>  
>>
>>
>> Specific requirements are imposed on the MMC/SD boot devices (onboard 
>> MMC is interfaced as it was a SD-card) and the way they are setup to be 
>> able to load the MLO file, most importantly; 
>> "The image used by the booting procedure is taken from a specific 
>> booting file named “MLO”. This file has to be located in the root 
>> directory on an active primary partition of type FAT12/16 or FAT32." 
>> (details in chapter 26.1.7.5.6 of the AM335x Technical Reference 
>> Manual at http://www.ti.com/lit

Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Colin Bester]

Please let us know how the jumping RX to 3V3 line works out. If I recall 
correctly, the RX line is pulled down to ground which didn't make sense to 
me as generally an asserted RX state is considered idle (if memory serves 
me correctly). What resistance are you using? Modifying u-boot is not 
something I want to do if I don't have to.


On Wednesday, June 3, 2015 at 2:04:29 PM UTC-5, AQG Chris wrote:
>
> We are dealing with the same issue - we found another complaint of the 
> same thing, in which the user identifies phantom characters on the UART 
> during startup causing the board to go into u-boot.  If you don't have a 
> display attached or a serial connection available, u-boot looks a lot like 
> a solid power LED and nothing else.  link to that thread:
> http://andicelabs.com/2014/07/beaglebone-black-boot-issues/
>
> That user apparently was able to modify u-boot to look for a certain 
> character instead of any keystroke.  In the limiting testing I've done, it 
> seems that the problem also doesn't occur if you have a serial connection 
> hooked up to UART0.  I'm now experimenting with jumping the RX line of 
> UART0 to 3.3v, and so far haven't had the issue again.
>
>>
>>

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[ivan . wunderlin]

Jumping Rx to 3V3 pretty much solved the problem for me. 

Why only "pretty much"? Well - I actually installed my first project on a 
customer site. This project consists of 12 boards communicating back to a 
management system. Because of the issue with the eth0 occasionally not 
reconnecting (e.g. after the switch is restarted) I added safety code that 
restarts the board if there is no communication back to the management 
system for 120s.

The system has been running perfectly for 2 months - but last week the 
customer accidentally switched the management system off (power button 
pressed; I've since disabled that button). The problem was only detected 
after 4 days - so all 12 boards kept restarting for 4 days. This resulted 
in roughly 30,000 restarts. After the management system was finally 
switched back on 2 boards did not establish communication. I had to go on 
site (luckily it is in the same city) and found that the 2 boards did not 
start up. So 2 failed restarts out of 30,000 - even with Rx connected 
straight to 3V3.

I have to admit that I now look into other options (other than the BBB) 
because as much as I like it I cannot use a HW platform that a.) does not 
start up 100.00% reliably (even after manual modifications that should not 
be necessary in the 1st place) and that b.) that does not always connect 
back to the switch. I am scratching my head a little bit why the BBB team 
does not fix those issues as they are not exactly disputed. It is clear 
enough that the BBB does have a serious reboot issue (as this thread 
certainly proves). Even worse is the issue with eth0 not always 
re-connecting if static IP configuration is used. Just in case somebody 
wonders if I really implemented all fixes suggested in the various forums - 
this is what I've done for all 12 boards for my 1st project:

  Soldered Rx to 3V3 (much improved the restart issue but still 2 out of 
30,000 restarts fail)
  Installed latest Debian image  
  Updated Kernel to latest version
  Removed apache service
  Removed DHCP service
  Removed wicd service
  Disabled lightdm (my applications doesn't need it)
  Disabled HDMI (my applications doesn't need it)
  Adjusted /etc/interfaces (set static IP for eth0)

Note that ifconfig shows the correct IP address when the issue with eth0 
not connecting happens.

So yeah - the BBB seems to be a great board but unfortunately not reliable 
enough for 24*7 unattended operation. And I really cannot spend more time 
on trouble shooting - I have enough work at my hands with the actual 
application so I need a platform that works out of the box.

On Thursday, 13 August 2015 01:13:08 UTC+10, Colin Bester wrote:
>
> Please let us know how the jumping RX to 3V3 line works out. If I recall 
> correctly, the RX line is pulled down to ground which didn't make sense to 
> me as generally an asserted RX state is considered idle (if memory serves 
> me correctly). What resistance are you using? Modifying u-boot is not 
> something I want to do if I don't have to.
>
>

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Robert Nelson]

On Wed, Aug 12, 2015 at 6:35 PM,   wrote:
> Jumping Rx to 3V3 pretty much solved the problem for me.
>
> Why only "pretty much"? Well - I actually installed my first project on a
> customer site. This project consists of 12 boards communicating back to a
> management system. Because of the issue with the eth0 occasionally not
> reconnecting (e.g. after the switch is restarted) I added safety code that
> restarts the board if there is no communication back to the management
> system for 120s.
>
> The system has been running perfectly for 2 months - but last week the
> customer accidentally switched the management system off (power button
> pressed; I've since disabled that button). The problem was only detected
> after 4 days - so all 12 boards kept restarting for 4 days. This resulted in
> roughly 30,000 restarts. After the management system was finally switched
> back on 2 boards did not establish communication. I had to go on site
> (luckily it is in the same city) and found that the 2 boards did not start
> up. So 2 failed restarts out of 30,000 - even with Rx connected straight to
> 3V3.
>
> I have to admit that I now look into other options (other than the BBB)
> because as much as I like it I cannot use a HW platform that a.) does not
> start up 100.00% reliably (even after manual modifications that should not
> be necessary in the 1st place) and that b.) that does not always connect
> back to the switch. I am scratching my head a little bit why the BBB team
> does not fix those issues as they are not exactly disputed. It is clear
> enough that the BBB does have a serious reboot issue (as this thread
> certainly proves). Even worse is the issue with eth0 not always
> re-connecting if static IP configuration is used. Just in case somebody
> wonders if I really implemented all fixes suggested in the various forums -
> this is what I've done for all 12 boards for my 1st project:
>
>   Soldered Rx to 3V3 (much improved the restart issue but still 2 out of
> 30,000 restarts fail)
>   Installed latest Debian image
>   Updated Kernel to latest version
>   Removed apache service
>   Removed DHCP service
>   Removed wicd service
>   Disabled lightdm (my applications doesn't need it)
>   Disabled HDMI (my applications doesn't need it)
>   Adjusted /etc/interfaces (set static IP for eth0)
>
> Note that ifconfig shows the correct IP address when the issue with eth0 not
> connecting happens.
>
> So yeah - the BBB seems to be a great board but unfortunately not reliable
> enough for 24*7 unattended operation. And I really cannot spend more time on
> trouble shooting - I have enough work at my hands with the actual
> application so I need a platform that works out of the box.

Please confirm which kernel your running:

uname -r

There's a big thread on this list, where a bunch spend about 2 weeks
bisecting the v4.1.x kernel to find the cause of the "random" reboot..

sudo apt-get update
sudo apt-get install linux-image-4.1.4-ti-r9
sudo reboot

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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[ivan . wunderlin]

Hi Robert,

> Please confirm which kernel your running

3.8.13-bone71 (updated beginning of last June)

> There's a big thread on this list, where a bunch spend about 2 weeks 
bisecting the v4.1.x kernel to find the cause of the "random" reboot.. 

I don't have an issue though with random reboots - the reboots are 
initiated on purpose by my application (because of the eth0 problem) - but 
as described 2 in 30,000 reboots failed.

Cheers,
Ivan

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Colin Bester]

In my case I am running 3.8.13-bone68 and system is pretty darn solid if it 
does start up. I have not seen Ethernet fail nor have I had any random 
reboots, but occasional I do have a device not power up when power is 
applied. We have not been able to determine a consistent cause and I am not 
convinced it's due to the mentioned RX pin as I am pretty sure I saw that 
this pin is pulled low (which I still think is wrong polarity) on rev C 
boards.

In addition, we have physically blocked off the PWR button and only expose 
the reset button via a small pin hole in our enclosure.



On Thursday, August 13, 2015 at 5:42:23 PM UTC-5, ivan.wu...@gmail.com 
wrote:
>
> Hi Robert,
>
> > Please confirm which kernel your running
>
> 3.8.13-bone71 (updated beginning of last June)
>
> > There's a big thread on this list, where a bunch spend about 2 weeks 
> bisecting the v4.1.x kernel to find the cause of the "random" reboot.. 
>
> I don't have an issue though with random reboots - the reboots are 
> initiated on purpose by my application (because of the eth0 problem) - but 
> as described 2 in 30,000 reboots failed.
>
> Cheers,
> Ivan
>
>

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[AQG Chris]

I'll chime in again too - we originally tested our 3v3-rx jumper with a 
direct connection, but then decided it might be nice to keep the ability to 
use the serial debug port.  Right now we've got a 470 ohm resistor pulling 
rx up, which seems to allow communication over serial still.  We also tried 
values of 220 through 1kohm and were still able to send characters to 
uart0.  100 ohm was too low to send anything over serial.  I've not done 
extensive reboot testing yet with each of these, but we will likely settle 
on either 470 or 1kohm.

If you probe the RX pin of the BB with nothing attached, we find 0v.  The 
TX pin (both on the BB and on the FTDI board we attach to the BB) is at 
3.3v by default, and we've also noticed that the problem never occurs when 
we're hooked up to uart0 with our FTDI chip adapter.  That made pulling the 
line up rather than down an attractive option.  We did try pulling RX down 
to ground at some point, but the very first test I did after that resulted 
in power LED on but no boot.

We still haven't done a mass deployment, so for now I'm taking our smaller 
testing runs and experiences like Ivan's to guide us.  Sidenote - yes, we 
have noticed eth0 not showing up as well, although it's not critical for 
our application.

On Thursday, August 13, 2015 at 4:04:34 PM UTC-7, Colin Bester wrote:
>
> In my case I am running 3.8.13-bone68 and system is pretty darn solid if 
> it does start up. I have not seen Ethernet fail nor have I had any random 
> reboots, but occasional I do have a device not power up when power is 
> applied. We have not been able to determine a consistent cause and I am not 
> convinced it's due to the mentioned RX pin as I am pretty sure I saw that 
> this pin is pulled low (which I still think is wrong polarity) on rev C 
> boards.
>
> In addition, we have physically blocked off the PWR button and only expose 
> the reset button via a small pin hole in our enclosure.
>
>
>
> On Thursday, August 13, 2015 at 5:42:23 PM UTC-5, ivan.wu...@gmail.com 
> wrote:
>>
>> Hi Robert,
>>
>> > Please confirm which kernel your running
>>
>> 3.8.13-bone71 (updated beginning of last June)
>>
>> > There's a big thread on this list, where a bunch spend about 2 weeks 
>> bisecting the v4.1.x kernel to find the cause of the "random" reboot.. 
>>
>> I don't have an issue though with random reboots - the reboots are 
>> initiated on purpose by my application (because of the eth0 problem) - but 
>> as described 2 in 30,000 reboots failed.
>>
>> Cheers,
>> Ivan
>>
>>

-- 
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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Andrew Glen]

For what it's worth, I run hundreds of 24/7 unattended systems with the
BBB. We have tested reboots into the tens of thousands, and with some work
we are able to achieve zero failures.

Off the top of my head here are the key platform specific things I do that
you might want to look at:

1) Mod the h/w to avoid the Ethernet issue (from another post) (this may be
fixed in the latest kernel, but we locked the s/w down a while back.
2) Use a custom u-boot to avoid the uart boot issue.
3) Configure the file system as read only (perform all app-level
read/writes on a separate partition).
4) Disable all journaling/logging, etc, except to temporary ramfs.
4) Force fsck to run and auto-recover on each boot (this was prior to
running read-only, may not be necessary now).
5) Remove all unneeded processes.
6) Enable the watchdog.
7) Use 'allow-hotplug' on the ethernet connection.
8) There was an issue with USB mounting causing the CAN bus to fail, but
this was resolved with a patch to the kernel I submitted a year or so ago.
Prior to the fix I had a script checking for a failure and re-init'ing as
necesary.

Have you been able to ascertain how the boot sequence fails, e.g. run 30k
reboots and record serial output?

Cheers,
Andrew.


On 14 August 2015 at 10:14,  wrote:

> Hi Robert,
>
> > Please confirm which kernel your running
>
> 3.8.13-bone71 (updated beginning of last June)
>
> > There's a big thread on this list, where a bunch spend about 2 weeks
> bisecting the v4.1.x kernel to find the cause of the "random" reboot..
>
> I don't have an issue though with random reboots - the reboots are
> initiated on purpose by my application (because of the eth0 problem) - but
> as described 2 in 30,000 reboots failed.
>
> Cheers,
> Ivan
>
> --
> 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/aXv6An1xfqI/unsubscribe.
> To unsubscribe from this group and all its topics, 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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Colin Bester]

I just took a look at Rev C schematics and there is a 100K pulldown on the RX 
pin so I wouldn’t have expected pulling directly to ground to make it any 
worse. All in all 100K is not much of a pull down, but I do agree that pull up 
is what you want - that at least is idle state on a serial line (from what I 
recall). My gut feel would be to use around a 3K resistor would should allow 
plenty headroom for hooking up a serial monitor if you ever wanted to - its a 
real pity that there is no convenient 3V3 on the monitor header.

~C

> On Aug 13, 2015, at 6:25 PM, AQG Chris  wrote:
> 
> I'll chime in again too - we originally tested our 3v3-rx jumper with a 
> direct connection, but then decided it might be nice to keep the ability to 
> use the serial debug port.  Right now we've got a 470 ohm resistor pulling rx 
> up, which seems to allow communication over serial still.  We also tried 
> values of 220 through 1kohm and were still able to send characters to uart0.  
> 100 ohm was too low to send anything over serial.  I've not done extensive 
> reboot testing yet with each of these, but we will likely settle on either 
> 470 or 1kohm.
> 
> If you probe the RX pin of the BB with nothing attached, we find 0v.  The TX 
> pin (both on the BB and on the FTDI board we attach to the BB) is at 3.3v by 
> default, and we've also noticed that the problem never occurs when we're 
> hooked up to uart0 with our FTDI chip adapter.  That made pulling the line up 
> rather than down an attractive option.  We did try pulling RX down to ground 
> at some point, but the very first test I did after that resulted in power LED 
> on but no boot.
> 
> We still haven't done a mass deployment, so for now I'm taking our smaller 
> testing runs and experiences like Ivan's to guide us.  Sidenote - yes, we 
> have noticed eth0 not showing up as well, although it's not critical for our 
> application.
> 
> On Thursday, August 13, 2015 at 4:04:34 PM UTC-7, Colin Bester wrote:
> In my case I am running 3.8.13-bone68 and system is pretty darn solid if it 
> does start up. I have not seen Ethernet fail nor have I had any random 
> reboots, but occasional I do have a device not power up when power is 
> applied. We have not been able to determine a consistent cause and I am not 
> convinced it's due to the mentioned RX pin as I am pretty sure I saw that 
> this pin is pulled low (which I still think is wrong polarity) on rev C 
> boards.
> 
> In addition, we have physically blocked off the PWR button and only expose 
> the reset button via a small pin hole in our enclosure.
> 
> 
> 
> On Thursday, August 13, 2015 at 5:42:23 PM UTC-5, ivan.wu...@gmail.com <> 
> wrote:
> Hi Robert,
> 
> > Please confirm which kernel your running
> 
> 3.8.13-bone71 (updated beginning of last June)
> 
> > There's a big thread on this list, where a bunch spend about 2 weeks 
> > bisecting the v4.1.x kernel to find the cause of the "random" reboot.. 
> 
> I don't have an issue though with random reboots - the reboots are initiated 
> on purpose by my application (because of the eth0 problem) - but as described 
> 2 in 30,000 reboots failed.
> 
> Cheers,
> Ivan
> 
> 
> -- 
> 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/aXv6An1xfqI/unsubscribe 
> .
> To unsubscribe from this group and all its topics, 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] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Gerald Coley]

3,3V and 5V shorted together would most certainly have been something
undesirable. Pity that the FTDI only puts out 5V on that header and not a
voltage level that is the same as the signal level.

The purpose of the buffer which was to prevent current coming from the the
FTDI signals and powering the processor when power was off and the FTDI
cable was still plugged in. It actually made it worse when we tried a
pullup. So the weak pulldown was a compromise.

If we ever do another revision, which is doubtful with all those clones out
there, I would consider adding a pullup on the other side of the buffer
again and see if we can get it to work.

You could create a pullup by using  a voltage divider between the 5V rail
and ground and connecting your pullup to that.

Or you can add look at adding pullup via SW on the RX pin.

Gerald


On Thu, Aug 13, 2015 at 6:38 PM, Colin Bester 
wrote:

> I just took a look at Rev C schematics and there is a 100K pulldown on the
> RX pin so I wouldn’t have expected pulling directly to ground to make it
> any worse. All in all 100K is not much of a pull down, but I do agree that
> pull up is what you want - that at least is idle state on a serial line
> (from what I recall). My gut feel would be to use around a 3K resistor
> would should allow plenty headroom for hooking up a serial monitor if you
> ever wanted to - its a real pity that there is no convenient 3V3 on the
> monitor header.
>
> ~C
>
> On Aug 13, 2015, at 6:25 PM, AQG Chris  wrote:
>
> I'll chime in again too - we originally tested our 3v3-rx jumper with a
> direct connection, but then decided it might be nice to keep the ability to
> use the serial debug port.  Right now we've got a 470 ohm resistor pulling
> rx up, which seems to allow communication over serial still.  We also tried
> values of 220 through 1kohm and were still able to send characters to
> uart0.  100 ohm was too low to send anything over serial.  I've not done
> extensive reboot testing yet with each of these, but we will likely settle
> on either 470 or 1kohm.
>
> If you probe the RX pin of the BB with nothing attached, we find 0v.  The
> TX pin (both on the BB and on the FTDI board we attach to the BB) is at
> 3.3v by default, and we've also noticed that the problem never occurs when
> we're hooked up to uart0 with our FTDI chip adapter.  That made pulling the
> line up rather than down an attractive option.  We did try pulling RX down
> to ground at some point, but the very first test I did after that resulted
> in power LED on but no boot.
>
> We still haven't done a mass deployment, so for now I'm taking our smaller
> testing runs and experiences like Ivan's to guide us.  Sidenote - yes, we
> have noticed eth0 not showing up as well, although it's not critical for
> our application.
>
> On Thursday, August 13, 2015 at 4:04:34 PM UTC-7, Colin Bester wrote:
>>
>> In my case I am running 3.8.13-bone68 and system is pretty darn solid if
>> it does start up. I have not seen Ethernet fail nor have I had any random
>> reboots, but occasional I do have a device not power up when power is
>> applied. We have not been able to determine a consistent cause and I am not
>> convinced it's due to the mentioned RX pin as I am pretty sure I saw that
>> this pin is pulled low (which I still think is wrong polarity) on rev C
>> boards.
>>
>> In addition, we have physically blocked off the PWR button and only
>> expose the reset button via a small pin hole in our enclosure.
>>
>>
>>
>> On Thursday, August 13, 2015 at 5:42:23 PM UTC-5, ivan.wu...@gmail.com
>> wrote:
>>>
>>> Hi Robert,
>>>
>>> > Please confirm which kernel your running
>>>
>>> 3.8.13-bone71 (updated beginning of last June)
>>>
>>> > There's a big thread on this list, where a bunch spend about 2 weeks
>>> bisecting the v4.1.x kernel to find the cause of the "random" reboot..
>>>
>>> I don't have an issue though with random reboots - the reboots are
>>> initiated on purpose by my application (because of the eth0 problem) - but
>>> as described 2 in 30,000 reboots failed.
>>>
>>> Cheers,
>>> Ivan
>>>
>>>
> --
> 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/aXv6An1xfqI/unsubscribe.
> To unsubscribe from this group and all its topics, 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 opti

Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Dr. Michael J. Chudobiak]

On 08/13/2015 07:28 PM, Andrew Glen wrote:

For what it's worth, I run hundreds of 24/7 unattended systems with the
BBB. We have tested reboots into the tens of thousands, and with some
work we are able to achieve zero failures.

Off the top of my head here are the key platform specific things I do
that you might want to look at:

1) Mod the h/w to avoid the Ethernet issue (from another post) (this may
be fixed in the latest kernel, but we locked the s/w down a while back.


Andrew,

Could you elaborate on what hardware changes you made to fix the 
ethernet issue?


- Mike

--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[evilwulfie]

IF not using USB ground Vusb been working for me.


On 8/24/2015 11:33 AM, Dr. Michael J. Chudobiak wrote:
> On 08/13/2015 07:28 PM, Andrew Glen wrote:
>> For what it's worth, I run hundreds of 24/7 unattended systems with the
>> BBB. We have tested reboots into the tens of thousands, and with some
>> work we are able to achieve zero failures.
>>
>> Off the top of my head here are the key platform specific things I do
>> that you might want to look at:
>>
>> 1) Mod the h/w to avoid the Ethernet issue (from another post) (this may
>> be fixed in the latest kernel, but we locked the s/w down a while back.
>
> Andrew,
>
> Could you elaborate on what hardware changes you made to fix the
> ethernet issue?
>
> - Mike
>

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