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

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

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.

... 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

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

Right, not strictly needed, only for consistency, so the language should be softened, I agree. That is needed, but the steps that required editing files aren't easily captured in a transcript, so I

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@...> ---

just to clarify any overlooked issues ... 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

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

Some fairly straightforward to Appendix A: BSP Development Example in the Yocto Project Development Manual: * Remove obsolete commands * Fix spelling mistakes. Signed-off-by: Robert P. J. Day

On Tue, 1 Nov 2011, Tom Zanussi wrote: ... snip ... > Or at least that's what I'm building now. I'll post the full transcript > assuming I get a good build out of it... i'm also into task 301 of

Makes sense to me. Also, the same comment would apply to the main poky repo as well. No, not strictly necessary, but assuming you're using these instructions to create a new BSP, definitely

some questions/observations as i'm getting close to the end of this appendix (some of which you've already seen and addressed), all done on my 64-bit ubuntu 11.10 system: * section A.3: rather than

... snip ... let me finish following this through and i'll make notes on anything else that looks odd and report back. rday --

Probably what was meant was this instead: rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay/ And of course the first line in section A.5.2.2. doesn't apply and should be removed. rm

You're right, that line shouldn't be there (it should be removed from the instructions). The emgd recipes were moved out of meta-crownbay and into meta-intel/common, so this step is no longer

ironically, i'm working on this very example and something in the dev manual doesn't look right. section A.5.2.1: These commands take care of the recipes-bsp recipes: $ rm -rf

The odd thing is not only is the bzImage file is missing, but also is the whole kernel directory that bzImage is supposed to be locate in.

Yeah, normally, assuming you're using an existing kernel branch. But you didn't get a build error for the kernel, so I'm assuming that's the case. Tom

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