Date   

Re: [PATCH] DOCS: Fix spelling error in link to Fedora sudo page.

Rifenbark, Scott M <scott.m.rifenbark@...>
 

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

Scott

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Robert P. J. Day
Sent: Friday, July 15, 2011 5:04 AM
To: Yocto discussion list
Subject: [yocto] [PATCH] DOCS: Fix spelling error in link to Fedora sudo page.


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
========================================================================
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: couple questions about toolchains from QS manual

Robert P. J. Day
 

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


Re: couple questions about toolchains from QS manual

Richard Purdie
 

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


couple questions about toolchains from QS manual

Robert P. J. Day
 

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


Re: [PATCH 0/1][linux-yocto] Fix boot failure with less than 17 MB RAM

Bruce Ashfield <bruce.ashfield@...>
 

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


Re: toolchain queries

Richard Purdie
 

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


Re: [PATCH 1/6] meta-intel: add a couple common .inc files

Tom Zanussi <tom.zanussi@...>
 

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


Re: toolchain queries

Kumar Gala <galak@...>
 

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


Re: [PATCH 1/6] meta-intel: add a couple common .inc files

Richard Purdie
 

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


Re: [PATCH] mpc8315e-rdb: Set TARGET_FPU correct

Bruce Ashfield <bruce.ashfield@...>
 

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


Re: [PATCH] mpc8315e-rdb: Set TARGET_FPU correct

Kumar Gala <galak@...>
 

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


[PATCH] DOCS: Correct format of command continuation.

Robert P. J. Day
 

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


[PATCH] DOCS: Fix spelling error in link to Fedora sudo page.

Robert P. J. Day
 

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


Re: when checksums collide -- the saga of linux-2.6.37.2.tar.bz2

Robert P. J. Day
 

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


Re: when checksums collide -- the saga of linux-2.6.37.2.tar.bz2

Paul Eggleton
 

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


when checksums collide -- the saga of linux-2.6.37.2.tar.bz2

Robert P. J. Day
 

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


yocto build fails

Gray, Mark D <mark.d.gray@...>
 

Hi all,

 

I have been trying to build on Ubuntu 11.0.4. I think I have followed the online documentation correctly. I have also followed the wiki page, which is required for me, to set up the proxy servers. However, the build is still failing for me. This is for Bernard-5.0.1. I get the following message

 

NOTE: Executing RunQueue Tasks

NOTE: Running task 697 of 1863 (ID: 484, /home/green/mdgray/yocto/poky-bernard-5.0.1/meta/recipes-kernel/linux/linux-yocto_git.bb, do_fetch)

NOTE: package linux-yocto-2.6.37+git1+212cae404e57ff9dc58c808035770d51325c3512_1+c75cbd202d8abb0b5f316f934f5d33c17ff6d3c3-r16: task do_fetch: Started

ERROR: Function 'Fetcher failure for URL: 'git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta'. Unable to fetch URL git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta from any source.' failed

ERROR: Logfile of failure stored in: /home/green/mdgray/yocto/poky-5.0.1-build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git1+212cae404e57ff9dc58c808035770d51325c3512_1+c75cbd202d8abb0b5f316f934f5d33c17ff6d3c3-r16/temp/log.do_fetch.8521

Log data follows:

| NOTE: fetch http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz

| Cloning into bare repository /home/green/mdgray/yocto/poky-5.0.1-build/downloads/git2/git.pokylinux.org.linux-yocto-2.6.37...

|  nc: read failed (0/3): Broken pipe

|  fatal: The remote end hung up unexpectedly

| ERROR: Function 'Fetcher failure for URL: 'git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta'. Unable to fetch URL git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta from any source.' failed

|

NOTE: package linux-yocto-2.6.37+git1+212cae404e57ff9dc58c808035770d51325c3512_1+c75cbd202d8abb0b5f316f934f5d33c17ff6d3c3-r16: task do_fetch: Failed

ERROR: Task 484 (/home/green/mdgray/yocto/poky-bernard-5.0.1/meta/recipes-kernel/linux/linux-yocto_git.bb, do_fetch) failed with exit code '1'

ERROR: '/home/green/mdgray/yocto/poky-bernard-5.0.1/meta/recipes-kernel/linux/linux-yocto_git.bb' failed

 

On closer inspection, the file http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz is unavailable in the repo. I did a search and I could only find http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz.bad

 

Can anyone help me on this?

 

Thanks

 

Mark

--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.


Re: [PATCH] mpc8315e-rdb: Set TARGET_FPU correct

Bruce Ashfield <bruce.ashfield@...>
 

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


[PATCH 1/1] linux-yocto/meta-yocto: update SRCREVS

Bruce Ashfield <bruce.ashfield@...>
 

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


[PATCH 0/1] linux-yocto/meta: update SRCREVs

Bruce Ashfield <bruce.ashfield@...>
 

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