Re: [yocto] PREEMPT-RT patch: wrong header
Hello, I think you need to set PREFERRED_VERSION_linux-headers, but I have no idea what you should set for yocto-rt. Regards, Marcin W dniu 07.12.2015 o 14:03, mike9874 channel pisze: Hello, i am building an image for qeumux86 with the PREEMT-RT patch. Therefore I use the following in my image.conf file: PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt" PREFERRED_VERSION_linux-yocto-rt ?= "4%" I get an image with the 4.1.8-rt8-yocto-preempt-rt kernel. I have an Application which is also build into the image where I try to use SCHED_DEADLINE with sched_setattr() and struct sched_attr from . My bitbake compiler throws following error: storage size of 'scheduling_attribut' isn't known. Where do I get the correct Headers to compile my application? Regards, Mike -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Migration 1.8 -> 2.0 opkg-cl missing in SDK
Hello, After migrating from 1.8 to 2.0 opkg-cl is missing in SDK (sdk - is generated by bitbake meta-toolchain command). Manual clearly states that opkg-cl is still avaliable: http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#configuring-the-pms I can not find any instruction how to migrate PMS based on opkg in sdk in 2.0 release, so my question is what should I change to make opk running in SDK? I am suspecting I need to replace opkg-cl with opkg, something more is needed? Regards, Marcin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration 1.8 -> 2.0 opkg-cl missing in SDK
Hi Paul, Thanks for clarification. Regards, Marcin W dniu 25.11.2015 o 20:04, Paul Eggleton pisze: Hi Marcin, On Wednesday 25 November 2015 17:49:19 mar.krzeminski wrote: After migrating from 1.8 to 2.0 opkg-cl is missing in SDK (sdk - is generated by bitbake meta-toolchain command). Manual clearly states that opkg-cl is still avaliable: http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#configuri ng-the-pms I can not find any instruction how to migrate PMS based on opkg in sdk in 2.0 release, so my question is what should I change to make opk running in SDK? I am suspecting I need to replace opkg-cl with opkg, something more is needed? opkg-cl has been renamed to opkg in opkg 0.3.0 (which was included in our 2.0 release). Probably something we ought to have noted in the 2.0 migration guide. Cheers, Paul -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] overriding install in recipe for nativesdk
Thanks for the clue, but as you mentioned u-boot is small so there is no big problem with that. W dniu 13.08.2015 o 19:36, Khem Raj pisze: On Tue, Jul 14, 2015 at 9:57 PM, Marcin Krzemiński mar.krzemin...@gmail.com wrote: Currently in our yocto layer there is a recipe for u-boot that also produce mkimage binary for host, I would like to have mkimage in SDK. Now, there is a separate recipe in yocto to do that, but I am wondering is it possible in some way to override install function for nativesdk. Then I could use same sources for u-boot and I won't be downloading them twice.maybe there is another way that I can try? you could use shared-workdir model like what kernel and gcc use but maintenance of such a setup is high clue it may be appealing for components with large sourcecode and multiple recipes uboot may not be particularly suitable -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Perl usage in recipe
Hello, In my recipe I want to call perl script that will create image. How should I do that to be absolutely sure that perl will be used from yocto not from my system? Maybe is there any example somewhere that I can check how this should be done? Regards, Marcin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Perl usage in recipe
W dniu 05.08.2015 o 20:08, Khem Raj pisze:
On Wed, Aug 5, 2015 at 10:23 AM, mar.krzeminski
mar.krzemin...@gmail.com wrote:
Hello,
In my recipe I want to call perl script that will create image.
How should I do that to be absolutely sure that perl will be used from yocto
not from my system?
Maybe is there any example somewhere that I can check how this should be
done?
inherit perlnative
Ok, thanks. And one more question.
How about scrip call after this inherit?
Can I use simple perl MY_SCRIPT or should I consider to use something
like this (from perf recipe)
inherit perlnative
# Env var which tells perl if it should use host (no) or target (yes) settings
export PERLCONFIGTARGET = ${@is_target(d)}
export PERL_INC =
${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}/CORE
export PERL_LIB =
${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}
export PERL_ARCHLIB =
${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}
Regards,
Marcin
Regards,
Marcin
--
___
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] Multiple conncetion to svn (svn+ssh)
Hi Brian, Paul,
Thanks for response.
W dniu 06.07.2015 o 17:11, Paul Eggleton pisze:
On Monday 06 July 2015 15:04:57 Bryan Evenson wrote:
Paul,
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: Monday, July 06, 2015 10:08 AM
To: Marcin Krzemiński
Cc: Bryan Evenson; yocto@yoctoproject.org
Subject: Re: [yocto] Multiple conncetion to svn (svn+ssh)
On Monday 06 July 2015 12:57:39 Bryan Evenson wrote:
Marcin,
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Marcin
Krzeminski
Sent: Friday, July 03, 2015 7:55 AM
To: yocto@yoctoproject.org
Subject: [yocto] Multiple conncetion to svn (svn+ssh)
Hello again,
I have 12 recipes that download code from same svn repository (using
svn+ssh)protocol. Recipes are grouped in packagegroup.
When I want to bitbake packagegroup fetcher fail, but when I run
recipe alone all is ok. I think it is because I want to open 8
connection to one svn repository.How can I fix this, for example by
allowing only eg. 2 recipes from packagegroup to be executed in
paralell.
There is no fetcher-specific variable that I know of, but I think you
can set PARALLEL_MAKE=2 in your recipes to reduce the number of
fetches on your repository at a time. The downside is your build will
go slower when it is building your recipes as it won't be doing as
many things in parallel.
That's not going to help. The parallelism we are talking about here is
across recipes - PARALLEL_MAKE is just passed through to make within one
task in one recipe, and make isn't even involved at the fetch stage.
Sorry, I grabbed the wrong variable. I meant BB_NUMBER_THREADS, not
PARALLEL_MAKE.
Sure, but that's not going to work either from within a recipe. It would work
at the configuration level but that'll quite severely impact build performance.
This was my first idea.
Something that might work would be to set a lockfile on the do_fetch task
such that only one of the recipes could fetch at once. That could not
allow
two executing at once, but at least it would solve the problem. e.g. you
could add this to all of the recipes:
do_fetch[lockfiles] += ${TMPDIR}/mysvnlock.lock
(The file name isn't critical, it just needs to be the same for all of the
recipes you wish to participate in the exclusive fetching.)
This works as you wrote, it is not a perfect solution for my problem,
but at least builds doesn't fail. Thanks!
I had no idea that we could do this. I don't see any documentation on
lockfiles anywhere. If you use a lockfile, do the all recipes with the same
lockfile wait until the lockfile is available before continuing on with
that step? Is there a timeout for waiting for the lockfile or does the
recipe wait indefinitely?
Yes, it's just a lock on the specified file - whoever gets there first can
continue, everyone else blocks, and it's an indefinite wait as far as
I'm aware.
It's a little obscure perhaps, but it is in the BitBake manual:
http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#variable-flags
Cheers,
Paul
Regards,
Marcin
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Can not compile u-boot with meta toolchain
Hi, I've got problem with compiling u-boot usind SDK. I am building image for my platform, then I am running commnad bitbake meta-toolchain. In result I've got: CC examples/standalone/hello_world.o LD examples/standalone/hello_world arm-poky-linux-gnueabi-ld.bfd: cannot find -lgcc make[2]: *** [examples/standalone/hello_world] Error 1 scripts/Makefile.build:421: recipe for target 'examples/standalone' failed make[1]: *** [examples/standalone] Error 2 Makefile:1145: recipe for target 'examples' failed make: *** [examples] Error 2 In yocto environment u-boot builds fine. I've also tried unset LDFLAGS unset CFLAGS unset CPPFLAHS before compilation. What might be wrong here? Regards, Marcin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can not compile u-boot with meta toolchain
That does the trick: make CROSS_COMPILE=arm-poky-linux-gnueabi- CC=arm-poky-linux-gnueabi-gcc --sysroot=/media/work/sdk/sysroots/armv7a-vfp-neon-poky-linux-gnueabi all Regards, Marcin W dniu 16.06.2015 o 21:16, mar.krzeminski pisze: Hi, I've got problem with compiling u-boot usind SDK. I am building image for my platform, then I am running commnad bitbake meta-toolchain. In result I've got: CC examples/standalone/hello_world.o LD examples/standalone/hello_world arm-poky-linux-gnueabi-ld.bfd: cannot find -lgcc make[2]: *** [examples/standalone/hello_world] Error 1 scripts/Makefile.build:421: recipe for target 'examples/standalone' failed make[1]: *** [examples/standalone] Error 2 Makefile:1145: recipe for target 'examples' failed make: *** [examples] Error 2 In yocto environment u-boot builds fine. I've also tried unset LDFLAGS unset CFLAGS unset CPPFLAHS before compilation. What might be wrong here? Regards, Marcin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Changing VIRTUAL-RUNTIME_init_manager for initramfs image
Hi, I have machine and in this machine I have two images. One of this images is image for kernel initramfs. In this image I want to change init manager to busybox mdev, while ine the other one I use udev. I can do that by changing VIRTUAL-RUNTIME_init_manager variable. And now is time for dummy qestion, but I am not sure, if I change this variable in particular image everything will be ok? Is this a proper way to do so? Regards, Marcin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing do_compile task and ordering problem
After reading manual I assumed that /deltask/ will reorder the dependences. If this is expected behaviour it is fine for me :) I use /noexec/ flag then. Regards, Marcin W dniu 21.05.2015 o 14:55, Paul Eggleton pisze: Hi Marcin, On Thursday 21 May 2015 12:47:05 Marcin Krzemiński wrote: I am writing recipe that inherits from *native*. I removed do_compile task using: *deltask do_compile* When i was ruing bitbake my-recipe all works fine, but when I added recipe to *EXTRA_IMAGEDEPENDS *and run* bitbake core-image-minimal *tasks were reordered in some strange way that task do_install was performed before do_fetch. When I hanged *deltask do_compile *to *do_compile[noexec] = 1 * all went back to normal. I found *deltask *in manual so I do not know, is it a bug or not? I suspect this is because all deltask does is delete the task, it does not reconnect the dependency chain such that tasks that depended on the deleted task would depend on the tasks that the deleted task depended upon, so what you get in this case is do_install no longer having any dependencies. To be honest the current behaviour seems reasonable to me, though it is not immediately obvious and ought to be described in the manual. I think in your situation you really do want to set the noexec flag rather than using deltask. Cheers, Paul -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Qemu - problem with nfs filesytem
Hi all, I want to set up a nfs user space server using runqemu-export-rootfs.sh script. When I run the unmodified script my exported filesystem can not be seen, but when I remove parameters: -x $NFS_NFSPROG and -y $NFS_MOUNTPRO from unfsd and remove corresponding command line parameters all is working fine. Those parameters are responsible for setting rpc ports for nfs service. Google says there is some patch to kernel allowing rpc services or higher port in yocto: https://lists.yoctoproject.org/pipermail/yocto/2011-September/002741.html, but I can not see them in poky 1.6. I am using kernel 3.14. Is there any patches that I need to apply, or maybe I do something wrong? Regards, Marcin ** -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
