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.
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.
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
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
Mikini Services » boot issue.
A patch and build of u-boot mainline (from January) can be found at
Mikini Services» Blog Archive » 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.
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's_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
(Mikini Services» Blog Archive » 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
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
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
Problem still exist on Revision C
Why the BBB team do not recompile ufficially the uboot whit the solution ?
Problem still exist on Revision C
why BBB team do not recompile officially the uboot whit the solution ?
Hi,
Robert, in place of 2015-07-17 image, I see 2015-07-28 image. In any way, how it is fixed? I just tried to flash it to my BBB and I still can go into u-boot pressing any single key. Shouldn’t it be some key sequence like “uboot”?
Thanks,
Gediminas
Hi,
Just to make it clear. As I see there is no way to update u-boot without reflashing eMMC. Am I right?
Thanks in advance for an answer.
Regards,
Gediminas
Hi,
Robert, in place of 2015-07-17 image, I see 2015-07-28 image. In any way,
how it is fixed?
Just weekly build snapshots, look at the log for major changes:
I just tried to flash it to my BBB and I still can go into
u-boot pressing any single key. Shouldn't it be some key sequence like
"uboot"?
It's just a single key over the usart...
If it's not working, you more then likely have a version in eMMC not from me
Regards,
Yes, it’s single key. Thanks
Oh, i should mention, we can't change this from a single key, as
CircuitCo's testing equipment relies on this "feature".
Regards,
The system checks for MLO on the eMMC before the sd card. If you have updated u-boot/MLO on the sd card, but the ‘as shipped’ files are still present on the eMMC, your new files will have no effect.
To get rid of the files on the eMMC you don’t need to refashion it. Just boot the BBB, mount the eMMC partition, and delete MLO/u-boot.
On the next boot it will be using your updated boot loader files on the sd card.
Isn’t that why the boot switch exists ?
But my scripts can flick a switch:)
But my scripts can flick a switch:)
Point I was making is that I’m not sure it is wise to instruct people to remove the first or second stage bootloader from the eMMC. This typically leads to more problems than it solves . . .
Here are my instructions how to solve boot issue on eMMC (see one warning which I get below):
All commands should be run on BBB as root or add sudo.
Checkout and patch u-boot as described here: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot
Do not build yet.
nano configs/am335x_boneblack_defconfig
Add these lines to the end of the file:
CONFIG_AUTOBOOT_KEYED=y
CONFIG_AUTOBOOT_PROMPT="Autobooting in %d seconds, enter \"stop\" to stop\n"
CONFIG_AUTOBOOT_STOP_STR="stop"
CONFIG_AUTOBOOT_DELAY_STR="delay"
Then compile u-boot running these commands:
make ARCH=arm CROSS_COMPILE=${CC} distclean
make ARCH=arm CROSS_COMPILE=${CC} am335x_boneblack_defconfig
make ARCH=arm CROSS_COMPILE=${CC}
Now you should have u-boot.img and MLO files compiled.
Write them to eMMC boot calling these commands:
dd if=MLO of=/dev/mmcblk0 count=1 seek=1 conv=notrunc bs=128k
dd if=u-boot.img of=/dev/mmcblk0 count=2 seek=1 conv=notrunc bs=384k
Done. Try to restart. If you have serial connection, check if you will see message when BBB starts “Autobooting in 1 seconds, enter “stop” to stop”
Warning: After applying this I see warning when u-boot starts “*** Warning - bad CRC, using default environment”. By this warning description here (http://www.denx.de/wiki/view/DULG/WarningBadCRCUsingDefaultEnvironment) seems like it’s not critical or even important, but still, maybe someone has an idea how to solve it?
Thanks.
Gedas
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.