[yocto] BBB doesn't boot

Tue Apr 15 09:26:39 PDT 2014

On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
> > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > > > > Very interesting results!  These are the results from the 
> build hosts I have:
> > > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > 
> > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > Fedora host - this is the first time I hear about issues with
> > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > more time...
> > > > > > > > 
> > > > > > > > I've been having a look at this. The biggest differences I can
> > > > > > > > find
> > > > > > > > between working and non working builds is the path length to the
> > > > > > > > build
> > > > > > > > directory for the kernel. This is from comparing vmlinux files
> > > > > > > > from
> > > > > > > > working and non working builds.
> > > > > > > > 
> > > > > > > > Works:
> > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > 
> > > > > > > > Doesn't Work:
> > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gn
> > > > > > > > ueabi
> > > > > > > > 
> > > > > > > > I also have been wondering if the version strings may be making
> > > > > > > > a
> > > > > > > > difference.
> > > > > > > > 
> > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build
> > > > > > > > where I
> > > > > > > > truncated the path length to a "working" build path length and
> > > > > > > > patched
> > > > > > > > in the same version strings:
> > > > > > > > 
> > > > > > > > const char linux_banner[] =
> > > > > > > > 
> > > > > > > >        "Linux version 3.14.0-yocto-standard
> > > > > > > >        (paul at ubuntu-build01) (gcc
> > > > > > > > 
> > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > 2014\n";
> > > > > > > > 
> > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > (paul at ubuntu-build01)
> > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > 
> > > > > > > > to init/version.c.
> > > > > > > > 
> > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > kernel
> > > > > > > > linked to above works or not. If it doesn't, it rules out these
> > > > > > > > path and
> > > > > > > > string lengths, if it does work, it points to a problem there.
> > > > > > > 
> > > > > > > Richard,
> > > > > > 
> > > > > > > Good catch! It boots:
> > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one
> > > > > > but
> > > > > > with my changes to version.c reverted. The one should tell us if its
> > > > > > the
> > > > > > paths or the strings.
> > > > > 
> > > > > This one also boots for me:
> > > > > 
> > > > > Linux version 3.14.0-yocto-standard (richard at ted) (gcc version 4.8.2
> > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > > 
> > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > possible.
> > > > > > This is starting to look like some kind of compiler or linker issue.
> > > > > > If
> > > > > > it is that, it would help to have more data points about what works
> > > > > > and
> > > > > > what doesn't. With that in mind could people who have good or bad
> > > > > > builds
> > > > > > please share the paths they built the kernels in so we can see if we
> > > > > > can
> > > > > > spot some kind of pattern.
> > > > 
> > > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and
> > > > it works.
> > > 
> > > I can confirm:
> > >  build dir in /home/stefans/b1  works,
> > > 
> > > but /home/stefans/yocto/poky/build doesn't.
> > 
> > But this works
> > [stefans at firebird bu]$ pwd
> > /home/stefans/yocto/poky/bu
> > [stefans at firebird bu]$ echo `pwd`| wc -c
> > 28
> > 
> > 
> > But 29 doesn't.
> > So, what now?
> 
> Some other things I tried with a "long" TMPDIR path (note that it's the TMPDIR 
> path that makes the difference - in my tests I've been using 
> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> 
> * 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
> 
> I think we're now at the point where we'd benefit from someone with better 
> knowledge debugging the issue.

Ok, should we expand the search area? Since this is supposed to be vanilla 
3.14 kernel, can we try other platforms and see if they are similarly 
affected? I'll try pinging our kernel guys for any ideas...

-- 
Denys