Re: [yocto] [PATCH v2 1/2] kernel-dev: Fix the locations of .config and source directory

[Tom Zanussi]

ping

On 05/03/2016 11:28 AM, Tom Zanussi wrote:

The locations of the kernel .config file and source directory moved a
couple releases ago; update the documentation accordingly.

Also, add a note explaining how to expand variables, which serves a
couple of purposes:

   * For curious readers, shows them how to demystify where these
 variables come from and how they're used.
   * For suspicious readers, shows them how they can verify that the
 variables in the documentation are actually correct.

Fixes [YOCTO #9124].

Signed-off-by: Tom Zanussi 
---
  documentation/kernel-dev/kernel-dev-common.xml | 20 +++-
  1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/documentation/kernel-dev/kernel-dev-common.xml 
b/documentation/kernel-dev/kernel-dev-common.xml
index 261471c..5bd12be 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -384,9 +384,7 @@

  
  The resulting .config file is
-located in
-${WORKDIR}
 under the
-linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build directory.
+located in the build directory,  ${B}, which expands to ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build.
  You can use the entire .config file as 
the
  defconfig file as described in the
  "Changing the 
Configuration" section.
@@ -396,6 +394,19 @@
  section in the Yocto Project Development Manual.
  

+
+  If you're ever confused about what a variable expands
+  to, you can determine that unequivocally by looking at
+  the output of the bitbake -e command:
+
+ 
+ $ bitbake -e virtual/kernel
+  
+
+ Search the output for the variable you're interested in
+ and you can see exactly how it's expanded and used.
+
+
  
  A better method is to create a configuration fragment using 
the
  differences between two configuration files: one previously
@@ -512,8 +523,7 @@
  
  Taking this step ensures you have the sources prepared
  and the configuration completed.
-You can find the sources in the
-${WORKDIR}/linux
 directory.
+You can find the sources in the symlinked source/ directory just off the build directory, in other words ${B}/source, which expands to 
${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build/source.  The directory pointed to by the 
source/ symlink is also known as ${STAGING_KERNEL_DIR}
  

  



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

Re: [yocto] Yocto Hands-on Kernel Lab now available for Yocto 2.1 (krogoth)

[Tom Zanussi]

It seems a last-minute update broke the link I used.  Please try this 
instead:


https://www.yoctoproject.org/sites/default/files/kernel-lab-2.1_0.pdf

Thanks,

Tom

On 05/04/2016 02:56 PM, Tom Zanussi wrote:

Hi,

I'm happy to announce that an updated version of the Yocto 'Hands-on
Kernel Lab' has been released and is available here:

   https://www.yoctoproject.org/sites/default/files/kernel-lab-2.1.pdf

The above document contains all the instructions you need to get started
from scratch.

You can get to the lab and associated content by visiting the Yocto home
page (https://www.yoctoproject.org/) and selecting 'Obtain training on
your own or at an event' from the drop-down list you get by clicking on
the 'START HERE TO LEARN MORE' box on the left-hand side and clicking on
the 'Hands-on Kernel Lab for TP 2.1 krogoth' link.

The 'Hands-on Kernel Lab' has been updated to Yocto 2.1 ('krogoth') and
a couple of new sections have been added.

See below for a complete list of what's covered along with the lab
number covering those topics.

I've run through the lab twice, once on Fedora 20 and once on Ubuntu
16.04, so it should be pretty solid at this point, but if you find
problems, please let me know...

Thanks,

Tom



The 'Hands-on Kernel Lab' is a series of labs that covers the following
topics:

   * Creating and using a traditional kernel recipe (lab1)

   * Using 'bitbake -c menuconfig' to modify the kernel configuration
and replace the defconfig with the new configuration (lab1)

   * Adding a kernel module to the kernel source and configuring it as a
built-in module by adding options to the kernel defconfig (lab1)

   * Creating and using a linux-yocto-based kernel (lab2)

   * Adding a kernel module to the kernel source and configuring it as a
built-in module using linux-yocto 'config fragments' (lab2)

   * Using the linux-yocto kernel as an LTSI kernel (configuring in an
item added by the LTSI kernel which is merged into linux-yocto) (lab2)

   * Using an arbitrary git-based kernel via the linux-yocto-custom
kernel recipe (lab3)

   * Adding a kernel module to the kernel source of an arbitrary
git-based kernel and configuring it as a loadable module using 'config
fragments' (lab3)

   * Actually getting the module into the image and autoloading it on
boot (lab3)

   * Using a local clone of an arbitrary git-based kernel via the
linux-yocto custom kernel recipe to demonstrate a typical development
workflow (lab4)

   * Modifying the locally cloned custom kernel source and verifying the
changes in the new image (lab4)

   * Using a local clone of a linux-yocto kernel recipe to demonstrate a
typical development workflow (lab4)

   * Adding and using an external kernel module via a module recipe (lab4)

   * Using the 'Yocto BSP Tools' yocto-bsp tool generate a new Yocto BSP
(lab5)

   * Using the 'Yocto BSP Tools' yocto-kernel tool to add kernel config
fragments (lab5)

   * Using the 'Yocto BSP Tools' yocto-kernel tool to add kernel patches
(lab5)


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

[yocto] Yocto Hands-on Kernel Lab now available for Yocto 2.1 (krogoth)

[Tom Zanussi]

Hi,

I'm happy to announce that an updated version of the Yocto 'Hands-on 
Kernel Lab' has been released and is available here:


  https://www.yoctoproject.org/sites/default/files/kernel-lab-2.1.pdf

The above document contains all the instructions you need to get started 
from scratch.


You can get to the lab and associated content by visiting the Yocto home 
page (https://www.yoctoproject.org/) and selecting 'Obtain training on 
your own or at an event' from the drop-down list you get by clicking on 
the 'START HERE TO LEARN MORE' box on the left-hand side and clicking on 
the 'Hands-on Kernel Lab for TP 2.1 krogoth' link.


The 'Hands-on Kernel Lab' has been updated to Yocto 2.1 ('krogoth') and 
a couple of new sections have been added.


See below for a complete list of what's covered along with the lab 
number covering those topics.


I've run through the lab twice, once on Fedora 20 and once on Ubuntu 
16.04, so it should be pretty solid at this point, but if you find 
problems, please let me know...


Thanks,

Tom



The 'Hands-on Kernel Lab' is a series of labs that covers the following 
topics:


  * Creating and using a traditional kernel recipe (lab1)

  * Using 'bitbake -c menuconfig' to modify the kernel configuration 
and replace the defconfig with the new configuration (lab1)


  * Adding a kernel module to the kernel source and configuring it as a 
built-in module by adding options to the kernel defconfig (lab1)


  * Creating and using a linux-yocto-based kernel (lab2)

  * Adding a kernel module to the kernel source and configuring it as a 
built-in module using linux-yocto 'config fragments' (lab2)


  * Using the linux-yocto kernel as an LTSI kernel (configuring in an 
item added by the LTSI kernel which is merged into linux-yocto) (lab2)


  * Using an arbitrary git-based kernel via the linux-yocto-custom 
kernel recipe (lab3)


  * Adding a kernel module to the kernel source of an arbitrary 
git-based kernel and configuring it as a loadable module using 'config 
fragments' (lab3)


  * Actually getting the module into the image and autoloading it on 
boot (lab3)


  * Using a local clone of an arbitrary git-based kernel via the 
linux-yocto custom kernel recipe to demonstrate a typical development 
workflow (lab4)


  * Modifying the locally cloned custom kernel source and verifying the 
changes in the new image (lab4)


  * Using a local clone of a linux-yocto kernel recipe to demonstrate a 
typical development workflow (lab4)


  * Adding and using an external kernel module via a module recipe (lab4)

  * Using the 'Yocto BSP Tools' yocto-bsp tool generate a new Yocto BSP 
(lab5)


  * Using the 'Yocto BSP Tools' yocto-kernel tool to add kernel config 
fragments (lab5)


  * Using the 'Yocto BSP Tools' yocto-kernel tool to add kernel patches 
(lab5)

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

[yocto] [PATCH 0/2] kernel-dev manual fixes, V2

[Tom Zanussi]

This is a fix for Yocto bug 9124, against yocto-docs/master.

V2: Fix a typo in the commit message and update README update, as the
cc: to the maintainer listed there bounced.

The following changes since commit 0b9ee8da66ff81e0724465f18b0323f1216cb9fa:

  ref-manual: Added GObject Introspection to 2.1 migration section. (2016-04-20 
07:27:43 -0700)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib tzanussi/kernel-dev-manual-fixes
  
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/kernel-dev-manual-fixes

Tom Zanussi (2):
  kernel-dev: Fix the locations of .config and source directory
  README: Add correct email for Yocto documentation maintainer

 README |  2 +-
 documentation/kernel-dev/kernel-dev-common.xml | 20 +++-
 2 files changed, 16 insertions(+), 6 deletions(-)

-- 
1.9.3

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

[yocto] [PATCH v2 2/2] README: Add correct email for Yocto documentation maintainer

[Tom Zanussi]

The e-mail address the top-level README says to cc: is no longer
valid; replace it with the same e-mail address found elsewhere in the
repo.

Signed-off-by: Tom Zanussi 
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 4c3b257..bcd68c1 100644
--- a/README
+++ b/README
@@ -12,4 +12,4 @@ Where to Send Patches
 
 Git repository: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/
 Mailing list: yocto@yoctoproject.org
-Please cc: Scott Rifenbark  on changes.
+Please cc: Scott Rifenbark  on changes.
-- 
1.9.3

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

[yocto] [PATCH v2 1/2] kernel-dev: Fix the locations of .config and source directory

[Tom Zanussi]

The locations of the kernel .config file and source directory moved a
couple releases ago; update the documentation accordingly.

Also, add a note explaining how to expand variables, which serves a
couple of purposes:

  * For curious readers, shows them how to demystify where these
variables come from and how they're used.
  * For suspicious readers, shows them how they can verify that the
variables in the documentation are actually correct.

Fixes [YOCTO #9124].

Signed-off-by: Tom Zanussi 
---
 documentation/kernel-dev/kernel-dev-common.xml | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/documentation/kernel-dev/kernel-dev-common.xml 
b/documentation/kernel-dev/kernel-dev-common.xml
index 261471c..5bd12be 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -384,9 +384,7 @@
 
 
 The resulting .config file is
-located in
-${WORKDIR}
 under the
-linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build
 directory.
+located in the build directory,  ${B},
 which expands to ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build.
 You can use the entire .config file as the
 defconfig file as described in the
 "Changing the 
Configuration" section.
@@ -396,6 +394,19 @@
 section in the Yocto Project Development Manual.
 
 
+
+  If you're ever confused about what a variable expands
+  to, you can determine that unequivocally by looking at
+  the output of the bitbake -e command:
+
+ 
+ $ bitbake -e virtual/kernel
+  
+
+ Search the output for the variable you're interested in
+ and you can see exactly how it's expanded and used.
+
+
 
 A better method is to create a configuration fragment using the
 differences between two configuration files: one previously
@@ -512,8 +523,7 @@
 
 Taking this step ensures you have the sources prepared
 and the configuration completed.
-You can find the sources in the
-${WORKDIR}/linux
 directory.
+You can find the sources in the symlinked 
source/ directory just off the build directory, in other 
words ${B}/source,
 which expands to ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build/source.
  The directory pointed to by the source/ symlink is also 
known as ${STAGING_KERNEL_DIR}
 
 
 
-- 
1.9.3

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

[yocto] [PATCH 1/1] kernel-dev: Fix the locations of .config and source directory

[Tom Zanussi]

The locations of the kernel .config file and source directory moved a
couple releases ago; update the documentation accordingly.

Also, add a note explaining how to expand variables, which serves a
couple of purposes:

  * For curious readers, shows them how to demystify where these
variables come from and how their used.
  * For suspicious readers, shows them how they can verify that the
variables in the documentation are actually correct.

Fixes [YOCTO #9124].

Signed-off-by: Tom Zanussi 
---
 documentation/kernel-dev/kernel-dev-common.xml | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/documentation/kernel-dev/kernel-dev-common.xml 
b/documentation/kernel-dev/kernel-dev-common.xml
index 261471c..5bd12be 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -384,9 +384,7 @@
 
 
 The resulting .config file is
-located in
-${WORKDIR}
 under the
-linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build
 directory.
+located in the build directory,  ${B},
 which expands to ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build.
 You can use the entire .config file as the
 defconfig file as described in the
 "Changing the 
Configuration" section.
@@ -396,6 +394,19 @@
 section in the Yocto Project Development Manual.
 
 
+
+  If you're ever confused about what a variable expands
+  to, you can determine that unequivocally by looking at
+  the output of the bitbake -e command:
+
+ 
+ $ bitbake -e virtual/kernel
+  
+
+ Search the output for the variable you're interested in
+ and you can see exactly how it's expanded and used.
+
+
 
 A better method is to create a configuration fragment using the
 differences between two configuration files: one previously
@@ -512,8 +523,7 @@
 
 Taking this step ensures you have the sources prepared
 and the configuration completed.
-You can find the sources in the
-${WORKDIR}/linux
 directory.
+You can find the sources in the symlinked 
source/ directory just off the build directory, in other 
words ${B}/source,
 which expands to ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build/source.
  The directory pointed to by the source/ symlink is also 
known as ${STAGING_KERNEL_DIR}
 
 
 
-- 
1.9.3

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

[yocto] [PATCH 0/1] kernel-dev manual fix

[Tom Zanussi]

This is a fix for Yocto bug 9124, against yocto-docs/master.

The following changes since commit 0b9ee8da66ff81e0724465f18b0323f1216cb9fa:

  ref-manual: Added GObject Introspection to 2.1 migration section. (2016-04-20 
07:27:43 -0700)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib tzanussi/kernel-dev-manual-fixes
  
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/kernel-dev-manual-fixes

Tom Zanussi (1):
  kernel-dev: Fix the locations of .config and source directory

 documentation/kernel-dev/kernel-dev-common.xml | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

-- 
1.9.3

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

Re: [yocto] Intel BSP for Rangeley

[Tom Zanussi]

On Tue, 2015-03-10 at 12:45 +0800, Albert K wrote:
> Dear all,
> 
> May I know which BSP to use for Intel Atom C2000 Rangeley?  I do not
> see that Intel BSP has the mohon peak bsp.  I am trying out the Dizzy
> 1.7 branch.  Thanks.
> 

There is a BSP for mohon peak in the meta-intel/dizzy branch:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/meta-isg/meta-mohonpeak?h=dizzy

Tom

> Regards,
> Albert.


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

Re: [yocto] separate partition support

[Tom Zanussi]

Hi,

As far as wic goes, I think this is something that should be supported,
and probably wouldn't be too hard to implement, but I really haven't
thought about the details much.  Off the top of my head, I think it
would mainly require some changes to the Wic_PartData and rootfs plugin
and an extension to the rootfs syntax - possibly just appending the
directory within the rootfs to the rootfs plugin e.g.:  

part / --source rootfs --ondisk sda --fstype=ext3 --label platform --align 1024
part /var --source rootfs/var --ondisk sda --fstype=ext3 --label data --align 
1024

The second line would cause just the contents of the /var directory of
rootfs to be put into a separate partition and mounted as /var.

One complication would be then subtracting that from the rootfs and
leaving just the remainder mounted as / - it would probably require a
copy and subtraction.

Tom

On Tue, 2015-01-06 at 15:05 +, Moore, Thomas (FtWorth) wrote:
> Andre,
> 
>  
> 
> I spent some time trying to determine how to generate multiple images
> as you’ve mentioned. However, the process used to generate the rootfs
> image appears to be buried deep in the Open Embedded core and I wasn’t
> able to figure out how it works. Maybe someone else can chime in on
> how that might be accomplished.
> 
>  
> 
> Thomas Moore
> 
> 
>  
> 
> From: Andre Marschalek [mailto:andre.marscha...@outlook.com] 
> Sent: Tuesday, January 06, 2015 8:34 AM
> To: Moore, Thomas (FtWorth); yocto@yoctoproject.org
> Subject: RE: [yocto] separate partition support
> 
> 
>  
> 
> Hi Thomas,
> 
>  
> 
> what I need is to have one image per partition
> 
>  
> 
> for example if i need to have /opt on a different partition i would
> need 2 image files at the end
> 
>  
> 
> one containing the root partition but without /opt and one with the
> contents of /opt (without /opt itself because this image will be
> mounted as /opt at the end)
> 
>  
> 
> br
> 
> Andre
> 
>  
> 
> From: Moore, Thomas (FtWorth) [mailto:thomas.moo...@atk.com] 
> Sent: Tuesday, January 6, 2015 1:01 AM
> To: Andre Marschalek; yocto@yoctoproject.org
> Subject: RE: [yocto] separate partition support
> 
> 
>  
> 
> I’m actually experimenting with this today.
> 
>  
> 
> Per the Development Manual, my first attempt was to use wic. While I
> was able to create an image with multiple partitions, there appears to
> be no way to split up the rootfs image that is created amongst the
> multiple partitions. Below is the wks file I created for my test:
> 
>  
> 
> part /boot --source bootimg-pcbios --ondisk sda --label boot --active
> --align 1024
> 
> part / --source rootfs --ondisk sda --fstype=ext3 --label platform
> --align 1024
> 
> part /var --source rootfs --ondisk sda --fstype=ext3 --label data
> --align 1024
> 
>  
> 
> bootloader  --timeout=0  --append="rootwait rootfstype=ext3
> video=vesafb vga=0x318 console=tty0"
> 
>  
> 
> After running wic, I was able to examine the resulting image and there
> were three partitions. However, the second and third partitions (/
> and /var) both contained the entire rootfs. In this case, I was hoping
> that wic would realize that I only wanted the contents /var in the
> third partition and to also not be included in the second partition.
> 
>  
> 
> While it may be possible to create a new plugin for wic to achieve my
> desired result, I’m not sure if it would be possible for the instance
> of the plugin creating the / partition to be aware of the other
> partitions and their mount points to be able to exclude those folders
> from the / partition. Does anyone have any thoughts on this?
> 
>  
> 
> Thanks,
> 
>  
> 
> Thomas Moore
> 
> 
>  
> 
> From:yocto-boun...@yoctoproject.org
> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Andre Marschalek
> Sent: Monday, January 05, 2015 5:50 PM
> To: yocto@yoctoproject.org
> Subject: [yocto] separate partition support
> 
> 
>  
> 
> hi,
> 
>  
> 
> splitting the root file filesystem into different partitions is a
> common task and supported from every operating system during install
> and should be also supported from yocto’s build system
> 
> based on the current available documentation it seems impossible to
> accomplish this task, the only available result is one full blown
> image containing the root partition
> 
>  
> 
> currently the only idea i had is to run bitbake which will generate
> the root image containing everything
> 
> create afterwards my own images with the desired size (also a new root
> image because in this case IMAGE_ROOTFS_SIZE does not reflect the
> ending image size)
> 
> mount every image and move the directories from the bitbake produced
> image into this new images
> 
> and finally flash that images to my devices
> 
>  
> 
> what do you mean?
> 
> should this basic core functionality part of yocto’s build process
> without an overhead for everyone to create isolated solutions?
> 
> do you see a better workaround as to create new images and movements
> after the build process?
> 
>  
> 
>

Re: [yocto] BSP guide refers to meta-fri2 as example for binary/ data, it has none

[Tom Zanussi]

On Mon, 2015-01-05 at 21:44 +, Rifenbark, Scott M wrote:
> 
> >-Original Message-
> >From: yocto-boun...@yoctoproject.org [mailto:yocto-
> >boun...@yoctoproject.org] On Behalf Of Robert P. J. Day
> >Sent: Tuesday, December 30, 2014 10:20 AM
> >To: Yocto discussion list
> >Subject: [yocto] BSP guide refers to meta-fri2 as example for binary/ data, 
> >it
> >has none
> >
> >
> >  in sec 1.3.1 of BSP guide, there is an explanation of the README.sources 
> > file.
> >first, the text suggests that file is mandatory:
> >
> >"You must include a README.sources in the meta-bsp_name directory."
> 
> I understood that for a released BSP to be considered Yocto-compliant, the 
> README.sources files is a requirement.
> >

Right, README.sources refers to the sources used to generate the
binaries in a released BSP e.g. the release tarballs on the Yocto BSP
Downloads page(s).

> >however, as i read it, it's really only necessary when a layer provides some
> >binary content in the binary/ subdirectory. the guide then goes on to claim
> >that the meta-fri2 layer does just that, but i see no binary content in that 
> >layer
> >-- in fact, none of the meta-intel sublayers appear to come with binary
> >content. so perhaps that part of the guide can be updated to refer to an
> >appropriate layer.
> 
> The wording here does imply that the sources are the ones used to
> generate the images that would be in the "binary/" directory.  Can
> someone tell me if it would be more accurate to state that the
> README.sources file simply indicates where the sources to build the
> BSP are period... regardless of whether or not any binaries are
> included in that directory?  Knowing that would help me make sure this
> section is not mis-leading.  Also, knowing that would help me choose
> an appropriate example to point to for the README.sources file.
> 

No. the README.sources indicate what was actually used to build the
images, which can and do contain much more than what is specified by the
recipes in the BSP layer.

So README.sources is meaningless if there are no binaries in /binary,
and the layer itself may have no /binary directory or README.sources
until a tarball is generated for release, which generation might be done
by the release process instead.

Again, this all refers to released BSPs, and if e.g. meta-fri2 doesn't
have these in the meta-intel git repo, any meta-fri2 released BSP
certainly does.

hth,

Tom

 

> >
> >rday
> >
> >--
> >
> >===
> >=
> >Robert P. J. Day Ottawa, Ontario, CANADA
> >http://crashcourse.ca
> >
> >Twitter:   http://twitter.com/rpjday
> >LinkedIn:   http://ca.linkedin.com/in/rpjday
> >===
> >=
> >--
> >___
> >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] [PATCH 2/2] yocto-bsp: Add mips64 support

[Tom Zanussi]

mips64 support was recently added to the core BSPs; we should also
support it in yocto-bsp.  [YOCTO #5314]

Signed-off-by: Tom Zanussi 
---
 scripts/lib/bsp/help.py|  1 +
 .../bsp/substrate/target/arch/mips64/.gitignore|  0
 .../arch/mips64/conf/machine/{{=machine}}.conf | 38 +
 .../recipes-kernel/linux/kernel-list.noinstall |  5 ++
 .../{{=machine}}-preempt-rt.scc"   |  9 +++
 .../{{=machine}}-standard.scc" |  9 +++
 .../{{=machine}}-tiny.scc" |  9 +++
 .../{{=machine}}-user-config.cfg"  |  0
 .../{{=machine}}-user-features.scc"|  0
 .../{{=machine}}-user-patches.scc" |  0
 .../{{=machine}}.cfg"  | 65 ++
 .../{{=machine}}.scc"  |  7 +++
 ...linux-yocto-dev\": }} linux-yocto-dev.bbappend" | 25 +
 ...cto-rt_3.10\": }} linux-yocto-rt_3.10.bbappend" | 32 +++
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +++
 ...tiny_3.10\": }} linux-yocto-tiny_3.10.bbappend" | 32 +++
 ...tiny_3.14\": }} linux-yocto-tiny_3.14.bbappend" | 32 +++
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +++
 ...nux-yocto_3.10\": }} linux-yocto_3.10.bbappend" | 32 +++
 ...nux-yocto_3.14\": }} linux-yocto_3.14.bbappend" | 32 +++
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +++
 .../arch/qemu/conf/machine/{{=machine}}.conf   |  6 +-
 .../xserver-xf86-config/{{=machine}}/xorg.conf |  4 +-
 .../{{=machine}}-standard.scc" |  2 +
 ...linux-yocto-dev\": }} linux-yocto-dev.bbappend" |  6 ++
 ...cto-rt_3.10\": }} linux-yocto-rt_3.10.bbappend" |  6 ++
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" |  6 ++
 ...tiny_3.10\": }} linux-yocto-tiny_3.10.bbappend" |  6 ++
 ...-tiny_3.14\": }} linux-yocto-tiny_3.4.bbappend" |  6 ++
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" |  6 ++
 ...nux-yocto_3.10\": }} linux-yocto_3.10.bbappend" |  6 ++
 ...nux-yocto_3.14\": }} linux-yocto_3.14.bbappend" |  6 ++
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 10 +++-
 33 files changed, 489 insertions(+), 5 deletions(-)
 create mode 100644 scripts/lib/bsp/substrate/target/arch/mips64/.gitignore
 create mode 100644 
scripts/lib/bsp/substrate/target/arch/mips64/conf/machine/{{=machine}}.conf
 create mode 100644 
scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/kernel-list.noinstall
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice != \"custom\": }} files/{{=machine}}-preempt-rt.scc"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice != \"custom\": }} files/{{=machine}}-standard.scc"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice != \"custom\": }} files/{{=machine}}-tiny.scc"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice != \"custom\": }} files/{{=machine}}-user-config.cfg"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice != \"custom\": }} files/{{=machine}}-user-features.scc"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice != \"custom\": }} files/{{=machine}}-user-patches.scc"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice != \"custom\": }} files/{{=machine}}.cfg"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice != \"custom\": }} files/{{=machine}}.scc"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-dev\": }} linux-yocto-dev.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.10\": }} linux-yocto-rt_3.10.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-tiny_3.10\": }} linux-yocto-tiny_3.10.bbappend"
 create mode 100644 
&quo

[yocto] [PATCH 1/2] yocto-bsp: Update templates to 3.17 kernel

[Tom Zanussi]

Add 3.17 kernel support.

Signed-off-by: Tom Zanussi 
---
 .../target/arch/arm/conf/machine/{{=machine}}.conf | 24 --
 .../arm/recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +
 .../recipes-kernel/linux/kernel-list.noinstall |  8 ++--
 .../arch/i386/conf/machine/{{=machine}}.conf   | 20 ++--
 .../recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +
 .../recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +
 .../arch/powerpc/conf/machine/{{=machine}}.conf| 12 +
 .../recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +
 .../recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...linux-yocto-dev\": }} linux-yocto-dev.bbappend" |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 55 ++
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 55 ++
 ...nux-yocto_3.10\": }} linux-yocto_3.10.bbappend" |  4 +-
 ...nux-yocto_3.14\": }} linux-yocto_3.14.bbappend" |  4 +-
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 55 ++
 .../arch/x86_64/conf/machine/{{=machine}}.conf | 10 +++-
 .../recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +
 32 files changed, 713 insertions(+), 42 deletions(-)
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.17\": }} linux-yocto_3.17.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.17\": }} linux-yocto_3.17.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.17\": }} linux-yocto_3.17.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto_3.17\": }} linux-yocto_3.17.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/{{ if 
kernel_choice == \"linux-yocto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend"
 create mode 100644 
"scripts/lib/bsp/substrate/target/arch/qe

[yocto] [PATCH 0/2] yocto-bsp 3.17 updates

[Tom Zanussi]

This is the yocto-bsp 3.17 update, along with new mips64 support
addressing [YOCTO #5314].

This is currently gated on the qemu and yocto-bsp machines moving to
3.17, which is in turn still currently gated on [YOCTO #6810], but I'm
submitting what I have now for that eventuality and so that I can
continue with further yocto-bsp work that needs to go on top if this.

The following changes since commit 0bc03af7ee6112fa0af0608b02f715ec8495e4ff:

  maintainers.inc: update maintainers (2014-11-26 17:06:10 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib.git 
tzanussi/yocto-bsp-3.17-master-updates
  
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/yocto-bsp-3.17-master-updates

Tom Zanussi (2):
  yocto-bsp: Update templates to 3.17 kernel
  yocto-bsp: Add mips64 support

 scripts/lib/bsp/help.py|  1 +
 .../target/arch/arm/conf/machine/{{=machine}}.conf | 24 
 .../arm/recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +++
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +++
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +++
 .../recipes-kernel/linux/kernel-list.noinstall |  8 +--
 .../arch/i386/conf/machine/{{=machine}}.conf   | 20 +--
 .../recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +++
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +++
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +++
 .../recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +++
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +++
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +++
 .../bsp/substrate/target/arch/mips64/.gitignore|  0
 .../arch/mips64/conf/machine/{{=machine}}.conf | 38 +
 .../recipes-kernel/linux/kernel-list.noinstall |  5 ++
 .../{{=machine}}-preempt-rt.scc"   |  9 +++
 .../{{=machine}}-standard.scc" |  9 +++
 .../{{=machine}}-tiny.scc" |  9 +++
 .../{{=machine}}-user-config.cfg"  |  0
 .../{{=machine}}-user-features.scc"|  0
 .../{{=machine}}-user-patches.scc" |  0
 .../{{=machine}}.cfg"  | 65 ++
 .../{{=machine}}.scc"  |  7 +++
 ...linux-yocto-dev\": }} linux-yocto-dev.bbappend" | 25 +
 ...cto-rt_3.10\": }} linux-yocto-rt_3.10.bbappend" | 32 +++
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +++
 ...tiny_3.10\": }} linux-yocto-tiny_3.10.bbappend" | 32 +++
 ...tiny_3.14\": }} linux-yocto-tiny_3.14.bbappend" | 32 +++
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +++
 ...nux-yocto_3.10\": }} linux-yocto_3.10.bbappend" | 32 +++
 ...nux-yocto_3.14\": }} linux-yocto_3.14.bbappend" | 32 +++
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +++
 .../arch/powerpc/conf/machine/{{=machine}}.conf| 12 
 .../recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +++
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +++
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 32 +++
 .../arch/qemu/conf/machine/{{=machine}}.conf   |  6 +-
 .../xserver-xf86-config/{{=machine}}/xorg.conf |  4 +-
 .../recipes-kernel/linux/kernel-list.noinstall |  4 +-
 .../{{=machine}}-standard.scc" |  2 +
 ...linux-yocto-dev\": }} linux-yocto-dev.bbappend" | 10 +++-
 ...cto-rt_3.10\": }} linux-yocto-rt_3.10.bbappend" |  6 ++
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 61 
 ...tiny_3.10\": }} linux-yocto-tiny_3.10.bbappend" |  6 ++
 ...-tiny_3.14\": }} linux-yocto-tiny_3.4.bbappend" |  6 ++
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 61 
 ...nux-yocto_3.10\": }} linux-yocto_3.10.bbappend" | 10 +++-
 ...nux-yocto_3.14\": }} linux-yocto_3.14.bbappend" | 10 +++-
 ...nux-yocto_3.17\": }} linux-yocto_3.17.bbappend" | 61 
 .../arch/x86_64/conf/machine/{{=machine}}.conf | 10 +++-
 .../recipes-kernel/linux/kernel-list.noinstall |  4 +-
 ...cto-rt_3.14\": }} linux-yocto-rt_3.14.bbappend" | 32 +++
 ...tiny_3.17\": }} linux-yocto-tiny_3.17.bbappend" | 32 +++
 ...n

Re: [yocto] Running "yocto-bsp create .." in the source directory(poky) brings up an error. "poky directory vs build directory"

[Tom Zanussi]

On Mon, 2014-11-24 at 07:07 -0600, Rifenbark, Scott M wrote:
> Hi ,
> 
>  
> 
> Although that sentence could be written differently, it is correct.
> Step six of the example says “By default, the script creates the new
> BSP Layer in the current working directory of the Source Directory,
> which is poky in this case.”  The clause at the end of the sentence is

Yes, it's ambiguous as to what 'which is poky' refers to.  I think that
just changing it to 'in the current working directory (poky/build in
this case)' is most clear (your revision seems to still have some
ambiguity, I think).

Tom

>  tied to the “Source Directory”, which in fact is poky.  I will
> re-write that sentence though to remove any chance of confusion.  You
> can see the change at
> http://www.yoctoproject.org/docs/1.7/bsp-guide/bsp-guide.html#creating-a-new-bsp-layer-using-the-yocto-bsp-script.
> 
>  
> 
> Thanks, 
> 
> Scott
> 
>  
> 
> From: yocto-boun...@yoctoproject.org
> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Biao
> Sent: Sunday, November 23, 2014 8:35 PM
> To: Zanussi, Tom
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Running "yocto-bsp create .." in the source
> directory(poky) brings up an error. "poky directory vs build
> directory"
> 
> 
>  
> 
> 
> At 2014-11-24 03:23:10, "Tom Zanussi"  wrote:
> >Hi,
> > 
> >On Sun, 2014-11-23 at 22:55 +0800, Biao wrote:
> >> Hi all,
> >> I am doing excises following this section
> >> --
> >> http://www.yoctoproject.org/docs/1.7/bsp-guide/bsp-guide.html#creating-a-new-bsp-layer-using-the-yocto-bsp-script
> >> 1.6.2. Creating a new BSP Layer Using the yocto-bsp Script
> >> ...
> >>  $ yocto-bsp create myarm qemu
> >> 
> >> By default, the script creates the new BSP Layer in the current
> >> working directory of the  Source Directory , which is  poky  in this
> >> case. 
> >> 
> >> -
> >> To my understand, it means after "source oe-init-build-env mybuild", i
> >> should change to the poky directory to run the "yocto-bsp create ..."
> >> command,
> > 
> >Yes, the documentation is misleading - yocto-bsp assumes you're in the
> >build directory after you've sourced oe-init-build-env, and not the poky
> >dir.
> > 
> >Tom
>  
> I see, thanks for you help, Tom.
>  
> Jerry
> > 
> >> however, i got an error  
> >> " Do you need a new machine branch for this BSP (the alternative is to
> >> re-use an existing branch)? [y/n] [default: y] 
> >> The BBPATH variable is not set and bitbake did not find a
> >> conf/bblayers.conf file in the expected location.
> >> Maybe you accidentally invoked bitbake from the wrong directory?
> >> Couldn't find BBLAYERS in bitbake -e output, exiting." 
> >> It seems it is asking me to run "yocto-bsp create ..." in the build
> >> directory
> >> 
> >> 
> >> Which one is correct? Do we have a wrong document?
> >> 
> >> 
> >> Thanks,
> >> Jerry 
> >> 
> >> 
> > 
> > 


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

Re: [yocto] Running "yocto-bsp create .." in the source directory(poky) brings up an error. "poky directory vs build directory"

[Tom Zanussi]

Hi,

On Sun, 2014-11-23 at 22:55 +0800, Biao wrote:
> Hi all,
> I am doing excises following this section
> --
> http://www.yoctoproject.org/docs/1.7/bsp-guide/bsp-guide.html#creating-a-new-bsp-layer-using-the-yocto-bsp-script
> 1.6.2. Creating a new BSP Layer Using the yocto-bsp Script
> ...
>  $ yocto-bsp create myarm qemu
> 
> By default, the script creates the new BSP Layer in the current
> working directory of the  Source Directory , which is  poky  in this
> case. 
> 
> -
> To my understand, it means after "source oe-init-build-env mybuild", i
> should change to the poky directory to run the "yocto-bsp create ..."
> command,

Yes, the documentation is misleading - yocto-bsp assumes you're in the
build directory after you've sourced oe-init-build-env, and not the poky
dir.

Tom

> however, i got an error  
> " Do you need a new machine branch for this BSP (the alternative is to
> re-use an existing branch)? [y/n] [default: y] 
> The BBPATH variable is not set and bitbake did not find a
> conf/bblayers.conf file in the expected location.
> Maybe you accidentally invoked bitbake from the wrong directory?
> Couldn't find BBLAYERS in bitbake -e output, exiting." 
> It seems it is asking me to run "yocto-bsp create ..." in the build
> directory
> 
> 
> Which one is correct? Do we have a wrong document?
> 
> 
> Thanks,
> Jerry 
> 
> 


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

Re: [yocto] Packages util-linux and gettext both showing undefined reference

[Tom Zanussi]

On Mon, 2014-09-22 at 19:19 +, Summers, John S wrote:
> Hi Darren,
> 
> Maybe I should elaborate a bit on what I am trying to do.  Basically,
> I am trying to develop an embedded EFI-bootable image using the
> poky-tiny distro.
> 
> I would like to be able to automate the image generation process, so
> I've been using the "wic" tool to generate the image.  Wic has been
> working great (at least it works fine with manual parameters, the -e
> argument results in a failure as described at
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6704&list_id=cookie), but 
> it appears that the initramfs image is not being generated properly, 
> resulting in a kernel Panic when I load the image via UEFI.
> 

Hi,

I haven't generated a poky-tiny image with wic before, but those
undefined error messages do seem vaguely familiar to me, and I seem to
remember working around them but I can't remember the details.

Can you send me the the relevant info to try a build myself, and also
the wic command you're using (and the one that fails)?

Thanks,

Tom

> I saw that poky-tiny by default uses the following image types:
> IMAGE_FSTYPES = "ext2 cpio.gz"
> 
> This is in my foo-layer/conf/distro/foo-layer.conf file.  There's also
> a note there saying that "We don't build live as that pulls in a lot
> of dependencies for live image and the installer, like udev, grub,
> etc.  These pull in gettext, which fails to build with wide character
> support."
> 
> Does this mean that wic is not supported with poky-tiny?  If it is
> supported, are there any additional requirements for building
> initramfs images into wic generated images?
> 
> Also, I don't see core-image-minimal-initramfs added in poky-tiny as a
> PNBLACKLIST image.  Do you know of any additional configuration I need
> to get this image to build properly (either directly with bitbake or
> embedded into my recipe)?
> 
> Thanks in advance,
> Stuart
> 
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com] 
> Sent: Monday, September 22, 2014 10:28 AM
> To: Summers, John S
> Cc: yocto@yoctoproject.org; Darren Hart
> Subject: Re: [yocto] Packages util-linux and gettext both showing undefined 
> reference
> 
> On 22 September 2014 18:05, Summers, John S  wrote:
> > DISTRO= "poky-tiny"
> 
> I expect this is what's causing the problem.  poky-tiny is very cut-down.  
> CC'ing Darren for a more informed comment.
> 
> Ross


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

Re: [yocto] yocto-bsp create question

[Tom Zanussi]

On Fri, 2014-09-12 at 15:09 -0600, Michael Kotson wrote:
> Hi Tom,
>Thanks for the response.  I filed an enhancement request, but in
> the meantime is there a preferred method to create our own BSP from
> Valleyisland?
> 

Thanks for filing the request, it's been assigned to me and I'll try to
get to it as soon as I can.

In the meantime, I guess what I'd suggest is that you start by copying
the valleyisland bsp you're interested in and modifying it to suit your
needs.  This is essentially what users had to do before yocto-bsp
existed and is the reason it was created - to take all the cut-and-paste
drudgery out of that exercise.

Tom


> All the best,
> Michael
> 
> Michael Kotson
> Chief Technology Officer
> 
> OTel:   (303) 412-2055
> TE-Mail: mkot...@octagonsystems.com
>  NOTICE: The information contained in this email and any document attached 
> hereto is intended only for the named recipient(s). If you are not the 
> intended recipient, nor the employee or agent responsible for delivering this 
> message in confidence to the intended recipient(s), you are hereby notified 
> that you have received this transmittal in error, and any review, 
> dissemination, distribution or copying of this transmittal or its attachments 
> is strictly prohibited. If you have received this transmittal and/or 
> attachments in error, please notify me immediately by reply e-mail and then 
> delete this message, including any attachments. 
> 
> 
> -Original Message-
> From: Tom Zanussi [mailto:tom.zanu...@intel.com] 
> Sent: Friday, September 12, 2014 10:26 AM
> To: Michael Kotson
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] yocto-bsp create question
> 
> On Fri, 2014-09-12 at 10:07 -0600, Michael Kotson wrote:
> > Hi all,
> > 
> >We are trying to create a custom BSP based off of valleyisland-64 
> > using the yocto-bsp script.  When we are presented choices for which 
> > BSP to branch from, valleyisland isn’t one of the choices.  We have 
> > tried all of the different kernel options presented, but no luck.  I’m 
> > pretty sure we have the layers added correctly, as we can build
> > valleyisland-32 and valleyisland-64 inside of hob with no problems.
> > Any idea what we are doing wrong?
> > 
> 
> Nothing that you're doing wrong, it's just that the valleyisland BSPs are 
> built a little differently from the normal BSPs - instead of a machine 
> branch, they do a merge of a valleyisland-io branch into another branch and 
> the yocto-bsp tools aren't set up to do that.  They'd need to be enhanced to 
> enhanced to handle cases like that.  I'd suggest filing a an enhancement bug 
> so we can add that capability..
> 
> Thanks,
> 
> Tom
> 
> 
> 
> >  
> > 
> > All the best,
> > 
> > Michael
> > 
> >  
> > 
> >  
> > 
> > Michael Kotson
> > 
> > Chief Technology Officer
> > 
> > 
> > 
> > (Tel:   (303) 412-2055
> > 
> > *E-Mail: mkot...@octagonsystems.com
> > 
> > NOTICE: The information contained in this email and any document 
> > attached hereto is intended only for the named recipient(s). If you 
> > are not the intended recipient, nor the employee or agent responsible 
> > for delivering this message in confidence to the intended 
> > recipient(s), you are hereby notified that you have received this 
> > transmittal in error, and any review, dissemination, distribution or 
> > copying of this transmittal or its attachments is strictly prohibited.
> > If you have received this transmittal and/or attachments in error, 
> > please notify me immediately by reply e-mail and then delete this 
> > message, including any attachments.
> > 
> >  
> > 
> > 
> 
> 


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

Re: [yocto] yocto-bsp create question

[Tom Zanussi]

On Fri, 2014-09-12 at 10:07 -0600, Michael Kotson wrote:
> Hi all,
> 
>We are trying to create a custom BSP based off of valleyisland-64
> using the yocto-bsp script.  When we are presented choices for which
> BSP to branch from, valleyisland isn’t one of the choices.  We have
> tried all of the different kernel options presented, but no luck.  I’m
> pretty sure we have the layers added correctly, as we can build
> valleyisland-32 and valleyisland-64 inside of hob with no problems.
> Any idea what we are doing wrong?
> 

Nothing that you're doing wrong, it's just that the valleyisland BSPs
are built a little differently from the normal BSPs - instead of a
machine branch, they do a merge of a valleyisland-io branch into another
branch and the yocto-bsp tools aren't set up to do that.  They'd need to
be enhanced to enhanced to handle cases like that.  I'd suggest filing a
an enhancement bug so we can add that capability..

Thanks,

Tom



>  
> 
> All the best,
> 
> Michael
> 
>  
> 
>  
> 
> Michael Kotson
> 
> Chief Technology Officer
> 
> 
> 
> (Tel:   (303) 412-2055
> 
> *E-Mail: mkot...@octagonsystems.com
> 
> NOTICE: The information contained in this email and any document
> attached hereto is intended only for the named recipient(s). If you
> are not the intended recipient, nor the employee or agent responsible
> for delivering this message in confidence to the intended
> recipient(s), you are hereby notified that you have received this
> transmittal in error, and any review, dissemination, distribution or
> copying of this transmittal or its attachments is strictly prohibited.
> If you have received this transmittal and/or attachments in error,
> please notify me immediately by reply e-mail and then delete this
> message, including any attachments. 
> 
>  
> 
> 


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

[yocto] [PATCH 5/5] dev-manual: Various minor fixes for 'Creating Partitioned Images' section

[Tom Zanussi]

This is a set of fixes for miscellaneous dev-manual updates noticed
while transcribing wic help for the dev manual.

Signed-off-by: Tom Zanussi 
---
 .../dev-manual/dev-manual-common-tasks.xml | 94 +-
 1 file changed, 54 insertions(+), 40 deletions(-)

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml 
b/documentation/dev-manual/dev-manual-common-tasks.xml
index e72e983..8189247 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -3354,14 +3354,14 @@
 
 Creating an image for a particular hardware target using the
 OpenEmbedded build system does not necessarily mean you can boot
-that image as is on your device.
+that image as-is on your device.
 Physical devices accept and boot images in various ways depending
 on the specifics of the device.
 Usually, information about the hardware can tell you what image
 format the device requires.
 Should your device require multiple partitions on an SD card, 
flash,
-or an HDD, you can use the OpenEmbedded Image Creator
-to create the properly partitioned image.
+or an HDD, you can use the OpenEmbedded Image Creator,
+   wic, to create the properly partitioned image.
 
 
 
@@ -3372,7 +3372,7 @@
 specified either directly on the command-line or as one of a
 selection of canned .wks files as shown
 with the wic list images command in the
-"Using a Provided 
Kickstart File"
+"Using an Existing 
Kickstart File"
 section.
 When applied to a given set of build artifacts, the result is an
 image or set of images that can be directly written onto media and
@@ -3440,9 +3440,9 @@
 Requirements
 
 
-In order to use the wic utility with the
-OpenEmbedded Build system, you need to meet the following
-requirements:
+In order to use the wic utility
+with the OpenEmbedded Build system, your system needs
+to meet the following requirements:
 
 The Linux distribution on your
 development host must support the Yocto Project.
@@ -3462,14 +3462,17 @@
 system.
 
 
-Have the build artifacts already available.
-You must already have created an image using the
+You need to have the build artifacts already
+available, which typically means that you must
+have already created an image using the
 Openembedded build system (e.g.
-core-image-minimal.
-It might seem redundant to generate an image in order
-to create an image using wic,
-but the artifacts are needed and they are generated
-with the build system.
+core-image-minimal.  It
+might seem redundant to generate an image in
+order to create an image using
+wic, but in the current
+version the artifacts are needed in the form
+generated by the build
+system.
 
 You must have sourced one of the build environment
 setup scripts (i.e.
@@ -3519,8 +3522,8 @@
 
 
 
-You can find more out about the images
-wic creates using the provided
+You can find out more about the images
+wic creates using the existing
 kickstart files with the following form of the command:
 
  $ wic list <image> help
@@ -3552,7 +3555,7 @@
 
 
 
-Regardless of the mode you use, you need to have the build
+Regardless of which mode you use, you need to have the build
 artifacts ready and available.
 Additionally, the environment must be set up using the
 &OE_INIT_FILE;
@@ -3575,7 +3578,7 @@
  image_name.wks
An an OpenEmbedded kickstart file.  You can 
provide
your own custom file or use a file from a set of
-   provided files as described by further options.
+   existing files as described by further options.
 
  -o OUTDIR, 
--outdir=OUTDIR
 

[yocto] [PATCH 4/5] dev-manual: Various updates to the 'Creating Partitioned Images' section

[Tom Zanussi]

This is a set of miscellaneous updates brought over from the wic help
text.

Signed-off-by: Tom Zanussi 
---
 .../dev-manual/dev-manual-common-tasks.xml | 137 +
 1 file changed, 86 insertions(+), 51 deletions(-)

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml 
b/documentation/dev-manual/dev-manual-common-tasks.xml
index c00c961..e72e983 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -3380,6 +3380,15 @@
 
 
 
+ The wic command and the infrastructure
+ it's based on is by definition incomplete - its purpose is
+ to allow the generation of customized images, and as such
+ was designed to be completely extensible via a plugin
+ interface (see "Plugins").
+ 
+
+
 This section provides some background information on
 wic, describes what you need to have in
 place to run the tool, provides instruction on how to use
@@ -3416,12 +3425,13 @@
 easier-to-use and more flexible replacements for a
 couple bits of existing functionality in OE Core's
 directdisk.bbclass and
-mkefidisk.sh script.
-The replaced scripts are implemented by a
-general-purpose partitioning language based on Red Hat
-kickstart syntax.
-Underlying code for wic succeeded
-from several projects over time.
+mkefidisk.sh scripts.
+The difference between
+wic and those examples is
+that with wic the
+functionality of those scripts is implemented
+by a general-purpose partitioning 'language'
+based on Redhat kickstart syntax.
 
 
 
@@ -3496,6 +3506,19 @@
 
 
 
+You can also get detailed help on a number of topics
+from the help system.  The output of wic
+--help displays a list of available help
+topics under a 'Help topics' heading.  You can have
+the help system display the help text for a given
+topic by prefacing the topic with wic
+help:
+
+ $ wic help <help topic>
+
+
+
+
 You can find more out about the images
 wic creates using the provided
 kickstart files with the following form of the command:
@@ -3512,8 +3535,10 @@
 Operational Modes
 
 
-You can run wic in two modes: Raw and
-Cooked:
+ wic can be used in two different
+ modes, depending on how much control the user needs in
+ specifying the Openembedded build artifacts that will be
+ used in creating the image: Raw and Cooked:
 
 Raw Mode:
 You explicitly specify build artifacts through
@@ -3655,7 +3680,7 @@
  # long-description: Creates a partitioned EFI disk image that the user
  # can directly dd to boot media.
 
- part /boot ‐‐source bootimg-efi ‐‐ondisk sda 
‐‐fstype=efi ‐‐active
+ part /boot ‐‐source bootimg-efi ‐‐ondisk sda 
‐‐active
 
  part / ‐‐source rootfs ‐‐ondisk sda 
‐‐fstype=ext3 ‐‐label platform
 
@@ -3798,7 +3823,7 @@
 The example changes the following two lines and leaves the
 remaining lines untouched:
 
- part /boot --source bootimg --ondisk sdb --fstype=msdos --label boot 
--active --align 1024
+ part /boot --source bootimg-pcbios --ondisk sdb --label boot --active 
--align 1024
  part / --source rootfs --ondisk sdb --fstype=ext3 --label platform 
--align 1024
 
 Once the lines are changed, the example generates the
@@ -4129,32 +4154,49 @@
 You do not need this option if you use
 --source.
 
--source:
-This option is a wic-specific option that can
-currently have one of two values, "bootimg" or
-"rootfs".
-If --source rootfs is
-used, it tells the wic command
-to create a partition as large as needed to fill
-with the contents of the root filesystem
-(specified by the -r
-wic option) and to

[yocto] [PATCH 2/5] dev-manual: Add squashfs to --fstypes documentation

[Tom Zanussi]

squashfs support was recently added to wic, so document it.

Signed-off-by: Tom Zanussi 
---
 documentation/dev-manual/dev-manual-common-tasks.xml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml 
b/documentation/dev-manual/dev-manual-common-tasks.xml
index c3df8b3..f8a1398 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -4174,6 +4174,8 @@
 
 btrfs
 
+squashfs
+
 swap
 
 
-- 
1.8.3.1

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

[yocto] [PATCH 0/5] dev-manual updates for wic

[Tom Zanussi]

This patchset updates the wic documentation in the dev-manual for
master.

The following changes since commit 2d1660112e54653f7bb763939d0416472c49fe01:

  populate_sdk_base: Fix grep command usage on old hosts (2014-07-29 09:58:27 
+0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib.git tzanussi/dev-manual-wic-updates
  
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/dev-manual-wic-updates

Tom Zanussi (5):
  dev-manual: Add 'Creating Partitioned Images/Plugins' subsection
  dev-manual: Add squashfs to --fstypes documentation
  dev-manual: Add documentation for --fsoptions
  dev-manual: Various updates to the 'Creating Partitioned Images'
section
  dev-manual: Various minor fixes for 'Creating Partitioned Images'
section

 .../dev-manual/dev-manual-common-tasks.xml | 399 -
 1 file changed, 308 insertions(+), 91 deletions(-)

-- 
1.8.3.1

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

[yocto] [PATCH 3/5] dev-manual: Add documentation for --fsoptions

[Tom Zanussi]

--fsoptions support was recently added to wic, so document it.

Signed-off-by: Tom Zanussi 
---
 documentation/dev-manual/dev-manual-common-tasks.xml | 8 
 1 file changed, 8 insertions(+)

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml 
b/documentation/dev-manual/dev-manual-common-tasks.xml
index f8a1398..c00c961 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -4179,6 +4179,14 @@
 swap
 
 
+
--fsoptions:
+Specifies a free-form string of options to be
+used when mounting the filesystem. This string
+will be copied into the
+/etc/fstab file of the
+installed system and should be enclosed in
+quotes.  If not specified, the default string
+is "defaults".
 --label 
label:
 Specifies the label to give to the filesystem to
 be made on the partition.
-- 
1.8.3.1

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

[yocto] [PATCH 1/5] dev-manual: Add 'Creating Partitioned Images/Plugins' subsection

[Tom Zanussi]

Add a new section discussing plugins, taken directly from the
corresponding wic help section.

Signed-off-by: Tom Zanussi 
---
 .../dev-manual/dev-manual-common-tasks.xml | 158 +
 1 file changed, 158 insertions(+)

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml 
b/documentation/dev-manual/dev-manual-common-tasks.xml
index c4c3d9f..c3df8b3 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -3916,6 +3916,164 @@
 
 
 
+
+Plugins
+
+
+ Plugins allow wic functionality to
+ be extended and specialized by users.  This section
+ documents the plugin interface, which is currently
+ restricted to 'source' plugins.
+
+
+
+ 'Source' plugins provide a mechanism to customize
+ various aspects of the image generation process in
+ wic, mainly the contents of
+ partitions.
+
+
+
+ Source plugins provide a mechanism for mapping values
+ specified in .wks files using the
+ --source keyword to a particular
+ plugin implementation that populates a corresponding
+ partition.
+
+
+
+ A source plugin is created as a subclass of
+ SourcePlugin (see
+ scripts/lib/mic/pluginbase.py) and
+ the plugin file containing it is added to
+ scripts/lib/mic/plugins/source/ to
+ make the plugin implementation available to the
+ wic implementation.
+
+
+
+ Source plugins can also be implemented and added by
+ external layers - any plugins found in a
+ scripts/lib/mic/plugins/source/
+ directory in an external layer will also be made
+ available.
+
+
+
+ When the wic implementation needs
+ to invoke a partition-specific implementation, it looks
+ for the plugin that has the same name as the
+ --source param given to that
+ partition.  For example, if the partition is set up like
+ this:
+
+
+
+
+ part /boot --source bootimg-pcbios   ...
+
+
+
+
+ then the methods defined as class members of the plugin
+ having the matching bootimg-pcbios
+ .name class member would be used.
+
+
+
+ To be more concrete, here's the plugin definition that
+ would match a '--source
+ bootimg-pcbios' usage, along with an example
+ method that would be called by the
+ wic implementation when it needed
+ to invoke an implementation-specific
+ partition-preparation function:
+
+
+
+
+class BootimgPcbiosPlugin(SourcePlugin):
+name = 'bootimg-pcbios'
+
+@classmethod
+def do_prepare_partition(self, part, ...)
+
+
+
+
+ If the subclass itself doesn't implement a function, a
+ 'default' version in a superclass will be located and
+ used, which is why all plugins must be derived from
+ SourcePlugin.
+
+
+
+ The SourcePlugin class defines the
+ following methods, which is the current set of methods
+ that can be implemented/overridden by
+ --source plugins.  Any methods not
+ implemented by a SourcePlugin
+ subclass inherit the implementations present in the
+ SourcePlugin class (see the
+ SourcePlugin source for details):
+
+
+
+
+
do_prepare_partition():
+Called to do the actual content population for a
+partition.  In other words, it 'prepares' the final
+partition image which will be incorporated into the
+disk image.  
+
+
do_configure_partition():
+Called before
+do_prepare_partition(), typically
+used to create custom configuration files for a
+partition, for example syslinux or grub config files.
+
+
+
do_install_disk():
+Called after all partitions have been prepared and
+assembled into a disk image.  This provides a hook to
+allow finalization of a disk image, for example to
+write an MBR to it.  
+
+
do_stage_partition():
+Special co

Re: [yocto] wic status

[Tom Zanussi]

On Thu, 2014-07-17 at 19:38 +0200, Maciek Borzecki wrote:
> On czw, 2014-07-17 at 09:18 -0500, Tom Zanussi wrote:
> > On Thu, 2014-07-17 at 14:51 +0100, Paul Eggleton wrote:
> > > On Thursday 17 July 2014 16:48:41 Scott Rifenbark wrote:
> > > > On Thu, Jul 17, 2014 at 3:56 PM, Paul Eggleton <
> > > > paul.eggle...@linux.intel.com> wrote:
> > > > > On Thursday 17 July 2014 14:25:16 Maciek Borzecki wrote:
> > > > > > There used to be an entry about wic in development manual back in 
> > > > > > 1.5.2:
> > > > > > http://www.yoctoproject.org/docs/1.5.2/dev-manual/dev-manual.html
> > > > > > 
> > > > > > This entry is gone in current documentation and there seems to be no
> > > > > > mention of wic at all:
> > > > > > https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html
> > > > > 
> > > > > Scott, can you take a look at this if you haven't already?
> > > >
> > > > wic was documented in the 1.5.x set and was not put into the 1.6 set.  I
> > > > was told that it was going to change or be further completed so it did 
> > > > not
> > > > go in that development branch.  Wic was never documented in the 1.6 set.
> > > 
> > > Well, wic is still a part of the system in 1.6 and beyond so we do need 
> > > to 
> > > document it; as far as I can tell what was in the 1.5 manual linked above 
> > > should be perfectly fine and we can just extend / update it as needed. 
> > > Tom 
> > > should be able to help fill in any blanks.
> > > 
> > 
> > Right, wic is still included in the system, and like the rest of the
> > system is undergoing continual development, so I'm not sure why it would
> > be treated differently.
> > 
> > In any case, to make it easier for users and to avoid a mismatch with
> > external documentation, over the past couple weeks I've submitted a set
> > of patches (which have now been merged) that puts most of the help
> > content into the tool itself, which is all now accessible via 'wic
> > help'.
> 
> Right, I've seen your patches in master, very helpful.
> 
> There's one more thing that I'm a bit confused about. The 1.5.2 docs
> state the following:
> 
> 
> Here are the actual partition language commands used in the
> mkefidisk.wks file to generate an image:
> 
>  # short-description: Create an EFI disk image
>  # long-description: Creates a partitioned EFI disk image that the
> user
>  # can directly dd to boot media.
> 
>  part /boot --source bootimg --ondisk sda --fstype=efi --label msdos
> --active --align 1024
> 
> 
> I'd assume to find scripts/lib/mic/plugins/source/bootimg.py in the
> tree, but the file is not there. Have I missed something? 
> 

Yeah, the documentation is wrong - I need to update it.  Previous
versions had --source bootimg treated specially and hard-coded the
different cases - for --source bootimg, it would look at the --fstype
and decide which hard-coded version to use, efi in this case.

Versions after that implemented those cases completely as --source
plugins, which you see now as bootimg-efi and bootimg-bios plugins.

> (btw. I'm also assuming that bootimg would prepare a boot partitiong
> without pushing any particular bootloader, like syslinux or whatever
> right?)

Right now, those plugins do push specific bootloaders, which so far has
been enough for our initial images.  You can use --source rootfs to
create general-purpose partitions of the supported fstypes including
contents needed for bootloaders, but the actual installation of a
bootloader would need a plugin containing the logic to do that.  With
support for more architectures and bootloaders coming online, we may
want to provide a more generic mechanism or implementation, but I don't
have any specifics in mind at the moment..

Tom

> 
> 
> -- 
> Maciej Borzęcki
> Senior Software Developer at Open-RnD Sp. z o.o., Poland
> www.open-rnd.pl
> mobile: +48 889 117 365, fax: +48 42 657 9079
> 
> Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem
> lub poufne informacje i została wysłana wyłącznie do wiadomości i
> użytku osób, do których została zaadresowana. Jeśli wiadomość została
> otrzymana przypadkowo zabrania się jej kopiowania lub rozsyłania do
> osób trzecich. W takim przypadku uprasza się o natychmiastowe
> zniszczenie wiadomości oraz poinformowanie nadawcy o zaistniałej
> sytuacji za pomocą wiadomości zwrotnej. Dziękujemy.
> 
> This message, including any attachments hereto, may contain privileged
> or confidential information and is sent solely for the attention and
> use of the intended addressee(s). If you are not an intended addressee,
> you may neither use this message nor copy or deliver it to anyone. In
> such case, you should immediately destroy this message and kindly notify
> the sender by reply email. Thank you.
> 
> 


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

Re: [yocto] wic status

[Tom Zanussi]

On Thu, 2014-07-17 at 14:51 +0100, Paul Eggleton wrote:
> On Thursday 17 July 2014 16:48:41 Scott Rifenbark wrote:
> > On Thu, Jul 17, 2014 at 3:56 PM, Paul Eggleton <
> > paul.eggle...@linux.intel.com> wrote:
> > > On Thursday 17 July 2014 14:25:16 Maciek Borzecki wrote:
> > > > There used to be an entry about wic in development manual back in 1.5.2:
> > > > http://www.yoctoproject.org/docs/1.5.2/dev-manual/dev-manual.html
> > > > 
> > > > This entry is gone in current documentation and there seems to be no
> > > > mention of wic at all:
> > > > https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html
> > > 
> > > Scott, can you take a look at this if you haven't already?
> >
> > wic was documented in the 1.5.x set and was not put into the 1.6 set.  I
> > was told that it was going to change or be further completed so it did not
> > go in that development branch.  Wic was never documented in the 1.6 set.
> 
> Well, wic is still a part of the system in 1.6 and beyond so we do need to 
> document it; as far as I can tell what was in the 1.5 manual linked above 
> should be perfectly fine and we can just extend / update it as needed. Tom 
> should be able to help fill in any blanks.
> 

Right, wic is still included in the system, and like the rest of the
system is undergoing continual development, so I'm not sure why it would
be treated differently.

In any case, to make it easier for users and to avoid a mismatch with
external documentation, over the past couple weeks I've submitted a set
of patches (which have now been merged) that puts most of the help
content into the tool itself, which is all now accessible via 'wic
help'.

Thanks,

Tom


> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre


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

Re: [yocto] wic status

[Tom Zanussi]

On Thu, 2014-07-17 at 14:51 +0100, Paul Eggleton wrote:
> On Thursday 17 July 2014 16:48:41 Scott Rifenbark wrote:
> > On Thu, Jul 17, 2014 at 3:56 PM, Paul Eggleton <
> > paul.eggle...@linux.intel.com> wrote:
> > > On Thursday 17 July 2014 14:25:16 Maciek Borzecki wrote:
> > > > There used to be an entry about wic in development manual back in 1.5.2:
> > > > http://www.yoctoproject.org/docs/1.5.2/dev-manual/dev-manual.html
> > > > 
> > > > This entry is gone in current documentation and there seems to be no
> > > > mention of wic at all:
> > > > https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html
> > > 
> > > Scott, can you take a look at this if you haven't already?
> >
> > wic was documented in the 1.5.x set and was not put into the 1.6 set.  I
> > was told that it was going to change or be further completed so it did not
> > go in that development branch.  Wic was never documented in the 1.6 set.
> 
> Well, wic is still a part of the system in 1.6 and beyond so we do need to 
> document it; as far as I can tell what was in the 1.5 manual linked above 
> should be perfectly fine and we can just extend / update it as needed. Tom 
> should be able to help fill in any blanks.
> 

Right, wic is still included in the system, and like the rest of the
system is undergoing continual development, so I'm not sure why it would
be treated differently.

In any case, to make it easier for users and to avoid a mismatch with
external documentation, over the past couple weeks I've submitted a set
of patches (which have now been merged) that puts most of the help
content into the tool itself, which is all now accessible via 'wic
help'.

Thanks,

Tom

> Cheers,
> Paul
> 


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

Re: [yocto] yocto-bsp treats beaglebone as omap3 device

[Tom Zanussi]

Hi,

On Fri, 2014-06-06 at 14:28 -0400, Matthew Keeter wrote:
> I’ve got a quick question about using the yocto-bsp tool (release 1.6):
> 
> Using it to create an ARM BSP from the beaglebone machine branch results in a 
> BSP
> that targets the OMAP3 processor (which is on the beagleboard, not the 
> beaglebone).
> 
> I say this because the default value for UBOOT_MACHINE is 
> “omap3_beagle_config” and
> the kernel device tree in conf/machine/my-bbb.conf points to an omap3 device 
> tree.
> 
> This appears to be incorrect behavior and disagrees with the default 
> beaglebone machine
> configuration in meta-yocto-bsp/conf/machine/beaglebone.conf
> 
> Am I missing something, or is the tool doing the wrong thing?

It's not really doing the wrong thing, it's just sort of outdated and
not doing what I guess you'd expect, which is to match the reference
board in meta-yocto-bsp (note that the yocto-bsp tool doesn't really
have anything to do with meta-yocto-bsp, though the names are similar).

The old arm reference board was the beagleboard, and that's what the
yocto-bsp template reflects, and should probably be updated to use the
beaglebone settings.

> Any suggested work-arounds?

I'd suggest just manually modifying the generated BSP to match your
hardware; technically the output of yocto-bsp is only guaranteed to
build, not necessarily successfully boot on a given board.  The Intel
boards have been boot-tested, but that's just because I have the
necessary hardware, and nobody's actually paid much attention to the arm
output, as far as I can tell.  If you have suggestions other than that
that the output should match the beaglebone reference in meta-yocto-bsp,
I'd be happy to make those changes in the next iteration of the tool.

Thanks,

Tom

> 
> Regards,
> Matt Keeter


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

Re: [yocto] [meta-intel][common][dora][PATCHv2] emgd-driver-bin: limit build to x86

[Tom Zanussi]

On Fri, 2014-02-14 at 19:24 +0100, Koen Kooi wrote:
> When building GL apps for non-x86 machines (e.g. raspberrypi) emgd-driver-bin 
> is being
> dragged in as a valid provider. To avoid build breakage fix it at the
> source by limiting emgd-driver-bin to x86 architectures.
> 
> Signed-off-by: Koen Kooi 

Pulled into meta-intel/dora and meta-intel/master.

Thanks,

Tom

> ---
>  common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb | 2 ++
>  common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb 
> b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
> index c8ca726..8cb088e 100644
> --- a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
> +++ b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb
> @@ -9,6 +9,8 @@ LICENSE = "Intel-software-license-emgd-1.16 & 
> Intel-user-space-graphics-driver-b
>  LICENSE_FLAGS = "license_${PN}_${PV}"
>  PR = "r0"
>  
> +COMPATIBLE_HOST = "(i.86).*-linux"
> +
>  EMGD_LIC_DIR = "IEMGD_HEAD_Linux/License"
>  EMGD_RPM_DIR = "IEMGD_HEAD_Linux/MeeGo1.2"
>  EMGD_VIDEO_PLUGIN_DIR = "../common/video_plugin"
> diff --git a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb 
> b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb
> index b3bf0d2..cf6d855 100644
> --- a/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb
> +++ b/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb
> @@ -9,6 +9,8 @@ LICENSE = "Intel-software-license-emgd-1.18 & 
> Intel-user-space-graphics-driver-b
>  LICENSE_FLAGS = "license_${PN}_${PV}"
>  PR = "r1"
>  
> +COMPATIBLE_HOST = "(i.86).*-linux"
> +
>  EMGD_LIC_DIR = "IEMGD_HEAD_Linux/License"
>  EMGD_RPM_DIR = "IEMGD_HEAD_Linux/MeeGo1.2"
>  EMGD_VIDEO_PLUGIN_DIR = "../common/video_plugin"


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

[yocto] [PATCH 00/10] Make dd text in READMEs consistent

[tom . zanussi]

From: Tom Zanussi 

This updates all the top-level meta-intel BSPs with consistent
text for the dd step.

The following changes since commit f707b6c67909ccd84cb2070bdc15777573833461:

  meta-fri2: Use the symlink to the actual image in README (2014-01-06 11:34:28 
-0600)

are available in the git repository at:

  git://git.yoctoproject.org/meta-intel-contrib.git 
tzanussi/consistify-README-dd-text
  
http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/consistify-README-dd-text

Tom Zanussi (10):
  meta-chiefriver: Use the symlink to the actual image in README
  meta-crownbay: Use the symlink to the actual image in README
  meta-crystalforest: Use the symlink to the actual image in README
  meta-emenlow: Use the symlink to the actual image in README
  meta-jasperforest: Use the symlink to the actual image in README
  meta-n450: Use the symlink to the actual image in README
  meta-nuc: Use the symlink to the actual image in README
  meta-romley: Use the symlink to the actual image in README
  meta-sugarbay: Use the symlink to the actual image in README
  meta-sys940x: Use the symlink to the actual image in README

 meta-chiefriver/README|2 +-
 meta-crownbay/README  |2 +-
 meta-crystalforest/README |4 ++--
 meta-emenlow/README   |2 +-
 meta-jasperforest/README  |2 +-
 meta-n450/README  |2 +-
 meta-nuc/README   |2 +-
 meta-romley/README|2 +-
 meta-sugarbay/README  |2 +-
 meta-sys940x/README   |2 +-
 10 files changed, 11 insertions(+), 11 deletions(-)

-- 
1.7.9.5

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

[yocto] [PATCH 10/10] meta-sys940x: Use the symlink to the actual image in README

[tom . zanussi]

From: Tom Zanussi 

Using the image symlink when dd'ing is more convenient for the user -
update the documentation to reflect that.

Signed-off-by: Tom Zanussi 
---
 meta-sys940x/README |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-sys940x/README b/meta-sys940x/README
index f63d3c9..57f64f2 100644
--- a/meta-sys940x/README
+++ b/meta-sys940x/README
@@ -152,7 +152,7 @@ Under Linux, insert a USB flash drive.  Assuming the USB 
flash drive
 takes device /dev/sdf, use dd to copy the live image to it.  For
 example:
 
-# dd if=core-image-sato-sys940x-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-sys940x.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
-- 
1.7.9.5

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

[yocto] [PATCH 04/10] meta-emenlow: Use the symlink to the actual image in README

[tom . zanussi]

From: Tom Zanussi 

Using the image symlink when dd'ing is more convenient for the user -
update the documentation to reflect that.

Signed-off-by: Tom Zanussi 
---
 meta-emenlow/README |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-emenlow/README b/meta-emenlow/README
index 01398f1..15f8ddb 100644
--- a/meta-emenlow/README
+++ b/meta-emenlow/README
@@ -159,7 +159,7 @@ Under Linux, insert a USB flash drive.  Assuming the USB 
flash drive
 takes device /dev/sdf, use dd to copy the live image to it.  For
 example:
 
-# dd if=core-image-sato-emenlow-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-emenlow.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
-- 
1.7.9.5

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

[yocto] [PATCH 09/10] meta-sugarbay: Use the symlink to the actual image in README

[tom . zanussi]

From: Tom Zanussi 

Using the image symlink when dd'ing is more convenient for the user -
update the documentation to reflect that.

Signed-off-by: Tom Zanussi 
---
 meta-sugarbay/README |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-sugarbay/README b/meta-sugarbay/README
index 6c87930..5b71a24 100644
--- a/meta-sugarbay/README
+++ b/meta-sugarbay/README
@@ -132,7 +132,7 @@ Under Linux, insert a USB flash drive.  Assuming the USB 
flash drive
 takes device /dev/sdf, use dd to copy the live image to it.  For
 example:
 
-# dd if=core-image-sato-sugarbay-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-sugarbay.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
-- 
1.7.9.5

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

[yocto] [PATCH 02/10] meta-crownbay: Use the symlink to the actual image in README

[tom . zanussi]

From: Tom Zanussi 

Using the image symlink when dd'ing is more convenient for the user -
update the documentation to reflect that.

Signed-off-by: Tom Zanussi 
---
 meta-crownbay/README |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-crownbay/README b/meta-crownbay/README
index 3912f31..af8931b 100644
--- a/meta-crownbay/README
+++ b/meta-crownbay/README
@@ -153,7 +153,7 @@ Under Linux, insert a USB flash drive.  Assuming the USB 
flash drive
 takes device /dev/sdf, use dd to copy the live image to it.  For
 example:
 
-# dd if=core-image-sato-crownbay-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-crownbay.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
-- 
1.7.9.5

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

[yocto] [PATCH 03/10] meta-crystalforest: Use the symlink to the actual image in README

[tom . zanussi]

From: Tom Zanussi 

Using the image symlink when dd'ing is more convenient for the user -
update the documentation to reflect that.

Signed-off-by: Tom Zanussi 
---
 meta-crystalforest/README |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-crystalforest/README b/meta-crystalforest/README
index c0841cf..67de39d 100644
--- a/meta-crystalforest/README
+++ b/meta-crystalforest/README
@@ -134,13 +134,13 @@ example:
 
 To boot the Gladden Platform:
 
-# dd if=core-image-sato-crystalforest-gladden-20120829033154.hddimg of=/dev/sdf
+# dd if=core-image-sato-crystalforest-gladden.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
 To boot the Server Platform:
 
-# dd if=core-image-sato-crystalforest-server-20120829044852.hddimg of=/dev/sdf
+# dd if=core-image-sato-crystalforest-server.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
-- 
1.7.9.5

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

[yocto] [PATCH 06/10] meta-n450: Use the symlink to the actual image in README

[tom . zanussi]

From: Tom Zanussi 

Using the image symlink when dd'ing is more convenient for the user -
update the documentation to reflect that.

Signed-off-by: Tom Zanussi 
---
 meta-n450/README |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-n450/README b/meta-n450/README
index 80aabaf..2f652db 100644
--- a/meta-n450/README
+++ b/meta-n450/README
@@ -108,7 +108,7 @@ Under Linux, insert a USB flash drive.  Assuming the USB 
flash drive
 takes device /dev/sdf, use dd to copy the live image to it.  For
 example:
 
-# dd if=core-image-sato-n450-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-n450.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
-- 
1.7.9.5

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

[yocto] [PATCH 07/10] meta-nuc: Use the symlink to the actual image in README

[tom . zanussi]

From: Tom Zanussi 

Using the image symlink when dd'ing is more convenient for the user -
update the documentation to reflect that.

Signed-off-by: Tom Zanussi 
---
 meta-nuc/README |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-nuc/README b/meta-nuc/README
index c0087bb..605de5d 100644
--- a/meta-nuc/README
+++ b/meta-nuc/README
@@ -130,7 +130,7 @@ Under Linux, insert a USB flash drive.  Assuming the USB 
flash drive
 takes device /dev/sdf, use dd to copy the live image to it.  For
 example:
 
-# dd if=core-image-sato-nuc-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-nuc.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
-- 
1.7.9.5

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

Re: [yocto] [PATCH 00/10] Make dd text in READMEs consistent

[Tom Zanussi]

Oops, sorry, wrong list, please ignore..

Tom

On Mon, 2014-01-06 at 11:55 -0600, tom.zanu...@intel.com wrote:
> From: Tom Zanussi 
> 
> This updates all the top-level meta-intel BSPs with consistent
> text for the dd step.
> 
> The following changes since commit f707b6c67909ccd84cb2070bdc15777573833461:
> 
>   meta-fri2: Use the symlink to the actual image in README (2014-01-06 
> 11:34:28 -0600)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/meta-intel-contrib.git 
> tzanussi/consistify-README-dd-text
>   
> http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/consistify-README-dd-text
> 
> Tom Zanussi (10):
>   meta-chiefriver: Use the symlink to the actual image in README
>   meta-crownbay: Use the symlink to the actual image in README
>   meta-crystalforest: Use the symlink to the actual image in README
>   meta-emenlow: Use the symlink to the actual image in README
>   meta-jasperforest: Use the symlink to the actual image in README
>   meta-n450: Use the symlink to the actual image in README
>   meta-nuc: Use the symlink to the actual image in README
>   meta-romley: Use the symlink to the actual image in README
>   meta-sugarbay: Use the symlink to the actual image in README
>   meta-sys940x: Use the symlink to the actual image in README
> 
>  meta-chiefriver/README|2 +-
>  meta-crownbay/README  |2 +-
>  meta-crystalforest/README |4 ++--
>  meta-emenlow/README   |2 +-
>  meta-jasperforest/README  |2 +-
>  meta-n450/README  |2 +-
>  meta-nuc/README   |2 +-
>  meta-romley/README|2 +-
>  meta-sugarbay/README  |2 +-
>  meta-sys940x/README   |2 +-
>  10 files changed, 11 insertions(+), 11 deletions(-)
> 


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

[yocto] [PATCH 08/10] meta-romley: Use the symlink to the actual image in README

[tom . zanussi]

From: Tom Zanussi 

Using the image symlink when dd'ing is more convenient for the user -
update the documentation to reflect that.

Signed-off-by: Tom Zanussi 
---
 meta-romley/README |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-romley/README b/meta-romley/README
index b8c089b..a5041d8 100644
--- a/meta-romley/README
+++ b/meta-romley/README
@@ -124,7 +124,7 @@ Under Linux, insert a USB flash drive.  Assuming the USB 
flash drive
 takes device /dev/sdf, use dd to copy the live image to it.  For
 example:
 
-# dd if=core-image-sato-romley-20111007220323.hddimg of=/dev/sdf
+# dd if=core-image-sato-romley.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
-- 
1.7.9.5

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

[yocto] [PATCH 05/10] meta-jasperforest: Use the symlink to the actual image in README

[tom . zanussi]

From: Tom Zanussi 

Using the image symlink when dd'ing is more convenient for the user -
update the documentation to reflect that.

Signed-off-by: Tom Zanussi 
---
 meta-jasperforest/README |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-jasperforest/README b/meta-jasperforest/README
index 6fe43b0..12c4ace 100644
--- a/meta-jasperforest/README
+++ b/meta-jasperforest/README
@@ -111,7 +111,7 @@ Under Linux, insert a USB flash drive.  Assuming the USB 
flash drive
 takes device /dev/sdf, use dd to copy the live image to it.  For
 example:
 
-# dd if=core-image-sato-jasperforest-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-jasperforest.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
-- 
1.7.9.5

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

[yocto] [PATCH 01/10] meta-chiefriver: Use the symlink to the actual image in README

[tom . zanussi]

From: Tom Zanussi 

Using the image symlink when dd'ing is more convenient for the user -
update the documentation to reflect that.

Signed-off-by: Tom Zanussi 
---
 meta-chiefriver/README |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-chiefriver/README b/meta-chiefriver/README
index 925abaa..f846be6 100644
--- a/meta-chiefriver/README
+++ b/meta-chiefriver/README
@@ -132,7 +132,7 @@ Under Linux, insert a USB flash drive.  Assuming the USB 
flash drive
 takes device /dev/sdf, use dd to copy the live image to it.  For
 example:
 
-# dd if=core-image-sato-chiefriver-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-chiefriver.hddimg of=/dev/sdf
 # sync
 # eject /dev/sdf
 
-- 
1.7.9.5

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

Re: [yocto] poky-tiny breaks at ncurses and perl (Dylan 9.0.1)

[Tom Zanussi]

On Mon, 2013-12-09 at 16:45 -0500, r10kindsofpeople wrote:
> On Mon, Dec 9, 2013 at 4:24 PM, Saul Wold  wrote:
> On 12/09/2013 11:51 AM, r10kindsofpeople wrote:
> On Fri, Dec 6, 2013 at 3:08 PM, Tom Zanussi
>  <mailto:tom.zanu...@intel.com>> wrote:
> 
> On Fri, 2013-12-06 at 14:08 -0500,
> r10kindsofpeople wrote:
>  > After some success building my system
> (crownbay), I'm now trying to
>  > optimize boot time, so I read up on poky-tiny,
> created a new
> layer and
>  > am trying to build.  I think I've pulled most
> of my system
> changes out
>  > so that I can at least bitbake
> core-image-minimal, but I'm still not
>  > able to get past ncurses config and perl.
>  (ncurses reports autoconf
>  > errors in widec, perl has undefined references
> to gcvt, I'm also
>  > getting complaints about multiple providers for
> the kernel, etc.)
>  >
>  >
>  > Is poky-tiny still active and tested?  What are
> the odds of this
> being
>  > resolved in Dora versus the odds of running
> into other migration
>  > issues?
>  >
> 
> I haven't tried poky-tiny with dylan, but I have
> with dora and didn't
> run into any build problems - the build errors
> you're running into
> aren't things I've seen either.
> 
> So maybe you can try with dora and see what
> happens - if you still run
> into problems, please provide some more details on
> your setup.
> 
> 
> Thanks, Tom...using Dora, I was able to get the basic
> system to build.
> 
> Adding some features (dhcp-server, for instance) still
> breaks the build,
> but I suspect that's just a consequence of -tiny doing
> it's thing.
> 
> John, that's probably correct, the tiny configuration uses
> uclibc and if you see bug number 5431
> (https://bugzilla.yoctoproject.org/show_bug.cgi?id=5431),
> there are a number of recipes that will not build correctly
> with the full uclibc, but that was with a full uclibc, where
> as the tiny configuration cuts down ulibc to just support the
> bare minimum.
> 
> Hope that helps with your efforts.
> 
> Sau!
> 
> 
> Thanks, Saul, I'll take a look.
> 
> 
> A "FWIW" for any and all...to get qemu to work with the tiny image, I
> had to do a menuconfig for busybox and add "setsid" and "cttyhack",
> otherwise I was getting "not found" and "error 127" loops on startup.
>  
> 
> 
> (hints on how to do this without menuconfig are welcome...I tried
> creating my own recipe and adding package ${PN}-setsid or including my
> own (edited) defconfig, but neither seemed to work. 

I also ran into that problem and sent an initial fix for it:

https://lists.yoctoproject.org/pipermail/poky/2013-November/009378.html

I still need to 'fix' the fix but it works in any case..

Tom


> John
> 
> 
> 
> ___
> 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] poky-tiny breaks at ncurses and perl (Dylan 9.0.1)

[Tom Zanussi]

On Fri, 2013-12-06 at 14:08 -0500, r10kindsofpeople wrote:
> After some success building my system (crownbay), I'm now trying to
> optimize boot time, so I read up on poky-tiny, created a new layer and
> am trying to build.  I think I've pulled most of my system changes out
> so that I can at least bitbake core-image-minimal, but I'm still not
> able to get past ncurses config and perl.  (ncurses reports autoconf
> errors in widec, perl has undefined references to gcvt, I'm also
> getting complaints about multiple providers for the kernel, etc.)
> 
> 
> Is poky-tiny still active and tested?  What are the odds of this being
> resolved in Dora versus the odds of running into other migration
> issues?  
> 

I haven't tried poky-tiny with dylan, but I have with dora and didn't
run into any build problems - the build errors you're running into
aren't things I've seen either.

So maybe you can try with dora and see what happens - if you still run
into problems, please provide some more details on your setup.

Thanks,

Tom

> 
> John
> ___
> 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] yocto Digest, Vol 38, Issue 29

[Tom Zanussi]

On Wed, 2013-11-06 at 22:26 +, Andy Gikling wrote:
> Brian,
> 
> Yes the meta-intel x86-64 should work.  I wouldn't count on the infrared 
> working out of the box though.  Chances are getting the appropriated graphics 
> drivers to work with Yocto will also be difficult and probably won't work out 
> of the box.  All the NUC's peripherals might work if you install Ubuntu - but 
> I'd even give that a 40% chance of failing to support everything you need for 
> your home theater computer.
> 
> If this is your first go at Yocto, I'd try getting the build system to run on 
> an older x86 computer that you're not interested in using as your home 
> theater PC.  Otherwise you're going to probably get frustrated if/when Yocto 
> doesn't totally support the NUC...
> 

Or you could try the Yocto NUC BSP:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/meta-nuc

I don't know about IR, but everything else works fine out of the box,
including graphics.

Tom


> But if you're not planning on this being a home theater PC, by all means, 
> have at it!  If Yocto has issues now, many of them will get fixed eventually 
> as more of the NUC devices come online.
> 
> Just my 2 cents.
> 
> ~Andy Gikling 
> 
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
> On Behalf Of yocto-requ...@yoctoproject.org
> Sent: Wednesday, November 06, 2013 4:07 PM
> To: yocto@yoctoproject.org
> Subject: yocto Digest, Vol 38, Issue 29
> 
> Send yocto mailing list submissions to
>   yocto@yoctoproject.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.yoctoproject.org/listinfo/yocto
> or, via email, send a message with subject or body 'help' to
>   yocto-requ...@yoctoproject.org
> 
> You can reach the person managing the list at
>   yocto-ow...@yoctoproject.org
> 
> When replying, please edit your Subject line so it is more specific than "Re: 
> Contents of yocto digest..."
> 
> 
> Today's Topics:
> 
>1. Re: FW: curious about ref manual, sec 6.1.11,
>   oe-init-build-env-memres (Saul Wold)
>2. Re: FW: curious about ref manual, sec 6.1.11,
>   oe-init-build-env-memres (Robert P. J. Day)
>3. Bitbake Commander Content Assist on bbappend files
>   (Jate Sujjavanich)
>4. My first Yocto Project (Brian Duffy)
>5. Changing Config for linux-raspberrypi (John Whitmore)
>6. Re: Changing Config for linux-raspberrypi (Robert P. J. Day)
>7. Re: My first Yocto Project (Sean Liming)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 06 Nov 2013 12:38:13 -0800
> From: Saul Wold 
> To: "Rifenbark, Scott M" ,   Yocto
>   discussion list 
> Subject: Re: [yocto] FW: curious about ref manual, sec 6.1.11,
>   oe-init-build-env-memres
> Message-ID: <527aa8b5.8060...@linux.intel.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 11/06/2013 11:11 AM, Rifenbark, Scott M wrote:
> > Anyone know this?
> >
> >> -Original Message-
> >> From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
> >> Sent: Wednesday, November 06, 2013 10:48 AM
> >> To: Rifenbark, Scott M
> >> Subject: curious about ref manual, sec 6.1.11, 
> >> oe-init-build-env-memres
> >>
> >>
> >>   i've never used that memory-resident version of bitbake -- it's not 
> >> clear from that section whether you need to start bitbake running 
> >> before you run that script.
> >>
> Running that scripts will start the server at the default port of 12345 and 
> setup the default "build" directory.
> 
> >>   that is, it's not really *explicitly* explained whether running 
> >> that script with a port number *starts* the bitbake server. does it?
> >>
> Yes, running the script with a port number will start the server using that 
> port number.
> 
> The bitbake -m command will Stop the server.
> 
> Sau!
> 
> >> rday
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
> 
> 
> --
> 
> Message: 2
> Date: Wed, 6 Nov 2013 15:41:02 -0500 (EST)
> From: "Robert P. J. Day" 
> To: Saul Wold 
> Cc: Yocto discussion list 
> Subject: Re: [yocto] FW: curious about ref manual, sec 6.1.11,
>   oe-init-build-env-memres
> Message-ID: 
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> On Wed, 6 Nov 2013, Saul Wold wrote:
> 
> > On 11/06/2013 11:11 AM, Rifenbark, Scott M wrote:
> > > Anyone know this?
> > >
> > > > -Original Message-
> > > > From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
> > > > Sent: Wednesday, November 06, 2013 10:48 AM
> > > > To: Rifenbark, Scott M
> > > > Subject: curious about ref manual, sec 6.1.11, 
> > > > oe-init-build-env-memres
> > > >
> > > >
> > > >   i've never used that memory-resident version of bitbake -- it's 
> > > > not clear from that section whether you need to start bitbake 
> > > > running before

Re: [yocto] example of Kernel work

[Tom Zanussi]

On Wed, 2013-11-06 at 14:02 -0500, Robert P. J. Day wrote:
> On Wed, 6 Nov 2013, Tom Zanussi wrote:
> 
> ... snip ...
> 
> > OK, well, anyway, until it gets fixed, here's a link to the pdf:
> >
> > https://www.yoctoproject.org/sites/yoctoproject.org/files/kernel-lab-1.4.pdf
> >
> > And here are the accompanying layers:
> >
> > https://www.yoctoproject.org/sites/yoctoproject.org/files/kernel-lab-1.4-layers.tar.bz2
> >
> > Sorry for the inconvenience.
> 
>   i recall exchanging some email with tom a few weeks back about that
> very lab. i started working through it and making notes as to how to
> update it for 1.5 so that i could use it in upcoming OE/yocto classes.
> my goal is for something that is based on his 1.4 lab but tweaked here
> and there to match the rest of my courseware.
> 
>   when i finally get it done, i'll post it -- unless tom updates his
> lab first. :-)
> 

I do have the 1.5 update on my schedule for 1.6 M1, but if you were
going to do something like that anyway, that would be great.  I wasn't
actually going to start on it until next week - I guess I should check
with you then before I actually start diving in...

https://bugzilla.yoctoproject.org/show_bug.cgi?id=5486

Thanks,

Tom

> rday
> 


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

Re: [yocto] example of Kernel work

[Tom Zanussi]

On Wed, 2013-11-06 at 08:00 -0600, Tom Zanussi wrote:
> On Wed, 2013-11-06 at 10:26 +, John Whitmore wrote:
> > Found this nice little document on Kernel work in the yocto build system [1]
> > it's just a shame that it isn't up to date, to use against the current 
> > version
> > of the build system. 
> > 
> > Does anybody know is there a more up to date version of this document? It
> > might just be me but a worked example is so much cleared then writing about
> > the process.
> 
> I updated the kernel lab for 1.4, and it used to be here:
> 
> https://www.yoctoproject.org/training/kernel-lab
> 
> I see the kernel-lab layers for 1.4 here:
> 
> https://www.yoctoproject.org/training/kernel-training
> 
> Which doesn't make sense either - you'd think the layers would go with
> the (nonexistent) pdf under kernel-lab.
> 
> And I don't see either for 1.3 and am wondering how you found it...
> 
> Cc:ing Jefro on this.
> 
> 

OK, well, anyway, until it gets fixed, here's a link to the pdf:

https://www.yoctoproject.org/sites/yoctoproject.org/files/kernel-lab-1.4.pdf

And here are the accompanying layers:

https://www.yoctoproject.org/sites/yoctoproject.org/files/kernel-lab-1.4-layers.tar.bz2

Sorry for the inconvenience.

Tom

> Tom
> 
> > 
> > [1] 
> > https://www.yoctoproject.org/sites/yoctoproject.org/files/elc2013-kernel-lab.pdf
> > ___
> > 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] example of Kernel work

[Tom Zanussi]

On Wed, 2013-11-06 at 10:26 +, John Whitmore wrote:
> Found this nice little document on Kernel work in the yocto build system [1]
> it's just a shame that it isn't up to date, to use against the current version
> of the build system. 
> 
> Does anybody know is there a more up to date version of this document? It
> might just be me but a worked example is so much cleared then writing about
> the process.

I updated the kernel lab for 1.4, and it used to be here:

https://www.yoctoproject.org/training/kernel-lab

I see the kernel-lab layers for 1.4 here:

https://www.yoctoproject.org/training/kernel-training

Which doesn't make sense either - you'd think the layers would go with
the (nonexistent) pdf under kernel-lab.

And I don't see either for 1.3 and am wondering how you found it...

Cc:ing Jefro on this.


Tom

> 
> [1] 
> https://www.yoctoproject.org/sites/yoctoproject.org/files/elc2013-kernel-lab.pdf
> ___
> 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] why does meta-intel crownbay-noemgd.conf not require "meta-intel"?

[Tom Zanussi]

On Fri, 2013-10-11 at 05:49 -0400, Robert P. J. Day wrote:
> perusing sample machine conf files and BSP definitions, looking for
> nice examples to use in a class in a couple weeks, and i noticed the
> following oddity under meta-intel/meta-crownbay.
> 
>   while crownbay.conf contains:
> 
> require conf/machine/include/tune-atom.inc
> require conf/machine/include/ia32-base.inc
> require conf/machine/include/meta-intel.inc
> require conf/machine/include/meta-intel-emgd.inc
> 
>   crownbay-noemgd.conf contains only:
> 
> require conf/machine/include/tune-atom.inc
> require conf/machine/include/ia32-base.inc
> 
>   i would have thought the latter would still need to require
> "meta-intel.inc" for consistency.
> 
>   i'm sure if i poked around for a few seconds, it would make sense
> but, just from a visual point of view -- if someone is reading the
> files trying to understand how to define a BSP -- it looks confusing,
> no?
> 

Not really - meta-intel is itself a separate layer, and crownbay-noemgd
doesn't need anything from it, so doesn't need the includes for it.

crownbay.conf does need at least emgd and related packages from
meta-intel so includes meta-intel.inc and meta-intel-emgd.inc.

Tom

> rday
> 


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

Re: [yocto] Fwd: FW: Creating BSP without using git

[Tom Zanussi]

On Tue, 2013-10-01 at 11:48 +0530, Dilip Kumar wrote:
> 
> >  
> >
> > 
> >
> > Hi,
> >
> > I need to create a local BSP layer using Yocto-bsp
> create command without the use of Git.
> >
> >  
> >
> >  
> >
> > yocto-bsp create mylayers qemu -s
> >
> > Which qemu architecture would you like to use? [default: i386]
> >
> > 1) i386(32-bit)
> >
> > 2) x86_64  (64-bit)
> >
> > 3) ARM (32-bit)
> >
> > 4) PowerPC (32-bit)
> >
> > 5) MIPS(32-bit)
> >
> > 3
> >
> > Would you like to use the default (3.8) kernel? (y/n) [default: y] y
> >
> > Do you need a new machine branch for this BSP (the alternative is to
> re-use an existing branch)? [y/n] [default: y] n
> >
> > Getting branches from remote repo
> git://git.yoctoproject.org/linux-yocto-3.8.git...
> >
> >  

You can use the -i param with JSON to feed it the answers you want to
give it, and then it won't try to generate and display a branch list,
etc.

>From the help:

yocto-bsp create   [-o  | --outdir ]
[-i  | --infile ]

The BSP-specific properties that define the values that will be
used to generate a particular BSP can be specified on the
command-line using the -i option and supplying a JSON object
consisting of the set of name:value pairs needed by the BSP.

If the -i option is not used, the user will be interactively
prompted for each of the required property values, which will then
be used as values for BSP generation.

The set of properties available for a given architecture can be
listed using the 'yocto-bsp list' command.

> >
> >  
> >
> > Thanks with Regards
> >
> >
> -
> > Dilip Kumar b
> >
> 
> >
> >  
> >
> >
> > 
> > The contents of this e-mail and any attachment(s) may contain
> confidential or privileged information for the intended recipient(s).
> Unintended recipients are prohibited from taking action on the basis
> of information in this e-mail and using or disseminating the
> information, and must notify the sender and delete it from their
> system. L&T Infotech will not accept responsibility or liability for
> the accuracy or completeness of, or the presence of any virus or
> disabling code in this e-mail"
> 
> 
> ___
> 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] yocto-bsp and kconf-check

[Tom Zanussi]

On Thu, 2013-08-29 at 11:36 -0400, Jate Sujjavanich wrote:
> It appears that the yocto-bsp script generates a kernel configuration that 
> creates some warnings during kern-tools' kconf_check. The {{machine}}.cfg 
> file has many non-hardware options, therefore the script warns.
> 
> It seems like many of these should be in the standard kernel configuration. 
> Is this correct, and does the yocto-bsp data need to be updated?
> 

The templates in yocto-bsp are derived from the reference and qemu BSPs,
and have basically inherited the kernel config from those.

Now that the new kernel has landed, I've started updating the templates
for 3.10, and yes, if all the reference and qemu BSPs have been fixed in
this regard, I need to update the yocto-bsp templates with the new
options as well.

BTW, which arch did you use to generate your BSP?

Tom

> - Jate
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


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

[linux-yocto] [PATCH 0/2] linux-yocto-3.10: revert timer_list patches

[Tom Zanussi]

The following reverts fix the problem outlined in [Yocto #5062], which
manifested as a dropbearkey hang:

 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5062

This is a temporary fix and this particular branch contains only a revert
for common-pc-64-base, but the same revert should be done repo-wide.

I'll be looking into creating a proper upstream fix for this, but this
gets around the problem for now; this fix was for large-CPU systems and
memory-fragmented conditions.

The following changes since commit 6c1528b2b78d1ec7e75bb7a9880074ec35aa1aa0:

  perf annotate: replace 'expand' with equivalent sed expression (2013-08-22 
14:34:00 -0400)

are available in the git repository at:

  git://git.yoctoproject.org/linux-yocto-contrib.git 
tzanussi/proc_timer_list-revert
  
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=tzanussi/proc_timer_list-revert

Tom Zanussi (2):
  Revert "timer_list: Convert timer list to be a proper seq_file"
  Revert "timer_list: Split timer_list_show_tickdevices"

 kernel/time/timer_list.c | 104 ++-
 1 file changed, 21 insertions(+), 83 deletions(-)

-- 
1.7.11.4

___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 2/2] Revert "timer_list: Split timer_list_show_tickdevices"

[Tom Zanussi]

This reverts commit 60cf7ea849e77c8782dee147cfb8c38d1984236e.

This is a temporary workaround for the dropbearkey hang issue in 3.10.
---
 kernel/time/timer_list.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
index 380a589..af5a7e9 100644
--- a/kernel/time/timer_list.c
+++ b/kernel/time/timer_list.c
@@ -133,6 +133,7 @@ static void print_cpu(struct seq_file *m, int cpu, u64 now)
struct hrtimer_cpu_base *cpu_base = &per_cpu(hrtimer_bases, cpu);
int i;
 
+   SEQ_printf(m, "\n");
SEQ_printf(m, "cpu: %d\n", cpu);
for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {
SEQ_printf(m, " clock %d:\n", i);
@@ -186,7 +187,6 @@ static void print_cpu(struct seq_file *m, int cpu, u64 now)
 
 #undef P
 #undef P_ns
-   SEQ_printf(m, "\n");
 }
 
 #ifdef CONFIG_GENERIC_CLOCKEVENTS
@@ -195,6 +195,7 @@ print_tickdevice(struct seq_file *m, struct tick_device 
*td, int cpu)
 {
struct clock_event_device *dev = td->evtdev;
 
+   SEQ_printf(m, "\n");
SEQ_printf(m, "Tick Device: mode: %d\n", td->mode);
if (cpu < 0)
SEQ_printf(m, "Broadcast device\n");
@@ -229,11 +230,12 @@ print_tickdevice(struct seq_file *m, struct tick_device 
*td, int cpu)
print_name_offset(m, dev->event_handler);
SEQ_printf(m, "\n");
SEQ_printf(m, " retries:%lu\n", dev->retries);
-   SEQ_printf(m, "\n");
 }
 
-static void timer_list_show_tickdevices_header(struct seq_file *m)
+static void timer_list_show_tickdevices(struct seq_file *m)
 {
+   int cpu;
+
 #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
print_tickdevice(m, tick_get_broadcast_device(), -1);
SEQ_printf(m, "tick_broadcast_mask: %08lx\n",
@@ -244,7 +246,12 @@ static void timer_list_show_tickdevices_header(struct 
seq_file *m)
 #endif
SEQ_printf(m, "\n");
 #endif
+   for_each_online_cpu(cpu)
+   print_tickdevice(m, tick_get_device(cpu), cpu);
+   SEQ_printf(m, "\n");
 }
+#else
+static void timer_list_show_tickdevices(struct seq_file *m) { }
 #endif
 
 static int timer_list_show(struct seq_file *m, void *v)
@@ -255,16 +262,12 @@ static int timer_list_show(struct seq_file *m, void *v)
SEQ_printf(m, "Timer List Version: v0.7\n");
SEQ_printf(m, "HRTIMER_MAX_CLOCK_BASES: %d\n", HRTIMER_MAX_CLOCK_BASES);
SEQ_printf(m, "now at %Ld nsecs\n", (unsigned long long)now);
-   SEQ_printf(m, "\n");
 
for_each_online_cpu(cpu)
print_cpu(m, cpu, now);
 
-#ifdef CONFIG_GENERIC_CLOCKEVENTS
-   timer_list_show_tickdevices_header(m);
-   for_each_online_cpu(cpu)
-   print_tickdevice(m, tick_get_device(cpu), cpu);
-#endif
+   SEQ_printf(m, "\n");
+   timer_list_show_tickdevices(m);
 
return 0;
 }
-- 
1.7.11.4

___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 1/2] Revert "timer_list: Convert timer list to be a proper seq_file"

[Tom Zanussi]

This reverts commit b3956a896ea57f25cacd74708b8fab611543a81d.

This is a temporary workaround for the dropbearkey hang issue in 3.10.
---
 kernel/time/timer_list.c | 89 +++-
 1 file changed, 12 insertions(+), 77 deletions(-)

diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
index 3bdf283..380a589 100644
--- a/kernel/time/timer_list.c
+++ b/kernel/time/timer_list.c
@@ -20,13 +20,6 @@
 
 #include 
 
-
-struct timer_list_iter {
-   int cpu;
-   bool second_pass;
-   u64 now;
-};
-
 typedef void (*print_fn_t)(struct seq_file *m, unsigned int *classes);
 
 DECLARE_PER_CPU(struct hrtimer_cpu_base, hrtimer_bases);
@@ -254,101 +247,43 @@ static void timer_list_show_tickdevices_header(struct 
seq_file *m)
 }
 #endif
 
-static inline void timer_list_header(struct seq_file *m, u64 now)
-{
-   SEQ_printf(m, "Timer List Version: v0.7\n");
-   SEQ_printf(m, "HRTIMER_MAX_CLOCK_BASES: %d\n", HRTIMER_MAX_CLOCK_BASES);
-   SEQ_printf(m, "now at %Ld nsecs\n", (unsigned long long)now);
-   SEQ_printf(m, "\n");
-}
-
 static int timer_list_show(struct seq_file *m, void *v)
 {
-   struct timer_list_iter *iter = v;
-   u64 now = ktime_to_ns(ktime_get());
-
-   if (iter->cpu == -1 && !iter->second_pass)
-   timer_list_header(m, now);
-   else if (!iter->second_pass)
-   print_cpu(m, iter->cpu, iter->now);
-#ifdef CONFIG_GENERIC_CLOCKEVENTS
-   else if (iter->cpu == -1 && iter->second_pass)
-   timer_list_show_tickdevices_header(m);
-   else
-   print_tickdevice(m, tick_get_device(iter->cpu), iter->cpu);
-#endif
-   return 0;
-}
-
-void sysrq_timer_list_show(void)
-{
u64 now = ktime_to_ns(ktime_get());
int cpu;
 
-   timer_list_header(NULL, now);
+   SEQ_printf(m, "Timer List Version: v0.7\n");
+   SEQ_printf(m, "HRTIMER_MAX_CLOCK_BASES: %d\n", HRTIMER_MAX_CLOCK_BASES);
+   SEQ_printf(m, "now at %Ld nsecs\n", (unsigned long long)now);
+   SEQ_printf(m, "\n");
 
for_each_online_cpu(cpu)
-   print_cpu(NULL, cpu, now);
+   print_cpu(m, cpu, now);
 
 #ifdef CONFIG_GENERIC_CLOCKEVENTS
-   timer_list_show_tickdevices_header(NULL);
+   timer_list_show_tickdevices_header(m);
for_each_online_cpu(cpu)
-   print_tickdevice(NULL, tick_get_device(cpu), cpu);
+   print_tickdevice(m, tick_get_device(cpu), cpu);
 #endif
-   return;
-}
 
-static void *timer_list_start(struct seq_file *file, loff_t *offset)
-{
-   struct timer_list_iter *iter = file->private;
-
-   if (!*offset) {
-   iter->cpu = -1;
-   iter->now = ktime_to_ns(ktime_get());
-   } else if (iter->cpu >= nr_cpu_ids) {
-#ifdef CONFIG_GENERIC_CLOCKEVENTS
-   if (!iter->second_pass) {
-   iter->cpu = -1;
-   iter->second_pass = true;
-   } else
-   return NULL;
-#else
-   return NULL;
-#endif
-   }
-   return iter;
-}
-
-static void *timer_list_next(struct seq_file *file, void *v, loff_t *offset)
-{
-   struct timer_list_iter *iter = file->private;
-   iter->cpu = cpumask_next(iter->cpu, cpu_online_mask);
-   ++*offset;
-   return timer_list_start(file, offset);
+   return 0;
 }
 
-static void timer_list_stop(struct seq_file *seq, void *v)
+void sysrq_timer_list_show(void)
 {
+   timer_list_show(NULL, NULL);
 }
 
-static const struct seq_operations timer_list_sops = {
-   .start = timer_list_start,
-   .next = timer_list_next,
-   .stop = timer_list_stop,
-   .show = timer_list_show,
-};
-
 static int timer_list_open(struct inode *inode, struct file *filp)
 {
-   return seq_open_private(filp, &timer_list_sops,
-   sizeof(struct timer_list_iter));
+   return single_open(filp, timer_list_show, NULL);
 }
 
 static const struct file_operations timer_list_fops = {
.open   = timer_list_open,
.read   = seq_read,
.llseek = seq_lseek,
-   .release= seq_release_private,
+   .release= single_release,
 };
 
 static int __init init_timer_list_procfs(void)
-- 
1.7.11.4

___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Antwort: RE: Antwort: Re: [meta-intel] Boot failure when using meta-intel and meta-ivi

[Tom Zanussi]

On Mon, 2013-07-29 at 10:05 +0200, Felix01 Fischer wrote:
> "Behrens, Holger"  schrieb am 29.07.2013
> 08:54:40:
> 
> > Von: "Behrens, Holger"  
> > An: Tom Zanussi , Felix01 Fischer 
> > , 
> > Kopie: "meta-in...@yoctoproject.org" , 
> > "yocto@yoctoproject.org" , "genivi-meta-
> > i...@lists.genivi.org"  
> > Datum: 29.07.2013 08:55 
> > Betreff: RE: [yocto] Antwort: Re: [meta-intel] Boot failure when 
> > using meta-intel and meta-ivi 
> > 
> > Hi,
> > 
> > > On Fri, 2013-07-26 at 09:48 +0200, Felix01 Fischer wrote:
> > > > Tom Zanussi  schrieb am 25.07.2013
> 18:57:57:
> > > >
> > > > > Von: Tom Zanussi 
> > > > > An: Felix01 Fischer ,
> > > > > Kopie: yocto@yoctoproject.org, meta-in...@yoctoproject.org,
> genivi-
> > > > > meta-...@lists.genivi.org
> > > > > Datum: 25.07.2013 18:58
> > > > > Betreff: Re: [meta-intel] Boot failure when using meta-intel
> and
> > > > meta-ivi
> > > > >
> > > > > On Thu, 2013-07-25 at 11:00 +0200, Felix01 Fischer wrote:
> > > > > > Hi,
> > > > > > I haven written regarding this issues before. So maybe it
> sounds
> > > > > > familiar :-)
> > > > > >
> > > > > > I'm unable to produce a booting image when combining a
> machine
> > > > from
> > > > > > the meta-intel layer with "DISTRO ?= "poky-ivi-systemd" from
> the
> > > > > > meta-ivi layer.
> > > > > > You will find a photograph of my screen attached, but I will
> > > > describe
> > > > > > the error anyway.
> > > > > >
> > > > > >
> > > > > > Which error do I get?
> > > > > >
> > > > > > When I'm booting my image the machine fails to boot. The
> relevant
> > > > > > information (IMHO) are the lines:
> > > > > >/init: line 98: mount: not found
> > > > > > /init: line 98: mount: not found
> > > > > > /init: line 98: mount: not found
> > > > > > and
> > > > > > cat: can't open '/proc/cmdline': No such file or
> > > > directory
> > > > > > Waiting for removable media...
> > > > > >
> > > > > >
> > > > > > When does the error occur?
> > > > > >
> > > > > > Every image built with the local.conf options
> > > > > > MACHINE ?= "crownbay"ORMACHINE ?=
> "chiefriver"
> > > > > > AND
> > > > > > DISTRO ?= "poky-ivi-systemd"
> > > > > >
> > > > > > failed to boot.
> > > > > >
> > > > > I guess more information is needed to even build this.  Using
> the
> > > > poky
> > > > > commit id in the README, using either meta-intel/master or
> > > > > meta-intel/dylan gives errors like this:
> > > > >
> > > > > trz@elmorro:/usr/local/dev/yocto/ivi-test/build$ bitbake
> foton-image
> > > > > Pseudo is not present but is required, building this first
> before
> > > > the
> > > > > main build
> > > > > Loading cache: 100%
> > > |###|
> > > > ETA:
> > > > > 00:00:00
> > > > > Loaded 1162 entries from dependency cache.
> > > > > ERROR: No recipes available for:
> > > > >
>   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-extended/common-
> > > > > api/dbus_1.6.10.bbappend
> > > > >
>   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/dbus/
> > > > > dbus_1.6.10.bbappend
> > > > >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-connectivity/
> > > > > connman/connman_1.15.bbappend
> > > > >
>   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-graphics/xorg-
> > > > > xserver/xserver-xorg_1.14.0.bbappend
> > > > >
>   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/busybox/
> > > > > busybox_1.21.1.bbappend
> > > > >
>   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/eglibc/
> > > > > eglibc_2.18.bbappend
> > > > >
>   /

Re: [yocto] Antwort: Re: [meta-intel] Boot failure when using meta-intel and meta-ivi

[Tom Zanussi]

On Mon, 2013-07-29 at 06:54 +, Behrens, Holger wrote:
> Hi,
> 
> > On Fri, 2013-07-26 at 09:48 +0200, Felix01 Fischer wrote:
> > > Tom Zanussi  schrieb am 25.07.2013 18:57:57:
> > >
> > > > Von: Tom Zanussi 
> > > > An: Felix01 Fischer ,
> > > > Kopie: yocto@yoctoproject.org, meta-in...@yoctoproject.org, genivi-
> > > > meta-...@lists.genivi.org
> > > > Datum: 25.07.2013 18:58
> > > > Betreff: Re: [meta-intel] Boot failure when using meta-intel and
> > > meta-ivi
> > > >
> > > > On Thu, 2013-07-25 at 11:00 +0200, Felix01 Fischer wrote:
> > > > > Hi,
> > > > > I haven written regarding this issues before. So maybe it sounds
> > > > > familiar :-)
> > > > >
> > > > > I'm unable to produce a booting image when combining a machine
> > > from
> > > > > the meta-intel layer with "DISTRO ?= "poky-ivi-systemd" from the
> > > > > meta-ivi layer.
> > > > > You will find a photograph of my screen attached, but I will
> > > describe
> > > > > the error anyway.
> > > > >
> > > > >
> > > > > Which error do I get?
> > > > >
> > > > > When I'm booting my image the machine fails to boot. The relevant
> > > > > information (IMHO) are the lines:
> > > > >/init: line 98: mount: not found
> > > > > /init: line 98: mount: not found
> > > > > /init: line 98: mount: not found
> > > > > and
> > > > > cat: can't open '/proc/cmdline': No such file or
> > > directory
> > > > > Waiting for removable media...
> > > > >
> > > > >
> > > > > When does the error occur?
> > > > >
> > > > > Every image built with the local.conf options
> > > > > MACHINE ?= "crownbay"ORMACHINE ?= "chiefriver"
> > > > > AND
> > > > > DISTRO ?= "poky-ivi-systemd"
> > > > >
> > > > > failed to boot.
> > > > >
> > > > I guess more information is needed to even build this.  Using the
> > > poky
> > > > commit id in the README, using either meta-intel/master or
> > > > meta-intel/dylan gives errors like this:
> > > >
> > > > trz@elmorro:/usr/local/dev/yocto/ivi-test/build$ bitbake foton-image
> > > > Pseudo is not present but is required, building this first before
> > > the
> > > > main build
> > > > Loading cache: 100%
> > |###|
> > > ETA:
> > > > 00:00:00
> > > > Loaded 1162 entries from dependency cache.
> > > > ERROR: No recipes available for:
> > > >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-extended/common-
> > > > api/dbus_1.6.10.bbappend
> > > >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/dbus/
> > > > dbus_1.6.10.bbappend
> > > >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-connectivity/
> > > > connman/connman_1.15.bbappend
> > > >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-graphics/xorg-
> > > > xserver/xserver-xorg_1.14.0.bbappend
> > > >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/busybox/
> > > > busybox_1.21.1.bbappend
> > > >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/eglibc/
> > > > eglibc_2.18.bbappend
> > > >   /usr/local/dev/yocto/ivi-test/meta-intel/meta-crownbay/recipes-
> > > > kernel/linux/linux-yocto-rt_3.8.bbappend
> > > >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-qt/qt4/qt4-
> > > > embedded_4.8.5.bbappend
> > > >   /usr/local/dev/yocto/ivi-test/meta-intel/common/recipes-graphics/
> > > > mesa/mesa_9.0.2.bbappend
> > > >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/netbase/
> > > > netbase_5.1.bbappend
> > > > ERROR: Command execution failed: Exited with 1
> > > >
> > > > So, please supply the relevant commits for all layers used..
> > > >
> > >
> > > First, thank you for your help.
> > > I guess your meta-ivi is not up to date. You have to "git checkout
> > > 4.0.2", which is the latest meta-ivi release
> > > I have been building non-booting images for quit

Re: [yocto] Antwort: Re: [meta-intel] Boot failure when using meta-intel and meta-ivi

[Tom Zanussi]

On Fri, 2013-07-26 at 09:48 +0200, Felix01 Fischer wrote:
> Tom Zanussi  schrieb am 25.07.2013 18:57:57:
> 
> > Von: Tom Zanussi  
> > An: Felix01 Fischer , 
> > Kopie: yocto@yoctoproject.org, meta-in...@yoctoproject.org, genivi-
> > meta-...@lists.genivi.org 
> > Datum: 25.07.2013 18:58 
> > Betreff: Re: [meta-intel] Boot failure when using meta-intel and
> meta-ivi 
> > 
> > On Thu, 2013-07-25 at 11:00 +0200, Felix01 Fischer wrote:
> > > Hi, 
> > > I haven written regarding this issues before. So maybe it sounds
> > > familiar :-)
> > > 
> > > I'm unable to produce a booting image when combining a machine
> from
> > > the meta-intel layer with "DISTRO ?= "poky-ivi-systemd" from the
> > > meta-ivi layer.
> > > You will find a photograph of my screen attached, but I will
> describe
> > > the error anyway. 
> > > 
> > > 
> > > Which error do I get? 
> > > 
> > > When I'm booting my image the machine fails to boot. The relevant
> > > information (IMHO) are the lines:
> > >/init: line 98: mount: not found 
> > > /init: line 98: mount: not found 
> > > /init: line 98: mount: not found 
> > > and 
> > > cat: can't open '/proc/cmdline': No such file or
> directory 
> > > Waiting for removable media... 
> > > 
> > > 
> > > When does the error occur?
> > > 
> > > Every image built with the local.conf options 
> > > MACHINE ?= "crownbay"ORMACHINE ?= "chiefriver" 
> > > AND 
> > > DISTRO ?= "poky-ivi-systemd" 
> > > 
> > > failed to boot. 
> > > 
> > I guess more information is needed to even build this.  Using the
> poky
> > commit id in the README, using either meta-intel/master or
> > meta-intel/dylan gives errors like this:
> > 
> > trz@elmorro:/usr/local/dev/yocto/ivi-test/build$ bitbake foton-image
> > Pseudo is not present but is required, building this first before
> the
> > main build
> > Loading cache: 100% |###|
> ETA:
> > 00:00:00
> > Loaded 1162 entries from dependency cache.
> > ERROR: No recipes available for:
> >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-extended/common-
> > api/dbus_1.6.10.bbappend
> >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/dbus/
> > dbus_1.6.10.bbappend
> >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-connectivity/
> > connman/connman_1.15.bbappend
> >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-graphics/xorg-
> > xserver/xserver-xorg_1.14.0.bbappend
> >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/busybox/
> > busybox_1.21.1.bbappend
> >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/eglibc/
> > eglibc_2.18.bbappend
> >   /usr/local/dev/yocto/ivi-test/meta-intel/meta-crownbay/recipes-
> > kernel/linux/linux-yocto-rt_3.8.bbappend
> >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-qt/qt4/qt4-
> > embedded_4.8.5.bbappend
> >   /usr/local/dev/yocto/ivi-test/meta-intel/common/recipes-graphics/
> > mesa/mesa_9.0.2.bbappend
> >   /usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/netbase/
> > netbase_5.1.bbappend
> > ERROR: Command execution failed: Exited with 1
> > 
> > So, please supply the relevant commits for all layers used..
> > 
> 
> First, thank you for your help. 
> I guess your meta-ivi is not up to date. You have to "git checkout
> 4.0.2", which is the latest meta-ivi release
> I have been building non-booting images for quite some time now using
> various releases of poky, meta-intel and meta-ivi, so it shouldn't
> rely on one special commit. 
> Currently I'm using "git checkout 4.0.2" for meta-ivi and the dylan
> branch for poky and meta-intel aswell.
> 
OK, with those commits, I was able to get a good build (the README is
also misleading about adding the INCOMPATIBLE_LICENSE line - it doesn't
build if you do what it says).

Anyway, from your error message:
   /init: line 98: mount: not found

it can't find mount, which prompted me to look in the rootfs for 'mount'
and indeed it's not there, so that causes the init script to fail as
above.

The mount command isn't there because meta-ivi applies its own busybox
defconfig.  From that defconfig, we can see that it excludes mount:

# CONFIG_MOUNT is not set

which is why the live image init script can't find mount and fails like

Re: [yocto] [meta-intel] Boot failure when using meta-intel and meta-ivi

[Tom Zanussi]

On Thu, 2013-07-25 at 11:00 +0200, Felix01 Fischer wrote:
> Hi, 
> I haven written regarding this issues before. So maybe it sounds
> familiar :-)
> 
> I'm unable to produce a booting image when combining a machine from
> the meta-intel layer with "DISTRO ?= "poky-ivi-systemd" from the
> meta-ivi layer.
> You will find a photograph of my screen attached, but I will describe
> the error anyway. 
> 
> 
> Which error do I get? 
> 
> When I'm booting my image the machine fails to boot. The relevant
> information (IMHO) are the lines:
>/init: line 98: mount: not found 
> /init: line 98: mount: not found 
> /init: line 98: mount: not found 
> and 
> cat: can't open '/proc/cmdline': No such file or directory 
> Waiting for removable media... 
> 
> 
> When does the error occur?
> 
> Every image built with the local.conf options 
> MACHINE ?= "crownbay"ORMACHINE ?= "chiefriver" 
> AND 
> DISTRO ?= "poky-ivi-systemd" 
> 
> failed to boot. 
> 
I guess more information is needed to even build this.  Using the poky
commit id in the README, using either meta-intel/master or
meta-intel/dylan gives errors like this:

trz@elmorro:/usr/local/dev/yocto/ivi-test/build$ bitbake foton-image
Pseudo is not present but is required, building this first before the
main build
Loading cache: 100% |###| ETA:
00:00:00
Loaded 1162 entries from dependency cache.
ERROR: No recipes available for:
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-extended/common-api/dbus_1.6.10.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/dbus/dbus_1.6.10.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-connectivity/connman/connman_1.15.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-graphics/xorg-xserver/xserver-xorg_1.14.0.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/busybox/busybox_1.21.1.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/eglibc/eglibc_2.18.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-qt/qt4/qt4-embedded_4.8.5.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-intel/common/recipes-graphics/mesa/mesa_9.0.2.bbappend
  
/usr/local/dev/yocto/ivi-test/meta-ivi/recipes-core-ivi/netbase/netbase_5.1.bbappend
ERROR: Command execution failed: Exited with 1

So, please supply the relevant commits for all layers used..

> I have tried builds with meta-ivi excalibur (not 100% sure) and foton
> releases and the master branch aswell 
> Similar applies to poky and meta-intel. I tried the danny and dylan
> releases and the master branch. 
> 
> The boot happens from an USB stick on which I dd'ed
> "foton-image-$MACHINE-$BUILDDATE.hddimg" 
> 
> All other builds are booting fine.
> 
> Addind "EXTRA_IMAGE_FEATURE = "udev-extraconf" did not change this
> behauviour. 
> 
> Building only with meta-intel OR meta-ivi results in a booting image.
> 
Not sure what this means - if using only meta-ivi, which machine are you
building?

Tom


> So, any ideas?
> 
> regards,
> 
> Viele Grüße
> 
> Felix Fischer
> 
> Studentischer Mitarbeiter (VC-D1)
> Vehicle Cockpit Electronics Devices
> 
> IAV GmbH
> Carnotstr. 1
> 10587 BERLIN
> GERMANY
> 
> Phone: +49 30 39978-9540
> Fax:  +49 30 39978-9411
> E-Mail:  
> Internet: http://www.iav.com
> 
> Sitz/Registered Office: Berlin, 
> Registergericht/Registration Court: Amtsgericht Charlottenburg, 
> Registernummer/Company Registration Number: HRB 21 280, 
> Geschäftsführer/Managing Directors: Kurt Blumenröder, Michael
> Schubert, Dr. Rüdiger Goyk
> ___
> meta-intel mailing list
> meta-in...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel


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

Re: [yocto] How to get released BSP that contains meta-intel ?

[Tom Zanussi]

On Thu, 2013-07-18 at 10:01 -0500, Tom Zanussi wrote:
> Hi,
> 
> On Thu, 2013-07-18 at 10:21 -0400, r10kindsofpeople wrote:
> > I've been working with denzil, but decided to try and upgrade to
> > dylan...
> > 
> > 
> > Downloading and installing poky-dylan-9.0.1.tar.bz2 went fine.
> > Finding and downloading meta-crownbay-dylan-9.0.0.tar.bz2 was easy
> > enough.
> > 
> > 
> > But neither of these give me meta-intel.  
> > 
> 
> Actually, what's in the meta-crownbay-dylan tarball is meta-intel, with
> just the meta-crownbay BSP included.  But it looks like there's a
> problem with the naming of the top-level directory in the tarball:
> 
> $ ls meta-crownbay
> binary  common  conf  MAINTAINERS  meta-crownbay  meta-tlk  README
> 
> whereas after untarring, I should have been able to do:
> 
> $ ls meta-intel
> binary  common  conf  MAINTAINERS  meta-crownbay  meta-tlk  README
> 
> Beth or Nitin, can you please fix the tarballs so that the top-level
> directory isn't the meta-BSPname but meta-intel (like they are for the
> previous releases).
> 
> > 
> > So the central question is: how do I find and download a released
> > package that contains meta-intel that's required by meta-crownbay?  A
> 
> If you just rename the top-level directory to meta-intel rather than
> meta-crownbay, things should be fine..
> 

Filed bug 4868 for this.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=4868

Tom

> >  second question is whether I'd have had problems anyway, given that
> > dylan is 9.0.1 and the BSP is 9.0.0. 
> > 
> 
> No, you shouldn't have problems - a given BSP should be good for the
> same major release and all its point releases...
> 
> Thanks,
> 
> Tom
> 
> > 
> > I can do a git of meta-intel, but that apparently gives me a snapshot
> > that doesn't play well with the released poky.  I can do a git of
> > poky, then a git of meta-intel...I still needed to do a bit of
> > tweaking but I could bitbake core-image-minimal.  Now I'm having
> > problems with adt_install, apparently because the scripts all think my
> > release is 1.4+snapshot, which breaks the repository links and the
> > opkg install.  I seem to have gotten around these, too, but if someone
> > has something for me to test using released packages, I'm willing, at
> > the moment, to start from scratch.
> > 
> > 
> > John  
> > 
> > ___
> > 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] How to get released BSP that contains meta-intel ?

[Tom Zanussi]

Hi,

On Thu, 2013-07-18 at 10:21 -0400, r10kindsofpeople wrote:
> I've been working with denzil, but decided to try and upgrade to
> dylan...
> 
> 
> Downloading and installing poky-dylan-9.0.1.tar.bz2 went fine.
> Finding and downloading meta-crownbay-dylan-9.0.0.tar.bz2 was easy
> enough.
> 
> 
> But neither of these give me meta-intel.  
> 

Actually, what's in the meta-crownbay-dylan tarball is meta-intel, with
just the meta-crownbay BSP included.  But it looks like there's a
problem with the naming of the top-level directory in the tarball:

$ ls meta-crownbay
binary  common  conf  MAINTAINERS  meta-crownbay  meta-tlk  README

whereas after untarring, I should have been able to do:

$ ls meta-intel
binary  common  conf  MAINTAINERS  meta-crownbay  meta-tlk  README

Beth or Nitin, can you please fix the tarballs so that the top-level
directory isn't the meta-BSPname but meta-intel (like they are for the
previous releases).

> 
> So the central question is: how do I find and download a released
> package that contains meta-intel that's required by meta-crownbay?  A

If you just rename the top-level directory to meta-intel rather than
meta-crownbay, things should be fine..

>  second question is whether I'd have had problems anyway, given that
> dylan is 9.0.1 and the BSP is 9.0.0. 
> 

No, you shouldn't have problems - a given BSP should be good for the
same major release and all its point releases...

Thanks,

Tom

> 
> I can do a git of meta-intel, but that apparently gives me a snapshot
> that doesn't play well with the released poky.  I can do a git of
> poky, then a git of meta-intel...I still needed to do a bit of
> tweaking but I could bitbake core-image-minimal.  Now I'm having
> problems with adt_install, apparently because the scripts all think my
> release is 1.4+snapshot, which breaks the repository links and the
> opkg install.  I seem to have gotten around these, too, but if someone
> has something for me to test using released packages, I'm willing, at
> the moment, to start from scratch.
> 
> 
> John  
> 
> ___
> 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-intel][PATCH] lms8: handle different host setups

[Tom Zanussi]

On Tue, 2013-06-25 at 17:45 +0100, Ross Burton wrote:
> The configure script looks at the *host* environment to decide where to 
> install
> the init script, so it's location at packaging time can change.
> 
> Signed-off-by: Ross Burton 

Pulled into meta-intel/master.

Thanks,

Tom

> ---
>  common/recipes-bsp/amt/lms8_8.0.0-7.bb |8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/common/recipes-bsp/amt/lms8_8.0.0-7.bb 
> b/common/recipes-bsp/amt/lms8_8.0.0-7.bb
> index fbb4e45..65c413a 100644
> --- a/common/recipes-bsp/amt/lms8_8.0.0-7.bb
> +++ b/common/recipes-bsp/amt/lms8_8.0.0-7.bb
> @@ -26,7 +26,13 @@ INITSCRIPT_PARAMS = "defaults"
>  do_install_append () {
>   mv ${D}/${sbindir}/lms ${D}/${sbindir}/lms8
>   install -d ${D}${sysconfdir}/init.d
> - mv ${D}${sysconfdir}/rc.d/init.d/lms 
> ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
> + # The configure script looks at the host to decide where to put init
> + # scripts, so move it at the same time as renaming it.
> + if test -f ${D}${sysconfdir}/rc.d/init.d/lms ; then
> + mv ${D}${sysconfdir}/rc.d/init.d/lms 
> ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
> + else
> + mv ${D}${sysconfdir}/init.d/lms 
> ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
> + fi
>   sed -i 's/^NAME=lms/NAME=lms8/' 
> ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
>   rmdir ${D}${datadir} || :
>  }


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

Re: [yocto] [meta-intel][PATCH] meta-nuc: don't install lms8 as NUC doesn't support AMT

[Tom Zanussi]

On Tue, 2013-06-25 at 17:47 +0100, Ross Burton wrote:
> The NUC doesn't support Active Management Technology, so don't install lms8 as
> part of the machine recommendations.
> 
> Signed-off-by: Ross Burton 

Pulled into meta-intel/master.

Thanks,

Tom

> ---
>  meta-nuc/conf/machine/nuc.conf |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-nuc/conf/machine/nuc.conf b/meta-nuc/conf/machine/nuc.conf
> index 1404f72..f6ae404 100644
> --- a/meta-nuc/conf/machine/nuc.conf
> +++ b/meta-nuc/conf/machine/nuc.conf
> @@ -19,7 +19,7 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
> ${XSERVER_IA32_I965} \
> "
>  
> -MACHINE_EXTRA_RRECOMMENDS += "lms8 linux-firmware-iwlwifi-6000g2b-6"
> +MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-iwlwifi-6000g2b-6"
>  
>  # disable the serial port configuration
>  SERIAL_CONSOLE = ""


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

Re: [yocto] [meta-intel][PATCH] intel-gpu-tools: add new package

[Tom Zanussi]

On Tue, 2013-06-25 at 17:43 +0100, Ross Burton wrote:
> This package contains numerous useful tools for working with Intel GPUs.  Add 
> a
> patch to install intel_panel_fitter as it's genuinely useful and not just a
> debugging tool.
> 
> Signed-off-by: Ross Burton 

Nice addition.

Pulled into meta-intel/master.

Thanks,

Tom

> ---
>  .../intel-gpu-tools/files/install-fitter.patch |   26 
> 
>  .../intel-gpu-tools/intel-gpu-tools_1.3.bb |   15 +++
>  2 files changed, 41 insertions(+)
>  create mode 100644 
> common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch
>  create mode 100644 
> common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb
> 
> diff --git 
> a/common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch 
> b/common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch
> new file mode 100644
> index 000..2a344c5
> --- /dev/null
> +++ b/common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch
> @@ -0,0 +1,26 @@
> +The panel_fitter is genuinely useful but not installed, so install it.
> +
> +Upstream-Status: Inappropriate
> +Signed-off-by: Ross Burton 
> +
> +Index: tools/Makefile.am
> +===
> +--- a/tools.orig/Makefile.am 2012-08-21 08:30:29.0 +0100
>  b/tools/Makefile.am  2013-06-25 16:52:34.220504579 +0100
> +@@ -17,13 +17,13 @@
> + intel_forcewaked\
> + intel_dpio_read \
> + intel_dpio_write\
> +-intel_l3_parity
> ++intel_l3_parity \
> ++intel_panel_fitter
> + 
> + noinst_PROGRAMS =   \
> + intel_dump_decode   \
> + intel_infoframes\
> +-intel_lid   \
> +-intel_panel_fitter
> ++intel_lid
> + 
> + dist_bin_SCRIPTS = intel_gpu_abrt
> + 
> diff --git a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb 
> b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb
> new file mode 100644
> index 000..893c418
> --- /dev/null
> +++ b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb
> @@ -0,0 +1,15 @@
> +require ${COREBASE}/meta/recipes-graphics/xorg-app/xorg-app-common.inc
> +
> +SUMMARY = "Intel GPU tools"
> +DESCRIPTION = "Variety of small tools for testing intel graphics."
> +
> +SRC_URI += "file://install-fitter.patch"
> +
> +SRC_URI[md5sum] = "67facd6241e26e2c68614728e3a932e9"
> +SRC_URI[sha256sum] = 
> "51d22fdb3d415a1b3b7d0a172c1bb24dec6f16116e80a9ce49873f44527f20a0"
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=0918806acfedc3e8c0488f2dd61616dd"
> +
> +DEPENDS += "libdrm libpciaccess cairo udev glib-2.0"
> +
> +EXTRA_OECONF = "--disable-nouveau --disable-shader-debugger"


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

Re: [yocto] Cedartrail and Dylan?

[Tom Zanussi]

On Thu, 2013-06-20 at 10:26 -0700, Paul D. DeRocco wrote:
> > From: Tom Zanussi
> > 
> > I actually used yocto-bsp to create a brand new cedartrail BSP, called
> > meta-cdt, with just a vesa graphics machine called 'cdt-vesa':
> > 
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi
> /meta-cdt-v0
> > 
> > It built fine here, but it wouldn't boot on my Aspire One, but I
> > couldn't boot either of the official 'danny' cedartrail 
> > (cedartrail and
> > cedartrail-nopvr) images I built either.
> > 
> > I'd be curious if the meta-cdt layer would work for you, though.
> 
> This builds and boots fine on an Intel DN2800MT. Now to start modifying it,
> and seeing what happens.
> 

Great, glad to hear it!  Now I need to figure out what's going on with
the Aspire One, now that I know it should work..

Thanks,

Tom

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

Re: [yocto] Cedartrail and Dylan?

[Tom Zanussi]

On Wed, 2013-06-19 at 16:09 -0700, Paul D. DeRocco wrote:
> > From: Tom Zanussi
> > 
> > On Tue, 2013-06-18 at 20:50 +0100, Chris Tapp wrote:
> > > Hi Tom,
> > > 
> > > On 18 Jun 2013, at 15:04, Tom Zanussi wrote:
> > > 
> > > > On Mon, 2013-06-17 at 16:56 -0700, Paul D. DeRocco wrote:
> > > >> I've been using the Intel meta-cedartrail layer with 
> > Danny 8.0.1. Is this
> > > >> layer likely to be unusable with Dylan 9.0? Or unusable 
> > without lots of
> > > >> tinkering that's probably beyond my abilities?
> > > >> 
> > > >> And if I were to try Dylan, is it best to start from 
> > scratch, in a
> > > >> completely new directory?
> > > >> 
> > > > 
> > > > Hi,
> > > > 
> > > > I believe the main problem would be the graphics driver - 
> > it would need
> > > > porting to the 3.8 kernel - the rest would probably be 
> > straightforward.
> > > > 
> > > > The cedartrail BSP was discontinued following danny, but 
> > I'm cc:ing the
> > > > maintainers in case they might have any further input.
> > > > 
> > > > I was thinking of creating a meta-intel/staging area for 
> > things like
> > > > this i.e. discontinued BSPs that people are still using, 
> > which would
> > > > contain best-effort updates but completely without 
> > promise of any kind
> > > > of support.  If there's enough interest, and there seems 
> > to be judging
> > > > from the number of questions about cedartrail we continue to keep
> > > > getting, I'll try to find some free time to take a stab 
> > at moving it to
> > > > dylan...
> > > 
> > > I'm certainly interested and happy to help out if I can.
> > > 
> > > I also see that ASRock are now making a board 
> > (http://www.asrock.com/IPC/overview.asp?Model=DN2800MT) that 
> > looks exactly the same as the Intel one with the same name 
> > aimed at signage and thin-client applications, so hardware 
> > will be about for a good few years yet,
> > > 
> > 
> > OK, good to know.  The only Cedar Trail hardware I have 
> > access to is the
> > Acer Aspire One I have here - let me see if I can get 
> > something going on
> > that...
> 
> My first attempt to build cedartrail-nopvr finds that meta-intel has an
> unmatched mesa_9.1.3.bbappend, but I suppose I can configure it to ignore
> that since I'm not building graphics. However, meta-cedartrail contains an
> unmatched linux-yocto_3.0.bbappend and linux-yocto-rt_3.0.bbappend. I don't
> know how to fix that.
> 

You should just be able to delete those 3.0 .bbappends - they're of no
use at this point.

I actually used yocto-bsp to create a brand new cedartrail BSP, called
meta-cdt, with just a vesa graphics machine called 'cdt-vesa':

http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/meta-cdt-v0

It built fine here, but it wouldn't boot on my Aspire One, but I
couldn't boot either of the official 'danny' cedartrail (cedartrail and
cedartrail-nopvr) images I built either.

I'd be curious if the meta-cdt layer would work for you, though.

Tom



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

Re: [yocto] Cedartrail and Dylan?

[Tom Zanussi]

On Tue, 2013-06-18 at 20:50 +0100, Chris Tapp wrote:
> Hi Tom,
> 
> On 18 Jun 2013, at 15:04, Tom Zanussi wrote:
> 
> > On Mon, 2013-06-17 at 16:56 -0700, Paul D. DeRocco wrote:
> >> I've been using the Intel meta-cedartrail layer with Danny 8.0.1. Is this
> >> layer likely to be unusable with Dylan 9.0? Or unusable without lots of
> >> tinkering that's probably beyond my abilities?
> >> 
> >> And if I were to try Dylan, is it best to start from scratch, in a
> >> completely new directory?
> >> 
> > 
> > Hi,
> > 
> > I believe the main problem would be the graphics driver - it would need
> > porting to the 3.8 kernel - the rest would probably be straightforward.
> > 
> > The cedartrail BSP was discontinued following danny, but I'm cc:ing the
> > maintainers in case they might have any further input.
> > 
> > I was thinking of creating a meta-intel/staging area for things like
> > this i.e. discontinued BSPs that people are still using, which would
> > contain best-effort updates but completely without promise of any kind
> > of support.  If there's enough interest, and there seems to be judging
> > from the number of questions about cedartrail we continue to keep
> > getting, I'll try to find some free time to take a stab at moving it to
> > dylan...
> 
> I'm certainly interested and happy to help out if I can.
> 
> I also see that ASRock are now making a board 
> (http://www.asrock.com/IPC/overview.asp?Model=DN2800MT) that looks exactly 
> the same as the Intel one with the same name aimed at signage and thin-client 
> applications, so hardware will be about for a good few years yet,
> 

OK, good to know.  The only Cedar Trail hardware I have access to is the
Acer Aspire One I have here - let me see if I can get something going on
that...

Tom

> > Thanks,
> > 
> > Tom
> > 
> > 
> > 
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> 
> Chris Tapp
> 
> opensou...@keylevel.com
> www.keylevel.com
> 
> 
> 


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

Re: [yocto] Cedartrail and Dylan?

[Tom Zanussi]

On Tue, 2013-06-18 at 09:17 -0700, Paul D. DeRocco wrote:
> > From: Tom Zanussi
> > 
> > I believe the main problem would be the graphics driver - it 
> > would need
> > porting to the 3.8 kernel - the rest would probably be 
> > straightforward.
> > 
> > The cedartrail BSP was discontinued following danny, but I'm 
> > cc:ing the maintainers in case they might have any further input.
> 
> Is this graphics issue likely to be a problem if I'm making the non-graphics
> image? My app is headless.
> 

I wouldn't think so - my guess would be that the -nopvr wouldn't be a
problem.

Tom

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

Re: [yocto] Cedartrail and Dylan?

[Tom Zanussi]

On Mon, 2013-06-17 at 16:56 -0700, Paul D. DeRocco wrote:
> I've been using the Intel meta-cedartrail layer with Danny 8.0.1. Is this
> layer likely to be unusable with Dylan 9.0? Or unusable without lots of
> tinkering that's probably beyond my abilities?
> 
> And if I were to try Dylan, is it best to start from scratch, in a
> completely new directory?
> 

Hi,

I believe the main problem would be the graphics driver - it would need
porting to the 3.8 kernel - the rest would probably be straightforward.

The cedartrail BSP was discontinued following danny, but I'm cc:ing the
maintainers in case they might have any further input.

I was thinking of creating a meta-intel/staging area for things like
this i.e. discontinued BSPs that people are still using, which would
contain best-effort updates but completely without promise of any kind
of support.  If there's enough interest, and there seems to be judging
from the number of questions about cedartrail we continue to keep
getting, I'll try to find some free time to take a stab at moving it to
dylan...

Thanks,

Tom



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

Re: [yocto] Problem to compile kernel (enable nfsd)

[Tom Zanussi]

On Wed, 2013-05-29 at 14:19 -0400, Bruce Ashfield wrote:
> On 13-05-29 02:15 PM, Caio wrote:
> > Hello,
> >
> > I'm following the ELC2013 hands-on
> > (https://www.yoctoproject.org/sites/yoctoproject.org/files/elc2013-kernel-lab.pdf)
> > but with poky 9.0.
> >
> > Git Branch (b15bdd842092f2335784c20b8e1b3a0ddcf7996b)
> >
> > In the lab3 I'm trying to compile a kernel from master git tree.
> >
> >
> > But I'm having these trouble to enable NFSD.
> > -WARNING: addon feature "features/nfsd/nfsd-enable" was not found
> >
> 
> There's a bug in master at the moment that is breaking linux-yocto-custom.
> 

Also apparently in the dylan point release i.e post-9.0.0.

Tom

> I'll send it out for merge shortly.
> 
> In the meantime, take this change:
> 
> --- a/meta-yocto/conf/distro/poky-lsb.conf
> +++ b/meta-yocto/conf/distro/poky-lsb.conf
> @@ -7,6 +7,6 @@ DISTRO_FEATURES_append = " pam largefile opengl"
>   PREFERRED_PROVIDER_virtual/libx11 = "libx11"
> 
>   # Ensure the kernel nfs server is enabled
> -KERNEL_FEATURES_append = " features/nfsd/nfsd-enable.scc"
> +KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
> 
> 
> Bruce
> 
> >
> > My log:
> >
> > Build Configuration:
> > BB_VERSION= "1.18.0"
> > BUILD_SYS = "x86_64-linux"
> > NATIVELSBSTRING   = "Ubuntu-12.04"
> > TARGET_SYS= "i586-poky-linux"
> > MACHINE   = "lab3-qemux86"
> > DISTRO= "poky"
> > DISTRO_VERSION= "1.4.1"
> > TUNE_FEATURES = "m32 i586"
> > TARGET_FPU= ""
> > meta
> > meta-yocto
> > meta-yocto-bsp
> > meta-lab3-qemux86 = "dylan:3768675706462c0cc8566ead958161e77e2247e9"
> >
> >
> > NOTE: Resolving any missing task queue dependencies
> > NOTE: Preparing runqueue
> > NOTE: Executing SetScene Tasks
> > NOTE: Executing RunQueue Tasks
> > ERROR: Function failed: do_patch (see
> > /home/caio/yocto/poky/lab3/tmp/work/lab3_qemux86-poky-linux/linux-yocto-custom/3.4.28+gitAUTOINC+c7788792a5e7b0d5d7f96d0766b4cb6112d47d75-r0/temp/log.do_patch.8248
> > for further information)
> > ERROR: Logfile of failure stored in:
> > /home/caio/yocto/poky/lab3/tmp/work/lab3_qemux86-poky-linux/linux-yocto-custom/3.4.28+gitAUTOINC+c7788792a5e7b0d5d7f96d0766b4cb6112d47d75-r0/temp/log.do_patch.8248
> > Log data follows:
> > | DEBUG: Executing shell function do_patch
> > | WARNING: no meta data branch found ...
> > | Already on 'linux-3.4.y'
> > | WARNING: addon feature "features/nfsd/nfsd-enable" was not found
> > | ERROR: required features were not found. aborting
> > | ERROR. Could not update linux-3.4.y
> > | ERROR: Function failed: do_patch (see
> > /home/caio/yocto/poky/lab3/tmp/work/lab3_qemux86-poky-linux/linux-yocto-custom/3.4.28+gitAUTOINC+c7788792a5e7b0d5d7f96d0766b4cb6112d47d75-r0/temp/log.do_patch.8248
> > for further information)
> > ERROR: Task 843
> > (/home/caio/yocto/poky/meta-lab3-qemux86/recipes-kernel/linux/linux-yocto-custom.bb,
> > do_patch) failed with exit code '1'
> > NOTE: Tasks Summary: Attempted 1618 tasks of which 1613 didn't need to
> > be rerun and 1 failed.
> > No currently running tasks (1618 of 1647)
> >
> > Summary: 1 task failed:
> >
> > /home/caio/yocto/poky/meta-lab3-qemux86/recipes-kernel/linux/linux-yocto-custom.bb,
> > do_patch
> > Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> >
> >
> >
> > I tryed configure defconf to
> >
> > CONFIG_NETWORK_FILESYSTEMS=y
> > CONFIG_NFS_FS=y
> > CONFIG_NFS_DEF_FILE_IO_SIZE=4096
> > CONFIG_NFS_V3=y
> > # CONFIG_NFS_V3_ACL is not set
> > CONFIG_NFS_V4=y
> > #CONFIG_NFS_V4_1 is not set
> > CONFIG_ROOT_NFS=y
> > # CONFIG_NFS_USE_LEGACY_DNS is not set
> > CONFIG_NFS_USE_KERNEL_DNS=y
> > CONFIG_NFSD=y
> >
> >
> > The Recipe
> >
> > inherit kernel
> > require recipes-kernel/linux/linux-yocto.inc
> >
> > SRC_URI = 
> > "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;bareclone=1"
> >
> > SRC_URI += "file://defconfig"
> >
> > #SRC_URI += "file://yocto-testmod.patch"
> > #SRC_URI += "file://lab3.cfg"
> >
> > #module_autoload_yocto-testmod = "yocto-testmod"
> >
> > KBRANCH = "linux-3.4.y"
> >
> > LINUX_VERSION ?= "3.4.28"
> > LINUX_VERSION_EXTENSION ?= "-custom"
> >
> > SRCREV="${AUTOREV}"
> >
> > PR = "r0"
> > PV = "${LINUX_VERSION}+git${SRCPV}"
> >
> > COMPATIBLE_MACHINE_lab3-qemux86 = "lab3-qemux86"
> >
> >
> > There's some advice to me?
> >
> > Thank you!
> >
> > Regards,
> >
> > Caio Pereira
> >
> >
> > --
> > --
> > Caio Pereira
> > ___
> > 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] Problem to compile kernel (enable nfsd)

[Tom Zanussi]

On Wed, 2013-05-29 at 15:15 -0300, Caio wrote:
> Hello,
> 
> I'm following the ELC2013 hands-on
> (https://www.yoctoproject.org/sites/yoctoproject.org/files/elc2013-kernel-lab.pdf)
> but with poky 9.0.
> 
> Git Branch (b15bdd842092f2335784c20b8e1b3a0ddcf7996b)
> 
> In the lab3 I'm trying to compile a kernel from master git tree.
> 
> 
> But I'm having these trouble to enable NFSD.
> -WARNING: addon feature "features/nfsd/nfsd-enable" was not found
> 

Hi,

For the labs, you need to use the release specifically mentioned and
that the kernel lab was tested with, which is dylan-9.0.0.

It appears there was an nfsd commit to dylan for the point release that
broke things..

Tom

> 
> My log:
> 
> Build Configuration:
> BB_VERSION= "1.18.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-12.04"
> TARGET_SYS= "i586-poky-linux"
> MACHINE   = "lab3-qemux86"
> DISTRO= "poky"
> DISTRO_VERSION= "1.4.1"
> TUNE_FEATURES = "m32 i586"
> TARGET_FPU= ""
> meta
> meta-yocto
> meta-yocto-bsp
> meta-lab3-qemux86 = "dylan:3768675706462c0cc8566ead958161e77e2247e9"
> 
> 
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: Function failed: do_patch (see
> /home/caio/yocto/poky/lab3/tmp/work/lab3_qemux86-poky-linux/linux-yocto-custom/3.4.28+gitAUTOINC+c7788792a5e7b0d5d7f96d0766b4cb6112d47d75-r0/temp/log.do_patch.8248
> for further information)
> ERROR: Logfile of failure stored in:
> /home/caio/yocto/poky/lab3/tmp/work/lab3_qemux86-poky-linux/linux-yocto-custom/3.4.28+gitAUTOINC+c7788792a5e7b0d5d7f96d0766b4cb6112d47d75-r0/temp/log.do_patch.8248
> Log data follows:
> | DEBUG: Executing shell function do_patch
> | WARNING: no meta data branch found ...
> | Already on 'linux-3.4.y'
> | WARNING: addon feature "features/nfsd/nfsd-enable" was not found
> | ERROR: required features were not found. aborting
> | ERROR. Could not update linux-3.4.y
> | ERROR: Function failed: do_patch (see
> /home/caio/yocto/poky/lab3/tmp/work/lab3_qemux86-poky-linux/linux-yocto-custom/3.4.28+gitAUTOINC+c7788792a5e7b0d5d7f96d0766b4cb6112d47d75-r0/temp/log.do_patch.8248
> for further information)
> ERROR: Task 843
> (/home/caio/yocto/poky/meta-lab3-qemux86/recipes-kernel/linux/linux-yocto-custom.bb,
> do_patch) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 1618 tasks of which 1613 didn't need to
> be rerun and 1 failed.
> No currently running tasks (1618 of 1647)
> 
> Summary: 1 task failed:
>   
> /home/caio/yocto/poky/meta-lab3-qemux86/recipes-kernel/linux/linux-yocto-custom.bb,
> do_patch
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> 
> 
> 
> I tryed configure defconf to
> 
> CONFIG_NETWORK_FILESYSTEMS=y
> CONFIG_NFS_FS=y
> CONFIG_NFS_DEF_FILE_IO_SIZE=4096
> CONFIG_NFS_V3=y
> # CONFIG_NFS_V3_ACL is not set
> CONFIG_NFS_V4=y
> #CONFIG_NFS_V4_1 is not set
> CONFIG_ROOT_NFS=y
> # CONFIG_NFS_USE_LEGACY_DNS is not set
> CONFIG_NFS_USE_KERNEL_DNS=y
> CONFIG_NFSD=y
> 
> 
> The Recipe
> 
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
> 
> SRC_URI = 
> "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;bareclone=1"
> 
> SRC_URI += "file://defconfig"
> 
> #SRC_URI += "file://yocto-testmod.patch"
> #SRC_URI += "file://lab3.cfg"
> 
> #module_autoload_yocto-testmod = "yocto-testmod"
> 
> KBRANCH = "linux-3.4.y"
> 
> LINUX_VERSION ?= "3.4.28"
> LINUX_VERSION_EXTENSION ?= "-custom"
> 
> SRCREV="${AUTOREV}"
> 
> PR = "r0"
> PV = "${LINUX_VERSION}+git${SRCPV}"
> 
> COMPATIBLE_MACHINE_lab3-qemux86 = "lab3-qemux86"
> 
> 
> There's some advice to me?
> 
> Thank you!
> 
> Regards,
> 
> Caio Pereira
> 
> 
> --
> --
> Caio Pereira
> ___
> 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] Yocto Hands-on Kernel Lab dylan (1.4) update available

[Tom Zanussi]

Hi,

I'm happy to announce that the Yocto 'Hands-on Kernel Lab' has been
updated for dylan (Yocto 1.4) and is available here:

https://www.yoctoproject.org/sites/yoctoproject.org/files/kernel-lab-1.4.pdf

The above document contains all the instructions you need to get started
from scratch.

Besides the updates for dylan, this version of the 'Hands-on Kernel Lab'
incorporates a lot of feedback from the users of the previous version.
Special thanks to Robert P. J. Day, who sent a lot of useful comments
and suggestions.

The topics covered are essentially the same as those in the previous
version, with sections covering the use of traditional kernel recipes,
custom kernel recipes, and linux-yocto recipes, along with sections
discussing how to modify the kernel configuration and sources in each of
those cases.  It also discusses how to make use of loadable modules and
how to get them into (and autoloaded into) images, how to make use of
external modules, and how to enable LTSI features.  Additionally, it
discusses overall workflow issues including the use of local clones and
bare local clones.  Finally, it demonstrates how to use the yocto-bsp
and yocto-kernel tools to generate board support packages and use those
tools to configure and patch the kernel in the generated BSP.

See below for a more complete listing of what's covered along with the
lab number covering those topics.

I've run through the lab twice, once on Fedora 17 and once on Ubuntu
12.04, but if you find problems, please let me know...

* Creating and using a traditional kernel recipe (lab1)
* Using 'bitbake -c menuconfig' to modify the kernel configuration and replace 
the defconfig with the new configuration (lab1)
* Adding a kernel module to the kernel source and configuring it as a built-in 
module by adding options to the kernel defconfig (lab1)
* Creating and using a linux-yocto-based kernel (lab2)
* Adding a kernel module to the kernel source and configuring it as a built-in 
module using linux-yocto 'config fragments' (lab2)
* Using the linux-yocto kernel as an LTSI kernel (configuring in an item added 
by the LTSI kernel which is merged into linux-yocto) (lab2)
* Using an arbitrary git-based kernel via the linux-yocto-custom kernel recipe 
(lab3)
* Adding a kernel module to the kernel source of an arbitrary git-based kernel 
and configuring it as a loadable module using 'config fragments' (lab3)
* Actually getting the module into the image and autoloading it on boot (lab3)
* Using a local clone of an arbitrary git-based kernel via the 
linux-yocto-custom kernel recipe to demonstrate a typical development workflow 
(lab4)
* Modifying the locally cloned custom kernel source and verifying the changes 
in the new image (lab4)
* Using a local clone of a linux-yocto- kernel recipe to demonstrate a typical 
development workflow (lab4)
* Modifying the locally cloned linux-yocto kernel source and verifying the 
changes in the new image (lab4)
* Using a 'bare' local clone of a linux-yocto- kernel recipe to demonstrate a 
typical development workflow (lab4)
* Modifying the locally cloned 'bare' linux-yocto kernel source and verifying 
the changes in the new image (lab4)
* Adding and using an external kernel module via a module recipe (lab4)
* Using the 'Yocto BSP Tools' yocto-bsp tool generate a new Yocto BSP (lab5)
* Using the 'Yocto BSP Tools' yocto-kernel tool to add kernel patches and 
config fragments (lab5)

Thanks,

Tom

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

Re: [yocto] [meta-intel] [PATCH] tiny-init: Drop the bbappend

[Tom Zanussi]

Pulled into meta-intel/master.

Thanks,

Tom

On Thu, 2013-05-16 at 12:15 -0700, Darren Hart wrote:
> 
> On 05/15/2013 09:57 PM, Khem Raj wrote:
> > init file which it was providing is ditto as meta-yocto
> > so bbappend is redundant plus it gets rid of following warning
> > for non poky distros.
> > 
> > WARNING: No recipes available for:
> >   /builds1/meta-intel/meta-fri2/recipes-core/tiny-init/tiny-init.bbappend
> > 
> > Signed-off-by: Khem Raj 
> > CC: Darren Hart 
> 
> Acked-by: Darren Hart 
> 
> Thanks Khem!
> 
> > ---
> >  .../recipes-core/tiny-init/tiny-init.bbappend  |6 -
> >  meta-fri2/recipes-core/tiny-init/tiny-init/init|   26 
> > 
> >  2 files changed, 32 deletions(-)
> >  delete mode 100644 meta-fri2/recipes-core/tiny-init/tiny-init.bbappend
> >  delete mode 100644 meta-fri2/recipes-core/tiny-init/tiny-init/init
> > 
> > diff --git a/meta-fri2/recipes-core/tiny-init/tiny-init.bbappend 
> > b/meta-fri2/recipes-core/tiny-init/tiny-init.bbappend
> > deleted file mode 100644
> > index 89416dc..000
> > --- a/meta-fri2/recipes-core/tiny-init/tiny-init.bbappend
> > +++ /dev/null
> > @@ -1,6 +0,0 @@
> > -# Update the init script for the tiny image to manually mount devtmpfs and
> > -# ensure the ttyPCH1 device is available for the console.
> > -
> > -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > - 
> > -PRINC := "${@int(PRINC) + 1}"
> > diff --git a/meta-fri2/recipes-core/tiny-init/tiny-init/init 
> > b/meta-fri2/recipes-core/tiny-init/tiny-init/init
> > deleted file mode 100644
> > index 4b78f01..000
> > --- a/meta-fri2/recipes-core/tiny-init/tiny-init/init
> > +++ /dev/null
> > @@ -1,26 +0,0 @@
> > -#!/bin/sh
> > -
> > -# Mount the Linux kernel virtual filesystems
> > -mount none -t proc /proc
> > -mount none -t sysfs /sys
> > -
> > -# Ensure devtmpfs is mounted, it must be done manually with initramfs
> > -mount none -t devtmpfs /dev
> > -
> > -# Setup PTY infrastructure
> > -mkdir /dev/pts
> > -mount none -t devpts /dev/pts
> > -
> > -ifup lo
> > -
> > -# Allow for distro or local customizations
> > -if [ -f /etc/rc.local ] ; then
> > -   source /etc/rc.local
> > -fi
> > -
> > -# Become session leader and try to find a real tty (e.g. ttyS0)
> > -while true; do
> > -   setsid cttyhack sh
> > -   echo "Console sh exited with $?, respawning..."
> > -   sleep 1
> > -done
> > 
> 


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

Re: [yocto] [PATCH] meta-jasperforest: Fix BBFILES

[Tom Zanussi]

On Tue, 2013-04-23 at 13:26 +0100, Richard Purdie wrote:
> BBFILES is whitespace delimited. If .= used, no whitespace padding is added 
> around
> the addition and this can lead to it being combined with some other part of 
> the
> field, leading to parts of BBFILES mysteriously not being seen.
> 
> For example, I have in my bblayers.conf:
> 
>   /media/build1/poky/meta-intel/meta-emenlow \
>   /media/build1/poky/meta-intel/meta-fri2 \
>   /media/build1/poky/meta-intel/meta-jasperforest \
>   /media/build1/poky/meta-intel/meta-n450 \
>   /media/build1/poky/meta-intel/meta-romley \
> 
> and this results in the warning:
> 
> WARNING: No bb files matched BBFILE_PATTERN_fri2 
> '^/media/build1/poky/meta-intel/meta-fri2/'
> 
> and if I try to build MACHINE=fri2, I get strange errors due to the .bb files
> not being parsed.
> 
> The fix is simply to use +=, just like every other layer.conf file.
> 

Good catch, thanks!

Pulled into meta-intel/master and meta-intel/dylan.

Tom

> Signed-off-by: Richard Purdie 
> ---
>  meta-jasperforest/conf/layer.conf |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-jasperforest/conf/layer.conf 
> b/meta-jasperforest/conf/layer.conf
> index b539733..6d096e7 100644
> --- a/meta-jasperforest/conf/layer.conf
> +++ b/meta-jasperforest/conf/layer.conf
> @@ -2,7 +2,7 @@
>  BBPATH .= ":${LAYERDIR}"
>  
>  # We have a recipes directory, add to BBFILES
> -BBFILES .= "${LAYERDIR}/recipes-*/*/*.bb \
> +BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
>   ${LAYERDIR}/recipes-*/*/*.bbappend"
>  
>  BBFILE_COLLECTIONS += "jasperforest"
> 
> 


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

Re: [yocto] remaining comments on current BSP developers guide

[Tom Zanussi]

On Mon, 2013-04-22 at 12:00 -0400, Robert P. J. Day wrote:
> (again, someone up the food chain can decide what's worth
> processing.)
> 

Thanks for all your comments - I'll submit some patches to the docs when
I get a chance, but see below..

> 1.6.1 Common Features
> 
> * "Both tools [yocto-bsp and yocto-kernel] reside in the scripts/
> subdirectory of the Source Directory." no, they don't, they're in
> meta-yocto/scripts/, so simply sourcing oe-init-build-env isn't
> sufficient to add them to the search path, is it? (i'm guessing it
> used to be, but no longer.)
> 

Not sure what you're looking at to see that.  This is what I have:

[trz@empanada dylan-cur]$ pwd
/home/trz/yocto/dylan-cur
[trz@empanada dylan-cur]$ ls
bitbakeLICENSE   meta-intel meta-yocto-bsp README
build  meta  meta-skeleton  oe-init-build-env  README.hardware
documentation  meta-hob  meta-yocto poky-extrasscripts
[trz@empanada dylan-cur]$ ls -al meta-yocto
total 24
drwxrwxr-x.  6 trz trz 4096 Apr 17 11:31 .
drwxrwxr-x. 14 trz trz 4096 Apr 17 14:20 ..
drwxrwxr-x.  2 trz trz 4096 Apr 17 11:31 classes
drwxrwxr-x.  3 trz trz 4096 Apr 17 11:31 conf
drwxrwxr-x.  5 trz trz 4096 Apr 17 11:31 recipes-core
drwxrwxr-x.  3 trz trz 4096 Apr 17 11:31 recipes-kernel
[trz@empanada dylan-cur]$ ls -al scripts/yocto*
-rwxrwxr-x. 1 trz trz  5302 Apr 17 11:31 scripts/yocto-bsp
-rwxrwxr-x. 1 trz trz 12957 Apr 17 11:31 scripts/yocto-kernel
-rwxrwxr-x. 1 trz trz  4840 Apr 17 11:31 scripts/yocto-layer


No scripts/ in meta-yocto, etc.  So things should work as expected with
sourcing oe-init-build-env, etc.

> 1.6.2 Creating a new BSP Layer ...
> 
>  $ yocto-bsp list karch
>  Architectures available:
>  qemu
>  x86_64
>  i386
>  powerpc
>  arm
>  mips
> 
>   but if you run that, you get the additional arch "layer". where's
> that coming from? is it a holdover from before there was a yocto-layer
> command? i never noticed that before now.
> 

Right, that's a bug - 'layer' does come from the new yocto-layer command
and shouldn't be there..

> * "Assuming you have sourced the environment ..." Again, you don't get
> these utilities in your PATH by sourcing the environment, you need to
> do that manually.
> 

See above..

Tom

> * "...pressing enter and providing an invalid response..." um, what is
> that supposed to say?
> 
> * Point 6.  Do you actually need to include the meta-yocto and
> meta-yocto-bsp layers in this new layer's bblayers.conf file? I don't
> see why but maybe I'm missing something obvious.
> 
> * also, typo "BBLAYERS = ?"
> 
>   i think that's everything.
> 
> rday
> 


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

Re: [yocto] [PATCH][meta-yocto] Fix typoes in BSP help scripts.

[Tom Zanussi]

On Mon, 2013-04-22 at 11:14 -0400, Robert P. J. Day wrote:
> Numerous examples of command "yocto bsp" should be "yocto-bsp".
> 
> Signed-off-by: Robert P. J. Day 
> 

Yes, I'm continually making that mistake, on the command-line as well.
Maybe that means it should have been named something else. ;-)

Acked-by: Tom Zanussi 

> ---
> 
>   i'm assuming i'm not misintgerpreting what's happening here.
> 
> 
> 
> diff --git a/scripts/lib/bsp/help.py b/scripts/lib/bsp/help.py
> index 427b5a0..d152025 100644
> --- a/scripts/lib/bsp/help.py
> +++ b/scripts/lib/bsp/help.py
> @@ -120,13 +120,13 @@ yocto_bsp_create_usage = """
>   bblayers.conf file in order for it to be subsequently seen and
>   modified by the yocto-kernel tool.
> 
> - See 'yocto bsp help create' for more detailed instructions.
> + See 'yocto-bsp help create' for more detailed instructions.
> 
>   NOTE: For x86-based BSPs that select the EMGD xserver, the generated
>   BSP assumes the presence of the meta-intel layer. Ensure the
>   meta-intel layer is present and added to bblayers.conf.
> 
> - See 'yocto bsp help create' for more detailed instructions.
> + See 'yocto-bsp help create' for more detailed instructions.
>  """
> 
>  yocto_bsp_create_help = """
> @@ -216,16 +216,16 @@ yocto_bsp_list_usage = """
>   specified option or property needed by the BSP creation process.
> 
>   The first form enumerates all the possible values that exist and can
> - be specified for the 'karch' parameter to the 'yocto bsp create'
> + be specified for the 'karch' parameter to the 'yocto-bsp create'
>   command.
> 
>   The second form enumerates all the possible properties that exist and
> - must have values specified for them in the 'yocto bsp create' command
> + must have values specified for them in the 'yocto-bsp create' command
>   for the given 'karch'.
> 
>   The third form enumerates all the possible values that exist and can
>   be specified for any of the enumerable properties of the given
> - 'karch' in the 'yocto bsp create' command.
> + 'karch' in the 'yocto-bsp create' command.
> 
>   See 'yocto-bsp help list' for more details.
>  """
> @@ -247,7 +247,7 @@ DESCRIPTION
>  specified option or property needed by the BSP creation process.
> 
>  The first form enumerates all the possible values that exist and
> -can be specified for the 'karch' parameter to the 'yocto bsp
> +can be specified for the 'karch' parameter to the 'yocto-bsp
>  create' command.  Example output for the 'list karch' command:
> 
>  $ yocto-bsp list karch
> @@ -260,7 +260,7 @@ DESCRIPTION
>  qemu
> 
>  The second form enumerates all the possible properties that exist
> -and must have values specified for them in the 'yocto bsp create'
> +and must have values specified for them in the 'yocto-bsp create'
>  command for the given 'karch'.  This command is mainly meant to
>  allow the development user interface alternatives to the default
>  text-based prompting interface.  If the -o option is specified,
> @@ -326,7 +326,7 @@ DESCRIPTION
> 
>  The third form enumerates all the possible values that exist and
>  can be specified for any of the enumerable properties of the given
> -'karch' in the 'yocto bsp create' command.  If the -o option is
> +'karch' in the 'yocto-bsp create' command.  If the -o option is
>  specified, the list of values for the given property, in addition
>  to being displayed, will be written to the specified file as a
>  JSON object.  In this case, the object will consist of the set of
> 
> 
> rday
> 


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

Re: [yocto] clarification about BSP layer names and bblayers.conf file?

[Tom Zanussi]

On Sat, 2013-04-20 at 05:35 -0400, Robert P. J. Day wrote:
> On Fri, 19 Apr 2013, Tom Zanussi wrote:
> 
> > On Fri, 2013-04-19 at 08:37 -0400, Robert P. J. Day wrote:
> >
> > >   second, the BBLAYERS example there seems overly complicated and
> > > potentially confusing to beginners. the fact that meta-yocto is listed
> > > as NON_REMOVABLE might make readers wonder how they're supposed to
> > > know that. why not go with something a lot more people will see, like,
> > > say:
> > >
> > >  BBLAYERS = ?" \  <-- and that looks like a typo
> > >/usr/local/src/yocto/meta \
> > >/usr/local/src/yocto/meta-ti \
> > >"
> > >
> > >  BBLAYERS_NON_REMOVABLE ?= " \
> > >/usr/local/src/yocto/meta \
> > >"
> > >
> >
> > I agree - the whole NON_REMOVABLE thing doesn't add anything and should
> > be removed - the example is just trying to show how to add a BSP layer -
> > the rest just adds potential confusion.  And, yeah, it's a typo..
> 
>   i'll let someone else decide what to do there.
> 
> > >   finally, the passing reference to layers that contain sub-BSP-layers
> > > is good, but show an example, such as the fact that the meta-crownbay
> > > layer.conf file has a dependency on meta-intel:
> > >
> > > ...
> > > LAYERDEPENDS_crownbay = "intel"
> > >
> > >   never pass up the opportunity to reinforce an idea with a few lines
> > > of actual code. :-)
> > >
> >
> > Agreed, but on the other hand we don't really want to be too
> > intel-specific (I know, we have crownbay everywhere else, but anyway..)
> 
>   i was just looking for an example of the kind of hierarchical layer
> structure you find in meta-intel. is there another layer that has that
> kind of structure?
> 

A quick scan of all the layers I have opengrokked here doesn't show any
either, so possibly meta-intel is currently the only example.  If so,
let's use it..

Tom

> rday
> 


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

Re: [yocto] clarification about BSP layer names and bblayers.conf file?

[Tom Zanussi]

On Fri, 2013-04-19 at 08:37 -0400, Robert P. J. Day wrote:
> from section 1.1 of BSP developers guide:
> 
> http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#bsp-layers
> 
> first, it's not actually *required* that a layer name start with the
> prefix "meta-", is it?  pretty sure it's not and, if it isn't, that
> should be made abundantly clear. it's fine to point out that it's a
> well-established convention but it should still be mentioned
> explicitly that it's not necessary.
> 

Right, the naming isn't required and it would make sense to make that
clear, I agree.

>   second, the BBLAYERS example there seems overly complicated and
> potentially confusing to beginners. the fact that meta-yocto is listed
> as NON_REMOVABLE might make readers wonder how they're supposed to
> know that. why not go with something a lot more people will see, like,
> say:
> 
>  BBLAYERS = ?" \  <-- and that looks like a typo
>/usr/local/src/yocto/meta \
>/usr/local/src/yocto/meta-ti \
>"
> 
>  BBLAYERS_NON_REMOVABLE ?= " \
>/usr/local/src/yocto/meta \
>"
> 

I agree - the whole NON_REMOVABLE thing doesn't add anything and should
be removed - the example is just trying to show how to add a BSP layer -
the rest just adds potential confusion.  And, yeah, it's a typo..

>   finally, the passing reference to layers that contain sub-BSP-layers
> is good, but show an example, such as the fact that the meta-crownbay
> layer.conf file has a dependency on meta-intel:
> 
> ...
> LAYERDEPENDS_crownbay = "intel"
> 
>   never pass up the opportunity to reinforce an idea with a few lines
> of actual code. :-)
> 

Agreed, but on the other hand we don't really want to be too
intel-specific (I know, we have crownbay everywhere else, but anyway..)

Tom

>   more shortly ...
> 
> rday
> 


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

Re: [yocto] how strict are released BSP requirements?

[Tom Zanussi]

On Fri, 2013-04-19 at 08:19 -0400, Robert P. J. Day wrote:
> (aside: currently going through yocto BSP developer's guide with my
> proofreader's beanie on so be prepared for a few BSP-related questions
> today. you've been warned.)
> 
>   in section on BSP requirements:
> 
> http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#released-bsp-requirements
> 
> there are alleged requirements like the existence of README and
> README.sources files, but it seems lots of layers at
> http://layers.openembedded.org/layerindex/ don't have one or the other
> of those files. could that explanation be refined a bit? or should
> those layers suck it up and add all files that are allegedly
> "required"?
> 

I don't think there's a requirement that the layerindex contain only
Yocto-compliant or released BSP layers, so talking about Yocto BSP
requirements doesn't really apply...

For Yocto-compliant BSPs, yes, the README is required.

For released BSPs that contain binary images, README.sources is
required, but since binary images are only recommended (see 1.3.2, this
requirement should be moved from the required section to the recommended
if binary images are included).

In practice, both files are typically added to a BSP, so if images are
shipped, they're covered.

Tom

> rday
> 


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

Re: [yocto] couple questions about kernel dev manual, section 2

[Tom Zanussi]

On Sat, 2013-04-13 at 11:20 -0400, Robert P. J. Day wrote:
> some oddities in section 2.2.1 of the current kernel dev manual.
> first, there's:
> 
> "The append file should initially contain the following text:
> 
>  FILESEXTRAPATHS := "${THISDIR}/${PN}"
> 
>   i was under the impression that the standard line would be:
> 
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> 
> would it not? to make sure you can support potential layers on top of
> layers, no?  if you absolutely *know* that won't happen, then, sure,
> that will work, but i think the wording above is unnecessarily
> restrictive.
> 

Right, that should be changed to match the recommendation in the Poky
Reference manual.

>   also, right underneath that, one reads:
> 
> "If you add any new files that modify the kernel recipe, you need to
> place them in your layer in the following area:
> 
>  /recipes-kernel/linux/linux-yocto/"
> 
> IIRC, you *can* put them there but you don't *need* to. in fact, tom
> zanussi's kernel labs place extra files simply under a "files/"
> subdirectory (after setting FILESEXTRAPATHS to pick up that
> directory). so, again, some wording that is unnecessarily strong and
> somewhat misleading.
> 
>   thoughts?
> 

That text assumes you've used (the corrected) from the paragraph above:

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

which means you do need to put the files in the linux-yocto/ subdir (for
a linux-yocto bbappend), since we're dealing with a .bbappend here.

If we were talking about a recipe, then yes, we wouldn't *need* to put
them there but could also put them in any of the default subdirs such as
files/.  There's a little more discussion about it here:

https://lists.yoctoproject.org/pipermail/yocto/2013-February/014419.html

Seems like it might be good to explicitly explain all this or at least
point out the difference and help avoid the confusion...

Tom

> rday
> 


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

Re: [yocto] working my way through the kernel hands-on labs finally

[Tom Zanussi]

On Tue, 2013-04-09 at 18:06 -0400, Trevor Woerner wrote:
> On Tue, Apr 9, 2013 at 5:46 PM, Robert P. J. Day  
> wrote:
> >   ok, so what am i looking for?
> 
> I couldn't get lab3 to work fully unless I switched from package_ipk
> to package_rpm. The module would get built and included in the image,
> but it wasn't being loaded automatically during boot. At the time I
> tried against the master HEAD and everything worked fine, so whatever
> it is I think I've found, it has been fixed (this is only a
> danny-8.0.1 problem).
> 
> https://lists.yoctoproject.org/pipermail/yocto/2013-February/014424.html
> 
> When I mentioned it, it didn't seem to make sense that the choice of
> packaging should affect something like this. But I tried it a couple
> times on my machine and could reproduce it. I don't think anyone else
> tried reproducing it.

I believe I tried and couldn't reproduce it.  But if someone does
reproduce it, please file a bug detailing the *exact* steps needed to
reproduce.

Thanks,

Tom

> 
> This might be of interest to anyone still using danny.
> ___
> 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] working my way through the kernel hands-on labs finally

[Tom Zanussi]

On Mon, 2013-04-08 at 11:41 -0400, Robert P. J. Day wrote:
> finally have the time to work my way through the ELC 2013 hands on
> kernel labs described here:
> 
> https://www.yoctoproject.org/tools-resources/presentations/working-kernel
> 
> since i'll almost certainly use some of them in my next yocto course,
> so the occasional question for anyone who's already been down this
> road.  start with lab 1.
> 
>   the doc mentions including the meta-yocto and meta-yocto-bsp layers
> -- are those strictly necessary? the layer.conf definition file for
> the lab1 layer doesn't list those layers as dependencies. what will
> happen if i leave them out? what's the policy on explicitly listing
> dependencies on those two layers in a new layer?
> 

The bblayers.conf for the labs is just the bblayers.conf that gets
generated the first time you source oe-init-build-env in poky, which is
what the lab is based on.  You shouldn't need those layers - the BSPs
should work fine outside of poky, but since this is a yocto lab and it
uses poky, there's no need to make a point of removing them - actually,
I haven't tried removing those layers - meta-yocto-bsp could certainly
be removed since it's all machine-specific to existing BSPs, but it's
easy enough to remove them and see...

>   also, just doing a basic fetch for lab1 produces:
> 
> ERROR: QA Issue:
> /home/rpjday/yocto/k_lab/layers/meta-lab1-qemux86/recipes-kernel/linux/linux_3.0.18.bb:
> Variable FILES is set as not being package specific, please fix this.
> 
>   is that deliberate? something that will be resolved later in the
> lab as part of an exercise? just curious.
> 

The labs are and should be targeted to a specific release for exactly
the reason you just discovered - in this case, the main metadata
promoted various QA Issues into errors immediately following the
release.   In this case you were lucky and hit an example of something
obvious, most of the time it's not that obvious - basically if you do
anything outside of what's specified in the labs, especially working
from master, all bets are off...

Tom

> rday
> 


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

Re: [yocto] This one can't be me...

[Tom Zanussi]

On Sat, 2013-04-06 at 11:20 -0700, Paul D. DeRocco wrote:
> > From: Tom Zanussi
> > 
> > It looks like the problem is a bad SRCREV for the meta branch in the
> > -nopvr machine in the cedartrail danny tarball.  Try changing the
> > following line in
> > meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend:
> > 
> > SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= 
> > "a4ac64fe873f08ef718e2849b88914725dc99c1c"
> > 
> > to
> > 
> > SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= 
> > "bf5ee4945ee6d748e6abe16356f2357f76b5e2f0"
> > 
> > Changing that got me a .config with the correct CONFIG_BLK_DEV_RAM
> > setting.
> 
> Ta-da! That fixed it.
> 
> I'm glad the subject of this thread didn't come back to bite me.
> 
> Thanks so much for your time in figuring this out.
> 

Sure, glad that worked out...

And of course the cedartrail tarball should be updated as soon as
possible with at least that change - this shouldn't have been a problem
in the first place (also should add the missing preferred provider and
avoid the other warning as well).  Cc:ing the maintainer for that...

Tom



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

Re: [yocto] This one can't be me...

[Tom Zanussi]

On Fri, 2013-04-05 at 23:48 -0500, Tom Zanussi wrote:
> On Fri, 2013-04-05 at 21:15 -0700, Paul D. DeRocco wrote:
> > > From: Tom Zanussi [mailto:tom.zanu...@intel.com] 
> > > 
> > > I'm seeing the same thing here (# CONFIG_BLK_DEV_RAM is not set) with
> > > your bblayers and local.conf.  For some reason the base and
> > > standard .cfgs aren't being applied to the .config.  I'll have to dig
> > > around further as time permits over the weekend...
> > 
> > Thanks, although this might be floobydust. I've nuked the _entire_ build
> > tree, included downloads, and am trying a rebuild from scratch, but that
> > will take until tomorrow morning to complete, since I'm doing the build on
> > an Atom. If it somehow solves the problem, I'll let you know, so you don't
> > waste your time chasing unicorns. But if it doesn't solve the problem, your
> > help would definitely be appreciated. I've been trying to get a build, any
> > build, to boot for a really long time now.
> > 
> 
> My guess is there's a real problem here, since I'm able to reproduce it
> with my own downloads dir and a rebuild from scratch.  Now that I have a
> reproducer, I'm pretty sure we'll be able to nail down the problem and
> at least get the kernel part right - if the kernel is missing config
> like this it just won't boot, plain and simple, so we need to get past
> that first and chances are it will be smoother sailing after that...
> 

It looks like the problem is a bad SRCREV for the meta branch in the
-nopvr machine in the cedartrail danny tarball.  Try changing the
following line in
meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend:

SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= 
"a4ac64fe873f08ef718e2849b88914725dc99c1c"

to

SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= 
"bf5ee4945ee6d748e6abe16356f2357f76b5e2f0"

Changing that got me a .config with the correct CONFIG_BLK_DEV_RAM
setting.

Tom

> Tom
> 
> ___
> 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] This one can't be me...

[Tom Zanussi]

On Fri, 2013-04-05 at 21:15 -0700, Paul D. DeRocco wrote:
> > From: Tom Zanussi [mailto:tom.zanu...@intel.com] 
> > 
> > I'm seeing the same thing here (# CONFIG_BLK_DEV_RAM is not set) with
> > your bblayers and local.conf.  For some reason the base and
> > standard .cfgs aren't being applied to the .config.  I'll have to dig
> > around further as time permits over the weekend...
> 
> Thanks, although this might be floobydust. I've nuked the _entire_ build
> tree, included downloads, and am trying a rebuild from scratch, but that
> will take until tomorrow morning to complete, since I'm doing the build on
> an Atom. If it somehow solves the problem, I'll let you know, so you don't
> waste your time chasing unicorns. But if it doesn't solve the problem, your
> help would definitely be appreciated. I've been trying to get a build, any
> build, to boot for a really long time now.
> 

My guess is there's a real problem here, since I'm able to reproduce it
with my own downloads dir and a rebuild from scratch.  Now that I have a
reproducer, I'm pretty sure we'll be able to nail down the problem and
at least get the kernel part right - if the kernel is missing config
like this it just won't boot, plain and simple, so we need to get past
that first and chances are it will be smoother sailing after that...

Tom

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

Re: [yocto] This one can't be me...

[Tom Zanussi]

On Fri, 2013-04-05 at 18:34 -0500, Tom Zanussi wrote:
> On Fri, 2013-04-05 at 11:48 -0700, Paul D. DeRocco wrote:
> > > From: Bodke, Kishore K
> > > 
> > > Here are the config parameters for the clean build that I am 
> > > doing now.
> > > 
> > > kishore@kishore-desktop:/usr/local/src/cedartrail/build/tmp/wo
> > rk/cedartrail_nopvr-poky-linux/linux-yocto-3.0.32+git1>
> > +bf5ee4945ee6d748e6abe16356f2357f76b5e2f0_1+1e79e03d115ed17788
> > 2ab53909a4f3555e434833-r4.1/linux-cedartrail-nopvr-standard-build$ grep >
> > BLK_DEV_RAM .config
> > > CONFIG_BLK_DEV_RAM=y
> > > CONFIG_BLK_DEV_RAM_COUNT=16
> > > CONFIG_BLK_DEV_RAM_SIZE=4096
> > > 
> > > I don't understand how these are missing in your build?  
> > > BLK_DEV_RAM are enabled for Cedartrail-nopvr build.
> > > 
> > > What did you do different?
> > 
> > I don't know. I detailed the steps I took. I still have
> > 
> > # CONFIG_BLK_DEV_RAM is not set
> > 
> > Does the order of the layers in bblayers.conf matter? Is it possible that
> > something in the past fetched a different version of something, and it's
> > sitting in my downloads tree and screwing things up?
> > 
> > I'm sending you the two build log files separately, so that they don't go
> > out to the entire list.
> > 
> 
> Can you send those to me as well, along with your entire bblayers.conf
> and local.conf?
> 

I'm seeing the same thing here (# CONFIG_BLK_DEV_RAM is not set) with
your bblayers and local.conf.  For some reason the base and
standard .cfgs aren't being applied to the .config.  I'll have to dig
around further as time permits over the weekend...

Tom

> Thanks,
> 
> Tom
> 


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

Re: [yocto] This one can't be me...

[Tom Zanussi]

On Fri, 2013-04-05 at 11:48 -0700, Paul D. DeRocco wrote:
> > From: Bodke, Kishore K
> > 
> > Here are the config parameters for the clean build that I am 
> > doing now.
> > 
> > kishore@kishore-desktop:/usr/local/src/cedartrail/build/tmp/wo
> rk/cedartrail_nopvr-poky-linux/linux-yocto-3.0.32+git1>
> +bf5ee4945ee6d748e6abe16356f2357f76b5e2f0_1+1e79e03d115ed17788
> 2ab53909a4f3555e434833-r4.1/linux-cedartrail-nopvr-standard-build$ grep >
> BLK_DEV_RAM .config
> > CONFIG_BLK_DEV_RAM=y
> > CONFIG_BLK_DEV_RAM_COUNT=16
> > CONFIG_BLK_DEV_RAM_SIZE=4096
> > 
> > I don't understand how these are missing in your build?  
> > BLK_DEV_RAM are enabled for Cedartrail-nopvr build.
> > 
> > What did you do different?
> 
> I don't know. I detailed the steps I took. I still have
> 
>   # CONFIG_BLK_DEV_RAM is not set
> 
> Does the order of the layers in bblayers.conf matter? Is it possible that
> something in the past fetched a different version of something, and it's
> sitting in my downloads tree and screwing things up?
> 
> I'm sending you the two build log files separately, so that they don't go
> out to the entire list.
> 

Can you send those to me as well, along with your entire bblayers.conf
and local.conf?

Thanks,

Tom


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

Re: [yocto] perf build breaks in poky master branch

[Tom Zanussi]

On Tue, 2013-03-19 at 14:06 +0100, Maxin B. John wrote:
> Hi,
> 
> Perf build fails while trying to build core-image-minimal for qemux86, 

Hi,

Richard has just pushed a fix for a thinko in the patch, please pull and
try again.

Tom

> $ git clone git://git.yoctoproject.org/poky
> $ cd poky
> $ source oe-init-build-env
> $ bitbake core-image-minimal
> Pseudo is not present but is required, building this first before the main 
> build
> Loading cache: 100%
> |###|
> ETA:  00:00:00
> Loaded 347 entries from dependency cache.
> ERROR: ExpansionError during parsing
> /home/majo/master/poky/meta/recipes-kernel/perf/perf.bb:
> Failure expanding variable do_package: ExpansionError: Failure
> expanding variable do_package, expression was
> bb.data.setVar('PKGV',
> '${@get_kernelversion('/home/majo/master/poky/build/tmp/sysroots/qemux86/usr/src/kernel').split("-")[0]}',
> d)
> # Change the following version to cause sstate to invalidate the
> # package
> # cache.  This is useful if an item this class depends on changes
> # in a
> # way that the output of this class changes.  rpmdeps is a good
> # example
> # as any change to rpmdeps requires this to be rerun.
> # PACKAGE_BBCLASS_VERSION = "1"
> 
> # Init cachedpath
> global cpath
> cpath = oe.cachedpath.CachedPath()
> 
> 
> ###
> # Sanity test the setup
> 
> ###
> 
> packages = (d.getVar('PACKAGES', True) or "").split()
> if len(packages) < 1:
> bb.debug(1, "No packages to build, skipping do_package")
> return
> 
> workdir = d.getVar('WORKDIR', True)
> outdir = d.getVar('DEPLOY_DIR', True)
> dest = d.getVar('D', True)
> dvar = d.getVar('PKGD', True)
> pn = d.getVar('PN', True)
> 
> if not workdir or not outdir or not dest or not dvar or not pn:
> bb.error("WORKDIR, DEPLOY_DIR, D, PN and PKGD all must be
> defined, unable to package")
> return
> 
> bb.build.exec_func("package_get_auto_pr", d)
> 
> 
> ###
> # Optimisations
> 
> ###
> 
> # Contunually rexpanding complex expressions is inefficient,
> # particularly when
> # we write to the datastore and invalidate the expansion cache.
> # This code
> # pre-expands some frequently used variables
> 
> def expandVar(x, d):
> d.setVar(x, d.getVar(x, True))
> 
> for x in 'PN', 'PV', 'BPN', 'TARGET_SYS', 'EXTENDPRAUTO':
> expandVar(x, d)
> 
> 
> ###
> # Setup PKGD (from D)
> 
> ###
> 
> for f in (d.getVar('PACKAGEBUILDPKGD', True) or '').split():
> bb.build.exec_func(f, d)
> 
> 
> ###
> # Split up PKGD into PKGDEST
> 
> ###
> 
> cpath = oe.cachedpath.CachedPath()
> 
> for f in (d.getVar('PACKAGESPLITFUNCS', True) or '').split():
> bb.build.exec_func(f, d)
> 
> 
> ###
> # Process PKGDEST
> 
> ###
> 
> # Build global list of files in each split package
> global pkgfiles
> pkgfiles = {}
> packages = d.getVar('PACKAGES', True).split()
> pkgdest = d.getVar('PKGDEST', True)
> for pkg in packages:
> pkgfiles[pkg] = []
> for walkroot, dirs, files in cpath.walk(pkgdest + "/" + pkg):
> for file in files:
> pkgfiles[pkg].append(walkroot + os.sep + file)
> 
> for f in (d.getVar('PACKAGEFUNCS', True) or '').split():
> bb.build.exec_func(f, d)
>  which triggered exception AttributeError: 'NoneType' object has no
> attribute 'split'
> NOTE: Error during finalise of
> /home/majo/master/poky/meta/recipes-kernel/perf/perf.bb
> ERROR: Command execution failed: Exited with 1
> 
> Summary: There were 2 ERROR messages shown, returning a non-zero exit
> code.
>   


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

Re: [yocto] Updated Yocto Hands-on Kernel Lab available

[Tom Zanussi]

On Tue, 2013-02-19 at 22:34 -0500, Trevor Woerner wrote:
> Following up on a hunch, after reading Pierre Ficheux's email from
> earlier today, I realized that by default I always switch my build's
> PACKAGE_CLASSES to ipk simply because this packaging takes the least
> amount of build time. Sure enough, when working on lab3 I had switched
> to ipk and it didn't work. Switching PACKAGE_CLASSES to rpm and doing
> nothing else but rebuilding, everything worked. I tried twice more
> switching between ipk and rpm and anytime ipk is used the module is
> not automatically installed, but with rpm it is.

Interesting - I wouldn't have thought of looking at that as a source of
the problem.  I'll try it out myself and file a bug if it turns out to
be the problem.  Thanks for that info!

Tom

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

Re: [yocto] Updated Yocto Hands-on Kernel Lab available

[Tom Zanussi]

On Tue, 2013-02-19 at 05:31 -0500, Trevor Woerner wrote:
> On Tue, Feb 19, 2013 at 12:31 AM, Tom Zanussi  wrote:
> > So when you say it doesn't work, you mean the module autoload didn't
> > work, but everything else did?
> 
> Yes, exactly.
> 
> > Did you do the 'bump the PR' step after
> > you uncommmented the module autoload statement?
> 
> Yes, I even bumped it twice :-) But even if I forgot to bump the PR
> number, when I deleted tmp/sstate/etc and started a fresh build, it
> should have worked then?
> 

It really should have, yes.

> > If that's not it, then I don't know what you say - I tested it with
> > danny and it worked fine for me.  I can try running through it again to
> > verify again, but it really should work...
> 
> Thanks for your comments. I'll guess I'll have to try it all again.
> Maybe I somehow checked out the wrong version. Like I said, performing
> the same steps against yesterday's master worked completely as
> expected.

I'll go through it here as well as soon as I can and let you know...

Tom

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

Re: [yocto] Updated Yocto Hands-on Kernel Lab available

[Tom Zanussi]

On Mon, 2013-02-18 at 18:50 -0500, Trevor Woerner wrote:
> I can't figure out what I'm doing wrong, but I can't get lab3 to work.
> 
> Following the instructions in the pdf I first tried doing lab3
> incrementally (build/test, build/test, build/test) and it didn't work.
> Then I tried deleting (tmp, sstate, etc), trying again, and it still
> didn't work.
> 
> Build Configuration:
> BB_VERSION= "1.16.0"
> TARGET_ARCH   = "i586"
> TARGET_OS = "linux"
> MACHINE   = "lab3-qemux86"
> DISTRO= "poky"
> DISTRO_VERSION= "1.3"
> TUNE_FEATURES = "m32 i586"
> TARGET_FPU= ""
> meta
> meta-yocto
> meta-yocto-bsp
> meta-lab3-qemux86 = "danny:45f95b5f3381097672dd43077f267aa716a02b4c"
> 
> I then copied the meta-lab3-qemux86 layer to where I was working with
> the master branch of poky (hmm... I guess I could have just edited
> bblayers.conf without needing the hassle of the copy), retried the
> exercise, and it worked.
> 
> Build Configuration:
> BB_VERSION= "1.17.1"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "SUSE-LINUX-12.2"
> TARGET_SYS= "i586-poky-linux"
> MACHINE   = "lab3-qemux86"
> DISTRO= "poky"
> DISTRO_VERSION= "1.3+snapshot-20130218"
> TUNE_FEATURES = "m32 i586"
> TARGET_FPU= ""
> meta
> meta-yocto
> meta-yocto-bsp
> meta-lab3-qemux86 = "master:c7b23ab68aafc04d9830ef318015912e5d4f0672"
> 
> Note that the above information is a bit misleading.
> "meta-lab3-qemux86" is just a plain directory without any .git so
> there is no "master" or "danny" of "meta-lab3-qemux86". The "master"
> and "danny" branches are of the enclosing poky repository.
> 
> In the case where it doesn't work, the module is built and included in
> the image, but it isn't loaded automatically during boot. Working off
> master, the module is loaded during boot automatically.

So when you say it doesn't work, you mean the module autoload didn't
work, but everything else did?  Did you do the 'bump the PR' step after
you uncommmented the module autoload statement?

If that's not it, then I don't know what you say - I tested it with
danny and it worked fine for me.  I can try running through it again to
verify again, but it really should work...

Tom


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

Re: [yocto] Fwd: Updated Yocto Hands-on Kernel Lab available

[Tom Zanussi]

On Sun, 2013-02-17 at 21:16 -0500, Trevor Woerner wrote:
> ...sorry, I meant to CC the list too
> 
> 
> -- Forwarded message --
> From: Trevor Woerner 
> Date: Sun, Feb 17, 2013 at 9:15 PM
> Subject: Re: [yocto] Updated Yocto Hands-on Kernel Lab available
> To: Tom Zanussi 
> 
> 
> Hi Tom,
> 
> I can see how the kernel *.bb files get pulled in due to the following
> line in each lab's layer configuration (${LAYERDIR}/conf/layer.conf):
> 
> BBFILES := "... ${LAYERDIR}/recipes-*/*/*.bb ..."
> 
> Since the *.bb files are located under
> ${LAYERDIR}/recipes-kernel/linux/.bb this matched the above
> pattern.
> 
> What I can't figure out is why, for example, in lab1 are the kernel
> patch files located in
> 
> ${LAYERDIR}/recipes-kernel/linux/linux
> 
> while the kernel patch files for lab2 are in
> 
> ${LAYERDIR}/recipes-kernel/linux/files
> 
> Does bitbake find the patch files for lab1 in a subdirectory called
> "linux" because the recipe's name is linux_3.0.18.bb? Because I don't
> see anything in that particular recipe which would suggest it
> (bitbake) should look there (linux). And when I go to lab2 and rename
> the "files" directory to "linux-yocto" the build doesn't work, so this
> behaviour would seem to discount the belief that a patch directory
> name can take on the recipe name and be found.
> 

Hi,

Yes, in lab1 bitbake finds the patch files because they're in the
'linux' subdirectory.  It should also be able to find them if you
renamed that directory to 'linux-3.0.18', and it would also find them in
the 'files' directory.  These subdirectories are added to FILESPATH in
base.bbclass:

FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", 
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"

Those are relative to a .bb, which is what we have in lab1 - the kernel
recipe is linux_3.0.18.bb.

In lab2, we have a linux-yocto_3.4.bbappend file rather than a .bb file.

If you look at the .bbappend, you can see:

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

which is what we need to add to the .bbappend to get bitbake to look in
the 'files' subdirectory under the .bbappend - since the FILESPATH is
relative to the base recipe in meta/, linux-yocto_3.4.bb, and not
our .bbappend, bitbake won't find the files under our .bbappend unless
we add our .bbappend's 'files' subdir to FILESPATH via FILESEXTRAPATHS. 

If you wanted to change the name of the directory under the .bbappend to
'linux-yocto', you could just use:

FILESEXTRAPATHS_prepend := "${THISDIR}/linux-yocto:"

or better:

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

Tom

> Best regards,
> Trevor
> ___
> 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] kernel menuconfig unusable Was: Updated Yocto Hands-on Kernel Lab available

[Tom Zanussi]

On Sun, 2013-02-17 at 16:22 -0500, Trevor Woerner wrote:
> On Fri, Feb 15, 2013 at 9:29 PM, Tom Zanussi  wrote:
> > I'm happy to announce that an updated version of the Yocto 'Hands-on
> > Kernel Lab' has been released and is available here:
> 
> This is awesome, and much appreciated (especially by those of us who
> can't make it out to these events).
> 
> Following the lab, however, I very quickly ran into the dreaded
> "kernel menuconfig unusable" issue. Is there any way Liang Li's
> suggested fix[1] could make it into mainline and the danny branch
> which is used for these labs? Is there a better fix? Is there another
> way around this issue, perhaps with a pure conf/local.conf setting?
> 

Yeah, I ran into this too on Fedora 17, but not Ubuntu.  I thought it
was a local thing and basically 'powered through it' and changed the
settings, knowing I was seeing double.

I don't know what the proper fix for this is - if it's the patch you
pointed to, I'm not sure why it wasn't pulled in.  If not, I guess a bug
should be opened for it.

Tom

> Thanks and best regards,
> Trevor
> 
> [1] 
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-August/027130.html
> 
> NOTE: simply setting OE_TERMINAL to "xterm" doesn't fix the problem,
> it only changes the terminal :-)
> ___
> 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] [PATCH 0/2][meta-intel] Remove Cedartrail BSP

[Tom Zanussi]

On Fri, 2013-02-08 at 14:34 -0800, kishore.k.bo...@intel.com wrote:
> From: Kishore Bodke 
> 
> Hi All,
> 
> This patch set is to remove Cedartrail BSP from
> meta-intel/master.
> Cedartrail BSP will be no longer supported in Yocto 
> from 1.4 release.
> 
> Please pull these patches into meta-intel/master.
> 

Pulled into meta-intel/master.

> Thanks
> Kishore.
> 
> The following changes since commit 575f93dd4ba1fb9aca8a58dc66e9066eca0a3925:
> 
>   meta-intel: remove kernel AUTOREVs (2013-02-04 10:39:06 -0600)
> 
> are available in the git repository at:
> 
>   git://git.pokylinux.org/meta-intel-contrib kishore/cedartrail_remove
>   
> http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=kishore/cedartrail_remove
> 
> Kishore Bodke (2):
>   Cedartrail: Remove Cedartrail BSP
>   meta-intel: Update the MAINTAINERS list.
> 
>  MAINTAINERS|4 -
>  meta-cedartrail/COPYING.MIT|   17 --
>  meta-cedartrail/README |  199 
> 
>  meta-cedartrail/README.sources |   17 --
>  meta-cedartrail/conf/layer.conf|   12 --
>  meta-cedartrail/conf/machine/cedartrail-nopvr.conf |   21 ---
>  meta-cedartrail/conf/machine/cedartrail.conf   |   29 ---
>  .../formfactor/cedartrail-nopvr/machconfig |3 -
>  .../formfactor/formfactor/cedartrail/machconfig|3 -
>  .../recipes-bsp/formfactor/formfactor_0.0.bbappend |3 -
>  .../images/core-image-cdv-media-sdk.bb |   12 --
>  .../images/core-image-cdv-media.bb |   13 --
>  .../xorg-driver/cdv-pvr-driver_1.0.3.bb|  197 ---
>  .../xserver-xf86-config/cedartrail-nopvr/xorg.conf |   26 ---
>  .../xserver-xf86-config/cedartrail/xorg.conf   |   19 --
>  .../xorg-xserver/xserver-xf86-config_0.1.bbappend  |1 -
>  .../linux/linux-yocto-rt_3.0.bbappend  |   18 --
>  .../recipes-kernel/linux/linux-yocto_3.0.bbappend  |   23 ---
>  .../ogg-CC-BY-3.0-music-samples_0.1.bb |   21 ---
>  .../video-samples/bigbuckbunny-ogg.bb  |   22 ---
>  20 files changed, 660 deletions(-)
>  delete mode 100755 meta-cedartrail/COPYING.MIT
>  delete mode 100755 meta-cedartrail/README
>  delete mode 100755 meta-cedartrail/README.sources
>  delete mode 100644 meta-cedartrail/binary/.gitignore
>  delete mode 100644 meta-cedartrail/conf/layer.conf
>  delete mode 100644 meta-cedartrail/conf/machine/cedartrail-nopvr.conf
>  delete mode 100644 meta-cedartrail/conf/machine/cedartrail.conf
>  delete mode 100644 
> meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail-nopvr/machconfig
>  delete mode 100644 
> meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail/machconfig
>  delete mode 100644 
> meta-cedartrail/recipes-bsp/formfactor/formfactor_0.0.bbappend
>  delete mode 100644 
> meta-cedartrail/recipes-cdv-media/images/core-image-cdv-media-sdk.bb
>  delete mode 100644 
> meta-cedartrail/recipes-cdv-media/images/core-image-cdv-media.bb
>  delete mode 100644 
> meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
>  delete mode 100644 
> meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail-nopvr/xorg.conf
>  delete mode 100644 
> meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail/xorg.conf
>  delete mode 100644 
> meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
>  delete mode 100644 
> meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
>  delete mode 100644 
> meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
>  delete mode 100644 
> meta-cedartrail/recipes-mediasamples/music-samples/ogg-CC-BY-3.0-music-samples_0.1.bb
>  delete mode 100644 
> meta-cedartrail/recipes-mediasamples/video-samples/bigbuckbunny-ogg.bb
> 


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

Re: [yocto] Slides from the Yocto Developer Day

[Tom Zanussi]

On Wed, 2013-01-30 at 08:43 -0800, Darren Hart wrote:
> On 01/30/2013 06:41 AM, Marco wrote:
> > Il 13/11/2012 08:01, Scott Garman ha scritto:
> >> On 11/12/2012 11:52 AM, Anna Dushistova wrote:
> >>> Hi All,
> >>>
> >>> Are the slides available somewhere?
> >>>
> >>> Thanks!
> >>> Anna.
> >>
> >> Hi Anna,
> >>
> >> Attached are the slides and lab packet I used for the intro hands-on lab
> >> in PDF format.
> > 
> > 
> > Hi all,
> > would be available slides and worksheet for the other YDD-2012 labs?
> > 
> > - "Hands on kernel lab" by Darren & Tom
> 
> We're working on making the kernel lab available online. Until then, the
> materials would not be of much use as they were just specific enough to
> the lab machines we set up, that they would frustrate more than
> enlighten someone trying to use them on their own. Once they are up,
> you'll be able to download them and do the labs on your own machines.
> 

Hi,

The 'Hands-on Kernel Lab' has now been updated, and the instructions now
assume you'll be starting from scratch on your own machine - anything
related to the lab environment is now gone, and there's actually a lot
more material now (5 labs instead of 3).  See here for details:

https://lists.yoctoproject.org/pipermail/yocto/2013-February/014408.html

Tom

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

[yocto] Updated Yocto Hands-on Kernel Lab available

[Tom Zanussi]

Hi,

I'm happy to announce that an updated version of the Yocto 'Hands-on
Kernel Lab' has been released and is available here:

https://www.yoctoproject.org/sites/yoctoproject.org/files/elc2013-kernel-lab.pdf

The above document contains all the instructions you need to get started
from scratch.

You can always get to the lab and associated content by visiting the
Yocto home page (https://www.yoctoproject.org/) and selecting 'Read
presentations about the project' from the drop-down list you get by
clicking on the 'Start Here to learn more' box on the left-hand side and
clicking on the 'Working with the Kernel' presentation link.

The 'Hands-on Kernel Lab' has been updated to Yocto 1.3 ('danny') and
has been substantially expanded from three to five labs, with completely
new sections covering custom kernels, loadable modules and getting them
into (and autoloaded into) images, external modules, local clones, bare
local clones, and enabling LTSI features.

See below for a more complete listing of what's covered along with the
lab number covering those topics.

I've run through the lab twice, once on Fedora 17 and once on Ubuntu
12.04, so it should be pretty solid at this point, but if you find
problems, please let me know...

* Creating and using a traditional kernel recipe (lab1)
* Using 'bitbake -c menuconfig' to modify the kernel configuration and replace 
the defconfig with the new configuration (lab1)
* Adding a kernel module to the kernel source and configuring it as a built-in 
module by adding options to the kernel defconfig (lab1)
* Creating and using a linux-yocto-based kernel (lab2)
* Adding a kernel module to the kernel source and configuring it as a built-in 
module using linux-yocto 'config fragments' (lab2)
* Using the linux-yocto kernel as an LTSI kernel (configuring in an item added 
by the LTSI kernel which is merged into linux-yocto) (lab2)
* Using an arbitrary git-based kernel via the linux-yocto-custom kernel recipe 
(lab3)
* Adding a kernel module to the kernel source of an arbitrary git-based kernel 
and configuring it as a loadable module using 'config fragments' (lab3)
* Actually getting the module into the image and autoloading it on boot (lab3)
* Using a local clone of an arbitrary git-based kernel via the 
linux-yocto-custom kernel recipe to demonstrate a typical development workflow 
(lab4)
* Modifying the locally cloned custom kernel source and verifying the changes 
in the new image (lab4)
* Using a local clone of a linux-yocto- kernel recipe to demonstrate a typical 
development workflow (lab4)
* Modifying the locally cloned linux-yocto kernel source and verifying the 
changes in the new image (lab4)
* Using a 'bare' local clone of a linux-yocto- kernel recipe to demonstrate a 
typical development workflow (lab4)
* Modifying the locally cloned 'bare' linux-yocto kernel source and verifying 
the changes in the new image (lab4)
* Adding and using an external kernel module via a module recipe (lab4)
* Using the 'Yocto BSP Tools' yocto-bsp tool generate a new Yocto BSP (lab5)
* Using the 'Yocto BSP Tools' yocto-kernel tool to add kernel patches and 
config fragments (lab5)


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

Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine

[Tom Zanussi]

On Tue, 2013-02-12 at 21:34 +, Chris Tapp wrote:
> On 12 Feb 2013, at 19:56, Tom Zanussi wrote:
> 
> > On Mon, 2013-02-11 at 22:02 -0800, Sean Liming wrote:
> >> 
> >>> -Original Message-
> >>> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> >>> boun...@yoctoproject.org] On Behalf Of Liu, Song
> >>> Sent: Monday, February 11, 2013 1:25 PM
> >>> To: Chris Tapp
> >>> Cc: Darren Hart; Yocto Discussion Mailing List
> >>> Subject: Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine
> >>> 
> >>> Thanks for the reply, Chris! Feel free to let us know if you have any
> >>> questions. Hope your project will go well.
> >>> 
> >>> Song
> >>> 
> >>> -Original Message-
> >>> From: Chris Tapp [mailto:opensou...@keylevel.com]
> >>> Sent: Monday, February 11, 2013 1:17 PM
> >>> To: Liu, Song
> >>> Cc: Bodke, Kishore K; Bruce Ashfield; Darren Hart; Saxena, Rahul; Zanussi,
> >>> Tom; Yocto Discussion Mailing List
> >>> Subject: Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine
> >>> 
> >>> Hi Song / Kishore,
> >>> 
> >>> On 11 Feb 2013, at 18:47, Liu, Song wrote:
> >>> 
> >>>> Hi Chris,
> >>>> 
> >>>> Intel is still supporting critical fixes for the Cedar Trail BSP on
> >> Yocto Project
> >>> 1.3 release. If you need additional support for your project, I can
> >> connect you
> >>> with some Intel sales/support people who can help. At the same time, would
> >>> you be able to share more information about your project with me? It will
> >>> help when I ask them for additional support.
> >>> 
> >>> Thanks, that's good news.
> >>> 
> >>> The only slight down side from my perspective is we won't get the benefits
> >>> from 1.4 (and future) improvements. However, it will give me an excuse to
> >>> move the hardware on as new platforms become available ;-)
> >>> 
> >>> 
> >>>> Song
> >>>> 
> >>>> -Original Message-
> >>>> From: Chris Tapp [mailto:opensou...@keylevel.com]
> >>>> Sent: Saturday, February 09, 2013 1:33 AM
> >>>> To: Bodke, Kishore K
> >>>> Cc: bruce.ashfi...@windriver.com; dvh...@linux.intel.com; Saxena,
> >>>> Rahul; Liu, Song; Zanussi, Tom; linux-yo...@yoctoproject.org;
> >>>> yocto@yoctoproject.org
> >>>> Subject: Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail
> >>>> Machine
> >>>> 
> >>>> 
> >>>> On 8 Feb 2013, at 23:18, kishore.k.bo...@intel.com wrote:
> >>>> 
> >>>>> From: Kishore Bodke 
> >>>>> 
> >>>>> 
> >>>>> Hi,
> >>>>> 
> >>>>> This patch set is to remove the Cedartail Machine from
> >>>>> Linux-yocto-3.4 Kernel.
> >>>>> Cedartrail BSP will not be supported for Yocto 1.4 Release.
> >>>> 
> >>>> Hi Kishore,
> >>>> 
> >>>> Are there any plans to bring support back in? We recently committed a
> >>> project to using this BSP for the Intel DN2800MT...
> >>>> 
> >>>>> Also Please remove the standard/cedartrail branch.
> >>>>> 
> >>>>> Please pull into linux-yocto-3.4/meta branch.
> >>>>> 
> >>>>> Thanks
> >>>>> Kishore.
> >>>>> 
> >>>>> The following changes since commit
> >>> f697e099bc76d5df3a307a5bc0cc25021dd6dfe0:
> >>>>> 
> >>>>> meta: bump to v3.4.28, rt-40 (2013-02-04 00:14:21 -0500)
> >>>>> 
> >>>>> are available in the git repository at:
> >>>>> 
> >>>>> git://git.pokylinux.org/linux-yocto-contrib kishore/cedartrail_remove
> >>>>> http://git.pokylinux.org/cgit.cgi/linux-yocto-contrib/log/?h=kishore/
> >>>>> c
> >>>>> edartrail_remove
> >>>>> 
> >>>>> Kishore Bodke (1):
> >>>>> meta: Remove Cedartrail Machine
> >>>>> 
> >>>>> .../bsp/cedartrail/cedartrail-preempt-rt.scc   |   13 --
> >>>>> .../bsp/cedartrail/cedartrail-standard.scc

Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine

[Tom Zanussi]

On Mon, 2013-02-11 at 22:02 -0800, Sean Liming wrote:
> 
> > -Original Message-
> > From: yocto-boun...@yoctoproject.org [mailto:yocto-
> > boun...@yoctoproject.org] On Behalf Of Liu, Song
> > Sent: Monday, February 11, 2013 1:25 PM
> > To: Chris Tapp
> > Cc: Darren Hart; Yocto Discussion Mailing List
> > Subject: Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine
> > 
> > Thanks for the reply, Chris! Feel free to let us know if you have any
> > questions. Hope your project will go well.
> > 
> > Song
> > 
> > -Original Message-
> > From: Chris Tapp [mailto:opensou...@keylevel.com]
> > Sent: Monday, February 11, 2013 1:17 PM
> > To: Liu, Song
> > Cc: Bodke, Kishore K; Bruce Ashfield; Darren Hart; Saxena, Rahul; Zanussi,
> > Tom; Yocto Discussion Mailing List
> > Subject: Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine
> > 
> > Hi Song / Kishore,
> > 
> > On 11 Feb 2013, at 18:47, Liu, Song wrote:
> > 
> > > Hi Chris,
> > >
> > > Intel is still supporting critical fixes for the Cedar Trail BSP on
> Yocto Project
> > 1.3 release. If you need additional support for your project, I can
> connect you
> > with some Intel sales/support people who can help. At the same time, would
> > you be able to share more information about your project with me? It will
> > help when I ask them for additional support.
> > 
> > Thanks, that's good news.
> > 
> > The only slight down side from my perspective is we won't get the benefits
> > from 1.4 (and future) improvements. However, it will give me an excuse to
> > move the hardware on as new platforms become available ;-)
> > 
> > 
> > > Song
> > >
> > > -Original Message-
> > > From: Chris Tapp [mailto:opensou...@keylevel.com]
> > > Sent: Saturday, February 09, 2013 1:33 AM
> > > To: Bodke, Kishore K
> > > Cc: bruce.ashfi...@windriver.com; dvh...@linux.intel.com; Saxena,
> > > Rahul; Liu, Song; Zanussi, Tom; linux-yo...@yoctoproject.org;
> > > yocto@yoctoproject.org
> > > Subject: Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail
> > > Machine
> > >
> > >
> > > On 8 Feb 2013, at 23:18, kishore.k.bo...@intel.com wrote:
> > >
> > >> From: Kishore Bodke 
> > >>
> > >>
> > >> Hi,
> > >>
> > >> This patch set is to remove the Cedartail Machine from
> > >> Linux-yocto-3.4 Kernel.
> > >> Cedartrail BSP will not be supported for Yocto 1.4 Release.
> > >
> > > Hi Kishore,
> > >
> > > Are there any plans to bring support back in? We recently committed a
> > project to using this BSP for the Intel DN2800MT...
> > >
> > >> Also Please remove the standard/cedartrail branch.
> > >>
> > >> Please pull into linux-yocto-3.4/meta branch.
> > >>
> > >> Thanks
> > >> Kishore.
> > >>
> > >> The following changes since commit
> > f697e099bc76d5df3a307a5bc0cc25021dd6dfe0:
> > >>
> > >> meta: bump to v3.4.28, rt-40 (2013-02-04 00:14:21 -0500)
> > >>
> > >> are available in the git repository at:
> > >>
> > >> git://git.pokylinux.org/linux-yocto-contrib kishore/cedartrail_remove
> > >> http://git.pokylinux.org/cgit.cgi/linux-yocto-contrib/log/?h=kishore/
> > >> c
> > >> edartrail_remove
> > >>
> > >> Kishore Bodke (1):
> > >> meta: Remove Cedartrail Machine
> > >>
> > >> .../bsp/cedartrail/cedartrail-preempt-rt.scc   |   13 --
> > >> .../bsp/cedartrail/cedartrail-standard.scc |8 
> > >> .../cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg |   46
> 
> > >> .../cfg/kernel-cache/bsp/cedartrail/cedartrail.scc |   15 ---
> > >> 4 files changed, 82 deletions(-)
> > >> delete mode 100755
> > >> meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-preempt-rt.scc
> > >> delete mode 100755
> > >> meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc
> > >> delete mode 100755
> > >> meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg
> > >> delete mode 100644
> > >> meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.scc
> > >>
> > >> --
> > >> 1.7.9.5
> > >>
> > >> ___
> > >> yocto mailing list
> > >> yocto@yoctoproject.org
> > >> https://lists.yoctoproject.org/listinfo/yocto
> > >
> > > Chris Tapp
> > >
> > > opensou...@keylevel.com
> > > www.keylevel.com
> > >
> > >
> > >
> > 
> > Chris Tapp
> > 
> > opensou...@keylevel.com
> > www.keylevel.com
> > 
> > 
> > 
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> I haven't looked at the changes. Out of curiosity, is it possible to add a
> BSP back in for a new Yocto Project version? What would be the challenge?
> 

It probably wouldn't take much to bring it back - basically the pvr
graphics driver, which I assume is one of the most important features of
this BSP for users, is stuck at kernel version 3.0.  If everything else
stayed the same, forward-porting the GPL'ed kernel portion of the driver
would be all that would be needed to get it working again.  We've done
that routinely for other drivers such as EMGD, s

Re: [yocto] [meta-intel][PATCH 1/2] ffmpeg: Remove package as nobody depends on it anymore

[Tom Zanussi]

On Thu, 2013-01-24 at 21:10 +0200, Andrei Gherzan wrote:
> Ping
> 

Pulled into meta-intel/master.

Thanks,

Tom

> 
> On Sun, Jan 13, 2013 at 6:23 PM, Andrei Gherzan 
> wrote:
> Signed-off-by: Andrei Gherzan 
> ---
>  common/recipes-multimedia/ffmpeg/ffmpeg.inc   |  110
> -
>  common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb |   44
> -
>  2 files changed, 154 deletions(-)
>  delete mode 100644
> common/recipes-multimedia/ffmpeg/ffmpeg.inc
>  delete mode 100644
> common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb
> 
> diff --git a/common/recipes-multimedia/ffmpeg/ffmpeg.inc
> b/common/recipes-multimedia/ffmpeg/ffmpeg.inc
> deleted file mode 100644
> index 3ce950e..000
> --- a/common/recipes-multimedia/ffmpeg/ffmpeg.inc
> +++ /dev/null
> @@ -1,110 +0,0 @@
> -DESCRIPTION = "FFmpeg is a complete solution to record,
> convert and stream audio and video"
> -HOMEPAGE = "http://ffmpeg.mplayerhq.hu/";
> -AUTHOR = "Fabrice Bellard ffmpeg-de...@mplayerhq.hu"
> -SECTION = "libs"
> -PRIORITY = "optional"
> -LICENSE = "GPLv2+ & LGPLv2.1+"
> -
> -LICENSE_FLAGS = "commercial"
> -
> -ARM_INSTRUCTION_SET = "arm"
> -
> -DEPENDS = "zlib libogg libvorbis libtheora liba52 libva
> yasm-native"
> -
> -INC_PR = "r0"
> -
> -inherit autotools pkgconfig
> -
> -LEAD_SONAME = "libavcodec.so"
> -
> -EXTRA_OECONF = "\
> -\
> ---enable-pp \
> ---enable-shared \
> ---enable-pthreads \
> ---enable-gpl \
> -\
> ---cross-prefix=${TARGET_PREFIX} \
> ---disable-debug \
> ---disable-ffserver \
> ---disable-ffplay \
> -\
> -"
> -
> -EXTRA_OECONF_append_powerpc +=
> 
> "--${@['disable-altivec','enable-altivec'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1)
>  in ['ppce600']]}"
> -
> -FFMPEG_LIBS = "libavcodec libavdevice libavformat \
> -   libavutil libpostproc libswscale libavfilter"
> -
> -SYSROOT_PREPROCESS_FUNCS = " \
> -  ffmpeg_stage_cleanup \
> -  ffmpeg_create_compat_links"
> -
> -ffmpeg_create_compat_links() {
> -rm -rf ${SYSROOT_DESTDIR}${includedir}/ffmpeg
> -mkdir -m 0755 ${SYSROOT_DESTDIR}${includedir}/ffmpeg
> -cd ${SYSROOT_DESTDIR}${includedir}/ffmpeg
> -
> -for lib in ${FFMPEG_LIBS}; do
> -ln -s ../$lib/*.h '.' || true
> -done
> -}
> -
> -ffmpeg_stage_cleanup() {
> -rm -rf ${SYSROOT_DESTDIR}${libdir}/vhook \
> -${SYSROOT_DESTDIR}${datadir}
> -}
> -
> -PACKAGES += "${PN}-vhook-dbg ${PN}-vhook"
> -
> -FILES_${PN} = "${bindir}"
> -FILES_${PN}-dev = "${includedir}/${PN}"
> -
> -FILES_${PN}-vhook = "${libdir}/vhook"
> -FILES_${PN}-vhook-dbg += "${libdir}/vhook/.debug"
> -
> -PACKAGES += "ffmpeg-x264-presets \
> - libavcodec  libavcodec-dev  libavcodec-dbg \
> - libavdevice libavdevice-dev libavdevice-dbg \
> - libavformat libavformat-dev libavformat-dbg \
> - libavutil   libavutil-dev   libavutil-dbg \
> - libpostproc libpostproc-dev libpostproc-dbg \
> - libswscale  libswscale-dev  libswscale-dbg \
> - libavfilter libavfilter-dev libavfilter-dbg \
> - libavcore   libavcore-dev   libavcore-dbg \
> -"
> -
> -FILES_ffmpeg-x264-presets = "${datadir}/*.ffpreset"
> -
> -FILES_${PN}-dev = "${includedir}"
> -FILES_libavcodec = "${libdir}/libavcodec*.so.*"
> -FILES_libavcodec-dev = "${libdir}/libavcodec*.so
> ${libdir}/pkgconfig/libavcodec.pc ${libdir}/libavcodec*.a"
> -FILES_libavcodec-dbg += "${libdir}/.debug/libavcodec*"
> -
> -FILES_libavdevice = "${libdir}/libavdevice*.so.*"
> -FILES_libavdevice-dev = "${libdir}/libavdevice*.so
> ${libdir}/pkgconfig/libavdevice.pc ${libdir}/libavdevice*.a"
> -FILES_libavdevice-dbg += "${libdir}/.debug/libavdevice*"
> -
> -FILES_libavformat = "${libdir}/libavformat*.so.*"
> -FILES_libavformat-dev = "${libdir}/libavformat*.so
> ${libdir}/pkgconfig/libavformat.pc ${libdir}/libavformat*.a"
> -FILES_libavformat-dbg += "${libdir}/.debug/libavformat*"
> -
> -FILES_libavutil = "${libdir}/li

Re: [yocto] [meta-intel][PATCH 2/2] fri2.conf: mesa-dri was updated to 9.0.1

[Tom Zanussi]

On Thu, 2013-01-24 at 21:06 +0200, Andrei Gherzan wrote:
> On Sun, Jan 13, 2013 at 11:06 PM, Andrei Gherzan 
> wrote:
> On Sun, Jan 13, 2013 at 10:03 PM, Ross Burton
>  wrote:
> 
> On Sunday, 13 January 2013 at 19:39, Andrei Gherzan
> wrote:
> > Tested with a new sato build on master. Everything
> seems to be OK.
> 
> 
> glxinfo/glxgears or something that actually uses the
> hardware?
> 
> 
> Yes. That too. 
> 
> Ping.
> 

Pulled into meta-intel/master.

Thanks,

Tom

> 
> -- 
> 
> Andrei Gherzan
> m: +40.744.478.414 |  f: +40.31.816.28.12
> 
> ___
> 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-intel][PATCH 2/2] fri2.conf: mesa-dri was updated to 9.0.1

[Tom Zanussi]

On Thu, 2013-01-24 at 22:22 +, Burton, Ross wrote:
> On 24 January 2013 19:06, Andrei Gherzan  wrote:
> > Ping.
> 
> Your pings are misdirected - the meta-intel patches should now be
> going to meta-in...@yoctoproject.org.
> 

Oops, yeah, I somehow missed these, sorry - let me try them out and I'll
pull them in.

And I just noticed the meta-intel MAINTAINERS still has the old address
(thought I had fixed that, guess not), so will fix that too..

Tom 


> Ross
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


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