Re: [yocto] Which is the best strategy to customize Qt configuration?
On Jul 13, 2015, at 22:04, Martin Jansa martin.ja...@gmail.com wrote: Will this work if gstreamer gst-plugins-base aren't next to each other in DEPENDS? I think good convention is to use: DEPENDS_remove = gstreamer DEPENDS_remove = gst-plugins-base for it to work even after original DEPENDS in the recipe is re-ordered or changed. Shouldn't you be using += instead of =, so that you append to the list: DEPENDS_remove += gstreamer DEPENDS_remove += gst-plugins-base The earlier line had it in one line, so it was okay: DEPENDS_remove = gstreamer gst-plugins-base Regards, Elvis Dowson -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [poky] Error patching gcc-4.8.2
Hi Khem, I’m getting an error with poky master branch, when it attempts to patch gcc-cross-4.8.2. Have you seen this happen earlier at your end? Build Configuration: BB_VERSION= 1.23.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-12.10 TARGET_SYS= arm-poky-linux-gnueabi MACHINE = zc702-zynq7 DISTRO= poky DISTRO_VERSION= 1.6+snapshot-20140502 TUNE_FEATURES = arm armv7a vfp neon zynq TARGET_FPU= vfp-neon meta meta-yocto meta-yocto-bsp= master:f7bbe9ce7679714c3dc464d0c382ef9ee2d7ce77 meta-xilinx = master:869cba51d3db7909077ad0f066b784ebfd3b092d meta-xilinx-community = master:44187a45f0f0c904fc385f12347ae01c669ba7f2 NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: Command Error: exit status: 1 Output: File series fully applied, ends at patch 0031-Disable-sdt.patch ERROR: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /tool/yocto/build/zc702/tmp/work-shared/gcc-4.8.2-r0/temp/log.do_patch.20954 ERROR: Task 424 (/tool/yocto/poky/meta/recipes-devtools/gcc/gcc-cross_4.8.bb, do_patch) failed with exit code '1' NOTE: Tasks Summary: Attempted 692 tasks of which 3 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: Summary: 1 task failed: /tool/yocto/poky/meta/recipes-devtools/gcc/gcc-cross_4.8.bb, do_patch Summary: There was 1 WARNING message shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code. real2m18.089s user11m16.352s sys 1m20.140s Regards, Elvis Dowson signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [poky] Error patching gcc-4.8.2
Hi Khem, On May 3, 2014, at 7:24, Khem Raj raj.k...@gmail.com wrote: I am subsumed with gcc 4.9 work however haven't seen this happening so far. may be you should clean the build tree and retry This was with a clean build. There are a bunch of changes to the gcc recipes done by Richard Purdie starting with this one, which appears to have triggered the build failure with the gcc-4.8.2 recipe http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=03a0f8e8b4e286bfcc0076e7380ce26d1b1b106a Reverting to commit 17daa2ba6280304771c5fe52b94eb56f0c087490 for poky master branch helps complete the build. This was a commit from 3 days ago http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=17daa2ba6280304771c5fe52b94eb56f0c087490 Regards, Elvis Dowson signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [poky] Build failure gcc-4.8
Hi, I just updated to the latest poky master, and encountered a build failure with gcc patch#0030 failing to apply. Build Configuration: BB_VERSION= 1.23.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-12.10 TARGET_SYS= arm-poky-linux-gnueabi MACHINE = zc706-zynq7 DISTRO= poky DISTRO_VERSION= 1.6+snapshot-20140425 TUNE_FEATURES = armv7a vfp neon zynq TARGET_FPU= vfp-neon meta meta-yocto meta-yocto-bsp= master:c446d4edca3b4edfcdee48247391bfb306aab4c2 meta-xilinx = master:62c97f8bd8205b0526a1698fe6844266a98f meta-xilinx-community = master:3a03b207084cbbdbd88a5691c3c2c16ad50be7df NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: Command Error: exit status: 1 Output: File series fully applied, ends at patch 0029-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch ERROR: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /tool/yocto/build/zc706/tmp/work-shared/gcc-4.8.2-r0/temp/log.do_patch.32469 ERROR: Task 691 (/tool/yocto/poky/meta/recipes-devtools/gcc/libgcc_4.8.bb, do_patch) failed with exit code '1' NOTE: Tasks Summary: Attempted 628 tasks of which 3 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: Summary: 1 task failed: /tool/yocto/poky/meta/recipes-devtools/gcc/libgcc_4.8.bb, do_patch Summary: There was 1 WARNING message shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code. real3m13.888s user12m59.532s sys 2m4.204s Some of the recent commits beyond the following one has caused this breakage, http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7f138d64f093610a03f2333ae31b48edfa3553ff Regards, Elvis Dowson signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [poky] ERROR: Function failed: do_rootfs, when using ipk package class
Hi, I just tries a build with poky master, and meta-xilinx master branch, and got the following build error. For some reason the yocto build process fails is PACKAGE_CLASSES is set to package_ipk. ERROR: Unable to install packages. Command '/tool/yocto/build/zc706/tmp/sysroots/x86_64-lux/usr/bin/opkg-cl -f /tool/yocto/build/zc706/tmp/work/zc706_zynq7-poky-linux-gnueabi/core-image-minimal/1.0-r0/opkg.conf -o /tool/yocto/build/zc706/tmp/work/zc706_zynq7-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version install run-postinsts packagegroup-core-boot' returned 255: Installing run-postinsts (1.0-r9) to root... Downloading file:/tool/yocto/build/zc706/tmp/deploy/ipk/all/run-postinsts_1.0-r9_all.ipk. Installing update-rc.d (0.7-r5) to root... Downloading file:/tool/yocto/build/zc706/tmp/deploy/ipk/all/update-rc.d_0.7-r5_all.ipk. sh: 1: /tmp/opkg-RUBbug/run-postinsts-mxgou5/preinst: Permission denied Installing packagegroup-core-boot (1.0-r17) to root... Downloading file:/tool/yocto/build/zc706/tmp/deploy/ipk/zc706_zynq7/packagegroup-core-boot_1.0-r17_zc706_zynq7.ipk. Installing busybox (1.22.1-r0) to root... Downloading file:/tool/yocto/build/zc706/tmp/deploy/ipk/armv7a-vfp-neon/busybox_1.22.1-r0_armv7a-vfp-neon.ipk. Installing update-alternatives-opkg (0.1.8+git0+c33b217016-r0) to root... Downloading file:/tool/yocto/build/zc706/tmp/deploy/ipk/armv7a-vfp-neon/update-alternatives-opkg_0.1.8+git0+c33b217016-r0_armv7a-vfp-neon.ipk. Installing libc6 (2.19-r0) to root... Downloading file:/tool/yocto/build/zc706/tmp/deploy/ipk/armv7a-vfp-neon/libc6_2.19-r0_armv7a-vfp-neon.ipk. Installing busybox-syslog (1.22.1-r0) to root... Downloading file:/tool/yocto/build/zc706/tmp/deploy/ipk/armv7a-vfp-neon/busybox-syslog_1.22.1-r0_armv7a-vfp-neon.ipk. sh: 1: /tmp/opkg-RUBbug/busybox-syslog-FMmuzB/preinst: Permission denied update-alternatives: Linking /tool/yocto/build/zc706/tmp/work/zc706_zynq7-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs//usr/bin/ar to /bin/busybox.nosuid update-alternatives: Linking /tool/yocto/build/zc706/tmp/work/zc706_zynq7-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs//bin/gunzip to /bin/busybox.nosuid snip update-alternatives: Linking /tool/yocto/build/zc706/tmp/work/zc706_zynq7-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs//usr/bin/vlock to /bin/busybox.suid Configuring libc6. Configuring update-alternatives-opkg. Configuring update-rc.d. Configuring busybox. Collected errors: * preinst_configure: Aborting installation of run-postinsts. * opkg_install_cmd: Cannot install package run-postinsts. * preinst_configure: Aborting installation of busybox-syslog. * opkg_install_cmd: Cannot install package packagegroup-core-boot. ERROR: Function failed: do_rootfs ERROR: Logfile of failure stored in: /tool/yocto/build/zc706/tmp/work/zc706_zynq7-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.2749 ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 1728 tasks of which 1727 didn't need to be rerun and 1 failed. No currently running tasks (1727 of 1729) Setting it to rpm works. I ran into this issue recently. I’m using Ubuntu-12.10 as the host. I recall things used to work file with package_ipk earlier, but with recent releases, the build process only works with package_rpm. Regards, Elvis Dowson signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [poky] WARNING: QA Issue: ELF binary has relocations in .text
-linux/usr/bin/qemu-system-arm' 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-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-io' 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-arm' 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/lib/qemu/qemu-bridge-helper' has relocations in .text NOTE: Tasks Summary: Attempted 1938 tasks of which 988 didn't need to be rerun and all succeeded. Summary: There were 20 WARNING messages shown. real20m47.466s user0m8.620s sys 0m0.904s Regards, Elvis Dowson signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Server specs for a continuous integration system
I use a 3770K i7 quad-core processor, 16GB RAM, with a liquid cooled solution running at 3.8GHz. I've overclocked the CPU to 4.5GHz, but I end up shaving only 2 minutes off build times, so I just run it at 3.8GHz. A core-image-minimal build takes around 22 minutes for me, for a Xilinx ZC702 machine configuration (Dual ARM Cortex A9 processor + FPGA). Is it a full build from scratch (cross-toolchain, native stuff, etc...)? If so, it's quite impressive to me! Yes, it is a full build from scratch, and the core-image-minimal builds the cross tool chain, kernel and root file system. A full kernel build from scratch completes in under 1 or 2 minutes, can't remember exactly, will let u know in a while. This represents approximately 1600 tasks. A full meta-toolchain-sdk task takes about 40 minutes and executes around 3600 tasks. I'll send some precise figures later on. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Server specs for a continuous integration system
Hi, On Sep 3, 2013, at 3:29 AM, Christian Gagneraud chg...@gna.org wrote: Isn't RAID-5 going to be slower, especially if it's software? RAID 1 is probably better as you'll potentially double the write speed to disk. I use a couple of Vertex SSDs in RAID 1 giving a theoretical write speed near to 1GBs. Write endurance is possibly a concern, but I've not had any issues using them on a local build machine. I would probably look at some higher end models if I was going to run a lot of builds. A lot less noise than hard drives ;-) Thanks for the info, i will have a look at RAID-1, as you can see, I know absolutely nothing about RAID! ;) Does SSD really help with disk throughput? Then what's the point of using ramdisk for TMPDIR/WORKDIR? If you fully work in RAM, the disk bottleneck shouldn't be such a problem anymore (basically, on disk, you should only have your yocto source tree and your download directory?). I use a Gigabyte Z77X-UP5TH motherboard http://www.gigabyte.us/press-center/news-page.aspx?nid=1166 which has support for RAID in BIOS, at boot up, and Thunderbolt connected to an Apple 27 Thunderbolt display. I've got two SSDs in a RAID1 configuration (striped). If you can wait for some more time, they'll be releasing a version of the motherboard for the new haswell chips as well, but it's not probably going to increase performance. I use a 3770K i7 quad-core processor, 16GB RAM, with a liquid cooled solution running at 3.8GHz. I've overclocked the CPU to 4.5GHz, but I end up shaving only 2 minutes off build times, so I just run it at 3.8GHz. A core-image-minimal build takes around 22 minutes for me, for a Xilinx ZC702 machine configuration (Dual ARM Cortex A9 processor + FPGA). Here are the modifications that I've done to my system, to tweak SSD performance, for Ubuntu-12.10, for a RAID1 array. SSD performance tweaks (for non RAID0 arrays) Step 01.01: Modify /etc/fstab. $ sudo gedit /etc/fstab Increase the life of the SSD by reducing how much the OS writes to the disk. If you don't need to knowwhen each file or directory was last accessed, add the following two options to the /etc/fstab file: noatime, nodiratime To enable TRIM support to help manage disk performance over the long term, add the following option to the /etc/fstab file: discard The /etc/fstab file should look like this: # / was on /dev/sda1 during installation UUID=---- / ext4 discard,noatime,nodiratime,errors=remount-ro 0 1 Move /tmp to RAM # Move /tmp to RAM none/tmptmpfs defaults,noatime,nodiratime,noexec,nodev,nosuid 0 0 See: Guide software RAID/LVM TRIM support on Linux for more details. Step 01.02: Move the browser's cache to a tmpfs in RAM Launch firefox and type the following in the location bar: about:config Right click and enter a new preference configution by selecting the New-String option. Preference name:browser.cache.disk.parent_directory string value: /tmp/firefox-cache See: Running Ubuntu and other Linux flavors on an SSD « Brizoma. Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] Rename branch standard/arm-versatile-926ejs to standard/qemuarm
On Sep 2, 2013, at 7:16 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: kernel patches, definitely, send them here. If you are talking about patches to runqemu, and related infrastructure, to start the boot, then send them to oe-core, and chances are they won't be accepted at this point in the dev cycle. If you have a machine.conf and board layer, then we need to find it a home while we figure out how to get the support into core. But I'd definitely like to see those changes as well, even if they are from a github or other externally hosted layer. As for the configuration, you can send it along as a defconfig, but I'll need to factor it out into a board fragment, since we don't maintain full defconfigs for boards that boot from linux-yocto. I can demonstrate how to factor it down to a fragment, if you haven't already done it. Yes, please. I've attached a defconfig generated based on the arm-versatile branch here. If you can show me how to factor it to a config fragment, it would be great and I'll send a patch accordingly for modifying the meta data for qemuarma9. 002-defconfig-vexpress-a9-linux-yocto-3.10-standard-arm-versatile-926ejs-1.0 Description: Binary data Elvis Dowson ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] Rename branch standard/arm-versatile-926ejs to standard/qemuarm
On Sep 1, 2013, at 8:08 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-08-31 2:46 PM, Elvis Dowson wrote: Hi, In preparation for adding additional qemuarm machine configurations to the linux-yocto kernels, can we rename the existing standard/arm-versatile-926ejs branch to standard/qemuarm? As I've mentioned before, there's absolutely no reason to do this, the branch name represents the machine support for the versatile and qemuarm re-uses it. So it can stay as is. If we add QEMU support for newer ARM architectures, like Cortex A8, A9 and A15, it's a bit confusing, and not immediately obvious if one should using a kernel branch intended for an old ARM v5 instruction set branch. At least for me, the first time I saw it, my first reaction was this must be old and incompatible. Changing it to a generic form such as standard/qemuarm, like it's done for the other architectures, e.g. standard/qemuppc, gives a better indication that it can potentially support a set of generic arm architectures, purely from a naming perspective. I would strive for branch naming consistency, for the qemu architectures. Also, can we merge all the changes from the standard/base branch into this branch? This happens for every single branch in the repository. I'm preparing a set of patches for qemuarma9 support for linux-yocto-3.10, and would like the qemuarm branch updated, before releasing the patches, if possible. It's full up to date .. at all times :) Ok, I've just built and tested a qemuarma9 machine configuration, with a separate defconfig, shall I send across the patches? Elvis Dowson ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] Yocto reference manual missing entries for MACHINE_DEVICETREE and KERNEL_DEVICETREE
Hi Scott, I noticed that the yocto reference manual is missing entries for MACHINE_DEVICETREE and KERNEL_DEVICETREE variables. I was trying to find out what the difference between the two were, and discovered that it's not described in the reference manual here: http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to work with linux-yocto kernel
Hi, I just don't understand how to work with the linux-yocto kernel. For example, I created a local copy of the yocto kernel, and updated the linux-yocto_3.8.bb recipe to point to the local copy (git:///path;protocol=file, etc) Then I created a local branch meta, and another local branch standard/qemuarma9 and then updated the machine definitions in the meta branch for qemuarma9. When I run yocto, and bitbake linux-yocto, in the tmp folder, if I check the git branch, it's checked out standard/common-pc/atom-pc. This is really weird. I've wasted a couple of days because the yocto build infrastructure was checkout out the wrong branch. Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to work with linux-yocto kernel
Hi Bruce, On Aug 28, 2013, at 9:52 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: There were some old bugs which caused the wrong board description to be picked up, the seems similar. But without seeing your exact changes, as they sit in the tree, I can't be sure. Did you also update the meta and machine branch SRCREVs ? No, I didn't. I've just done this now. It's only after you mentioned it that I noticed the SRCREV_meta variable in linux-yocto_3.8.bb While obvious, once stated, it's better to explicitly document this step in the kernel development guide, so that people remember to do it: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html BTW, in qemuarma9-standard.scc, for the branch, do I specify standard/qemuarma9 or just qemuarma9 ? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to work with linux-yocto kernel
On Aug 28, 2013, at 10:07 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 13-08-28 02:05 PM, Elvis Dowson wrote: Hi Bruce, On Aug 28, 2013, at 9:52 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: There were some old bugs which caused the wrong board description to be picked up, the seems similar. But without seeing your exact changes, as they sit in the tree, I can't be sure. Did you also update the meta and machine branch SRCREVs ? No, I didn't. I've just done this now. It's only after you mentioned it that I noticed the SRCREV_meta variable in linux-yocto_3.8.bb While obvious, once stated, it's better to explicitly document this step in the kernel development guide, so that people remember to do it: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html If you have a moment, drop a quick bugzilla and we can make sure that happens. I've just done this now. https://bugzilla.yoctoproject.org/show_bug.cgi?id=5065 Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-yocto defaulting to 3.4.52 for new qemuarmhf.conf
Hi Bruce,
On Aug 25, 2013, at 9:22 AM, Bruce Ashfield bruce.ashfi...@windriver.com
wrote:
Another quick question, why is it that when I create a new qemuarmhf.conf
machine configuration, it doesn't automatically pick up the latest
linux-yocto_3.8.bb recipe? Why does it attempt to use the 3.4 recipe?
Are you working off master ?
Since you set the compatibility, it should have been picked. But something
else must be changed in your layers, since if you didn't add
3.4 compatibility via bbappends, it never would have been selected
at all.
Yes, I'm currently working off master. If I add the following qemuarmhf.conf
file, and apply the patch to linux-yocto_3.8.bb, it still tries to compile
linux-yocto_3.4.bb recipe. You should be able to reproduce this fairly easily
at your end, with the current poky master. I'm not using any additional layers,
just the core yocto default layers.
Filename: qemuarmhf.conf
#@TYPE: Machine
#@NAME: qemuarmhf
#@DESCRIPTION: Machine configuration for QEMU ARM Cortex A9 hard float.
require conf/machine/include/qemu.inc
require conf/machine/include/tune-cortexa9.inc
KERNEL_IMAGETYPE = zImage
SERIAL_CONSOLE = 115200 ttyAMA0
Patch for linux-yocto_3.8.bb
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
index 790e3e3..787affe 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.8.bb
@@ -4,6 +4,7 @@ KBRANCH_DEFAULT = standard/base
KBRANCH = ${KBRANCH_DEFAULT}
SRCREV_machine_qemuarm ?= aa76cc28408376814752bd36fb0dcf0e25aa5ba3
+SRCREV_machine_qemuarmhf ?= aa76cc28408376814752bd36fb0dcf0e25aa5ba3
SRCREV_machine_qemumips ?= aa0affda03c955678b26b2fb586f1d9505127871
SRCREV_machine_qemumips64 ?= 077bff22c9951db6b35470ba17b1df2f2a91fefb
SRCREV_machine_qemuppc ?= 698eada61d9385b42dd117858b943655b565084b
@@ -21,7 +22,7 @@ PV = ${LINUX_VERSION}+git${SRCPV}
KMETA = meta
-COMPATIBLE_MACHINE = qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64
+COMPATIBLE_MACHINE =
qemuarm|qemuarmhf|qemux86|qemuppc|qemumips|qemumips64|qemux86-64
# Functionality flags
KERNEL_EXTRA_FEATURES ?= features/netfilter/netfilter.scc
Best regards,
Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] QEMU with ARM Cortex A9 hard float with NEON
Hi, I'm trying to build a QEMU machine configuration with support for ARM Cortex A9, with hard float and neon support. What should I specify in my qemuarmhf.conf machine file to enable a specific tune configuration defined in tune-cortexa9.inc ? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] linux-yocto defaulting to 3.4.52 for new qemuarmhf.conf
Hi, I created a new qemuarmhf.conf, to build using armv7a vfp and neon. In the linux-yocto_3.8.bb recipe, I explicitly specified SRCREV_machine_qemuarmhf and added qemuarmhf to the list of COMPATIBLE_MACHINES. For some reason, it still refuses to build using kernel 3.8, and keeps defaulting to 3.4.52. I know I can over-ride it in my local.conf by setting a PREFERRED_VERSION_virtual/linux =3.8 , but I'd like to know what I've missed, to get it to work by default, without setting the over-ride in my local.conf. Thanks! Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-yocto defaulting to 3.4.52 for new qemuarmhf.conf
On Aug 24, 2013, at 10:00 PM, Elvis Dowson elvis.dow...@gmail.com wrote: I created a new qemuarmhf.conf, to build using armv7a vfp and neon. In the linux-yocto_3.8.bb recipe, I explicitly specified SRCREV_machine_qemuarmhf and added qemuarmhf to the list of COMPATIBLE_MACHINES. For some reason, it still refuses to build using kernel 3.8, and keeps defaulting to 3.4.52. I know I can over-ride it in my local.conf by setting a PREFERRED_VERSION_virtual/linux =3.8 , but I'd like to know what I've missed, to get it to work by default, without setting the over-ride in my local.conf. Weird, even after setting PREFERRED_VERSION_virtual/linux =3.8, it still picks up linux-yocto_3.4.bb recipe! What am I failing to set or configure additionally to get it to work, as intended? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-yocto defaulting to 3.4.52 for new qemuarmhf.conf
Hi Bruce, On Aug 25, 2013, at 4:57 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: I created a new qemuarmhf.conf, to build using armv7a vfp and neon. In the linux-yocto_3.8.bb recipe, I explicitly specified SRCREV_machine_qemuarmhf and added qemuarmhf to the list of COMPATIBLE_MACHINES. For some reason, it still refuses to build using kernel 3.8, and keeps defaulting to 3.4.52. I know I can over-ride it in my local.conf by setting a PREFERRED_VERSION_virtual/linux =3.8 , but I'd like to know what I've missed, to get it to work by default, without setting the over-ride in my local.conf. Weird, even after setting PREFERRED_VERSION_virtual/linux =3.8, it still picks up linux-yocto_3.4.bb recipe! Try 3.8%, you need to match on the version completely, and it is 3.8, not just 3.8. Ok, I forgot about that! Another quick question, why is it that when I create a new qemuarmhf.conf machine configuration, it doesn't automatically pick up the latest linux-yocto_3.8.bb recipe? Why does it attempt to use the 3.4 recipe? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Recipe for building an Ubuntu-12.04 root filesystem
Hi, Does anyone know how to create a recipe for building an Ubuntu-12.04 root filesystem image? The Ubuntu and Linaro websites don’t document how the actual binary *.deb packages were created, the just document the process of assembling a rootfs from deb binary package feeds. I’m aware that Yocto/OpenEmbedded can be used to generate *.deb packages, but what isn’t clear to me is how one can go about assembling a basic Ubuntu rootfs image that will boot into the Ubuntu Unity interface. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recipe for building an Ubuntu-12.04 root filesystem
Hi Nicolas, On Aug 21, 2013, at 4:50 AM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Wed, Aug 21, 2013 at 2:24 AM, Elvis Dowson elvis.dow...@gmail.com wrote: The Ubuntu and Linaro websites don’t document how the actual binary *.deb packages were created, the just document the process of assembling a rootfs from deb binary package feeds. I’m aware that Yocto/OpenEmbedded can be used to generate *.deb packages, but what isn’t clear to me is how one can go about assembling a basic Ubuntu rootfs image that will boot into the Ubuntu Unity interface. the short answer is that Ubuntu is not built with OE/Yocto, so you can't do that. OE/Yocto can help you build a filesystem for your target, that's what it's here for, but it won't generate an Ubuntu image. it is correct that OE can generate .deb (or .rpm or .ipk) packages, but the generated packages won't be compatible on an Ubuntu system (you won't be able to install and satisfy dependencies). Ubuntu is a 'binary' based distribution. All Ubuntu packages are built on a centralized server (Launchpad), natively on 'actual' hardware. Ubuntu packages for ARM are indeed build on ARM build slaves hosted by Canonical. Launchpad offers 'PPA' (personal package archive) where users can upload their 'source package' and expect them to be built on Canonical build infrastructure. This is the mechanism that was by at Linaro to build ARM .deb packages. Note that since this is a binary distribution nobody rebuilds the entire image from scratch, instead packages are built individually whenever there is a change in the package, and the process of making an image (like Ubuntu daily image, or Linaro Ubuntu images) is just to 'assemble' existing binary .deb packages all together. OE/Yocto is a set of 'tools' and recipes to let you create and customize your own distribution. You can create 'rebuild from scratch' distro with OE, or you can even create a 'binary' distribution if you need that. Is there a way to replicate the build infrastructure locally in my environment? I have a quad core i.MX6 platform. Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Recipe for Gnome Unity Interface
Hi, Has anyone developed a recipe for building a Gnome Unity Interface? https://github.com/chenxiaolong/Unity-for-Arch Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fedora 18 CentOS 6.4 yocto difference zc702
Hi Edward, On Jul 3, 2013, at 11:05 PM, Edward Vidal vidal.devel...@gmail.com wrote: Hello, I recently built core-image-minimal for zc702. This generated a file with a dtb extension that I have not seen before uImage--3.8-xilinx+git0+6a0bedad60-r1-zynq-zc702-20130703173428.dtb. Can anyone tell me more about the this extension. The *.dts and *.dtb files are related to the device tree source and binary formats. When you work with a hardware project using the Xilinx ISE 14.6/Vivado 2013.2 tools, a dts file will be create. This contains the base address and other parameters for each device peripheral, e.g. serial ports, video controller, etc. The yocto build system takes these files and generates the required *.dtb file. Please refer the Zynq Base TRD 14.6 document, (you can quickly scan through the document and fast forward to section 8.2, for building a dtb file from a dts file) http://www.wiki.xilinx.com/Zynq+Base+TRD+14.6-beta Where do you find the boot.scr or uEnv.txt for the zc702? I built this on both a CentOS 6.4 and a Fedora18 x86_64 system. meta-yocto= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e meta-xilinx meta-kc705 meta-zc702 meta-zedboard = (nobranch):b065f091f10060f2bb68b58f1d618e26a966fee2 meta-yocto-bsp= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e The latest version of poky that I downloaded commit 8a186a6b3853fc1a7dcf342d421c8926c38949c9 Author: Cristiana Voicu cristiana.vo...@intel.com Date: Mon Jul 1 08:09:52 2013 + bitbake: hob: save button from settings called a nonexisting method The method was removed when the process for saving configuration in Hob was changed. Replace the call with the right function. [YOCTO #4793] (Bitbake rev: b6aa2b63d71cbe82850a375381b2dbc750cf1905) Signed-off-by: Cristiana Voicu cristiana.vo...@intel.com Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org causes the following error on both CentOS 6.4 and Fedora 18 . oe-init-build-env BitBake requires Python 2.7.3 or later CentOS 6.4 has a non standard location of python. Does anyone know how to tell bitbake of the non standard location of python. This latest version of poky that I downloaded on fedora18 causes the following error. MACHINE=zc702 bitbake core-image-minimal -vDD ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version. ERROR: Execution of event handler 'check_sanity_eventhandler' failed This version of poky and meta-xilinx worked okay. meta meta-yocto= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e meta-xilinx meta-kc705 meta-zc702 meta-zedboard = (nobranch):b065f091f10060f2bb68b58f1d618e26a966fee2 meta-yocto-bsp= (nobranch):04af378874f38d1200bea2fa191beeae94232d6e MACHINE=zc702 bitbake core-image-minimal -vDD NOTE: Tasks Summary: Attempted 1530 tasks of which 306 didn't need to be rerun and all succeeded. We are trying to determine which board to purchase the Xilinx Zynq-7000 SoC ZC702 Evaluation Kit EK-Z7-ZC702-G $895.00 or AES-Z7EV-7Z020-G ZEDBOARD ZYNQ BOARD AES-Z7EV-7Z020-G ECCN Avnet Design Services - Custom $395.00 Does anyone have any experience with either of these boards? From a support standpoint, both the ZC702 and Zedboard are supported really well. You will find that most of the Xilinx reference design and application notes usually always target the ZC702. If you get a Zedboard you'll need to take the extra effort to adapt the pin constraints file. Also the ZC702 has two FMC LPC connectors rather than 1 FMC LPC connector, if that's more important for you. My recommendation would be to go in for the ZC702 or the ZC706 if you need more logic density. Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fedora 18 CentOS 6.4 yocto difference zc702
Hi, On Jul 4, 2013, at 3:25 AM, Edward Vidal vidal.devel...@gmail.com wrote: Where do you find the boot.scr or uEnv.txt for the zc702? I haven't seen one for the ZC702. You could use one of the prebuilt boot images (e.g. the Base TRD 14.5 or 14.6 beta packages), put it into the SD card slot, interrupt the boot process and type printenv, and list out all the u-boot environment variables and copy it out to create your own boot.scr file. The boot args are stored in the *.dts file, so look up the dts file for the zynq board in the TRD or the Xilinx linux kernel distro. Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-xilinx moved to meta-xilinx-community
Hi, The existing meta-xilinx repo has moved to meta-xilinx-community http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx-community/ This layer will contain community support for the Xilinx platforms, including legacy boards (ML507) and other soft-processor architectures. This paves the way for an officially supported meta-xilinx layer, the details of which will be officially announced by Xilinx. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems building yocto for Xilinx ML507 (with some tentative fixes)
Hi Andrea, On May 10, 2013, at 6:02 PM, Andrea Sterbini a.sterb...@tiscali.it wrote: The problems I have found (and someway fixed) are: 1) when I do bitbake meta-toolchain I get an error complaining that the compiler is not able to build for powerpc with FPU Fix: I have changed the ml507 rules to include just the soft FPU I never did get soft-float to work properly with gcc-4.6 or gcc-4.7. I got soft-float to work with gcc-4.5.4. hard float fpu support worked with gcc-4.7. Were you able to boot and login to the command prompt with the generated images ? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-xilinx] PREFERRED_VERSION_linux-libc-headers = 3.6 getting ignored
Hi, In my zynq-7-default-versions.inc file, I have the following definitions for preferred versions PREFERRED_VERSION_virtual/kernel ?= 3.6 PREFERRED_VERSION_linux-libc-headers = 3.6 PREFERRED_VERSION_u-boot = 2012.10 However, when I build core-image-minimal, PREFERRED_VERSION_linux-libc-headers = 3.6 gets ignored and it goes ahead and builds linux-libc-headers_3.8.bb Is it only effective if specified in the local.conf file? Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [poky] bash: oe-init-build-env: line 33: syntax error near unexpected token `elif'
Hi, The following commit http://ares/gitweb/?p=tools/poky.git;a=blobdiff;f=oe-init-build-env;h=68af7b5193b73627cd6ebf6196adfa685a787c38;hp=67eddcd295bd9d1adac21fc4e97506fca05f4bfa;hb=813127247a1100b1abe179dfba25795560eac864;hpb=a468b0d5579148771da716eaf357e5d45fc3211c is causing a build error while sourcing the oe-init-build-env build script $ cd /tool/yocto/poky;source oe-init-build-env build : command not found : command not found bash: oe-init-build-env: line 33: syntax error near unexpected token `elif' 'ash: oe-init-build-env: line 33: ` elif [ -n $ZSH_NAME ]; then This is on Ubuntu 12.10 x86 64-bit. Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [poky] bash: oe-init-build-env: line 33: syntax error near unexpected token `elif'
On Apr 18, 2013, at 8:12 PM, Elvis Dowson elvis.dow...@gmail.com wrote: On Apr 18, 2013, at 7:58 PM, Trevor Woerner twoer...@gmail.com wrote: On Thu, Apr 18, 2013 at 11:37 AM, Elvis Dowson elvis.dow...@gmail.com wrote: http://ares/gitweb/?p=tools/poky.git;a=blobdiff;f=oe-init-build-env;h=68af7b5193b73627cd6ebf6196adfa685a787c38;hp=67eddcd295bd9d1adac21fc4e97506fca05f4bfa;hb=813127247a1100b1abe179dfba25795560eac864;hpb=a468b0d5579148771da716eaf357e5d45fc3211c Do you have a better link? http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/oe-init-build-env?id=813127247a1100b1abe179dfba25795560eac864 I reverted the commit, but the error still persisted. It's something else, probably due to a recent update to Ubuntu 12.10. I tried reverting to known commit ids but all of them don't work. My shell is correctly configured to use bash instead of dash. When I ran the debug mode for the bash shell, I found out that the : command not found : command not found errors were due to the new lines on line 2 and line 20. Deleting the new lines made the : command not found errors go away, but I get the following error with the older commit bash: ./oe-init-build-env: line 45: syntax error: unexpected end of file and the following error with the current master bash: ./oe-init-build-env: line 33: syntax error near unexpected token `elif' 'ash: ./oe-init-build-env: line 33: ` elif [ -n $ZSH_NAME ]; then Man, this is so un-expected!! :-) Okay, false alarm, sorry about that. I noticed that when I pull the latest updates, something went wrong and there were a lot of modified files after the update in red. I did a git clean -df and git reset --hard, and it solved the problem. Don't know how that happened though, but problem fixed by resetting the git repo and cleaning all the dirty files. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [poky] bash: oe-init-build-env: line 33: syntax error near unexpected token `elif'
Hi, I think I know what happened. I briefly setup autocrlf=true in the global .gitconfig last week, and when I pull in all the latest commits, it ended up adding CRLF, and ended up causing issues. Even after disabling it, the damage already done to the local poky repository. Luckily I had backups. This shouldn't have happened to with git! Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build problems with ML507 and meta-xilinx
Hi Andrew, On Apr 12, 2013, at 12:34 PM, Andrew James andrew.james77...@gmail.com wrote: I wonder if someone can help me. I'm attempting to do a yocto build for the ML507 xilinx development board and am running into build error when building eglibc I'm using VMWARE Player running an Ubuntu 12.10 64-bit virtual machine. I can succesfully build core-image-minimal using the default settings, but when trying to build for the ML507 (MACHINE = virtex-5-ml507-powerpc-440 I get a build error when compiling eglibc, '440fp not supported' I have used git to get the 'danny' version of the yocto directories. Any help would be appreciated, I can provide futher details if neccessary I was able to get Yocto to build soft fpu (gcc-4.5) and hard fpu (gcc-4.7) support, a couple of months back. Here are some instructions Step 01: Modfy your bblayers.conf file to include the following repositories BBLAYERS ?= \ /tool/yocto/poky/meta \ /tool/yocto/poky/meta-yocto \ /tool/yocto/meta-openembedded/toolchain-layer \ /tool/yocto/meta-xilinx \ Step 02: Modify your local.conf file XILINX_LOC ?= /tool/xilinx/14.3/ISE_DS MACHINE ?= virtex-5-ml507-powerpc-440 XILINX_BSP_PATH ?= /project/xilinx-ml507-base-trd-ppc440-fpu If you use the EDK BSB to create a default project with APU FPU support, it should be sufficient. Step 03: Checkout specific commits ids for each of the repositories poky: commit id: 2a9c574fd8b0800199b6569b6abf02634801013d meta-openembedded: commit id: ef5e1d752003e70d30ce8462c3cd09ce3794d783 meta-xilinx: commit id: c8ad57010f189d6b072ca193a88fd1ff551c5644 http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/log/ Let me know if you run into any more issues. I will need to get around to updating support for the ML507 against the current poky master danny branches in a couple of weeks. Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-xilinx][PATCH] layer.conf: avoid unnecessary early expansion with :=
applied
http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/commit/?id=bbe2cb495fdbfc31eea422021548c0c95401c11a
On Mar 19, 2013, at 6:13 AM, Christopher Larson kerg...@gmail.com wrote:
From: Christopher Larson chris_lar...@mentor.com
bitbake handles immediate expansions of LAYERDIR for us automatically.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
conf/layer.conf | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/conf/layer.conf b/conf/layer.conf
index d1a1a84..f415d2f 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -1,12 +1,12 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := ${BBPATH}:${LAYERDIR}
+BBPATH .= :${LAYERDIR}
require conf/distro/include/xilinx-default-revisions.inc
# We have a packages directory, add to BBFILES
-BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend
BBFILE_COLLECTIONS += xilinx
-BBFILE_PATTERN_xilinx := ^${LAYERDIR}/
+BBFILE_PATTERN_xilinx = ^${LAYERDIR}/
BBFILE_PRIORITY_xilinx = 6
--
1.8.2
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] arch and tune files for microblaze processor
Hi Khem,
I'm trying to expand on the initial arch and tune files
defined for the microblaze processor within the meta-xilinx layer.
I was wondering if you could help review the arch and tune files, to see if
there are any glaring mistakes, possible areas for improvement or mistakes in
the naming convention.
The microblaze processor is a 32-bit processor, supporting combinations of
big-endian and little-endian, plus hard-float and soft-float for the FPU.
http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_4/mb_ref_guide.pdf
http://gcc.gnu.org/onlinedocs/gcc/MicroBlaze-Options.html
I've listed the main arch-microblaze.inc (big-endian, hard-float),
tune-microblazeel (little-endian, hard-float), and a machine conf that uses
these files (spartan-6-sp601-microblazeel.conf)
File: arch-microblaze.inc
# Microblaze ABI interface definition
# Four defined ABIs, all combinations of:
# *) Hard/Soft Floating Point
# *) Big Endian (PLB System) / Little Endian (AXI System)
DEFAULTTUNE ?= microblaze
TUNE_PKGARCH = ${TUNE_PKGARCH_tune-${DEFAULTTUNE}}
ABIEXTENSION ?=
TUNEVALID[m32] = Microblaze ELF32 standard ABI
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m32, -m32, , d)}
TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, m32, microblaze, ,
d)}
TUNEVALID[mbig-endian] = Microblaze Big Endian processor
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mbig-endian,
-mbig-endian, , d)}
TUNEVALID[mlittle-endian] = Microblaze Little Endian processor
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mlittle-endian,
-mlittle-endian, , d)}
TUNEVALID[fpu-soft] = Use software FPU.
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, fpu-soft,
-msoft-float, , d)}
TARGET_FPU .= ${@bb.utils.contains(TUNE_FEATURES, fpu-soft, soft, ,
d)}
TUNEVALID[fpu-hard] = Use hardware FPU.
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, fpu-hard,
-mhard-float, , d)}
TUNE_PKGARCH ?= ${TUNE_ARCH}
# Basic tune definitions
AVAILTUNES += microblaze
TUNE_FEATURES_tune-microblaze ?= m32 mbig-endian fpu-hard
BASE_LIB_tune-microblaze = lib
TUNE_PKGARCH_tune-microblaze = microblaze
PACKAGE_EXTRA_ARCHS_tune-microblaze = microblaze
File: tune-microblazeel.inc
# Tune options for MicroBlaze little endian hard-float
DEFAULTTUNE ?= microblazeel
require conf/machine/include/microblaze/arch-microblaze.inc
TUNEVALID[microblazeel] = Enable MicroBlaze little endian hard-float
optimizations
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, microblazeel,
-mcpu=v8.10a, , d)}
TUNE_PKGARCH = ${@bb.utils.contains(TUNE_FEATURES, microblazeel,
microblazeel, microblazeel, d)}
AVAILTUNES += microblazeel
TUNE_FEATURES_tune-microblazeel ?= m32 mlittle-endian fpu-hard microblazeel
BASE_LIB_tune-microblazeel = lib
PACKAGE_EXTRA_ARCHS_tune-microblazeel = microblazeel
File: spartan-6-sp601-microblazeel.conf
# Copyright (C) 2013, Elvis Dowson xx...@xx.xx
# Released under the MIT license (see packages/COPYING)
#@TYPE: Machine
#@Name: spartan-6-sp601-microblazeel
#@DESCRIPTION: Machine configuration for the Xilinx Spartan-6 SP601 FPGA
development platform with a MicroBlaze Little Endian processor (with FPU).
# Specify target cpu
TARGET_CPU = microblaze
# Specify tune for the MicroBlaze litte endian CPU
include conf/machine/include/tune-microblazeel.inc
# Specify common settings.
include conf/machine/include/spartan-6/spartan-6-base.inc
# Specify linux kernel devicetree
KERNEL_DEVICETREE = ${S}/arch/microblaze/boot/dts/sp601_le.dts
# Specify u-boot machine configuration
UBOOT_MACHINE ?= microblaze-generic_config
UBOOT_ENTRYPOINT ?= 0xa800
UBOOT_LOADADDRESS ?= 0xa800
# Specify machine features
MACHINE_FEATURES = kernel26 apm ext2 ext3 vfat ethernet serial
#MACHINE_FEATURES_BACKFILL_CONSIDERED = rtc
# Specify the Xilinx board name
XILINX_BOARD = sp601
# Xilinx EDK override hardware definitions for xilinx-bsp
# Include the following environment variables in your local.conf
# XILINX_BSP_PATH = complete path to the Xilinx XPS project
# Specify serial console settings
# Don't use tty1
# USE_VT = 0
SERIAL_CONSOLE ?= 115200 ttyUL0
# Device nodes add xsa for (system ace)
IMAGE_DEVICE_TABLES = files/device_table_add-xsa.txt
Best regards,
Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze
Hi Khem, After patching both gcc-4.7.2 and gcc-4.8.0, I get the following error. This looks like a common error, and I was wondering if there is something that needs to be additionally taken into consideration, in the poky gcc recipes (gcc-configure-*.inc) to get it to work for the microblaze processor? The output log is from the gcc-4.8.0 build, but the same message persists with the gcc-4.7.2 adapted build with the microblaze patches: | checking for microblaze-poky-linux-gcc... /tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.8.0-r01/gcc-4.8.0/build.x86_64-linux.microblaze-poky-linux/./gcc/xgcc -B/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.8.0-r01/gcc-4.8.0/build.x86_64-linux.microblaze-poky-linux/./gcc/ -m32 -isystem/tool/yocto/poky/build/tmp/sysroots/spartan-6-sp601-microblaze/usr/include -B/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/bin/ -B/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/lib/ -isystem /tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/include -isystem /tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/sys-include --sysroot=/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.8.0-r01/gcc-4.8.0/build.x86_64-linux.microblaze-poky-linux/tmpsysroot | checking for suffix of object files... configure: error: in `/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.8.0-r01/gcc-4.8.0/build.x86_64-linux.microblaze-poky-linux/microblaze-poky-linux/libgcc': | configure: error: cannot compute suffix of object files: cannot compile | See `config.log' for more details. | make: *** [configure-target-libgcc] Error 1 | ERROR: oe_runmake failed | ERROR: Function failed: do_compile (see /tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.8.0-r01/temp/log.do_compile.32684 for further information) Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze
/sysroots/x86_64-linux
--with-newlib --without-headers --disable-shared --disable-threads
--disable-multilib --disable-__cxa_atexit --enable-languages=c
--enable-target-optspace --program-prefix=microblaze-poky-linux-
--with-sysroot=/tool/yocto/poky/build/tmp/sysroots/spartan-6-sp601-microblaze
--with-build-sysroot=/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/tmpsysroot
--disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath
--with-system-zlib --disable-lto --disable-
plugin --enable-decimal-float=no --disable-nls --enable-__cxa_atexit
Thread model: single
gcc version 4.7.2 (GCC)
configure:3355: $? = 0
configure:3344:
/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/./gcc/xgcc
-B/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/./gcc/
-m32-mhard-float
-isystem/tool/yocto/poky/build/tmp/sysroots/spartan-6-sp601-microblaze/usr/include
-B/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/bin/
-B/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/lib/
-isystem
/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/include
-isystem
/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/microblaze-poky-linux/sys-include
--sysroot=/tool/yocto/poky/build/tmp/work/microblaze-poky-linux/gcc-cross-initial/4.7.2-r19/gcc-4.7.2/build.x86_64-linux.microblaze-poky-linux/tmpsysroot
-V 5
xgcc: error: unrecognized command line option '-m32'
xgcc: error: unrecognized command line option '-V'
xgcc: fatal error: no input files
compilation terminated.
The arch-microblaze.inc file snippent is as follows:
DEFAULTTUNE ?= microblaze
TUNEVALID[m32] = Microblaze ELF32 standard ABI
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m32, -m32, , d)}
TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, m32, microblaze, ,
d)}
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze
Hi Khem, Any plans on moving to gcc-4.7.3 or 4.8.0 anytime soon? Nearly all the microblaze gcc patches are for gcc-4.8.0 on the trunk, several of them in fact. I've re-applied and ported all the existing patches that you've created for gcc-4.7.2 to gcc-4.7.3 (not yet tested). So, I was wondering if you'd like me to try to get gcc-4.7.3 or gcc-4.8.0 built against the current poky master branch? I can test ARM Cortex A9, ARM Cortex A8 and Microblaze at my end. Do let me know! Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze
Hi Khem, On Mar 6, 2013, at 6:58 AM, Khem Raj raj.k...@gmail.com wrote: I dont have a public repo for gcc its too big to host. You can just do a normal patch process on gcc in work-shared using quilt That should work I've already started doing this. If I get the compiler support for MicroBlaze built and tested, I'll send across the patches for inclusion. The Xilinx Series -7 FPGAs without an ARM core will require a MicroBlaze processor (Artix-7, Kintex-7 and Virtex-7). The Xilinx mb-gcc toolchain was built using crosstool-ng, but I'd like to build it using Yocto. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Patching gcc-4.7.2 to add support for Xilinx MicroBlaze
Hi Khem, I hope you're doing fine! Could you give me the url to your gcc-4.7.2 git repo, so that I can develop patches against it to add support for the Xilinx MicroBlaze soft-processor? I've hit the following bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54663 and the patches are available with this revision http://gcc.gnu.org/viewcvs?view=revisionrevision=195488 So, I'd like to back port it against the current gcc-4.7.2 recipe revision. Or else, I will have to do a git svn import of the source, and manually patch it using the current list of patches in the yocto recipe, which would take a couple of hours. So if I can have access to your repo, it will save me sometime! Thanks! Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Eclipse IDE Plugin: Configuring cross gcc
Hi, I've build meta-toolchain-sdk and installed the toolchain on a separate machine. I then installed Eclipse, Linux tools, and the Yocto Eclipse IDE Plugin. I configured the Yocto Project ADT to use Standalone Pre-built toolchain, and pointed to the correct toolchain root and sysroot locations. However, when I try to create a simple HelloWorld project, and select cross-gcc, it doesn't set any of the cross-compile prefix or toolchain paths. I have to manually type them once again. What's worse is that the environment-setup-ppc440e-poky-linux script file doesn't seem to be invoked. This causes the gcc sysroot variable not to be set, causing errors during linking. What is the correct way to use the pre-built toolchain, with the eclipse IDE. I want to build on the host, and direct compile for my target board. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Eclipse IDE Plugin: Configuring cross gcc
Hi, On Jan 20, 2013, at 12:15 AM, Flavio Castro Alves Filho flavio.al...@gmail.com wrote: I believe that Yocto ADT plugin only supports Autotools based projects. I tried an Autotools project with a standalone toolchain sdk installed on a separate machine. It was able to reconfigure and build the example. However, I noticed that on the machine where I built the toolchain, the autotools reconfigure project did not work. When I type bitbake meta-ide-support, it generates an environment configuration file, but the sys root variable is not pointing to the correct toolchain x64_64 something. It is pointing to my machine configuration folder, e.g. virtex_5_ml507_powerpc440 This cause the reconfigure steps to fail, and give the same error while configuring the project, i.e. the configure step while attempting to detect the c compiler, and errors out saying no c compiler. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Error: nativesdk-qemu-helper_1.0.bb, do_compile, for gcc-4.5.4 and eglibc-2.13 port against current poky master
Hi, While attempting to maintain the gcc-4.5.4 and eglibc-2.13 recipes, against the current poky master, I ran into the following errors, while running bitbake meta-toolchain: ERROR: Function failed: do_compile (see /tool/yocto/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu-helper/1.0-r9/temp/log.do_compile.16700 for further information) ERROR: Logfile of failure stored in: /tool/yocto/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu-helper/1.0-r9/temp/log.do_compile.16700 Log data follows: | DEBUG: Executing shell function do_compile | tunctl.c:5:19: fatal error: stdio.h: No such file or directory | compilation terminated. | ERROR: Function failed: do_compile (see /tool/yocto/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu-helper/1.0-r9/temp/log.do_compile.16700 for further information) ERROR: Task 590 (/tool/yocto/poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb, do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 1196 tasks of which 1190 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: Summary: 1 task failed: /tool/yocto/poky/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb, do_compile Summary: There was 1 ERROR message shown, returning a non-zero exit code. How can I fix this error? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ERROR: locale-base-tt-ru is listed in PACKAGES multiple times, this leads to packaging errors.
Hi, While attempting to maintain the gcc-4.5.4 and eglibc-2.13 recipes, against the current poky master, I ran into the following errors, while running bitbake meta-toolchain: ERROR: locale-base-tt-ru is listed in PACKAGES multiple times, this leads to packaging errors. How can I fix this error? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using SRC_URI_append with SOC_FAMILY
Hi,
I have defined the following variables defined
SOC_FAMILY = virtex-5 in my virtex-5.inc file, which is included by my
virtex-5-ml507-powerpc-440.conf machine configuration file.
I have defined MACHINE=virtex-4-ml507-powerpc-440 in my local.conf file
In my u-boot-xilinx.git recipe, I have defined
FILESPATH = ${@base_set_filespath([ '${FILE_DIRNAME}/${PN}/${SOC_FAMILY}' ],
d)}
COMPATIBLE_MACHINE = (virtex-5|microblaze)
I will have multiple machine configurations, each of which will use either the
virtex-5 or microblaze SOC_FAMILY.
How can I specify SRC_URI_append, so that it appends based on the SOC_FAMILY,
rather than the machine configuration.
Setting SRC_URI_append_virtex-5 doesn't work (SOC_FAMILY), since the MACHINE
configuration is set to virtex-5-ml507-powerpc-440.
I don't want to end up specifying SRC_URI_append_virtex-5-ml507-powerpc-440,
and so forth for each and every MACHINE configuration that is based on a single
SOC_FAMILY.
What should I do to achieve the desired results, and optimize the recipe so
that it appends patches, based on the SOC_FAMILY, rather than the MACHINE
configuraiton.
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] building for ZYNQ ZC702 SoC
Hi Anup,
Atleast two people on the yocto mailing list have successfully
built the toolchain and rootfile system for the ZC702, Philip Balister and
myself, using the latest yocto master.
Here are a few steps:
01. Look up the Yocto Quick Start Guide to setup your Ubuntu 12.10 x86 64-bit
host development environment.
02. Use Philip Balister's meta-zynq layer located here, and add it to your
bblayer.conf file
https://github.com/balister/meta-zynq
$ gedit conf/bblayers.conf
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = 5
BBPATH = ${TOPDIR}
BBFILES ?=
BBLAYERS ?= \
/tool/yocto/poky/meta \
/tool/yocto/poky/meta-yocto \
/tool/yocto/meta-openembedded/toolchain-layer \
/tool/yocto/meta-zynq \
03. Updated your yocto local.conf file as follows:
#
# Xilinx target board configuration.
#
# Set the target machine details
MACHINE ?= zynq-zc702
# Set Xilinx Platform Studio hardware project path
XILINX_BSP_PATH ?= /project/xilinx-zc702
# Set target board
XILINX_BOARD ?= zc702
04. Download the souces
$ cd /tool/yocto/poky
$ source oe-init-build-env build
### Shell environment set up for builds. ###
You can now run 'bitbake target'
Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-toolchain-sdk
adt-installer
meta-ide-support
You can also run generated qemu images with a command like 'runqemu qemux86'
$ bitbake -c fetchall core-image-minimal
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = zynq-zc702
DISTRO= poky
DISTRO_VERSION= 1.3+snapshot-20121025
TUNE_FEATURES = armv7a vfp neon cortexa9
TARGET_FPU= vfp-neon
meta
meta-yocto= master:33440ee70623394d06a4b214c2be10788cba6d08
toolchain-layer = master:55855cd569fbff7182974ca08b1de8435bf0f597
meta-zynq-balister =
master-xilinx-zc702-gcc-4.7:d168cea411034d1f1530e4eacf6eb3ce4affd1c8
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
05. Build the toolchain
$ cd /tool/yocto/poky
$ source oe-init-build-env build
$ bitbake meta-toolchain
06. Build the image
$ bitbake core-image-minimal
07. Use Xilinx PlanAhead 14.3 software design too to create your hardware
design.
The only additional step you need to perform is to use the Xilinx PlanAhead
software, to export you hardware to the Xilinx SDK, and use the SDK to generate
and build the Zynq First Stage Bootloader (zynq_fsbl). After that, create a
boot image by using the Xilinx tool menu option, and include the u-boot.elf,
system.bit and zynq_fsbl.elf.
Use the scripts in XAPP792 to download the kernel and bootable image to the
target using XMD. Or rename the u-boot.bin file to BOOT.bin, copy the uImage
generated from the yocto build, and it should all work.
Best regards,
Elvis Dowson
On Dec 12, 2012, at 6:56 PM, Anup Kini ak...@synapticon.com wrote:
Hi all,
I am new to Yocto.
I am trying to build an environment with arm-gcc integrated since the ZYNQ
board has ARM Cortex A9 ducal core on it.
Let me know if any one has tried something similar or some pointers on how i
can proceed.
--
Anup Kini
Systems Engineer
Synapticon | Cyber-Physical System Solutions
Direct:
+49 7335 / 186 999 17
Fax:
+49 7335 / 186 999 19
synapticon.com | @synapticon_co
Synapticon GmbH | Hohlbachweg 2 | 73344 Gruibingen, DE
Secretary +49 7335 / 186 999 0 | General Manager: Nikolai Ensslen
Registry Court Ulm HRB 725114 | USt-ID DE271647127
This message and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
Please notify the sender immediately if you have received this e-mail by
mistake and delete it from your system.
___
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] building for ZYNQ ZC702 SoC
Hi Anup, On Dec 12, 2012, at 7:32 PM, Anup Kini ak...@synapticon.com wrote: I could not find where the arm gcc was included in this build. I was checking the build process and took the gcc.4.4.6 while building the core-image-minimal. Hence i wanted to confirm if the arm-gcc can be integrated and steps to do it. Two things to keep in mind here: a. Yocto will generate a cross compiler for you. It will be called arm-poky-linux-gcc , and will be located in the poky/build/tmp/sysroots/x86_64-linux/usr/bin folder This won't appear in your path, unless you explicitly specify it. You can use this to build u-boot, the linux kernel and the root filesystem for the ZC702. b. The cross compiler generated from yocto has some issues building the Xilinx SDK sources, for compiling the bsp and fsbl sources. Hence, you can use the default xilinx supplied compiler, which is already setup with Xilinx SDK, to build the bsp and fsbl binaries. You only need the Xilinx supplied gcc toolchain for these tasks, as well as for bare-metal applications using StandAlone OS or XilKernel. For the rest, yocto gives you an easy way to build a fully working image for the ZC702. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] eglibc-2.13: backport sotruss from eglibc-2.16
Hi Khem,
On Dec 9, 2012, at 10:58 PM, Elvis Dowson elvis.dow...@gmail.com wrote:
I get the following error while attempting to backport support for the older
eglibc-2.13 recipe and gcc-4.5.4, to make it work with the latest poky master.
I got the image to build and execute correctly, temporarily by commenting out
the parts relating to sotruss, and it worked on my powerpc 440 target with
softfloat.
Now, I just want to update the eglibc-2.13 recipe, so that it works correctly
with poky master. I patched the eglibc-2.13 sources and it builds the
required files.
However, during the installation phase, I get a problem, in that the scripts
attempt to install libsotruss.so to the root folder on my host machine,
instead of the yocto build folder:
/usr/bin/install -c
/tool/yocto/poky/build/tmp/work/ppc405-poky-linux/eglibc/2.13-r32/build-powerpc-poky-linux/elf/sotruss-lib.so
/sotruss-lib.so.new
/usr/bin/install -c
/tool/yocto/poky/build/tmp/work/ppc405-poky-linux/eglibc/2.13-r32/build-powerpc-poky-linux/elf/sprof
/tool/yocto/poky/build/tmp/work/ppc405-poky-linux/eglibc/2.13-r32/image/usr/bin/sprof.new
(cd
/tool/yocto/poky/build/tmp/work/ppc405-poky-linux/eglibc/2.13-r32/build-powerpc-poky-linux/elf/.;
/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/libexec/ppc405-poky-linux.gcc-cross-initial/gcc/powerpc-poky-linux/4.5.4/objdump
-h dl-load.o dl-cache.o dl-lookup.o dl-object.o dl-reloc.o dl-deps.o
dl-runtime.o dl-error.o dl-init.o dl-fini.o dl-debug.o dl-misc.o dl-version.o
dl-profile.o dl-conflict.o dl-tls.o dl-origin.o dl-scope.o dl-execstack.o
dl-open.o dl-close.o dl-trampoline.o dl-support.o dl-iteratephdr.o dl-addr.o
enbl-secure.o dl-profstub.o dl-libc.o dl-sym.o dl-tsd.o dl-sysdep.o dl-vdso.o
dl-machine.o dl-iteratephdr.os dl-addr.os dl-profstub.os dl-libc.os dl-sym.os
dl-tsd.os unwind-dw2-fde-glibc.os dl-vdso.os framestate.os unwind-pe.os
rtld.os dl-load.os dl-cache.os dl-lookup.os dl-object.os dl-reloc.os
dl-deps.os dl-runtime.os dl-error.os dl-init.os dl-fini.os dl-debug.os
dl-misc.os dl-version.os dl-profile.os dl-conflict.os dl-tls.os dl-origin.os
dl-scope.os dl-execstack.os dl-caller.os dl-open.os dl-close.os
dl-trampoline.os dl-sysdep.os dl-environ.os dl-minimal.os dl-brk.os
dl-sbrk.os dl-start.os dl-machine.os soinit.os sofini.os interp.os
static-stubs.o cache.o readlib.o xmalloc.o xstrdup.o chroot_canon.o
sotruss-lib.os sotruss-lib.so) | \
gawk '/\.gnu\.glibc-stub\./ { \
sub(/\.gnu\.glibc-stub\./, , $2); \
stubs[$2] = 1; } \
END { for (s in stubs) print #define __stub_ s }'
/tool/yocto/poky/build/tmp/work/ppc405-poky-linux/eglibc/2.13-r32/build-powerpc-poky-linux/elf/stubsT
/usr/bin/install: cannot create regular file `/sotruss-lib.so.new':
Permission denied
How can I get past this error?
I got solved this error.
Apparently, I needed to ensure that the eglibc-2.13 libc/Makeconfig file had a
definition for auditdir . Since that was missing, the expression
${auditor}/libsotruss.so ended up evaluating to /libsotruss.so, which cause the
build error, with bitbake trying to install it to the host root directory.
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] eglibc-2.13: backport sotruss from eglibc-2.16
Hi Khem,
I get the following error while attempting to backport support
for the older eglibc-2.13 recipe and gcc-4.5.4, to make it work with the latest
poky master.
I got the image to build and execute correctly, temporarily by commenting out
the parts relating to sotruss, and it worked on my powerpc 440 target with
softfloat.
Now, I just want to update the eglibc-2.13 recipe, so that it works correctly
with poky master. I patched the eglibc-2.13 sources and it builds the required
files.
However, during the installation phase, I get a problem, in that the scripts
attempt to install libsotruss.so to the root folder on my host machine, instead
of the yocto build folder:
/usr/bin/install -c
/tool/yocto/poky/build/tmp/work/ppc405-poky-linux/eglibc/2.13-r32/build-powerpc-poky-linux/elf/sotruss-lib.so
/sotruss-lib.so.new
/usr/bin/install -c
/tool/yocto/poky/build/tmp/work/ppc405-poky-linux/eglibc/2.13-r32/build-powerpc-poky-linux/elf/sprof
/tool/yocto/poky/build/tmp/work/ppc405-poky-linux/eglibc/2.13-r32/image/usr/bin/sprof.new
(cd
/tool/yocto/poky/build/tmp/work/ppc405-poky-linux/eglibc/2.13-r32/build-powerpc-poky-linux/elf/.;
/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/libexec/ppc405-poky-linux.gcc-cross-initial/gcc/powerpc-poky-linux/4.5.4/objdump
-h dl-load.o dl-cache.o dl-lookup.o dl-object.o dl-reloc.o dl-deps.o
dl-runtime.o dl-error.o dl-init.o dl-fini.o dl-debug.o dl-misc.o dl-version.o
dl-profile.o dl-conflict.o dl-tls.o dl-origin.o dl-scope.o dl-execstack.o
dl-open.o dl-close.o dl-trampoline.o dl-support.o dl-iteratephdr.o dl-addr.o
enbl-secure.o dl-profstub.o dl-libc.o dl-sym.o dl-tsd.o dl-sysdep.o dl-vdso.o
dl-machine.o dl-iteratephdr.os dl-addr.os dl-profstub.os dl-libc.os dl-sym.os
dl-tsd.os unwind-dw2-fde-glibc.os dl-vdso.os framestate.os unwind-pe.os rtld.os
dl-load.os dl-cache.os dl-lookup.os dl-object.os dl-reloc.os dl-deps.os
dl-runtime.os dl-error.os dl-init.os dl-fini.os dl-debug.os dl-misc.os
dl-version.os dl-profile.os dl-conflict.os dl-tls.os dl-origin.os dl-scope.os
dl-execstack.os dl-caller.os dl-open.os dl-close.os dl-trampoline.os
dl-sysdep.os dl-environ.os dl-minimal.os dl-brk.os dl-sbrk.os dl-start.os
dl-machine.os soinit.os sofini.os interp.os static-stubs.o cache.o readlib.o
xmalloc.o xstrdup.o chroot_canon.o sotruss-lib.os sotruss-lib.so) | \
gawk '/\.gnu\.glibc-stub\./ { \
sub(/\.gnu\.glibc-stub\./, , $2); \
stubs[$2] = 1; } \
END { for (s in stubs) print #define __stub_ s }'
/tool/yocto/poky/build/tmp/work/ppc405-poky-linux/eglibc/2.13-r32/build-powerpc-poky-linux/elf/stubsT
/usr/bin/install: cannot create regular file `/sotruss-lib.so.new': Permission
denied
How can I get past this error?
Best regards,
Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to check if systemd is correctly setup
Hi, I haven't used systemd before, and I've just built a linux kernel image using the latest yocto poky/master. The boot process starts as normal, but it just displays freeing memory (some value) and I get no console prompt. Q1: Which config setting or recipe code, controls the inclusion of systemd in the root filesystem? Q2: How can I check to see if systemd is properly configured for my target (virtex-5-powerpc-405-ml507-softfloat)? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to check if systemd is correctly setup
Hi Gary, Thanks for the reply! On Dec 8, 2012, at 8:02 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-12-08 07:19, Elvis Dowson wrote: Hi, I haven't used systemd before, and I've just built a linux kernel image using the latest yocto poky/master. The boot process starts as normal, but it just displays freeing memory (some value) and I get no console prompt. Q1: Which config setting or recipe code, controls the inclusion of systemd in the root filesystem? Q2: How can I check to see if systemd is properly configured for my target (virtex-5-powerpc-405-ml507-softfloat)? First thing, make sure that your kernel has this in the config: CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y The latest udev (rev 182) has to have this to work. Yes, my defconfig has the above two configs set. Which file control if systemd gets pulled into the core-image-minimal recipe? Where are the systemd configuration files stored? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to check if systemd is correctly setup
Hi, On Dec 8, 2012, at 8:02 PM, Gary Thomas g...@mlbassoc.com wrote: First thing, make sure that your kernel has this in the config: CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y The latest udev (rev 182) has to have this to work. In my kernel boot message, devtmpfs: mounted Freeing unused kernel memory : 168k freed _ I am able to ping to the board from a terminal console on the host, and I get a reply. However, I don't see a console prompt, even though on my bootargs i have set init=/bin/sh Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] mail list for Xilinx Zynq platform?
Hi Andreas, On Dec 6, 2012, at 4:57 PM, Andreas Schweigstill andr...@schweigstill.de wrote: After changing the order of BBLAYERS in build/conf/local.conf to meta, meta-zynq, meta-yocto, meta-yocto-bsp and using Hob to select MACHINE=zynq-zc702, base image=zc702-proto-image everything works fine. Now I get a proper toolchain for Cortex A9 and a kernel named zynq-zc702 3.5.0-14.3-build1-yocto-standard which is properly running on my ZC702 board. I don't add meta-yocto-bsp to my bblayers configuration. I haven't built a BOOT.BIN file with Yocto based U-Boot yet. Instead I'm using U-Boot from Petalinux 12.9 which is configured to use the QSPI Flash to store its environment. Currently I boot from QSPI Flash, load kernel und DTB files via TFTP and use a root filesystem stored on a SD card. ;-) If you want to build your own version of BOOT.bin, its quite simple. Just take the u-boot.elf file, and use SDK to create a simple zynq_fsbl project. From that create the boot image, using the SDK, and add the system.bit, zynq_fsbl.elf and u-boot.elf binaries. Rename the produce binary to BOOT.bin, and you're good to go. You can find more information of the boot image creation process on section 3.5, page 29, of the UG821 - Zynq-7000 EPP Software Developers Guide v3.0. From within SDK, it's pretty straightforward, and it will automatically create the bif file after you've specified all the binaries, and create the bootable image. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] mail list for Xilinx Zynq platform?
Hi, On Dec 5, 2012, at 5:21 PM, Andreas Schweigstill andr...@schweigstill.de wrote: I have also tried to build a kernel and root filesystem for Zynq but the kernel gets stuck when booting, regardless if on the ZC702 board or on Qemu. I tried Poky denzil and Poky danny. Also the alternate meta-zynq layer from git.yoctoproject.org shows the same behaviour. These are the last console messages which I get: ## Booting kernel from Legacy Image at 0100 ... Image Name: Linux-3.2.11-yocto-standard Created: 2012-12-04 20:07:37 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2997472 Bytes = 2.9 MiB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01a8 Booting using the fdt blob at 0x1a8 Loading Device Tree to 0eff8000, end 0efff185 ... OK Loading Kernel Image ... OK OK Loading Device Tree to 0efed000, end 0eff7185 ... OK Starting kernel ... Instead of using Linux kernel version 3.5-xilinx I always get Linux-3.2.11-yocto-standard which is obviously missing the Zynq patches. meta-zynq/recipes-kernel-linux-zynq contains the following lines: LINUX_VERSION ?= 3.5 LINUX_VERSION_EXTENSION ?= -xilinx How can I force Yocto to build kernel 3.5-xilinx? From you messages, I infer that you are using the meta-zynq layer located here: http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/ For my builds, I used Philip Ballister's meta-zynq layer located here for the simple reason that it uses xilinx git repository: https://github.com/balister/meta-zynq Also, try to ensure that you don't put both the meta-layers in your bblayers.conf file while building, and ensure that you set machine as follows in your local.conf file MACHINE ?= zynq-zc702 Do let me know how it goes! Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] mail list for Xilinx Zynq platform?
Hi Daniel, As far as I know, there is no specific mailing list for the Xilinx Zynq platform. I use the Xilinx forums to get help at the moment. I personally have used Philip's meta-zynq layer to build a working u-boot and linux kernel image using Yocto. It works really well. Using the Zynq is a little bit different than a standard ARM SOC. If you've worked with the TI OMAP series, you would be familiar with the x-loader component, that runs before u-boot. Well, the only difference here is that you need to use the Xilinx SDK to create a zynq_fsbl (first stage boot loader) project, using the defaults. Once you've got the zynq_fsbl, you have a couple of options a. Create a bootable image Use the SDK create boot image utility to create a bootable image - zynq_fsbl - u-boot.bin - system.bit (hardware bitstream) You would rename the resultant file as BOOT.bin. After that, you can drop the linux kernel uImage onto an SD card and boot linux as normal. b. Download to the target using xmd and a tcl script Use the xapp792 design files, to see how to download the binaries to the Zynq board using a JTAG cable. The tcl file is located in xapp792/zc702_video_3x_pipeline/ready_for_download/xmd_top.tcl The whole process takes a couple of days to get used to. Let me know if you get stuck somewhere. Best regards, Elvis DOwson On Nov 26, 2012, at 12:45 PM, Daniel Martinez Ramos daniel.marti...@sacnet.es wrote: Hi all, I've found a bsp layer in Xilinx here http://forums.xilinx.com/t5/Embedded-Linux/Yocto-BSP-for-ZC-702/td-p/246932, which is pretty interesting. Is any mail list under Yocto for the Xilinx Zinq platform? Best regards, Daniel Martinez ___ 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] Performance improvements and machine build configuration
Hi Chris, On Oct 23, 2012, at 11:39 PM, Chris Tapp opensou...@keylevel.com wrote: On 23 Oct 2012, at 19:45, Elvis Dowson wrote: I noticed that between commits http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=0260bb5c6978839c068007fcff2f704937805faf and http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a3d5e9e6b7729319c518dcaf25bbe0643bfb25db the build time has improved by around 7 minutes for my machine configuration, for building a core-image-minimal rootfs for the Xilinx ZC-702 FPGA with dual ARM Cortex A-9 CPUs. commit id 0260bb5c6978839c068007fcff2f704937805faftook 29 minutes commit id a3d5e9e6b7729319c518dcaf25bbe0643bfb25db took 22 minutes The machine configuration is an Intel i7 3770K over-clocked to 4.2GHz, with 16GB RAM at 1600Mhz, two 120GB SSDs configured into a striped disk array (Intel 330 series SSDs) with a write performance of 838MB/s and read performance of around 600MB/s, in RAID0 configuration, with a Corsair HT100 liquid CPU cooler keeping the CPU cool at around 52 degree centigrade during the build process. The motherboard is a gigabyte GA-Z77X-UP5TH http://www.gigabyte.com/products/product-page.aspx?pid=4279#ov This motherboard has a thunderbolt display port, so I can re-use my existing Apple Thunderbolt display. I've run Ubuntu 12.04.1 LTS and Ubuntu 12.10, and it appears to work after a few tweaks. The only curious thing that I've noticed is that I don't see a large performance improvement using a standard 3TB Seagate Barracuda 7200 RPM HDD, and the two Intel Series 330 SSDs in a striped RAID0 configuration. The read (600MB/s) / write (838MB/s) figures are impressive, although I expected the read performance to be higher than write performance, as is normally with a single SSD. I'm using the motherboard's hardware RAID support on a 6GB/s SATA 3 port. The 3TB HDD took the approximately 2 or 3 minutes longer than the 120GB x 2 RAID0 SSD configuration for commit id 0260bb5c6978839c068007fcff2f704937805faf (31 minutes vs. 29 minutes). My local.conf parallelism settings were set to 6 threads for bitbake and make, for the quad-core (virtual 8 cpu cores)system. Has anyone tried yocto builds with a 6-core, 8-core or 10-core Xeon processor system? How do those figures fare? I'm thinking my current bottleneck might be the CPU and not the HDD (?!), for the yocto build workloads, which I find curious and would like to confirm. I did quite a bit of experimenting with this a while back (similar spec, but with nearly 1000MB/s read/write SDD array). CPU was quad core with hyper-threading, so 8 virtual cores. I generally run with 16 threads, 16 parallel make as I find that the main performance hit is running out of stuff to keep all the cores busy. Most of the time all 8 cores are maxed out, but around when the kernel gets built (and cross tools needed for it) I see the total CPU use drop to about 25%. This isn't because the system is I/O bound; it simply doesn't have enough tasks ready to run at that point in time. I estimate that my 55 min build times would come down by 10 to 15 minutes if I could keep the CPUs busy (still, much better than the 10 hour build times on my previous system!). With the poky/master branch commit 33440ee70623394d06a4b214c2be10788cba6d08, which is the tip master branch, I tried two builds 01. parallelism set to 16, which took 23 minutes 21 seconds. 02. parallelism set to 6, which took less time at 22 minutes 13 seconds. Therefore, for a quad core machine (Intel i7-3770K @ 4.2GHz over-clocked, 16GB 1600MHz RAM), setting the parallelism parameters to 6 appears to be better than setting it to 16. Run # 01 BB_NUMBER_THREADS = 16 PARALLEL_MAKE = -j 16 Build Configuration: BB_VERSION= 1.16.0 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = zynq-zc702 DISTRO= poky DISTRO_VERSION= 1.3+snapshot-20121025 TUNE_FEATURES = armv7a vfp neon cortexa9 TARGET_FPU= vfp-neon meta meta-yocto= master:33440ee70623394d06a4b214c2be10788cba6d08 toolchain-layer = master:55855cd569fbff7182974ca08b1de8435bf0f597 meta-zynq-balister = master-xilinx-zc702-gcc-4.7:d168cea411034d1f1530e4eacf6eb3ce4affd1c8 NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: validating kernel configuration cat: meta/cfg/standard/zynq-zc702/specified.cfg: No such file or directory cat: meta/cfg/standard/zynq-zc702/specified.cfg: No such file or directory ** NOTE: There were 0 required options requested that do not have a corresponding value present in the final .config file. This is a violation of the policy defined by the higher level config The full list can be found in your kernel src dir at: meta/cfg/standard/zynq-zc702/missing_required.cfg
Re: [yocto] ERROR: Function failed: do_rootfs, poky commit id 8ce23f569584f195391bc5c68a780e1bf54e4360
Hi Ross, On Oct 23, 2012, at 11:53 PM, Burton, Ross ross.bur...@intel.com wrote: On 23 October 2012 19:35, Elvis Dowson elvis.dow...@gmail.com wrote: the following entry works for the /etc/fstab for moving the /tmp file to RAM none/tmptmpfsdefaults,noatime,nodiratime00 tmpfs is in virtual memory, so potentially swap. Have you benchmarked a build with the build on SSD verses in tmpfs to see what the improvement is? There was no difference in build times with the /tmp folder in RAM or SSD Both these scenarios took around 22 minutes for commit id a3d5e9e6b7729319c518dcaf25bbe0643bfb25db I think the optimisation is only useful to improve the life of the SSD drive, by moving the /tmp folder to RAM. I've also moved the fire-fox browser cache to RAM, to avoid hitting the SSD as far as possible. An alternative (and less intrusive) is to increase the commit timeout on the build partition, which means more data is buffered in RAM before the disk is used. I haven't benchmarked that either though. :) I modified /etc/sysctl.conf as follows, to improve desktop performance. One of the parameters vm.swappiness, controls swap to disk. With a setting of 10, and 16GB of RAM, it hardly ever swaps to disk throughout the entire build process. Here are my /etc/sysctl.conf settings: ### # Additional settings - these setting can increase desktop performance # Configure vm.mmap_min_addr vm.mmap_min_addr = 0 vm.vdso_enabled = 0 # Optimize swap usage to increase desktop performance vm.swappiness=10 vm.vfs_cache_pressure=1000 vm.dirty_background_ratio=10 vm.dirty_ratio=30 Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: Function failed: do_rootfs, poky commit id 8ce23f569584f195391bc5c68a780e1bf54e4360
Hi, I haven't had any solutions for this build error that I'm facing. If someone could offer some insight as to what might be going wrong, it would be much appreciated. On Oct 23, 2012, at 12:22 AM, Elvis Dowson elvis.dow...@gmail.com wrote: | Configuring sysvinit. | Collected errors: | * preinst_configure: Aborting installation of base-passwd. | * opkg_install_cmd: Cannot install package packagegroup-core-boot. | ERROR: Function failed: do_rootfs (see /tool/yocto/poky/build/tmp/work/zynq_zc702-poky-linux-gnueabi/core-image-minimal-1.0-r0/temp/log.do_rootfs.30138 for further information) ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 1395 tasks of which 227 didn't need to be rerun and 1 failed. No currently running tasks (1395 of 1396) The build appears to be failing because it cannot install packagegroup-core-boot. Has something changed recently in poky/master, that might be causing this? I additionally notice that the path being generated is zynq_702 instead of zynq-702. No-where in Philip Ballister's machine configs for the zc702 board, is is mentioned zynq_zc702 with an underscore, yet it adds it. It's kind of weird. ERROR: Function failed: do_rootfs (see /tool/yocto/poky/build/tmp/work/zynq_zc702-poky-linux-gnueabi/core-image-minimal-1.0-r0/temp/log.do_rootfs.30138 for further information) It's kind of weird. I also see the same zynq_zc702 entry with an underscore in the logs as follows: | + ipkgarchs='all any noarch arm armv4 armv5 armv5-vfp armv5e armv5e-vfp armv6-vfp armv7a armv7a-vfp armv7a-vfp-neon zynq_zc702' What could be causing this? Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: Function failed: do_rootfs, poky commit id 8ce23f569584f195391bc5c68a780e1bf54e4360
Hi, On Oct 23, 2012, at 8:32 PM, Elvis Dowson elvis.dow...@gmail.com wrote: I haven't had any solutions for this build error that I'm facing. If someone could offer some insight as to what might be going wrong, it would be much appreciated. On Oct 23, 2012, at 12:22 AM, Elvis Dowson elvis.dow...@gmail.com wrote: | Configuring sysvinit. | Collected errors: | * preinst_configure: Aborting installation of base-passwd. | * opkg_install_cmd: Cannot install package packagegroup-core-boot. | ERROR: Function failed: do_rootfs (see /tool/yocto/poky/build/tmp/work/zynq_zc702-poky-linux-gnueabi/core-image-minimal-1.0-r0/temp/log.do_rootfs.30138 for further information) ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 1395 tasks of which 227 didn't need to be rerun and 1 failed. No currently running tasks (1395 of 1396) The build appears to be failing because it cannot install packagegroup-core-boot. Has something changed recently in poky/master, that might be causing this? I additionally notice that the path being generated is zynq_702 instead of zynq-702. No-where in Philip Ballister's machine configs for the zc702 board, is is mentioned zynq_zc702 with an underscore, yet it adds it. It's kind of weird. ERROR: Function failed: do_rootfs (see /tool/yocto/poky/build/tmp/work/zynq_zc702-poky-linux-gnueabi/core-image-minimal-1.0-r0/temp/log.do_rootfs.30138 for further information) It's kind of weird. I also see the same zynq_zc702 entry with an underscore in the logs as follows: | + ipkgarchs='all any noarch arm armv4 armv5 armv5-vfp armv5e armv5e-vfp armv6-vfp armv7a armv7a-vfp armv7a-vfp-neon zynq_zc702' What could be causing this? I found out why it was failing. I recently added two SSD drives in a RAID0 stripped disk configuration. One of the performance tweaks was to move /tmp to RAM, to improve the life of the SSDs. My /etc/fstab for setting up the /tmp folder inadvertently included the noexec,nodev,nosuid options, which cause the rootfs process to fail. the following entry works for the /etc/fstab for moving the /tmp file to RAM none/tmptmpfsdefaults,noatime,nodiratime00 I just updated poky and the rest of the meta-layers to the latest commit on their respective master branches, and it built successfully. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: Function failed: do_rootfs, poky commit id 8ce23f569584f195391bc5c68a780e1bf54e4360
Hi, On Oct 23, 2012, at 12:22 AM, Elvis Dowson elvis.dow...@gmail.com wrote: | Configuring sysvinit. | Collected errors: | * preinst_configure: Aborting installation of base-passwd. | * opkg_install_cmd: Cannot install package packagegroup-core-boot. | ERROR: Function failed: do_rootfs (see /tool/yocto/poky/build/tmp/work/zynq_zc702-poky-linux-gnueabi/core-image-minimal-1.0-r0/temp/log.do_rootfs.30138 for further information) ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 1395 tasks of which 227 didn't need to be rerun and 1 failed. No currently running tasks (1395 of 1396) The build appears to be failing because it cannot install packagegroup-core-boot. Has something changed recently in poky/master, that might be causing this? Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Any updates to meta-zynq in the pipeline?
Hi Bruce, I'm about to start with my Xilinx ZC702 development board, and I was wondering if there are any updates planned to the meta-zynq repository? In an earlier thread, you had mentioned that a whole bunch of updates were pending to the meta-zynq layer: Re: [yocto] meta-zynq, was Re: any success with spartan6-lx9mb? Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Any updates to meta-zynq in the pipeline?
Hi Bruce, On Oct 13, 2012, at 6:21 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: There are updates planned, but with some vacations (mine and others), since that last update things slowed down a bit. But work is proceeding, I expect something in the next few weeks. In particular, as an initial item, the BSP can be bumped to the Yocto 1.3 (3.4) kernel, and complete some work on remaining issues with the layer. After that, SDK updates, and other enhancements would be in the pipeline, but i don't have a complete visibility into those yet. I'm more interested in updates to the machine configuration and tune files for the Zynq-7020 processor. Are there any updates planned for these? The processor uses a ARM Cortex A9 dual core CPU, so I was wondering where one draws on from, in order to get an accurate representation of the processor. e.g. use TRM for Zynq-7020 and then look a a TI OMAP 4430 or Freescale i.MX 6 dual core machine configuration, etc? The kernel and u-boot recipes, I can migrate to the latest 3.5 and 2012.x versions, so that shouldn't be a problem for me. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Any updates to meta-zynq in the pipeline?
Hi Philip, On Oct 13, 2012, at 6:28 PM, Philip Balister phi...@balister.org wrote: If you are interested in a kernel built direct from the Xilinx repo look at: https://github.com/balister/meta-zynq I just pushed use changes yesterday and could use some help testing them. It is setup to boot from a SD card. You have to take the output of the u-boot recipe and use the Xilinx tools to combine it with the fsbl to get the required BOOT.BIN file. I'll help out and test your layer first, and let you know. It's going to take me a while to get used to this new board. I always find that I end up spending more than 2 to 3 months, just getting to know each platform to a good level, the last two ones being the Gumstix TI OMAP 3530 and the Xilinx ML507. I'm going to brace myself, its going to be a deep dive I think! :-) Adrian Alonso's meta-xilinx layer had some *.bbclass files, that invoked the Xilinx tools to create the ace image files, so perhaps that could be modified to automate the process or getting the final BOOT.BIN file. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Any updates to meta-zynq in the pipeline?
Hi, I just took a quick look both the repos My initial reaction is that I think Philip's repo appears to better structured, and attempts to use the xilinx kernel and u-boot repos, which for these targets is a good thing, given the state of the development for this new board. I also think its probably good to take then best of both repos, and maintain a single meta-zynq layer, since both these repos are in its initial stages. I'll give more feedback, as I progress with my build and test runs on the target board. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-zynq-balister: Build output
Hi Philip,
I made the following changes to your repo, since it was
giving a warning about apps-console-core being no longer valid, and yocto
replacing it with splash.
diff --git a/conf/machine/zynq-zc702.conf b/conf/machine/zynq-zc702.conf
index 74a1271..d25093f 100644
--- a/conf/machine/zynq-zc702.conf
+++ b/conf/machine/zynq-zc702.conf
@@ -1,3 +1,8 @@
+#@TYPE: Machine
+#@Name: Xilinx ZC702 FPGA Development Platform for the Zynq-7020 processor.
+#@DESCRIPTION: Machine configuration for the Xilinx ZC702 FPGA Development
Platform.
+
+#tune for the Zynq 7020 ARM Cortex A-9 CPU
include conf/machine/include/tune-cortexa9.inc
PREFERRED_PROVIDER_virtual/kernel ?= linux-zynq
diff --git a/recipes-core/images/zc702-proto-image.bb
b/recipes-core/images/zc702-proto-image.bb
index a6e4b11..02a6af2 100644
--- a/recipes-core/images/zc702-proto-image.bb
+++ b/recipes-core/images/zc702-proto-image.bb
@@ -1,14 +1,12 @@
-DESCRIPTION = A foundational basic image without support for X that can be \
-reasonably used for customization.
+DESCRIPTION = A console-only image with more full-featured Linux system \
+functionality installed.
-IMAGE_FEATURES += apps-console-core ssh-server-openssh tools-sdk \
+IMAGE_FEATURES += splash ssh-server-openssh tools-sdk \
tools-debug debug-tweaks
IMAGE_INSTALL = \
-task-core-boot \
-task-core-basic \
+packagegroup-core-boot \
+packagegroup-core-basic \
-#${CORE_IMAGE_BASE_INSTALL}
-
inherit core-image
and here is the build output:
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = zynq-zc702
DISTRO= poky
DISTRO_VERSION= 1.3+snapshot-20121013
TUNE_FEATURES = armv7a vfp neon cortexa9
TARGET_FPU= vfp-neon
meta
meta-yocto= master:0260bb5c6978839c068007fcff2f704937805faf
toolchain-layer = master:9e701bb060325bc47509d4874bd695f039191ea8
meta-zynq-balister = master:61ee369f84252acaaa4a4500f08450df2648247d
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: Failed to fetch URL
http://kernel.org/pub/linux/kernel/people/jsipek/guilt/guilt-0.33.tar.gz,
attempting MIRRORS if available
NOTE: validating kernel configuration
cat: meta/cfg/standard/zynq-zc702/specified.cfg: No such file or directory
cat: meta/cfg/standard/zynq-zc702/specified.cfg: No such file or directory
** NOTE: There were 0 required options requested that do not
have a corresponding value present in the final .config file.
This is a violation of the policy defined by the higher level config
The full list can be found in your kernel src dir at:
meta/cfg/standard/zynq-zc702/missing_required.cfg
NOTE: Tasks Summary: Attempted 1465 tasks of which 229 didn't need to be rerun
and all succeeded.
Summary: There was 1 WARNING message shown.
real33m58.594s
user97m0.724s
sys12m50.976s
It gives a config policy warning, haven't seen this before.
I also noticed that by default, u-boot-zynq doesn't get compiled, but it's
trivial enough to include in the zynq-zc702.conf file.
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zynq-balister: Build output
Hi Philip, I've just sent out two patches refactoring the zc702 machine configuration, and adding u-boot to the rootfs image. I've built this against the latest poky/master branch. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Getting gcc-4.7 and eglibc-2.16 to work with PowerPC440
Hi Khem, After I finished getting gcc-4.5.4 and eglibc-2.13 to build for the PowerPC440 target, using soft-float, I tried the following combinations 1. gcc-4.7.2 with eglibc-2.13 - result, no prompt on the login screen, able to ping the target board, but no root login prompt. It doesn't crash during the boot process either. 2. gcc-4.5.4 with eglibc-2.16: init crash with a kernel panic, immediately after boot, just before the login prompt. I vaguely recall somewhere in one of the patches, or browsing some discussions threads on the internet, that before gcc-4.5, support would be dropped for specific powerpc variants. Perhaps is that why I'm running into these issues? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] denx.de site down?
Hi Wolfgang, I noticed that your site has been down since yesterday? I usually sync with your u-boot and eldk repositories, and during the yocto build process, it failed because your site was un-reachable. I was able to get past the yocto build issue, by temporarily modifying my u-boot repositories to point to the local file system. I'm sure others are also facing a similar issue. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dependency walk for busybox recipe
Hi Paul,
On Sep 16, 2012, at 10:31 PM, Paul Eggleton wrote:
On Sunday 16 September 2012 20:09:10 Elvis Dowson wrote:
On 09/16/2012 07:54 AM, Khem Raj wrote:
On Sat, Sep 15, 2012 at 10:59 AM, Elvis Dowson elvis.dow...@gmail.com
wrote:
So I added busybox-1.19.4 recipe back into my poky master branch, and the
resulting size of the busybox-1.19.4 /bin/busybox or /bin/sh executable
is 604.2 kb.
make sure that .config of busybox has not changed even if you have
same version backported
I've made sure that the defconfig files used in the recipe are
identical. The only addition that I notice now, is that the recent
rework done to task-core-boot, resulting in it being renamed as
packagegroup-core-boot.bb adds the following extra line:
${@base_contains(MACHINE_FEATURES, rtc, busybox-hwclock, , d)} \
My virtex5.conf machine features entry does not specify an rtc,
MACHINE_FEATURES = kernel26 apm ext2 ext3 vfat ethernet keyboard screen
serial
yet the current poky master attempts to pull it in:
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'busybox-hwclock' (but
/tool/yocto/poky/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'busybox-hwclock' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['busybox-hwclock']
NOTE: Runtime target 'packagegroup-core-boot' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['packagegroup-core-boot',
'busybox-hwclock']
ERROR: Required build target 'core-image-minimal' has no buildable
providers.
Missing or unbuildable dependency chain was: ['core-image-minimal',
'packagegroup-core-boot', 'busybox-hwclock']
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Is this a bug? Is the rtc being added from somewhere else? Should this
be happening?
It's not a bug, this is meant to happen. This is a result of
MACHINE_FEATURES_BACKFILL, which is intended to ensure that we can introduce
new items to MACHINE_FEATURES controlling existing functionality without
breaking existing machine configurations by disabling the existing
functionality because the configuration doesn't include it. (In older
versions
of busybox the hwclock feature was on by default - an hwclock item was added
at the MACHINE_FEATURES level to be able to control it).
To fix this, just add hwclock to MACHINE_FEATURES_BACKFILL_CONSIDERED in your
machine configuration.
My target board doesn't have an rtc, and busybox tries to look for a
busybox-hwclock.
Hence, I don't need an rtc and would like to prevent the hwclock.sh script from
being
copied onto the target by default.
In my machine configuration file, even if I set
MACHINE_FEATURES_BACKFILL =
MACHINE_FEATURES_BACKFILL_CONSIDERED =
it still complains with the same error
Nothing RPROVIDES 'busybox-hwclock' (but
/tool/yocto/poky/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
The only way to suppress that error is to remove the line
${@base_contains(MACHINE_FEATURES, rtc, busybox-hwclock, , d)} \
but the hwclock.sh script gets copied onto the rootfilesystem any way into /sbin
So, I'm not sure what's being achieved. The MACHINE_FEATURES_BACKFILL
and MACHINE_FEATURES_BACKFILL_CONSIDERED = has not effect
and the hwclock.sh gets copied to the target in all cases.
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] All kernel modules being built and shipped in images/modules-*.tgz
Hi Bruce, On Sep 17, 2012, at 7:18 AM, Bruce Ashfield wrote: On 12-09-16 12:49 PM, Elvis Dowson wrote: Hi, On Sep 15, 2012, at 7:29 AM, Elvis Dowson wrote: I just noticed that with the recent poky master updates, my images/modules-3.3.1-r00-virtex5.tgz file has grown from 4.6 MB to 668.5MB. When I looked in the package, I saw that the kernel/drivers folder inside that package was nearly 1.5GB uncompressed!! My kenel defconfig was tuned so that I only used a bare minimum of kernel modules, and nearly all except for 2 groups (one related to filesystem and the other for networking) was built as a module. The rest were all built into the kernel. Isn't this a regression or an error? Also my build time has gone up from 40 minutes to 67 minutes, probably as a result of the increased number of kernel modules being built and shipped. Is there any way to prevent all the kernel modules from being built, when 99% of my kernel defconfig settings are set to 'y' and not to build any modules? You'll have to confirm in your kernel build directory and .config that you really don't have these modules enabled. Since there's no kernel recipe that I've seen that builds all modules, they just the modules specified in your .config are built and packaged by the kernel classes. But maybe I've misunderstood the question, or what you are seeing. The problem that I'm seeing is that before, with the same defconfig file the size of the kernel module image was only 4.6MB. Now with the latest poky master, the same recipe generates a kernel module image that is 668.5MB in size!! :-) I looked at the .config file in the tmp/work/virtex5-poky-linux/linux-xilinx-3.3.0-r00/git folder and find that a whole bunch of modules that were not enabled at all in my defconfig-3.0.0 file (that's the name given in the linux-xilinx_3.3.0.bb recipe), got enabled. The original size of the defconfig-3.3.0 file was 43.4kb. the one in the tmp/work/virtex5-poky-linux/linux-xilinx-3.3.0-r00/git was over 124kb! This is with poky master commit id 913944d904266bf90af0cad94b4f0fb3652bd29d. This problem did not occur with poky master commit id 2dec760b79bb7e2e79c33c5127fa64685bd86a18 Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dependency walk for busybox recipe
On 09/16/2012 07:54 AM, Khem Raj wrote:
On Sat, Sep 15, 2012 at 10:59 AM, Elvis Dowson elvis.dow...@gmail.com wrote:
So I added busybox-1.19.4 recipe back into my poky master branch, and the
resulting size of the busybox-1.19.4 /bin/busybox or /bin/sh executable is
604.2 kb.
make sure that .config of busybox has not changed even if you have
same version backported
I've made sure that the defconfig files used in the recipe are
identical. The only addition that I notice now, is that the recent
rework done to task-core-boot, resulting in it being renamed as
packagegroup-core-boot.bb adds the following extra line:
${@base_contains(MACHINE_FEATURES, rtc, busybox-hwclock, , d)} \
My virtex5.conf machine features entry does not specify an rtc,
MACHINE_FEATURES = kernel26 apm ext2 ext3 vfat ethernet keyboard screen
serial
yet the current poky master attempts to pull it in:
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'busybox-hwclock' (but
/tool/yocto/poky/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'busybox-hwclock' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['busybox-hwclock']
NOTE: Runtime target 'packagegroup-core-boot' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['packagegroup-core-boot',
'busybox-hwclock']
ERROR: Required build target 'core-image-minimal' has no buildable
providers.
Missing or unbuildable dependency chain was: ['core-image-minimal',
'packagegroup-core-boot', 'busybox-hwclock']
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Is this a bug? Is the rtc being added from somewhere else? Should this
be happening?
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] All kernel modules being built and shipped in images/modules-*.tgz
Hi, On Sep 15, 2012, at 7:29 AM, Elvis Dowson wrote: I just noticed that with the recent poky master updates, my images/modules-3.3.1-r00-virtex5.tgz file has grown from 33.1 MB to 668.5MB. When I looked in the package, I saw that the kernel/drivers folder inside that package was nearly 1.5GB uncompressed!! My kenel defconfig was tuned so that I only used a bare minimum of kernel modules, and nearly all except for 2 groups (one related to filesystem and the other for networking) was built as a module. The rest were all built into the kernel. Isn't this a regression or an error? Also my build time has gone up from 40 minutes to 67 minutes, probably as a result of the increased number of kernel modules being built and shipped. Is there any way to prevent all the kernel modules from being built, when 99% of my kernel defconfig settings are set to 'y' and not to build any modules? Elvis ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Dependency walk for busybox recipe
Hi, How can I do a dependency walk for the busybox recipe? I've added gcc-4.5 recipe support and eglibc-2.13 support against the latest poky master branch. The core-image-minimal image works for my powerpc440 soft-float target, from an older commit id, prior to the gcc toolchain rework, and it worked correctly with gcc-4.5 and eglibc-2.13. So, as a next step after getting the image to boot correctly, I updated the recipes to work against the latest poky master. The resulting image crashed with a kernel init, when I passed init=/bin/sh. The size of the /bin/busybox or /bin/sh (soft-link) executable was 600.1kb for the older commit id, with busybox-1.19.4. The size of the busybox-1.20.2 executable a bit larger(around 608kb) but that did't work with gcc-4.5 and eglibc-2.13, and caused a kernel panic. So I added busybox-1.19.4 recipe back into my poky master branch, and the resulting size of the busybox-1.19.4 /bin/busybox or /bin/sh executable is 604.2 kb. Same gcc-4.5, eglibc-2.13 and busybox-1.19.4 recipes and srcrevs, but different executable sizes. How can I find out which packages might be contributing the extra 3.2kb to the /bin/busybox executable? I'm hoping that if I can progressively replace each recipe in the dependency chain, till I get to the original size, I might be able to atleast narrow it down to the recipe that i causing the kernel panics for the powerpc440 target. Once I do that, then I can try with a newer gcc and eglibc version. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] All kernel modules being built and shipped in images/modules-*.tgz
Hi, I just noticed that with the recent poky master updates, my images/modules-3.3.1-r00-virtex5.tgz file has grown from 33.1 MB to 668.5MB. When I looked in the package, I saw that the kernel/drivers folder inside that package was nearly 1.5GB uncompressed!! My kenel defconfig was tuned so that I only used a bare minimum of kernel modules, and nearly all except for 2 groups (one related to filesystem and the other for networking) was built as a module. The rest were all built into the kernel. Isn't this a regression or an error? Also my build time has gone up from 40 minutes to 67 minutes, probably as a result of the increased number of kernel modules being built and shipped. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
Hi Trevor, I just briefly tried building it, using gcc-4.5.1, and got build failures too. It looks like it will take some effort to get this up and running with the current version of yocto. I just managed to get powerpc440 soft-float working with gcc-4.5.1 eglibc-2.13 with a specific commit id for poky and meta-openembedded. Now I have to try and make that legacy gcc-4.5.1 support with with the latest poky and meta-openembedded master branch. Perhaps if you get a Xilinx SP601 board and dive in, you could help get microblaze up and running! Best regards, Elvis ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
Hi Trevor, On Sep 13, 2012, at 10:17 PM, Trevor Woerner wrote: ~$300 for the SP601 is certainly not too onerous. If I start to see more success with yocto I will definitely consider it. Other options include: - qemu (maybe getting yocto to run/build a microblaze qemu image would be nice) - the spartan-6 version of the papilio board (which is either going to be a papilio plus or the papilio pro) I do have one question though: if I had the SP601, would I be able to download (for free) an synthesize (using the freely available ISE tools) a microblaze and/or a PPC soft core? Or would I need to pay for those components (and if so, how much)? There are two parts of the design suite, ISE (for VHDL and Verilog) development, and XPS (EDK) for re-using the Xilinx IP cores in a project. To edit microblaze projects, you would need an EDK license. The standard webpack only includes a license for the ISE component, and is usually device locked to a particular set of devices, usually the low-end FPGAs. The SP601 comes only with the WebPack software, so hmm no, not suitable for what you want to do. What you really need is the ISE Embedded Edition or System Edition, in order to be able to configure your IP cores using the Xilinx Base System Builder, so that you can design your peripherals around a MicroBlaze (Virtex, Spartan) or ARM (Zynq) processor core. There are no soft PowerPC IP cores, only hard PowerPC IP cores on specific Virtex 4 (PPC405) / 5 (PPC440) FPGA variants, with the FXT designation. Xilinx stopped using PowerPC hard cores with the Virtex 5 series. So, series-6 and series-7 FPGAs don't have PowerPC any more, and the only option was to use a soft core processor like the microblaze. In the specific case of the Zynq series, they have a dual ARM Cortex-A9 hard core processor. I find that the Spartan-6 Embedded Kit (SP605 + ISE Design Suite Embedded Edition) gives you want you want, and the price listed on the website is USD$695. http://www.xilinx.com/products/boards-and-kits/DK-S6-EMBD-G.htm The other option is the Zynq-EPP 7020 platform which includes the base board with the ARM processor, and ISE Design Suite System Edition for USD$895. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
Hi,
On Sep 4, 2012, at 6:25 AM, Trevor Woerner wrote:
I was playing around with the meta-xilinx layer and tried to build
core-image-minimal for the spartan6 without success. I was wondering
if anyone has tried this lately and/or if anyone has any tips to
suggest?
Can you please list which version of the Xilinx ISE tools you are using? e.g.
12.4, 14.1, 14.2 ?
Could you also please list the Xilinx development board that you are using?
e.g. SP601 (Spartan6) ?
configuration:
I'm using the latest HEAD:
BB_VERSION= 1.15.3
TARGET_ARCH = microblaze
TARGET_OS = linux
MACHINE = spartan6-lx9mb
DISTRO= poky
DISTRO_VERSION= 1.2+snapshot-20120904
TUNE_FEATURES = m32 microblazeel
TARGET_FPU= soft
meta
meta-yocto= master:37c8597e7600385367257e8a513e003947ebef5b
meta-xilinx = master:d196fa93c7ff5e080d4c44e2b83aed472f32b2c7
conf/local.conf:
BB_NUMBER_THREADS = 4
PARALLEL_MAKE = -j 4
MACHINE ??= spartan6-lx9mb
DL_DIR = /home/trevor/devel/Downloads
DISTRO ?= poky
PACKAGE_CLASSES ?= package_rpm
EXTRA_IMAGE_FEATURES = debug-tweaks
USER_CLASSES ?= buildstats image-mklibs image-prelink
PATCHRESOLVE = noop
CONF_VERSION = 1
conf/bblayers.conf:
LCONF_VERSION = 5
BBPATH = ${TOPDIR}
BBFILES ?=
BBLAYERS ?= \
/home/trevor/devel/yocto/git-method/poky/meta \
/home/trevor/devel/yocto/git-method/poky/meta-yocto \
/home/trevor/devel/yocto/git-method/poky/meta-xilinx \
issues:
The first problem I encountered was trying to build gcc-cross-initial:
This target does not support --with-float.
If you look at the tune file, it says TARGET_FPU = soft, which means
software floating point emulation.
However, the gcc toolchain recipes are trying to build with hardware floating
point support, from the error message.
Let me know what you ISE development tool configuration and development
board is, and I'll see if I can divert a bit from target platform, and try to
explore getting the toolchain to build for the Microblaze processor.
I've got the following boards with me:
- Xilinx ML507 (Virtex 5 FX70T with PowerPC 440)
- Xilinx SP601 (Spartan 6)
- Xilinx Zynq (ARM Cortex A-9)
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Procedure to setup icecc for performing a distributed build
Hi Paul, On Sep 6, 2012, at 2:17 PM, Paul Eggleton wrote: Elvis, did you have any further luck with this? Unfortunately no. I've got two machines, both with quad-core intel i7 processors, but I just couldn't get icecc to work with yocto. I end up regularly perform fresh builds at least 5 to 6 times a day, and it takes me 2 hours to build core-image-minimal. Otherwise, Dmitry, any suggestions? I'm assuming you made use of icecc.bbclass since you made some changes to it a while ago... Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Procedure to setup icecc for performing a distributed build
Hi Gary, On Sep 6, 2012, at 7:31 PM, Gary Thomas wrote: On 2012-09-06 09:23, Elvis Dowson wrote: Unfortunately no. I've got two machines, both with quad-core intel i7 processors, but I just couldn't get icecc to work with yocto. I end up regularly perform fresh builds at least 5 to 6 times a day, and it takes me 2 hours to build core-image-minimal. Just wondering the exact details of your system and why your performance is so very different from mine. I have a HP box with 8-way Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz 12GB RAM It will build a Yocto image from scratch in around 40 minutes. I'm running Ubuntu 12.04 LTS virtualized on a 2011 Apple MacBook Pro 15, with VMware Fusion 5.0.1. The VMware disk image resides on a SSD drive with a 3G SATA interface. The specs are 2.3GHz Intel quad-core i7-2820QM with 8MB L3 cache, 8GB 1333 MHz RAM for the host. The Ubuntu 12.04 guest is configured with 4GB RAM, 8 virtual CPU cores. During core-image-minimal builds, the memory usage doesn't exceed 2 to 3GB. A linux kernel 3.3.0 build for a powepc440 target takes 1 min 40 seconds, as an additional data point. Maybe next year, when the newer Mac Pros come out, I'll probably invest in a 8-core or 10-core xeon configuration. The current Mac Pros are due for a refresh then, so I'm waiting for the next hardware update. I'm also considered buying an IBM Blade server, but haven't made up my mind yet. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_FPU not getting populated for powerpc 405/440 fpu-hard targets
Hi Khem,
On Aug 24, 2012, at 8:35 PM, Khem Raj wrote:
On Fri, Aug 24, 2012 at 9:27 AM, Elvis Dowson elvis.dow...@gmail.com wrote:
I just observed that TARGET_FPU is not getting populated, when you do
a build for fpu-hard targets. For fpu-soft targets, it displays TARGET_FPU =
soft, but for fpu-hard targets, it display TARGET_FPU = .
that means default is hard for this architecture. This option is
essentially used to configure gcc
unless your fpu is special like fsl one's you are good here.
The FPU unit is an IP core, that is attached to a generic PowerPC405 or
PowerPC440 embedded processor core on the FPGA, which by default doesn't
contain an FPU unit.
In the Xilinx FPGA hardware project, I have to add this FPU unit, and there are
some additional options that I can see relevant to this setup with the FPU
unit, such as -mxilinx-fpu and -mfpu=dp_full
Should I specify them in TUNE_CCARGS (as shown below) or
TUNE_FEATURES_tune-ppc405e (not done below) or specify the same values for both
variables ?
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppc405e, -mcpu=405fp
-mxilinx-fpu -mfpu=dp_full, , d)}
AVAILTUNES += ppc405e
TUNE_FEATURES_tune-ppc405e = m32 ppc405e fpu-hard
Best regards,
Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] libgcc_s.so libstdc++.so on the target
Hi, I notice that core-image-minimal doesn't ship libgcc_s.so and libstdc++.so shared libraries on the target. Some of the executables that I manually cross compile on the host, and copy over to the target, require these libraries at a minimum. Which package or task should I append, to core-image-minimal, to get these two shared libraries file to get copied over to the rootfilesystem image tarball? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor
Hi Khem, On Aug 17, 2012, at 9:48 AM, Khem Raj wrote: On Tue, Aug 14, 2012 at 7:26 AM, Khem Raj raj.k...@gmail.com wrote: There are differences in eglibc.inc and initrd recipes. Try to see if they make difference Also the libgcc one after the above two Elvis Did you try the above ? I have pushed a patch into my contrib tree. http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/miscid=502a61792cdb219c1ee35bb9474b8f0c4b007385 can you try that out and see if it helps with gcc 4.7 I had to manually apply the patch to poky/master. The gcc-4.7 patch alone didn't fix the issue with not getting a bash prompt, which makes sense I guess, since the eglibc recipes also need to be modified to ensure that the soft-float libraries are also generated into the target root filesystem. I'll now, make the necessary changes to eglibc-2.13, in poky/master, with gcc-4.7, and see if it works. If it does, then I'll adapt the same solution for eglibc-2.15, eglibc-2.16, and gcc-4.6 recipes, and sent them across. Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor
hi Khem,
On Aug 19, 2012, at 10:08 AM, Elvis Dowson wrote:
I'll now, make the necessary changes to eglibc-2.13, in poky/master, with
gcc-4.7, and see if it works.
Sorry, I meant to say libgcc-4.7
diff --git a/tool/yocto/poky/meta/recipes-devtools/gcc/libgcc_4.6.bb
b/tool/eldk/meta/recipes-devtools/gcc/libgcc_4.6.bb
index 9a8b20d..f75ca34 100644
--- a/tool/yocto/poky/meta/recipes-devtools/gcc/libgcc_4.6.bb
+++ b/tool/eldk/meta/recipes-devtools/gcc/libgcc_4.6.bb
@@ -16,8 +16,10 @@ PACKAGES = \
FILES_${PN} = ${base_libdir}/libgcc*.so.*
FILES_${PN}-dev = \
${base_libdir}/libgcc*.so \
- ${libdir}/${TARGET_SYS}/${BINV}/*crt* \
- ${libdir}/${TARGET_SYS}/${BINV}/libgcc*
+ ${libdir}/${TARGET_SYS}/${BINV}/crt* \
+ ${libdir}/${TARGET_SYS}/${BINV}/libgcc* \
+ ${libdir}/${TARGET_SYS}/${BINV}/nof/crt* \
+ ${libdir}/${TARGET_SYS}/${BINV}/nof/libgcc*
FILES_libgcov${PKGSUFFIX}-dev = \
${libdir}/${TARGET_SYS}/${BINV}/libgcov.a
Best regards,
Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor
Hi Khem, On Aug 17, 2012, at 9:48 AM, Khem Raj wrote: On Tue, Aug 14, 2012 at 7:26 AM, Khem Raj raj.k...@gmail.com wrote: There are differences in eglibc.inc and initrd recipes. Try to see if they make difference Also the libgcc one after the above two Did you try the above ? I took a slight detour, the past 2 days, trying to use icecc, to reduce my build time across two quad-core i7 Ubuntu machines, but that didn't work for some reason. No workloads got distributed across to the second machine. I'll get back to continuing these tests this weekend. I have pushed a patch into my contrib tree. http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/miscid=502a61792cdb219c1ee35bb9474b8f0c4b007385 can you try that out and see if it helps with gcc 4.7 Will do that for sure! :-) Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] IMX 6 quad core development kit
Hi, Any suggestions for an IMX 6 quad core development kit? Has Yocto been tested on the IMX 6 ARM processor? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using distcc with poky
Hi Khem. On May 5, 2012, at 11:39 PM, Khem Raj wrote: On 05/05/2012 10:35 AM, Elvis Dowson wrote: Hi, Is it possible to tell poky to use distcc, to perform a distributed build across two ubuntu 12.04 machines on a netwrok? there is icecc have a look at meta/classes/icecc.bbclass How do I setup yocto to use icecc? I've setup icecc on two ubuntu 12.04 machines. Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor
Hi Khem, I also just tried gcc-4.6.3 and eglibc-2.13, and I get a segmentation fault while running /bin/getty, and a kernel panic when running init=/bin/bash, building off poky/master branch recipes. zImage starting: loaded at 0x0080 (sp: 0x0185dfa0) Allocating 0x548f0c bytes for kernel ... gunzipping (0x - 0x0080f000:0x00a1563f)...done 0x42b5c0 bytes Attached initrd image at 0x00a16000-0x0185ce95 initrd head: 0x1f8b0808 Linux/PowerPC load: console=ttyS0,9600n8 ip=off root=/dev/ram rw rootwait init=/bin/sh Finalizing device tree... flat tree at 0x186a0e0 PM: Adding info for No Bus:ttyv9 [0.588026] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [0.593401] 83e0.serial: ttyS0 at MMIO 0x83e01003 (irq = 20) is a 16550 [0.788848] console [ttyS0] enabled [0.834170] brd: module loaded [0.880867] loop: module loaded [0.918134] xsysace 8360.sysace: Xilinx SystemACE revision 1.0.12 [0.994836] xsysace 8360.sysace: No CF in slot [1.053840] Xilinx SystemACE device driver, major=254 [1.114793] xilinx_emaclite 8100.ethernet: Device Tree Probing [1.188315] xilinx_emaclite 8100.ethernet: error registering MDIO bus [1.269388] xilinx_emaclite 8100.ethernet: MAC address is now 00:0a:35:b7:78:00 [1.363146] xilinx_emaclite 8100.ethernet: Xilinx EmacLite at 0x8100 mapped to 0xD10A, irq=17 [1.477955] xilinx_ps2 8148.ps2: Device Tree Probing 'ps2' [1.547173] xilinx_ps2 8148.ps2: Xilinx PS2 at 0x8148 mapped to 0xd1036000, irq=22 [1.646551] xilinx_ps2 81481000.ps2: Device Tree Probing 'ps2' [1.716251] xilinx_ps2 81481000.ps2: Xilinx PS2 at 0x81481000 mapped to 0xd1038000, irq=23 [1.816836] mousedev: PS/2 mouse device common for all mice [1.884361] i2c /dev entries driver [1.925909] Device Tree Probing 'i2c' [1.970181] xilinx-iic #0 at 0x8160 mapped to 0xD10C, irq=18 [2.047926] TCP cubic registered [2.085783] NET: Registered protocol family 17 [2.882898] atkbd serio0: keyboard reset failed on xilinxps2/serio at 8148 [3.367192] RAMDISK: gzip image found at block 0 [3.891097] input: AT Raw Set 2 keyboard as /devices/plb.0/xps-ps2.1/81481000.ps2/serio1/input/input0 [6.271270] EXT2-fs (ram0): warning: mounting unchecked fs, running e2fsck is recommended [6.368556] VFS: Mounted root (ext2 filesystem) on device 1:0. [6.439318] Freeing unused kernel memory: 156k freed /bin/sh: can't access tty; job control turned off [6.583032] Kernel panic - not syncing: Attempted to kill init! [6.653114] Rebooting in 180 seconds.. So, in summary: The following combinations didn't work for the poky/master branch gcc-4.5.1, eglibc-2.15, binutils-2.22 gcc-4.5.1, eglibc-2.16, binutils-2.22 gcc-4.6.3, eglibc-2.13, binutils-2.22 gcc-4.7.2, eglibc-2.13, binutils-2.22 The combinations that worked are gcc-4.5.1, eglibc-2.13, binutils-2.22 (from poky/master) gcc-4.6.3, eglibc-2.13, binutils-2.22 (from the Denx ELDK 5.2.1 release, which corresponds to the denzil release) What would you like me to do next, to try and narrow down this issue? Some things that I can try are: a. build gcc-4.6.3, eglibc-2.13, binutils-2.22 (from poky/denzil branch, to establish a known good build data point) b. try and build gcc-4.8.0, with eglibc-2.13, binutils-2.22 (I prepare a gcc-4.8 recipe already, but need to try it out) c. try eglibc-2.13/2.15/2.16 combination with gcc-4.5.1 and binutils-2.22 on a different architecture (e.g. TI OMAP 3530 ARM Cortex A8 Gumstix Overo, TI OMAP 4430 PandaBoard, Xilinx Zynq-7020 Dual ARM Cortex A9) just to see if the problem manifests on different architectures as well Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor
Hi Khem, I've made tangential progress!! I found out that Denx had a bunch of pre-built rootfilesystems, generated from yocto/denzil branch. I took the core-image-core-generic-powerpc-4xx-softfloat.tar.gz from the following location: ftp://ftp.denx.de/pub/eldk/5.2.1/targets/powerpc-4xx-softfloat I used the linux-xilinx-3.3.0 kernel that I built earlier (since the linux sources are independent) with gcc-4.5.1, and use the pre-build root filesystem, and guess what, I get the bash prompt!! zImage starting: loaded at 0x0080 (sp: 0x016defa0) Allocating 0x54cf4c bytes for kernel ... gunzipping (0x - 0x0080f000:0x00a1aedf)...done 0x42f600 bytes Attached initrd image at 0x00a1b000-0x016ddb0f initrd head: 0x1f8b0808 Linux/PowerPC load: console=ttyS0,9600n8 ip=off root=/dev/ram rw rootwait init=/bin/sh Finalizing device tree... flat tree at 0x16eb0e0 PM: Adding info for No Bus:ttyv9 [0.572492] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [0.577880] 83e0.serial: ttyS0 at MMIO 0x83e01003 (irq = 20) is a 16550 [0.773419] console [ttyS0] enabled [0.818736] brd: module loaded [0.865394] loop: module loaded [0.902715] xsysace 8360.sysace: Xilinx SystemACE revision 1.0.12 [0.979410] xsysace 8360.sysace: No CF in slot [1.038416] Xilinx SystemACE device driver, major=254 [1.099449] xilinx_emaclite 8100.ethernet: Device Tree Probing [1.172953] xilinx_emaclite 8100.ethernet: error registering MDIO bus [1.254057] xilinx_emaclite 8100.ethernet: MAC address is now 00:0a:35:b7:78:00 [1.347806] xilinx_emaclite 8100.ethernet: Xilinx EmacLite at 0x8100 mapped to 0xD10A, irq=17 [1.462670] xilinx_ps2 8148.ps2: Device Tree Probing 'ps2' [1.531949] xilinx_ps2 8148.ps2: Xilinx PS2 at 0x8148 mapped to 0xd1036000, irq=22 [1.631395] xilinx_ps2 81481000.ps2: Device Tree Probing 'ps2' [1.701014] xilinx_ps2 81481000.ps2: Xilinx PS2 at 0x81481000 mapped to 0xd1038000, irq=23 [1.801542] mousedev: PS/2 mouse device common for all mice [1.869031] i2c /dev entries driver [1.910602] Device Tree Probing 'i2c' [1.954862] xilinx-iic #0 at 0x8160 mapped to 0xD10C, irq=18 [2.032541] TCP cubic registered [2.070347] NET: Registered protocol family 17 [2.867055] atkbd serio0: keyboard reset failed on xilinxps2/serio at 8148 [3.351351] RAMDISK: gzip image found at block 0 [3.875264] input: AT Raw Set 2 keyboard as /devices/plb.0/xps-ps2.1/81481000.ps2/serio1/input/input0 [6.223416] EXT2-fs (ram0): warning: mounting unchecked fs, running e2fsck is recommended [6.320721] VFS: Mounted root (ext2 filesystem) on device 1:0. [6.391510] Freeing unused kernel memory: 160k freed /bin/sh: can't access tty; job control turned off / # The following link gives
[yocto] gnutls_2.12.20: Incorrect location for header file
Hi, While trying to build gnutls_2.12.20.bb recipe, with gcc-4.5, using the current poky master, I get the following error: | In file included from gnutlsxx.cpp:5:0: | ./includes/gnutls/gnutlsxx.h:4:21: fatal error: exception: No such file or directory The header file is located under the following folder /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gnutls-2.12.20-r8.3/gnutls-2.12.20/lib/includes/gnutls how do I modify the recipe, so that it prefixes the lib folder, to the patch so that it can properly locate it under ./lib/includes/gnutls/ instead of ./includes/gnutls/ Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor
Hi Khem, I just noticed that libquadmath was disabled in the gcc-4.7.inc recipe. EXTRA_OECONF_INITIAL = --disable-libmudflap \ --disable-libgomp \ --disable-libssp \ --disable-libquadmath \ --with-system-zlib \ --disable-lto \ --disable-plugin \ --enable-decimal-float=no Isn't that required for powerpc targets, since it ends up using quads for floats? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor
Hi Khem, I added support for gcc-4.5.1 inside meta-openembedded/toolchain-layer, and got it building against the latest yocto/master branch. However, switching to gcc-4.5.1 did not fix the issue. Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] external-sourcery-toolchain: ERROR: Function failed: do_install
Hi, I cloned the meta-sourcery repo, added it to my bblayers.conf $ cd /tool/yocto $ git clone git://github.com/MentorEmbedded/meta-sourcery.git I specified the following variables in my local.conf: # Set the toolchain. TCMODE = external-csl EXTERNAL_TOOLCHAIN = /tool/mentor/csl-2011.03-39 CSL_TARGET_SYS_powerpc = powerpc-eabi I get the following error, when I try to run bitbake core-image-minimal: ERROR: Function failed: do_install (see /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646 for further information) ERROR: Logfile of failure stored in: /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646 Log data follows: | DEBUG: Executing shell function do_install | cp: target `/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/image/lib' is not a directory | ERROR: Function failed: do_install (see /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646 for further information) NOTE: package external-sourcery-toolchain-2011.03-39-r12: task do_install: Failed ERROR: Task 41 (/tool/yocto/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb, do_install) failed with exit code '1' Waiting for 3 running tasks to finish: 0: ncurses-native-5.9-r10.1 do_configure (pid 31329) 1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503) 2: zlib-native-1.2.7-r0 do_compile (pid 31632) NOTE: package attr-native-2.4.46-r4: task do_fetch: Started Waiting for 4 running tasks to finish: 0: ncurses-native-5.9-r10.1 do_configure (pid 31329) 1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503) 2: zlib-native-1.2.7-r0 do_compile (pid 31632) 3: attr-native-2.4.46-r4 do_fetch (pid 31843) NOTE: package attr-native-2.4.46-r4: task do_fetch: Succeeded Waiting for 3 running tasks to finish: 0: ncurses-native-5.9-r10.1 do_configure (pid 31329) 1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503) 2: zlib-native-1.2.7-r0 do_compile (pid 31632) NOTE: package openssl-native-1.0.0j-r15.3: task do_unpack: Succeeded Waiting for 2 running tasks to finish: 0: ncurses-native-5.9-r10.1 do_configure (pid 31329) 1: zlib-native-1.2.7-r0 do_compile (pid 31632) NOTE: package zlib-native-1.2.7-r0: task do_compile: Succeeded Waiting for 1 running tasks to finish: 0: ncurses-native-5.9-r10.1 do_configure (pid 31329) NOTE: package ncurses-native-5.9-r10.1: task do_configure: Succeeded NOTE: Tasks Summary: Attempted 97 tasks of which 63 didn't need to be rerun and 1 failed. Summary: 1 task failed: /tool/yocto/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb, do_install Summary: There were 5 ERROR messages shown, returning a non-zero exit code. How can I resolve this error? Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] external-sourcery-toolchain: ERROR: Function failed: do_install
Hi,
On Aug 10, 2012, at 7:37 PM, Elvis Dowson wrote:
I cloned the meta-sourcery repo, added it to my bblayers.conf
$ cd /tool/yocto
$ git clone git://github.com/MentorEmbedded/meta-sourcery.git
I specified the following variables in my local.conf:
# Set the toolchain.
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /tool/mentor/csl-2011.03-39
CSL_TARGET_SYS_powerpc = powerpc-eabi
I get the following error, when I try to run bitbake core-image-minimal:
ERROR: Function failed: do_install (see
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646
for further information)
ERROR: Logfile of failure stored in:
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646
Log data follows:
| DEBUG: Executing shell function do_install
| cp: target
`/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/image/lib'
is not a directory
| ERROR: Function failed: do_install (see
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/external-sourcery-toolchain-2011.03-39-r12/temp/log.do_install.31646
for further information)
NOTE: package external-sourcery-toolchain-2011.03-39-r12: task do_install:
Failed
ERROR: Task 41
(/tool/yocto/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb,
do_install) failed with exit code '1'
Waiting for 3 running tasks to finish:
0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503)
2: zlib-native-1.2.7-r0 do_compile (pid 31632)
NOTE: package attr-native-2.4.46-r4: task do_fetch: Started
Waiting for 4 running tasks to finish:
0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503)
2: zlib-native-1.2.7-r0 do_compile (pid 31632)
3: attr-native-2.4.46-r4 do_fetch (pid 31843)
NOTE: package attr-native-2.4.46-r4: task do_fetch: Succeeded
Waiting for 3 running tasks to finish:
0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
1: openssl-native-1.0.0j-r15.3 do_unpack (pid 31503)
2: zlib-native-1.2.7-r0 do_compile (pid 31632)
NOTE: package openssl-native-1.0.0j-r15.3: task do_unpack: Succeeded
Waiting for 2 running tasks to finish:
0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
1: zlib-native-1.2.7-r0 do_compile (pid 31632)
NOTE: package zlib-native-1.2.7-r0: task do_compile: Succeeded
Waiting for 1 running tasks to finish:
0: ncurses-native-5.9-r10.1 do_configure (pid 31329)
NOTE: package ncurses-native-5.9-r10.1: task do_configure: Succeeded
NOTE: Tasks Summary: Attempted 97 tasks of which 63 didn't need to be rerun
and 1 failed.
Summary: 1 task failed:
/tool/yocto/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb,
do_install
Summary: There were 5 ERROR messages shown, returning a non-zero exit code.
How can I resolve this error?
I found the solution. I had to specify NO32LIBS = 0, since I'm building on an
Ubuntu 12.04 64-bit machine.
# Set the toolchain.
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /tool/mentor/csl-2012.03.71
NO32LIBS = 0
CSL_TARGET_SYS_powerpc = powerpc-mentor-linux-gnu
PREFERRED_PROVIDER_linux-libc-headers = external-sourcery-toolchain
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc = external-sourcery-toolchain
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-initial =
external-sourcery-toolchain
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-intermediate =
external-sourcery-toolchain
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ = external-sourcery-toolchain
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils =
external-sourcery-toolchain
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc =
external-sourcery-toolchain
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}compilerlibs =
external-sourcery-toolchain
PREFERRED_PROVIDER_libgcc = external-sourcery-toolchain
PREFERRED_PROVIDER_eglibc = external-sourcery-toolchain
PREFERRED_PROVIDER_virtual/libc = external-sourcery-toolchain
PREFERRED_PROVIDER_virtual/libintl = external-sourcery-toolchain
PREFERRED_PROVIDER_virtual/libiconv = external-sourcery-toolchain
PREFERRED_PROVIDER_gdbserver = external-sourcery-toolchain
The build is progressing along now.
Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] external-sourcery-toolchain: ERROR: QA Issue: No GNU_HASH in the elf binary
Hi,
On Aug 10, 2012, at 8:41 PM, Chris Larson wrote:
On Fri, Aug 10, 2012 at 9:37 AM, Elvis Dowson elvis.dow...@gmail.com wrote:
I'm building with the mentor external-sourcery-toolchain.
I get the following error:
ERROR: QA Issue: No GNU_HASH in the elf binary:
'/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipcloak'
ERROR: QA Issue: No GNU_HASH in the elf binary:
'/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zip'
ERROR: QA Issue: No GNU_HASH in the elf binary:
'/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipsplit'
ERROR: QA Issue: No GNU_HASH in the elf binary:
'/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipnote'
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
ERROR: Logfile of failure stored in:
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/temp/log.do_package.47453
Adding the following statement to zip.bb doesn't fix the problem, like it
used to when using the gcc-4.x compilers:
TARGET_CC_ARCH += ${LDFLAGS}
I have bits that work around this by making the ldflags/gnu_hash check
nonfatal when using this toolchain, but they haven't gone into oe-core
yet. See
https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery.inc#L87-94
for details. You should be able to try a build using this layer, or
just grab those bits and put them into your oe-core
tcmode-external-sourcery.inc.
I haven't had time to pursue this meta-sourcery wrt upstream yet, but
I think in the long term it's the best approach for supporting the
sourcery g++ toolchain. I think all we should keep in oe-core is
either a sample/example config, a link to that layer, or a
configuration for a toolchain that doesn't require as much tweaking
(e.g. tuning arguments), such as crosstool-ng. That isn't related to
your issue, but is why I haven't been quite as proactive about pushing
fixes to the tcmode in oe-core recently.
Copy pasting the tcmode-external-sourcery.inc file from your meta-sourcery
repo, to oe-core fixes the issue.
Thanks for the timely assist!! :-)
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] external-sourcery-toolchain: cp: cannot stat `/tool/yocto/poky/build/tmp/sysroots/virtex5/usr/share/gettext/config.rpath': No such file or directory
Hi, When using the mentor external-sourcery-toolchain, I get the following error: NOTE: package gdbm-1.10-r3: task do_configure: Started ERROR: Function failed: do_configure (see /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409 for further information) ERROR: Logfile of failure stored in: /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: SITE files ['endian-big', 'bit-32', 'powerpc-common', 'common-linux', 'common-glibc', 'powerpc32-linux', 'powerpc-linux', 'common'] | DEBUG: Executing shell function do_configure | automake (GNU automake) 1.12.1 | Copyright (C) 2012 Free Software Foundation, Inc. | License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl-2.0.html | This is free software: you are free to change and redistribute it. | There is NO WARRANTY, to the extent permitted by law. | | Written by Tom Tromey tro...@redhat.com |and Alexandre Duret-Lutz a...@gnu.org. | AUTOV is 1.12 | cp: cannot stat `/tool/yocto/poky/build/tmp/sysroots/virtex5/usr/share/gettext/config.rpath': No such file or directory | ERROR: Function failed: do_configure (see /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409 for further information) NOTE: package gdbm-1.10-r3: task do_configure: Failed ERROR: Task 541 (/tool/yocto/poky/meta/recipes-support/gdbm/gdbm_1.10.bb, do_configure) failed with exit code '1' Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] external-sourcery-toolchain: cp: cannot stat `/tool/yocto/poky/build/tmp/sysroots/virtex5/usr/share/gettext/config.rpath': No such file or directory
Hi, On Aug 10, 2012, at 9:07 PM, Elvis Dowson wrote: When using the mentor external-sourcery-toolchain, I get the following error: NOTE: package gdbm-1.10-r3: task do_configure: Started ERROR: Function failed: do_configure (see /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409 for further information) ERROR: Logfile of failure stored in: /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: SITE files ['endian-big', 'bit-32', 'powerpc-common', 'common-linux', 'common-glibc', 'powerpc32-linux', 'powerpc-linux', 'common'] | DEBUG: Executing shell function do_configure | automake (GNU automake) 1.12.1 | Copyright (C) 2012 Free Software Foundation, Inc. | License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl-2.0.html | This is free software: you are free to change and redistribute it. | There is NO WARRANTY, to the extent permitted by law. | | Written by Tom Tromey tro...@redhat.com |and Alexandre Duret-Lutz a...@gnu.org. | AUTOV is 1.12 | cp: cannot stat `/tool/yocto/poky/build/tmp/sysroots/virtex5/usr/share/gettext/config.rpath': No such file or directory | ERROR: Function failed: do_configure (see /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/gdbm-1.10-r3/temp/log.do_configure.53409 for further information) NOTE: package gdbm-1.10-r3: task do_configure: Failed ERROR: Task 541 (/tool/yocto/poky/meta/recipes-support/gdbm/gdbm_1.10.bb, do_configure) failed with exit code '1' I solved the problem, I ignored a warning saying that there were multiple providers for virtual/gettext. When I looked at the target folder, gettext was missing. I added the following entry to my local.conf file, and the build is now progressing : PREFERRED_PROVIDER_virtual/gettext = gettext Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] external-sourcery-toolchain: do_compile failed for sqlite3-3.7.13
=440 -msoft-float --sysroot=/tool/yocto/poky/build/tmp/sysroots/virtex5 -shared -fPIC -DPIC .libs/sqlite3.o -ldl -lpthread -m32 -msoft-float -mcpu=440 -msoft-float --sysroot=/tool/yocto/poky/build/tmp/sysroots/virtex5 -O2 -Wl,-O1 -Wl,--hash-style=gnu -Wl,-soname -Wl,libsqlite3.so.0 -o .libs/libsqlite3.so.0.8.6 | powerpc-poky-linux-libtool: link: (cd .libs rm -f libsqlite3.so.0 ln -s libsqlite3.so.0.8.6 libsqlite3.so.0) | powerpc-poky-linux-libtool: link: (cd .libs rm -f libsqlite3.so ln -s libsqlite3.so.0.8.6 libsqlite3.so) | powerpc-poky-linux-libtool: link: powerpc-mentor-linux-gnu-ar cru .libs/libsqlite3.a sqlite3.o | powerpc-poky-linux-libtool: link: powerpc-mentor-linux-gnu-ranlib .libs/libsqlite3.a | powerpc-poky-linux-libtool: link: ( cd .libs rm -f libsqlite3.la ln -s ../libsqlite3.la libsqlite3.la ) | ./powerpc-poky-linux-libtool --tag=CC --mode=link powerpc-mentor-linux-gnu-gcc -m32 -msoft-float -mcpu=440 -msoft-float --sysroot=/tool/yocto/poky/build/tmp/sysroots/virtex5 -D_REENTRANT=1 -DSQLITE_THREADSAFE=1 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -o sqlite3 shell.o ./libsqlite3.la -lreadline -lcurses -ldl -lpthread | powerpc-poky-linux-libtool: link: powerpc-mentor-linux-gnu-gcc -m32 -msoft-float -mcpu=440 -msoft-float --sysroot=/tool/yocto/poky/build/tmp/sysroots/virtex5 -D_REENTRANT=1 -DSQLITE_THREADSAFE=1 -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -o .libs/sqlite3 shell.o ./.libs/libsqlite3.so -lreadline -lcurses -ldl -lpthread | ./.libs/libsqlite3.so: undefined reference to `__gcc_qtod' | ./.libs/libsqlite3.so: undefined reference to `__gcc_qneg' | ./.libs/libsqlite3.so: undefined reference to `__gcc_qge' | ./.libs/libsqlite3.so: undefined reference to `__gcc_qlt' | ./.libs/libsqlite3.so: undefined reference to `__gcc_itoq' | ./.libs/libsqlite3.so: undefined reference to `__gcc_qtoi' | ./.libs/libsqlite3.so: undefined reference to `__gcc_qgt' | ./.libs/libsqlite3.so: undefined reference to `__gcc_dtoq' | collect2: ld returned 1 exit status | make: *** [sqlite3] Error 1 | ERROR: oe_runmake failed | ERROR: Function failed: do_compile (see /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/sqlite3-3.7.13-r0/temp/log.do_compile.48315 for further information) NOTE: package sqlite3-3.7.13-r0: task do_compile: Failed Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky/bernard: gcc-4.5.1 configure: error: cannot compute suffix of object files: cannot compile
Hi Khem, On Aug 9, 2012, at 1:23 AM, Khem Raj wrote: Elvis I think gcc 4.6 is retired in toolchain-layer in meta-openembedded repo. I think first thing I would suggest is use that layer and use gcc 4.6 this might work better. I think 4.6 should still work with master or we can kind of fix it if need be. Then if you are still unlucky then use 4.5.1 Ok, just reconfigured all my layers to use the latest poky and meta-openembedded updates, and set the preferred versions for gcc to 4.6, and will give it a try. I just have one question though. The current kernel that I'm using is linux-3.3.0 from the xilinx repo. The poky master branch build is using linux-libc-headers_3.4.3.bb. Should I ensure that the version of the kernel and the linux-libc-headers match, by creating a linux-libc-headers_3.3.0.bb recipe and setting the preferred_versions accordingly? Would this mismatch cause issues? Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Incorrect warning: preferred version linux-libc-headers_3.3 of linux-libc-headers not available (for item linux-libc-headers)
Hi, In my local.conf I have set the following variable PREFERRED_VERSION_linux-libc-headers = linux-libc-headers_3.3 However, when I run bitbake linux-libc-headers -c fetchall, it complains that the preferred version is not available, even though I've created a linux-libc-headers_3.3.bb recipe and set the preferred version in my local.conf NOTE: preferred version linux-libc-headers_3.3 of linux-libc-headers not available (for item linux-libc-headers) NOTE: versions of linux-libc-headers available: 3.0.8 3.2 3.3 3.4.3 NOTE: Resolving any missing task queue dependencies NOTE: preferred version linux-libc-headers_3.3 of linux-libc-headers not available (for item linux-libc-headers-dev) NOTE: versions of linux-libc-headers available: 3.0.8 3.2 3.3 3.4.3 NOTE: Preparing runqueue NOTE: Executing RunQueue Tasks NOTE: Running task 2 of 3 (ID: 0, /tool/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.3.bb, do_fetch) NOTE: package linux-libc-headers-3.3-r0: task do_fetch: Started Why is this so? Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Incorrect warning: preferred version linux-libc-headers_3.3 of linux-libc-headers not available (for item linux-libc-headers)
Hi Bruce, On Aug 9, 2012, at 6:50 PM, Bruce Ashfield wrote: On 12-08-09 10:48 AM, Elvis Dowson wrote: Hi, In my local.conf I have set the following variable PREFERRED_VERSION_linux-libc-headers = linux-libc-headers_3.3 Have you tried dropping the linux-libc-headers ? i.e. PREFERRED_VERSION_linux-libc-headers = 3.3 Ahh, ok, that worked. Along similar lines, if I had to explicitly set the gcc version, is it correct to specify the following variables? PREFERRED_VERSION_gcc = gcc_4.6 PREFERRED_VERSION_gcc-cross = gcc-cross_4.6 PREFERRED_VERSION_gcc-cross-initial = gcc-cross-initial_4.6 PREFERRED_VERSION_gcc-cross-intermediate = gcc-cross-intermediate_4.6 PREFERRED_VERSION_gcc-cross-canadian = gcc-cross-canadian_4.6 PREFERRED_VERSION_gcc-crosssdk= gcc-crosssdk_4.6 PREFERRED_VERSION_gcc-crosssdk-initial= gcc-crosssdk-initial_4.6 PREFERRED_VERSION_gcc-crosssdk-intermediate= gcc-crosssdk-intermediate_4.6 PREFERRED_VERSION_gcc-runtime = gcc-runtime_4.6 PREFERRED_VERSION_libgcc = libgcc_4.6 Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor
Hi, I switched to using gcc-4.6 from the meta-openembedded layer, and still get the same issue, i.e. no login or bash prompt with init=/bin/sh zImage starting: loaded at 0x0080 (sp: 0x016d2fa0) Allocating 0x546e0c bytes for kernel ... gunzipping (0x - 0x0080f000:0x00a14e83)...done 0x4295c0 bytes Attached initrd image at 0x00a15000-0x016d1e57 initrd head: 0x1f8b0808 Linux/PowerPC load: console=ttyS0,9600n8 ip=off root=/dev/ram rw rootwait init=/bin/sh Finalizing device tree... flat tree at 0x16df0e0 PM: Adding info for No Bus:ttyv9 [0.571186] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [0.576568] 83e0.serial: ttyS0 at MMIO 0x83e01003 (irq = 20) is a 16550 [0.772047] console [ttyS0] enabled [0.836379] brd: module loaded [0.883293] loop: module loaded [0.920576] xsysace 8360.sysace: Xilinx SystemACE revision 1.0.12 [0.997321] xsysace 8360.sysace: No CF in slot [1.056390] Xilinx SystemACE device driver, major=254 [1.117274] xilinx_emaclite 8100.ethernet: Device Tree Probing [1.190788] xilinx_emaclite 8100.ethernet: error registering MDIO bus [1.271877] xilinx_emaclite 8100.ethernet: MAC address is now 00:0a:35:b7:78:00 [1.365554] xilinx_emaclite 8100.ethernet: Xilinx EmacLite at 0x8100 mapped to 0xD10A, irq=17 [1.480513] xilinx_ps2 8148.ps2: Device Tree Probing 'ps2' [1.549769] xilinx_ps2 8148.ps2: Xilinx PS2 at 0x8148 mapped to 0xd1036000, irq=22 [1.649154] xilinx_ps2 81481000.ps2: Device Tree Probing 'ps2' [1.718826] xilinx_ps2 81481000.ps2: Xilinx PS2 at 0x81481000 mapped to 0xd1038000, irq=23 [1.819612] mousedev: PS/2 mouse device common for all mice [1.887013] i2c /dev entries driver [1.928583] Device Tree Probing 'i2c' [1.972867] xilinx-iic #0 at 0x8160 mapped to 0xD10C, irq=18 [2.050528] TCP cubic registered [2.088448] NET: Registered protocol family 17 [2.882860] atkbd serio0: keyboard reset failed on xilinxps2/serio at 8148 [3.367142] RAMDISK: gzip image found at block 0 [3.895064] input: AT Raw Set 2 keyboard as /devices/plb.0/xps-ps2.1/81481000.ps2/serio1/input/input0 [6.255216] EXT2-fs (ram0): warning: mounting unchecked fs, running e2fsck is recommended [6.352491] VFS: Mounted root (ext2 filesystem) on device 1:0. [6.423252] Freeing unused kernel memory: 156k freed gdb, connected to the target board via JTAG to debug the kernel, also doesn't seem to complain: (gdb) syslog device: 'input0': device_add 7[3.890268] PM: Adding info for No Bus:input0 6[3.895007] input: AT Raw Set 2 keyboard as /devices/plb.0/xps-ps2.1/81481000.ps2/serio1/input/input0 7[4.110886] driver: 'serio1': driver_bound: bound to device 'atkbd' 7[4.110922] bus: 'serio': really_probe: bound device serio1 to driver atkbd 7[4.110956] bus: 'serio': driver_probe_device: matched device serio0 with driver psmouse 7[4.110975] bus: 'serio': really_probe: probing driver psmouse with device serio0 7[4.310941] psmouse: probe of serio0 rejects match -19 4[6.259162] EXT2-fs (ram0): warning: mounting unchecked fs, running e2fsck is recommended 6[6.356473] VFS: Mounted root (ext2 filesystem) on device 1:0. 6[6.427235] Freeing unused kernel memory: 156k freed So weird. Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Incorrect warning: preferred version linux-libc-headers_3.3 of linux-libc-headers not available (for item linux-libc-headers)
HI, On Aug 9, 2012, at 6:58 PM, Bruce Ashfield wrote: In my experience .. it is always just the version, not the package that you want to specify, so from all of those, you'd drop the gcc_ .. etc, from the string. Bruce PREFERRED_VERSION_gcc = gcc_4.6 PREFERRED_VERSION_gcc-cross = gcc-cross_4.6 PREFERRED_VERSION_gcc-cross-initial = gcc-cross-initial_4.6 PREFERRED_VERSION_gcc-cross-intermediate = gcc-cross-intermediate_4.6 PREFERRED_VERSION_gcc-cross-canadian = gcc-cross-canadian_4.6 PREFERRED_VERSION_gcc-crosssdk= gcc-crosssdk_4.6 PREFERRED_VERSION_gcc-crosssdk-initial= gcc-crosssdk-initial_4.6 PREFERRED_VERSION_gcc-crosssdk-intermediate= gcc-crosssdk-intermediate_4.6 PREFERRED_VERSION_gcc-runtime = gcc-runtime_4.6 PREFERRED_VERSION_libgcc = libgcc_4.6 If I set the values as follows: PREFERRED_VERSION_gcc = 4.5 PREFERRED_VERSION_gcc-cross = 4.5 PREFERRED_VERSION_gcc-cross-initial = 4.5 PREFERRED_VERSION_gcc-cross-intermediate = 4.5 PREFERRED_VERSION_gcc-cross-canadian = 4.5 PREFERRED_VERSION_gcc-crosssdk= 4.5 PREFERRED_VERSION_gcc-crosssdk-initial= 4.5 PREFERRED_VERSION_gcc-crosssdk-intermediate= 4.5 PREFERRED_VERSION_gcc-runtime = 4.5 PREFERRED_VERSION_libgcc = 4.5 I get the following warnings: NOTE: preferred version 4.5 of gcc not available (for item gcc) NOTE: versions of gcc available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: Resolving any missing task queue dependencies NOTE: preferred version 4.5 of gcc-cross not available (for item virtual/powerpc-poky-linux-gcc) NOTE: versions of gcc-cross available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of gcc-runtime not available (for item virtual/powerpc-poky-linux-compilerlibs) NOTE: versions of gcc-runtime available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of gcc not available (for item gcc) NOTE: versions of gcc available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of gcc-cross not available (for item virtual/powerpc-poky-linux-g++) NOTE: versions of gcc-cross available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of libgcc not available (for item libgcc) NOTE: versions of libgcc available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of gcc-cross-intermediate not available (for item virtual/powerpc-poky-linux-gcc-intermediate) NOTE: versions of gcc-cross-intermediate available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of libgcc not available (for item libgcc) NOTE: versions of libgcc available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of gcc-cross-initial not available (for item virtual/powerpc-poky-linux-gcc-initial) NOTE: versions of gcc-cross-initial available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 I've now got 3 gcc variants, 4.7 (in poky), 4.6 and 4.5 (in meta-openembedded), and it's automatically picking up 4.6, from the meta-openembedded/toolchain-layer. After gcc_4.6 recipe builds, and I attempt to re-run gcc_4.5, I get the following output: NOTE: preferred version 4.5 of gcc not available (for item gcc) NOTE: versions of gcc available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: Resolving any missing task queue dependencies NOTE: preferred version 4.5 of gcc-cross not available (for item virtual/powerpc-poky-linux-gcc) NOTE: versions of gcc-cross available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of gcc-runtime not available (for item virtual/powerpc-poky-linux-compilerlibs) NOTE: versions of gcc-runtime available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of gcc not available (for item gcc) NOTE: versions of gcc available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of gcc-cross not available (for item virtual/powerpc-poky-linux-g++) NOTE: versions of gcc-cross available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of libgcc not available (for item libgcc) NOTE: versions of libgcc available: 4.5.4+svnr189152 4.6.3+svnr184847 4.7.1.0+git1+1653160670db186c6243997447ecbe6ce5056648 NOTE: preferred version 4.5 of gcc-cross-intermediate not available (for item virtual/powerpc-poky-linux-gcc-intermediate) NOTE: versions of gcc-cross-intermediate
