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