On Fri, 2011-07-15 at 08:33 -0500, Kumar Gala wrote:

On Jul 14, 2011, at 9:36 PM, Kumar Gala wrote:

Where is the best place to ask questions and try and get support for adding some toolchain variations in?

I'm wanting to add support in for a few different flavors of PPC that are not currently supported:

* e500v2 (gcc needs --enable-e500_double, eglibc
* e5500 (64-bit embedded ppc)
* e5500 - multilib support for 32/64-bit

The other reason I ask is the recipes today don't seem to use (or allow for use of) --with-cpu.

Wondering who is the expect on these recipes to discuss such issues with.

The tune files (conf/machine/include/tune*) usually set the march and
mcpu options which are added to CFLAGS. Does that provide the
functionality you're looking for?

Wording change taken care of.

Scott

On Fri, 2011-07-15 at 10:15 -0400, Robert P. J. Day wrote:

(look on the bright side -- eventually, after many, many patches, i
will have nothing left to whine about.)

:)

from quick start manual, i notice that all toolchain tarballs have
"sdk" in the filename, whereas the actual downloads have "gmae". a
simple textual fix, i'm assuming. (what means "gmae"?)

GMAE = GNOME Mobile and Embedded

think cut down GNOME.

more significantly, QS manual states that toolchains "should" be
installed under /opt/poky. "should" is a loaded word -- it
implies a recommendation for some benefit but not an actual
requirement. and installing it there requires the reader to have
root privilege, something to be avoided if at all possible.

can someone clarify the "shouldness" or "mustness" of toolchain
installation under /opt/poky?

At this point its a requirement, we'd like to relax that but it
isn't possible right now.

(look on the bright side -- eventually, after many, many patches, i
will have nothing left to whine about.)

from quick start manual, i notice that all toolchain tarballs have
"sdk" in the filename, whereas the actual downloads have "gmae". a
simple textual fix, i'm assuming. (what means "gmae"?)

more significantly, QS manual states that toolchains "should" be
installed under /opt/poky. "should" is a loaded word -- it implies a
recommendation for some benefit but not an actual requirement. and
installing it there requires the reader to have root privilege,
something to be avoided if at all possible.

can someone clarify the "shouldness" or "mustness" of toolchain
installation under /opt/poky?

From: Darren Hart<dvhart@...>

The following patch from mainline addresses an issues that prevented my
qemu testing from booting in less than 17M of memory. With this page,
the kernel can boot to init in 8M of memory.

Apply to yocto/standard/base

The following changes since commit bb8e31f2c99f5e007660d4540df246fb7ecfa746:

USB: ehci: remove structure packing from ehci_def (2011-06-22 14:23:26 -0400)

are available in the git repository at:
git://git.yoctoproject.org/linux-yocto-2.6.37-contrib dvhart/mm
http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=dvhart/mm

Yinghai Lu (1):
mm: use alloc_bootmem_node_nopanic() on really needed path

include/linux/bootmem.h | 2 ++
mm/page_alloc.c | 7 ++++---
2 files changed, 6 insertions(+), 3 deletions(-)

On Jul 14, 2011, at 9:36 PM, Kumar Gala wrote:

Where is the best place to ask questions and try and get support for adding some toolchain variations in?

I'm wanting to add support in for a few different flavors of PPC that are not currently supported:

* e500v2 (gcc needs --enable-e500_double, eglibc
* e5500 (64-bit embedded ppc)
* e5500 - multilib support for 32/64-bit

The other reason I ask is the recipes today don't seem to use (or allow for use of) --with-cpu.

Wondering who is the expect on these recipes to discuss such issues with.

Hi Tom,

On Thu, 2011-07-14 at 19:55 -0500, tom.zanussi@... wrote:

From: Tom Zanussi <tom.zanussi@...>

The meta-intel BSPs currently have a number of machine settings common
to all - factor these out into a couple common include files.

For reference common include files are usually placed in
conf/machine/include/. If that happens they also need non-generic
suitably namespaced names, likely including "x86" or "ia32" in this
case.

The benefit is you can then refer to one of these includes from another
layer.

It also means you can refer to them as:

include conf/machine/includes/xxx

in other conf files removing some of the potential path issues.

I do like the cleanup this gives though, this is just a detail! :)

Cheers,

Richard

Where is the best place to ask questions and try and get support for adding some toolchain variations in?

I'm wanting to add support in for a few different flavors of PPC that are not currently supported:

* e500v2 (gcc needs --enable-e500_double, eglibc
* e5500 (64-bit embedded ppc)
* e5500 - multilib support for 32/64-bit

From: Tom Zanussi <tom.zanussi@...>

The meta-intel BSPs currently have a number of machine settings common
to all - factor these out into a couple common include files.

On Jul 15, 2011, at 12:31 AM, Bruce Ashfield wrote:

On 11-07-15 12:56 AM, Kumar Gala wrote:

The MPC8315E has a e300c3 core in it with 'classic' or normal PPC
floating point.

'SPE' floating point is what exists on the e500v2 core.

Acked-by: Bruce Ashfield<bruce.ashfield@...>

Been meaning to change this for a while, the good news, is that
the setting doesn't make any difference at the moment :)

Cheers,

Bruce

True, I want to use this for configure toolchain properly:

I'm looking at doing the following for when SPE is set:

diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
index 7bf036c..409ad01 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -12,6 +12,8 @@ FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
def get_gcc_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return "--with-float=soft"
+ if bb.data.getVar('TARGET_FPU', d, 1) in [ 'spe' ]:
+ return "--enable-e500_double"
return ""

On 11-07-15 12:56 AM, Kumar Gala wrote:

The MPC8315E has a e300c3 core in it with 'classic' or normal PPC
floating point.

'SPE' floating point is what exists on the e500v2 core.

Acked-by: Bruce Ashfield <bruce.ashfield@...>

Been meaning to change this for a while, the good news, is that
the setting doesn't make any difference at the moment :)

Cheers,

Bruce

On Friday 15 July 2011 11:47:44 Robert P. J. Day wrote:

unsurprisingly, the fetch for the linux tarball still failed for the
same reason as before -- incorrect checksums. huh. i typically don't
expect to see that in a simple fetch. so check KERNELORG_MIRROR (http
site), *manually* download that tarball and, sure enough, its md5 and
sha256 sums are the (incorrect) ones that bitbake is reporting, which
don't match what's expected. how odd. (i verified this two
additional times, same result.)

just as a test, i edited the bitbake.conf and changed
KERNELORG_MIRROR to refer to the kernel ftp site, cleared out the
remnants of that fetch, re-ran it and ... success! huh? so the
tarball via http is broken, but the one via ftp is good? but it was
late, so i just threw up my hands and went to bed.

this morning, manually download both tarballs (ftp and http), check
their sums and ... they match! reset everything, go back to the
original http KERNELORG_MIRROR value and it's all good. what the heck
was *that* all about?

Do you still have the tarball with the bad md5sum? Can you diff the
contents? Or was it simply a case of the bad tarball being
truncated?