Sorry I missed without notice. I was standing outside of the daycare providers house with an 18 month old wonder where everyone was at 11:00 am this morning :( Bruce

That matches my understanding. Bruce

I can comment on some of this from the kernel point of view, I'll leave others to comment on platform/project/userspace issues. It is definitely possible to enable (basic or more capabilities) in the

The rest of the config has been moved to meta-extras, and we'd need to do a bit of kernel work, but it has worked in the past, and could work again in the future. In other words 'I agree'. Cheers, Bru

This is too much separation, having over categorization of the kernel defects at this point is overkill. I'd suggest three categories: - kernel build (which often transitions to straight up build-syst

It does. What we can also do, is split it between 'kernel' and 'BSP'. I've been triaging bugs like this for 6 years now, and typically it is very hard for the submitters to categorize properly. But ty

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 flo

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 a

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 t

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

In preparation for some larger kernel changes being sent for review, I'm clearing my queue of a few minor changes that were done while working on the 0.9 release. The uImage one is particularly intere

It is useful to override revision checking from a layer or other recipe. In order to show the global nature of the variable rename it KERNEL_REVISION_CHECKING and make it a weak assignment. Signed-off

The custom uImage produced by the kernel classes by default does not universally boot and working with existing uboot configurations and setups. This changes the preference to the uImage constructed b

But they aren't. The libc headers should be coupled to the kernel version. New ABIs are established and glibc can detect and deal with this, but you should never have a newer set of headers than the r

I've seen incompatibilities. Since we aren't running full toolchain validation, I do see some (minor) chances of 'bad things' happening. If we can limit it in eglibc, then things should be fine, since

It isn't used at the moment, so we can safely ignore this. It was a hold over from when I initially created the BSP, and I've since changed it locally, but haven't sent the updated BSP yet. Cheers, Br

Any interest in moving to a newer/different kernel ? The supported kernel for yocto is at 2.6.34 and I'll have a -dev tree tracking 2.6.37 shortly. My interest is getting more BSPs using the same kern

To clarify on this point, the kernel configuration is NOT using SPE for this, and I was attempting to use the FPU setting to trigger some different gcc flags during development the base of that test w

Indeed. I fell back to a safe multilib. I'm willing to try again and see if the gcc bootstrap phases will build. The kernel was fine, and is fine, it was userspace that caused problems for me .. and t

Agreed. For me, this is the slightly harder part. I'll start a few builds and see if the errors are still here. Should be doable. I've already got a generic set of configs/ patches/features in place f