Date   

Re: Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel

Chris Tapp
 

On 9 Oct 2012, at 14:40, James Abernathy wrote:



On Mon, Oct 8, 2012 at 12:28 PM, Saxena, Rahul <rahul.saxena@...> wrote:


-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@...]
Sent: Monday, October 08, 2012 7:00 AM
To: Chris Tapp
Cc: Saxena, Rahul; yocto@... Project
Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel

On Mon, Oct 8, 2012 at 3:58 AM, Chris Tapp <opensource@...> wrote:
> On 7 Oct 2012, at 22:41, Bruce Ashfield wrote:
>
>> On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp <opensource@...> wrote:
>>> On 7 Oct 2012, at 03:00, Saxena, Rahul wrote:
>>>
>>>> Try adding the unionfs feature (below) to your kernel:
>>>>
>>>> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tree/meta
>>>> /cfg/kernel-cache/features/unionfs?h=meta
>>>>
>>>> create a file my_cedartrail.scc with following line:
>>>> include features/unionfs/unionfs.scc
>>>>
>>>> put this file in a dir linux-yocto, the dir being created in
>>>>
>>>> meta-cedartrail/recipes-kernel/linux
>>>>
>>>> add following line in
>>>> meta-cedartrail/recipes-kernel/Linux/linux-yocto_3.0.bbappend
>>>>
>>>> SRC_URI +="file://my_cedartrail.scc"
>>>
>>> Thanks - I thought just running 'menuconfig' would allow me to enable it (for a quick test).
>>>
>>> However, this still doesn't seem to be working. I can see that 'my_cedartrail.scc' gets fetched in to the build area, but I still don't see CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in fs/ of the build tree.
>>>
>>> Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc) I'm not seeing any diagnostic.
>>
>> unionfs was never merged to the 3.0 kernel, I re-added it to the
>> development trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree
>> at the moment). The meta data is carried forward from the older
>> kernels as a placeholder and is documented in the .scc file itself:
>>
>> -----------------------
>> kconf non-hardware unionfs.cfg
>>
>> # commented pending update to a newer version ported to 2.6.35+ #
>> patch unionfs-2.5.4-integration.patch
>> -----------------------
>>
>> So to get unionfs in the 3.0 kernel, we'd need a port .. but since
>> we've moved on quite a bit past 3.0, I don't know of any pending
>> ports myself.
>
> Thanks Bruce.
>
> I guess I need to ask the Intel guys if there are any plans to move Cedartrail on from 3.0 ?

It will have to happen post yocto 1.3 (as far as I know), since the
3.0 kernel will be
dropped at that point.

For the short term, it's likely easier to backport/update unionfs than it would be to update the BSP .. but I can't speak for the time to be spent doing it :)

Cheers,

Bruce


Chris,

There are no plans to port Cedartrail BSP to support any other Kernel other than 3.0. The reason is that
the Cedartrail PVR Graphics driver is supported only for 3.0 kernel.

Rahul

 
It may not solve the 3.0 problem for CDV and Yocto, but I noticed that Ubuntu 12.04.1 with the 3.2 kernel supports the PVR driver on it's 3.2.0 kernel.  I've only tested it successfully on an All-In-One with LVDS off of an eDP to LVDS converter used on the DN2800MT motherboard.

Interesting - that's the same board as I'm using. It would be worth seeing what happens. I've had a look at the bbappend for 3.2 that Kishore posted and compared it with the standard one for 3.0. I think it 'just' needs a new meta data branch before I can try a build with pvr. I guess this will need to be a new branch and not an existing one?

 
Jim A
 
>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>>
>>>> -----Original Message-----
>>>> From: yocto-bounces@...
>>>> [mailto:yocto-bounces@...] On Behalf Of Chris Tapp
>>>> Sent: Saturday, October 06, 2012 5:43 PM
>>>> To: yocto@... Project
>>>> Subject: [yocto] Meta Intel / Cedartrail / Denzil - how to get
>>>> unionfs in the kernel
>>>>
>>>> I' trying to enable unionfs in the 3.0.32 kernel for the cedartrail BSP under Denzil 7.0.1.
>>>>
>>>> However, the CONFIG_UNION_FS config flag isn't in the .config ...
>>>>
>>>> Is there something else I need to enable, or do I need to find another way?
>>>>
>>>> Chris Tapp
>>>>
>>>> opensource@...
>>>> www.keylevel.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@...
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>> Chris Tapp
>>>
>>> opensource@...
>>> www.keylevel.com
>>>
>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@...
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>
> Chris Tapp
>
> opensource@...
> www.keylevel.com
>
>
>



--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto




Re: Newbie looking for a Recipe Box for AM1707 aka Texas Instruments TMDXEVM1707

Denys Dmytriyenko
 

On Tue, Sep 25, 2012 at 09:27:22AM -0400, Wesley J. Miller wrote:
The subject pretty much says it all.

I am looking for a build package for the TI AM1707 ARM9 EVM. This is a
Sitara family processor.

And if the answer is "there isn't one", what's the best package choice to
use as a starting point?
Hi,

Sorry for the delay. You can start with the MACHINE=am180x-evm from meta-ti[1],
as it's close enough and from basic BSP perspective should be the same.

[1] http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/

--
Denys


Re: [RFCv2 0/3] [eclipse-poky] Cheat sheet for hello world project

Zhang, Jessica
 

Hi Atanas,

The patch set is merged to eclipse-poky master, thanks for the contribution.

Cheers,
Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Atanas Gegov
Sent: Thursday, October 04, 2012 7:54 AM
To: yocto@...
Subject: [yocto] [RFCv2 0/3] [eclipse-poky] Cheat sheet for hello world project

From: Atanas Gegov <atanas.gegov@...>

Hi Jessica,

Please excuse my late reaction, but I was on vacation in August and had some high-priority organisational issues at work in Septmeber. I improved the cheat sheet accroding to your feedback. I used conditional subitems to make it both fit for the "Hello World C++ Autotools Project" and the "Hello World ANSI C Project". The user can now choose its preferred programming language and the cheat sheet adapts itself accordingly. I also took into account that the SDK is now relocatable.

The patches apply both on the "master" and on the "master-indigo" branches.

Cheers,
Atanas

Atanas Gegov (3):
plugins/sdk.ide.doc.user: Added plugin for ide specific user help
feature/sdk: Added user doc plugin
plugins/sdk.ide.doc.user: Added cheat sheet for hello world project

features/org.yocto.sdk/feature.xml | 8 +
plugins/org.yocto.sdk.ide.doc.user/.classpath | 6 +
plugins/org.yocto.sdk.ide.doc.user/.project | 28 +++
.../.settings/org.eclipse.jdt.core.prefs | 8 +
.../META-INF/MANIFEST.MF | 8 +
.../OSGI-INF/l10n/bundle.properties | 7 +
.../org.yocto.sdk.ide.doc.user/build.properties | 6 +
.../cheatsheets/createNewHelloWorldProject.xml | 222 ++++++++++++++++++++
plugins/org.yocto.sdk.ide.doc.user/plugin.xml | 13 ++
9 files changed, 306 insertions(+), 0 deletions(-) create mode 100644 plugins/org.yocto.sdk.ide.doc.user/.classpath
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/.project
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/.settings/org.eclipse.jdt.core.prefs
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/build.properties
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/cheatsheets/createNewHelloWorldProject.xml
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/plugin.xml

--
1.7.5.4

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel

Jim Abernathy
 



On Mon, Oct 8, 2012 at 12:28 PM, Saxena, Rahul <rahul.saxena@...> wrote:


-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@...]
Sent: Monday, October 08, 2012 7:00 AM
To: Chris Tapp
Cc: Saxena, Rahul; yocto@... Project
Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel

On Mon, Oct 8, 2012 at 3:58 AM, Chris Tapp <opensource@...> wrote:
> On 7 Oct 2012, at 22:41, Bruce Ashfield wrote:
>
>> On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp <opensource@...> wrote:
>>> On 7 Oct 2012, at 03:00, Saxena, Rahul wrote:
>>>
>>>> Try adding the unionfs feature (below) to your kernel:
>>>>
>>>> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tree/meta
>>>> /cfg/kernel-cache/features/unionfs?h=meta
>>>>
>>>> create a file my_cedartrail.scc with following line:
>>>> include features/unionfs/unionfs.scc
>>>>
>>>> put this file in a dir linux-yocto, the dir being created in
>>>>
>>>> meta-cedartrail/recipes-kernel/linux
>>>>
>>>> add following line in
>>>> meta-cedartrail/recipes-kernel/Linux/linux-yocto_3.0.bbappend
>>>>
>>>> SRC_URI +="file://my_cedartrail.scc"
>>>
>>> Thanks - I thought just running 'menuconfig' would allow me to enable it (for a quick test).
>>>
>>> However, this still doesn't seem to be working. I can see that 'my_cedartrail.scc' gets fetched in to the build area, but I still don't see CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in fs/ of the build tree.
>>>
>>> Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc) I'm not seeing any diagnostic.
>>
>> unionfs was never merged to the 3.0 kernel, I re-added it to the
>> development trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree
>> at the moment). The meta data is carried forward from the older
>> kernels as a placeholder and is documented in the .scc file itself:
>>
>> -----------------------
>> kconf non-hardware unionfs.cfg
>>
>> # commented pending update to a newer version ported to 2.6.35+ #
>> patch unionfs-2.5.4-integration.patch
>> -----------------------
>>
>> So to get unionfs in the 3.0 kernel, we'd need a port .. but since
>> we've moved on quite a bit past 3.0, I don't know of any pending
>> ports myself.
>
> Thanks Bruce.
>
> I guess I need to ask the Intel guys if there are any plans to move Cedartrail on from 3.0 ?

It will have to happen post yocto 1.3 (as far as I know), since the
3.0 kernel will be
dropped at that point.

For the short term, it's likely easier to backport/update unionfs than it would be to update the BSP .. but I can't speak for the time to be spent doing it :)

Cheers,

Bruce


Chris,

There are no plans to port Cedartrail BSP to support any other Kernel other than 3.0. The reason is that
the Cedartrail PVR Graphics driver is supported only for 3.0 kernel.

Rahul

 
It may not solve the 3.0 problem for CDV and Yocto, but I noticed that Ubuntu 12.04.1 with the 3.2 kernel supports the PVR driver on it's 3.2.0 kernel.  I've only tested it successfully on an All-In-One with LVDS off of an eDP to LVDS converter used on the DN2800MT motherboard.
 
Jim A
 
>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>>
>>>> -----Original Message-----
>>>> From: yocto-bounces@...
>>>> [mailto:yocto-bounces@...] On Behalf Of Chris Tapp
>>>> Sent: Saturday, October 06, 2012 5:43 PM
>>>> To: yocto@... Project
>>>> Subject: [yocto] Meta Intel / Cedartrail / Denzil - how to get
>>>> unionfs in the kernel
>>>>
>>>> I' trying to enable unionfs in the 3.0.32 kernel for the cedartrail BSP under Denzil 7.0.1.
>>>>
>>>> However, the CONFIG_UNION_FS config flag isn't in the .config ...
>>>>
>>>> Is there something else I need to enable, or do I need to find another way?
>>>>
>>>> Chris Tapp
>>>>
>>>> opensource@...
>>>> www.keylevel.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@...
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>> Chris Tapp
>>>
>>> opensource@...
>>> www.keylevel.com
>>>
>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@...
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>
> Chris Tapp
>
> opensource@...
> www.keylevel.com
>
>
>



--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: The BitBake equivalent of "Hello, World!"

Rudolf Streif <rudolf.streif@...>
 

The T variable points to a directory were Bitbake places temporary files when building a particular package. It is typically set to

T = ${WORKDIR}/temp

WORKDIR is the directory into which Bitbake unpacks and builds a package. The default bitbake.conf file sets this variable.

T is not to be confused with TMPDIR which points to the root of the directory tree where Bitbake puts the output of an entire build.

:rjs


On Mon, Oct 8, 2012 at 5:30 PM, Patrick Turley <PatrickTurley@...> wrote:
I am continuing my work on creating a "Hello, World!" BitBake project. Because of the excellent help I got before, things have gone reasonably well, but I'm again running into something I don't know how to fix.

As before, the entire contents of my very small project appear at the end of this message. Here's what works fine:


    $ ../BitBake/bin/bitbake-layers show-layers
    Parsing recipes..done.

    layer     path                                    priority
    ==========================================================
    LayerA    /home/pturley/Workspace/Hello/LayerA    1

    $ ../BitBake/bin/bitbake-layers show-recipes
    Parsing recipes..done.
    === Available recipes: ===
    a:
      LayerA               1


When I tried this:


    ../BitBake/bin/bitbake -c listtasks a


I got a Python stack trace that ended here:


      File "../BitBake/lib/bb/runqueue.py", line 902, in RunQueue.check_stamp_task(task=0, taskname='do_listtasks', recurse=False):
                 # If the stamp is missing its not current
        >        if not os.access(stampfile, os.F_OK):
                     logger.debug(2, "Stampfile %s not available", stampfile)
    TypeError: coercing to Unicode: need string or buffer, NoneType found


This code isn't expecting the "stampfile" variable to be "None" (which it is), so it freaks out. I made a very simple fix to get past the problem:


    if not stampfile or not os.access(stampfile, os.F_OK):


That made a dramatic difference, and enabled me to get this far:


    $ ../BitBake/bin/bitbake -c listtasks a
    Loading cache: 100% |###############################################################| ETA:  00:00:00
    Loaded 2 entries from dependency cache.
    NOTE: Resolving any missing task queue dependencies
    NOTE: Preparing runqueue
    NOTE: Executing RunQueue Tasks
    NOTE: Running task 1 of 1 (ID: 0, /home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks)
    ERROR: T variable not set, unable to build
    ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks) failed with exit code '1'
    NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and 1 failed.

    Summary: 1 task failed:
      /home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks
    Summary: There was 1 ERROR message shown, returning a non-zero exit code.

    $ ../BitBake/bin/bitbake a
    Loading cache: 100% |###############################################################| ETA:  00:00:00
    Loaded 2 entries from dependency cache.
    NOTE: Resolving any missing task queue dependencies
    NOTE: Preparing runqueue
    NOTE: Executing RunQueue Tasks
    NOTE: Running task 1 of 1 (ID: 0, /home/pturley/Workspace/Hello/LayerA/a.bb, do_build)
    ERROR: T variable not set, unable to build
    ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb, do_build) failed with exit code '1'
    NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and 1 failed.

    Summary: 1 task failed:
      /home/pturley/Workspace/Hello/LayerA/a.bb, do_build
    Summary: There was 1 ERROR message shown, returning a non-zero exit code.


As you can see, BitBake is expecting the "T" variable to be set.  I don't think I've ever seen this variable -- so I don't know what it's for or what I should change.

Can anyone offer a hint?


------------------------------------------------------------


├── build
│   │
│   ├── classes
│   │   │
│   │   └── base.bbclass
│   │
│   │       +-----------------------------------------------
│   │       |  addtask listtasks
│   │       |
│   │       |  do_listtasks[nostamp] = "1"
│   │       |
│   │       |  python do_listtasks() {
│   │       |          import sys
│   │       |          # emit variables and shell functions
│   │       |          #bb.data.emit_env(sys.__stdout__, d)
│   │       |          # emit the metadata which isnt valid shell
│   │       |          for e in d.keys():
│   │       |                  if d.getVarFlag(e, 'task'):
│   │       |                          bb.plain("%s" % e)
│   │       |  }
│   │       |
│   │       |  addtask build
│   │       |
│   │       |  do_build() {
│   │       |      echo "Hello"
│   │       |  }
│   │       +-----------------------------------------------
│   │
│   └── conf
│       │
│       ├── bblayers.conf
│       │
│       │   +-----------------------------------------------
│       │   |  BBLAYERS ?= " \
│       │   |    /home/pturley/Workspace/Hello/LayerA \
│       │   |    "
│       │   +-----------------------------------------------
│       │
│       └── bitbake.conf
│           +-----------------------------------------------
│           |  CACHE = "${TOPDIR}/cache"
│           +-----------------------------------------------
├── LayerA
│   │
│   ├── a.bb
│   │
│   │       +-----------------------------------------------
│   │       |  DESCRIPTION = "Layer A Main Recipe"
│   │       |  PN = 'a'
│   │       |  PV = '1'
│   │       +-----------------------------------------------
│   │
│   └── conf
│       │
│       └── layer.conf
│           +-----------------------------------------------
│           |  BBPATH .= ":${LAYERDIR}"
│           |
│           |  BBFILES += "${LAYERDIR}/*.bb"
│           |
│           |  BBFILE_COLLECTIONS += "A"
│           |  BBFILE_PATTERN_A := "^${LAYERDIR}/"
│           +-----------------------------------------------
└── BitBake

   The BitBake directory origin is:


   I have the 1.15.2 tag checked out, which is what
   Yocto denzil uses.


_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto



Re: The BitBake equivalent of "Hello, World!"

Patrick Turley <PatrickTurley@...>
 

I am continuing my work on creating a "Hello, World!" BitBake project. Because of the excellent help I got before, things have gone reasonably well, but I'm again running into something I don't know how to fix.

As before, the entire contents of my very small project appear at the end of this message. Here's what works fine:


    $ ../BitBake/bin/bitbake-layers show-layers
    Parsing recipes..done.

    layer     path                                    priority
    ==========================================================
    LayerA    /home/pturley/Workspace/Hello/LayerA    1

    $ ../BitBake/bin/bitbake-layers show-recipes
    Parsing recipes..done.
    === Available recipes: ===
    a:
      LayerA               1


When I tried this:


    ../BitBake/bin/bitbake -c listtasks a


I got a Python stack trace that ended here:


      File "../BitBake/lib/bb/runqueue.py", line 902, in RunQueue.check_stamp_task(task=0, taskname='do_listtasks', recurse=False):
                 # If the stamp is missing its not current
        >        if not os.access(stampfile, os.F_OK):
                     logger.debug(2, "Stampfile %s not available", stampfile)
    TypeError: coercing to Unicode: need string or buffer, NoneType found


This code isn't expecting the "stampfile" variable to be "None" (which it is), so it freaks out. I made a very simple fix to get past the problem:


    if not stampfile or not os.access(stampfile, os.F_OK):


That made a dramatic difference, and enabled me to get this far:


    $ ../BitBake/bin/bitbake -c listtasks a
    Loading cache: 100% |###############################################################| ETA:  00:00:00
    Loaded 2 entries from dependency cache.
    NOTE: Resolving any missing task queue dependencies
    NOTE: Preparing runqueue
    NOTE: Executing RunQueue Tasks
    NOTE: Running task 1 of 1 (ID: 0, /home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks)
    ERROR: T variable not set, unable to build
    ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks) failed with exit code '1'
    NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and 1 failed.

    Summary: 1 task failed:
      /home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks
    Summary: There was 1 ERROR message shown, returning a non-zero exit code.

    $ ../BitBake/bin/bitbake a
    Loading cache: 100% |###############################################################| ETA:  00:00:00
    Loaded 2 entries from dependency cache.
    NOTE: Resolving any missing task queue dependencies
    NOTE: Preparing runqueue
    NOTE: Executing RunQueue Tasks
    NOTE: Running task 1 of 1 (ID: 0, /home/pturley/Workspace/Hello/LayerA/a.bb, do_build)
    ERROR: T variable not set, unable to build
    ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb, do_build) failed with exit code '1'
    NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and 1 failed.

    Summary: 1 task failed:
      /home/pturley/Workspace/Hello/LayerA/a.bb, do_build
    Summary: There was 1 ERROR message shown, returning a non-zero exit code.


As you can see, BitBake is expecting the "T" variable to be set.  I don't think I've ever seen this variable -- so I don't know what it's for or what I should change.

Can anyone offer a hint?


------------------------------------------------------------


├── build
│   │
│   ├── classes
│   │   │
│   │   └── base.bbclass
│   │
│   │       +-----------------------------------------------
│   │       |  addtask listtasks
│   │       |
│   │       |  do_listtasks[nostamp] = "1"
│   │       |
│   │       |  python do_listtasks() {
│   │       |          import sys
│   │       |          # emit variables and shell functions
│   │       |          #bb.data.emit_env(sys.__stdout__, d)
│   │       |          # emit the metadata which isnt valid shell
│   │       |          for e in d.keys():
│   │       |                  if d.getVarFlag(e, 'task'):
│   │       |                          bb.plain("%s" % e)
│   │       |  }
│   │       |
│   │       |  addtask build
│   │       |
│   │       |  do_build() {
│   │       |      echo "Hello"
│   │       |  }
│   │       +-----------------------------------------------
│   │
│   └── conf
│       │
│       ├── bblayers.conf
│       │
│       │   +-----------------------------------------------
│       │   |  BBLAYERS ?= " \
│       │   |    /home/pturley/Workspace/Hello/LayerA \
│       │   |    "
│       │   +-----------------------------------------------
│       │
│       └── bitbake.conf
│           +-----------------------------------------------
│           |  CACHE = "${TOPDIR}/cache"
│           +-----------------------------------------------
├── LayerA
│   │
│   ├── a.bb
│   │
│   │       +-----------------------------------------------
│   │       |  DESCRIPTION = "Layer A Main Recipe"
│   │       |  PN = 'a'
│   │       |  PV = '1'
│   │       +-----------------------------------------------
│   │
│   └── conf
│       │
│       └── layer.conf
│           +-----------------------------------------------
│           |  BBPATH .= ":${LAYERDIR}"
│           |
│           |  BBFILES += "${LAYERDIR}/*.bb"
│           |
│           |  BBFILE_COLLECTIONS += "A"
│           |  BBFILE_PATTERN_A := "^${LAYERDIR}/"
│           +-----------------------------------------------
└── BitBake

   The BitBake directory origin is:


   I have the 1.15.2 tag checked out, which is what
   Yocto denzil uses.


Re: Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel

Chris Tapp
 

On 8 Oct 2012, at 22:03, Chris Tapp wrote:

On 8 Oct 2012, at 21:30, Bodke, Kishore K wrote:

< snip ... >

Thanks for the really fast response on this :-)

For denzil, try with this by creating a new file in meta-cedartrail/recipes-kernel/linux/linux-yocto_3.2.bbappend.

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_cedartrail-nopvr = "git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
I had to add 'bareclone=1' to this to get it to run.

COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
KMACHINE_cedartrail-nopvr = "cedartrail"
KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail"
KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"

SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= "8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c"
SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= "486f7aec824b4127e91ef53228823e996b3696f0"
I think it's nearly there, but I get a failure when validating the branch:

NOTE: package linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1: task do_validate_branches: Started
ERROR: Function failed: do_validate_branches (see /media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866 for further information)
ERROR: Logfile of failure stored in: /media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866
Log data follows:
| ERROR: Function failed: do_validate_branches (see /media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866 for further information)
NOTE: package linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1: task do_validate_branches: Failed
ERROR: Task 0 (/media/SSD-RAID/poky-git/meta/recipes-kernel/linux/linux-yocto_3.2.bb, do_validate_branches) failed with exit code '1'
Got it - I should have realised this would need to be using the latest denzil head.

I've now got a working unionfs. A few minor kernel configuration issues to sort (e.g. Apple HID for my keyboard) and I'll be there.

Thanks again for the help.

One final question - does lack of PVR mean I won't have a framebuffer device? I've got the vesa one, but I can't use video=... in the kernel command line. Not a show stopper by any means, but the video= stanza is much easier for general users to modify.

Add these below lines to meta-cedartrail/conf/machine/cedartrail-nopvr.conf

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.2%"

Add MACHINE = "cedartrail-nopvr" to your local.conf and build.

Ofcourse you should be adding your unionfs related stuff by some means either by menuconfig or by creating .scc file.
Of course, and that's the bit I understand ;-)

Thanks
Kishore.
Chris Tapp

opensource@...
www.keylevel.com



_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
Chris Tapp

opensource@...
www.keylevel.com


Re: [PATCHv3 0/1] meta-intel misc commits

Tom Zanussi <tom.zanussi@...>
 

On Fri, 2012-10-05 at 19:17 -0700, nitin.a.kamble@... wrote:
From: Nitin A Kamble <nitin.a.kamble@...>

Updated the kernel command line for crownbay BSP, after discussions with Darren.

Thanks,
Nitin

The following changes since commit 7228f6b0c81817c8a8455ea78271abfd5d66fed8:

meta-tlk: fix ignored SRC_URI appends (2012-10-05 14:47:55 -0500)

are available in the git repository at:
git://git.yoctoproject.org/meta-intel-contrib nitin/misc
http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/misc

Nitin A Kamble (1):
crownbay.conf: add kernel parameters for EMGD video acceleration

meta-crownbay/conf/machine/crownbay.conf | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Pulled into meta-intel/master.

Thanks,

Tom


Re: Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel

Chris Tapp
 

On 8 Oct 2012, at 21:30, Bodke, Kishore K wrote:

< snip ... >

Thanks for the really fast response on this :-)

For denzil, try with this by creating a new file in meta-cedartrail/recipes-kernel/linux/linux-yocto_3.2.bbappend.

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_cedartrail-nopvr = "git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
I had to add 'bareclone=1' to this to get it to run.

COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
KMACHINE_cedartrail-nopvr = "cedartrail"
KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail"
KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"

SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= "8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c"
SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= "486f7aec824b4127e91ef53228823e996b3696f0"
I think it's nearly there, but I get a failure when validating the branch:

NOTE: package linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1: task do_validate_branches: Started
ERROR: Function failed: do_validate_branches (see /media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866 for further information)
ERROR: Logfile of failure stored in: /media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866
Log data follows:
| ERROR: Function failed: do_validate_branches (see /media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866 for further information)
NOTE: package linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1: task do_validate_branches: Failed
ERROR: Task 0 (/media/SSD-RAID/poky-git/meta/recipes-kernel/linux/linux-yocto_3.2.bb, do_validate_branches) failed with exit code '1'

Add these below lines to meta-cedartrail/conf/machine/cedartrail-nopvr.conf

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.2%"

Add MACHINE = "cedartrail-nopvr" to your local.conf and build.

Ofcourse you should be adding your unionfs related stuff by some means either by menuconfig or by creating .scc file.
Of course, and that's the bit I understand ;-)

Thanks
Kishore.
Chris Tapp

opensource@...
www.keylevel.com


Agenda: Yocto Project Technical Team Meeting - Tuesday, October 09, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

Liu, Song <song.liu@...>
 

Agenda:
 
* Opens collection - 5 min (Song)
* Yocto 1.3 status - 10 min (Song/team)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status
- Medium+ bugs review: https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&list_id=16013&priority=Medium%2B&query_format=advanced&target_milestone=1.3&target_milestone=1.3%20M1&target_milestone=1.3%20M2&target_milestone=1.3%20M3&target_milestone=1.3%20M4&target_milestone=1.3%20M5&target_milestone=1.3.1&target_milestone=1.3.2&order=assigned_to%20DESC%2Cpriority%2Cbug_status%20DESC%2Cbug_id&query_based_on=
* Yocto 1.4 feature open discussion - 10 min (team)
https://wiki.yoctoproject.org/wiki/Yocto_1.4_Features
* SWAT team rotation: Saul
* Opens - 10 min
* Team sharing - 20 min


-----Original Appointment-----



We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto
IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html

Conference details
Conference name:
Yocto Technical Team
Conference date/start time:
Tue Jun 26, 2012 at 10:00 AM Central Daylight Time
Participants:
30
Duration:
60 minutes
Participant passcode:
76994298
Dial-in number:
1.972.995.7777
US Toll Free number:
1.877.561.6828
BlackBerry users, click this link to join your conference as a participant:
1.972.995.7777x76994298#
 
Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode.

Local and Global Access Numbers


Country
Dial-in number
Australia:
1800 636 843
Czech Republic:
242 430 350
China (Beijing):
From office dial 8-9957777 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai):
From office dial 8-9957777 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen):
From office dial 8-9957777 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities):
From IP phone dial 8-9957777
Other cities - Non IP phone dial 021-23073322
Denmark:
8060 1400
Finland:
09 41333477
France:
0497 275888
Germany:
08161 803232
Holland:
030 2417490
India:
BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) From TI Campus use 89957777 Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel:
09 790 6715
Italy:
039 69061234 (039 is local city code not country code)
Japan:
From TI Campus use 8 995 7777
Outside TI use 03 4331 3777
Malaysia:
From IP phone dial 2643799
From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway:
2 295 8744
Philippines:
From Baguio City use 4471177
From Metro Manila area use 8702477
Singapore:
From IP phone dial 3894777
Outside TI use 6389 4777
South Korea:
From IP phone dial 5606998
From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden:
08 58755577
Taiwan:
From IP phone dial 1363
From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey:
Landline Only dial 0811 288 0001
then enter 877 633 1123
UK:
01604 663003
US:
972 995 7777 or 1877 561 6828

Recurring conferences
First scheduled conference:
Tue Jun 26, 2012
Recurrence frequency:
Weekly - Every 1 week(s) on Tuesday
Recurrence ends:
End on Fri Jun 21, 2013, 10:40 AM CDT


Agenda: Yocto Project Technical Team Meeting - Tuesday, October 09, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

Liu, Song <song.liu@...>
 

Agenda:
 
* Opens collection - 5 min (Song)
* Yocto 1.3 status - 10 min (Song/team)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status
- Medium+ bugs review: https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&list_id=16013&priority=Medium%2B&query_format=advanced&target_milestone=1.3&target_milestone=1.3%20M1&target_milestone=1.3%20M2&target_milestone=1.3%20M3&target_milestone=1.3%20M4&target_milestone=1.3%20M5&target_milestone=1.3.1&target_milestone=1.3.2&order=assigned_to%20DESC%2Cpriority%2Cbug_status%20DESC%2Cbug_id&query_based_on=
* Yocto 1.4 feature open discussion - 10 min (team)
https://wiki.yoctoproject.org/wiki/Yocto_1.4_Features
* SWAT team rotation: Saul
* Opens - 10 min
* Team sharing - 20 min


-----Original Appointment-----



We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto
IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html

Conference details
Conference name:
Yocto Technical Team
Conference date/start time:
Tue Jun 26, 2012 at 10:00 AM Central Daylight Time
Participants:
30
Duration:
60 minutes
Participant passcode:
76994298
Dial-in number:
1.972.995.7777
US Toll Free number:
1.877.561.6828
BlackBerry users, click this link to join your conference as a participant:
1.972.995.7777x76994298#
 
Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode.

Local and Global Access Numbers


Country
Dial-in number
Australia:
1800 636 843
Czech Republic:
242 430 350
China (Beijing):
From office dial 8-9957777 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai):
From office dial 8-9957777 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen):
From office dial 8-9957777 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities):
From IP phone dial 8-9957777
Other cities - Non IP phone dial 021-23073322
Denmark:
8060 1400
Finland:
09 41333477
France:
0497 275888
Germany:
08161 803232
Holland:
030 2417490
India:
BSNL subscribers use 1800 425 9996 (Toll Free)
Airtel subscribers use 0008 009 861 212 (Toll Free)
From TI Campus use 89957777
Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel:
09 790 6715
Italy:
039 69061234 (039 is local city code not country code)
Japan:
From TI Campus use 8 995 7777
Outside TI use 03 4331 3777
Malaysia:
From IP phone dial 2643799
From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway:
2 295 8744
Philippines:
From Baguio City use 4471177
From Metro Manila area use 8702477
Singapore:
From IP phone dial 3894777
Outside TI use 6389 4777
South Korea:
From IP phone dial 5606998
From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden:
08 58755577
Taiwan:
From IP phone dial 1363
From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey:
Landline Only dial 0811 288 0001
then enter 877 633 1123
UK:
01604 663003
US:
972 995 7777 or 1877 561 6828

Recurring conferences
First scheduled conference:
Tue Jun 26, 2012
Recurrence frequency:
Weekly - Every 1 week(s) on Tuesday
Recurrence ends:
End on Fri Jun 21, 2013, 10:40 AM CDT


Re: Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel

Bodke, Kishore K <kishore.k.bodke@...>
 

-----Original Message-----
From: Chris Tapp [mailto:opensource@...]
Sent: Monday, October 08, 2012 1:03 PM
To: Bodke, Kishore K
Cc: Bruce Ashfield; yocto@... Project
Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the
kernel

On 8 Oct 2012, at 17:35, Bodke, Kishore K wrote:



-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Chris Tapp
Sent: Monday, October 08, 2012 12:59 AM
To: Bruce Ashfield
Cc: yocto@... Project
Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in
the
kernel

On 7 Oct 2012, at 22:41, Bruce Ashfield wrote:

On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp <opensource@...>
wrote:
On 7 Oct 2012, at 03:00, Saxena, Rahul wrote:

Try adding the unionfs feature (below) to your kernel:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-
3.0/tree/meta/cfg/kernel-cache/features/unionfs?h=meta

create a file my_cedartrail.scc with following line:
include features/unionfs/unionfs.scc

put this file in a dir linux-yocto, the dir being created in

meta-cedartrail/recipes-kernel/linux

add following line in meta-cedartrail/recipes-kernel/Linux/linux-
yocto_3.0.bbappend

SRC_URI +="file://my_cedartrail.scc"
Thanks - I thought just running 'menuconfig' would allow me to enable it
(for a quick test).

However, this still doesn't seem to be working. I can see that
'my_cedartrail.scc' gets fetched in to the build area, but I still don't see
CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in
fs/ of the build tree.

Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc)
I'm
not seeing any diagnostic.

unionfs was never merged to the 3.0 kernel, I re-added it to the
development
trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree at the moment). The
meta
data is carried forward from the older kernels as a placeholder and is
documented
in the .scc file itself:

-----------------------
kconf non-hardware unionfs.cfg

# commented pending update to a newer version ported to 2.6.35+
# patch unionfs-2.5.4-integration.patch
-----------------------

So to get unionfs in the 3.0 kernel, we'd need a port .. but since
we've moved on
quite a bit past 3.0, I don't know of any pending ports myself.
Thanks Bruce.

I guess I need to ask the Intel guys if there are any plans to move Cedartrail
on
from 3.0 ?
If the interest is to have unionfs, you can still get it from 3.2 or 3.4 Kernel.

But the downside is you will be missing the PVR Graphics and will be falling
back to the
basic vesa graphics mode.
Tricky. One of the reasons for specifying Cedartrail was the accelerated
graphics. However, I've got code running without acceleration and it looks like
it should be fast enough to do what I need without it.

PVR graphics has support only for 3.0 kernel only, so we had only put the 3.0
kernel recipe in the meta-intel.

We do not have plans to port PVR graphics to 3.4 kernel.
That's a pity, as this platform has a very good level of performance. I guess I'll
have to be patient and wait for Ivy Bridge graphics ;-)

We can update the Cedartrail BSP to have 3.2 and 3.4 kernel but it will be
vesa graphics support only.

How much work would this take? It looks like there is no unification FS support
in 3.0 that I could use instead, but this is only for a low-volume project and I
wouldn't like to think it was using resource that could be deployed more
effectively else where.

Thanks for your input on this - looks like I may need to revise my deployment
strategy for this project ;-)
For denzil, try with this by creating a new file in meta-cedartrail/recipes-kernel/linux/linux-yocto_3.2.bbappend.

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_cedartrail-nopvr = "git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
KMACHINE_cedartrail-nopvr = "cedartrail"
KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail"
KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"

SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= "8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c"
SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= "486f7aec824b4127e91ef53228823e996b3696f0"

Add these below lines to meta-cedartrail/conf/machine/cedartrail-nopvr.conf

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.2%"

Add MACHINE = "cedartrail-nopvr" to your local.conf and build.

Ofcourse you should be adding your unionfs related stuff by some means either by menuconfig or by creating .scc file.

Thanks
Kishore.


Re: Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel

Tom Zanussi <tom.zanussi@...>
 

On Mon, 2012-10-08 at 21:02 +0100, Chris Tapp wrote:
On 8 Oct 2012, at 17:35, Bodke, Kishore K wrote:



-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Chris Tapp
Sent: Monday, October 08, 2012 12:59 AM
To: Bruce Ashfield
Cc: yocto@... Project
Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the
kernel

On 7 Oct 2012, at 22:41, Bruce Ashfield wrote:

On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp <opensource@...>
wrote:
On 7 Oct 2012, at 03:00, Saxena, Rahul wrote:

Try adding the unionfs feature (below) to your kernel:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-
3.0/tree/meta/cfg/kernel-cache/features/unionfs?h=meta

create a file my_cedartrail.scc with following line:
include features/unionfs/unionfs.scc

put this file in a dir linux-yocto, the dir being created in

meta-cedartrail/recipes-kernel/linux

add following line in meta-cedartrail/recipes-kernel/Linux/linux-
yocto_3.0.bbappend

SRC_URI +="file://my_cedartrail.scc"
Thanks - I thought just running 'menuconfig' would allow me to enable it
(for a quick test).

However, this still doesn't seem to be working. I can see that
'my_cedartrail.scc' gets fetched in to the build area, but I still don't see
CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in
fs/ of the build tree.

Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc) I'm
not seeing any diagnostic.

unionfs was never merged to the 3.0 kernel, I re-added it to the
development
trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree at the moment). The
meta
data is carried forward from the older kernels as a placeholder and is
documented
in the .scc file itself:

-----------------------
kconf non-hardware unionfs.cfg

# commented pending update to a newer version ported to 2.6.35+
# patch unionfs-2.5.4-integration.patch
-----------------------

So to get unionfs in the 3.0 kernel, we'd need a port .. but since
we've moved on
quite a bit past 3.0, I don't know of any pending ports myself.
Thanks Bruce.

I guess I need to ask the Intel guys if there are any plans to move Cedartrail on
from 3.0 ?
If the interest is to have unionfs, you can still get it from 3.2 or 3.4 Kernel.

But the downside is you will be missing the PVR Graphics and will be falling back to the
basic vesa graphics mode.
Tricky. One of the reasons for specifying Cedartrail was the accelerated graphics. However, I've got code running without acceleration and it looks like it should be fast enough to do what I need without it.

PVR graphics has support only for 3.0 kernel only, so we had only put the 3.0 kernel recipe in the meta-intel.

We do not have plans to port PVR graphics to 3.4 kernel.
That's a pity, as this platform has a very good level of performance. I guess I'll have to be patient and wait for Ivy Bridge graphics ;-)
Another option would be to try to do the kernel work needed to move the
driver to a later kernel - we have a similar situation with EMGD, which
also typically lags by a few kernel versions, so we just go ahead and
fix up whatever needs fixing up for the later kernels in order to keep
it working as we uprev the kernels.

Since 3.0 is going away soon and there seems to be interest in Cedar
Trail, we should see what we can do to keep it alive with the pvr
graphics support going forward.

Tom

We can update the Cedartrail BSP to have 3.2 and 3.4 kernel but it will be vesa graphics support only.
How much work would this take? It looks like there is no unification FS support in 3.0 that I could use instead, but this is only for a low-volume project and I wouldn't like to think it was using resource that could be deployed more effectively else where.

Thanks for your input on this - looks like I may need to revise my deployment strategy for this project ;-)

Chris Tapp

opensource@...
www.keylevel.com



_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel

Chris Tapp
 

On 8 Oct 2012, at 17:35, Bodke, Kishore K wrote:



-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Chris Tapp
Sent: Monday, October 08, 2012 12:59 AM
To: Bruce Ashfield
Cc: yocto@... Project
Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the
kernel

On 7 Oct 2012, at 22:41, Bruce Ashfield wrote:

On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp <opensource@...>
wrote:
On 7 Oct 2012, at 03:00, Saxena, Rahul wrote:

Try adding the unionfs feature (below) to your kernel:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-
3.0/tree/meta/cfg/kernel-cache/features/unionfs?h=meta

create a file my_cedartrail.scc with following line:
include features/unionfs/unionfs.scc

put this file in a dir linux-yocto, the dir being created in

meta-cedartrail/recipes-kernel/linux

add following line in meta-cedartrail/recipes-kernel/Linux/linux-
yocto_3.0.bbappend

SRC_URI +="file://my_cedartrail.scc"
Thanks - I thought just running 'menuconfig' would allow me to enable it
(for a quick test).

However, this still doesn't seem to be working. I can see that
'my_cedartrail.scc' gets fetched in to the build area, but I still don't see
CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in
fs/ of the build tree.

Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc) I'm
not seeing any diagnostic.

unionfs was never merged to the 3.0 kernel, I re-added it to the
development
trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree at the moment). The
meta
data is carried forward from the older kernels as a placeholder and is
documented
in the .scc file itself:

-----------------------
kconf non-hardware unionfs.cfg

# commented pending update to a newer version ported to 2.6.35+
# patch unionfs-2.5.4-integration.patch
-----------------------

So to get unionfs in the 3.0 kernel, we'd need a port .. but since
we've moved on
quite a bit past 3.0, I don't know of any pending ports myself.
Thanks Bruce.

I guess I need to ask the Intel guys if there are any plans to move Cedartrail on
from 3.0 ?
If the interest is to have unionfs, you can still get it from 3.2 or 3.4 Kernel.

But the downside is you will be missing the PVR Graphics and will be falling back to the
basic vesa graphics mode.
Tricky. One of the reasons for specifying Cedartrail was the accelerated graphics. However, I've got code running without acceleration and it looks like it should be fast enough to do what I need without it.

PVR graphics has support only for 3.0 kernel only, so we had only put the 3.0 kernel recipe in the meta-intel.

We do not have plans to port PVR graphics to 3.4 kernel.
That's a pity, as this platform has a very good level of performance. I guess I'll have to be patient and wait for Ivy Bridge graphics ;-)

We can update the Cedartrail BSP to have 3.2 and 3.4 kernel but it will be vesa graphics support only.
How much work would this take? It looks like there is no unification FS support in 3.0 that I could use instead, but this is only for a low-volume project and I wouldn't like to think it was using resource that could be deployed more effectively else where.

Thanks for your input on this - looks like I may need to revise my deployment strategy for this project ;-)

Chris Tapp

opensource@...
www.keylevel.com


Re: [meta-ti] meta-gumstix proceedings

Denys Dmytriyenko
 

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


ww40 Yocto Project Bug Trend

Serban, Laurentiu <laurentiu.serban@...>
 

Hello guys,

 

The bug trend for Yocto Project for ww 40 is updated (https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend).

I also attached the excel file.

 

Best regards,

 

Laurentiu Serban

QA Engineer

Open Source Technology Center

System Software Division Romania

Desk: +40 31 8604742

iNET: 88451042

 


[PATCH 2/2] Move 'tag=' to SRCREV in mtd-utils recipe

Evade Flow <evadeflow@...>
 

Signed-off-by: Evade Flow <evadeflow@...>
---
meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb b/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
index 1a9d4d3..bdfb022 100644
--- a/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
+++ b/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
@@ -6,7 +6,8 @@ LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c"

-SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=ca39eb1d98e736109c64ff9c1aa2a6ecca222d8f \
+SRCREV = "ca39eb1d98e736109c64ff9c1aa2a6ecca222d8f"
+SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git \
file://add-exclusion-to-mkfs-jffs2-git-2.patch"

S = "${WORKDIR}/git/"
--
1.7.9.5


[PATCH 1/2] Move 'tag=' to SRCREV in btrfs-tools recipe

Evade Flow <evadeflow@...>
 

Signed-off-by: Evade Flow <evadeflow@...>
---
.../btrfs-tools/btrfs-tools_git.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
index c2ae298..e963a74 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
@@ -12,7 +12,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067"
SECTION = "base"
DEPENDS = "util-linux attr"

-SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git;protocol=git;tag=fdb6c0402337d9607c7a39155088eaf033742752;branch=master"
+SRCREV = "fdb6c0402337d9607c7a39155088eaf033742752"
+SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git;protocol=git"

S = "${WORKDIR}/git"

--
1.7.9.5


[PATCH 0/2] Move 'tag=' for a few SRC_URIs to SRCREV

Evade Flow <evadeflow@...>
 

Sending in response to:

- http://lists.yoctoproject.org/pipermail/yocto/2012-September/011802.html

Building with BB_NO_NETWORK can fail if recipes specify 'tag=' in
SRC_URI, since bitbake must contact the source repository to verify
which hash the tag currently points to. Since tags can, in principle,
change, current best practice is to omit 'tag=' from SRC_URIs and
instead specify the required revision hash in SRCREV.

SHA hashes *cannot* change, so they should not need to be checked, in
theory; however, bitbake currently has no mechanism for distinguishing
between human-friendly tags like 'v2.1.2' and SHA-1 sums like
'fdb6c0402337d9607c7a39155088eaf033742752': both will result in a call
to `git ls-remote` to verify the tag, which is problematic for
BB_NO_NETWORK builds.

The second part of this patch was, I think, already submitted, but not
yet applied to master[?]:

- http://lists.yoctoproject.org/pipermail/yocto/2012-September/011949.html


Evade Flow (2):
Move 'tag=' to SRCREV in btrfs-tools recipe
Move 'tag=' to SRCREV in mtd-utils recipe

.../btrfs-tools/btrfs-tools_git.bb | 3 ++-
meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)

--
1.7.9.5


Re: [yocto-docs][PATCH 00/11] Documentation improvements

Paul Eggleton
 

On Monday 08 October 2012 16:38:06 Paul Eggleton wrote:
Add some missing variables to the variable reference and improve
the descriptions of others. Also fix references to "package" where
we mean "recipe" and a couple of other issues I noticed at the same
time.


The following changes since commit 821162221818f5ce53bb903aeef57c85314f5083:

documentation: dev-manual - mentioned SRC_URI in the kernel example
(2012-10-05 11:25:03 -0700)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib paule/doc-fixes-5
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/doc-fixes-5

Paul Eggleton (11):
documentation: dev-manual: fix spelling
documentation: poky-ref-manual: correct LICENSE_DIR -> LICENSE_PATH
documentation: poky-ref-manual: improve MACHINE_* variable
descriptions
documentation: poky-ref-manual: extend description of MACHINE
variable
documentation: poky-ref-manual: add PACKAGECONFIG variable
documentation: poky-ref-manual: extend DISTRO description
documentation: poky-ref-manual: add information on
*_FEATURES_BACKFILL
documentation: poky-ref-manual: fix description of SUMMARY variable
documentation: poky-ref-manual: remove references to ipkg
documentation: poky-ref-manual: replace "package" with "recipe" where
appropriate
documentation: poky-ref-manual: update directory structure
information

documentation/dev-manual/dev-manual-newbie.xml | 2 +-
documentation/poky-ref-manual/faq.xml | 2 +-
documentation/poky-ref-manual/ref-features.xml | 46 ++++
documentation/poky-ref-manual/ref-structure.xml | 30 ++-
documentation/poky-ref-manual/ref-variables.xml | 267
+++++++++++++++-------- 5 files changed, 249 insertions(+), 98 deletions(-)
Apologies if 10/11 comes through twice, there was some kind of issue with
getting the original mail through to the mailing list server so I resent it.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre