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
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
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
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.
On Wed, Aug 12, 2015 at 6:35 PM, ivan.wunder...@gmail.com 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.
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 -
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
-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
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
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
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
-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
On Fri, Jan 16, 2015 at 9:45 AM, Mikkel Kirkgaard Nielsen
m...@mikini.dk 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
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
-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
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
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
30 matches
Mail list logo
