This is a rebased and resent version of that I sent to poky@... (Thanks to Mark and Saul's suggestion). Since this is a non poky core change, I post this version in this mailing list. Please

Great, thanks Dave! :) I have spec'ed out and initiated an order for our newest server. In case anyone likes to geek out on hardware specs, here they are: Dell PowerEdge R710 2x Xeon X5680 @

This is a place where I think the Yocto Project can help. We're likely never going to have a final answer.. but what we'll be able to do is give these impromptu ABIs reasonable names so when people

Hello Mark, I don't see how we could be "final" on this, it seems a returning topic every few years. To bring in the OpenEmbedded arch namespace and our optimizations, from the "master" branch at

I think this is an area we need to coordinate.. I'm not against calling is ppce500v2 for right now. However, I think this is a place we need to coordinate efforts. I'm going to attempt to pull

Hello Mark, In OpenEmbedded we use the core variant as the packaging name: TARGET_CC_ARCH = "-mcpu=8548 -mspe=yes -mabi=spe -mhard-float -mfloat-gprs=double" BASE_PACKAGE_ARCH =

I'm sitting in a talk by Arnd Bergmann (IBM) at LPC. He's is speaking about "porting Linux to a new architecture, done right" and among the build systems he lists as good starting point he mentioned

I'm not sure we have all of the pieces in place yet in the toolchain. My quick looking of my own e500v1 & e500v2 support includes both libc patches and compiler patches. Just an FYI.. the compiler

It was particular to the mpc8315e config. Runtime on the target is fine, since this is all well known and working (we've had SPE/e500/e500v2 BSPs working for quite some time), the issue was specific

Hello Bruce, <bruce.ashfield@...> wrote: Was combo did you see problems with? I added e500v2 support to OpenEmbedded more than one year ago and have not seen issues yet in userspace

test

There is. And I'll clean it up a bit. The BSP bootstrap currently has a couple of different steps that are local to your build (but eventually merge to the kernel tree if a board is supported) which

2010/11/3 Bruce Ashfield <bruce.ashfield@...>: Sounds good. Is there anything you could share as a starting point? Frans

I can definitely guarantee that this would work in the yocto kernel (with a small local step for you), in fact, I've got a full BSP for this, and any of the extra features in the kernel (SPE, IEEE

At this point we have no added any e500 support to Poky. It would certainly be interesting to me to add/enable e500 support, as well as other spe optimizations that eglibc might provide. --Mark

Hi, I'm trying to add my powerpc board to yocto (as a test). This board mpc8536ds has an e500v2 core. It works under OE (MACHINE = "calamari"). but gcc-cross-initial fails in do_compile when it

Thats the full purpose of the winner is to deal with conflicts. Libraries should never conflict, if they do it's a bug in the library. The file dependencies that I added in the 0.9 work will resolve

2010/11/3 Richard Purdie <rpurdie@...>: ess it would be nice if bitbake would have given a decent error msg though. Richard, the recipe was a private kernel recipe which actually didn't do

Can you point at a copy of this recipe or the do_package function? At this point its hard to guess what the problem might be. I suspect you might be right about there being a reference to but not a

2010/11/3 Frans Meulenbroeks <fransmeulenbroeks@...>: Nevermind, already found the cause of the traceback. I accidently ran bitbake in the wrong dir. My default setup is such that BBPATH etc is