[yocto] [poky] WARNING: QA Issue: ELF binary has relocations in .text
Hi, I just built meta-toolchain using the latest poky master, along with the meta-xilinx layer, and find that the build system issues multiple QA warnings, for a number of qemu machine configurations that are not specified in my local.conf. I only have MACHINE=“zc702-zynq7” specified, but the toolchain appears to be generating native-sdk-qemu binaries for all architectures. Build Configuration: BB_VERSION= "1.21.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-12.10" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "zc702-zynq7" DISTRO = "poky" DISTRO_VERSION= "1.5+snapshot-20140329" TUNE_FEATURES = " armv7a vfp neon zynq" TARGET_FPU= "vfp-neon" meta meta-yocto meta-yocto-bsp= "master:95cd5688c67fa179204a7704b1287980672894fd" meta-xilinx = "master:9d446e98558239d0453d61f65e69b67c4df72f26" meta-xilinx-community = "master:3b513f2b29f047b17778538c331bfaddd6105e39" NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-eglibc/2.19-r0/packages-split/nativesdk-nscd/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/sbin/nscd' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-microblazeel' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-mipsel' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-i386' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-ga' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-mips.real' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-microblazeel' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-img' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-mipsel' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-mips' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-nbd' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-x86_64' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-i386' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/opt/poky/1.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-ppc' has relocations in .text WARNING: QA Issue: ELF binary '/tool/yocto/build/zc702/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/op
[yocto] Recursive entry to debugger" panic seen with KGDB (PowerPC)
I am using Linux Kernel Version 2.6.34.6 SMP for powerPC 64 bit. I tried to debug kernel using KGDB and ended up in Kernel panic reboot issue. Here is the list of steps I did. 1) I enabled the following in the config file CONFIG_DEBUG_PAGEALLOC=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_INFO=y CONFIG_KGDB=y CONFIG_FRAME_POINTER=y CONFIG_KGDB_SERIAL_CONSOLE=y Built and loaded the Kernel. 2) My Linux PC is connected terminal server using ttyS0 and I enabled KGDB over serial port by doing "echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc" 3) Trigger KGDB by issuing sysrq-g. echo g > /proc/sysrq-trigger 4) Kernel Panic reboot is seen with the following reboot log sw0:root> echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc kgdb: Registered I/O driver kgdboc. sw0:root> echo g > /proc/sysrq-trigger SysRq : DEBUG Entering KGDB Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x KGDB: re-enter exception: ALL breakpoints killed Call Trace: STACK MAGIC 0x57ac6e9d [813679c0] [40007fcc] show_stack+0x84/0x24c (unreliable) [81367a20] [4057d9f4] dump_stack+0x2c/0x44 [81367a30] [40098008] kgdb_handle_exception+0x184/0x1b8 [81367a80] [40013320] kgdb_debugger+0x88/0xa0 [81367a90] [4000f5a4] die+0x48/0x28c [81367ac0] [40019460] bad_page_fault+0x90/0xe0 [81367ae0] [400123fc] handle_page_fault+0x7c/0x80 [81367ba0] [407a] kmalloc_caches+0xdc0/0x1340 [81367bb0] [402d11ac] uart_poll_get_char+0x58/0x70 [81367bc0] [402daae8] kgdboc_get_char+0x40/0x58 [81367bd0] [40096eac] kgdb_cpu_enter+0x420/0x1320 [81367c60] [40097f08] kgdb_handle_exception+0x84/0x1b8 [81367cb0] [40013250] kgdb_handle_breakpoint+0x4c/0x94 [81367cc0] [40578dbc] program_check_exception+0x5c/0x860 [81367da0] [40012544] ret_from_except_full+0x0/0x4c [81367e60] [40096018] sysrq_handle_gdb+0x94/0xb0 [81367e70] [402c9f28] __handle_sysrq+0xe0/0x1c8 [81367ea0] [402ca06c] write_sysrq_trigger+0x5c/0x80 [81367eb0] [401614a4] proc_reg_write+0x90/0xcc [81367ee0] [4011201c] vfs_write+0xb4/0x1a8 [81367f00] [401122b0] sys_write+0x60/0x144 [81367f40] [40011f4c] ret_from_syscall+0x0/0x3c Kernel panic - not syncing: Recursive entry to debugger Call Trace: STACK MAGIC 0x57ac6e9d Can you help me to understand the root cause of the issue? Let me know how to solve this issue. Thanks Jegan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fw: regarding adding custom kernel to yocto build system
On Thu, Mar 20, 2014 at 10:32 PM, mujtaba rizwan wrote: > my previous problem is resolved its picking my kernel from local system.i > didn't get any reply from yocto group i'm expecting some help please help me > out. > > I've compiled the msm working kernel with make then i took the zimage along > with ramdisk and created boot.img and flashed it to the boot partition of > android kernel is booting fine rest of the partitions are working and > untouched only i'm changing the boot.img. > > The same kernel i took and built it from yocto build system by providing > proper defconfig file, kernel is compiled successfully got the zimage used > it along with the working ramdisk stripped from working boot.img file and > created the boot.img and flashed to the boot partition, i'm facing a few > problem in booting. I've attached the boot logs and defconfig.please help me > out to resolve this problem it is critical and i've already crossed the > deadline... > > ->log messages from kernel booting: > [0.00] of_mpm_init(): Cannot find irq controller for qcom,gic-parent > [0.00] of_mpm_init(): Cannot find irq controller for > qcom,gpio-parent > [0.00] irq: no irq domain found for > /soc/interrupt-controller@F900 > You should try to narrow down the problem. there are several factors firstly make sure that kernel version you are using is compiled/booted OK with gcc 4.8, then make sure that resulting .config when building kernel inside OE framework is same as you expected it to be. There might be additional tweaks that framework will do to defconfig and it could be thats causing problems. Is the device tree correctly used are there modules which are not being loaded properly since you kept the rootfs unmodified you will end up doing mix and match of kernel and modules. > Thanks & Regards, > Rizwan > > On Monday, March 10, 2014 10:40 AM, mujtaba rizwan > wrote: > Hi All, > > I'm trying to compile msm linux kernel source code which is already present > in my system. i've created a new meta layer for msm and then i've added > machine and local mirror into local.conf file and appended bblayers with my > layer and i've given the SRC-URI as path to the kernel in my system inside > linux-yocto-custom.bb. so please let me know wether it will compile my sorce > code or will it fetch standard code > > > > -- > ___ > 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] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker wrote: > On 26 March 2014 22:12, Burton, Ross wrote: >> On 26 March 2014 22:04, Khem Raj wrote: >>> There were interest in other threads in having musl as an alternative >>> to eglibc/uclibc that we already have in OE, in that direction I have >>> poured in my on and off work and put it into a contrib tree >> >> Blimey Khem that was quick. :) >> > > Agreed! > > I wonder if it's worth splitting this out into its own layer though I thought about it and since class/conf changes that need to go in into OE-core first I kept it as it is (lazyness too). I think once the core support is available in OE-core we can spin the recipes into a layer of its own. > (with fixes done via bbappends) so that it's easy for multiple people > to contribute to. It would also mean it doesn't need rebasing onto > master all the time. > > I'd definitely like to get involved with this. In particular I can > ensure opkg (both current release and development branch) work with > musl and see if some of my preferred software from meta-oe will build > (vim, htop, etc). start with what we have. Once master opens up I would propose the needed changes to OE-core and spin a layer > > Many thanks, > > -- > Paul Barker > > Email: p...@paulbarker.me.uk > http://www.paulbarker.me.uk > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
