It seems like there is a way to use a prebuilt toolchain with poky but no real details. Some refs in the docs like: POKYMODE Toolchain selector. It can be external toolchain built from Poky or few

Matthew, Thanks for submitting this. A similar fix was recently rejected, as we are looking at a different way to accomplish this. See

Is it normal that the first stage (native) portion does not seem to either deal with BB_NUMBER_THREADS or PARALLEL_MAKE? - k

Saul has not woken up completely yet and thought that Paul made that change, thanks for speaking up! Sau!

Agreed, patch merged to master, thanks. Richard

Hmm, actually I missed the default to xterm change and thus did not alter that aspect of the comments. Therefore I think we should apply this. Cheers, Paul -- Paul Eggleton Intel Open Source

Matthew, Paul Eggelton recently made a similar change so I am going to drop this one. In the future Sau!

The original criteria for what we included was: * One board per architecture * Should be available to a general developer in a relatively cost effective manner (sub $1000?) * Lets us test

This sort of coverage would be great, and your options would be the big ones on my hit list as well. It allows us to at the least ensure that the build coverage is complete. This makes sense as

Most definitely. Having some sort of alignment on the kernel versions is nice, but we definitely don't expect all BSPs to follow every new kernel. And like Richard said, the model you are thinking

Just for reference, this is exactly what meta-intel intends to do. The released versions of the code there are based on a specific release of Yocto/OE-Core. When new BSPs are developed they are likely

I was wondering what distinction qualified for a BSP existing in a meta layer vs in poky directly. For FSL PPC we currently have MPC8315-RDB in poky. Ideally we'd have one BSP for each major flavor

I'm good w/just using the main yocto list for now until traffic gets to a point we think it makes sense to split it off - k

Hmm, I completely forgot about that list, and apparently everybody else has too (no messages in it). It's also not linked to from anywhere on the Yocto site that I can see e.g. Community | Mailing

What I'm envisioning as a start is we'd offer a meta layer on yocto sites for the upstream supported boards & feature set. I'm still looking at what we do for a FSL delivered BSP (via freescale.com)

Ok, same model would work for meta-fsl-ppc. The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@...' list. - k

So just to put what Bruce says into other words, there isn't any hard requirement to use linux-yocto but we are asking people to try it and if it doesn't work, at least tell us why. I understand

Hi Kumar, For meta-intel, it's pretty simple and is summarized by this blurb from the meta-intel MAINTAINERS file: "Please submit any patches against meta-intel BSPs to the Yocto mailing list

Hi Kumar, As you know, I've been working on several kernel efforts around the FSL parts as well (in particular the ones that have enough pieces upstream to work out of the box). I definitely don't