Unable to boot beagle bone black from prebuilt image #3 (hardware A5A, empty emmc)

[Zygmunt Krynicki]

Hi

Using instructions from [1] and the image downloaded there [2] (corresponding to the -3rd update) I get a non-booting device. Logs from the serial console contain just this [3]

[1] http://developer.ubuntu.com/en/snappy/start/
[2] http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf-bbb.img.xz
[3] http://pastebin.ubuntu.com/11696123/

NOTE: The same board was running the previous image successfully. Update process failed and after that I wiped the card and started over with the fresh image.

[Zygmunt Krynicki (zyga)]

zyga@virtual-fx:/media/zyga/system-boot$ ls -lR
.:
razem 4,0K
drwxr-xr-x 3 zyga zyga 512 cze 11 04:14 a/
drwxr-xr-x 3 zyga zyga 512 cze 11 04:14 b/
-rw-r--r-- 1 zyga zyga 1,6K cze 11 04:14 snappy-system.txt
drwxr-xr-x 2 zyga zyga 512 cze 11 2015 System Volume Information/
-rw-r--r-- 1 zyga zyga 237 cze 11 04:14 uEnv.txt

./a:
razem 20M
drwxr-xr-x 2 zyga zyga 512 cze 11 04:14 dtbs/
-rw-r--r-- 1 zyga zyga 114 cze 11 04:14 hardware.yaml
-rw-r--r-- 1 zyga zyga 13M cze 11 04:14 initrd.img
-rw-r--r-- 1 zyga zyga 6,3M cze 11 04:14 vmlinuz

./a/dtbs:
razem 30K
-rw-r--r-- 1 zyga zyga 30K cze 11 04:14 am335x-boneblack.dtb

./b:
razem 20M
drwxr-xr-x 2 zyga zyga 512 cze 11 04:14 dtbs/
-rw-r--r-- 1 zyga zyga 114 cze 11 04:14 hardware.yaml
-rw-r--r-- 1 zyga zyga 13M cze 11 04:14 initrd.img
-rw-r--r-- 1 zyga zyga 6,3M cze 11 04:14 vmlinuz

./b/dtbs:
razem 30K
-rw-r--r-- 1 zyga zyga 30K cze 11 04:14 am335x-boneblack.dtb

./System Volume Information:
razem 512
-rw-r--r-- 1 zyga zyga 76 cze 11 2015 IndexerVolumeGuid

[Zygmunt Krynicki (zyga)]

With this card inside, my beagle (doesn't) boot with the following console:

U-Boot SPL 2014.10-dirty (Dec 18 2014 - 22:07:26)
MMC: block number 0x100 exceeds max(0x0)
MMC: block number 0x200 exceeds max(0x0)
*** Error - No Valid Environment Area found
Using default environment

U-Boot 2014.10-dirty (Dec 18 2014 - 22:07:26)

       Watchdog enabled
I2C: ready
DRAM: 512 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
reading boot.scr
** Unable to read file boot.scr **
reading uEnv.txt
237 bytes read in 3 ms (77.1 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
** File not found snappy-system.txt **
## Error: "snappy_boot" not defined
** File not found /boot/zImage **
switch to partitions #0, OK
mmc1(part 0) is current device
SD/MMC found on device 1
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Running uenvcmd ...
** No partition table - mmc 1 **
## Error: "snappy_boot" not defined
** No partition table - mmc 1 **
## Error: "nandboot" not defined

[Zygmunt Krynicki (zyga)]

The boot meta-data for me is on partition 1 of mmc 0:

U-Boot# fatls mmc 0:1
            b/
            a/
      237 uenv.txt
     1585 snappy-system.txt
            system volume information/

2 file(s), 3 dir(s)

[Zygmunt Krynicki (zyga)]

This bug seems to be caused by incorrect defaults and lack of any overrides in uEnv.txt. I'll post updates soon. My theory is that it works for people that kept Debian on the eMMC (I erased it).

[Paul Larson (pwlars)]

As it turns out, we are only accidentally booting snappy because of a weird uboot config that is in the images (like debian) produced by rcn. I was looking at this a while back and was very confused as to why snappy booted, even if I didn't hold down the s2 button. The s2 button is *supposed* to be required for booting from the sd card. What's actually getting controlled by that though, is where it reads the bootloader. Anything after that is up to the scripts. So if you boot snappy on a bbb and do *not* hold the s2 button, you are still using the MLO and uboot off of the emmc.

[Zygmunt Krynicki (zyga)]

Yep. I totally agree. The merge request I've sent fixes defaults.

[Michael Vogt (mvo)]

This is fixed now