On Fri, Sep 2, 2011 at 10:48 AM, Mark Hatle <mark.hatle@windriver.com> wrote:

The normal OE approach is to resolve all items by run-time dependencies.  That
is why a lot more is built then installed.

So if you want a system capable of running bash, you would create a task (and
related image) that simply has a RDEPENDS on "bash".  Everything else is
determined automatically.  So even if you build ncurses for 32-bit and 64-bit,
only the one needed by bash will be installed.

If you change this and specify that your task RDEPENDS is "bash lib64-ncurses".
 Then the system will determine the dependencies based on both bash and the
64-bit ncurses.  This will result in a system (likely 32-bit in this example)
that includes bash and lib64-ncurses and all of it's dependencies...

The point is, if you explicitly tell the system to install something it is
expected to be installed.  If you don't the automatic resolution is used to
determine install components and not everything you want may be installed.

One would expect then if I did a:

MULTILIB_IMAGE_INSTALL += "lib64-perl"

I would be a 64bit perl and a slew of 64 bit libraries installed. I'm
still trying to figure out why this is not happening on my particular
build.

-M

On Fri, Sep 2, 2011 at 2:26 AM, Chris Tapp <opensource@keylevel.com> wrote:

However, kernel configuration becomes a little bit more complicated as this
is done by machine name. A kernel recipe will be needed for each machine
(e.g. for the different sound drivers), but I can't work out how to do this
using a base configuration for the SoCs that are shared and then adding
machine specific parts. I can do it using (for example) a .defconfig for
each machine, but that would require updates to multiple files to change the
SoC configuration.

I guess what I'm really asking is, is it possible to have a base CPU
configuration and add a machine configuration to this ?

I've recently seen discussion of .cfg kernel fragment files. Are these what
I should be looking at? Are these available in the releases or only in the
development branch?

I think this is a good solution for you. It's a little confusing to
find were this work is but you can look in the linux-yocto kernel tree
- then the actual cfg fragment stuff on different branches.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/

meta branch contains meta/ which contains a lot of the cfg fragments,
and patches, etc. There is also a document in the git repo as well
which is worth a look.

-M

On 9/2/11 10:40 AM, McClintock Matthew-B29882 wrote:

On Fri, Sep 2, 2011 at 10:03 AM, Mark Hatle <mark.hatle@windriver.com> wrote:

However in run time testing I met a problem that, for those libraries whose
base/multilib versions packages will be both built out (like libgtk, it has
"libgtk-2.0-2.22.1-r2.x86_64.rpm" and "libgtk-2.0-2.22.1-r2.x86.rpm"), the
rpm will only installs the lib32 version of it.

During filesystem construction the system uses dependencies to decide what to
install. If you build a 32-bit connman-gnome and it requires other 32-bit
libraries the dependency scanner will either pick them up and install them, or
error due to missing dependencies.

Some you are saying since we do not build an actual binary that
depends on the 64bit library we just drop the libraries we requested
to be installed?

-M

The normal OE approach is to resolve all items by run-time dependencies. That
is why a lot more is built then installed.

So if you want a system capable of running bash, you would create a task (and
related image) that simply has a RDEPENDS on "bash". Everything else is
determined automatically. So even if you build ncurses for 32-bit and 64-bit,
only the one needed by bash will be installed.

If you change this and specify that your task RDEPENDS is "bash lib64-ncurses".
Then the system will determine the dependencies based on both bash and the
64-bit ncurses. This will result in a system (likely 32-bit in this example)
that includes bash and lib64-ncurses and all of it's dependencies...

The point is, if you explicitly tell the system to install something it is
expected to be installed. If you don't the automatic resolution is used to
determine install components and not everything you want may be installed.

--Mark

On 11-09-02 03:26 AM, Chris Tapp wrote:

How should meta data be structured so that a layer can support a set of
systems using a set of processors?

For example, many of the 'eBox' systems use variants of the Vortex86
SoC. So, a set of machine files are needed for these (e.g. ebox-3300,
ebox-3500mx, etc.).

These have different peripherals available (e.g. some have serial, some
don't) and use different SoC variants with different cpu, sound, etc. It
would therefore make sense for the machine configuration to inherit the
SoC attributes (for the common features) and add (or remove) machine
specific attributes (e.g. serial) to these. This can be done by putting
the SoC bits in to an include.

However, kernel configuration becomes a little bit more complicated as
this is done by machine name. A kernel recipe will be needed for each
machine (e.g. for the different sound drivers), but I can't work out how
to do this using a base configuration for the SoCs that are shared and
then adding machine specific parts. I can do it using (for example) a
.defconfig for each machine, but that would require updates to multiple
files to change the SoC configuration.

I guess what I'm really asking is, is it possible to have a base CPU
configuration and add a machine configuration to this ?

I've recently seen discussion of .cfg kernel fragment files. Are these
what I should be looking at? Are these available in the releases or only
in the development branch?

What you've described is one of the primary reasons that the
configuration fragments exist :) You define a common set of
config fragments, extend and then select what you want.

These are available in all the releases, but the capabilities
are evolving and I merge more changes into the yocto bindings
for manipulating the configuration fragments outside of a kernel
tree proper.

If you have your own kernel repository based on linux-yocto, you
could implement any of this inside the tree. If you are re-using
existing machines/branches in the linux-yocto tree, you can also
do what you want, but have to do it via a collection of configuration
fragments that are appended to the SRC_URI based on the machine
you are building,.

Cheers,

Bruce

Chris Tapp

opensource@keylevel.com
www.keylevel.com



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

On Fri, Sep 2, 2011 at 10:03 AM, Mark Hatle <mark.hatle@windriver.com> wrote:

However in run time testing I met a problem that, for those libraries whose
base/multilib versions packages will be both built out (like libgtk, it has
"libgtk-2.0-2.22.1-r2.x86_64.rpm" and "libgtk-2.0-2.22.1-r2.x86.rpm"), the
rpm will only installs the lib32 version of it.

During filesystem construction the system uses dependencies to decide what to
install.  If you build a 32-bit connman-gnome and it requires other 32-bit
libraries the dependency scanner will either pick them up and install them, or
error due to missing dependencies.

Some you are saying since we do not build an actual binary that
depends on the 64bit library we just drop the libraries we requested
to be installed?

-M

On 9/2/11 2:33 AM, Xu, Dongxiao wrote:

Hi Mark and Richard,

I am trying to setup a RPM multilib system that, it is a qemux86-64 base
image with MULTILIB_IMAGE_INSTALL = "lib32-connman-gnome". With several
fixes, the build can pass.

However in run time testing I met a problem that, for those libraries whose
base/multilib versions packages will be both built out (like libgtk, it has
"libgtk-2.0-2.22.1-r2.x86_64.rpm" and "libgtk-2.0-2.22.1-r2.x86.rpm"), the
rpm will only installs the lib32 version of it.

During filesystem construction the system uses dependencies to decide what to
install. If you build a 32-bit connman-gnome and it requires other 32-bit
libraries the dependency scanner will either pick them up and install them, or
error due to missing dependencies.

In the manual case you would use "rpm -Uhv <path>" manually specifying which one
you want. RPM will detect a multilib package and will allow installation of
both versions. (Note always use rpm -U and not rpm -i.. rpm -i just blindly
installs the software with no checking if an existing version exists.)

Therefore one question is, if there are two rpm packages with the same PN,
PV, PR, but different architecture (like our multilib case), then we run
command "rpm -ivh libgtk", which version of libgtk will be installed? Or does
rpm have any parameter to force installing them both? Actually multilib
requires to install them both with certain order.

No specific order should be necessary on a multilib system. As long as the end
dependencies are satisfied the resulting filesystem will work. (Exceptions to
this are when there are pre and post install scripts that have their own unique
dependencies.. but those are not the normal case for OE-Core/Yocto.)

--Mark

Thanks, Dongxiao

Hi Mark and Richard,

I am trying to setup a RPM multilib system that, it is a qemux86-64 base image with MULTILIB_IMAGE_INSTALL = "lib32-connman-gnome". With several fixes, the build can pass.

However in run time testing I met a problem that, for those libraries whose base/multilib versions packages will be both built out (like libgtk, it has "libgtk-2.0-2.22.1-r2.x86_64.rpm" and "libgtk-2.0-2.22.1-r2.x86.rpm"), the rpm will only installs the lib32 version of it.

Therefore one question is, if there are two rpm packages with the same PN, PV, PR, but different architecture (like our multilib case), then we run command "rpm -ivh libgtk", which version of libgtk will be installed? Or does rpm have any parameter to force installing them both? Actually multilib requires to install them both with certain order.

Thanks,
Dongxiao

How should meta data be structured so that a layer can support a set of systems using a set of processors?

For example, many of the 'eBox' systems use variants of the Vortex86 SoC. So, a set of machine files are needed for these (e.g. ebox-3300, ebox-3500mx, etc.).

These have different peripherals available (e.g. some have serial, some don't) and use different SoC variants with different cpu, sound, etc. It would therefore make sense for the machine configuration to inherit the SoC attributes (for the common features) and add (or remove) machine specific attributes (e.g. serial) to these. This can be done by putting the SoC bits in to an include.

However, kernel configuration becomes a little bit more complicated as this is done by machine name. A kernel recipe will be needed for each machine (e.g. for the different sound drivers), but I can't work out how to do this using a base configuration for the SoCs that are shared and then adding machine specific parts. I can do it using (for example) a .defconfig for each machine, but that would require updates to multiple files to change the SoC configuration.

I guess what I'm really asking is, is it possible to have a base CPU configuration and add a machine configuration to this ?

I've recently seen discussion of .cfg kernel fragment files. Are these what I should be looking at? Are these available in the releases or only in the development branch?

Chris Tapp

opensource@keylevel.com
www.keylevel.com

For the build I removed the rttests in the IMAGE_INSTALL , so it is not showing up here.

bitbake -e core-image-sato | egrep "IMAGE_INSTALL="
# MULTILIB_IMAGE_INSTALL=
# IMAGE_INSTALL=${POKY_BASE_INSTALL}
IMAGE_INSTALL="task-core-boot task-base-extended"

I will rebuild with rttests and send the output.

Thanks
Kishore.

Can you report the output of:

$ bitbake -e core-image-sato | egrep "^IMAGE_INSTALL="

Thanks,

Darren

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Yeah, it is the same do_rootfs failure I get for both the builds.
Thanks
Kishore.

On 09/01/2011 02:01 PM, Bodke, Kishore K wrote:

Clean build with the below TOM's two commit IDs worked for me, if I
do not add IMAGE_INSTALL += "rttests" for sugarbay.

It failed if I add the IMAGE_INSTALL += "rttests"

Do you get the same error? If so, it's starting to sound like the second
build is what fails since neither of your failure scenarios include
a change that's related to the failure. Perhaps an issue with sstate...

--
Darren

Thanks Kishore. -----Original Message----- From: Darren Hart
[mailto:dvhart@linux.intel.com] Sent: Thursday, September 01, 2011
1:57 PM To: Zanussi, Tom Cc: Bodke, Kishore K;
yocto@yoctoproject.org; Hart, Darren; Saxena, Rahul Subject: Re: RT
kernel with core-image-sato build failed for sugarbay



On 08/31/2011 09:19 PM, Tom Zanussi wrote:

On Wed, 2011-08-31 at 16:49 -0700, Bodke, Kishore K wrote:

Hi,



I am trying to build core-image-sato with rt kernel for sugarbay
and it fails for the do_rootfs .

FWIW, I was able to build and boot core-image-sato with the rt
kernel:

Linux sugarbay 3.0.3-rt8-yocto-preempt-rt+ #1 SMP PREEMPT RT Wed
Aug 31 21:33:27 CDT 2011 x86_64 GNU/Linux

using the following commits:

poky/master 705ec50edda7f7fb8c132238fe3f1477384a470e meta/intel
902d2f3c919cd1d870dc8d35a7521cbba42e53ea

Actually, meta/intel was that commit with Darren's grub patch on
top (meta-intel/dvhart/grub-freetype).

Kishore, would you try with a clean build and see if this works for
you?

I'm going to try and build first without -rt and then with rt and see
if I can reproduce the issue.

Thanks,

Darren

Tom

Attached is the build log.



Could you please let me know what went wrong?



Thanks

Kishore.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

On 11-09-01 4:41 PM, Saxena, Rahul wrote:

Cover letter for the delete duplicate statement and delete unused cfg
fragment patches

Thanks. These look good. I'm preparing a pull request right now, so I'll
merge these and include them in that update.

Bruce

Rahul Saxena (2):

Removed duplicate statement

Removed unused cfg file

meta/cfg/kernel-cache/bsp/fishriver/eg20t.cfg | 39 ---------------------

meta/cfg/kernel-cache/bsp/fishriver/fishriver.scc | 1 -

2 files changed, 0 insertions(+), 40 deletions(-)

delete mode 100644 meta/cfg/kernel-cache/bsp/fishriver/eg20t.cfg



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

Clean build with the below TOM's two commit IDs worked for me, if I do not add IMAGE_INSTALL += "rttests" for sugarbay.

It failed if I add the IMAGE_INSTALL += "rttests"

Thanks
Kishore.

On 08/31/2011 09:19 PM, Tom Zanussi wrote:

On Wed, 2011-08-31 at 16:49 -0700, Bodke, Kishore K wrote:

Hi,



I am trying to build core-image-sato with rt kernel for sugarbay and
it fails for the do_rootfs .

FWIW, I was able to build and boot core-image-sato with the rt kernel:

Linux sugarbay 3.0.3-rt8-yocto-preempt-rt+ #1 SMP PREEMPT RT Wed Aug 31
21:33:27 CDT 2011 x86_64 GNU/Linux

using the following commits:

poky/master 705ec50edda7f7fb8c132238fe3f1477384a470e
meta/intel 902d2f3c919cd1d870dc8d35a7521cbba42e53ea

Actually, meta/intel was that commit with Darren's grub patch on top
(meta-intel/dvhart/grub-freetype).

Kishore, would you try with a clean build and see if this works for you?

I'm going to try and build first without -rt and then with rt and see if
I can reproduce the issue.

Thanks,

Darren

Tom

Attached is the build log.



Could you please let me know what went wrong?



Thanks

Kishore.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

On 08/31/2011 07:34 PM, Darren Hart wrote:

Grub's configure task was picking up the host freetype libraries if
bitbake hadn't gotten around building freetype yet. We could add a
dependency on freetype, but it's only used for the optional grub-mkfont
utility which we don't really need.

Disable grub-mkfont via EXTRA_OECONF, removing the dependency on freetype.

Testing: core-image-minimal build and install on sugarbay.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Tested-by: Tom Zanussi <tom.zanussi@intel.com>
---
common/recipes-bsp/grub/grub_1.98.bb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/recipes-bsp/grub/grub_1.98.bb b/common/recipes-bsp/grub/grub_1.98.bb
index 0cd3a40..802733f 100644
--- a/common/recipes-bsp/grub/grub_1.98.bb
+++ b/common/recipes-bsp/grub/grub_1.98.bb
@@ -24,7 +24,7 @@ SRC_URI = "ftp://alpha.gnu.org/gnu/grub/grub-${PV}.tar.gz \
inherit autotools
inherit gettext

-EXTRA_OECONF = "--with-platform=pc --target=i386"
+EXTRA_OECONF = "--with-platform=pc --target=i386 --disable-grub-mkfont"

do_configure() {
oe_runconf

Merged to meta-intel:master.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel