Bug 6165

Summary:	Beaglebone does not boot - hangs at Starting kernel
Product:	[Runtime] System Startup	Reporter:	Stefan Stanacar <sstncr>
Component:	system-startup	Assignee:	Denys Dmytriyenko <denis>
Status:	VERIFIED FIXED	QA Contact:
Severity:	major
Priority:	Medium+	CC:	denis, jessica.zhang, kevin.tian, sgw, wmills, yi.zhao
Version:	1.6
Target Milestone:	1.6.1
Hardware:	BeagleBone
OS:	arm
Whiteboard:	Release note for 1.6
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Stefan Stanacar 2014-04-15 17:24:27 UTC

Revisions and configs:

This was originally tested on poky master:ea90bd054c449a8e19c474c8bfa8c289f692c33f and poky daisy:0ba2239abb4917a1c090a7802211f2695c711a58

FWIW: no other layers or custom configs, just MACHINE=beaglebone:
Build Configuration:
BB_VERSION        = "1.22.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Fedora-20"
TARGET_SYS        = "arm-poky-linux-gnueabi"
MACHINE           = "beaglebone"
DISTRO            = "poky"
DISTRO_VERSION    = "1.6"
TUNE_FEATURES     = "armv7a vfp neon callconvention-hard cortexa8"
TARGET_FPU        = "vfp-neon"
meta              
meta-yocto        
meta-yocto-bsp    = "daisy:0ba2239abb4917a1c090a7802211f2695c711a58"

PROBLEM:

I have an BBB rev A6 (but there are reports of this for white too), that I've setup-ed according (emmc erased, etc) to the README.hardware with an AB image, that fails to boot.

Relevant serial log from failed kernel (one attached in the archive, same thing for the good one, just difference in size)

4985288 bytes read in 866 ms (5.5 MiB/s)
29192 bytes read in 36 ms (791 KiB/s)
Booting from mmc ...
## Booting kernel from Legacy Image at 80200000 ...
   Image Name:   Linux-3.14.0-yocto-standard
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4985224 Bytes = 4.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80f80000
   Booting using the fdt blob at 0x80f80000
   Loading Kernel Image ... OK
   Using Device Tree in place at 80f80000, end 80f8a207

Starting kernel ...


And that's all (so no Uncompressing Linux...)

Steps to reproduce:
  - download http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6_M5.rc4/machines/beaglebone/core-image-sato-beaglebone.tar.bz2 (it's easier if you don't get a minimal)
  - get the u-boot.img and MLO too
  - and deploy on your sdcard according to the README.hardware
  - try to boot and notice somthing similar to the above message

-------

Workaround:
  - bitbake linux-yocto, that is build your own kernel
but in a short build dir (length of TMPDIR matters to be more exact), that is setup oe-env in something like /home/user/b1 and copy the resulting uImage on the sdcard over /boot/uImage-3.14.0-yocto-standard, what the image originally had (you can keep the original dtbs, uboot, mlo, etc) - or use uImage-good from the attached archive
  -> it now boots
  -> you can go an build your own image/uboot or whatever it will still fail if the path to the build dir for the kernel is above a certain number, details below.

Details:
 There are reports of non-working or working kernels built on multiple distros by multiple people (different Fedora and Ubuntu versions) everything seems to point to length of the tmpdir path.

On the same machine, I did two kernel clean builds with same metadata/configs/etc, one that works, one that doesn't, the only difference being the build dir, as follows:

 WORKS: If I build in:
[stefans@firebird bu]$ pwd
/home/stefans/yocto/poky/bu
[stefans@firebird bu]$ pwd | wc -c
28
[stefans@firebird bu]$ cd tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux-beaglebone-standard-build/
[stefans@firebird linux-beaglebone-standard-build]$ pwd | wc -c
152

FAILS:
 /home/stefans/yocto/poky/bui (poky/bu vs poky/bui, 28 vs 29, 152 vs 153 for the build dir of the kernel)

The attached archive contains the two vmlinux and uImage resulted from each build, you can check the vmlinux for strings and notice the above paths.

Paul has also tested these with a long TMPDIR (that don't work):
* kernel built with gcc 4.7.2 and binutils 2.23.2
* u-boot built with gcc 4.7.2 and binutils 2.23.2
* u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
* earlyprintk and CONFIG_DEBUG_LL - no additional output printed
Also:
  - qemuarm boots just fine
  - edgerouter (mips arch but uses u-boot) boots just fine

The archive attached contains:
  - a good pair of: uImage from bu/tmp/deploy/bla and vmlinux from bu/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux-beaglebone-standard-build/vmlinux
  - a bad (non-booting) pair of uImage/vmlinux from bui/...

The size difference on disk is about 40 bytes between the uImage files (because of timestamps and paths that are probably recorded, hostname didn't change though).

The archive with the kernels: http://tinyurl.com/yoctobbkernels

Cheers,
Stefan

Comment 1 Jessica 2014-04-17 14:52:10 UTC

Also, please add sanity test for path length

Comment 2 Denys Dmytriyenko 2014-04-17 20:14:43 UTC

The fix has been submitted to the list.

Comment 3 Bill Mills 2014-04-17 21:28:58 UTC

Denys has submitted a patch to fix this.
However, in case someone find this bug report in the future, here is what was going on.

The uncompressed kernel + its bss,etc was overwriting the devicetree data.
This was happening as a simple mater of size.
The size of the build path was just the straw that broke it.
Removing a big feature would also have fixed it and adding another big feature would have made it not boot regardless of build path.

The patch fixes the default load address in u-boot.
You can verify you have the fix by checking that fdtaddr==0x88000000.
The old value was 0x80f80000.

For a quick hack using an old u-boot you can
add the following to uEnv.txt:
loadaddr=0x82000000
kernel_addr_r=0x82000000
fdtaddr=0x88000000
fdt_addr_r=0x88000000
rdaddr=0x88080000
ramdisk_addr_r=0x88080000
bootm_size=0x10000000

I verified that uImage-bad from http://tinyurl.com/yoctobbkernels
boots if I add the above or just add
fdtaddr=0x88000000

Comment 4 Denys Dmytriyenko 2014-04-19 17:47:30 UTC

The patch has been applied to OE-Core.

Comment 5 Yi Zhao 2014-06-18 07:36:25 UTC

Verified with 1.6.1 and master branch.