On 04/15/2014 11:31 PM, Khem Raj wrote:
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-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!
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 -1111111 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-111111 pathnames are in
there (they get stripped out when you create the zImage).
Nope, I was fooled by sstate once, so this time I tested with cleansstate and
compared timestamps of the kernel when it boots - it is definitely the new
one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect
it, I increased the path length even further - that extra level with 333 is
there to over-compensate, as it was failing before even with just 111 and 222
levels only... Looks like Gary was also able to verify it.
But, you are right about vmlinux - it doesn't have those paths in there any
more! I've seen them there when building with B != S, but they are gone when
building with B = S. Wondering why. You can check it for yourself:
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:
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
earlycon
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
...
6Trying to unpack rootfs image as initramfs...
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/initramfs.c
6rootfs image is not initramfs (%s); looks like an initrd
TRAILER!!!
...
%lu.%02lu BogoMIPS (lpj=%lu)
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/arch/arm/vfp/vfpmodule.c
6VFP support v0.3:
B = S same strings:
init/main.c
earlycon
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
...
6Trying to unpack rootfs image as initramfs...
init/initramfs.c
6rootfs image is not initramfs (%s); looks like an initrd
TRAILER!!!
...
%lu.%02lu BogoMIPS (lpj=%lu)
arch/arm/vfp/vfpmodule.c
6VFP support v0.3:
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.
It would be interesting to see if the rodata segment (or segment it
contributes to) between working and non-working versions were crossing
some magic power of 2 value.
Are there two images published from the same build machines with just
the path difference? I would like to see one that was just under the
wire and one just a bit too long. Denys, you have that?
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
