6165 2014-04-15 17:24:27 +0000 Beaglebone does not boot - hangs at Starting kernel 2014-06-18 07:36:25 +0000 1 1 11 Runtime System Startup system-startup 1.6 BeagleBone arm VERIFIED FIXED Release note for 1.6 Medium+ major 1.6.1 1 sstncr denis denis jessica.zhang kevin.tian sgw wmills yi.zhao --- --- No (bug/feature does not impact docs) oldest_to_newest 42685 0 sstncr 2014-04-15 17:24:27 +0000 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 42717 1 jessica.zhang 2014-04-17 14:52:10 +0000 Also, please add sanity test for path length 42723 2 denis 2014-04-17 20:14:43 +0000 The fix has been submitted to the list. 42724 3 wmills 2014-04-17 21:28:58 +0000 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 42796 4 denis 2014-04-19 17:47:30 +0000 The patch has been applied to OE-Core. 44055 5 yi.zhao 2014-06-18 07:36:25 +0000 Verified with 1.6.1 and master branch.