Date   

[PATCH 0/1] Development Manual Appendix A changes

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Here are a set of changes that attempt to clean up the BSP Development
Manual a bit. Thanks to Robert P. J. Day and Jim Abernathy for their
input.

I went through the resulting doc and set things up exactly as written,
and so far the build is looking ok - will report if it doesn't turn out
as expected in the morning...

Tom

The following changes since commit 9b76e6a2cfc5a4d779f3b06e3acc5ff7b8275470:
Simon Busch (1):
meta: glib-2.0: don't apply qsort_r test removable patch for native version

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib.git tzanussi/appendix-a-changes
http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/appendix-a-changes

Tom Zanussi (1):
documentation/dev-manual: BSP Development Example changes

.../dev-manual/dev-manual-bsp-appendix.xml | 188 ++++++++++++++++----
1 files changed, 154 insertions(+), 34 deletions(-)


Help diagnosing a build failure involving ncurses, gettext, and eglibc

Darren Hart <dvhart@...>
 

I ran into various issues trying to add mtd-utils to an image today. As
I worked through the issues, I found after fixing a couple things, I was
more guessing and grasping at straws than anything else. I'll recount
what I did, and if anyone can offer a better approach to what I did that
would have resulted in a more deterministic result, I'd appreciate it
very much.

I copied meta-tiny to a new layer. I disabled uclibc (so I'm building
with eglibc). I added mtd-utils from OE and used the DEPENDS line using
util-linux (and not util-linux-ng which we don't have in yocto). This
resulted in ncurses failing the qa configure with host contamination
with the widec headers. I first attempted to enable widechar support in
my DISTRO_FEATURES_LIBC, and rebuild eglibc. This didn't solve the
problem. This turns out to be due to ncurses configuring in widechar
support regardless of whether or not you plan to use it (it does a widec
and a narrowc configure and only builds and installs widec if you set
ENABLE_WIDEC="true". I set that to false and hacked out the widec config
step which allowed ncurses to build. I'll send a proper fix for this
tomorrow.

The next failure was with gettext compilation. Several errors about
wchar related functions being redefined in incompatible ways. I thought
this might be related to DISTRO_FEATURES_LIBC changes I made, so I
commented them all out and rebuilt eglibc so it should be using the
default Poky distro configuration for eglibc (which I assumed gettext
was known to compile with). Gettext would still not compile, claiming
the redefined functions were first defined in /usr/include/wchar.h.
Confused, thinking I had just rebuilt eglibc, I did another cleanall of
eglibc and gettext and a rebuild. Same result.

Not trusting the sanity of my tmp tree at this point, I deleted tmp and
pseudodone and rebuilt the image. Everything succeeded and my final
image with mtd-utils included was built.

I tried to capture my complete log, but screen froze on me while trying
to paste the buffer into a log :( So besides writing a bitbake wrapper
to ensure I record ALL my bitbake sessions for reference, what would you
recommend I change in the above process? What could I have done to
either avoid deleting tmp or to have identified a possible bug that
required me to delete tmp?

Thanks,

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


Re: Build error while following Appendix A. Yocto Project Development manual

Jim Abernathy
 

I'm noticing fetcher failures while my bitbake is working. They are
listed as warning. Do I ignore these??

WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1500"; export
SSH_AUTH_SOCK="/tmp/keyring-Zcbzax/ssh"; export
GIT_CONFIG="/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux/usr/etc/gitconfig"; export PATH="/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux/usr/bin/core2-poky-linux:/home/jim/bsp-test/poky/build/tmp/sysroots/mymachine/usr/bin/crossscripts:/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux/usr/sbin:/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux/usr/bin:/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux/sbin:/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux//bin:/home/jim/bsp-test/poky/scripts:/home/jim/bsp-test/poky/bitbake/bin/:/home/jim/bsp-test/poky/scripts:/home/jim/bsp-test/poky/bitbake/bin/:/home/jim/bsp-test/poky/scripts:/home/jim/bsp-test/poky/bitbake/bin/:/home/jim/bsp-test/poky/scripts:/home/jim/bsp-test/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/CodeSourcery/Sourcery_G++_Lite/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/bsp-test/poky/scripts"; /usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P /home/jim/bsp-test/poky/build/downloads 'https://fedorahosted.org/releases/l/i/liberation-fonts/liberation-fonts-1.04.tar.gz' failed with signal 4, output:



Announcement: pseudo 1.2 released

Mark Hatle <mark.hatle@...>
 

Making a release announcement on behalf of the pseudo maintainer...

pseudo 1.2 is now released. It can be pulled from:

Via git:

git://github.com/wrpseudo/pseudo.git
git://git.yoctoproject.org/pseudo.git

branch PSEUDO_1_2

or the tarball from

http://downloads.yoctoproject.org/releases/pseudo/pseudo-1.2.tar.bz2

The included ChangeLog.txt
(http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/tree/ChangeLog.txt?h=PSEUDO_1_2)

Contains a full list of changes.

--Mark


Re: Build error while following Appendix A. Yocto Project Development manual

Tom Zanussi <tom.zanussi@...>
 

On Wed, 2011-11-02 at 13:07 -0700, Jim Abernathy wrote:
On Wed, 2011-11-02 at 14:36 -0500, Tom Zanussi wrote:

And what kind of machine are you booting it on?

Tom
I'm building on Core i5 desktop with Ubuntu 10.10. One of the odd
things I've noticed during the build is it takes the usual long time
(couple of hours) to build. However when it get to task ~4000, it jumps
Yeah, that's not out of line with expectations. You are using
BB_NUMBER_THREADS and PARALLEL make in your local.conf, I assume.

quickly to 43xx close to the end. Not sure if it's missing something
critical and I've not set some parameter about the Root file system
somewhere.
I wouldn't pay too much attention to the task numbers themselves - some
tasks take very little time and finish in quick progression. And
there's nothing specific about a root filesystem setting in the appendix
instructions, we're just copying existing working settings, but there is
something wrong with your build nonetheless.

I'm planning on submitting a patch to the appendix as soon as I can
today or tomorrow morning, which I'll work through and verify, so you
shouldn't have to do any guesswork and shouldn't run into any of these
kinds of problems...

Tom

Jim


Re: Build error while following Appendix A. Yocto Project Development manual

Jim Abernathy
 

On Wed, 2011-11-02 at 14:36 -0500, Tom Zanussi wrote:

And what kind of machine are you booting it on?

Tom
I'm building on Core i5 desktop with Ubuntu 10.10. One of the odd
things I've noticed during the build is it takes the usual long time
(couple of hours) to build. However when it get to task ~4000, it jumps
quickly to 43xx close to the end. Not sure if it's missing something
critical and I've not set some parameter about the Root file system
somewhere.

Jim


Re: Build error while following Appendix A. Yocto Project Development manual

Tom Zanussi <tom.zanussi@...>
 

On Wed, 2011-11-02 at 12:18 -0700, Jim Abernathy wrote:

Well, I finally got a "successful" build without erros of the Appendix A
example for Crownbay, but the image created was only 216MB in size and
kernel panic'ed because it couldn't find a valid root file system.
That size doesn't sound right. Here's mine:

-rw-r--r-- 1 trz trz 358715392 2011-11-01 19:11 core-image-sato-mymachine-20111101223904.hddimg

And what kind of machine are you booting it on?

Tom

I'm going to try again from scratch and see if I missed anything. If
that fails, I'll report out.

Jim A


Yocto Project 1.1 Announcement

Jeff Osier-Mixon <jefro@...>
 

Hi all - this is the announcement that went out on Weds at the Embedded Linux Conference Europe / LinuxCon Europe, in case you haven't seen it.

Yocto Project Introduces New Features

The Linux Foundation-hosted Yocto Project fosters growing community of embedded Linux developers, technologies and products

PRAGUE {LinuxCon Europe}, October 26, 2011 – The Yocto Project, a hosted project at The Linux Foundation, today announced the availability of Yocto Project Release 1.1, as well as a variety of one-year milestones for the project.

The Linux Foundation today also announced it will become the host for the Embedded GNU C Library (EGLIBC), further broadening and strengthening a common set of tools for embedded Linux development.

The EGLIBC library is an add-on to the GNU C library (glibc) and is optimized for use in embedded development. Until now, Mentor Graphics, the founder and chief maintainer of the project through its acquisition of CodeSourcery, hosted the EGLIBC library. Other participants have included Freescale, MIPS Technologies, MontaVista Software and Wind River, among others.

The Yocto Project was announced one year ago (October 2010) to provide developers with greater consistency in the software and tools they’re using across multiple architectures for embedded Linux development. The collaborative project brings together the elements needed to make the normally difficult embedded Linux development process much easier. The following milestones and activities are contributing to a vibrant community for embedded development:

• Alignment of OpenEmbedded technology and the inclusion of OpenEmbedded representation in the Yocto Project governance structure. The projects share a common core that consists of software build recipes and core Linux components that prevent fragmentation and reinforce the OpenEmbedded methodology as an open standard for embedded Linux build systems.

• Contribution of tools and technologies such as Cross-prelink, EGLIBC, Pseudo, Shoeleather Lab (for automated testing) and Swabber have been contributed from Intel, Mentor Graphics, MontaVista Software and Wind River.

• Commercial adoption with examples such as FIC’s Pegasus platform powered by Tridium’s Niagara Framework. The Pegasus platform is an industrial tablet design that was quickly ported to Linux based on existing Yocto Project Board Support Packages. Tridium is a world leader in software frameworks, automation infrastructure technology and device-to-enterprise integration solution, and FIC is a global designer and manufacturer of mobile and commercial hardware solutions.

• Board Support Packages that include Intel’s Atom-PC, Freescale’s MPC8315e-RDB, TI’s BeagleBoard and Ubiquiti’s RouterStation Pro, among others.

The new Yocto Project Release 1.1 is based on Linux kernel 3.0 and consists of the following new features and resources that enable developers and third parties to more quickly and easily build embedded Linux systems:

• Multi-lib: Reduces storage and memory footprint by allowing the system developer to mix and match binaries.

• Hob: An improved graphical user experience enables developers to select target architecture, image and layer combinations, and to select or remove individual packages before building, making the use of the Yocto tools even easier.

• Layer Tooling: Eases the integration and development of layers by “flattening” them together into a collection of meta-data, making it much easier for third parties to develop and release layers.

• Initial support for x32, allowing execution of 32-bit code with all the benefits of 64-bit mode bringing performance and footprint improvements on x86 processors.

• Small footprint/fast boot layers that make it easier to develop tiny embedded systems (less than 8MB of memory) with Yocto.

• New packages and components include 3G cellular data support and advanced btrfs filesystem, which improve applicability of the Yocto Project tools to new segments.

• New Yocto Project Developer Guide: This document provides important information on how to get started in open source, Board Support Package and kernel development.

“Since its introduction one year ago this week, the Yocto Project has exploded into a strong open source community of developers, users and vendors working together to advance Linux in the mobile and embedded markets,” said Jim Zemlin, executive director at The Linux Foundation. “The Yocto Project has quickly become a trusted upstream resource for embedded vendors who need to quickly and easily develop products for a variety of architectures, and get to market fast.”

Companies and organizations participating in the project include Dell, Intel, Mentor Graphics, MontaVista, OpenEmbedded eV, Texas Instruments, Timesys, and Wind River, among others. The Yocto Project participants are meeting this week at LinuxCon Europe and the Embedded Linux Conference in Prague, Czech Republic. For more information on these events, please visit the Linux Foundation conferences site. For more information about the Yocto Project, please visit: http://www.yoctoproject.org

“The Yocto Project provides an opportunity to help Intel customers differentiate and create unique solutions in the embedded market segment,” said Ton Steenman, vice president and general manager, Intelligent Systems Group, Intel. “Intel remains committed to choice in operating systems and our Intelligent Systems roadmap for embedded views the Yocto Project as a way to provide our customers with a flexible Linux enabling vehicle.”
 
“The EGLIBC library is a fundamental technology to an embedded Linux system. By integrating it with the Yocto Project and hosting it at The Linux Foundation, we can accelerate the development of EGLIBC,” said Mark Mitchell, Director of Tools, Mentor Graphics Embedded Software Division. “The new Shoeleather Lab hosted by Mentor Graphics will aid the Yocto Project by providing a neutral site for connecting developers to leading-edge hardware platforms, facilitating critical porting and optimization activities around Yocto and EGLIBC.”

“The Yocto Project is providing key resources specific to the embedded Linux developer community,” said Dan Cauchy, VP of Marketing and Business Development, MontaVista Software. “We’re glad to be collaborating with our industry peers in improving embedded Linux development.”

“The alignment of the Yocto Project and OpenEmbedded continues to accelerate our development," said Jason Kridner, ARM microprocessors community development manager at TI. "We're active in the Yocto Project because it moves as fast as we do to meet the market demands for embedded Linux development. We're proud to be a part of this community."

“The adoption of the Yocto Project validates the market demand for a common set of embedded Linux development tools,” said Paul Anderson, vice president of Linux products at Wind River. “As a founding member and active maintainer, Wind River is firmly committed to the success of the Yocto Project and will continue its contributions of code, resources, infrastructure, and tools, as well as draw from the Yocto Project as an upstream source for our commercial Linux releases.”

About The Linux Foundation

The Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux. Founded in 2000, the organization sponsors the work of Linux creator Linus Torvalds and promotes, protects and advances the Linux operating system by marshaling the resources of its members and the open source development community. The Linux Foundation provides a neutral forum for collaboration and education by hosting Linux conferences, including LinuxCon, and generating original Linux research and content that advances the understanding of the Linux platform. Its web properties, including Linux.com, reach approximately two million people per month and include important Linux video resources. The organization also provides extensive Linux training opportunities that feature the Linux kernel community’s leading experts as instructors. Follow The Linux Foundation on Twitter.

###

Trademarks: The Linux Foundation, Linux Standard Base, MeeGo, Tizen and Yocto Project are trademarks of The Linux Foundation. Linux is a trademark of Linus Torvalds.

-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org


Re: Build error while following Appendix A. Yocto Project Development manual

Jim Abernathy
 

Well, I finally got a "successful" build without erros of the Appendix A
example for Crownbay, but the image created was only 216MB in size and
kernel panic'ed because it couldn't find a valid root file system.

I'm going to try again from scratch and see if I missed anything. If
that fails, I'll report out.

Jim A


Re: meta-intel candidate branch for 1.1 edison point release

Tom Zanussi <tom.zanussi@...>
 

On Wed, 2011-11-02 at 10:17 -0700, Flanagan, Elizabeth wrote:
On Wed, Nov 2, 2011 at 9:37 AM, Tom Zanussi <tom.zanussi@...> wrote:
Hi,

I've created a new meta-intel/edison-next branch to hold commits
intended for the upcoming 1.1 point release.
From a build perspective, it would be better if these commits ended up
in the meta-intel/edison branch. It's generally what we do for
poky.git and I'd like to keep meta-intel the same. Also, the
autobuilder, when it builds out release branches like this, actually
will end up requiring that the release branches for all layers are the
same (at least until full layer support is implemented.)
Yes, they will end up there, as the next paragraph mentions:

"I'll be collecting candidate commits for a 1.1 point release there
until
it's time to cut the 1.1 point release, and will pull those into edison
proper at that point, assuming we have agreement on the set of patches
in the branch."

Tom


-b



Re: meta-intel candidate branch for 1.1 edison point release

Flanagan, Elizabeth <elizabeth.flanagan@...>
 

On Wed, Nov 2, 2011 at 9:37 AM, Tom Zanussi <tom.zanussi@...> wrote:
Hi,

I've created a new meta-intel/edison-next branch to hold commits
intended for the upcoming 1.1 point release.
From a build perspective, it would be better if these commits ended up
in the meta-intel/edison branch. It's generally what we do for
poky.git and I'd like to keep meta-intel the same. Also, the
autobuilder, when it builds out release branches like this, actually
will end up requiring that the release branches for all layers are the
same (at least until full layer support is implemented.)

-b



--
Elizabeth Flanagan
Yocto Project
Build and Release


meta-intel candidate branch for 1.1 edison point release

Tom Zanussi <tom.zanussi@...>
 

Hi,

I've created a new meta-intel/edison-next branch to hold commits
intended for the upcoming 1.1 point release.

I'll be collecting candidate commits for a 1.1 point release there until
it's time to cut the 1.1 point release, and will pull those into edison
proper at that point, assuming we have agreement on the set of patches
in the branch.

Please let me know if you have any comments on this set or if you know
of any missing patches that should be added.

Thanks,

Tom

Here's the current set of commit descriptions for the commits in that
branch:

commit 59292a744ad1ea7875c0f2b7564c4ad74af2d68e
Author: Tom Zanussi <tom.zanussi@...>
Date: Fri Oct 28 11:26:22 2011 -0500

meta-crownbay: allow linux-yocto-rt to be used for crownbay

The crownbay linux-yocto-rt .bbappend is missing settings needed for use
with crownbay - this adds them.

Signed-off-by: Tom Zanussi <tom.zanussi@...>

commit 3d78b56773943803f46c09f69e908506fff95b04
Author: Tom Zanussi <tom.zanussi@...>
Date: Thu Oct 27 23:48:15 2011 -0500

meta-fri2: allow linux-yocto-rt to be used for fri2-noemgd

The fri2 linux-yocto-rt .bbappend is missing settings needed for use
with fri2-noemgd - this adds them.

Signed-off-by: Tom Zanussi <tom.zanussi@...>

commit 9b901b4df24c88795e2a188e070249ef5273a8e9
Author: Tom Zanussi <tom.zanussi@...>
Date: Thu Oct 27 17:37:27 2011 -0500

meta-crownbay: add linux-yocto-rt_3.0.bbappend

commit 061f3187e8cbec70d5970928b6e8252cb0958f4a (meta-intel: move
emgd-driver-bin_1.8 to common) somehow mistakenly removed the
unrelated linux-yocto-rt_3.0.bbappend from meta-crownbay. This adds
it back.

Signed-off-by: Tom Zanussi <tom.zanussi@...>

commit cc0a4df25eb1db45698574d781c13fd7ee2ddaa7
Author: Tom Zanussi <tom.zanussi@...>
Date: Thu Oct 20 17:03:13 2011 -0500

meta-fri2: README correction

In the instructions for manually extracting the binaries from the EMGD
Linux tarball, an additional step for removing the emgd_drv_video
shared library is necessary; this adds it for fri2.

Signed-off-by: Tom Zanussi <tom.zanussi@...>

commit b8f9910a39196bdbce37dea25f82538b144d72dd
Author: Tom Zanussi <tom.zanussi@...>
Date: Thu Oct 20 17:01:39 2011 -0500

meta-crownbay: README correction

In the instructions for manually extracting the binaries from the EMGD
Linux tarball, an additional step for removing the emgd_drv_video
shared library is necessary; this adds it for crownbay.

Signed-off-by: Tom Zanussi <tom.zanussi@...>


The following changes since commit c3e12aa981e97261093abee05bb0301c35f54c23:
Tom Zanussi (1):
meta-emenlow: switch edison back to linux-yocto-2.6.37 kernel

are available in the git repository at:

git://git.yoctoproject.org/meta-intel.git tzanussi/edison-next
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/edison-next

Tom Zanussi (5):
meta-crownbay: README correction
meta-fri2: README correction
meta-crownbay: add linux-yocto-rt_3.0.bbappend
meta-fri2: allow linux-yocto-rt to be used for fri2-noemgd
meta-crownbay: allow linux-yocto-rt to be used for crownbay

meta-crownbay/README | 5 +++++
.../linux/linux-yocto-rt_3.0.bbappend | 20 ++++++++++++++++++++
meta-fri2/README | 9 +++++++++
.../linux/linux-yocto-rt_3.0.bbappend | 2 ++
4 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend


Re: Build error while following Appendix A. Yocto Project Development manual

Tom Zanussi <tom.zanussi@...>
 

On Wed, 2011-11-02 at 08:07 -0700, Jim Abernathy wrote:
Second, I looked at your cat of the same file containing the SRCREV
commit strings and I don't see that they agree with the commits on the
website even just this morning. Can you explain that? Should I just use
the ones in your cat output or eventually the corrected Dev. Manual?
I got these commits from the kernel .bb and .bbappends captured in the
edison branch, as mentioened above.

That's a lot clearer now. So does this mean that If I'm working with
edison branch, should I have to change the commits strings at all???
The commits in the doc should work - the SRCREV_machine is the last
commit on the edison branch for yocto/standard/common-pc/atom-pc and the
SRCREV_meta is also valid in edison, though in between the time the doc
was written and the time meta-intel was released for edison, the meta
SRCREV was bumped up to a later commit, which is the one I used in my
'cat'ed file. Either one should be fine. So no, you can directly use
the SRCREVS in the manual and don't have to change those at all.

Because the commit strings from your cat'ing of the your file don't
agree with what is in my clone of the edison branch for poky or
meta-intel. Or am I missing something else (likely).
Those commit strings identify commits in the linux-yocto_3.0 repo
(http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/). The
specific commits used for edison are captured in the linux-yocto_3.0 .bb
and .bbappend files mentioned previously.

Tom

Jim A


Re: Build error while following Appendix A. Yocto Project Development manual

Jim Abernathy
 

Second, I looked at your cat of the same file containing the SRCREV
commit strings and I don't see that they agree with the commits on the
website even just this morning. Can you explain that? Should I just use
the ones in your cat output or eventually the corrected Dev. Manual?
I got these commits from the kernel .bb and .bbappends captured in the
edison branch, as mentioened above.

That's a lot clearer now. So does this mean that If I'm working with
edison branch, should I have to change the commits strings at all???

Because the commit strings from your cat'ing of the your file don't
agree with what is in my clone of the edison branch for poky or
meta-intel. Or am I missing something else (likely).

Jim A


Re: Build error while following Appendix A. Yocto Project Development manual

Tom Zanussi <tom.zanussi@...>
 

On Wed, 2011-11-02 at 07:24 -0700, Jim Abernathy wrote:
okay, what you mentioned as the steps below, I agree with, but a couple
I don't understand. first, in the linux-yocto_3.0.bbappend file, why is
the KMACHINE statement changed to common-pc/atom-pc? If I look st eh
section of the doc in A.5.2.4 talking about going to
cgit/cgit.cgi/linux-yocto-3.0 to get the latest commit strings, I see
that it agrees with the path in #2, but not sure why??
This is part of the confusion I mentioned about this section that needs
to be cleaned up. Basically, for this example, to keep things simple,
we want to use an already-existing branch in the repo. The branch that
was somewhat vaguely chosen for this example was the atom-pc branch. So
this should be the branch specified in the KMACHINE, which my
corrected .bbappend shows, rather than the "yocto/standard/mymachine" in
the example code.

The mention of cgit/cgit.cgi/linux-yocto-3.0 to get the latest commit
strings is correct assuming you're working from master. But this
example is working from edison, where there commits to use are
essentially set in stone and contained in the SRCREVs in the .bb
and .bbappends in the edison branch.

Again, this is part of the confusion in this section that needs cleaning
up.

Second, I looked at your cat of the same file containing the SRCREV
commit strings and I don't see that they agree with the commits on the
website even just this morning. Can you explain that? Should I just use
the ones in your cat output or eventually the corrected Dev. Manual?
I got these commits from the kernel .bb and .bbappends captured in the
edison branch, as mentioened above.

Tom

Jim A

On Tue, 2011-11-01 at 19:45 -0500, Tom Zanussi wrote:
Hi James,

I'm still not sure what happened in your case to cause this problem, but
I just went through the Appendix A example pretty much as described, and
got a good build out of it. There was one particular part of the
example that wasn't exactly clear and that could definitely cause some
build problems if you did it incorrectly (the section that makes changes
to linux-yocto_3.0.bbappend, which in the example has a custom branch in
the .bbappend file, but has the explanation using atom-pc).

I'll work with Scott to make sure that part gets cleaned up, along with
the other comments that should get pulled in, but in the meantime, I
captured the steps I used below, which should work in the same way for
you.

trz@elmorro:/usr/local/dev/yocto$ mkdir bsp-test; cd bsp-test
trz@elmorro:/usr/local/dev/yocto/bsp-test$ git clone git://git.yoctoproject.org/poky
trz@elmorro:/usr/local/dev/yocto/bsp-test$ cd poky
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git checkout -b edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git clone git://git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ cd meta-intel
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ git checkout -b edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cp -a meta-crownbay/ meta-mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv meta-mymachine/conf/machine/crownbay-noemgd.conf meta-mymachine/conf/machine/mymachine.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay/
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay

----
The Developer's Manual seems to want to base the BSP on atom-pc for
this example, so we need to specify the atom-pc branch and get the
SRCREVs for atom-pc or the step that modifies the
linux-yocto_3.0.bbappend. So in
meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend, we find both
the KMACHINE branch we need, and the SRCREV on that branch we need for
edison. Since that doesn't specify the meta branch, but the base
recipe does, we can look at the SRCREV_meta there
(meta/recipes-kernel/linux/linux-yocto_3.0.bb) for the SRCREV of the
meta branch, which already matches what we're using, so no change
needed there.

Here's the resulting linux-yocto_3.0.bbappend:

trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cat meta-mymachine/recipes-kernel/linux/linux-yocto_3.0.bbappend

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

COMPATIBLE_MACHINE_mymachine = "mymachine"
KMACHINE_mymachine = "yocto/standard/common-pc/atom-pc"
KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"

SRCREV_machine_pn-linux-yocto_mymachine ?= "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
SRCREV_meta_pn-linux-yocto_mymachine ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"

----

trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ source oe-init-build-env
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ bitbake core-image-sato

NOTE: Tasks Summary: Attempted 4426 tasks of which 247 didn't need to be rerun and 0 failed.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/build


Tom


On Tue, 2011-11-01 at 12:48 -0700, James Abernathy wrote:
Just to clear up the basics, Prior to following Appendix A verbatim, I
did the following
1. install prerequisites from GS guide
2. git clone git://git.yoctoproject.org/poky
3. cd poky
4. git clone git://git.yoctoproject.org/meta-intel.git

I did not install the poky-extras. I assumed it only had to be
installed if you installed the kernel source for modification like in
Appendix b

Jim a




On Tue, Nov 1, 2011 at 3:40 PM, Tom Zanussi <tom.zanussi@...>
wrote:
Hi,

On Tue, 2011-11-01 at 11:37 -0700, James Abernathy wrote:
> I tried to duplicate the Yocto Project Decelopment Manual
Appendix A
> build of a Crownbay NOEMGD image, no changes just dulicate
the
> instructions. This is using the latest Yocto 1.1. I did
get a long
> way down the line, but had a fatal error in the last 2
steps.
>
> The only change I had to make was related to A.5.2.4. The
commit
> string for the SRCREV_meta_pn was different on the
> git.yoctoproject.org/cgit/cgi for the Meta commit so I used
what I
> found online. The first section of 126 task completed
without error.
> The next section of 4394 tasks failed on 4393. Not sure if
the error
> is obvious, but I wanted to run it by someone. Console error
log
> below:
>


Hmm, not sure what's going on here - I'm sure this example was
verified
several times, but just to make sure, what you're doing is
going through
'Appendix A. BSP Development Example' verbatim and getting
this?

The SRCREVs in either case look ok for this, so that shouldn't
be the
problem...

But let me go over the steps myself and see what I come up
with - will
let you know either way...

Tom


> NOTE: package core-image-sato-1.0-r0: task do_bootimg:
Started
> ERROR: Function 'build_boot_bin' failed
>
(see /home/jim/poky/yocto-build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.31418 for further information)
> ERROR: Logfile of failure stored
>
in: /home/jim/poky/yocto-build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.31418
> Log data follows:
> | install: cannot stat
>
`/home/jim/poky/yocto-build/tmp/sysroots/mymachine/kernel/bzImage': No
> such file or directory
> | ERROR: Function 'build_boot_bin' failed
>
(see /home/jim/poky/yocto-build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.31418 for further information)
> NOTE: package core-image-sato-1.0-r0: task do_bootimg:
Failed
> ERROR: Task 9
> (/home/jim/poky/meta/recipes-sato/images/core-image-sato.bb,
> do_bootimg) failed with exit code '1'
> ERROR:
'/home/jim/poky/meta/recipes-sato/images/core-image-sato.bb'
> failed
> jim@jim-ubuntu-10:~/poky/yocto-build$
>




Re: Build error while following Appendix A. Yocto Project Development manual

Robert P. J. Day
 

... all of tom's stuff snipped ...

ok, based on combining everything in the last several posts, my
build for core-image-sato for the new "mymachine" bsp just finished
successfully on my 64-bit ubuntu 11.10 system. happy, happy, joy,
joy. must write this all down somewhere. :-)

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Build error while following Appendix A. Yocto Project Development manual

Jim Abernathy
 

okay, what you mentioned as the steps below, I agree with, but a couple
I don't understand. first, in the linux-yocto_3.0.bbappend file, why is
the KMACHINE statement changed to common-pc/atom-pc? If I look st eh
section of the doc in A.5.2.4 talking about going to
cgit/cgit.cgi/linux-yocto-3.0 to get the latest commit strings, I see
that it agrees with the path in #2, but not sure why??

Second, I looked at your cat of the same file containing the SRCREV
commit strings and I don't see that they agree with the commits on the
website even just this morning. Can you explain that? Should I just use
the ones in your cat output or eventually the corrected Dev. Manual?

Jim A

On Tue, 2011-11-01 at 19:45 -0500, Tom Zanussi wrote:
Hi James,

I'm still not sure what happened in your case to cause this problem, but
I just went through the Appendix A example pretty much as described, and
got a good build out of it. There was one particular part of the
example that wasn't exactly clear and that could definitely cause some
build problems if you did it incorrectly (the section that makes changes
to linux-yocto_3.0.bbappend, which in the example has a custom branch in
the .bbappend file, but has the explanation using atom-pc).

I'll work with Scott to make sure that part gets cleaned up, along with
the other comments that should get pulled in, but in the meantime, I
captured the steps I used below, which should work in the same way for
you.

trz@elmorro:/usr/local/dev/yocto$ mkdir bsp-test; cd bsp-test
trz@elmorro:/usr/local/dev/yocto/bsp-test$ git clone git://git.yoctoproject.org/poky
trz@elmorro:/usr/local/dev/yocto/bsp-test$ cd poky
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git checkout -b edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git clone git://git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ cd meta-intel
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ git checkout -b edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cp -a meta-crownbay/ meta-mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv meta-mymachine/conf/machine/crownbay-noemgd.conf meta-mymachine/conf/machine/mymachine.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay/
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay

----
The Developer's Manual seems to want to base the BSP on atom-pc for
this example, so we need to specify the atom-pc branch and get the
SRCREVs for atom-pc or the step that modifies the
linux-yocto_3.0.bbappend. So in
meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend, we find both
the KMACHINE branch we need, and the SRCREV on that branch we need for
edison. Since that doesn't specify the meta branch, but the base
recipe does, we can look at the SRCREV_meta there
(meta/recipes-kernel/linux/linux-yocto_3.0.bb) for the SRCREV of the
meta branch, which already matches what we're using, so no change
needed there.

Here's the resulting linux-yocto_3.0.bbappend:

trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cat meta-mymachine/recipes-kernel/linux/linux-yocto_3.0.bbappend

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

COMPATIBLE_MACHINE_mymachine = "mymachine"
KMACHINE_mymachine = "yocto/standard/common-pc/atom-pc"
KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"

SRCREV_machine_pn-linux-yocto_mymachine ?= "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
SRCREV_meta_pn-linux-yocto_mymachine ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"

----

trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ source oe-init-build-env
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ bitbake core-image-sato

NOTE: Tasks Summary: Attempted 4426 tasks of which 247 didn't need to be rerun and 0 failed.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/build


Tom


On Tue, 2011-11-01 at 12:48 -0700, James Abernathy wrote:
Just to clear up the basics, Prior to following Appendix A verbatim, I
did the following
1. install prerequisites from GS guide
2. git clone git://git.yoctoproject.org/poky
3. cd poky
4. git clone git://git.yoctoproject.org/meta-intel.git

I did not install the poky-extras. I assumed it only had to be
installed if you installed the kernel source for modification like in
Appendix b

Jim a




On Tue, Nov 1, 2011 at 3:40 PM, Tom Zanussi <tom.zanussi@...>
wrote:
Hi,

On Tue, 2011-11-01 at 11:37 -0700, James Abernathy wrote:
> I tried to duplicate the Yocto Project Decelopment Manual
Appendix A
> build of a Crownbay NOEMGD image, no changes just dulicate
the
> instructions. This is using the latest Yocto 1.1. I did
get a long
> way down the line, but had a fatal error in the last 2
steps.
>
> The only change I had to make was related to A.5.2.4. The
commit
> string for the SRCREV_meta_pn was different on the
> git.yoctoproject.org/cgit/cgi for the Meta commit so I used
what I
> found online. The first section of 126 task completed
without error.
> The next section of 4394 tasks failed on 4393. Not sure if
the error
> is obvious, but I wanted to run it by someone. Console error
log
> below:
>


Hmm, not sure what's going on here - I'm sure this example was
verified
several times, but just to make sure, what you're doing is
going through
'Appendix A. BSP Development Example' verbatim and getting
this?

The SRCREVs in either case look ok for this, so that shouldn't
be the
problem...

But let me go over the steps myself and see what I come up
with - will
let you know either way...

Tom


> NOTE: package core-image-sato-1.0-r0: task do_bootimg:
Started
> ERROR: Function 'build_boot_bin' failed
>
(see /home/jim/poky/yocto-build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.31418 for further information)
> ERROR: Logfile of failure stored
>
in: /home/jim/poky/yocto-build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.31418
> Log data follows:
> | install: cannot stat
>
`/home/jim/poky/yocto-build/tmp/sysroots/mymachine/kernel/bzImage': No
> such file or directory
> | ERROR: Function 'build_boot_bin' failed
>
(see /home/jim/poky/yocto-build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.31418 for further information)
> NOTE: package core-image-sato-1.0-r0: task do_bootimg:
Failed
> ERROR: Task 9
> (/home/jim/poky/meta/recipes-sato/images/core-image-sato.bb,
> do_bootimg) failed with exit code '1'
> ERROR:
'/home/jim/poky/meta/recipes-sato/images/core-image-sato.bb'
> failed
> jim@jim-ubuntu-10:~/poky/yocto-build$
>




Re: Build error while following Appendix A. Yocto Project Development manual

Tom Zanussi <tom.zanussi@...>
 

On Wed, 2011-11-02 at 05:19 -0700, Robert P. J. Day wrote:
just to clarify any overlooked issues ...

On Tue, 1 Nov 2011, Tom Zanussi wrote:

... I captured the steps I used below, which should work in the same
way for you.

trz@elmorro:/usr/local/dev/yocto$ mkdir bsp-test; cd bsp-test
trz@elmorro:/usr/local/dev/yocto/bsp-test$ git clone git://git.yoctoproject.org/poky
trz@elmorro:/usr/local/dev/yocto/bsp-test$ cd poky
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git checkout -b edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git clone git://git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ cd meta-intel
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ git checkout -b edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cp -a meta-crownbay/ meta-mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv meta-mymachine/conf/machine/crownbay-noemgd.conf meta-mymachine/conf/machine/mymachine.conf
should one still change the NAME or DESCRIPTION comments in that new
mymachine.conf file to reflect "mymachine" as the dev-manual suggests,
or can one just leave them referring to crownbay? recall that the
current dev-manual claims that you "need" to make those changes. if
you don't, that claim should be softened.
Right, not strictly needed, only for consistency, so the language should
be softened, I agree.

also, there's no mention of editing "layer.conf" to reflect
"mymachine" as directed in dev-manual:

BBFILE_COLLECTIONS += "mymachine"

should that not be done? again, the current dev-manual states that
that change is "needed".
That is needed, but the steps that required editing files aren't easily
captured in a transcript, so I didn't capture those, but they are still
required. I should have added a <do editing step xxx from the doc here>
to make that clear, though I did mention that other than the
kernel .bbappend, the steps I went through were pretty much as
described. Anyway, hopefully we can get the changes from this thread in
the doc and it will then all fit together.

trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay/
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
don't you also have to rename "crownbay-noemgd/" to "mymachine/"
under that recipes-graphics/ directory as well, as the dev-manual
directs? you don't mention that here. you also don't mention making
Right, I missed that step. It still builds, though there would be
problems with X at runtime due to this.

editing changes to recipes-core/tasks/task-core-tools.bbappend as
dev-manual suggests. not necessary?
Yes, necessary, again, I didn't add the notes about editing.

Tom

Here's the resulting linux-yocto_3.0.bbappend:

trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cat meta-mymachine/recipes-kernel/linux/linux-yocto_3.0.bbappend

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

COMPATIBLE_MACHINE_mymachine = "mymachine"
KMACHINE_mymachine = "yocto/standard/common-pc/atom-pc"
KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"

SRCREV_machine_pn-linux-yocto_mymachine ?= "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
SRCREV_meta_pn-linux-yocto_mymachine ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
ok, just took that verbatim.

trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ source oe-init-build-env
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ bitbake core-image-sato

NOTE: Tasks Summary: Attempted 4426 tasks of which 247 didn't need to be rerun and 0 failed.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/build
other than sourcing from one directory level up and making the
appropriate changes in conf/local.conf to refer to "mymachine", no
difference here. just started the build ...

rday


[PATCH] oprofileui: allow build of server without X libs

Paul Eggleton
 

Fix the configure script to allow oprofile-server to be built
standalone (without needing GTK+ and other X-requiring libraries)

Signed-off-by: Paul Eggleton <paul.eggleton@...>
---
configure.ac | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index d49952e..2a7010b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -29,9 +29,11 @@ AC_ARG_ENABLE(client,
AM_CONDITIONAL(ENABLE_SERVER, test x$enable_server = xyes)
AM_CONDITIONAL(ENABLE_CLIENT, test x$enable_client = xyes)

-PKG_CHECK_MODULES(OPROFILEUI, [glib-2.0 libglade-2.0 gtk+-2.0 libxml-2.0 gconf-2.0])
-AC_SUBST(OPROFILEUI_CFLAGS)
-AC_SUBST(OPROFILEUI_LIBS)
+AS_IF([test "x$enable_client" = "xyes"], [
+ PKG_CHECK_MODULES(OPROFILEUI, [glib-2.0 libglade-2.0 gtk+-2.0 libxml-2.0 gconf-2.0])
+ AC_SUBST(OPROFILEUI_CFLAGS)
+ AC_SUBST(OPROFILEUI_LIBS)
+])

PKG_CHECK_MODULES(OPROFILE_SERVER, [glib-2.0])
AC_SUBST(OPROFILE_SERVER_CFLAGS)
@@ -41,7 +43,12 @@ AC_ARG_WITH(avahi,
[AC_HELP_STRING([--with-avahi], [Use Avahi to announce and search for OProfile servers])],
with_avahi="$withval", with_avahi=no)
if test $with_avahi = "yes"; then
- PKG_CHECK_MODULES(AVAHI, [avahi-client avahi-glib avahi-ui])
+ AS_IF([test "x$enable_client" = "xyes"], [
+ PKG_CHECK_MODULES(AVAHI, [avahi-client avahi-glib avahi-ui])
+ ],[
+ PKG_CHECK_MODULES(AVAHI, [avahi-client avahi-glib])
+ ])
+
AC_DEFINE_UNQUOTED(WITH_AVAHI, [1], [Using Avahi])
fi
AM_CONDITIONAL(WITH_AVAHI, test x$with_avahi = xyes)
--
1.7.5.4


Re: Build error while following Appendix A. Yocto Project Development manual

Robert P. J. Day
 

just to clarify any overlooked issues ...

On Tue, 1 Nov 2011, Tom Zanussi wrote:

... I captured the steps I used below, which should work in the same
way for you.

trz@elmorro:/usr/local/dev/yocto$ mkdir bsp-test; cd bsp-test
trz@elmorro:/usr/local/dev/yocto/bsp-test$ git clone git://git.yoctoproject.org/poky
trz@elmorro:/usr/local/dev/yocto/bsp-test$ cd poky
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git checkout -b edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git clone git://git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ cd meta-intel
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ git checkout -b edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cp -a meta-crownbay/ meta-mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv meta-mymachine/conf/machine/crownbay-noemgd.conf meta-mymachine/conf/machine/mymachine.conf
should one still change the NAME or DESCRIPTION comments in that new
mymachine.conf file to reflect "mymachine" as the dev-manual suggests,
or can one just leave them referring to crownbay? recall that the
current dev-manual claims that you "need" to make those changes. if
you don't, that claim should be softened.

also, there's no mention of editing "layer.conf" to reflect
"mymachine" as directed in dev-manual:

BBFILE_COLLECTIONS += "mymachine"

should that not be done? again, the current dev-manual states that
that change is "needed".

trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay/
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
don't you also have to rename "crownbay-noemgd/" to "mymachine/"
under that recipes-graphics/ directory as well, as the dev-manual
directs? you don't mention that here. you also don't mention making
editing changes to recipes-core/tasks/task-core-tools.bbappend as
dev-manual suggests. not necessary?

Here's the resulting linux-yocto_3.0.bbappend:

trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cat meta-mymachine/recipes-kernel/linux/linux-yocto_3.0.bbappend

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

COMPATIBLE_MACHINE_mymachine = "mymachine"
KMACHINE_mymachine = "yocto/standard/common-pc/atom-pc"
KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"

SRCREV_machine_pn-linux-yocto_mymachine ?= "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
SRCREV_meta_pn-linux-yocto_mymachine ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
ok, just took that verbatim.

trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ source oe-init-build-env
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ bitbake core-image-sato

NOTE: Tasks Summary: Attempted 4426 tasks of which 247 didn't need to be rerun and 0 failed.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/build
other than sourcing from one directory level up and making the
appropriate changes in conf/local.conf to refer to "mymachine", no
difference here. just started the build ...

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================