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: <ethaddr> 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, [email protected] <javascript:> 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.
