Re: [yocto] Updating uboot to v2013.01

2013-02-28 Thread Rudolf Streif
Hey Satya,

Sorry for the delayed response.

Well, it should create the kernel image and wrap it for u-boot. At least
that is my experience and what I just did during a YP class on the weekend
for the BeagleBone.

What is linux-dummy? Is that a kernel recipe that you created?

I second what Khem said that you may be missing the BSP or have incorrect
entries in your machine configuration file. That file ties machine-specific
stuff such as kernel, bootloader etc. together.

I am not sure about the device tree compiler. YP builds dtc as a native
package. The only reason I can imagine is that it was not built when you
are trying to build u-boot.

The SRCREV tags for u-boot I got from git.denx.de:

2013.01.01:
http://git.denx.de/?p=u-boot.git;a=tag;h=8512592e47cc968d2d6eb788acde761ebc3acbf6

2013.01:
http://git.denx.de/?p=u-boot.git;a=tag;h=35c192cf449860aec8766e20a51bf2052a1dc968

They are the git commit tags.

Cheers,
Rudi


On Tue, Feb 26, 2013 at 11:44 PM, Satya Swaroop Damarla 
swaroop.dama...@gmail.com wrote:

 Hey Rudy,

 I think, it doesnot automatically take a kernel but we have to choose the
 kernel and I chose it v3.2 but seems it doesnot support my board and so I
 should take a kernel from the original and configure it to my need Here
 is the only error message I see about linux kernel

 WARNING: linux-dummy: No generic license file exists for: GPL in any
 provider

 my board is Avionic Tamonten Carrier, based on NVIDIA harmony board.
 Suggestions are very much appreciated but I am also currently trying to
 solve it.. I just downloaded a git kernel from the avionic site and can you
 please tell me how to configure it to so that the build system takes this
 as kernel and build it

 Greets,
 Satya


 On Tue, Feb 26, 2013 at 6:21 PM, Rudolf Streif 
 rstr...@linuxfoundation.org wrote:

 Satya,

 So what exactly do you get when building the kernel? No image at all in
 tmp/deploy/images? What do the logs for the kernel recipes say?

 Rudi


 On Mon, Feb 25, 2013 at 11:36 PM, Satya Swaroop Damarla 
 swaroop.dama...@gmail.com wrote:

 hey hans,

 I think you are right about the kernel device tree.. I think it should
 come with the kernel but I have no idea why it works.. Only an expert
 should say why it works.. I think my work is not complete. I can generate
 the rootfs and the uboot.bin file but not the uImage... I have no idea...
 Diid you complete generating the image for the board?

 Greets,
 Satya


 On Mon, Feb 25, 2013 at 5:05 PM, Hans Beckérus 
 hans.becke...@gmail.comwrote:



 25 feb 2013 kl. 15:58 skrev Satya Swaroop DAMARLA swar...@weisser.at:

 Guys. I found the solution to this problem

 I think if you already install uboot-tools or uboot-mkimage packes from
 Ubuntu repository then it is used instead of the one that is downloaded and
 we should uninstall the packages and then rerun the build,,... Then IT
 WORKS... So, thank you for the time and enegry... I assume this thread is
 closed and this is the solution and if this doesnot work for some then
 please post it and we may discuss the situation depending on the problem,

 Greetings  Regards,
 Satya

 Same comment here as for the device tree compiler. You should use the
 uboot tools/version as they come with the package. Not the one used by the
 host distro. To me this is not a proper solution.



 On Thu, Feb 21, 2013 at 5:28 PM, Rudolf Streif 
 rstr...@linuxfoundation.org wrote:

 Satya,

 I will look into it later today. I am currently at the Linux
 Foundation's Embedded Linux Conference.

 Rudi


 On Thu, Feb 21, 2013 at 2:10 AM, Satya Swaroop DAMARLA 
 swar...@weisser.at wrote:

 Hello Guys,

 I have not received any reply from you. If you can help me to figure
 out what the errors mean when adding a new .bb or recipe file then I can
 learn the mistake and take care in the new recipes I request your 
 time


 On Wed, Feb 20, 2013 at 7:19 PM, Satya Swaroop Damarla 
 swaroop.dama...@gmail.com wrote:

 hey Guys... I get the following error... which I attached.. Its
 completely greek and latin to me.. Can you please help me..


 On Wed, Feb 20, 2013 at 7:19 PM, Satya Swaroop DAMARLA 
 swar...@weisser.at wrote:

 hey Guys... I get the following error... which I attached.. Its
 completely greek and latin to me.. Can you please help me..


 On Wed, Feb 20, 2013 at 6:46 PM, Hans Beckérus 
 hans.becke...@gmail.com wrote:

 On Wed, Feb 20, 2013 at 6:12 PM, Satya Swaroop Damarla
 swaroop.dama...@gmail.com wrote:
  Hey hans, this is what he meant,
 
  In the machine config file add the following
 
  PREFERRED_VERSION_u-boot ?= v2013.01%  or
 PREFERRED_VERSION_u-boot ?=
  v2013.01.01%
 
  By the way did you already complete the first part... There is
 also other
  file called u-boot-fw-utils_2012.04.01.bb ... I think we
 should do the
  same...
 
  Hans bytheway,  are you also working on the same board or
 diffferent board
  with same problem?
 

 Different board, same core, similar problem ;)
 Now I get it. Thanks. But still question 

Re: [yocto] uboot.bin and rootfs but not uImage

2013-02-28 Thread Rudolf Streif
Hi Satya,

You will first need a kernel recipe, let's call it linux-skidata.bb. It can
look like this:

DESCRIPTION = Skidata Linux Kernel
SECTION = kernel
LICENSE = GPLv2

LIC_FILES_CHKSUM = file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7

PV = 3.2

inherit kernel

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

# GIT repository location
KSRC ?= path to/linux-skidata.git

# Branch to check out
KBRANCH ?= branch

# Revision tag or AUTOREV
SRCREV ?= ${AUTOREV}

SRC_URI = git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel \
   file://defconfig \
   

S = ${WORKDIR}/git


You will need to provide a defconfig file next to your recipe containing
the kernel configuration settings. Your kernel GIT repo may contain a
.config that is good for your hardware. In that case you do not need a
defconfig but is still a good practice and will allow you to easily change
the settings.

Then you need to adjust your machine configuration file:

PREFERRED_PROVIDER_virtual/kernel ?= linux-skidata
PREFERRED_VERSION_skidata ?= 3.2%


That should do it.

:rjs


On Thu, Feb 28, 2013 at 11:21 AM, Satya Swaroop Damarla 
swaroop.dama...@gmail.com wrote:

 Yes I got an error message when I was building the kernel...  Actuallly I
 have a kernel git given by the company I downloaded it and is in my
 work pc.. How can I tell the build system to use that kernel?


 On Thu, Feb 28, 2013 at 8:17 PM, Rudolf Streif 
 rstr...@linuxfoundation.org wrote:

 Satya,

 your machine configuration file looks ok as far as I can tell. Did you
 get an error message when building the kernel? Did you try to build just
 the kernel e.g. bitbake linux-yocto?

 :rjs


 On Mon, Feb 25, 2013 at 11:31 PM, Satya Swaroop Damarla 
 swaroop.dama...@gmail.com wrote:

 Hello Guys... I think uImage is important but it is not being generated
 by the yocto project. It only generated the rootfs and uboot.bin. Is there
 any variable that has to be introduced in the machine.conf (in my case it
 is skidata-tamonten.conf)

 Here is the configuration file

 #@TYPE: Machine
 #@NAME: skidata-tamonten machine
 #@DESCRIPTION: Machine configuration for the Tamonten board

 PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg

 IMAGE_FEATURES += package-management
 EXTRA_IMAGEDEPENDS +=  u-boot

 # Uncomment the following line to enable the hard floating point abi.
 Note that
 # this breaks some binary libraries and 3D (neither of which ship with
 # meta-yocto). For maximum compatibility, leave this disabled.
 DEFAULTTUNE ?= cortexa9t
 include conf/machine/include/tune-cortexa9.inc

 IMAGE_FSTYPES += tar.bz2 ext2

 SERIAL_CONSOLE = 115200 ttyS0

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

 KERNEL_IMAGETYPE =  uImage

 PREFERRED_VERSION_u-boot ?= v2013.01.01%

 UBOOT_MACHINE = tec_config
 UBOOT_ENTRYPOINT = 0x1700
 UBOOT_LOADADDRESS = 0x1700

 MACHINE_FEATURES = usbgadget usbhost vfat screen touchscreen keyboard


 Greets,
 Satya

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




 --
 --
 *Rudolf J. Streif*
 Director of Embedded Solutions
 The Linux Foundation

 rudolf.str...@linux.com
 Phone: +1.619.631.5383
 Skype: rudolfstreif
 PGP: RSA 2048/2048 D6E7D28B

 Linux Foundation Events Schedule:  events.linuxfoundation.org
 Linux Foundation Training Schedule: training.linuxfoundation.org





-- 
-- 
*Rudolf J. Streif*
Director of Embedded Solutions
The Linux Foundation

rudolf.str...@linux.com
Phone: +1.619.631.5383
Skype: rudolfstreif
PGP: RSA 2048/2048 D6E7D28B

Linux Foundation Events Schedule:  events.linuxfoundation.org
Linux Foundation Training Schedule: training.linuxfoundation.org
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Newbie trying to get started

2013-02-28 Thread Paul D. DeRocco
I've been working with a Gumstix, and have successfully built both the
console and GUI version of their distro. So now I have two directories,
yocto/poky containing everything that was downloaded, and yocto/build
containing the stuff that was built. So far, so good.

Now, I need to do a completely unrelated project, based on an Intel Atom.
I've downloaded the BSP (the N2600/N2800/D2550), and the directions told me
to unpack it so that it's all contained in yocto/meta-intel. Does this mean
that this BSP isn't related to Poky? My yocto/poky directory is full of
other meta-blahblah stuff, so I would think that meta-intel would go in
there, one level down.

Then, the directions say to edit bblayers.conf, and possibly local.conf. The
only place I find these files are in my yocto/build/conf directory, but I
would think that doing a build for a different machine would involve setting
up a different build directory, e.g., yocto/buildatom. Is that correct? But
isn't the build directory set up by running the oe-init-build-env script,
which comes afterwards in the instructions?

Also, those instructions imply that I should run that script in the
yocto/poky directory, since that's where the script is located, but the
meta-intel is upstairs from that, which seems odd.

I'm confused by all this, but more to the point, I'm afraid of doing the
wrong thing, and clobbering the Gumstix stuff, which took a day and a half
to build. I expect the Atom build will also take a long time, but I don't
want to have to do it two more times.

Thanks in advance.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 
 

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


Re: [yocto] Newbie trying to get started

2013-02-28 Thread Sean Liming


 -Original Message-
 From: yocto-boun...@yoctoproject.org [mailto:yocto-
 boun...@yoctoproject.org] On Behalf Of Paul D. DeRocco
 Sent: Thursday, February 28, 2013 3:55 PM
 To: yocto@yoctoproject.org
 Subject: [yocto] Newbie trying to get started
 
 I've been working with a Gumstix, and have successfully built both the
 console and GUI version of their distro. So now I have two directories,
 yocto/poky containing everything that was downloaded, and yocto/build
 containing the stuff that was built. So far, so good.
 
 Now, I need to do a completely unrelated project, based on an Intel Atom.
 I've downloaded the BSP (the N2600/N2800/D2550), and the directions told
 me to unpack it so that it's all contained in yocto/meta-intel. Does this
mean
 that this BSP isn't related to Poky? My yocto/poky directory is full of
other
 meta-blahblah stuff, so I would think that meta-intel would go in there,
one
 level down.
 
 Then, the directions say to edit bblayers.conf, and possibly local.conf.
The
 only place I find these files are in my yocto/build/conf directory, but I
would
 think that doing a build for a different machine would involve setting up
a
 different build directory, e.g., yocto/buildatom. Is that correct? But
isn't the
 build directory set up by running the oe-init-build-env script, which
comes
 afterwards in the instructions?
 
 Also, those instructions imply that I should run that script in the
yocto/poky
 directory, since that's where the script is located, but the meta-intel is
 upstairs from that, which seems odd.
 
 I'm confused by all this, but more to the point, I'm afraid of doing the
wrong
 thing, and clobbering the Gumstix stuff, which took a day and a half to
build. I
 expect the Atom build will also take a long time, but I don't want to have
to
 do it two more times.
 
 Thanks in advance.
 
 --
 
 Ciao,   Paul D. DeRocco
 Paulmailto:pdero...@ix.netcom.com
 
 
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto

I have been working with the Intel Atom and Yocto Project -
http://www.annabooks.com/Book_OSSATOM.html 

1. Make sure you have first downloaded and extracted Poky. I extract Danny
as - Yocto 1.3/poky-danny-8.0
2. Download the BSP separately and unpack the contents to a temp folder.
There should be a meta-Intel directory.
3. Copy this meta-Intel folder to the Yocto 1.3/poky-danny-8.0 folder. Go
ahead and over write the directory that is there.

Yes, create a new project and build directory. you need to modify the
bblayers.conf file to point to the BSP files:

BBFILES ?= 
BBLAYERS ?=  \
  /home/user/Yocto1.3/poky-danny-8.0/meta \
  /home/user/Yocto1.3/poky-danny-8.0/meta-yocto \
  /home/user/Yocto1.3/poky-danny-8.0/meta-intel \  
  /home/user/Yocto1.3/poky-danny-8.0/meta-intel/meta-cedartrail \


Regards,

Sean Liming
Owner
Annabooks
Tel: 714-970-7523 / Cell: 858-774-3176

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


Re: [yocto] Newbie trying to get started

2013-02-28 Thread Paul D. DeRocco
 From: McClintock Matthew-B29882
 
 Not sure about the Intel BSPs but they may contain just their layer
 and/or poky + meta-intel. It does not really matter where meta-intel
 lives on your file system though. It can be referenced directly in
 your 'conf/bblayers.conf' file in your build folder.
 
  Then, the directions say to edit bblayers.conf, and 
 possibly local.conf. The
  only place I find these files are in my yocto/build/conf 
 directory, but I
  would think that doing a build for a different machine 
 would involve setting
  up a different build directory, e.g., yocto/buildatom. Is 
 that correct? But
  isn't the build directory set up by running the 
 oe-init-build-env script,
  which comes afterwards in the instructions?
 
 Different build folders are not an explicit requirement for different
 MACHINES (or in some cases unless there are some conflicts that are
 unknown diferrent distros - don't go out of your way to do this
 though). In fact if two MACHINES are the same ARCH you can reuse
 components between and save a lot of build time. That or use
 sstate-cache between two build folders which won't be quite as fast
 but almost...
 
  Also, those instructions imply that I should run that script in the
  yocto/poky directory, since that's where the script is 
 located, but the
  meta-intel is upstairs from that, which seems odd.
 
 Should not matter, you add meta-intel to 'conf/bblayers/conf' later.
 Unless this is possibly done for you via script - but I don't think
 any scripts in poky do this for you. Either way you can checkup on
 things layer to make sure the require layers are included.
 
  I'm confused by all this, but more to the point, I'm afraid 
 of doing the
  wrong thing, and clobbering the Gumstix stuff, which took a 
 day and a half
  to build. I expect the Atom build will also take a long 
 time, but I don't
  want to have to do it two more times.
 
 You are mixing gumstix and poky distros in one build folder? That
 could work as mentioned above, but it might encounter issues. I don't
 think it's regularly tested though so YMMV. My suggest would be to
 share the sstate-cache between the two build environments. So if one
 package has already been built it's reused (and the signatures match -
 which just means it's deemed compatible between machines)
 
 It's also quite likely you won't save much build time since gumstix
 and poky will be using different ARCHs and all the recipes will be
 rebuilt anyways. Again not really that familiar with gumstix so some
 statements above could be a bit off.

That's what I thought. You can't really share much of anything between a
Gumstix and an Atom, so I'm using a separate build tree.

But it's not working. The instructions tell me to set MACHINE to
cedartrail or cedartrail-nopvr in local.conf, so I chose the latter
since I'm doing a GUI-less system. And then it tells me to run bitbake
core-image-sato which seems strange, since sato refers to a desktop
manager or something graphical. After a lot of DEBUG output, I get the
following error message:

ERROR:  OE-core's config sanity checker detected a potential
misconfiguration.
Either fix the cause of this error or at your own risk disable the
checker (see sanity.conf).
Following is the list of potential problems / advisories:
Please set a valid MACHINE in your local.conf or environment

Also, I notice among the debug output, early on:

DEBUG: CONF file 'conf/machine/cedartrail-nopvr.conf' not found

even though that file exists in poky/meta-intel.

Is the problem that I'm making the wrong image for a GUI-less system? Where
are targets like core-image-sato defined? I don't see any file of that
name, with a .bb or any other extension, other than a prebuilt image.

I get the feeling I'm missing something.

By the way, I'm using the poky tree that was downloaded as a result of my
Gumstix build, except for the meta-intel subdirectory. Is that wrong?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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


Re: [yocto] Newbie trying to get started

2013-02-28 Thread McClintock Matthew-B29882
On Fri, Mar 1, 2013 at 12:20 AM, Paul D. DeRocco pdero...@ix.netcom.com wrote:
 From: McClintock Matthew-B29882

 Not sure about the Intel BSPs but they may contain just their layer
 and/or poky + meta-intel. It does not really matter where meta-intel
 lives on your file system though. It can be referenced directly in
 your 'conf/bblayers.conf' file in your build folder.

  Then, the directions say to edit bblayers.conf, and
 possibly local.conf. The
  only place I find these files are in my yocto/build/conf
 directory, but I
  would think that doing a build for a different machine
 would involve setting
  up a different build directory, e.g., yocto/buildatom. Is
 that correct? But
  isn't the build directory set up by running the
 oe-init-build-env script,
  which comes afterwards in the instructions?

 Different build folders are not an explicit requirement for different
 MACHINES (or in some cases unless there are some conflicts that are
 unknown diferrent distros - don't go out of your way to do this
 though). In fact if two MACHINES are the same ARCH you can reuse
 components between and save a lot of build time. That or use
 sstate-cache between two build folders which won't be quite as fast
 but almost...

  Also, those instructions imply that I should run that script in the
  yocto/poky directory, since that's where the script is
 located, but the
  meta-intel is upstairs from that, which seems odd.

 Should not matter, you add meta-intel to 'conf/bblayers/conf' later.
 Unless this is possibly done for you via script - but I don't think
 any scripts in poky do this for you. Either way you can checkup on
 things layer to make sure the require layers are included.

  I'm confused by all this, but more to the point, I'm afraid
 of doing the
  wrong thing, and clobbering the Gumstix stuff, which took a
 day and a half
  to build. I expect the Atom build will also take a long
 time, but I don't
  want to have to do it two more times.

 You are mixing gumstix and poky distros in one build folder? That
 could work as mentioned above, but it might encounter issues. I don't
 think it's regularly tested though so YMMV. My suggest would be to
 share the sstate-cache between the two build environments. So if one
 package has already been built it's reused (and the signatures match -
 which just means it's deemed compatible between machines)

 It's also quite likely you won't save much build time since gumstix
 and poky will be using different ARCHs and all the recipes will be
 rebuilt anyways. Again not really that familiar with gumstix so some
 statements above could be a bit off.

 That's what I thought. You can't really share much of anything between a
 Gumstix and an Atom, so I'm using a separate build tree.

 But it's not working. The instructions tell me to set MACHINE to
 cedartrail or cedartrail-nopvr in local.conf, so I chose the latter
 since I'm doing a GUI-less system. And then it tells me to run bitbake
 core-image-sato which seems strange, since sato refers to a desktop
 manager or something graphical. After a lot of DEBUG output, I get the
 following error message:

 ERROR:  OE-core's config sanity checker detected a potential
 misconfiguration.
 Either fix the cause of this error or at your own risk disable the
 checker (see sanity.conf).
 Following is the list of potential problems / advisories:
 Please set a valid MACHINE in your local.conf or environment

 Also, I notice among the debug output, early on:

 DEBUG: CONF file 'conf/machine/cedartrail-nopvr.conf' not found

 even though that file exists in poky/meta-intel.

Is the layer that contains this file in conf/bblayers.conf?

 Is the problem that I'm making the wrong image for a GUI-less system? Where
 are targets like core-image-sato defined? I don't see any file of that
 name, with a .bb or any other extension, other than a prebuilt image.

 I get the feeling I'm missing something.

What about just building core-image-minimal (this image has no gui)?

 By the way, I'm using the poky tree that was downloaded as a result of my
 Gumstix build, except for the meta-intel subdirectory. Is that wrong?

It could be you should check the differences between the two trees
each one is expecting (e.g. they could be based on different releases)

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


Re: [yocto] Newbie trying to get started

2013-02-28 Thread Paul D. DeRocco
Well, I'm making progress.

I discovered one mysterious cockpit error: my addition of meta-intel and
meta-intel/meta-cedartrail to bblayers.conf had somehow gotten lost. When I
added those lines again, the error concerning the invalid MACHINE
disappeared. I also found the recipe files for the various images, in meta
rather than meta-intel, so now I know that what I really want is something
called core-image-base, which is a console-based image that supports all
features of the machine except the graphics stuff.

Setting it up this way immediately complained that it couldn't find a file
called io32-base.inc, and a search found that this file doesn't exist
anywhere in my poky tree, even though Gumstix builds this tree by fetching
from the git repos, and I had just done a sync. However, I downloaded the
poky-danny-8.0 tarball, and it does include this file. It looks like my hope
that I could use the same poky tree that the Gumstix build fetched was a
pipe dream. Oh, well...

Anyway, bitbake core-image-base at least gets started. We'll see if it
makes it all the way through, some time tomorrow.

Thanks for your help.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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


Re: [yocto] Newbie trying to get started

2013-02-28 Thread Khem Raj
On (28/02/13 22:20), Paul D. DeRocco wrote:
  From: McClintock Matthew-B29882
  
  Not sure about the Intel BSPs but they may contain just their layer
  and/or poky + meta-intel. It does not really matter where meta-intel
  lives on your file system though. It can be referenced directly in
  your 'conf/bblayers.conf' file in your build folder.
  
   Then, the directions say to edit bblayers.conf, and 
  possibly local.conf. The
   only place I find these files are in my yocto/build/conf 
  directory, but I
   would think that doing a build for a different machine 
  would involve setting
   up a different build directory, e.g., yocto/buildatom. Is 
  that correct? But
   isn't the build directory set up by running the 
  oe-init-build-env script,
   which comes afterwards in the instructions?
  
  Different build folders are not an explicit requirement for different
  MACHINES (or in some cases unless there are some conflicts that are
  unknown diferrent distros - don't go out of your way to do this
  though). In fact if two MACHINES are the same ARCH you can reuse
  components between and save a lot of build time. That or use
  sstate-cache between two build folders which won't be quite as fast
  but almost...
  
   Also, those instructions imply that I should run that script in the
   yocto/poky directory, since that's where the script is 
  located, but the
   meta-intel is upstairs from that, which seems odd.
  
  Should not matter, you add meta-intel to 'conf/bblayers/conf' later.
  Unless this is possibly done for you via script - but I don't think
  any scripts in poky do this for you. Either way you can checkup on
  things layer to make sure the require layers are included.
  
   I'm confused by all this, but more to the point, I'm afraid 
  of doing the
   wrong thing, and clobbering the Gumstix stuff, which took a 
  day and a half
   to build. I expect the Atom build will also take a long 
  time, but I don't
   want to have to do it two more times.
  
  You are mixing gumstix and poky distros in one build folder? That
  could work as mentioned above, but it might encounter issues. I don't
  think it's regularly tested though so YMMV. My suggest would be to
  share the sstate-cache between the two build environments. So if one
  package has already been built it's reused (and the signatures match -
  which just means it's deemed compatible between machines)
  
  It's also quite likely you won't save much build time since gumstix
  and poky will be using different ARCHs and all the recipes will be
  rebuilt anyways. Again not really that familiar with gumstix so some
  statements above could be a bit off.
 
 That's what I thought. You can't really share much of anything between a
 Gumstix and an Atom, so I'm using a separate build tree.


well whole native recipes will be shared that a lot of build time saved

 
 But it's not working. The instructions tell me to set MACHINE to
 cedartrail or cedartrail-nopvr in local.conf, so I chose the latter
 since I'm doing a GUI-less system. And then it tells me to run bitbake
 core-image-sato which seems strange, since sato refers to a desktop
 manager or something graphical. After a lot of DEBUG output, I get the
 following error message:
 
 ERROR:  OE-core's config sanity checker detected a potential
 misconfiguration.
 Either fix the cause of this error or at your own risk disable the
 checker (see sanity.conf).
 Following is the list of potential problems / advisories:
 Please set a valid MACHINE in your local.conf or environment
 

you  simply add the right layer to conf/bblayers.conf

BBLAYERS = 
  ${TOPDIR}/sources/meta-intel/meta-cedartrail
  ...
  
and then 

MACHINE=cedartrail-nopvr bitbake core-image-minimal 
e.g. will build minimal image

 Also, I notice among the debug output, early on:
 
 DEBUG: CONF file 'conf/machine/cedartrail-nopvr.conf' not found
 
 even though that file exists in poky/meta-intel.
 
 Is the problem that I'm making the wrong image for a GUI-less system? Where
 are targets like core-image-sato defined? I don't see any file of that
 name, with a .bb or any other extension, other than a prebuilt image.
 
 I get the feeling I'm missing something.
 
 By the way, I'm using the poky tree that was downloaded as a result of my
 Gumstix build, except for the meta-intel subdirectory. Is that wrong?
 
 -- 
 
 Ciao,   Paul D. DeRocco
 Paulmailto:pdero...@ix.netcom.com 
 
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto

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