Out of curiosity. What's the logic/requirement behind this change ? Since we don't have a 'supported' 2.6.36 kernel, using these would be a mismatch with what is actually booting on the

Saul/RP, This is a pull request for upgrading most of the devel/toolchain recipes. This one is still missing the perl upgrade, and some gnome libs related python modules. I have done basic build

Today I tried upgrading python modules, and some of themodules have other dependencies for upgrading to the latest version. I was seeing these errors: Python-pygtk: | configure: error:

Please find enclosed the annotated list of recipes that are not currently built as part of any task or image. There are a some basic options that could occur with these recipes, do nothing, move the

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