[yocto] fido: funny ipk behavior
Hi,
I have a simple recipe like this:
---
DESCRIPTION = "Simple helloworld application + git"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
SRCREV = "ecf1f0bc87960ef6b6d97c0385b44ce6ea5b2211"
SRC_URI =
"git:///home/genius/yocto-repos/simple-hello-world-git.git;protocol=file;branch=master"
S = "${WORKDIR}/git"
do_compile() {
${CC} simple-hello-world-git.c -o simple-hello-world-git
}
do_install() {
install -d ${D}${bindir}
install -m 0755 simple-hello-world-git ${D}${bindir}
}
---
If I bake the .ipk, copy it over to the target and try to install it
there opkg complains:
opkg install /tmp/simple-hello-world-git_1.0.1-r0_armv7a-vfp-neon.ipk
Installing simple-hello-world-git (1.0.1-r0) on root.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies
for simple-hello-world-git:
* libc6 (>= 2.21) *
* opkg_install_cmd: Cannot install package simple-hello-world-git.
---
If I include the package into my image it works, also if I just copy
over the executable (which is included in the package) it works.
scp
/home/genius/test/yocto-autobuilder/yocto-worker/custom-fido-vexpressa9-qemu-core-image-minimal/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/simple-hello-world-git/1.0.1-r0/git/simple-hello-world-git
root@192.168.7.2:/tmp
/tmp/simple-hello-world-git
Simple Hello world git!
Am I missing something?
I am pretty sure this worked with dizzy.
Regards,
Robert
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] automated hardware testing
Hi, On 2014-07-21 08:35, Stoicescu, CorneliuX wrote: Hello Robert, Sorry for the late reply, I missed this mail. We do have an almost fully automated way of doing what you need. First of all, how do you want to run the automated tests? From the autobuilder as a build step OR from another machine (this will imply publishing the images on a http server). It's fine from the autobuilder as a build step. To give you more info to chew on, what you have to do is http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#performing-automated-runtime-testing . The TEST_TARGET would have to be set to BeagleBoneTarget and other fields like TEST_SERIALCONTROL_CMD will also have to be set. OK, Thanks! I will be out of the office for the next couple of weeks which will give me time to read the "mega manual". What else would someone do on the beach;) I'll certainly keep you updated about how things will go with autobuilder/auto hardware testing. Regards, Corneliu -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] automated hardware testing
Hi, On 2014-07-14 05:46, Paul Eggleton wrote: Absolutely. As a starting point I'd recommend the following section of the manual: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#performing-automated-runtime-testing Thanks! Some of the capabilities in this area were added after 1.6, i.e. they are only in master. I use a pretty recent yocto-autobuilder, but I guess I will need to update poky as well. Right? Cheers, Paul Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to properly add new qemu target + testimage support?
Hi, I hacked together a qemu target which supports vexpress-a9. In order to get core-image-minimal -c testimage to work as well I had to cook meta/lib/oeqa/utils/qemurunner.py scripts/runqemu scripts/runqemu-internal This does not seem to be a generic way to do such a thing. What's the proper way to do it? Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] jethro 2.0.1/ubi-utils not installed on target
Hi, I would like to have ubi-utils, which is part of mtd-utils, installed on my target. It seems to be insufficient to add mtd-utils to a packagegroup[1] and add this to the image for it to be installed in the image. The package is being built and I can install it afterwards e.g. opkg install mtd-utils-ubifs_1.5.1+git0+9f107132a6-r0_armv7a Is it intended to be like this? Regards, Robert [1] https://github.com/RobertBerger/meta-mainline/blob/jethro-training-v4.4.x/multi-v7-ml/recipes-core/packagegroups/packagegroup-tools-fs.bb -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] jethro 2.0.1/ubi-utils not installed on target
On 2016-02-16 05:40, Burton, Ross wrote: Hi, On 16 February 2016 at 09:03, wrote: It seems to be insufficient to add mtd-utils to a packagegroup[1] and add this to the image for it to be installed in the image. The package is being built and I can install it afterwards e.g. opkg install mtd-utils-ubifs_1.5.1+git0+9f107132a6-r0_armv7a Is it intended to be like this? Yes. As you said the resulting package is called mtd-utils-ubifs, so that's the name you need to use in the packagegroup. Thanks. I figured this out in the meantime;) I looked into mtd-utils.bb and the packages built where I found mtd-utils-ubifs, which does not seem a very generic approach. One recipe can result in more than one packages, so -s, --show-versions Show current and preferred versions of all recipes. does not show all packages. bitbake -s | grep mtd core-image-minimal-mtdutils :1.0-r0 mtd-utils :1.5.1+gitAUTOINC+9f107132a6-r0 mtd-utils-native:1.5.1+gitAUTOINC+9f107132a6-r0 mtdev :1.1.5-r0 How can I get a list of all available packages? Maybe there are more hidden secrets;) What I've found so far is[1], but still I don't get the complete list of available packages: bb search-packages mtd Parsing recipes..done. Gathering preferred recipe filenames...done core-image-minimal-mtdutils: Packages: core-image-minimal-mtdutils mtd-utils-native: Packages: mtd-utils-native mtd-utils: Packages: mtd-utils-misc mtd-utils-doc mtd-utils-jffs2 mtd-utils-ubifs mtd-utils-staticdev mtd-utils-dev mtd-utils-locale mtd-utils mtd-utils-dbg mtdev: Packages: mtdev-locale mtdev-dbg mtdev-staticdev mtdev-doc mtdev mtdev-dev [1] https://github.com/kergoth/bb Ross Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] jethro 2.0.1/ubi-utils not installed on target
Hi,
On 2016-02-17 04:07, Paul Eggleton wrote:
Hi Robert,
If you want the complete list of packages you can only get it after a
recipe
has been built, at which time oe-pkgdata-util can be used:
$ oe-pkgdata-util list-pkgs -p mtd-utils
mtd-utils-jffs2
mtd-utils-ubifs
mtd-utils-misc
mtd-utils-dbg
mtd-utils-dev
mtd-utils-doc
mtd-utils
The reason this is only available after building (strictly speaking,
after
do_packagedata has executed for the recipe in question) is that often
the list
of packages isn't determined until then; for example, kernel module
packages
are completely dynamic based on those modules that are enabled.
Cheers,
Paul
Thanks.
So would something I hacked up quickly like this work?
test.sh:
-->
bitbake -s | awk '{ print $1}' > test.txt
tail -n +6 test.txt > test1.txt
while IFS='' read -r line || [[ -n "$line" ]]; do
echo "-->"
echo "oe-pkgdata-util list-pkgs -p $line"
oe-pkgdata-util list-pkgs -p $line 2> /dev/null
echo "<--"
done < test1.txt
<--
./test.sh | grep mtd
oe-pkgdata-util list-pkgs -p core-image-minimal-mtdutils
oe-pkgdata-util list-pkgs -p mtd-utils
mtd-utils-jffs2
mtd-utils-ubifs
mtd-utils-misc
mtd-utils-dbg
mtd-utils-dev
mtd-utils-doc
mtd-utils
oe-pkgdata-util list-pkgs -p mtd-utils-native
oe-pkgdata-util list-pkgs -p mtdev
mtdev-dbg
mtdev-staticdev
mtdev-dev
mtdev
PS if you wish to email me could you please use my email address rather
than
the gmane alias you're currently using.
I'll try. Now I reply with your regular email (hoping gmane will not
scramble it)
Regards,
Robert
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] use yocto toolchain as external toolchain
Hi, It may sound slightly crazy:) but can I use a toolchain, which was created by Poky as an external toolchain for Poky? What I am after is something like this: I create a multiplatfrom v7 compatible Yocto project, which spits out toolchain/rootfs/kernel/various device trees.[1] Now I need to build for each board a custom u-boot, something like [2][3],... Obviously [2] and [3] build again the toolchain. Would it be possible to reuse the toolchain built by [1] like an external toolchain to save some build time? Regards, Robert [1] https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.4.x/multi-v7-ml [2] https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.4.x/beagle-bone-black-multi-v7-ml [3] https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.4.x/zedboard-multi-v7-ml -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] something like kernel configuration fragments for device tree?
Hi, I was wondering if there is something like kernel config fragments also available for device trees from the YP. It would be convenient, since kernel configuration and device tree might be related in some cases. Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Y-AB PublishArtifacts toolchain wrong dir
Hi, I use the latest and greatest yocto autobuilder: f9b4e02730a5e712ee9085e2480f9a3b8b00f56d It looks like Publishing Artifacts tries to find the toolchain instead of build/build/tmp/deploy/sdk (where it is built) here build/build/tmp/deploy/images/toolchain-x86_64 This patch [1] fixes the problem for me. Regards, Robert https://github.com/RobertBerger/autobuilder-patches/blob/master/before-install/0004-PublichArtifacts-searches-toolchain-in-wrong-place.patch -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Y-AB PublishArtifacts toolchain wrong dir
Hi, On 2016-10-07 22:05, Bill Randle wrote: Hi Robert, I see a couple of problems with this proposed patch. First, it's not clear the existing code is broken. Here[1] is a paste of the error. cp: cannot stat '/tmp/yocto-autobuilder/yocto-autobuilder/yocto-worker/res-custom-morty-multi-v7-core-image-minimal-dev-sato-sdk-toolchain/build/build/tmp/deploy/sdk/poky-*i686-core-image*.sh': No such file or directory That's[2] the .conf file which I used. Note that I'm not building a i686 toolchain, but only the 64 bit version. [1] http://pastebin.com/aLyer2fi [2] https://github.com/RobertBerger/meta-mainline/blob/morty-training-v4.4.x/multi-v7-ml/yocto-autobuilder/res-custom-morty-multi-v7-core-image-minimal-dev-sato-sdk-toolchain.conf Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Y-AB PublishArtifacts toolchain wrong dir
Hi, On 2016-10-07 22:05, Bill Randle wrote: Hi Robert, I see a couple of problems with this proposed patch. First, it's not clear the existing code is broken. Try this [1] to see the problem. [1] https://github.com/RobertBerger/meta-mainline/blob/jethro-training-v4.4.x/multi-v7-ml/yocto-autobuilder/custom-jethro-multi-v7-core-image-minimal-sato-sdk-adt.conf Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Y-AB PublishArtifacts toolchain wrong dir
Hi, On 2016-10-08 09:28, Bill Randle wrote: All the "standard" build configs produce both x86 and x86_64 toolchains - which makes sense, since it's not known what build host the user is using and the AB needs to show both are buildable. In your case, you know you have an x86_64 machine and don't want to bother building for x86, so, it's seems like the thing to do is check for the existence of a build package (x86 or x86_64) before attempting the copy. That's what I thought as well at first. So I introduced new toolchain artifacts like toolchain_x86_64 and toolchain_i686 where I did only the relevant thing in the relevant branch. It did not solve my problem. Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Y-AB PublishArtifacts toolchain wrong dir
Hi, On 2016-10-08 18:17, Bill Randle wrote: Hi, I think I would leave the toolchain artifact as is, but just surround the the 'cp' with an 'if' statement. E.g.,: if [ -e ]; then cp ; fi; if [ -e ]; then cp ; fi; This sounds like a brilliant idea. It looks like now I have the behaviour of the good old Y-AB plus md5sums and friends and being copied over. What do you think about this patch? [1] -Bill [1] https://github.com/RobertBerger/autobuilder-patches/blob/master/before-install/0004-deal-only-with-built-toolchains-cp-also-md5-and-mani.patch Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests
From 8f28afbfc21dc84f076b0cc620e578f9607d1465 Mon Sep 17 00:00:00 2001 From: Robert Berger Date: Mon, 10 Oct 2016 06:26:06 + Subject: [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests Signed-off-by: Robert Berger --- .../autobuilder/buildsteps/PublishArtifacts.py | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py index 633600c..46d7b40 100644 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py @@ -154,14 +154,16 @@ class PublishArtifacts(ShellCommand): elif artifact == "toolchain": artifact_name, deploy_image_dir = self.getDeployNames(artifact, buildername) command=command+self.generateMD5cmd(artifact, deploy_image_dir) -command=command+"mkdir -p " + os.path.join(DEST, X86TC_PUBLISH_DIR) + ";" +command=command+"if [ -e " + os.path.join(deploy_image_dir, "poky-*i686-core-image*.sh ") + " ]; then " + \ +"mkdir -p " + os.path.join(DEST, X86TC_PUBLISH_DIR) + "; " command=command+"cp -R --no-dereference --preserve=links " + \ -os.path.join(deploy_image_dir, "poky-*i686-core-image*.sh ") + \ -os.path.join(DEST, X86TC_PUBLISH_DIR) + pipeline + ";" -command=command+"mkdir -p " + os.path.join(DEST, X8664TC_PUBLISH_DIR) + ";" +os.path.join(deploy_image_dir, "poky-*i686-core-image* ") + \ +os.path.join(DEST, X86TC_PUBLISH_DIR) + pipeline + "; fi;" +command=command+"if [ -e " + os.path.join(deploy_image_dir, "poky-*x86_64-core-image*.sh ") + " ]; then " + \ +"mkdir -p " + os.path.join(DEST, X8664TC_PUBLISH_DIR) + "; " command=command+"cp -R --no-dereference --preserve=links " + \ -os.path.join(deploy_image_dir, "poky-*x86_64-core-image*.sh ") + \ -os.path.join(DEST, X8664TC_PUBLISH_DIR) + pipeline + ";" +os.path.join(deploy_image_dir, "poky-*x86_64-core-image* ") + \ +os.path.join(DEST, X8664TC_PUBLISH_DIR) + pipeline + "; fi;" elif artifact == "uninative": artifact_name, deploy_image_dir = self.getDeployNames(artifact, buildername) command=command+self.generateMD5cmd(artifact, deploy_image_dir) -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Y-AB automatic updates?
Hi, With a latest and greatest Yocto Autobuilder I noticed stuff like this when I restart it: --- ... Updating PRSERV remote: Counting objects: 20, done. remote: Compressing objects: 100% (20/20), done. remote: Total 20 (delta 17), reused 0 (delta 0) Unpacking objects: 100% (20/20), done. From git://git.openembedded.org/bitbake 35927a9..d9713ed master -> origin/master 35927a9..d9713ed 1.32 -> origin/1.32 + 21defce...09dd499 master-next -> origin/master-next (forced update) Updating 35927a9..d9713ed Fast-forward bin/bitbake | 2 +- lib/bb/__init__.py | 2 +- lib/bb/ui/depexp.py | 24 3 files changed, 26 insertions(+), 2 deletions(-) --- This pumps e.g. the bitbake version: Author: Richard Purdie Date: Tue Oct 11 08:46:35 2016 +0100 bitbake: Update version to 1.32.0 --- Is this really intentionally and what's the purpose? Say you have a build server for your production software and PRSERV is being (randomly) updated. Due to a bug before or after the update the build output might be different. So you can't reproduce your images any more. Some people (including myself) really would like to have reproduce able builds. Is there a "non hacky" way to turn these updates off? Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Y-AB automatic updates?
Hi, On 2016-10-11 17:39, Joshua Lock wrote: aren't set. If you point PRSERV_HOST and PRSERV_PORT at a non-localhost PRServer the git repo won't be fetched/updated. I use the Y-AB for nightly builds and to populate DL_DIR and friends. It's also not unusual to use this machine as the "master" PRSERV. What you are saying is that if I do so through the ab-prserv script (which I would like to use) it will automatically update PRServer and suggest as a work around to move my PRServer to another machine? I would like to use Y-AB and run the PRServer on it as well - ideally by using the script. So I guess I'll need to hack the ab-prserv script. How can you do QA with the Y-AB in it's "default mode" where it potentially updates the PRServer whenever you restart it? And you need to restart it e.g. to add/modify configuration files. I also can't see any indication which version of the PRServer is being used in the build logs. Regards, Joshua Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests
Hi, On 2016-10-13 16:29, Lock, Joshua G wrote: Can you help me understand why you needed to create this patch? We've run into some issues recently where toolchains we expected to be built weren't and the PublishArtifacts buildstep failing because they're missing is useful. With this change we'll no longer get that, right? Yes that's right (and not intended). I would hope that you'll be able to detect such kind of problems before the PublishArtifacts buildstep because there should be some error in previous steps. The toolchain did not build! I made this patch because I just want to build a 64 bit toolchain as opposed to both (like I used to do with some older version of Y-AB) and don't want the PublishArtifacts step to fail just because there is no 32-bit toolchain. There is no 32 bit toolchain on purpose. As a bonus the patch also copies md5sums and friends over and not just the .sh files. I do not want PublishArtifacts toolchain(s) to find out that something went wrong in previous build steps, but I would want it to copy over whatever was built (and not to fail if something I did not build is missing). As a quick and dirty alternative I would also be happy with a solution based on additional PublishArtifacts steps like: toolchain_i686 for 32 bit only (only the 32 bit toolchain) toolchain_x86_64 for 64 bit only (only the 64 bit toolchain) if that helps. Then in my config file I just use toolchain_x86_64 instead of toolchain in my PublishArtifacts step to indicate that I just want the 64 bit version. To publish both you could use toolchain_i686 and toolchain_x86_64 in the PublishArtifacts step. I find it a bit confusing to write toolchain and to expect various 64 bit and 32 bit toolchains to be published. BTW what happens here[1] if one toolchain does not build? I think even without my patch you'll not be able to detect the problem, since BuildToolchainImages is being called 4 times so two 32 bit and two 64 bit toolchains should be built. You'll just get an error in PublishArtifacts before my patch if no 32 bit or no 64 bit toolchain is being built. Nobody counts how many should be there. So I would say the best would be to count how many toolchains should be built (count BuildToolchainImages in combination with SDKMACHINE) and check if that's the case in PublishArtifacts. No idea if and how this can be done. Thanks, Joshua Regards, Robert [1] http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/buildset-config.controller/nightly-arm.conf - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests
Hi, On 2016-10-14 04:27, Joshua Lock wrote: This is a reasonable goal, but something I'd rather see addressed in the proposed PublishArtifacts rewrite. As we're trying to release morty right now I'd like to avoid changes to the AB behaviour until after the release. I'm absolutely happy with this and eagerly waiting for morty. Please keep me updated so, as my time permits, I can test the new Y-AB version. Regards, Joshua Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using A Proprietary Closed License Inside A Layer & Its Recipes
Hi,
On 2017-06-15 17:52, Thomas A. F. Thorne MEng AUS MIET wrote:
Good afternoon,
I am putting together a meta-company-name layer to hold some internal
code. This will contain a few BSPs for our units, some internally
developed applications and a few config file patches. I am having
trouble getting recipes to be related to the proprietary license.
I am doing something very similar which seems to work:
1) I create a custom-licenses dir in my layer which contains custom
licenses
2) add custom license path to layer.conf:
LICENSE_PATH += " ${LAYERDIR}/custom-licenses"
3) In the recipe I do this:
LICENSE = "hello-license"
LIC_FILES_CHKSUM =
"file://${THISDIR}/../../custom-licenses/hello-license;beginline=5;endline=12;md5=36e6988a930e054886e6af19372edb07"
But I don't think that the beginline,endline makes a difference.
Can you try pointing at ${THISIR}/../../dir is> and see if this makes any difference?
ERROR: recipe-0.1-r0 do_configure: QA Issue: recipe: LIC_FILES_CHKSUM
points to an invalid file:
/home/thomasthorne/work/yocto/build-lib/tmp/work/all-poky-linux/recipe/0.1-r0/companyname
[license-checksum]
Regards,
Robert
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] "external"/"internal" SDK
Hi, A client would like to dish out an SDK to their customers, but only with a subset of header files compared to those they use internally. internal SDK: As it is right now when you build an sdk with e.g. bitbake whatever -c populate_sdk external SDK: everything the same as above, but for some packages there should be only libraries - no header files. I guess I'm not the first one who needs something like this. How would you do something like this the "Yocto way"? Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] etnaviv image
Hi, Great that you managed to get to get open-source graphics on those boards! I would be very interested in the i.mx6 stuff. In roughly a week I'll fly to a board manufacturer to train some of their customers in Yocto/OE and friends. Maybe I can get them to send you some i.mx6 quad board to try there as well? Would you be interested? Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] yocto-bsp: Fix QEMUARM based bsps to not offer SMP support
On 2017-05-31 21:20, Andre McCurdy wrote: Keeping the existing platform but updating the CPU would have the advantage that qemuarm could then share binaries and sstate with real world ARM targets. It would also be a step towards defining an official "generic ARMv7" tuning target within OE, which could be used as the default DEFAULTTUNE for all ARMv7 targets. I would highly appreciate a "generic ARMv7" target! What I usually use on various boards is: *) DEFAULTTUNE = "armv7a-neon" include conf/machine/include/arm/arch-armv7a.inc *) same rootfs binay for all boards *) a kernel starting from a multi_v7_defconfig *) a different device tree for each board *) a different u-boot for each board I even got such a kernel/rootfs to work with the qemu which comes with the Yocto project with some ancient Yocto version by hacking the qemu run script [1][2]. This uses the versatile expressa qemu target and uses a device tree. I did not try, but nowadays runqemu is in Python and something like this should be possible as well. Like this the same binaries could run on qemu and on various boards. [1] https://github.com/RobertBerger/poky/blob/2015-03-20-dizzy%2B/scripts/runqemu [2] https://github.com/RobertBerger/poky/blob/2015-03-20-dizzy%2B/scripts/runqemu-internal -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Layer priorities & package selection
Hi, On 2016-08-04 16:21, Maciej Borzęcki wrote: Another option that I see is to set BBMASK = "meta-ivi/recipes-graphics/wayland/" in local.conf, but that's a bit ugly, hence I'd say it's a temporary solution only. BBMASK does not seem to apply only to local.conf anymore[1], so this might not just be a temporary solution. [1] https://lists.yoctoproject.org/pipermail/poky/2016-January/010358.html Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Antwort: Re: How to set the sysroot toolchain to hard float
Hi, On 2016-08-05 10:24, s.jar...@esa-grimma.de wrote: @TOOLCHAIN_OPTIONS: Where these are set in custom layers(like meta-atmel)? If you ask me I would say here [1]: DEFAULTTUNE = "cortexa5thf" Here [2] are the available HF options: # HF Tunes AVAILTUNES += "cortexa5hf cortexa5thf cortexa5hf-neon cortexa5thf-neon" [1] https://github.com/linux4sam/meta-atmel/blob/master/conf/machine/include/sama5d3.inc [2] http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/tune-cortexa5.inc Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the simplest way to test a new kernel configuration in a Yocto Project?
Hi, On 2016-08-09 07:20, Daniel. wrote: Hi Patrick, If you are running your image embedded at some board, and have easy access to the board, you can plug it to network and make u-boot download kernel from your machine. So that deploy a new kernel becomes simple as copy the new kernel to the tftp folder, and rebooting target. This is also true for device-trees. And if you have NFS support is true for all userspace too. :) To be precise the statically linked kernel + dtb can be loaded by u-boot over tftp (and nfs). The kernel modules are typically part of the rootfs so they would be exported by nfs in our scenario. I usually use symbolic links in my tftp export as well as which nfs rootfs I export so I don't need to change the u-boot environment to boot from something different. Like this it's just a matter of copying things around on your PC and adjusting the symlinks. Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cortex-M4 build support
Hi, Shouldn't it be possible to build a bare-metal Cortex-M4 compiler with the YP and build a small RTOS like FreeRTOS with this compiler? Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Creating a core image with openCV
Hi, I use multi-v7 kernel for the zedboard and create a custom packagegroup which contains openCV[1] which I add to the image. [1] https://github.com/RobertBerger/meta-mainline/blob/jethro-training-v4.4.x/multi-v7-ml/recipes-core/packagegroups/packagegroup-opencv.bb Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Out-of-Tree Modules and __stack_chk_fail()
Hi,
On 2016-09-13 21:55, Ronald Oakes wrote:
Any ideas how to proceed?
1) Can you try to use it from an in-tree kernel module? (modify the
attachment)
2) Can you grep in your kernel config for
CONFIG_CC_STACKPROTECTOR and friends?
Regards,
Robert
>From 69cabc395bd097dde34664b4e1fe1c57ced39f6e Mon Sep 17 00:00:00 2001
From: genius user
Date: Thu, 27 Aug 2015 16:44:46 +
Subject: [PATCH] Yocto kernel module
Signed-off-by: genius user
---
drivers/misc/Kconfig | 5 +
drivers/misc/Makefile| 1 +
drivers/misc/yocto-testmod.c | 38 ++
3 files changed, 44 insertions(+)
create mode 100644 drivers/misc/yocto-testmod.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 006242c..31e90be 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -372,6 +372,11 @@ config HMC6352
This driver provides support for the Honeywell HMC6352 compass,
providing configuration and heading data via sysfs.
+config YOCTO_TESTMOD
+ tristate "Yocto Test Driver"
+ help
+ This driver provides a silly message for testing Yocto.
+
config DS1682
tristate "Dallas DS1682 Total Elapsed Time Recorder with Alarm"
depends on I2C
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7d5c4cd..f6c21ba 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_DS1682) += ds1682.o
obj-$(CONFIG_TI_DAC7512) += ti_dac7512.o
obj-$(CONFIG_C2PORT) += c2port/
obj-$(CONFIG_HMC6352) += hmc6352.o
+obj-$(CONFIG_YOCTO_TESTMOD) += yocto-testmod.o
obj-y+= eeprom/
obj-y+= cb710/
obj-$(CONFIG_SPEAR13XX_PCIE_GADGET) += spear13xx_pcie_gadget.o
diff --git a/drivers/misc/yocto-testmod.c b/drivers/misc/yocto-testmod.c
new file mode 100644
index 000..c643624
--- /dev/null
+++ b/drivers/misc/yocto-testmod.c
@@ -0,0 +1,38 @@
+/*
+ * Copyright 2013 Intel Corporation
+ * Authored-by: Tom Zanussi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include
+
+static int __init yocto_testmod_init(void)
+{
+ printk("Billroy quacked here!");
+
+ return 0;
+}
+
+static void __exit yocto_testmod_exit(void)
+{
+ printk("Billroy did not quack here!");
+}
+
+module_init(yocto_testmod_init);
+module_exit(yocto_testmod_exit);
+
+MODULE_AUTHOR("Tom Zanussi --
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "bitbake virtual/kernel -c menuconfig" seems to be broken
Hi, On 2016-09-27 11:03, s.jar...@esa-grimma.de wrote: Hej Some error occurred. I give a print (sorry for that German text - but the error should be clear): ## GEN ./Makefile HOSTLD scripts/kconfig/mconf scripts/kconfig/mconf.o: In Funktion `show_help': mconf.c:(.text+0x914): Nicht definierter Verweis auf `stdscr' scripts/kconfig/lxdialog/checklist.o: In Funktion `print_arrows': Did you try something like this [1] (I know it is strange) bitbake ncurses -c populate_sysroot -f [1] http://lists.openembedded.org/pipermail/openembedded-core/2015-May/105374.html You might want to post those kind of bugs to bugzilla[2] [2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7609 Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration info - runqemu
Hi Robert, On 2016-10-14 05:12, Robert Yang wrote: QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" ... Could you also please mention which of those values are obligatory and what are the default values in case they are not contained in the config file? Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "external"/"internal" SDK
Hi, On 2017-01-18 04:54, Joshua Watt wrote: external SDK: everything the same as above, but for some packages there should be only libraries - no header files. Is there a reason why you want the libraries without the headers? It doesn't seem particularly useful to be able to link a program against a library, but not have the header to use its API (especially in an SDK, where the point is to build program against the libraries). I think they are worried about revealing their "internal" API since they don't want their customers to access it directly. As an alternative, there might be a way to completely exclude those particular packages from the external SDK instead of removing the header files (see below)? I'll try to clarify this with them. ... Hopefully it will at least give a place to start. Certainly. This gives me some more ideas how other people would do it. Thanks! Joshua Watt -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Task dependencies
Hi, On 2017-04-13 11:24, Gary Thomas wrote: On 2017-04-13 09:34, Gary Thomas wrote: I'm trying to understand why 'perl' is being built for my target even though I don't mention it in any of the package recipes used to build that target. When I used 'taskexp', I found that 'perl:do_build' only has a single dependent task, namely 'my-image:do_build' note: no perl packages end up in my image. This is just one example where it seems bitbake is doing a lot of unnecessary (certainly un-asked-for) work. How can I unravel this mystery? Thanks for any pointers Did you have a look at the dependency explorer? bitbake -g -u depexp core-image-sato-sdk There you see also reverse dependencies (who depends e.g. on perl) Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
