On 04/17/2014 03:10 PM, Denys Dmytriyenko wrote:

On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:

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-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/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, et al,

I've just submitted a patch to oe-core and yocto MLs that fixes this issue -
could you please test it in your setup and confirm? Thanks!

I updated Stefan's bug w/ more explanation.
I verified that Stefan's uImage-bad failed for me and then added the following to uEnv.txt:
fdtaddr=0x88000000

uImage-bad (and uImage-good) worked w/ the above change to uEnv.txt.
Denys' patch fixes all the defaults in u-boot so that no uEnv.txt change is needed.