Good catch Robert. I have fixed this and pushed. Will notify maintainer.

Scott

On Fri, 15 Jul 2011, Richard Purdie wrote:

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.

ah, of course.

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.

ok, then that sentence should simply be reworded to make it clear
that it's not optional and root privilege is required. patch to
follow shortly.

rday

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.

Cheers,

Richard

(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?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On 07/14/11 18:27, Darren Hart wrote:

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

This has been merged and pushed to the kernel repos,
the SRCREV updates are pending.

Cheers,

Bruce

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 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?

Cheers,

Richard

On Fri, 2011-07-15 at 06:23 -0700, Richard Purdie wrote:

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! :)

Yeah, I wasn't sure all that would be welcome in there. ;-)

I'll respin it that way and resubmit...

Thanks for the input,

Tom

Cheers,

Richard

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.

- k

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

On 07/15/11 08:29, Kumar Gala wrote:

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:

Definitely. It was simply good fortune that it hadn't been
used yet. And when something like you are doing arrives, we
want to have it right. Just to have it right, is a good enough
reason!

Cheers,

Bruce

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 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 ""

Signed-off-by: Robert P. J. Day <rpjday@...>

---

i *think* this is what the author had in mind.

diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml
index 52f7391..d2e85ba 100644
--- a/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -213,9 +213,9 @@
</literallayout>

<literallayout class='monospaced'>
- $ sudo zypper install python gcc gcc-c++ libtool
- $ subversion git chrpath automake
- $ help2man diffstat texinfo mercurial wget
+ $ sudo zypper install python gcc gcc-c++ libtool \
+ subversion git chrpath automake \
+ help2man diffstat texinfo mercurial wget
</literallayout>

</section>

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

Signed-off-by: Robert P. J. Day <rpjday@...>

---

diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml
index 52f7391..c0ba207 100644
--- a/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -180,7 +180,7 @@
<note><para>
If you are using a Fedora version prior to version 15 you will need to take some
extra steps to enable <filename>sudo</filename>.
- See <ulink url='https://fedoraproject.org/wiki/Configureing_Sudo'></ulink> for details.
+ See <ulink url='https://fedoraproject.org/wiki/Configuring_Sudo'></ulink> for details.
</para></note>

<para>

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On Fri, 15 Jul 2011, Paul Eggleton wrote:

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?

sadly, i tossed the "bad" tarball, but i do recall that when i just
tried to check the contents with "tar tvjf", it eventually reported
unexpected EOF -- yes, i might have mentioned that earlier. :-P

so i'll just chalk it up to cosmic rays or something, but i did try
the same thing three times and got the same error result all three
times. this morning, though, everything's back to normal. go figure.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

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?

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

while the problem has since gone away, something strange happened
yesterday i figured i'd share.

as a quick test, wanted to build core-image-sato so started with:

$ bitbake -c fetchall core-image-sato

just to grab everything and i'd start the build later. but, as i
reported yesterday, fetch failed for two packages, one of them being
that linux tarball, linux-2.6.37.2.tar.bz2.

being lazy, back off a bit and just go for a minimal image:

$ bitbake -c fetchall core-image-minimal

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?

obviously, the fetch issue is now resolved but i'm baffled as to
what happened there.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

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

Signed-off-by: Kumar Gala<galak@...>
---
meta-yocto/conf/machine/mpc8315e-rdb.conf | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta-yocto/conf/machine/mpc8315e-rdb.conf b/meta-yocto/conf/machine/mpc8315e-rdb.conf
index 095d113..3f946a0 100644
--- a/meta-yocto/conf/machine/mpc8315e-rdb.conf
+++ b/meta-yocto/conf/machine/mpc8315e-rdb.conf
@@ -2,7 +2,7 @@
#@DESCRIPTION: Machine configuration for running

TARGET_ARCH = "powerpc"
-TARGET_FPU = "spe"
+TARGET_FPU = "hard"

require conf/machine/include/tune-ppc603e.inc

Fixes bug [YOCTO #1161]
Fixes bug [YOCTO #773]

This streamlines the routerstation pro configuration to remove options
that are either unecessary or that are causing bugs.

Also added to all branches is:

commit ffd73d6b2a9bfa0de5710b90a2237f4be66ae9a7
Author: Yinghai Lu <yinghai@...>
Date: Thu Jul 14 15:27:44 2011 -0700

mm: use alloc_bootmem_node_nopanic() on really needed path

commit 8f389a99b652aab5b42297280bd94d95933ad12f upstream.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../linux/linux-yocto_2.6.37.bbappend | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto_2.6.37.bbappend b/meta-yocto/recipes-kernel/linux/linux-yocto_2.6.37.bbappend
index b12dcef..ba25c3a 100644
--- a/meta-yocto/recipes-kernel/linux/linux-yocto_2.6.37.bbappend
+++ b/meta-yocto/recipes-kernel/linux/linux-yocto_2.6.37.bbappend
@@ -3,11 +3,11 @@ KMACHINE_routerstationpro = "yocto/standard/routerstationpro"
KMACHINE_mpc8315e-rdb = "yocto/standard/fsl-mpc8315e-rdb"
KMACHINE_beagleboard = "yocto/standard/beagleboard"

-SRCREV_machine_emenlow = "cc5662b9bec39205074c13f51ac4caba4af0afe7"
-SRCREV_machine_atom-pc = "687233649bbe0ec4ef26c2db4e369fecb1237f6f"
-SRCREV_machine_routerstationpro = "6214197a40b8fcb97dfad5b386d64384ce302b81"
-SRCREV_machine_mpc8315e-rdb = "e79b560f5bb709448d81e51609c0ce72253310fc"
-SRCREV_machine_beagleboard = "83544c00cd60f5842683d4b89a16a832271b599e"
+SRCREV_machine_emenlow = "398d5adac19cb411cd80753e177769f6a666a7e7"
+SRCREV_machine_atom-pc = "fce17f046d3756045e4dfb49221d1cf60fcae329"
+SRCREV_machine_routerstationpro = "8f84c1aec0907766ab6d6ac79fcc3b7b9ce79b70"
+SRCREV_machine_mpc8315e-rdb = "2c54835ac49cd8abaf294009a00ccc516daa31cd"
+SRCREV_machine_beagleboard = "3ddb22772862a8223640fa97580569924f51bddc"

COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
COMPATIBLE_MACHINE_routerstationpro = "routerstationpro"
--
1.7.4.1

This is a repeat of the oe-core version of the patch, here's
the duplicate text:

The patch itself says it all, but here's an update to the 2.6.37
kernel that fixes a few issues. No sense sitting on this until
3.0 is ready, but these same fixes have already been applied
to the dev kernel as well.

The first change is to meta, to address a couple of bugs with
the routerstation pro:

Fixes bug [YOCTO #1161]
Fixes bug [YOCTO #773]

This streamlines the routerstation pro configuration to remove options
that are either unecessary or that are causing bugs.

Also added to all branches is:

commit ffd73d6b2a9bfa0de5710b90a2237f4be66ae9a7
Author: Yinghai Lu <yinghai@...>
Date: Thu Jul 14 15:27:44 2011 -0700

mm: use alloc_bootmem_node_nopanic() on really needed path

commit 8f389a99b652aab5b42297280bd94d95933ad12f upstream.

Which is a commit from Darren that he needed when working on the
boot/footprint efforts.

The following changes since commit f45c49d19403be3291ec2a144401c379ab0b0476:

linux-yocto/meta: update meta SRCREV for routerstation pro (2011-07-15 00:57:11 -0400)

are available in the git repository at:
git://git.pokylinux.org/poky-contrib zedd/kernel-yocto
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (1):
linux-yocto/meta-yocto: update SRCREVS

.../linux/linux-yocto_2.6.37.bbappend | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)

--
1.7.4.1