subject:"Re\: \[yocto\] BBB doesn't boot"

On 2014-04-15 03:03, 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-gnueabi

 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@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@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@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.

My paths:
  /local/bbb_yocto_2014-04-14 - works
  /home/local/bbb_yocto_2014-04-14 - fails
  /raid/work/tmp/bbb_yocto_2014-04-14 - fails
  /tmp/bbb_yocto_2014-04-15 - works
  /tmp/work/bbb_yocto_2014-04-15 - fails
  /tmp/w2/bbb_yocto_2014-04-15 - fails
  /tmp/w/bbb_yocto_2014-04-15 - works
Note: the last 5 were all built on the same host

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On 2014-04-15 05:52, Stanacar, StefanX wrote:
 
 
 
 On Tue, 2014-04-15 at 09:03 +, 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-gnueabi

 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@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@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@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@firebird bu]$ pwd
 /home/stefans/yocto/poky/bu
 [stefans@firebird bu]$ echo `pwd`| wc -c
 28
 
 
 But 29 doesn't.
 So, what now?

Hard to know, it might take debugging via JTAG to find out what's
happening since when it fails, it's so dead that nothing makes it
to the [dmesg] log buffer :-(

Sadly, I can't help much with this as I don't have a JTAG debug
setup for the BBB.

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Paul Eggleton

On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
 On Tue, 2014-04-15 at 09:03 +, 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@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@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@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@firebird bu]$ pwd
 /home/stefans/yocto/poky/bu
 [stefans@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.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Stoicescu, CorneliuX

 -Original Message-
 From: yocto-boun...@yoctoproject.org [mailto:yocto-
 boun...@yoctoproject.org] On Behalf Of Paul Eggleton
 Sent: Tuesday, April 15, 2014 5:50 PM
 To: yocto@yoctoproject.org
 Subject: Re: [yocto] BBB doesn't boot

 On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
  On Tue, 2014-04-15 at 09:03 +, 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-
 gnuea
bi

Doesn't Work:
/media/data1/build1/poky/build/tmp/work/beaglebone-poky-li
nux-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@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@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@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@firebird bu]$ pwd
  /home/stefans/yocto/poky/bu
  [stefans@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.

 Cheers,
 Paul

I don't know if this is helpful but this TMPDIR path size issue reminded me of 
a bug I verified some time ago: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3989

Regards,
Corneliu
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On 2014-04-15 09:15, Stoicescu, CorneliuX wrote:
 -Original Message-
 From: yocto-boun...@yoctoproject.org [mailto:yocto-
 boun...@yoctoproject.org] On Behalf Of Paul Eggleton
 Sent: Tuesday, April 15, 2014 5:50 PM
 To: yocto@yoctoproject.org
 Subject: Re: [yocto] BBB doesn't boot

 On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
 On Tue, 2014-04-15 at 09:03 +, 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-
 gnuea
 bi

 Doesn't Work:
 /media/data1/build1/poky/build/tmp/work/beaglebone-poky-li
 nux-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@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@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@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@firebird bu]$ pwd
 /home/stefans/yocto/poky/bu
 [stefans@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.

 Cheers,
 Paul

 I don't know if this is helpful but this TMPDIR path size issue reminded me 
 of a bug I verified some time ago: 
 https://bugzilla.yoctoproject.org/show_bug.cgi?id=3989

Probably not related since the only component which seems
to be having issues is the kernel (you can use a kernel which
boots with any file system, no matter the build path length)

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

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 +, 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@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@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@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@firebird bu]$ pwd
  /home/stefans/yocto/poky/bu
  [stefans@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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Paul Eggleton

On Tuesday 15 April 2014 12:26:39 Denys Dmytriyenko wrote:
 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 +, 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-linu
 x-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@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@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@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@firebird bu]$ pwd
   /home/stefans/yocto/poky/bu
   [stefans@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

Re: [yocto] BBB doesn't boot

On Tue, Apr 15, 2014 at 05:36:10PM +0100, Paul Eggleton wrote:
 On Tuesday 15 April 2014 12:26:39 Denys Dmytriyenko wrote:
  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 +, 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-linu
  x-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@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@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@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@firebird bu]$ pwd
/home/stefans/yocto/poky/bu
[stefans@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

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Stanacar, StefanX




On Tue, 2014-04-15 at 12:26 -0400, Denys Dmytriyenko wrote:
 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 +, 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@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@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@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@firebird bu]$ pwd
   /home/stefans/yocto/poky/bu
   [stefans@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

Re: [yocto] BBB doesn't boot

On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
 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...
   
   As far as I know it has only been observed with beaglebone (both white 
   and 
   black, if it makes a difference). FWIW, qemuarm images from the 
   autobuilder 
   boot just fine, and apparently the same is true of edgerouter (different 
   architecture but also uses u-boot).
  
  But do those other platforms use uImage or zImage?

I don't yet know what is going on, but building in the same directory with 
sources (B = S) makes it work regarless of the path length:

/OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

So, I just commented out setting kernel-specific B in linux-yocto.inc and any 
kernel now boots with long path:

#B = ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build

I'm copying Richard and Bruce directly to see if they may have a quick insight 
and/or accept it as a workaround for the release. I'll keep digging further, 
but if anyone cares to verify the above workaround works for them, I would 
appreciate. Thanks!

-- 
Denys
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On 2014-04-15 13:43, Denys Dmytriyenko wrote:
 On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
 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...

 As far as I know it has only been observed with beaglebone (both white and 
 black, if it makes a difference). FWIW, qemuarm images from the 
 autobuilder 
 boot just fine, and apparently the same is true of edgerouter (different 
 architecture but also uses u-boot).

 But do those other platforms use uImage or zImage?
 
 I don't yet know what is going on, but building in the same directory with 
 sources (B = S) makes it work regarless of the path length:
 
 /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
 
 So, I just commented out setting kernel-specific B in linux-yocto.inc and any 
 kernel now boots with long path:
 
 #B = ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build
 
 I'm copying Richard and Bruce directly to see if they may have a quick 
 insight 
 and/or accept it as a workaround for the release. I'll keep digging further, 
 but if anyone cares to verify the above workaround works for them, I would 
 appreciate. Thanks!
 

Verified - I rebuilt the kernel in a working tree with a longer
path (one in fact that had failed before) and it boots fine.

Wonder what ${B} != ${S} is doing wacky...?

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Bruce Ashfield


On 14-04-15 03:43 PM, Denys Dmytriyenko wrote:

On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:

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...


As far as I know it has only been observed with beaglebone (both white and
black, if it makes a difference). FWIW, qemuarm images from the autobuilder
boot just fine, and apparently the same is true of edgerouter (different
architecture but also uses u-boot).


But do those other platforms use uImage or zImage?


I don't yet know what is going on, but building in the same directory with
sources (B = S) makes it work regarless of the path length:

/OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

So, I just commented out setting kernel-specific B in linux-yocto.inc and any
kernel now boots with long path:

#B = ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build

I'm copying Richard and Bruce directly to see if they may have a quick insight
and/or accept it as a workaround for the release. I'll keep digging further,


I've never seen this before, and when I'm back in the office Wed/Thursday
I can have a closer look.

As for the BBB using this in the release, I really don't want to have
one board that breaks the build and source separation, since it has
always been in place to keep things clean (and I know of a few random
scripts, etc, that expect it) .. but more importantly, I want to root
cause this, since it is a lurking problem.

Bruce


but if anyone cares to verify the above workaround works for them, I would
appreciate. Thanks!



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Richard Purdie

On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
 I don't yet know what is going on, but building in the same directory with 
 sources (B = S) makes it work regarless of the path length:
 
 /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
 
 So, I just commented out setting kernel-specific B in linux-yocto.inc and any 
 kernel now boots with long path:
 
 #B = ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build
 
 I'm copying Richard and Bruce directly to see if they may have a quick 
 insight 
 and/or accept it as a workaround for the release. I'll keep digging further, 
 but if anyone cares to verify the above workaround works for them, I would 
 appreciate. Thanks!

I'm travelling and don't have hardware so I'm limited in what I can look
at right now. I suspect this workaround works because it makes the
beaglebone-standard-build extra characters on the path. I have a
feeling your -111 test above may have reused sstate or something
like that and given misleading results. I'd be interested in the vmlinux
file from the build above to see if the poky-11 pathnames are in
there (they get stripped out when you create the zImage).

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
I don't yet know what is going on, but building in the same directory with
sources (B = S) makes it work regarless of the path length:

/OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

So, I just commented out setting kernel-specific B in linux-yocto.inc and
any
kernel now boots with long path:

#B = ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build

http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard

--
Denys
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:
On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
I don't yet know what is going on, but building in the same directory
with
sources (B = S) makes it work regarless of the path length:

/OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

So, I just commented out setting kernel-specific B in linux-yocto.inc and
any
kernel now boots with long path:

#B = ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build

http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard

And, as a follow up, all those long paths in vmlinux when built with B != S
point to sources. Here are few examples:

B != S strings:

B = S same strings:

So, that explains why B = S works regardless of the location, as it doesn't
embed full path to source files...

--
Denys
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

2014-04-15 Thread Khem Raj

On Tue, Apr 15, 2014 at 6:20 PM, Denys Dmytriyenko de...@denix.org wrote:
On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:
On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
I don't yet know what is going on, but building in the same directory
with
sources (B = S) makes it work regarless of the path length:

/OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

So, I just commented out setting kernel-specific B in linux-yocto.inc
and any
kernel now boots with long path:

#B = ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build

http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard

And, as a follow up, all those long paths in vmlinux when built with B != S
point to sources. Here are few examples:

B != S strings:

B = S same strings:

So, that explains why B = S works regardless of the location, as it doesn't
embed full path to source files...

seemingly there could be rodata segment overflow issue. Can you do the
kernel build with say linker from dora build
and see if it still fails.

--
Denys
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On 2014-04-13 20:33, Denys Dmytriyenko wrote:
 On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
 I just tried building (core-image-sato) for my BeagleBoneBlack
 using the latest Poky/Yocto master:

 Build Configuration:
 BB_VERSION= 1.23.0
 BUILD_SYS = i686-linux
 NATIVELSBSTRING   = Fedora-13
 TARGET_SYS= arm-poky-linux-gnueabi
 MACHINE   = beaglebone
 DISTRO= poky
 DISTRO_VERSION= 1.6+snapshot-20140411
 TUNE_FEATURES = armv7a vfp neon callconvention-hard cortexa8
 TARGET_FPU= vfp-neon
 meta
 meta-yocto
 meta-yocto-bsp= master:863cc7483f5ee43189537940de8ee5c0964d24cc

 This built the kernel using SRCREV 928d7b2dda

 I followed the bring-up instructions from README.hadware and the
 boot failed to even start the kernel.  Here's what I see:

 === boot log 
 =
 U-Boot 2013.07 (Apr 11 2014 - 15:03:04)

 I2C:   ready
 DRAM:  512 MiB
 WARNING: Caches not enabled
 NAND:  0 MiB
 MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
 *** Warning - readenv() failed, using default environment

 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
 SoftConn)
 musb-hdrc: MHDRC RTL version 2.0
 musb-hdrc: setup fifo_mode 4
 musb-hdrc: 28/31 max ep, 16384/16384 memory
 USB Peripheral mode controller at 47401000 using PIO, IRQ 0
 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
 SoftConn)
 musb-hdrc: MHDRC RTL version 2.0
 musb-hdrc: setup fifo_mode 4
 musb-hdrc: 28/31 max ep, 16384/16384 memory
 USB Host mode controller at 47401800 using PIO, IRQ 0
 Net:   ethaddr not set. Validating first E-fuse MAC
 Phy not found
 PHY reset timed out
 cpsw, usb_ether
 Hit any key to stop autoboot:  0
 mmc0 is current device
 SD/MMC found on device 0
 reading uEnv.txt
 ** Unable to read file uEnv.txt **
 4981688 bytes read in 613 ms (7.7 MiB/s)
 29192 bytes read in 46 ms (619.1 KiB/s)
 Booting from mmc ...
 ## Booting kernel from Legacy Image at 8020 ...
Image Name:   Linux-3.14.0-yocto-standard
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:4981624 Bytes = 4.8 MiB
Load Address: 80008000
Entry Point:  80008000
Verifying Checksum ... OK
 ## Flattened Device Tree blob at 80f8
Booting using the fdt blob at 0x80f8
Loading Kernel Image ... OK
Using Device Tree in place at 80f8, end 80f8a207

 Starting kernel ...
 ==

 Any ideas what I've done wrong?
 
 Hmm, everything looks sane. What revision is your BBB? And did you press 
 USER/BOOT button or erased eMMC partition per instructions?
 

Revision A5A, with an LCD cape

Yes, I erased the eMMC before trying this.

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

2014-04-14 Thread Stanacar, StefanX

Hi Gary,

On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
 I just tried building (core-image-sato) for my BeagleBoneBlack
 using the latest Poky/Yocto master:
 
 Build Configuration:
 BB_VERSION= 1.23.0
 BUILD_SYS = i686-linux
 NATIVELSBSTRING   = Fedora-13
 TARGET_SYS= arm-poky-linux-gnueabi
 MACHINE   = beaglebone
 DISTRO= poky
 DISTRO_VERSION= 1.6+snapshot-20140411
 TUNE_FEATURES = armv7a vfp neon callconvention-hard cortexa8
 TARGET_FPU= vfp-neon
 meta
 meta-yocto
 meta-yocto-bsp= master:863cc7483f5ee43189537940de8ee5c0964d24cc
 
 This built the kernel using SRCREV 928d7b2dda
 
 I followed the bring-up instructions from README.hadware and the
 boot failed to even start the kernel.  Here's what I see:
 
 === boot log 
 =
 U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
 
 I2C:   ready
 DRAM:  512 MiB
 WARNING: Caches not enabled
 NAND:  0 MiB
 MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
 *** Warning - readenv() failed, using default environment
 
 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
 musb-hdrc: MHDRC RTL version 2.0
 musb-hdrc: setup fifo_mode 4
 musb-hdrc: 28/31 max ep, 16384/16384 memory
 USB Peripheral mode controller at 47401000 using PIO, IRQ 0
 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
 musb-hdrc: MHDRC RTL version 2.0
 musb-hdrc: setup fifo_mode 4
 musb-hdrc: 28/31 max ep, 16384/16384 memory
 USB Host mode controller at 47401800 using PIO, IRQ 0
 Net:   ethaddr not set. Validating first E-fuse MAC
 Phy not found
 PHY reset timed out
 cpsw, usb_ether
 Hit any key to stop autoboot:  0
 mmc0 is current device
 SD/MMC found on device 0
 reading uEnv.txt
 ** Unable to read file uEnv.txt **
 4981688 bytes read in 613 ms (7.7 MiB/s)
 29192 bytes read in 46 ms (619.1 KiB/s)
 Booting from mmc ...
 ## Booting kernel from Legacy Image at 8020 ...
Image Name:   Linux-3.14.0-yocto-standard
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:4981624 Bytes = 4.8 MiB
Load Address: 80008000
Entry Point:  80008000
Verifying Checksum ... OK
 ## Flattened Device Tree blob at 80f8
Booting using the fdt blob at 0x80f8
Loading Kernel Image ... OK
Using Device Tree in place at 80f8, end 80f8a207
 
 Starting kernel ...
 ==
 
 Any ideas what I've done wrong?
 

This is strange because last week I booted myself a BBB.
This actually looks like the serial doesn't output, perhaps the kernel
does boot. I wonder if console is right for the kernel cmdline.
On Friday I built and booted from
master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
that what you have but basically the same thing (updates for kernel
which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
${AUTOREV} those before they entered in master because I didn't had
HDMI output on my master commit).

I'm gonna rebuild from daisy tip and see what happens.

Cheers,
Stefan






 Thanks
 
 -- 
 
 Gary Thomas |  Consulting for the
 MLB Associates  |Embedded world
 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

2014-04-14 Thread Stanacar, StefanX




On Mon, 2014-04-14 at 10:35 +, Stanacar, StefanX wrote:
 Hi Gary,
 
 On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
  I just tried building (core-image-sato) for my BeagleBoneBlack
  using the latest Poky/Yocto master:
  
  Build Configuration:
  BB_VERSION= 1.23.0
  BUILD_SYS = i686-linux
  NATIVELSBSTRING   = Fedora-13
  TARGET_SYS= arm-poky-linux-gnueabi
  MACHINE   = beaglebone
  DISTRO= poky
  DISTRO_VERSION= 1.6+snapshot-20140411
  TUNE_FEATURES = armv7a vfp neon callconvention-hard cortexa8
  TARGET_FPU= vfp-neon
  meta
  meta-yocto
  meta-yocto-bsp= master:863cc7483f5ee43189537940de8ee5c0964d24cc
  
  This built the kernel using SRCREV 928d7b2dda
  
  I followed the bring-up instructions from README.hadware and the
  boot failed to even start the kernel.  Here's what I see:
  
  === boot log 
  =
  U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
  
  I2C:   ready
  DRAM:  512 MiB
  WARNING: Caches not enabled
  NAND:  0 MiB
  MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
  *** Warning - readenv() failed, using default environment
  
  musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
  SoftConn)
  musb-hdrc: MHDRC RTL version 2.0
  musb-hdrc: setup fifo_mode 4
  musb-hdrc: 28/31 max ep, 16384/16384 memory
  USB Peripheral mode controller at 47401000 using PIO, IRQ 0
  musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
  SoftConn)
  musb-hdrc: MHDRC RTL version 2.0
  musb-hdrc: setup fifo_mode 4
  musb-hdrc: 28/31 max ep, 16384/16384 memory
  USB Host mode controller at 47401800 using PIO, IRQ 0
  Net:   ethaddr not set. Validating first E-fuse MAC
  Phy not found
  PHY reset timed out
  cpsw, usb_ether
  Hit any key to stop autoboot:  0
  mmc0 is current device
  SD/MMC found on device 0
  reading uEnv.txt
  ** Unable to read file uEnv.txt **
  4981688 bytes read in 613 ms (7.7 MiB/s)
  29192 bytes read in 46 ms (619.1 KiB/s)
  Booting from mmc ...
  ## Booting kernel from Legacy Image at 8020 ...
 Image Name:   Linux-3.14.0-yocto-standard
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:4981624 Bytes = 4.8 MiB
 Load Address: 80008000
 Entry Point:  80008000
 Verifying Checksum ... OK
  ## Flattened Device Tree blob at 80f8
 Booting using the fdt blob at 0x80f8
 Loading Kernel Image ... OK
 Using Device Tree in place at 80f8, end 80f8a207
  
  Starting kernel ...
  ==
  
  Any ideas what I've done wrong?
  
 
 This is strange because last week I booted myself a BBB.
 This actually looks like the serial doesn't output, perhaps the kernel
 does boot. I wonder if console is right for the kernel cmdline.
 On Friday I built and booted from
 master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
 that what you have but basically the same thing (updates for kernel
 which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
 ${AUTOREV} those before they entered in master because I didn't had
 HDMI output on my master commit).
 
 I'm gonna rebuild from daisy tip and see what happens.
 

I just did a clean build from daisy and it worked fine...
Could you try again? And perhaps -ccleansstate for linux-yocto? I'm
thinking that somehow it didn't picked up the new console= that changed
in the machine definition.

Cheers,
Stefan

 Cheers,
 Stefan
 
 
 
 
 
 
  Thanks
  
  -- 
  
  Gary Thomas |  Consulting for the
  MLB Associates  |Embedded world
  
 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On 2014-04-14 05:38, Stanacar, StefanX wrote:
 
 
 
 On Mon, 2014-04-14 at 10:35 +, Stanacar, StefanX wrote:
 Hi Gary,

 On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
 I just tried building (core-image-sato) for my BeagleBoneBlack
 using the latest Poky/Yocto master:

 Build Configuration:
 BB_VERSION= 1.23.0
 BUILD_SYS = i686-linux
 NATIVELSBSTRING   = Fedora-13
 TARGET_SYS= arm-poky-linux-gnueabi
 MACHINE   = beaglebone
 DISTRO= poky
 DISTRO_VERSION= 1.6+snapshot-20140411
 TUNE_FEATURES = armv7a vfp neon callconvention-hard cortexa8
 TARGET_FPU= vfp-neon
 meta
 meta-yocto
 meta-yocto-bsp= master:863cc7483f5ee43189537940de8ee5c0964d24cc

 This built the kernel using SRCREV 928d7b2dda

 I followed the bring-up instructions from README.hadware and the
 boot failed to even start the kernel.  Here's what I see:

 === boot log 
 =
 U-Boot 2013.07 (Apr 11 2014 - 15:03:04)

 I2C:   ready
 DRAM:  512 MiB
 WARNING: Caches not enabled
 NAND:  0 MiB
 MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
 *** Warning - readenv() failed, using default environment

 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
 SoftConn)
 musb-hdrc: MHDRC RTL version 2.0
 musb-hdrc: setup fifo_mode 4
 musb-hdrc: 28/31 max ep, 16384/16384 memory
 USB Peripheral mode controller at 47401000 using PIO, IRQ 0
 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
 SoftConn)
 musb-hdrc: MHDRC RTL version 2.0
 musb-hdrc: setup fifo_mode 4
 musb-hdrc: 28/31 max ep, 16384/16384 memory
 USB Host mode controller at 47401800 using PIO, IRQ 0
 Net:   ethaddr not set. Validating first E-fuse MAC
 Phy not found
 PHY reset timed out
 cpsw, usb_ether
 Hit any key to stop autoboot:  0
 mmc0 is current device
 SD/MMC found on device 0
 reading uEnv.txt
 ** Unable to read file uEnv.txt **
 4981688 bytes read in 613 ms (7.7 MiB/s)
 29192 bytes read in 46 ms (619.1 KiB/s)
 Booting from mmc ...
 ## Booting kernel from Legacy Image at 8020 ...
Image Name:   Linux-3.14.0-yocto-standard
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:4981624 Bytes = 4.8 MiB
Load Address: 80008000
Entry Point:  80008000
Verifying Checksum ... OK
 ## Flattened Device Tree blob at 80f8
Booting using the fdt blob at 0x80f8
Loading Kernel Image ... OK
Using Device Tree in place at 80f8, end 80f8a207

 Starting kernel ...
 ==

 Any ideas what I've done wrong?


 This is strange because last week I booted myself a BBB.
 This actually looks like the serial doesn't output, perhaps the kernel
 does boot. I wonder if console is right for the kernel cmdline.
 On Friday I built and booted from
 master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
 that what you have but basically the same thing (updates for kernel
 which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
 ${AUTOREV} those before they entered in master because I didn't had
 HDMI output on my master commit).

 I'm gonna rebuild from daisy tip and see what happens.

 
 I just did a clean build from daisy and it worked fine...
 Could you try again? And perhaps -ccleansstate for linux-yocto? I'm
 thinking that somehow it didn't picked up the new console= that changed
 in the machine definition.

I'll try daisy, but my build/test was clean from the mentioned master rev.

I checked the console setup in U-Boot:
  console=ttyO0,115200n8
which I think is correct.

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote:
 On 2014-04-14 09:46, Denys Dmytriyenko wrote:
  On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
  On 2014-04-13 20:33, Denys Dmytriyenko wrote:
  On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
  I just tried building (core-image-sato) for my BeagleBoneBlack
  using the latest Poky/Yocto master:
 
  Build Configuration:
  BB_VERSION= 1.23.0
  BUILD_SYS = i686-linux
  NATIVELSBSTRING   = Fedora-13
  TARGET_SYS= arm-poky-linux-gnueabi
  MACHINE   = beaglebone
  DISTRO= poky
  DISTRO_VERSION= 1.6+snapshot-20140411
  TUNE_FEATURES = armv7a vfp neon callconvention-hard cortexa8
  TARGET_FPU= vfp-neon
  meta
  meta-yocto
  meta-yocto-bsp= master:863cc7483f5ee43189537940de8ee5c0964d24cc
 
  This built the kernel using SRCREV 928d7b2dda
 
  I followed the bring-up instructions from README.hadware and the
  boot failed to even start the kernel.  Here's what I see:
 
  === boot log 
  =
  U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
 
  I2C:   ready
  DRAM:  512 MiB
  WARNING: Caches not enabled
  NAND:  0 MiB
  MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
  *** Warning - readenv() failed, using default environment
 
  musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
  SoftConn)
  musb-hdrc: MHDRC RTL version 2.0
  musb-hdrc: setup fifo_mode 4
  musb-hdrc: 28/31 max ep, 16384/16384 memory
  USB Peripheral mode controller at 47401000 using PIO, IRQ 0
  musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
  SoftConn)
  musb-hdrc: MHDRC RTL version 2.0
  musb-hdrc: setup fifo_mode 4
  musb-hdrc: 28/31 max ep, 16384/16384 memory
  USB Host mode controller at 47401800 using PIO, IRQ 0
  Net:   ethaddr not set. Validating first E-fuse MAC
  Phy not found
  PHY reset timed out
  cpsw, usb_ether
  Hit any key to stop autoboot:  0
  mmc0 is current device
  SD/MMC found on device 0
  reading uEnv.txt
  ** Unable to read file uEnv.txt **
  4981688 bytes read in 613 ms (7.7 MiB/s)
  29192 bytes read in 46 ms (619.1 KiB/s)
  Booting from mmc ...
  ## Booting kernel from Legacy Image at 8020 ...
 Image Name:   Linux-3.14.0-yocto-standard
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:4981624 Bytes = 4.8 MiB
 Load Address: 80008000
 Entry Point:  80008000
 Verifying Checksum ... OK
  ## Flattened Device Tree blob at 80f8
 Booting using the fdt blob at 0x80f8
 Loading Kernel Image ... OK
 Using Device Tree in place at 80f8, end 80f8a207
 
  Starting kernel ...
  ==
 
  Any ideas what I've done wrong?
 
  Hmm, everything looks sane. What revision is your BBB? And did you press 
  USER/BOOT button or erased eMMC partition per instructions?
 
 
  Revision A5A, with an LCD cape
  
  Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in 
  this BSP. Can you try w/o it?
 
 Sure I can try it but I don't think that's it.  I got the kernel that StefanX
 built and booted and tried it on my board and it came up.  No clue why the
 kernels are different - ostensibly we both built the same image from the same
 meta data, but they are slightly different (only in size - I compared the
 System.map files from both builds and they contain exactly the same bits,
 just a few changes in memory layout which I can't explain).

Yeah, good point. Doesn't look like your cape causes the issue...
The only other difference is in the host. Do you have access to another Linux 
box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is 32-bit 
Fedora 13, right?


 I'm trying another build from scratch using a different build host to see
 if that makes a difference.

Do you have any other layers or customizations on top? (the metadata above 
suggests you build just pure Poky though)

-- 
Denys
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On 2014-04-14 10:00, Denys Dmytriyenko wrote:
 On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote:
 On 2014-04-14 09:46, Denys Dmytriyenko wrote:
 On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
 On 2014-04-13 20:33, Denys Dmytriyenko wrote:
 On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
 I just tried building (core-image-sato) for my BeagleBoneBlack
 using the latest Poky/Yocto master:

 Build Configuration:
 BB_VERSION= 1.23.0
 BUILD_SYS = i686-linux
 NATIVELSBSTRING   = Fedora-13
 TARGET_SYS= arm-poky-linux-gnueabi
 MACHINE   = beaglebone
 DISTRO= poky
 DISTRO_VERSION= 1.6+snapshot-20140411
 TUNE_FEATURES = armv7a vfp neon callconvention-hard cortexa8
 TARGET_FPU= vfp-neon
 meta
 meta-yocto
 meta-yocto-bsp= master:863cc7483f5ee43189537940de8ee5c0964d24cc

 This built the kernel using SRCREV 928d7b2dda

 I followed the bring-up instructions from README.hadware and the
 boot failed to even start the kernel.  Here's what I see:

 === boot log 
 =
 U-Boot 2013.07 (Apr 11 2014 - 15:03:04)

 I2C:   ready
 DRAM:  512 MiB
 WARNING: Caches not enabled
 NAND:  0 MiB
 MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
 *** Warning - readenv() failed, using default environment

 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
 SoftConn)
 musb-hdrc: MHDRC RTL version 2.0
 musb-hdrc: setup fifo_mode 4
 musb-hdrc: 28/31 max ep, 16384/16384 memory
 USB Peripheral mode controller at 47401000 using PIO, IRQ 0
 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
 SoftConn)
 musb-hdrc: MHDRC RTL version 2.0
 musb-hdrc: setup fifo_mode 4
 musb-hdrc: 28/31 max ep, 16384/16384 memory
 USB Host mode controller at 47401800 using PIO, IRQ 0
 Net:   ethaddr not set. Validating first E-fuse MAC
 Phy not found
 PHY reset timed out
 cpsw, usb_ether
 Hit any key to stop autoboot:  0
 mmc0 is current device
 SD/MMC found on device 0
 reading uEnv.txt
 ** Unable to read file uEnv.txt **
 4981688 bytes read in 613 ms (7.7 MiB/s)
 29192 bytes read in 46 ms (619.1 KiB/s)
 Booting from mmc ...
 ## Booting kernel from Legacy Image at 8020 ...
Image Name:   Linux-3.14.0-yocto-standard
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:4981624 Bytes = 4.8 MiB
Load Address: 80008000
Entry Point:  80008000
Verifying Checksum ... OK
 ## Flattened Device Tree blob at 80f8
Booting using the fdt blob at 0x80f8
Loading Kernel Image ... OK
Using Device Tree in place at 80f8, end 80f8a207

 Starting kernel ...
 ==

 Any ideas what I've done wrong?

 Hmm, everything looks sane. What revision is your BBB? And did you press 
 USER/BOOT button or erased eMMC partition per instructions?


 Revision A5A, with an LCD cape

 Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in 
 this BSP. Can you try w/o it?

 Sure I can try it but I don't think that's it.  I got the kernel that StefanX
 built and booted and tried it on my board and it came up.  No clue why the
 kernels are different - ostensibly we both built the same image from the same
 meta data, but they are slightly different (only in size - I compared the
 System.map files from both builds and they contain exactly the same bits,
 just a few changes in memory layout which I can't explain).
 
 Yeah, good point. Doesn't look like your cape causes the issue...
 The only other difference is in the host. Do you have access to another Linux 
 box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is 
 32-bit 
 Fedora 13, right?

I'll try Fedora 17 and Ubuntu 12.04 (x86_64) and see what happens.

Note: I use the Fedora 13 system *all* the time for my other Poky/Yocto builds.

 
 I'm trying another build from scratch using a different build host to see
 if that makes a difference.
 
 Do you have any other layers or customizations on top? (the metadata above 
 suggests you build just pure Poky though)

I was trying this on a pure Poky/Yocto build.

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On Mon, Apr 14, 2014 at 10:04:41AM -0600, Gary Thomas wrote:
 On 2014-04-14 10:00, Denys Dmytriyenko wrote:
  On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote:
  On 2014-04-14 09:46, Denys Dmytriyenko wrote:
  On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
  On 2014-04-13 20:33, Denys Dmytriyenko wrote:
  On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
  I just tried building (core-image-sato) for my BeagleBoneBlack
  using the latest Poky/Yocto master:
 
  Build Configuration:
  BB_VERSION= 1.23.0
  BUILD_SYS = i686-linux
  NATIVELSBSTRING   = Fedora-13
  TARGET_SYS= arm-poky-linux-gnueabi
  MACHINE   = beaglebone
  DISTRO= poky
  DISTRO_VERSION= 1.6+snapshot-20140411
  TUNE_FEATURES = armv7a vfp neon callconvention-hard cortexa8
  TARGET_FPU= vfp-neon
  meta
  meta-yocto
  meta-yocto-bsp= master:863cc7483f5ee43189537940de8ee5c0964d24cc
 
  This built the kernel using SRCREV 928d7b2dda
 
  I followed the bring-up instructions from README.hadware and the
  boot failed to even start the kernel.  Here's what I see:
 
  === boot log 
  =
  U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
 
  I2C:   ready
  DRAM:  512 MiB
  WARNING: Caches not enabled
  NAND:  0 MiB
  MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
  *** Warning - readenv() failed, using default environment
 
  musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
  SoftConn)
  musb-hdrc: MHDRC RTL version 2.0
  musb-hdrc: setup fifo_mode 4
  musb-hdrc: 28/31 max ep, 16384/16384 memory
  USB Peripheral mode controller at 47401000 using PIO, IRQ 0
  musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
  SoftConn)
  musb-hdrc: MHDRC RTL version 2.0
  musb-hdrc: setup fifo_mode 4
  musb-hdrc: 28/31 max ep, 16384/16384 memory
  USB Host mode controller at 47401800 using PIO, IRQ 0
  Net:   ethaddr not set. Validating first E-fuse MAC
  Phy not found
  PHY reset timed out
  cpsw, usb_ether
  Hit any key to stop autoboot:  0
  mmc0 is current device
  SD/MMC found on device 0
  reading uEnv.txt
  ** Unable to read file uEnv.txt **
  4981688 bytes read in 613 ms (7.7 MiB/s)
  29192 bytes read in 46 ms (619.1 KiB/s)
  Booting from mmc ...
  ## Booting kernel from Legacy Image at 8020 ...
 Image Name:   Linux-3.14.0-yocto-standard
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:4981624 Bytes = 4.8 MiB
 Load Address: 80008000
 Entry Point:  80008000
 Verifying Checksum ... OK
  ## Flattened Device Tree blob at 80f8
 Booting using the fdt blob at 0x80f8
 Loading Kernel Image ... OK
 Using Device Tree in place at 80f8, end 80f8a207
 
  Starting kernel ...
  ==
 
  Any ideas what I've done wrong?
 
  Hmm, everything looks sane. What revision is your BBB? And did you 
  press 
  USER/BOOT button or erased eMMC partition per instructions?
 
 
  Revision A5A, with an LCD cape
 
  Hmm, I'm wondering if LCD cape conflicts here - there's no cape support 
  in 
  this BSP. Can you try w/o it?
 
  Sure I can try it but I don't think that's it.  I got the kernel that 
  StefanX
  built and booted and tried it on my board and it came up.  No clue why the
  kernels are different - ostensibly we both built the same image from the 
  same
  meta data, but they are slightly different (only in size - I compared the
  System.map files from both builds and they contain exactly the same bits,
  just a few changes in memory layout which I can't explain).
  
  Yeah, good point. Doesn't look like your cape causes the issue...
  The only other difference is in the host. Do you have access to another 
  Linux 
  box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is 
  32-bit 
  Fedora 13, right?
 
 I'll try Fedora 17 and Ubuntu 12.04 (x86_64) and see what happens.
 
 Note: I use the Fedora 13 system *all* the time for my other Poky/Yocto 
 builds.

Yeah, it usually shouldn't matter, as OE is very good at isolating host 
differences. But at this point we need to eliminate every variable...


  I'm trying another build from scratch using a different build host to see
  if that makes a difference.
  
  Do you have any other layers or customizations on top? (the metadata above 
  suggests you build just pure Poky though)
 
 I was trying this on a pure Poky/Yocto build.
 
 -- 
 
 Gary Thomas |  Consulting for the
 MLB Associates  |Embedded world
 
 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

On 2014-04-14 10:08, Denys Dmytriyenko wrote:
 On Mon, Apr 14, 2014 at 10:04:41AM -0600, Gary Thomas wrote:
 On 2014-04-14 10:00, Denys Dmytriyenko wrote:
 On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote:
 On 2014-04-14 09:46, Denys Dmytriyenko wrote:
 On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
 On 2014-04-13 20:33, Denys Dmytriyenko wrote:
 On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
 I just tried building (core-image-sato) for my BeagleBoneBlack
 using the latest Poky/Yocto master:

 Build Configuration:
 BB_VERSION= 1.23.0
 BUILD_SYS = i686-linux
 NATIVELSBSTRING   = Fedora-13
 TARGET_SYS= arm-poky-linux-gnueabi
 MACHINE   = beaglebone
 DISTRO= poky
 DISTRO_VERSION= 1.6+snapshot-20140411
 TUNE_FEATURES = armv7a vfp neon callconvention-hard cortexa8
 TARGET_FPU= vfp-neon
 meta
 meta-yocto
 meta-yocto-bsp= master:863cc7483f5ee43189537940de8ee5c0964d24cc

 This built the kernel using SRCREV 928d7b2dda

 I followed the bring-up instructions from README.hadware and the
 boot failed to even start the kernel.  Here's what I see:

 === boot log 
 =
 U-Boot 2013.07 (Apr 11 2014 - 15:03:04)

 I2C:   ready
 DRAM:  512 MiB
 WARNING: Caches not enabled
 NAND:  0 MiB
 MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
 *** Warning - readenv() failed, using default environment

 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
 SoftConn)
 musb-hdrc: MHDRC RTL version 2.0
 musb-hdrc: setup fifo_mode 4
 musb-hdrc: 28/31 max ep, 16384/16384 memory
 USB Peripheral mode controller at 47401000 using PIO, IRQ 0
 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
 SoftConn)
 musb-hdrc: MHDRC RTL version 2.0
 musb-hdrc: setup fifo_mode 4
 musb-hdrc: 28/31 max ep, 16384/16384 memory
 USB Host mode controller at 47401800 using PIO, IRQ 0
 Net:   ethaddr not set. Validating first E-fuse MAC
 Phy not found
 PHY reset timed out
 cpsw, usb_ether
 Hit any key to stop autoboot:  0
 mmc0 is current device
 SD/MMC found on device 0
 reading uEnv.txt
 ** Unable to read file uEnv.txt **
 4981688 bytes read in 613 ms (7.7 MiB/s)
 29192 bytes read in 46 ms (619.1 KiB/s)
 Booting from mmc ...
 ## Booting kernel from Legacy Image at 8020 ...
Image Name:   Linux-3.14.0-yocto-standard
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:4981624 Bytes = 4.8 MiB
Load Address: 80008000
Entry Point:  80008000
Verifying Checksum ... OK
 ## Flattened Device Tree blob at 80f8
Booting using the fdt blob at 0x80f8
Loading Kernel Image ... OK
Using Device Tree in place at 80f8, end 80f8a207

 Starting kernel ...
 ==

 Any ideas what I've done wrong?

 Hmm, everything looks sane. What revision is your BBB? And did you 
 press 
 USER/BOOT button or erased eMMC partition per instructions?


 Revision A5A, with an LCD cape

 Hmm, I'm wondering if LCD cape conflicts here - there's no cape support 
 in 
 this BSP. Can you try w/o it?

 Sure I can try it but I don't think that's it.  I got the kernel that 
 StefanX
 built and booted and tried it on my board and it came up.  No clue why the
 kernels are different - ostensibly we both built the same image from the 
 same
 meta data, but they are slightly different (only in size - I compared the
 System.map files from both builds and they contain exactly the same bits,
 just a few changes in memory layout which I can't explain).

 Yeah, good point. Doesn't look like your cape causes the issue...
 The only other difference is in the host. Do you have access to another 
 Linux 
 box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is 
 32-bit 
 Fedora 13, right?

 I'll try Fedora 17 and Ubuntu 12.04 (x86_64) and see what happens.

 Note: I use the Fedora 13 system *all* the time for my other Poky/Yocto 
 builds.
 
 Yeah, it usually shouldn't matter, as OE is very good at isolating host 
 differences. But at this point we need to eliminate every variable...
 
 
 I'm trying another build from scratch using a different build host to see
 if that makes a difference.

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

Note that I routinely build for other targets (which does imply other, mostly
older, kernels) using all of these machines with no differences based on the
build host.

I don't know what's unique about an x86_64 host, but it does seem to work.

I was trying this to see how the stock Yocto support for the BBB competes with
building using meta-beaglebone which I've been using successfully.  Based on
these results, I'll be sticking with the meta-beaglebone approach for now
(not just for the booting issue, but support for my LCD cape and

Re: [yocto] BBB doesn't boot

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...


 Note that I routinely build for other targets (which does imply other, mostly
 older, kernels) using all of these machines with no differences based on the
 build host.

Same here - building for different targets with different kernels from meta-ti 
and on 32 and 64 bit hosts and never had an issue like that...


 I don't know what's unique about an x86_64 host, but it does seem to work.
 
 I was trying this to see how the stock Yocto support for the BBB competes with
 building using meta-beaglebone which I've been using successfully.  Based on
 these results, I'll be sticking with the meta-beaglebone approach for now
 (not just for the booting issue, but support for my LCD cape and other things
 that aren't there in the Yocto kernel)

This is not a Yocto kernel, this is a vanilla mainline 3.14 kernel (as a 
successor to 3.12 work done in meta-ti). Indeed, cape support is missing, as 
it is still not merged upstream, going through numerous iterations... The 
point of meta-beagleboard was to work on cape support and such, with the goal 
to upstream it, while meta-ti kept on working on SoC and peripheral support. 
Due to different circumstances, meta-beagleboard still uses 3.8 kernel. Once 
it is accepted upstream, it will be part of the mainline kernel and one of the 
later versions of the Yocto Project reference BSP.

-- 
Denys
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

2014-04-14 Thread Richard Purdie

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-gnueabi

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@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@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.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

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-gnueabi
 
 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@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@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:


U-Boot SPL 2013.07 (Apr 10 2014 - 04:47:32)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading args
spl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2013.07 (Apr 10 2014 - 04:47:32)

I2C:   ready
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:   ethaddr not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
** Unable to read file uEnv.txt **
4985376 bytes read in 853 ms (5.6 MiB/s)
29192 bytes read in 28 ms (1017.6 KiB/s)
Booting from mmc ...
## Booting kernel from Legacy Image at 8020 ...
   Image Name:   Linux-3.14.0-yocto-standard
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4985312 Bytes = 4.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80f8
   Booting using the fdt blob at 0x80f8
   Loading Kernel Image ... OK
   Using Device Tree in place at 80f8, end 80f8a207

Starting kernel ...

Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc version 4.8.2 
(GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: TI AM335x BeagleBone
cma: CMA: reserved 16 MiB at 9e80
Memory policy: Data cache writeback
CPU: All CPU(s) started in SVC mode.
AM335X ES2.0 (sgx neon )
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129792
Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro 
rootfstype=ext4 rootwait
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
allocated 1048576 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 489452K/523264K available (7491K kernel code, 520K rwdata, 2448K 
rodata, 488K

Re: [yocto] BBB doesn't boot

2014-04-14 Thread Richard Purdie

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-gnueabi
  
  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@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@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.

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.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

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-gnueabi
   
   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@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@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@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.
 
 Cheers,
 
 Richard
 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot