Re: [yocto] [meta-ti] Building for AM335x with meta-ti and meta-qt5
On Wed, Jul 24, 2019 at 05:53:36PM +, Andy Pont wrote: > I am trying to build a Yocto (warrior) image for the AM335x using meta-ti > and meta-qt5 that will render directly to the GPU. Initially this will be > for the Beaglebone Black but then ultimately will be for a custom hardware > platform. > > In broad outline, I think, the software stack needs to look a bit like: > > Qt Application > QtBase, QtWebEngine, etc. > Qt-OpenGL > ti-sgx-ddk > AM335x GPU > > I have included meta-ti and meta-qt5 into my belayers.conf and added > ti-sgx-ddk-km, ti-sgx-ddk-um, qtbase and qtwebengine to > IMAGE_INSTALL_append. When I try to bitbake core-image-minimal I start to > get a failure to compile ti-sgx-ddk-km with a number of, what appear to be, > warnings of the form: > > KBUILD_EXTRA_SYMBOLS= > | grep: > /home/me/Yocto/BeagleBoneBlack/tmp/work-shared/beaglebone/kernel-source/include/linux/amba: > Is a directory > | grep: > /home/me/Yocto/BeagleBoneBlack/tmp/work-shared/beaglebone/kernel-source/include/linux/avf: > Is a directory > > It then ultimately appears to give up with: > > | *** Multiarch build: no > | *** Primary arch:target_armel > | *** Secondary arch: none > | ../config/core.mk:513: $(KERNELDIR)/vmlinux does not exist. Kbuild may > fail. > | eurasiacon/build/linux2/toplevel.mk:230: > eurasiacon/build/linux2/moduledefs/target_armel.mk: No such file or > directory > > Is there a specific kernel I need to define in local.conf that the GPU > drivers build against? > > Also, is there any specific configuration I need to do in order to get Qt to > use the SGX OpenGL drivers? What's your DISTRO, your MACHINE, TUNES and any other special configs? > I have had a search on the web but not found anything for recent Yocto > versions, only very old stuff. It's been working fine for years, hence no recent discussions. You may want to look into TI Processor SDK for AM335x - it's Yocto Project based Arago distro that is configured for Qt5-Wayland/Weston-SGX, but has been also tested with EGLFS QPA. -- Denys -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti layer failed with Daisy
Hi Satya, > I am building the core-image-minimal for Daisy with meta-ti layer included in > bblayers.conf file after removing meta-yocto-bsp layer. I am getting the > error shown below, This is a very old version. Please update to one of the latest supported releases. > [Satya]~/Yocto-Daisy-Labs/poky/build > bitbake core-image-minimal > Loading cache: 100% > |#| > ETA: 00:00:00 > Loaded 1446 entries from dependency cache. > ERROR: No recipes available for: > /home/satya/Yocto-Daisy-Labs/poky/meta-ti/recipes-core/udev/eudev_%.bbappend > ERROR: Command execution failed: Exited with 1 This generally means that the bb file that this is an append for, wasn't found in any of the layers. Thanks, Anuj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On Tue, Jun 9, 2015 at 9:34 PM, Brian Hutchinson wrote: > On Tue, Jun 9, 2015 at 9:14 PM, Bruce Ashfield > wrote: >> On 2015-06-09 9:12 PM, Brian Hutchinson wrote: >>> >>> On Tue, May 19, 2015 at 12:42 PM, Brian Hutchinson >>> wrote: On Tue, May 19, 2015 at 12:31 PM, Bruce Ashfield wrote: > > On 2015-05-19 07:39 AM, Bruce Ashfield wrote: >> >> >> On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson >> >> wrote: >>> >>> >>> On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson >>> >>> wrote: On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson wrote: > > > On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson > wrote: >> >> >> >> On May 14, 2015 6:08 PM, "Denys Dmytriyenko" >> wrote: >>> >>> >>> >>> On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: On 2015-05-12 10:20 AM, Brian Hutchinson wrote: > > > On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield > wrote: >> >> >> On 2015-05-11 02:10 PM, Brian Hutchinson wrote: >>> >>> >>> >>> On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield >>> wrote: It is plausible. But in theory, linux-dummy should still provide what you need (but since it doesn't build anything, there is no abi .. and no modules can be built against it) .. so the error isn't graceful. Bruce >>> >>> >>> >>> >>> I can confirm this same problem is happening to me. I just >>> updated >>> one of my builds from 1.7 to 1.8 and am also getting my rootfs >>> to >>> fail >>> due to no abi kernel version: >> >> >> >> >> We still have a race condition in the 1.8 branch for the >> population >> of the build-artifacts directory. >> >> If modules start building, they'll race against the population >> of >> the >> abiversion, and you may see that message. >> >> There's a proposed patch for master, but I don't think it is in >> fido yet. >> >> Bruce > > > > Hi Bruce, > > I did some searches and looks like there are a number of 'race' > condition fixes but it wasn't obvious which one I may need. Is > it > this one: >> >> >> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 > > > That's the one that should make sure that the shared workdir (Which has the abiversion) is in place before building any modules. I can't say that it is exactly your issue, but it is the change I was thinking of. >>> >>> >>> >>> Brian, >>> >>> Were you able to try the above mentioned commit against am180x in >>> meta-ti? >>> Did >>> it solve the missing abi kernel version? Thanks. >>> >>> -- >>> Denys >> >> >> >> Hi Denys, >> >> No, I got caught up in something else ... I'll try it tomorrow and >> report >> back after I cherry pick that commit Bruce mentioned. >> >> Regards, >> >> Brian > > > > Update. Not sure if I did this right but this is what I did. I > added > master as a remote and cherry picked > 02d0a003d603266114512160b209876199241e98. Next I just went for it > and > tried to bitbake my image again and got the same result as before. > Next I did a bitbake cleanall on virtual/kernel and tried to make my > image again and still got the same result. > > I'm going to leave this build as is and setup a new one using 1.8 > master and see if I get the same thing again. I'll leave this > broken > build alone for a while in case someone wants me to try something > with > it to fix it. > > Regards, > > Brian Yet another update ... I did a fresh checkout of master and tried to build and had the same
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On Tue, Jun 9, 2015 at 9:14 PM, Bruce Ashfield wrote: > On 2015-06-09 9:12 PM, Brian Hutchinson wrote: >> >> On Tue, May 19, 2015 at 12:42 PM, Brian Hutchinson >> wrote: >>> >>> On Tue, May 19, 2015 at 12:31 PM, Bruce Ashfield >>> wrote: On 2015-05-19 07:39 AM, Bruce Ashfield wrote: > > > On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson > > wrote: >> >> >> On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson >> >> wrote: >>> >>> >>> On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson >>> >>> wrote: On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson wrote: > > > > On May 14, 2015 6:08 PM, "Denys Dmytriyenko" > wrote: >> >> >> >> On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: >>> >>> >>> On 2015-05-12 10:20 AM, Brian Hutchinson wrote: On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield wrote: > > > On 2015-05-11 02:10 PM, Brian Hutchinson wrote: >> >> >> >> On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield >> wrote: >>> >>> >>> >>> It is plausible. But in theory, linux-dummy should still >>> provide >>> what you need (but since it doesn't build anything, there is >>> no abi .. and no modules can be built against it) .. so the >>> error isn't graceful. >>> >>> Bruce >> >> >> >> >> I can confirm this same problem is happening to me. I just >> updated >> one of my builds from 1.7 to 1.8 and am also getting my rootfs >> to >> fail >> due to no abi kernel version: > > > > > We still have a race condition in the 1.8 branch for the > population > of the build-artifacts directory. > > If modules start building, they'll race against the population > of > the > abiversion, and you may see that message. > > There's a proposed patch for master, but I don't think it is in > fido yet. > > Bruce Hi Bruce, I did some searches and looks like there are a number of 'race' condition fixes but it wasn't obvious which one I may need. Is it this one: >>> >>> >>> > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 >>> >>> That's the one that should make sure that the shared workdir >>> (Which has the abiversion) is in place before building any >>> modules. >>> >>> I can't say that it is exactly your issue, but it is the change >>> I was thinking of. >> >> >> >> Brian, >> >> Were you able to try the above mentioned commit against am180x in >> meta-ti? >> Did >> it solve the missing abi kernel version? Thanks. >> >> -- >> Denys > > > > Hi Denys, > > No, I got caught up in something else ... I'll try it tomorrow and > report > back after I cherry pick that commit Bruce mentioned. > > Regards, > > Brian Update. Not sure if I did this right but this is what I did. I added master as a remote and cherry picked 02d0a003d603266114512160b209876199241e98. Next I just went for it and tried to bitbake my image again and got the same result as before. Next I did a bitbake cleanall on virtual/kernel and tried to make my image again and still got the same result. I'm going to leave this build as is and setup a new one using 1.8 master and see if I get the same thing again. I'll leave this broken build alone for a while in case someone wants me to try something with it to fix it. Regards, Brian >>> >>> >>> >>> Yet another update ... I did a fresh checkout of master and tried to >>> build and had the same kernelabiversion error: >>> >>> WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for >>> now### >>> | ETA: >>>
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On 2015-06-09 9:12 PM, Brian Hutchinson wrote: On Tue, May 19, 2015 at 12:42 PM, Brian Hutchinson wrote: On Tue, May 19, 2015 at 12:31 PM, Bruce Ashfield wrote: On 2015-05-19 07:39 AM, Bruce Ashfield wrote: On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson wrote: On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson wrote: On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson wrote: On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson wrote: On May 14, 2015 6:08 PM, "Denys Dmytriyenko" wrote: On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: On 2015-05-12 10:20 AM, Brian Hutchinson wrote: On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield wrote: On 2015-05-11 02:10 PM, Brian Hutchinson wrote: On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield wrote: It is plausible. But in theory, linux-dummy should still provide what you need (but since it doesn't build anything, there is no abi .. and no modules can be built against it) .. so the error isn't graceful. Bruce I can confirm this same problem is happening to me. I just updated one of my builds from 1.7 to 1.8 and am also getting my rootfs to fail due to no abi kernel version: We still have a race condition in the 1.8 branch for the population of the build-artifacts directory. If modules start building, they'll race against the population of the abiversion, and you may see that message. There's a proposed patch for master, but I don't think it is in fido yet. Bruce Hi Bruce, I did some searches and looks like there are a number of 'race' condition fixes but it wasn't obvious which one I may need. Is it this one: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 That's the one that should make sure that the shared workdir (Which has the abiversion) is in place before building any modules. I can't say that it is exactly your issue, but it is the change I was thinking of. Brian, Were you able to try the above mentioned commit against am180x in meta-ti? Did it solve the missing abi kernel version? Thanks. -- Denys Hi Denys, No, I got caught up in something else ... I'll try it tomorrow and report back after I cherry pick that commit Bruce mentioned. Regards, Brian Update. Not sure if I did this right but this is what I did. I added master as a remote and cherry picked 02d0a003d603266114512160b209876199241e98. Next I just went for it and tried to bitbake my image again and got the same result as before. Next I did a bitbake cleanall on virtual/kernel and tried to make my image again and still got the same result. I'm going to leave this build as is and setup a new one using 1.8 master and see if I get the same thing again. I'll leave this broken build alone for a while in case someone wants me to try something with it to fix it. Regards, Brian Yet another update ... I did a fresh checkout of master and tried to build and had the same kernelabiversion error: WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for now### | ETA: 00:00:28 WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for now | ETA: 00:00:26 Parsing recipes: 100% |##| Time: 00:01:02 Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303 targets, 182 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies NOTE: multiple providers are available for u-boot (u-boot, u-boot-glsdk, u-boot-ti-staging) NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo) NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg Build Configuration: BB_VERSION= "1.27.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Debian-7.8" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "am180x-evm" DISTRO= "poky" DISTRO_VERSION= "1.8+snapshot-20150515" TUNE_FEATURES = "arm armv5 thumb dsp" TARGET_FPU= "soft" meta meta-yocto meta-yocto-bsp= "master:fab7da4f8030a4067db0522f77eaa6d3b501c68f" meta-ti = "master:60a7bfbf96609ef6f3e084c32b2af853222b3b7e" meta-oe meta-python meta-networking meta-webserver= "master:53d55216c8c721d3b66ec8f968737bf081def870" NOTE: Preparing RunQueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: QA Issue: /usr/bin/apxs_apache2-dev contained in package apache2-dev requires /usr/bin/perl, but no providers found in its RDEPENDS [file-rdeps] ERROR: No kernel-abiversion file found (/home/hutch/yocto_1.8_davinci_2/poky/build/tmp/sysroots/am180x-evm/pkgdata/kernel-depmod/kernel-
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On Tue, May 19, 2015 at 12:42 PM, Brian Hutchinson wrote: > On Tue, May 19, 2015 at 12:31 PM, Bruce Ashfield > wrote: >> On 2015-05-19 07:39 AM, Bruce Ashfield wrote: >>> >>> On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson >>> wrote: On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson wrote: > > On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson > wrote: >> >> On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson >> wrote: >>> >>> >>> On May 14, 2015 6:08 PM, "Denys Dmytriyenko" wrote: On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: > > On 2015-05-12 10:20 AM, Brian Hutchinson wrote: >> >> On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield >> wrote: >>> >>> On 2015-05-11 02:10 PM, Brian Hutchinson wrote: On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield wrote: > > > It is plausible. But in theory, linux-dummy should still provide > what you need (but since it doesn't build anything, there is > no abi .. and no modules can be built against it) .. so the > error isn't graceful. > > Bruce I can confirm this same problem is happening to me. I just updated one of my builds from 1.7 to 1.8 and am also getting my rootfs to fail due to no abi kernel version: >>> >>> >>> >>> We still have a race condition in the 1.8 branch for the >>> population >>> of the build-artifacts directory. >>> >>> If modules start building, they'll race against the population of >>> the >>> abiversion, and you may see that message. >>> >>> There's a proposed patch for master, but I don't think it is in >>> fido yet. >>> >>> Bruce >> >> >> Hi Bruce, >> >> I did some searches and looks like there are a number of 'race' >> condition fixes but it wasn't obvious which one I may need. Is it >> this one: > > >>> >>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 >> >> > > That's the one that should make sure that the shared workdir > (Which has the abiversion) is in place before building any modules. > > I can't say that it is exactly your issue, but it is the change > I was thinking of. Brian, Were you able to try the above mentioned commit against am180x in meta-ti? Did it solve the missing abi kernel version? Thanks. -- Denys >>> >>> >>> Hi Denys, >>> >>> No, I got caught up in something else ... I'll try it tomorrow and >>> report >>> back after I cherry pick that commit Bruce mentioned. >>> >>> Regards, >>> >>> Brian >> >> >> Update. Not sure if I did this right but this is what I did. I added >> master as a remote and cherry picked >> 02d0a003d603266114512160b209876199241e98. Next I just went for it and >> tried to bitbake my image again and got the same result as before. >> Next I did a bitbake cleanall on virtual/kernel and tried to make my >> image again and still got the same result. >> >> I'm going to leave this build as is and setup a new one using 1.8 >> master and see if I get the same thing again. I'll leave this broken >> build alone for a while in case someone wants me to try something with >> it to fix it. >> >> Regards, >> >> Brian > > > Yet another update ... I did a fresh checkout of master and tried to > build and had the same kernelabiversion error: > > WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for > now### >| ETA: > 00:00:28 > WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now > WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for > now > > | ETA: 00:00:26 > Parsing recipes: 100% > > |##| > Time: 00:01:02 > Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303 > targets, 182 skipped, 0 masked, 0 errors. > NOTE: Resolving any missing task queue dependencies > NOTE: multiple providers are available for u-boot (u-boot, > u-boot-glsdk, u-boot-ti-staging) > NOTE: c
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On Tue, May 19, 2015 at 12:31 PM, Bruce Ashfield wrote: > On 2015-05-19 07:39 AM, Bruce Ashfield wrote: >> >> On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson >> wrote: >>> >>> On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson >>> wrote: On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson wrote: > > On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson > wrote: >> >> >> On May 14, 2015 6:08 PM, "Denys Dmytriyenko" wrote: >>> >>> >>> On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: On 2015-05-12 10:20 AM, Brian Hutchinson wrote: > > On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield > wrote: >> >> On 2015-05-11 02:10 PM, Brian Hutchinson wrote: >>> >>> >>> On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield >>> wrote: It is plausible. But in theory, linux-dummy should still provide what you need (but since it doesn't build anything, there is no abi .. and no modules can be built against it) .. so the error isn't graceful. Bruce >>> >>> >>> >>> I can confirm this same problem is happening to me. I just >>> updated >>> one of my builds from 1.7 to 1.8 and am also getting my rootfs to >>> fail >>> due to no abi kernel version: >> >> >> >> We still have a race condition in the 1.8 branch for the >> population >> of the build-artifacts directory. >> >> If modules start building, they'll race against the population of >> the >> abiversion, and you may see that message. >> >> There's a proposed patch for master, but I don't think it is in >> fido yet. >> >> Bruce > > > Hi Bruce, > > I did some searches and looks like there are a number of 'race' > condition fixes but it wasn't obvious which one I may need. Is it > this one: >> >> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 > > That's the one that should make sure that the shared workdir (Which has the abiversion) is in place before building any modules. I can't say that it is exactly your issue, but it is the change I was thinking of. >>> >>> >>> Brian, >>> >>> Were you able to try the above mentioned commit against am180x in >>> meta-ti? >>> Did >>> it solve the missing abi kernel version? Thanks. >>> >>> -- >>> Denys >> >> >> Hi Denys, >> >> No, I got caught up in something else ... I'll try it tomorrow and >> report >> back after I cherry pick that commit Bruce mentioned. >> >> Regards, >> >> Brian > > > Update. Not sure if I did this right but this is what I did. I added > master as a remote and cherry picked > 02d0a003d603266114512160b209876199241e98. Next I just went for it and > tried to bitbake my image again and got the same result as before. > Next I did a bitbake cleanall on virtual/kernel and tried to make my > image again and still got the same result. > > I'm going to leave this build as is and setup a new one using 1.8 > master and see if I get the same thing again. I'll leave this broken > build alone for a while in case someone wants me to try something with > it to fix it. > > Regards, > > Brian Yet another update ... I did a fresh checkout of master and tried to build and had the same kernelabiversion error: WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for now### | ETA: 00:00:28 WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for now | ETA: 00:00:26 Parsing recipes: 100% |##| Time: 00:01:02 Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303 targets, 182 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies NOTE: multiple providers are available for u-boot (u-boot, u-boot-glsdk, u-boot-ti-staging) NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo) NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg >
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On 2015-05-19 07:39 AM, Bruce Ashfield wrote: On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson wrote: On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson wrote: On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson wrote: On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson wrote: On May 14, 2015 6:08 PM, "Denys Dmytriyenko" wrote: On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: On 2015-05-12 10:20 AM, Brian Hutchinson wrote: On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield wrote: On 2015-05-11 02:10 PM, Brian Hutchinson wrote: On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield wrote: It is plausible. But in theory, linux-dummy should still provide what you need (but since it doesn't build anything, there is no abi .. and no modules can be built against it) .. so the error isn't graceful. Bruce I can confirm this same problem is happening to me. I just updated one of my builds from 1.7 to 1.8 and am also getting my rootfs to fail due to no abi kernel version: We still have a race condition in the 1.8 branch for the population of the build-artifacts directory. If modules start building, they'll race against the population of the abiversion, and you may see that message. There's a proposed patch for master, but I don't think it is in fido yet. Bruce Hi Bruce, I did some searches and looks like there are a number of 'race' condition fixes but it wasn't obvious which one I may need. Is it this one: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 That's the one that should make sure that the shared workdir (Which has the abiversion) is in place before building any modules. I can't say that it is exactly your issue, but it is the change I was thinking of. Brian, Were you able to try the above mentioned commit against am180x in meta-ti? Did it solve the missing abi kernel version? Thanks. -- Denys Hi Denys, No, I got caught up in something else ... I'll try it tomorrow and report back after I cherry pick that commit Bruce mentioned. Regards, Brian Update. Not sure if I did this right but this is what I did. I added master as a remote and cherry picked 02d0a003d603266114512160b209876199241e98. Next I just went for it and tried to bitbake my image again and got the same result as before. Next I did a bitbake cleanall on virtual/kernel and tried to make my image again and still got the same result. I'm going to leave this build as is and setup a new one using 1.8 master and see if I get the same thing again. I'll leave this broken build alone for a while in case someone wants me to try something with it to fix it. Regards, Brian Yet another update ... I did a fresh checkout of master and tried to build and had the same kernelabiversion error: WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for now### | ETA: 00:00:28 WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for now | ETA: 00:00:26 Parsing recipes: 100% |##| Time: 00:01:02 Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303 targets, 182 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies NOTE: multiple providers are available for u-boot (u-boot, u-boot-glsdk, u-boot-ti-staging) NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo) NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg Build Configuration: BB_VERSION= "1.27.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Debian-7.8" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "am180x-evm" DISTRO= "poky" DISTRO_VERSION= "1.8+snapshot-20150515" TUNE_FEATURES = "arm armv5 thumb dsp" TARGET_FPU= "soft" meta meta-yocto meta-yocto-bsp= "master:fab7da4f8030a4067db0522f77eaa6d3b501c68f" meta-ti = "master:60a7bfbf96609ef6f3e084c32b2af853222b3b7e" meta-oe meta-python meta-networking meta-webserver= "master:53d55216c8c721d3b66ec8f968737bf081def870" NOTE: Preparing RunQueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: QA Issue: /usr/bin/apxs_apache2-dev contained in package apache2-dev requires /usr/bin/perl, but no providers found in its RDEPENDS [file-rdeps] ERROR: No kernel-abiversion file found (/home/hutch/yocto_1.8_davinci_2/poky/build/tmp/sysroots/am180x-evm/pkgdata/kernel-depmod/kernel-abiversion), cannot run depmod, aborting ERROR: Function failed: do_rootfs ERROR: Logfile of failure stored in: /home/hutch/yocto_1.8_davinci_2/poky/build/tmp/work/am180x_evm-poky-linux-gnuea
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson wrote: > On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson > wrote: >> On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson >> wrote: >>> On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson >>> wrote: On May 14, 2015 6:08 PM, "Denys Dmytriyenko" wrote: > > On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: > > On 2015-05-12 10:20 AM, Brian Hutchinson wrote: > > >On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield > > > wrote: > > >>On 2015-05-11 02:10 PM, Brian Hutchinson wrote: > > >>> > > >>>On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield > > >>> wrote: > > > > It is plausible. But in theory, linux-dummy should still provide > > what you need (but since it doesn't build anything, there is > > no abi .. and no modules can be built against it) .. so the > > error isn't graceful. > > > > Bruce > > >>> > > >>> > > >>>I can confirm this same problem is happening to me. I just updated > > >>>one of my builds from 1.7 to 1.8 and am also getting my rootfs to > > >>> fail > > >>>due to no abi kernel version: > > >> > > >> > > >>We still have a race condition in the 1.8 branch for the population > > >>of the build-artifacts directory. > > >> > > >>If modules start building, they'll race against the population of the > > >>abiversion, and you may see that message. > > >> > > >>There's a proposed patch for master, but I don't think it is in > > >>fido yet. > > >> > > >>Bruce > > > > > >Hi Bruce, > > > > > >I did some searches and looks like there are a number of 'race' > > >condition fixes but it wasn't obvious which one I may need. Is it > > >this one: > > > > > >http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 > > > > > > > That's the one that should make sure that the shared workdir > > (Which has the abiversion) is in place before building any modules. > > > > I can't say that it is exactly your issue, but it is the change > > I was thinking of. > > Brian, > > Were you able to try the above mentioned commit against am180x in meta-ti? > Did > it solve the missing abi kernel version? Thanks. > > -- > Denys Hi Denys, No, I got caught up in something else ... I'll try it tomorrow and report back after I cherry pick that commit Bruce mentioned. Regards, Brian >>> >>> Update. Not sure if I did this right but this is what I did. I added >>> master as a remote and cherry picked >>> 02d0a003d603266114512160b209876199241e98. Next I just went for it and >>> tried to bitbake my image again and got the same result as before. >>> Next I did a bitbake cleanall on virtual/kernel and tried to make my >>> image again and still got the same result. >>> >>> I'm going to leave this build as is and setup a new one using 1.8 >>> master and see if I get the same thing again. I'll leave this broken >>> build alone for a while in case someone wants me to try something with >>> it to fix it. >>> >>> Regards, >>> >>> Brian >> >> Yet another update ... I did a fresh checkout of master and tried to >> build and had the same kernelabiversion error: >> >> WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for >> now### >> | ETA: >> 00:00:28 >> WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now >> WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for >> now >> >> | ETA: 00:00:26 >> Parsing recipes: 100% >> |##| >> Time: 00:01:02 >> Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303 >> targets, 182 skipped, 0 masked, 0 errors. >> NOTE: Resolving any missing task queue dependencies >> NOTE: multiple providers are available for u-boot (u-boot, >> u-boot-glsdk, u-boot-ti-staging) >> NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot >> NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo) >> NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg >> >> Build Configuration: >> BB_VERSION= "1.27.0" >> BUILD_SYS = "x86_64-linux" >> NATIVELSBSTRING = "Debian-7.8" >> TARGET_SYS= "arm-poky-linux-gnueabi" >> MACHINE = "am180x-evm" >> DISTRO= "poky" >> DISTRO_VERSION= "1.8+snapshot-20150515" >> TUNE_FEATURES = "arm armv5 thumb dsp" >> TARGET_FPU= "soft" >> meta >> meta-yocto >> meta-yocto-bsp= "master:fab7da4f8030a4067db0522f77eaa6d3b501c68f" >> meta-ti = "master:60a7bfbf96609ef
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson wrote: > On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson > wrote: >> On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson >> wrote: >>> >>> On May 14, 2015 6:08 PM, "Denys Dmytriyenko" wrote: On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: > On 2015-05-12 10:20 AM, Brian Hutchinson wrote: > >On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield > > wrote: > >>On 2015-05-11 02:10 PM, Brian Hutchinson wrote: > >>> > >>>On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield > >>> wrote: > > It is plausible. But in theory, linux-dummy should still provide > what you need (but since it doesn't build anything, there is > no abi .. and no modules can be built against it) .. so the > error isn't graceful. > > Bruce > >>> > >>> > >>>I can confirm this same problem is happening to me. I just updated > >>>one of my builds from 1.7 to 1.8 and am also getting my rootfs to > >>> fail > >>>due to no abi kernel version: > >> > >> > >>We still have a race condition in the 1.8 branch for the population > >>of the build-artifacts directory. > >> > >>If modules start building, they'll race against the population of the > >>abiversion, and you may see that message. > >> > >>There's a proposed patch for master, but I don't think it is in > >>fido yet. > >> > >>Bruce > > > >Hi Bruce, > > > >I did some searches and looks like there are a number of 'race' > >condition fixes but it wasn't obvious which one I may need. Is it > >this one: > > > >http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 > > > > That's the one that should make sure that the shared workdir > (Which has the abiversion) is in place before building any modules. > > I can't say that it is exactly your issue, but it is the change > I was thinking of. Brian, Were you able to try the above mentioned commit against am180x in meta-ti? Did it solve the missing abi kernel version? Thanks. -- Denys >>> >>> Hi Denys, >>> >>> No, I got caught up in something else ... I'll try it tomorrow and report >>> back after I cherry pick that commit Bruce mentioned. >>> >>> Regards, >>> >>> Brian >> >> Update. Not sure if I did this right but this is what I did. I added >> master as a remote and cherry picked >> 02d0a003d603266114512160b209876199241e98. Next I just went for it and >> tried to bitbake my image again and got the same result as before. >> Next I did a bitbake cleanall on virtual/kernel and tried to make my >> image again and still got the same result. >> >> I'm going to leave this build as is and setup a new one using 1.8 >> master and see if I get the same thing again. I'll leave this broken >> build alone for a while in case someone wants me to try something with >> it to fix it. >> >> Regards, >> >> Brian > > Yet another update ... I did a fresh checkout of master and tried to > build and had the same kernelabiversion error: > > WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for > now### > | ETA: > 00:00:28 > WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now > WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for > now > > | ETA: 00:00:26 > Parsing recipes: 100% > |##| > Time: 00:01:02 > Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303 > targets, 182 skipped, 0 masked, 0 errors. > NOTE: Resolving any missing task queue dependencies > NOTE: multiple providers are available for u-boot (u-boot, > u-boot-glsdk, u-boot-ti-staging) > NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot > NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo) > NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg > > Build Configuration: > BB_VERSION= "1.27.0" > BUILD_SYS = "x86_64-linux" > NATIVELSBSTRING = "Debian-7.8" > TARGET_SYS= "arm-poky-linux-gnueabi" > MACHINE = "am180x-evm" > DISTRO= "poky" > DISTRO_VERSION= "1.8+snapshot-20150515" > TUNE_FEATURES = "arm armv5 thumb dsp" > TARGET_FPU= "soft" > meta > meta-yocto > meta-yocto-bsp= "master:fab7da4f8030a4067db0522f77eaa6d3b501c68f" > meta-ti = "master:60a7bfbf96609ef6f3e084c32b2af853222b3b7e" > meta-oe > meta-python > meta-networking > meta-webserver= "master:53d55216c8c721d3b66ec8f968737bf081def870" > > NOTE: Preparing RunQueue > NOTE: Executing Set
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson wrote: > On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson > wrote: >> >> On May 14, 2015 6:08 PM, "Denys Dmytriyenko" wrote: >>> >>> On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: >>> > On 2015-05-12 10:20 AM, Brian Hutchinson wrote: >>> > >On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield >>> > > wrote: >>> > >>On 2015-05-11 02:10 PM, Brian Hutchinson wrote: >>> > >>> >>> > >>>On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield >>> > >>> wrote: >>> > >>> > It is plausible. But in theory, linux-dummy should still provide >>> > what you need (but since it doesn't build anything, there is >>> > no abi .. and no modules can be built against it) .. so the >>> > error isn't graceful. >>> > >>> > Bruce >>> > >>> >>> > >>> >>> > >>>I can confirm this same problem is happening to me. I just updated >>> > >>>one of my builds from 1.7 to 1.8 and am also getting my rootfs to >>> > >>> fail >>> > >>>due to no abi kernel version: >>> > >> >>> > >> >>> > >>We still have a race condition in the 1.8 branch for the population >>> > >>of the build-artifacts directory. >>> > >> >>> > >>If modules start building, they'll race against the population of the >>> > >>abiversion, and you may see that message. >>> > >> >>> > >>There's a proposed patch for master, but I don't think it is in >>> > >>fido yet. >>> > >> >>> > >>Bruce >>> > > >>> > >Hi Bruce, >>> > > >>> > >I did some searches and looks like there are a number of 'race' >>> > >condition fixes but it wasn't obvious which one I may need. Is it >>> > >this one: >>> > >>> > > >http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 >>> > > >>> > >>> > That's the one that should make sure that the shared workdir >>> > (Which has the abiversion) is in place before building any modules. >>> > >>> > I can't say that it is exactly your issue, but it is the change >>> > I was thinking of. >>> >>> Brian, >>> >>> Were you able to try the above mentioned commit against am180x in meta-ti? >>> Did >>> it solve the missing abi kernel version? Thanks. >>> >>> -- >>> Denys >> >> Hi Denys, >> >> No, I got caught up in something else ... I'll try it tomorrow and report >> back after I cherry pick that commit Bruce mentioned. >> >> Regards, >> >> Brian > > Update. Not sure if I did this right but this is what I did. I added > master as a remote and cherry picked > 02d0a003d603266114512160b209876199241e98. Next I just went for it and > tried to bitbake my image again and got the same result as before. > Next I did a bitbake cleanall on virtual/kernel and tried to make my > image again and still got the same result. > > I'm going to leave this build as is and setup a new one using 1.8 > master and see if I get the same thing again. I'll leave this broken > build alone for a while in case someone wants me to try something with > it to fix it. > > Regards, > > Brian Yet another update ... I did a fresh checkout of master and tried to build and had the same kernelabiversion error: WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for now### | ETA: 00:00:28 WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for now | ETA: 00:00:26 Parsing recipes: 100% |##| Time: 00:01:02 Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303 targets, 182 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies NOTE: multiple providers are available for u-boot (u-boot, u-boot-glsdk, u-boot-ti-staging) NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo) NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg Build Configuration: BB_VERSION= "1.27.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Debian-7.8" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "am180x-evm" DISTRO= "poky" DISTRO_VERSION= "1.8+snapshot-20150515" TUNE_FEATURES = "arm armv5 thumb dsp" TARGET_FPU= "soft" meta meta-yocto meta-yocto-bsp= "master:fab7da4f8030a4067db0522f77eaa6d3b501c68f" meta-ti = "master:60a7bfbf96609ef6f3e084c32b2af853222b3b7e" meta-oe meta-python meta-networking meta-webserver= "master:53d55216c8c721d3b66ec8f968737bf081def870" NOTE: Preparing RunQueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: QA Issue: /usr/bin/apxs_apache2-dev contained in package apache2-dev requires /usr/bin/perl, but no providers found in its RDEPENDS [file-rdeps] ERROR: No kernel-abiversion file found (
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson wrote: > > On May 14, 2015 6:08 PM, "Denys Dmytriyenko" wrote: >> >> On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: >> > On 2015-05-12 10:20 AM, Brian Hutchinson wrote: >> > >On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield >> > > wrote: >> > >>On 2015-05-11 02:10 PM, Brian Hutchinson wrote: >> > >>> >> > >>>On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield >> > >>> wrote: >> > >> > It is plausible. But in theory, linux-dummy should still provide >> > what you need (but since it doesn't build anything, there is >> > no abi .. and no modules can be built against it) .. so the >> > error isn't graceful. >> > >> > Bruce >> > >>> >> > >>> >> > >>>I can confirm this same problem is happening to me. I just updated >> > >>>one of my builds from 1.7 to 1.8 and am also getting my rootfs to >> > >>> fail >> > >>>due to no abi kernel version: >> > >> >> > >> >> > >>We still have a race condition in the 1.8 branch for the population >> > >>of the build-artifacts directory. >> > >> >> > >>If modules start building, they'll race against the population of the >> > >>abiversion, and you may see that message. >> > >> >> > >>There's a proposed patch for master, but I don't think it is in >> > >>fido yet. >> > >> >> > >>Bruce >> > > >> > >Hi Bruce, >> > > >> > >I did some searches and looks like there are a number of 'race' >> > >condition fixes but it wasn't obvious which one I may need. Is it >> > >this one: >> > >> > > >http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 >> > > >> > >> > That's the one that should make sure that the shared workdir >> > (Which has the abiversion) is in place before building any modules. >> > >> > I can't say that it is exactly your issue, but it is the change >> > I was thinking of. >> >> Brian, >> >> Were you able to try the above mentioned commit against am180x in meta-ti? >> Did >> it solve the missing abi kernel version? Thanks. >> >> -- >> Denys > > Hi Denys, > > No, I got caught up in something else ... I'll try it tomorrow and report > back after I cherry pick that commit Bruce mentioned. > > Regards, > > Brian Update. Not sure if I did this right but this is what I did. I added master as a remote and cherry picked 02d0a003d603266114512160b209876199241e98. Next I just went for it and tried to bitbake my image again and got the same result as before. Next I did a bitbake cleanall on virtual/kernel and tried to make my image again and still got the same result. I'm going to leave this build as is and setup a new one using 1.8 master and see if I get the same thing again. I'll leave this broken build alone for a while in case someone wants me to try something with it to fix it. Regards, Brian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: > On 2015-05-12 10:20 AM, Brian Hutchinson wrote: > >On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield > > wrote: > >>On 2015-05-11 02:10 PM, Brian Hutchinson wrote: > >>> > >>>On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield > >>> wrote: > > It is plausible. But in theory, linux-dummy should still provide > what you need (but since it doesn't build anything, there is > no abi .. and no modules can be built against it) .. so the > error isn't graceful. > > Bruce > >>> > >>> > >>>I can confirm this same problem is happening to me. I just updated > >>>one of my builds from 1.7 to 1.8 and am also getting my rootfs to fail > >>>due to no abi kernel version: > >> > >> > >>We still have a race condition in the 1.8 branch for the population > >>of the build-artifacts directory. > >> > >>If modules start building, they'll race against the population of the > >>abiversion, and you may see that message. > >> > >>There's a proposed patch for master, but I don't think it is in > >>fido yet. > >> > >>Bruce > > > >Hi Bruce, > > > >I did some searches and looks like there are a number of 'race' > >condition fixes but it wasn't obvious which one I may need. Is it > >this one: > >http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 > > > > That's the one that should make sure that the shared workdir > (Which has the abiversion) is in place before building any modules. > > I can't say that it is exactly your issue, but it is the change > I was thinking of. Brian, Were you able to try the above mentioned commit against am180x in meta-ti? Did it solve the missing abi kernel version? Thanks. -- Denys -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On May 14, 2015 6:08 PM, "Denys Dmytriyenko" wrote: > > On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: > > On 2015-05-12 10:20 AM, Brian Hutchinson wrote: > > >On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield > > > wrote: > > >>On 2015-05-11 02:10 PM, Brian Hutchinson wrote: > > >>> > > >>>On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield > > >>> wrote: > > > > It is plausible. But in theory, linux-dummy should still provide > > what you need (but since it doesn't build anything, there is > > no abi .. and no modules can be built against it) .. so the > > error isn't graceful. > > > > Bruce > > >>> > > >>> > > >>>I can confirm this same problem is happening to me. I just updated > > >>>one of my builds from 1.7 to 1.8 and am also getting my rootfs to fail > > >>>due to no abi kernel version: > > >> > > >> > > >>We still have a race condition in the 1.8 branch for the population > > >>of the build-artifacts directory. > > >> > > >>If modules start building, they'll race against the population of the > > >>abiversion, and you may see that message. > > >> > > >>There's a proposed patch for master, but I don't think it is in > > >>fido yet. > > >> > > >>Bruce > > > > > >Hi Bruce, > > > > > >I did some searches and looks like there are a number of 'race' > > >condition fixes but it wasn't obvious which one I may need. Is it > > >this one: > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 > > > > > > > That's the one that should make sure that the shared workdir > > (Which has the abiversion) is in place before building any modules. > > > > I can't say that it is exactly your issue, but it is the change > > I was thinking of. > > Brian, > > Were you able to try the above mentioned commit against am180x in meta-ti? Did > it solve the missing abi kernel version? Thanks. > > -- > Denys Hi Denys, No, I got caught up in something else ... I'll try it tomorrow and report back after I cherry pick that commit Bruce mentioned. Regards, Brian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Device Tree Overlays
On Mon, Feb 24, 2014 at 5:34 AM, Raul Rosetto Munoz wrote: > I couldnt see this folders: > > root@beaglebone:/lib/fir > an > mware# export SLOTS=/sys/devices/bone_capemgr.9/slots > can you use the kernel from meta-beagleboard and check if you get cape support ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Wifi Module + udev configs
Denys, Thanks for all Reply,
I understand that if I use udev at version 178 or more, I probable will get
a udev with solved firmware problems, however if I use this udev version I
will need to use a systemd packages.
Is possible you give some intructions how to put systemd and udev 178+ at
my build system?
There are another brach that this configuration work?
Thanks For all Help.
2013/2/25 Denys Dmytriyenko
> On Mon, Feb 18, 2013 at 08:56:06AM -0300, Raul Rosetto Munoz wrote:
> > Any suggestions?
> >
> > I really do not know what to do, the file "/lib/udev/firmware" never
> appear.
>
> FYI, starting with 176, udev handles loading firmware images internally,
> hence
> dropping the /lib/udev/firmware binary. But there were some bugs related to
> that functionality, which got fixed in version 178...
>
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=ChangeLog;hb=HEAD
> http://upstream-tracker.org/changelogs/libudev/181/changelog.html
>
> As I said before, if you are using Danny branch, then you should stick to
> the
> proven udev-164 that is in oe-core, unless you really want to have
> systemd, in
> which case you look into meta-openembedded...
>
> --
> Denys
>
>
> > 2013/2/14 Raul Rosetto Munoz
> >
> > > Now Im with 173 from meta-fsl bbapend, but I tryed with many others
> from
> > > meta-oe and poky.
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2013/2/14 Denys Dmytriyenko
> > >
> > >> On Thu, Feb 14, 2013 at 02:23:14PM -0200, Raul Rosetto Munoz wrote:
> > >> > Denys,
> > >> > There are something strange,
> > >> >
> > >> > First there are no linux-firmware-{rtl8192cu,rtl8192ce,rtl8192su}
> > >> > installed at rfs.
> > >>
> > >> I was talking about packages, looks like you have them already
> installed.
> > >>
> > >>
> > >> > raul@phi04:.../tmp/deploy/images$ find
> > >> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/ -name
> "*8192*"
> > >> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/RTL8192E
> > >> >
> > >>
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192sefw.bin
> > >> >
> > >>
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192defw.bin
> > >> >
> > >> > Another problem is that "/lib/udev/firmware" are not installed to.
> > >> >
> > >> > raul@phi04:.../tmp/deploy/images$ find
> > >> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/udev/ -name
> "*firmware*"
> > >> > raul@phi04:.../tmp/deploy/images$
> > >>
> > >> What is your udev version?
> > >>
> > >>
> > >> > But I can see theses files at my "tmp/sysroots/beaglebone"
> > >> >
> > >> > raul@phi04:.../tmp/sysroots/beaglebone$ find lib/firmware/ -name
> > >> "*8192*"
> > >> > lib/firmware/RTL8192E
> > >> > lib/firmware/rtlwifi/rtl8192sefw.bin
> > >> > lib/firmware/rtlwifi/rtl8192defw.bin
> > >> > lib/firmware/rtlwifi/rtl8192cfw.bin
> > >> > lib/firmware/rtlwifi/rtl8192cufw.bin
> > >> >
> > >> > raul@phi04:.../tmp/sysroots/beaglebone$ find lib/udev/ -name
> > >> "*firmware*"
> > >> > lib/udev/firmware
> > >> > lib/udev/rules.d/50-firmware.rules
> > >> >
> > >> > I tryed copy this files for the sdcard but doesnt work.
> > >> >
> > >> > Do you have any suggest?
> > >> >
> > >> > Thanks for all help.
> > >>
> > >
> > >
> > >
> > > --
> > > *Raul Rosetto Muñoz*
> > >
> >
> >
> >
> > --
> > *Raul Rosetto Muñoz*
>
> > ___
> > meta-ti mailing list
> > meta...@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-ti
>
>
--
*Raul Rosetto Muñoz*
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Wifi Module + udev configs
On Mon, Feb 18, 2013 at 08:56:06AM -0300, Raul Rosetto Munoz wrote:
> Any suggestions?
>
> I really do not know what to do, the file "/lib/udev/firmware" never appear.
FYI, starting with 176, udev handles loading firmware images internally, hence
dropping the /lib/udev/firmware binary. But there were some bugs related to
that functionality, which got fixed in version 178...
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=ChangeLog;hb=HEAD
http://upstream-tracker.org/changelogs/libudev/181/changelog.html
As I said before, if you are using Danny branch, then you should stick to the
proven udev-164 that is in oe-core, unless you really want to have systemd, in
which case you look into meta-openembedded...
--
Denys
> 2013/2/14 Raul Rosetto Munoz
>
> > Now Im with 173 from meta-fsl bbapend, but I tryed with many others from
> > meta-oe and poky.
> >
> >
> >
> >
> >
> >
> > 2013/2/14 Denys Dmytriyenko
> >
> >> On Thu, Feb 14, 2013 at 02:23:14PM -0200, Raul Rosetto Munoz wrote:
> >> > Denys,
> >> > There are something strange,
> >> >
> >> > First there are no linux-firmware-{rtl8192cu,rtl8192ce,rtl8192su}
> >> > installed at rfs.
> >>
> >> I was talking about packages, looks like you have them already installed.
> >>
> >>
> >> > raul@phi04:.../tmp/deploy/images$ find
> >> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/ -name "*8192*"
> >> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/RTL8192E
> >> >
> >> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192sefw.bin
> >> >
> >> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192defw.bin
> >> >
> >> > Another problem is that "/lib/udev/firmware" are not installed to.
> >> >
> >> > raul@phi04:.../tmp/deploy/images$ find
> >> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/udev/ -name "*firmware*"
> >> > raul@phi04:.../tmp/deploy/images$
> >>
> >> What is your udev version?
> >>
> >>
> >> > But I can see theses files at my "tmp/sysroots/beaglebone"
> >> >
> >> > raul@phi04:.../tmp/sysroots/beaglebone$ find lib/firmware/ -name
> >> "*8192*"
> >> > lib/firmware/RTL8192E
> >> > lib/firmware/rtlwifi/rtl8192sefw.bin
> >> > lib/firmware/rtlwifi/rtl8192defw.bin
> >> > lib/firmware/rtlwifi/rtl8192cfw.bin
> >> > lib/firmware/rtlwifi/rtl8192cufw.bin
> >> >
> >> > raul@phi04:.../tmp/sysroots/beaglebone$ find lib/udev/ -name
> >> "*firmware*"
> >> > lib/udev/firmware
> >> > lib/udev/rules.d/50-firmware.rules
> >> >
> >> > I tryed copy this files for the sdcard but doesnt work.
> >> >
> >> > Do you have any suggest?
> >> >
> >> > Thanks for all help.
> >>
> >
> >
> >
> > --
> > *Raul Rosetto Muñoz*
> >
>
>
>
> --
> *Raul Rosetto Muñoz*
> ___
> meta-ti mailing list
> meta...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Wifi Module + udev configs
Any suggestions?
I really do not know what to do, the file "/lib/udev/firmware" never appear.
Thank you.
2013/2/14 Raul Rosetto Munoz
> Now Im with 173 from meta-fsl bbapend, but I tryed with many others from
> meta-oe and poky.
>
>
>
>
>
>
> 2013/2/14 Denys Dmytriyenko
>
>> On Thu, Feb 14, 2013 at 02:23:14PM -0200, Raul Rosetto Munoz wrote:
>> > Denys,
>> > There are something strange,
>> >
>> > First there are no linux-firmware-{rtl8192cu,rtl8192ce,rtl8192su}
>> > installed at rfs.
>>
>> I was talking about packages, looks like you have them already installed.
>>
>>
>> > raul@phi04:.../tmp/deploy/images$ find
>> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/ -name "*8192*"
>> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/RTL8192E
>> >
>> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192sefw.bin
>> >
>> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192defw.bin
>> >
>> > Another problem is that "/lib/udev/firmware" are not installed to.
>> >
>> > raul@phi04:.../tmp/deploy/images$ find
>> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/udev/ -name "*firmware*"
>> > raul@phi04:.../tmp/deploy/images$
>>
>> What is your udev version?
>>
>>
>> > But I can see theses files at my "tmp/sysroots/beaglebone"
>> >
>> > raul@phi04:.../tmp/sysroots/beaglebone$ find lib/firmware/ -name
>> "*8192*"
>> > lib/firmware/RTL8192E
>> > lib/firmware/rtlwifi/rtl8192sefw.bin
>> > lib/firmware/rtlwifi/rtl8192defw.bin
>> > lib/firmware/rtlwifi/rtl8192cfw.bin
>> > lib/firmware/rtlwifi/rtl8192cufw.bin
>> >
>> > raul@phi04:.../tmp/sysroots/beaglebone$ find lib/udev/ -name
>> "*firmware*"
>> > lib/udev/firmware
>> > lib/udev/rules.d/50-firmware.rules
>> >
>> > I tryed copy this files for the sdcard but doesnt work.
>> >
>> > Do you have any suggest?
>> >
>> > Thanks for all help.
>>
>
>
>
> --
> *Raul Rosetto Muñoz*
>
--
*Raul Rosetto Muñoz*
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Wifi Module + udev configs
Now Im with 173 from meta-fsl bbapend, but I tryed with many others from
meta-oe and poky.
2013/2/14 Denys Dmytriyenko
> On Thu, Feb 14, 2013 at 02:23:14PM -0200, Raul Rosetto Munoz wrote:
> > Denys,
> > There are something strange,
> >
> > First there are no linux-firmware-{rtl8192cu,rtl8192ce,rtl8192su}
> > installed at rfs.
>
> I was talking about packages, looks like you have them already installed.
>
>
> > raul@phi04:.../tmp/deploy/images$ find
> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/ -name "*8192*"
> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/RTL8192E
> >
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192sefw.bin
> >
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192defw.bin
> >
> > Another problem is that "/lib/udev/firmware" are not installed to.
> >
> > raul@phi04:.../tmp/deploy/images$ find
> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/udev/ -name "*firmware*"
> > raul@phi04:.../tmp/deploy/images$
>
> What is your udev version?
>
>
> > But I can see theses files at my "tmp/sysroots/beaglebone"
> >
> > raul@phi04:.../tmp/sysroots/beaglebone$ find lib/firmware/ -name
> "*8192*"
> > lib/firmware/RTL8192E
> > lib/firmware/rtlwifi/rtl8192sefw.bin
> > lib/firmware/rtlwifi/rtl8192defw.bin
> > lib/firmware/rtlwifi/rtl8192cfw.bin
> > lib/firmware/rtlwifi/rtl8192cufw.bin
> >
> > raul@phi04:.../tmp/sysroots/beaglebone$ find lib/udev/ -name
> "*firmware*"
> > lib/udev/firmware
> > lib/udev/rules.d/50-firmware.rules
> >
> > I tryed copy this files for the sdcard but doesnt work.
> >
> > Do you have any suggest?
> >
> > Thanks for all help.
>
--
*Raul Rosetto Muñoz*
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Wifi Module + udev configs
On Thu, Feb 14, 2013 at 02:23:14PM -0200, Raul Rosetto Munoz wrote:
> Denys,
> There are something strange,
>
> First there are no linux-firmware-{rtl8192cu,rtl8192ce,rtl8192su}
> installed at rfs.
I was talking about packages, looks like you have them already installed.
> raul@phi04:.../tmp/deploy/images$ find
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/ -name "*8192*"
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/RTL8192E
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192sefw.bin
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192defw.bin
>
> Another problem is that "/lib/udev/firmware" are not installed to.
>
> raul@phi04:.../tmp/deploy/images$ find
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/udev/ -name "*firmware*"
> raul@phi04:.../tmp/deploy/images$
What is your udev version?
> But I can see theses files at my "tmp/sysroots/beaglebone"
>
> raul@phi04:.../tmp/sysroots/beaglebone$ find lib/firmware/ -name "*8192*"
> lib/firmware/RTL8192E
> lib/firmware/rtlwifi/rtl8192sefw.bin
> lib/firmware/rtlwifi/rtl8192defw.bin
> lib/firmware/rtlwifi/rtl8192cfw.bin
> lib/firmware/rtlwifi/rtl8192cufw.bin
>
> raul@phi04:.../tmp/sysroots/beaglebone$ find lib/udev/ -name "*firmware*"
> lib/udev/firmware
> lib/udev/rules.d/50-firmware.rules
>
> I tryed copy this files for the sdcard but doesnt work.
>
> Do you have any suggest?
>
> Thanks for all help.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Wifi Module + udev configs
Denys,
There are something strange,
First there are no linux-firmware-{rtl8192cu,rtl8192ce,rtl8192su}
installed at rfs.
raul@phi04:.../tmp/deploy/images$ find
/media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/ -name "*8192*"
/media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/RTL8192E
/media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192sefw.bin
/media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192defw.bin
Another problem is that "/lib/udev/firmware" are not installed to.
raul@phi04:.../tmp/deploy/images$ find
/media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/udev/ -name "*firmware*"
raul@phi04:.../tmp/deploy/images$
But I can see theses files at my "tmp/sysroots/beaglebone"
raul@phi04:.../tmp/sysroots/beaglebone$ find lib/firmware/ -name "*8192*"
lib/firmware/RTL8192E
lib/firmware/rtlwifi/rtl8192sefw.bin
lib/firmware/rtlwifi/rtl8192defw.bin
lib/firmware/rtlwifi/rtl8192cfw.bin
lib/firmware/rtlwifi/rtl8192cufw.bin
raul@phi04:.../tmp/sysroots/beaglebone$ find lib/udev/ -name "*firmware*"
lib/udev/firmware
lib/udev/rules.d/50-firmware.rules
I tryed copy this files for the sdcard but doesnt work.
Do you have any suggest?
Thanks for all help.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Wifi Module + udev configs
There's /lib/udev/firmware which is a firmware loading helper.
The actual firmware files go into /lib/firmware/ directory.
Please make sure you have the correct packages installed with firmware for
your WiFi - linux-firmware-{rtl8192cu,rtl8192ce,rtl8192su}
--
Denys
On Thu, Feb 14, 2013 at 09:17:43AM -0200, Raul Rosetto Munoz wrote:
> Yes I install this package,
> But I think that the problem is that the binary firmware at "/lib/udev"
> doesn't come with the build.
>
> Some one know how to build the binary firmware at "/lib/udev" responsible
> to record the firmware in wifi dongle and enable the udev rules for this
> action.
>
> Thanks for all Help
>
>
> 2013/2/12 Denys Dmytriyenko
>
> > On Thu, Feb 07, 2013 at 06:26:46PM -0200, Raul Rosetto Munoz wrote:
> > > Hello All,
> > > I need to configure my yocto project to work with wifi dongle realteck
> > > rtl8192cu.
> > >
> > > My first problem is that the module does not go up automatically
> > rtl8192cu
> > > different than Angstron distro that when I plug the dongle all modules
> > rise.
> > >
> > > Another important difference is that on Angstron distro I have on
> > /lib/udev
> > > the "firmware" binary file. I really was not able to install this
> > > functionality in udev.
> >
> > Have you looked at linux-firmware package? rtl8192* should be well
> > supported.
> >
> >
> > > And How to make this firmware binary go to /lib/udev?
> >
> > By default, firmware files go into /lib/firmware
> >
> > --
> > Denys
> >
>
>
>
> --
> *Raul Rosetto Mu?oz*
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Wifi Module + udev configs
Yes I install this package, But I think that the problem is that the binary firmware at "/lib/udev" doesn't come with the build. Some one know how to build the binary firmware at "/lib/udev" responsible to record the firmware in wifi dongle and enable the udev rules for this action. Thanks for all Help 2013/2/12 Denys Dmytriyenko > On Thu, Feb 07, 2013 at 06:26:46PM -0200, Raul Rosetto Munoz wrote: > > Hello All, > > I need to configure my yocto project to work with wifi dongle realteck > > rtl8192cu. > > > > My first problem is that the module does not go up automatically > rtl8192cu > > different than Angstron distro that when I plug the dongle all modules > rise. > > > > Another important difference is that on Angstron distro I have on > /lib/udev > > the "firmware" binary file. I really was not able to install this > > functionality in udev. > > Have you looked at linux-firmware package? rtl8192* should be well > supported. > > > > And How to make this firmware binary go to /lib/udev? > > By default, firmware files go into /lib/firmware > > -- > Denys > -- *Raul Rosetto Muñoz* ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] Wifi Module + udev configs
On Thu, Feb 07, 2013 at 06:26:46PM -0200, Raul Rosetto Munoz wrote: > Hello All, > I need to configure my yocto project to work with wifi dongle realteck > rtl8192cu. > > My first problem is that the module does not go up automatically rtl8192cu > different than Angstron distro that when I plug the dongle all modules rise. > > Another important difference is that on Angstron distro I have on /lib/udev > the "firmware" binary file. I really was not able to install this > functionality in udev. Have you looked at linux-firmware package? rtl8192* should be well supported. > And How to make this firmware binary go to /lib/udev? By default, firmware files go into /lib/firmware -- Denys ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] build failure with xf86-video-omap
On Thu, Nov 22, 2012 at 12:26:12AM +0100, Nicolas Dechesne wrote: > looping rob clark (upstream author) > > > On Thu, Nov 22, 2012 at 12:07 AM, Burton, Ross wrote: > > > On 21 November 2012 22:52, Nicolas Dechesne wrote: > > > since xf86-video-omap was recently merged in oe-core and poky, i am > > trying > > > to remove the recipes we had staged in meta-ti trees for some weeks > > > ( > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=410dc026f2ee24a2346e7563a83f0181c79809cf > > ). > > > so i was trying to build poky/master with meta-ti/master, for > > pandaboard, > > > and I get build failures in xf86-video-omap [1] and [2]. > > > > > > so [1] is actually trivial, as we are missing a DEPENDS in the recipe, i > > can > > > send a patch in oe-core for that. > > > > Please do. > > > > sure, will do. > > > > > > [2] is a bit more cryptic to me.. so I quickly tried to build with danny > > ( i > > > just cherry picked the commit that introduced xf86-video-omap from > > master) > > > and this time it built fine. > > > > > > has anyone actually tested this recipe? if so I must be doing something > > > wrong, any hint would be helpful. > > > > This was discussed a few hours ago. It's caused by a) the > > configure.ac being broken and b) the workaround for this being removed > > by me in e828faf027540bc5def8b7371a959884caad9557 (which is in master > > only). Presumably this code was test built before that patch landed. > > > > As this is a genuine upstream bug (ARM-specific driver that doesn't > > cross-compile?!) I've just filed fdo #57386. > > > > i suspect you opened a OE bug, since I can't find it in yocto BZ, however > bugs.openembedded.org doesn't seem to answer at the moment.. AFAIK, OE bugzilla was deprecated some time ago. We were considering taking it down, as a matter of fact. OE-Core issues are logged into Yocto bugzilla. Not sure where Ross filed this one though. > so, I checked our configure.ac , and clearly, that needs some love... > > Rob: any chance you can look into that? it's the xf86-video-omap > configure.ac file that's wrong, we should mimic what's in the > xf-video-intel one i guess.. otherwise i can try later this week. -- Denys ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] meta-gumstix proceedings
On Mon, Oct 08, 2012 at 12:18:24PM +0100, Paul Eggleton wrote: > Hi Andreas, > > On Monday 08 October 2012 12:54:46 Andreas Müller wrote: > > as some of you might know, gumstix created an official BSP layer > > [1][2]. To avoid confusion I renamed my layer from meta-gumstix to > > meta-gumstix-community [3]. Users should either switch to the official > > meta-gumstix layer or rename meta-gumstix to meta-gumstix-community > > [3] in git configuration (users of angstrom-setup-scripts should also > > change the name in layers.txt). > > So what should we do with the layer index [4]? Do we list both? What is the > delta between them, and is there a hope that there will be only one layer at > some point? Paul, FYI, http://thread.gmane.org/gmane.linux.distributions.gumstix.general/65109/focus=65131 -- Denys ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] [HOB] issue
Hello Tim, Please fill in a bug report at bugzilla.yoctoproject.org It will be investigated later on. Regards, Cristian Iorga -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Tim Verstraete Sent: Wednesday, August 01, 2012 9:29 AM To: Denys Dmytriyenko Cc: meta...@yoctoproject.org; yocto@yoctoproject.org Subject: Re: [yocto] [meta-ti] [HOB] issue Hi, When i use the HOB functionality in yocto with the meta-ti, I get an error message after about 5% with no error message in it. I can only press close. I use the default layers but I do see that HOB re-arranges them into: Poky/meta Poky/meta-hob Poky/meta-ti Poky/meta-yocto I see that I can build using the command line so it has to be something with HOB and not necessary something in yocto. Thanks in advance, Kind regards, Tim -Original Message- From: Denys Dmytriyenko [mailto:de...@ti.com] Sent: dinsdag 31 juli 2012 22:11 To: Tim Verstraete Cc: meta...@yoctoproject.org Subject: Re: [meta-ti] [HOB] issue On Tue, Jul 31, 2012 at 12:04:37PM +, Tim Verstraete wrote: > Hi, > > When i use the HOB functionality in yocto with the meta-ti, I get an > error message after about 5% with no error message in it. I can only press > close. > > I use the default layers but I do see that HOB re-arranges them into: > Poky/meta > Poky/meta-hob > Poky/meta-ti > Poky/meta-yocto > > I see that I can build using the command line so it has to be > something with HOB and not necessary something in yocto. Well, HOB _is_ part of Yocto anyway. While meta-ti may be triggering the issue in HOB, you better off reporting it to the main yocto mailing list - feel free to copy meta-ti as well. -- Denys ___ 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] [meta-ti] [HOB] issue
Hi, When i use the HOB functionality in yocto with the meta-ti, I get an error message after about 5% with no error message in it. I can only press close. I use the default layers but I do see that HOB re-arranges them into: Poky/meta Poky/meta-hob Poky/meta-ti Poky/meta-yocto I see that I can build using the command line so it has to be something with HOB and not necessary something in yocto. Thanks in advance, Kind regards, Tim -Original Message- From: Denys Dmytriyenko [mailto:de...@ti.com] Sent: dinsdag 31 juli 2012 22:11 To: Tim Verstraete Cc: meta...@yoctoproject.org Subject: Re: [meta-ti] [HOB] issue On Tue, Jul 31, 2012 at 12:04:37PM +, Tim Verstraete wrote: > Hi, > > When i use the HOB functionality in yocto with the meta-ti, I get an > error message after about 5% with no error message in it. I can only press > close. > > I use the default layers but I do see that HOB re-arranges them into: > Poky/meta > Poky/meta-hob > Poky/meta-ti > Poky/meta-yocto > > I see that I can build using the command line so it has to be > something with HOB and not necessary something in yocto. Well, HOB _is_ part of Yocto anyway. While meta-ti may be triggering the issue in HOB, you better off reporting it to the main yocto mailing list - feel free to copy meta-ti as well. -- Denys ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti layer and tag 2012.05-yocto1.2
On 2012-05-18 04:36, Enric Balletbò i Serra wrote: Hi Jack 2012/5/18 Jack Mitchell: On 18/05/12 08:48, Enric Balletbò i Serra wrote: Hi all, Just to be sure, should the tag 2012.05-yocto1.2 from meta-ti layer be compatible with yocto-1.2 (denzil) branch ? Or also depends on other layers. Adding only the meta-ti layer to the yocto 1.2 seems is not working, there is an unmet dependency on systemd.bbclass. yocto-1.2$ bitbake core-image-minimal ERROR: ParseError at /home/eballetbo/Workspace/poky/yocto-1.2/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not inherit file classes/systemd.bbclass ERROR: Command execution failed: Exited with 1 Cheers, Enric ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Hi Enric, to quote Denys from a patch to meta-ti earlier: README: by popular demand add comment on how to avoid systemd breakage Signed-off-by: Denys Dmytriyenko --- README |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/README b/README index b376695..0df391f 100644 --- a/README +++ b/README @@ -11,6 +11,12 @@ layers: meta branch: master +When not depending on meta-openembedded and not using systemd, you may need to +mask few miscellaneous recipes requiring systemd, by adding this to local.conf: + +BBMASK = "meta-ti/recipes-misc" + + The base BSP part of meta-ti should work with different OpenEmbedded/Yocto distributions and layer stacks, such as: distro-less (only with OE-Core), with Yocto/Poky, with Angstrom or Arago. Thanks, that works. I'm a bit confusing because the README of meta-ti layer says that this layer can only work with OE-core/Yocto but not sure that anyone has tested. For example bitbaking ti-dsplink recipe results on | make[1]: /arm-poky-linux-gnueabi-gcc: Command not found The problem seems that a lot of meta-ti recipes uses the TOOLCHAIN_PATH variable that is not defined in OE-core/Yocto or I'm wrong?. This don't look difficult to solve but are more surprises waiting for me after solve this ? Someone has tried this layer with only OE-core/Yocto ? Yes, I have used it this way, however I'm using the master/tip, not the mentioned tag. I just built ti-dsplink using meta = "master:38da655788361e949d605bebfab45cf5830df613" meta-ti = "master:fa87ca0b1a1890d262a591aee50f082194f45317" -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti layer and tag 2012.05-yocto1.2
Hi Jack 2012/5/18 Jack Mitchell : > On 18/05/12 08:48, Enric Balletbò i Serra wrote: >> >> Hi all, >> >> Just to be sure, should the tag 2012.05-yocto1.2 from meta-ti layer be >> compatible with yocto-1.2 (denzil) branch ? Or also depends on other >> layers. Adding only the meta-ti layer to the yocto 1.2 seems is not >> working, there is an unmet dependency on systemd.bbclass. >> >> yocto-1.2$ bitbake core-image-minimal >> ERROR: ParseError at >> >> /home/eballetbo/Workspace/poky/yocto-1.2/meta-ti/recipes-misc/payload/bonescript.bb:5: >> Could not inherit file classes/systemd.bbclass >> ERROR: Command execution failed: Exited with 1 >> >> Cheers, >> Enric >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > > Hi Enric, to quote Denys from a patch to meta-ti earlier: > > README: by popular demand add comment on how to avoid systemd breakage > > Signed-off-by: Denys Dmytriyenko > > --- > > README | 6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/README b/README > index b376695..0df391f 100644 > --- a/README > +++ b/README > @@ -11,6 +11,12 @@ layers: meta > branch: master > > > +When not depending on meta-openembedded and not using systemd, you may need > to > +mask few miscellaneous recipes requiring systemd, by adding this to > local.conf: > + > +BBMASK = "meta-ti/recipes-misc" > + > + > The base BSP part of meta-ti should work with different OpenEmbedded/Yocto > distributions and layer stacks, such as: > distro-less (only with OE-Core), with Yocto/Poky, with Angstrom or Arago. > Thanks, that works. I'm a bit confusing because the README of meta-ti layer says that this layer can only work with OE-core/Yocto but not sure that anyone has tested. For example bitbaking ti-dsplink recipe results on | make[1]: /arm-poky-linux-gnueabi-gcc: Command not found The problem seems that a lot of meta-ti recipes uses the TOOLCHAIN_PATH variable that is not defined in OE-core/Yocto or I'm wrong?. This don't look difficult to solve but are more surprises waiting for me after solve this ? Someone has tried this layer with only OE-core/Yocto ? Thanks, Enric > > Regards, > > -- > > Jack Mitchell (j...@embed.me.uk) > Embedded Systems Engineer > http://www.embed.me.uk > > -- > > ___ > 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] meta-ti layer and tag 2012.05-yocto1.2
On 18/05/12 08:48, Enric Balletbò i Serra wrote: Hi all, Just to be sure, should the tag 2012.05-yocto1.2 from meta-ti layer be compatible with yocto-1.2 (denzil) branch ? Or also depends on other layers. Adding only the meta-ti layer to the yocto 1.2 seems is not working, there is an unmet dependency on systemd.bbclass. yocto-1.2$ bitbake core-image-minimal ERROR: ParseError at /home/eballetbo/Workspace/poky/yocto-1.2/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not inherit file classes/systemd.bbclass ERROR: Command execution failed: Exited with 1 Cheers, Enric ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Hi Enric, to quote Denys from a patch to meta-ti earlier: README: by popular demand add comment on how to avoid systemd breakage Signed-off-by: Denys Dmytriyenko --- README |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/README b/README index b376695..0df391f 100644 --- a/README +++ b/README @@ -11,6 +11,12 @@ layers: meta branch: master +When not depending on meta-openembedded and not using systemd, you may need to +mask few miscellaneous recipes requiring systemd, by adding this to local.conf: + +BBMASK = "meta-ti/recipes-misc" + + The base BSP part of meta-ti should work with different OpenEmbedded/Yocto distributions and layer stacks, such as: distro-less (only with OE-Core), with Yocto/Poky, with Angstrom or Arago. Regards, -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] bitbake ti-syslink fails for MACHINE=c6a816x
Oops, hit return too quick on auto completion of email address ... this was meant for meta-ti list! Please forgive me and sorry for the noise. Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] bitbake ti-syslink fails for MACHINE=c6a816x
On Fri, Feb 24, 2012 at 4:07 PM, Monk, Roger wrote: > I don't think it is worth spending too much time debugging this, since this > version of syslink is pretty old now and there will likely be further issues > in this environment even if we can can get th build to complete, since there > are other related dependencies. Best would be to look at adding the version > >= those versions that are used in DVSDK 5.03. This is planned, but we don't > have a schedule at the moment. If you have some time to help integrate these > newer components it would be a big help. > > Thanks, > ~roger I just need to get syslink and sysbios going on C6A816x & L138. We bitbake our rootfs image from Angstrom at the moment. Can you advise the best way to get syslink/sysbios going on these two targets? Our build machines a Linux based. Should I be using the versions that are packaged inside the ezsdk .bin file? I can also help integrating but I might need some direction to get started. Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On 12-01-04 12:15 AM, Khem Raj wrote: On (23/12/11 12:59), Bruce Ashfield wrote: On 11-12-23 12:52 PM, Koen Kooi wrote: Op 23 dec. 2011, om 18:45 heeft Bruce Ashfield het volgende geschreven: On 11-12-23 12:38 PM, Philip Balister wrote: On 12/23/2011 12:10 PM, Bruce Ashfield wrote: On 11-12-23 08:10 AM, James Abernathy wrote: On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: On Friday 23 December 2011 09:28:31 Koen Kooi wrote: Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: I know the examples in the documentation of Yocto use meta-intel a lot to get the board specific BSPs like meta-crownbay or meta-n450. Is there a meta-ti or similar that gets you the meta-beagleboard and meta-pandaboard? If not how do you clone and checkout the pandaboard BPS? http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ It has a README in there on how to set it up, read it and follow it precisely. Just out of interest, why does meta-texasinstruments depend on meta-angstrom? It needs extra things in overrides and reuses tasks from there. Sorry for the follow-up, but if I clone the meta-texasinstruments bsp repository and checkout the pandaboard-rework branch, how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the Yocto site? I'll jump into the middle of the thread, and answer a couple of specific questions and leave the larger what depends on what, and where things evolve and why .. for another day. The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update of a reference BSP for the 3.0 (and newer) kernel(s). Who is the intended audience of this BSP? The Angstrom/meta-to layer is obviously intended for people using TI hardware and all the associated peripherals. Without defining your audience better, this jsut adds to the confusion end users are experiencing with all the words and layers being used in emails. This is becoming a real problem as new users enter the project. Quite simply, the audience that needs a particular kernel version and feature set, with the tooling to transition to a supported (i.e not the yocto one) BSP. You do realize that by doing this without informing anyone involved with the official pandaboard BSP the net effect is negative? And by 'negative' I mean "severe annoyance" among other things. .. and why would you assume that precisely that hadn't been done ? It has been, via management channels at multiple companies and organizations and is exactly why I said "a layer you can't get" and "work in progress". So please, no need to jump to anything resembling 'annoyance'. There's plenty of that to go around, and it isn't constructive. I think it would be nice if we had a wiki document which listed various BSPs for a given platform that are available using the given layers and some words differentiating them. That can help end users in understanding and deciding which to use. AFAIK there are plans in this area for the 1.2 timeframe, perhaps via the BSP portal that TomZ was creating. Something linked from the wiki pages that list all the available layers would be the logical place to locate something like this as well. Richard may have more insight as to whether or not something is planned like this. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On (23/12/11 12:59), Bruce Ashfield wrote: > On 11-12-23 12:52 PM, Koen Kooi wrote: > > > >Op 23 dec. 2011, om 18:45 heeft Bruce Ashfield het volgende geschreven: > > > >>On 11-12-23 12:38 PM, Philip Balister wrote: > >>>On 12/23/2011 12:10 PM, Bruce Ashfield wrote: > On 11-12-23 08:10 AM, James Abernathy wrote: > > > >On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: > > > >> > >>Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: > >> > >>>On Friday 23 December 2011 09:28:31 Koen Kooi wrote: > Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: > >I know the examples in the documentation of Yocto use meta-intel a > >lot > >to get the board specific BSPs like meta-crownbay or meta-n450. > > > >Is there a meta-ti or similar that gets you the meta-beagleboard and > >meta-pandaboard? If not how do you clone and checkout the pandaboard > >BPS? > http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ > > > It has a README in there on how to set it up, read it and follow it > precisely. > >>> > >>>Just out of interest, why does meta-texasinstruments depend on > >>>meta-angstrom? > >> > >>It needs extra things in overrides and reuses tasks from there. > > > >Sorry for the follow-up, but if I clone the meta-texasinstruments bsp > >repository and checkout the pandaboard-rework branch, > >how does that relate to the Yocto branch/bsp yocto/standard/pandaboard > >on the Yocto site? > > I'll jump into the middle of the thread, and answer a couple of specific > questions and leave the larger what depends on what, and where > things evolve and why .. for another day. > > The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update > of a reference BSP for the 3.0 (and newer) kernel(s). > >>> > >>>Who is the intended audience of this BSP? The Angstrom/meta-to layer is > >>>obviously intended for people using TI hardware and all the associated > >>>peripherals. Without defining your audience better, this jsut adds to > >>>the confusion end users are experiencing with all the words and layers > >>>being used in emails. This is becoming a real problem as new users enter > >>>the project. > >> > >>Quite simply, the audience that needs a particular kernel version > >>and feature set, with the tooling to transition to a supported (i.e > >>not the yocto one) BSP. > > > >You do realize that by doing this without informing anyone involved with the > >official pandaboard BSP the net effect is negative? And by 'negative' I mean > >"severe annoyance" among other things. > > .. and why would you assume that precisely that hadn't been done ? > It has been, via management channels at multiple companies and > organizations and is exactly why I said "a layer you can't get" > and "work in progress". > > So please, no need to jump to anything resembling 'annoyance'. > There's plenty of that to go around, and it isn't constructive. I think it would be nice if we had a wiki document which listed various BSPs for a given platform that are available using the given layers and some words differentiating them. That can help end users in understanding and deciding which to use. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On 11-12-23 12:52 PM, Koen Kooi wrote: Op 23 dec. 2011, om 18:45 heeft Bruce Ashfield het volgende geschreven: On 11-12-23 12:38 PM, Philip Balister wrote: On 12/23/2011 12:10 PM, Bruce Ashfield wrote: On 11-12-23 08:10 AM, James Abernathy wrote: On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: On Friday 23 December 2011 09:28:31 Koen Kooi wrote: Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: I know the examples in the documentation of Yocto use meta-intel a lot to get the board specific BSPs like meta-crownbay or meta-n450. Is there a meta-ti or similar that gets you the meta-beagleboard and meta-pandaboard? If not how do you clone and checkout the pandaboard BPS? http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ It has a README in there on how to set it up, read it and follow it precisely. Just out of interest, why does meta-texasinstruments depend on meta-angstrom? It needs extra things in overrides and reuses tasks from there. Sorry for the follow-up, but if I clone the meta-texasinstruments bsp repository and checkout the pandaboard-rework branch, how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the Yocto site? I'll jump into the middle of the thread, and answer a couple of specific questions and leave the larger what depends on what, and where things evolve and why .. for another day. The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update of a reference BSP for the 3.0 (and newer) kernel(s). Who is the intended audience of this BSP? The Angstrom/meta-to layer is obviously intended for people using TI hardware and all the associated peripherals. Without defining your audience better, this jsut adds to the confusion end users are experiencing with all the words and layers being used in emails. This is becoming a real problem as new users enter the project. Quite simply, the audience that needs a particular kernel version and feature set, with the tooling to transition to a supported (i.e not the yocto one) BSP. You do realize that by doing this without informing anyone involved with the official pandaboard BSP the net effect is negative? And by 'negative' I mean "severe annoyance" among other things. .. and why would you assume that precisely that hadn't been done ? It has been, via management channels at multiple companies and organizations and is exactly why I said "a layer you can't get" and "work in progress". So please, no need to jump to anything resembling 'annoyance'. There's plenty of that to go around, and it isn't constructive. Bruce ___ 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] meta-ti?????
Op 23 dec. 2011, om 18:45 heeft Bruce Ashfield het volgende geschreven: > On 11-12-23 12:38 PM, Philip Balister wrote: >> On 12/23/2011 12:10 PM, Bruce Ashfield wrote: >>> On 11-12-23 08:10 AM, James Abernathy wrote: On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: > > Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: > >> On Friday 23 December 2011 09:28:31 Koen Kooi wrote: >>> Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: I know the examples in the documentation of Yocto use meta-intel a lot to get the board specific BSPs like meta-crownbay or meta-n450. Is there a meta-ti or similar that gets you the meta-beagleboard and meta-pandaboard? If not how do you clone and checkout the pandaboard BPS? >>> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ >>> >>> >>> It has a README in there on how to set it up, read it and follow it >>> precisely. >> >> Just out of interest, why does meta-texasinstruments depend on >> meta-angstrom? > > It needs extra things in overrides and reuses tasks from there. Sorry for the follow-up, but if I clone the meta-texasinstruments bsp repository and checkout the pandaboard-rework branch, how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the Yocto site? >>> >>> I'll jump into the middle of the thread, and answer a couple of specific >>> questions and leave the larger what depends on what, and where >>> things evolve and why .. for another day. >>> >>> The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update >>> of a reference BSP for the 3.0 (and newer) kernel(s). >> >> Who is the intended audience of this BSP? The Angstrom/meta-to layer is >> obviously intended for people using TI hardware and all the associated >> peripherals. Without defining your audience better, this jsut adds to >> the confusion end users are experiencing with all the words and layers >> being used in emails. This is becoming a real problem as new users enter >> the project. > > Quite simply, the audience that needs a particular kernel version > and feature set, with the tooling to transition to a supported (i.e > not the yocto one) BSP. You do realize that by doing this without informing anyone involved with the official pandaboard BSP the net effect is negative? And by 'negative' I mean "severe annoyance" among other things. signature.asc Description: Message signed with OpenPGP using GPGMail ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On 11-12-23 12:38 PM, Philip Balister wrote: On 12/23/2011 12:10 PM, Bruce Ashfield wrote: On 11-12-23 08:10 AM, James Abernathy wrote: On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: On Friday 23 December 2011 09:28:31 Koen Kooi wrote: Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: I know the examples in the documentation of Yocto use meta-intel a lot to get the board specific BSPs like meta-crownbay or meta-n450. Is there a meta-ti or similar that gets you the meta-beagleboard and meta-pandaboard? If not how do you clone and checkout the pandaboard BPS? http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ It has a README in there on how to set it up, read it and follow it precisely. Just out of interest, why does meta-texasinstruments depend on meta-angstrom? It needs extra things in overrides and reuses tasks from there. Sorry for the follow-up, but if I clone the meta-texasinstruments bsp repository and checkout the pandaboard-rework branch, how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the Yocto site? I'll jump into the middle of the thread, and answer a couple of specific questions and leave the larger what depends on what, and where things evolve and why .. for another day. The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update of a reference BSP for the 3.0 (and newer) kernel(s). Who is the intended audience of this BSP? The Angstrom/meta-to layer is obviously intended for people using TI hardware and all the associated peripherals. Without defining your audience better, this jsut adds to the confusion end users are experiencing with all the words and layers being used in emails. This is becoming a real problem as new users enter the project. Quite simply, the audience that needs a particular kernel version and feature set, with the tooling to transition to a supported (i.e not the yocto one) BSP. Cheers, Bruce Philip But what you are seeing ,in the linux-yocto kernel tree, is a work in progress at the moment, since there is an associated layer that is a combo layer, and uses the layer tooling to build on top work that has already been done by TI and other distro layers. Since, as already been covered in this thread, there (often) multiple places support for any given board can be found. What you use, all depends on what you are looking for. The linux-yocto variant is built/tested with a yocto + oe-core base and receives updates of features/fixes that other BSPs in the tree gets. (note: I'm not claiming this is unique, just that it is done using the yocto kernel tooling ). A common set of features and docs would accompany any related BSPs. In this case, the BSP was contributed to the project on the 3.0 kernel, so I merged it into the tree to have that integrated support with as few layers as possible. If you want the angstrom/TI pandaboard, doing what Koen suggests is the ticket. Look at those layers, follow their READMEs and you'll be good to go. Cheers, Bruce Being a Yocto newbie, it's hard enough to understand all the branches on the yocto site. Relating the meta-angstrom is confusing. The light bulb has now gone on yet :-) Jim A ___ 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 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] meta-ti?????
On 12/23/2011 12:10 PM, Bruce Ashfield wrote: > On 11-12-23 08:10 AM, James Abernathy wrote: >> >> On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: >> >>> >>> Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: >>> On Friday 23 December 2011 09:28:31 Koen Kooi wrote: > Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: >> I know the examples in the documentation of Yocto use meta-intel a >> lot >> to get the board specific BSPs like meta-crownbay or meta-n450. >> >> Is there a meta-ti or similar that gets you the meta-beagleboard and >> meta-pandaboard? If not how do you clone and checkout the pandaboard >> BPS? > http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ > > > It has a README in there on how to set it up, read it and follow it > precisely. Just out of interest, why does meta-texasinstruments depend on meta-angstrom? >>> >>> It needs extra things in overrides and reuses tasks from there. >> >> Sorry for the follow-up, but if I clone the meta-texasinstruments bsp >> repository and checkout the pandaboard-rework branch, >> how does that relate to the Yocto branch/bsp yocto/standard/pandaboard >> on the Yocto site? > > I'll jump into the middle of the thread, and answer a couple of specific > questions and leave the larger what depends on what, and where > things evolve and why .. for another day. > > The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update > of a reference BSP for the 3.0 (and newer) kernel(s). Who is the intended audience of this BSP? The Angstrom/meta-to layer is obviously intended for people using TI hardware and all the associated peripherals. Without defining your audience better, this jsut adds to the confusion end users are experiencing with all the words and layers being used in emails. This is becoming a real problem as new users enter the project. Philip > > But what you are seeing ,in the linux-yocto kernel tree, is a work in > progress at the moment, since there is an associated layer that is a > combo layer, and uses the layer tooling to build on top work that has > already been done by TI and other distro layers. > > Since, as already been covered in this thread, there (often) multiple > places support for any given board can be found. What you use, all > depends on what you are looking for. > > The linux-yocto variant is built/tested with a yocto + oe-core base > and receives updates of features/fixes that other BSPs in the tree > gets. (note: I'm not claiming this is unique, just that it is done > using the yocto kernel tooling ). A common set of features and docs > would accompany any related BSPs. In this case, the BSP was contributed > to the project on the 3.0 kernel, so I merged it into the tree to > have that integrated support with as few layers as possible. > > If you want the angstrom/TI pandaboard, doing what Koen suggests is > the ticket. Look at those layers, follow their READMEs and you'll be > good to go. > > Cheers, > > Bruce > > > >> >> Being a Yocto newbie, it's hard enough to understand all the branches >> on the yocto site. Relating the meta-angstrom is confusing. >> >> The light bulb has now gone on yet :-) >> >> Jim A >> >>> ___ >>> 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 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] meta-ti?????
On 11-12-23 08:10 AM, James Abernathy wrote: On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: On Friday 23 December 2011 09:28:31 Koen Kooi wrote: Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: I know the examples in the documentation of Yocto use meta-intel a lot to get the board specific BSPs like meta-crownbay or meta-n450. Is there a meta-ti or similar that gets you the meta-beagleboard and meta-pandaboard? If not how do you clone and checkout the pandaboard BPS? http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ It has a README in there on how to set it up, read it and follow it precisely. Just out of interest, why does meta-texasinstruments depend on meta-angstrom? It needs extra things in overrides and reuses tasks from there. Sorry for the follow-up, but if I clone the meta-texasinstruments bsp repository and checkout the pandaboard-rework branch, how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the Yocto site? I'll jump into the middle of the thread, and answer a couple of specific questions and leave the larger what depends on what, and where things evolve and why .. for another day. The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update of a reference BSP for the 3.0 (and newer) kernel(s). But what you are seeing ,in the linux-yocto kernel tree, is a work in progress at the moment, since there is an associated layer that is a combo layer, and uses the layer tooling to build on top work that has already been done by TI and other distro layers. Since, as already been covered in this thread, there (often) multiple places support for any given board can be found. What you use, all depends on what you are looking for. The linux-yocto variant is built/tested with a yocto + oe-core base and receives updates of features/fixes that other BSPs in the tree gets. (note: I'm not claiming this is unique, just that it is done using the yocto kernel tooling ). A common set of features and docs would accompany any related BSPs. In this case, the BSP was contributed to the project on the 3.0 kernel, so I merged it into the tree to have that integrated support with as few layers as possible. If you want the angstrom/TI pandaboard, doing what Koen suggests is the ticket. Look at those layers, follow their READMEs and you'll be good to go. Cheers, Bruce Being a Yocto newbie, it's hard enough to understand all the branches on the yocto site. Relating the meta-angstrom is confusing. The light bulb has now gone on yet :-) Jim A ___ 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On 12/23/2011 08:43 AM, Paul Eggleton wrote: > On Friday 23 December 2011 14:23:53 Koen Kooi wrote: >>> Being a Yocto newbie, it's hard enough to understand all the branches on >>> the yocto site. Relating the meta-angstrom is confusing. >> >> No, yocto (or is it poky? noone knows) > > Officially, Poky is the build system, Yocto is the umbrella project which > also > includes a number of other sub-projects (swabber, pseudo, etc.). There are > some that use Yocto to refer to the build system; I'm not sure that does a > great deal of harm nor is it really relevant to this discussion. > >> has confusing messaging, It's best to >> find the official BSP for the board you use and follow the instructions in >> there and ignore anything else. > > Personally I think this is a bit disappointing. The Yocto Project and the > move > to OE-Core is supposed to provide us a way to mix and match hardware support > with available software packages. The apparent tying of meta-texasinstruments > to meta-angstrom goes against that philosophy, IMHO. I haven't yet heard a > compelling technical argument for why that should be necessary. BSP's shoudl contain image recipes that create useful images for the hardware. Images often tend to contain distro specific bits and pieces. This leads to this sort of (problematic) dependencies between layers. This is good area for further study since the problem will likely increase without careful thought. I'd also suggest not depending on the BSP guys to do this, since I suspect their corporate overlords care more about the output and customer satisfaction then internal "details". Philip ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On Friday 23 December 2011 14:23:53 Koen Kooi wrote: > > Being a Yocto newbie, it's hard enough to understand all the branches on > > the yocto site. Relating the meta-angstrom is confusing. > > No, yocto (or is it poky? noone knows) Officially, Poky is the build system, Yocto is the umbrella project which also includes a number of other sub-projects (swabber, pseudo, etc.). There are some that use Yocto to refer to the build system; I'm not sure that does a great deal of harm nor is it really relevant to this discussion. > has confusing messaging, It's best to > find the official BSP for the board you use and follow the instructions in > there and ignore anything else. Personally I think this is a bit disappointing. The Yocto Project and the move to OE-Core is supposed to provide us a way to mix and match hardware support with available software packages. The apparent tying of meta-texasinstruments to meta-angstrom goes against that philosophy, IMHO. I haven't yet heard a compelling technical argument for why that should be necessary. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On 12/23/2011 08:10 AM, James Abernathy wrote: > > On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: > >> >> Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: >> >>> On Friday 23 December 2011 09:28:31 Koen Kooi wrote: Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: > I know the examples in the documentation of Yocto use meta-intel a lot > to get the board specific BSPs like meta-crownbay or meta-n450. > > Is there a meta-ti or similar that gets you the meta-beagleboard and > meta-pandaboard? If not how do you clone and checkout the pandaboard > BPS? http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ It has a README in there on how to set it up, read it and follow it precisely. >>> >>> Just out of interest, why does meta-texasinstruments depend on >>> meta-angstrom? >> >> It needs extra things in overrides and reuses tasks from there. > > Sorry for the follow-up, but if I clone the meta-texasinstruments bsp > repository and checkout the pandaboard-rework branch, > how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the > Yocto site? > > Being a Yocto newbie, it's hard enough to understand all the branches on the > yocto site. Relating the meta-angstrom is confusing. > > The light bulb has now gone on yet :-) I would guess the panda support in the Yocto BSP branch are there to show Yocto (a word with many different meanings to different people) can build stuff for non-Intel hardware. However if I were building for a Panda, I would use the meta-texas-instruments stuff because I would expect it to support all the bits of hardware (3D etc) available on the Pandaboard. The Panda and Beagleboards are readily available so they make good demonstration cases for BSP's, but enabling all the features on these SoC's is a lot more work. Philip ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
Op 23 dec. 2011, om 14:10 heeft James Abernathy het volgende geschreven: > > On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: > >> >> Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: >> >>> On Friday 23 December 2011 09:28:31 Koen Kooi wrote: Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: > I know the examples in the documentation of Yocto use meta-intel a lot > to get the board specific BSPs like meta-crownbay or meta-n450. > > Is there a meta-ti or similar that gets you the meta-beagleboard and > meta-pandaboard? If not how do you clone and checkout the pandaboard > BPS? http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ It has a README in there on how to set it up, read it and follow it precisely. >>> >>> Just out of interest, why does meta-texasinstruments depend on >>> meta-angstrom? >> >> It needs extra things in overrides and reuses tasks from there. > > Sorry for the follow-up, but if I clone the meta-texasinstruments bsp > repository and checkout the pandaboard-rework branch, > how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the > Yocto site? It doesn't. > Being a Yocto newbie, it's hard enough to understand all the branches on the > yocto site. Relating the meta-angstrom is confusing. No, yocto (or is it poky? noone knows) has confusing messaging, It's best to find the official BSP for the board you use and follow the instructions in there and ignore anything else. signature.asc Description: Message signed with OpenPGP using GPGMail ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: > > Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: > >> On Friday 23 December 2011 09:28:31 Koen Kooi wrote: >>> Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: I know the examples in the documentation of Yocto use meta-intel a lot to get the board specific BSPs like meta-crownbay or meta-n450. Is there a meta-ti or similar that gets you the meta-beagleboard and meta-pandaboard? If not how do you clone and checkout the pandaboard BPS? >>> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ >>> >>> It has a README in there on how to set it up, read it and follow it >>> precisely. >> >> Just out of interest, why does meta-texasinstruments depend on meta-angstrom? > > It needs extra things in overrides and reuses tasks from there. Sorry for the follow-up, but if I clone the meta-texasinstruments bsp repository and checkout the pandaboard-rework branch, how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the Yocto site? Being a Yocto newbie, it's hard enough to understand all the branches on the yocto site. Relating the meta-angstrom is confusing. The light bulb has now gone on yet :-) Jim A > ___ > 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] meta-ti?????
Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: > On Friday 23 December 2011 09:28:31 Koen Kooi wrote: >> Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: >>> I know the examples in the documentation of Yocto use meta-intel a lot >>> to get the board specific BSPs like meta-crownbay or meta-n450. >>> >>> Is there a meta-ti or similar that gets you the meta-beagleboard and >>> meta-pandaboard? If not how do you clone and checkout the pandaboard >>> BPS? >> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ >> >> It has a README in there on how to set it up, read it and follow it >> precisely. > > Just out of interest, why does meta-texasinstruments depend on meta-angstrom? It needs extra things in overrides and reuses tasks from there. signature.asc Description: Message signed with OpenPGP using GPGMail ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On Friday 23 December 2011 09:28:31 Koen Kooi wrote: > Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: > > I know the examples in the documentation of Yocto use meta-intel a lot > > to get the board specific BSPs like meta-crownbay or meta-n450. > > > > Is there a meta-ti or similar that gets you the meta-beagleboard and > > meta-pandaboard? If not how do you clone and checkout the pandaboard > > BPS? > http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ > > It has a README in there on how to set it up, read it and follow it > precisely. Just out of interest, why does meta-texasinstruments depend on meta-angstrom? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: > I know the examples in the documentation of Yocto use meta-intel a lot to get > the board specific BSPs like meta-crownbay or meta-n450. > > Is there a meta-ti or similar that gets you the meta-beagleboard and > meta-pandaboard? If not how do you clone and checkout the pandaboard BPS? http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ It has a README in there on how to set it up, read it and follow it precisely. signature.asc Description: Message signed with OpenPGP using GPGMail ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On Thu, Dec 22, 2011 at 8:06 AM, Jim Abernathy wrote: > I know the examples in the documentation of Yocto use meta-intel a lot to > get the board specific BSPs like meta-crownbay or meta-n450. > > Is there a meta-ti or similar that gets you the meta-beagleboard and > meta-pandaboard? If not how do you clone and checkout the pandaboard BPS? http://www.openembedded.org/wiki/LayerIndex -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
