Date   

[PATCH 1/1] linux-yocto: fix machine compatibility

Bruce Ashfield <bruce.ashfield@...>
 

During the last phase of the recipe factoring, the board compatibility
lists ended up in the wrong place, which meant we had an incomplete
list of boards, and the same set of boards for both kernels (stable
and devel).

To fix this, I've yanked the compatibility to the recipes themselves and
updated the emenlow to have a -stable bbappend.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
...it.bbappend => linux-yocto-stable_git.bbappend} | 0
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 2 ++
meta/recipes-kernel/linux/linux-yocto.inc | 2 --
meta/recipes-kernel/linux/linux-yocto_git.bb | 1 +
4 files changed, 3 insertions(+), 2 deletions(-)
rename meta-emenlow/recipes/linux/{linux-yocto_git.bbappend => linux-yocto-stable_git.bbappend} (100%)

diff --git a/meta-emenlow/recipes/linux/linux-yocto_git.bbappend b/meta-emenlow/recipes/linux/linux-yocto-stable_git.bbappend
similarity index 100%
rename from meta-emenlow/recipes/linux/linux-yocto_git.bbappend
rename to meta-emenlow/recipes/linux/linux-yocto-stable_git.bbappend
diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
index 8ecd86f..dd4d176 100644
--- a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -17,6 +17,8 @@ PR = "r0"
PV = "${LINUX_VERSION}+git${SRCPV}"
SRCREV_FORMAT = "meta_machine"

+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"
+
# this performs a fixup on the SRCREV for new/undefined BSPs
python __anonymous () {
import bb, re
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
index 095b337..2a77f4a 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -7,8 +7,6 @@ LICENSE = "GPL"
# and it can be specific to the machine or shared
KMACHINE = "UNDEFINED"

-COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro)"
-
# Set this to 'preempt_rt' in the local.conf if you want a real time kernel
LINUX_KERNEL_TYPE ?= standard

diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb b/meta/recipes-kernel/linux/linux-yocto_git.bb
index 1e3df47..f40fe38 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -20,6 +20,7 @@ SRCREV_FORMAT = "meta_machine"
SRC_URI = "git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;noclone=1;branch=meta;name=meta"

+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)"

# Functionality flags
KERNEL_REVISION_CHECKING ?= "t"
--
1.7.0.4


[PATCH 0/1] linux-yocto: fix machine compatibility lists

Bruce Ashfield <bruce.ashfield@...>
 

During the last phase of the recipe factoring, the board compatibility
lists ended up in the wrong place, which meant we had an incomplete
list of boards, and the same set of boards for both kernels (stable
and devel).

To fix this, I've yanked the compatibility to the recipes themselves and
updated the emenlow to have a -stable bbappend.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield <bruce.ashfield@...>
---


Bruce Ashfield (1):
linux-yocto: fix machine compatibility

...it.bbappend => linux-yocto-stable_git.bbappend} | 0
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 2 ++
meta/recipes-kernel/linux/linux-yocto.inc | 2 --
meta/recipes-kernel/linux/linux-yocto_git.bb | 1 +
4 files changed, 3 insertions(+), 2 deletions(-)
rename meta-emenlow/recipes/linux/{linux-yocto_git.bbappend => linux-yocto-stable_git.bbappend} (100%)


Re: [poky] Milestone 2 Stabilization Branch Created (Resend)

Bruce Ashfield
 

On Mon, Dec 13, 2010 at 12:05 AM, Bruce Ashfield
<bruce.ashfield@...> wrote:
On 10-12-13 12:03 AM, Xu, Jiajun wrote:

On Sun, Dec 12, 2010 at 9:10 PM, Xu, Jiajun<jiajun.xu@...>  wrote:

[Resend with correct mailing lists]


Yocto / Poky Folks:

Thanks to everyone's hard work, we are currently on working getting
the first build of M2 started and available for QA testing on Monday.

I have pushed out the lastest commit that was pending in the
distro/master area to both master and create a builds/milestone
branch which is where bug fixes for M2 will go.

There is currently an issue with the PPC Kernel build on this branch
and that is being worked, this may impact getting a PPC build
available by Monday.

For the next week as we stabilize M2, please ensure that any patch
or pull requests indicate that this is for M2 or not.  By default
all commits will go to master regardless.
Hi Saul,
Nightly build is near finished now. PPC and some non-x86 real
hardware
target building failed. I begin downloading them now and will start QA
testing.

Is there somewhere I can check a log of the build errors ? We flipped
in the
2.6.37 kernel and associated tools, but the any hardware targets
should still be building 2.6.34 and be unaffected.

If it isn't a kernel that failed to build .. then I'm less help :)
For beagleboard,
http://autobuilder.pokylinux.org:8010/builders/nightly-release/builds/146/steps/shell_46/logs/stdio/text.
For mpc8315e-rdb,
http://autobuilder.pokylinux.org:8010/builders/nightly-release/builds/146/steps/shell_49/logs/stdio/text.
Both those boards are building random kernels .. one is building
the omap-pm (which is broken) and the other built linux-dummy.

So something went wrong with the merge of the new kernel, and could
be related to the board compatibility .. I'll have a look.
I made some changes (patch will be out shortly), they fix the emenlow, and
I can easily build the fsl and beagleboard out of the box with the changes
in place. Looks like a couple of boards were dropped from the stable
kernel recipe in all the chaos.

Bruce


Bruce


Cheers,

Bruce


Thanks
     Sau!
Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky
Best Regards,
Jiajun

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky

Best Regards,
Jiajun


_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky


--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"


[PATCH 1/1] qemuppc: update 2.6.37 SRCREV

Bruce Ashfield <bruce.ashfield@...>
 

Fixes [BUGID: 585]

The qemuppc irq handling was only partially updated to 2.6.37,
this completes the job. qemuppc builds and boots with this
change.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../conf/distro/include/poky-default-revisions.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc
index 81c39ab..be635e5 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -98,7 +98,7 @@ SRCREV_meta_pn-linux-yocto-stable ?= "d1cd5c80ee97e81e130be8c3de3965b770f320d6"
# development SRCREVs
SRCREV_machine_pn-linux-yocto_qemuarm = "87e00a2d47ba80b4ad1f9170cb3f6cf81f21d739"
SRCREV_machine_pn-linux-yocto_qemumips = "7231e473dd981a28e3cea9f677ed60583e731550"
-SRCREV_machine_pn-linux-yocto_qemuppc = "3ab3559637130b65d8889fa74286fdb57935726f"
+SRCREV_machine_pn-linux-yocto_qemuppc = "e2b529d7d74a9b21e1d1715f0c4062a4fd92a3ed"
SRCREV_machine_pn-linux-yocto_qemux86 = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
SRCREV_machine_pn-linux-yocto_qemux86-64 = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
SRCREV_machine_pn-linux-yocto_emenlow = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
--
1.7.0.4


[PATCH 0/1] qemuppc: fix 2.6.37 build failure

Bruce Ashfield <bruce.ashfield@...>
 

Somehow the ppc32 irq routines were only partially updated
to 2.6.37. I'll have to check later to see what happened, since
these were all built and booted here.

The fix is simple enough, here's the update for the SRCREV
that gets qemuppc building again.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield <bruce.ashfield@...>
---


Bruce Ashfield (1):
qemuppc: update 2.6.37 SRCREV

.../conf/distro/include/poky-default-revisions.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)


Re: [poky] Milestone 2 Stabilization Branch Created (Resend)

Bruce Ashfield <bruce.ashfield@...>
 

On 10-12-13 12:03 AM, Xu, Jiajun wrote:
On Sun, Dec 12, 2010 at 9:10 PM, Xu, Jiajun<jiajun.xu@...> wrote:
[Resend with correct mailing lists]


Yocto / Poky Folks:

Thanks to everyone's hard work, we are currently on working getting
the first build of M2 started and available for QA testing on Monday.

I have pushed out the lastest commit that was pending in the
distro/master area to both master and create a builds/milestone
branch which is where bug fixes for M2 will go.

There is currently an issue with the PPC Kernel build on this branch
and that is being worked, this may impact getting a PPC build
available by Monday.

For the next week as we stabilize M2, please ensure that any patch
or pull requests indicate that this is for M2 or not. By default
all commits will go to master regardless.
Hi Saul,
Nightly build is near finished now. PPC and some non-x86 real
hardware
target building failed. I begin downloading them now and will start QA testing.

Is there somewhere I can check a log of the build errors ? We flipped
in the
2.6.37 kernel and associated tools, but the any hardware targets
should still be building 2.6.34 and be unaffected.

If it isn't a kernel that failed to build .. then I'm less help :)
For beagleboard, http://autobuilder.pokylinux.org:8010/builders/nightly-release/builds/146/steps/shell_46/logs/stdio/text.
For mpc8315e-rdb, http://autobuilder.pokylinux.org:8010/builders/nightly-release/builds/146/steps/shell_49/logs/stdio/text.
Both those boards are building random kernels .. one is building
the omap-pm (which is broken) and the other built linux-dummy.

So something went wrong with the merge of the new kernel, and could
be related to the board compatibility .. I'll have a look.

Bruce


Cheers,

Bruce


Thanks
Sau!
Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky
Best Regards,
Jiajun

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky

Best Regards,
Jiajun


_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky


Re: [poky] Milestone 2 Stabilization Branch Created (Resend)

Xu, Jiajun <jiajun.xu@...>
 

On Sun, Dec 12, 2010 at 9:10 PM, Xu, Jiajun <jiajun.xu@...> wrote:
[Resend with correct mailing lists]


Yocto / Poky Folks:

Thanks to everyone's hard work, we are currently on working getting
the first build of M2 started and available for QA testing on Monday.

I have pushed out the lastest commit that was pending in the
distro/master area to both master and create a builds/milestone
branch which is where bug fixes for M2 will go.

There is currently an issue with the PPC Kernel build on this branch
and that is being worked, this may impact getting a PPC build
available by Monday.

For the next week as we stabilize M2, please ensure that any patch
or pull requests indicate that this is for M2 or not.  By default
all commits will go to master regardless.
Hi Saul,
Nightly build is near finished now. PPC and some non-x86 real
hardware
target building failed. I begin downloading them now and will start QA testing.

Is there somewhere I can check a log of the build errors ? We flipped
in the
2.6.37 kernel and associated tools, but the any hardware targets
should still be building 2.6.34 and be unaffected.

If it isn't a kernel that failed to build .. then I'm less help :)
For beagleboard, http://autobuilder.pokylinux.org:8010/builders/nightly-release/builds/146/steps/shell_46/logs/stdio/text.
For mpc8315e-rdb, http://autobuilder.pokylinux.org:8010/builders/nightly-release/builds/146/steps/shell_49/logs/stdio/text.

Cheers,

Bruce


Thanks
     Sau!
Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky
Best Regards,
Jiajun

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky

Best Regards,
Jiajun


Re: [poky] Milestone 2 Stabilization Branch Created (Resend)

Bruce Ashfield
 

On Sun, Dec 12, 2010 at 9:10 PM, Xu, Jiajun <jiajun.xu@...> wrote:
[Resend with correct mailing lists]


Yocto / Poky Folks:

Thanks to everyone's hard work, we are currently on working getting
the first build of M2 started and available for QA testing on Monday.

I have pushed out the lastest commit that was pending in the
distro/master area to both master and create a builds/milestone branch
which is where bug fixes for M2 will go.

There is currently an issue with the PPC Kernel build on this branch
and that is being worked, this may impact getting a PPC build available by Monday.

For the next week as we stabilize M2, please ensure that any patch or
pull requests indicate that this is for M2 or not.  By default all
commits will go to master regardless.
Hi Saul,
Nightly build is near finished now. PPC and some non-x86 real hardware target building failed. I begin downloading them now and will start QA testing.
Is there somewhere I can check a log of the build errors ? We flipped
in the 2.6.37 kernel and associated tools, but the any hardware targets
should still be building 2.6.34 and be unaffected.

If it isn't a kernel that failed to build .. then I'm less help :)

Cheers,

Bruce


Thanks
     Sau!
Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky
Best Regards,
Jiajun

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky


--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"


Re: Add extra parameters for qemu script

Scott Garman <scott.a.garman@...>
 

On 12/12/2010 05:43 PM, Ke, Liping wrote:
I tend to feel that this approach is more flexible, and scales better
than having to support each and every qemu option with our own script
syntax. Is this acceptable, or should we continue to support our own
custom options in addition to Criping's new approach?
My gut feeling is that having some simplified way to trigger possibly
complex option combinations is still desirable but adding a way to pass
additional custom commandline is equally good. This gives us the
maximum
flexibility moving forwards but keeps the script easy to use?
Hi, Scott

So the conclusion is that I should keep the old (serial nographic) option while
adding the new "<-XXX -XXX -XXX>" option?
OK. I will send out the modified patch to you for review later.
Yes, please respin the patch with those changes.

Thanks!

Scott

--
Scott Garman
Embedded Linux Distro Engineer - Yocto Project


Re: [poky] Milestone 2 Stabilization Branch Created (Resend)

Xu, Jiajun <jiajun.xu@...>
 

[Resend with correct mailing lists]


Yocto / Poky Folks:

Thanks to everyone's hard work, we are currently on working getting
the first build of M2 started and available for QA testing on Monday.

I have pushed out the lastest commit that was pending in the
distro/master area to both master and create a builds/milestone branch
which is where bug fixes for M2 will go.

There is currently an issue with the PPC Kernel build on this branch
and that is being worked, this may impact getting a PPC build available by Monday.

For the next week as we stabilize M2, please ensure that any patch or
pull requests indicate that this is for M2 or not. By default all
commits will go to master regardless.
Hi Saul,
Nightly build is near finished now. PPC and some non-x86 real hardware target building failed. I begin downloading them now and will start QA testing.

Thanks
Sau!
Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky
Best Regards,
Jiajun


Re: Add extra parameters for qemu script

Ke, Liping <liping.ke@...>
 

I tend to feel that this approach is more flexible, and scales better
than having to support each and every qemu option with our own script
syntax. Is this acceptable, or should we continue to support our own
custom options in addition to Criping's new approach?
My gut feeling is that having some simplified way to trigger possibly
complex option combinations is still desirable but adding a way to pass
additional custom commandline is equally good. This gives us the
maximum
flexibility moving forwards but keeps the script easy to use?
Hi, Scott

So the conclusion is that I should keep the old (serial nographic) option while
adding the new "<-XXX -XXX -XXX>" option?
OK. I will send out the modified patch to you for review later.

Thanks& Regards,
criping


Cheers,

Richard


Milestone 2 Stabilization Branch Created (Resend)

Saul Wold <sgw@...>
 

[Resend with correct mailing lists]


Yocto / Poky Folks:

Thanks to everyone's hard work, we are currently on working getting the first build of M2 started and available for QA testing on Monday.

I have pushed out the lastest commit that was pending in the distro/master area to both master and create a builds/milestone branch which is where bug fixes for M2 will go.

There is currently an issue with the PPC Kernel build on this branch and that is being worked, this may impact getting a PPC build available by Monday.

For the next week as we stabilize M2, please ensure that any patch or pull requests indicate that this is for M2 or not. By default all commits will go to master regardless.

Thanks
Sau!

Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System


about bitbake exec change

Qing He <qing.he@...>
 

Richard,

I've seen your recent bitbake change that reverts exec to fork, is there
intended to be the preparation for pseudo changes? Do you have some kind
of plan of next steps?

Btw, since pseudo change needs to ship pseudo binary which is kind of
weird, I've been considering some alternatives, i.e. the socket based
data. Can you help to review this idea?

The point is that, since shared memory is not easy if not impossible in
python (including the python internal data structure), can we use
something else like UNIX socket? Because for a single task, the
number of read/write access is limited. I've figured out several
aspects, including the extension to data_smart and how to arrange the
socket, but not sure about things like bb.cooker.

The idea is something like:
1. the extended data_smart:
a new field data["_remote_data"] is in place to work like current
"_data". Then, _findVar is almost the only thing needs to change
(this is greatly simplified though):
conn = data["_remote_data"]
conn.send(key)
data[key] = pickle.loads(conn.recv(4906))
Other methods that need change is __init__() and keys()

2. whenever bitbake runs a new task and calls bitbake-runtask, it sets
a socket and pass the socket file name to bitbake-runtask as a
command line parameter

3. the bitbake-runtask won't need cooker any more, currently, the
cooker itself also attributes a lot to the slowness, especially the
configuration loading phase


And if it's suitable, the socket listenners can even be put into the
bitbake server, then there is no need to ship binaries with poky.

Two things I'm not very sure about:
1. can cooker involvment be cleanly removed in bitbake-runtask, the
only reason of it is to load cache file, isn't it?
2. it would be very difficult for the task's own version of shadow data
be transfer back to main thread.

Do you think this approach is viable?

Thanks,
Qing


Re: [PATCH 0/1] Bug #528 fixing

Richard Purdie <rpurdie@...>
 

Hi Lianhao,

On Wed, 2010-12-01 at 11:31 +0800, Lianhao Lu wrote:
Since this my very first time trying to contribute to distro, so let me
put some fixing details here and warmly welcome the reivew/comment.

The purpose of this fixing is to add target name in the package name of
gcc(gdb/binutils)-cross-canadian so multiple cross-canadian toolchains
can be installed into the same SDK sysroot.

We choose the PN instead of the PACKAGE(or PKG_pn) to change the package
name because the -locale package is named by the PN. By changing PN, we
have different -locale and -doc packages for different target.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: llu/fix
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=llu/fix
These patches are just what we need, thanks.

We do however need to go one step further and complete the change which
is to remove the idea of "cross-canadian" packages from the packaging
backend and make all these "nativesdk", now there is no naming conflict.

I've attached a patch which starts to do this, I'm running some builds
to test this out a bit but the builds are not completing at the
moment :(.

Also note that I had to make the task-cross-canadian contain the
TARGET_ARCH in the PN which meant moving the TRANSLATED_TARGET_ARCH into
the more global namespace which I'm not too keen on.

Cheers,

Richard

(For reference, patches to Poky should go to the Poky list)


Re: why cp in do_install() change file permission mode?

Richard Purdie <rpurdie@...>
 

On Thu, 2010-12-02 at 18:16 +0800, Lu, Lianhao wrote:
Hi fellows,

Could anyone tell me why does the cp in do_install() change the file permission mode? Thanks!

do_install () {
rm -rf ${D}${installed_dir}
install -d ${D}${installed_dir}
cp -rp ${S}/* ${D}${installed_dir}
}

After "bitbake xxx -c install", I found the file under
${D}${installed_dir} had the permission mode of 0744 while the
corresponding file under directory ${S} had the mode of 0644. Why did
this happen? How to avoid this kind of mode change? Thanks!
do_install and all tasks that work on the output of do_install run under
pseduo which can mean the permissions on disk might not match the real
permissions as seen within a pseduo session.

To illustrate, in a do_install do something like

chown root.root somefile
ls -la somefile

then look at the file on disk and you'll see different owners. The
ownership works the same way as the permissions.

Cheers,

Richard

(Note Poky specific questions should be on the poky mailing list)


[PATCH 3/3] qemu: update arm timer handling

Bruce Ashfield <bruce.ashfield@...>
 

commit e388771458b4ff3ad81ab70e390b24d069647da4 in the upstream
kernel factored/cleaned the SP804 timer code. This commit exposed
issues in the qemu timer emulation that was dependent on the
old behaviour. As a result, no kernel past 2.6.34 would boot on
qemu-system-arm.

The quick fix is to backport two patches from the latest qemu
repositories that fix the timer handling under emulation. Long
term, these will be dropped when qemu is upreved.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../qemu-0.12.4/arm_timer-fix-oneshot-mode.patch | 32 ++++++++++++++++
.../arm_timer-reload-timer-when-enabled.patch | 40 ++++++++++++++++++++
meta/recipes-devtools/qemu/qemu_0.12.4.bb | 4 +-
3 files changed, 75 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch

diff --git a/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch b/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch
new file mode 100644
index 0000000..530736c
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch
@@ -0,0 +1,32 @@
+From a9cf98d939c4f6539fad7e7d812ea16d96ba3dc9 Mon Sep 17 00:00:00 2001
+From: Rabin Vincent <rabin@...>
+Date: Sun, 2 May 2010 15:20:52 +0530
+Subject: [PATCH] arm_timer: fix oneshot mode
+
+commit id: a9cf98d939c4f6539fad7e7d812ea16d96ba3dc9 in git://git.sv.gnu.org/qemu.git
+
+In oneshot mode, the delta needs to come from the TimerLoad register,
+not the maximum limit.
+
+Signed-off-by: Rabin Vincent <rabin@...>
+Signed-off-by: Aurelien Jarno <aurelien@...>
+---
+ hw/arm_timer.c | 2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/hw/arm_timer.c b/hw/arm_timer.c
+index 5b6947a..9073ffc 100644
+--- a/hw/arm_timer.c
++++ b/hw/arm_timer.c
+@@ -71,7 +71,7 @@ static void arm_timer_recalibrate(arm_timer_state *s, int reload)
+ {
+ uint32_t limit;
+
+- if ((s->control & TIMER_CTRL_PERIODIC) == 0) {
++ if ((s->control & (TIMER_CTRL_PERIODIC | TIMER_CTRL_ONESHOT)) == 0) {
+ /* Free running. */
+ if (s->control & TIMER_CTRL_32BIT)
+ limit = 0xffffffff;
+--
+1.6.5.2
+
diff --git a/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch b/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
new file mode 100644
index 0000000..1890e21
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
@@ -0,0 +1,40 @@
+From d6759902cb467c002086853d2eb38fb969c29f7f Mon Sep 17 00:00:00 2001
+From: Rabin Vincent <rabin@...>
+Date: Sun, 2 May 2010 15:20:51 +0530
+Subject: [PATCH] arm_timer: reload timer when enabled
+
+commit id: d6759902cb467c002086853d2eb38fb969c29f7f in git://git.sv.gnu.org/qemu.git
+
+Reload the timer when TimerControl is written, if the timer is to be
+enabled. Otherwise, if an earlier write to TimerLoad was done while
+periodic mode was not set, s->delta may incorrectly still have the value
+of the maximum limit instead of the value written to TimerLoad.
+
+This problem is evident on versatileap on current linux-next, which
+enables TIMER_CTRL_32BIT before writing to TimerLoad and then enabling
+periodic mode and starting the timer. This causes the first periodic
+tick to be scheduled to occur after 0xffffffff periods, leading to a
+perceived hang while the kernel waits for the first timer tick.
+
+Signed-off-by: Rabin Vincent <rabin@...>
+Signed-off-by: Aurelien Jarno <aurelien@...>
+---
+ hw/arm_timer.c | 2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/hw/arm_timer.c b/hw/arm_timer.c
+index 9fef191..5b6947a 100644
+--- a/hw/arm_timer.c
++++ b/hw/arm_timer.c
+@@ -113,7 +113,7 @@ static void arm_timer_write(void *opaque, target_phys_addr_t offset,
+ case 1: freq >>= 4; break;
+ case 2: freq >>= 8; break;
+ }
+- arm_timer_recalibrate(s, 0);
++ arm_timer_recalibrate(s, s->control & TIMER_CTRL_ENABLE);
+ ptimer_set_freq(s->timer, freq);
+ if (s->control & TIMER_CTRL_ENABLE) {
+ /* Restart the timer if still enabled. */
+--
+1.6.5.2
+
diff --git a/meta/recipes-devtools/qemu/qemu_0.12.4.bb b/meta/recipes-devtools/qemu/qemu_0.12.4.bb
index 04526d1..6125bca 100644
--- a/meta/recipes-devtools/qemu/qemu_0.12.4.bb
+++ b/meta/recipes-devtools/qemu/qemu_0.12.4.bb
@@ -25,7 +25,9 @@ SRC_URI = "\
file://cursor-shadow-fix.patch \
file://vmware-vga-fifo-rewind.patch \
file://fix-configure-checks.patch \
- file://powerpc_rom.bin"
+ file://powerpc_rom.bin \
+ file://arm_timer-fix-oneshot-mode.patch \
+ file://arm_timer-reload-timer-when-enabled.patch"

SRC_URI[md5sum] = "93e6b134dff89b2799f57b7d9e0e0fc5"
SRC_URI[sha256sum] = "1a29a5b5151162d1de035c4926d1a1dbffee4a145ef61ee865d6b82aaea0602e"
--
1.7.0.4


[PATCH 2/3] linux-libc-headers-yocto: use common linux-yocto routines

Bruce Ashfield <bruce.ashfield@...>
 

Modify linux-libc-headers-yocto to use the common linux-yocto
routines, so headers exported to userspace will track the
branches in the yocto kernel git repository.

This commit also switches supported boards to prefer the
yocto libc headers.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../linux-libc-headers-yocto_git.bb | 21 ++++++++-----------
1 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
index 3e3c1fa..0515233 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
@@ -1,4 +1,7 @@
require linux-libc-headers.inc
+include recipes-kernel/linux/linux-yocto.inc
+
+B = "${S}"

INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "unifdef-native"
@@ -8,7 +11,9 @@ PR = "r1"

SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;fullclone=1"

-S = "${WORKDIR}/linux"
+SRCREV_FORMAT = "meta_machine"
+SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
+ git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"

set_arch() {
case ${TARGET_ARCH} in
@@ -26,19 +31,11 @@ do_configure() {
oe_runmake allnoconfig ARCH=$ARCH
}

-do_kernel_checkout() {
- if [ -d ${WORKDIR}/.git/refs/remotes/origin ]; then
- rm -rf ${S}
- mkdir ${S}
- mv ${WORKDIR}/.git ${S}
- mv ${S}/.git/refs/remotes/origin/* ${S}/.git/refs/heads
- rmdir ${S}/.git/refs/remotes/origin
- fi
- cd ${S}
- git checkout -f standard
+do_kernel_configme() {
}

-addtask kernel_checkout before do_patch after do_unpack
+do_patch () {
+}

do_compile () {
}
--
1.7.0.4


[PATCH 1/3] yocto-kernel: factor common routes, update to 2.6.37 and branch renaming

Bruce Ashfield <bruce.ashfield@...>
 

In order to extend and create more kernel recipes based on the
supported yocto kernel common routines need to be placed in
re-usable blocks.

To accomplish this meta/recipes-kernel/linux/linux-yocto_git.bb
is broken into three parts:

- meta/classes/kernel-yocto.bbclass: contains common routines
for checking out and configuring a yocto kernel git repository.
This should be inherited by recipes that need this functionality.

- meta/recipes-kernel/linux/linux-yocto.inc: Contains the machine
mappings, compatibility, build directives and common task
definitions for a yocto kernel based recipe. This inherits
kernel-yocto, and is the typical point of entry for other recipes.

- meta/recipes-kernel/linux/linuux-tools.inc: tasks and function definitions
for kernel recipes that want to build/export perf

It also updates the linux-yocto recipe to default to 2.6.37.

As part of the update to 2.6.37 the branch naming and conventions
have been modified to show inheritance, and be more generic.

For example:

master
meta
yocto/base
yocto/standard/arm_versatile_926ejs
yocto/standard/base
yocto/standard/beagleboard
yocto/standard/common_pc/atom-pc
yocto/standard/common_pc/base
yocto/standard/common_pc_64
yocto/standard/fsl-mpc8315e-rdb
yocto/standard/intel_atom_z530
yocto/standard/intel_core_qm57_pch
yocto/standard/mti_malta32_be
yocto/standard/preempt_rt/base
yocto/standard/preempt_rt/common_pc
yocto/standard/preempt_rt/common_pc_64
yocto/standard/preempt_rt/intel_atom_z530
yocto/standard/preempt_rt/intel_core_qm57_pch
yocto/standard/qemu_ppc32
yocto/standard/routerstationpro

In this structure:

master: tracks the mainline kernel
meta: meta information for the BSPs and kernel features
yocto/base: baseline kernel branch
yocto/standard/base: 'standard' kernel, contains features
and configs for all BSPs
yocto/standard/<machine>: represents a BSP with specific
features or configurations

The tools, tree and libc-headers have all been updated to
deal with this new structure. Also in addition to dealing with
the new structure, they continue to work with the existing
tree and will adapt at runtime to the differences.

The linux-yocto-stable_git.bb recipe continues to build the
2.6.34 based tree,and linux-yocto_git.bb builds 2.6.37. As
boards are enabled for the new kernel they will move from
-stable to the development kernel. As of now, only the
emulated targets have moved to 2.6.37-rcX

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
meta-emenlow/conf/machine/emenlow.conf | 3 +-
meta/classes/kernel-yocto.bbclass | 202 ++++++++++++++++++
.../conf/distro/include/poky-default-revisions.inc | 36 +++-
meta/conf/machine/atom-pc.conf | 3 +-
meta/conf/machine/beagleboard.conf | 3 +-
meta/conf/machine/include/qemu.inc | 1 +
meta/conf/machine/mpc8315e-rdb.conf | 3 +-
meta/conf/machine/routerstationpro.conf | 3 +-
.../linux-libc-headers-yocto_git.bb | 4 +-
meta/recipes-kernel/linux/linux-tools.inc | 19 ++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
meta/recipes-kernel/linux/linux-yocto.inc | 23 ++
meta/recipes-kernel/linux/linux-yocto_git.bb | 219 ++------------------
13 files changed, 336 insertions(+), 224 deletions(-)
create mode 100644 meta/classes/kernel-yocto.bbclass
create mode 100644 meta/recipes-kernel/linux/linux-tools.inc
create mode 100644 meta/recipes-kernel/linux/linux-yocto-stable_git.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto.inc

diff --git a/meta-emenlow/conf/machine/emenlow.conf b/meta-emenlow/conf/machine/emenlow.conf
index 0f9ed8a..b8dea64 100644
--- a/meta-emenlow/conf/machine/emenlow.conf
+++ b/meta-emenlow/conf/machine/emenlow.conf
@@ -16,7 +16,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \

KERNEL_IMAGETYPE = "bzImage"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
PREFERRED_PROVIDER_libdrm = "libdrm-poulsbo"
PREFERRED_PROVIDER_drm = "libdrm-poulsbo"
PREFERRED_PROVIDER_virtual/libx11 = "libx11-trim"
diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
new file mode 100644
index 0000000..8e82012
--- /dev/null
+++ b/meta/classes/kernel-yocto.bbclass
@@ -0,0 +1,202 @@
+S = "${WORKDIR}/linux"
+
+# Determine which branch to fetch and build. Not all branches are in the
+# upstream repo (but will be locally created after the fetchers run) so
+# a fallback branch needs to be chosen.
+#
+# The default machine 'UNDEFINED'. If the machine is not set to a specific
+# branch in this recipe or in a recipe extension, then we fallback to a
+# branch that is always present 'standard'. This sets the KBRANCH variable
+# and is used in the SRC_URI. The machine is then set back to ${MACHINE},
+# since futher processing will use that to create local branches
+python __anonymous () {
+ import bb, re
+
+ version = bb.data.getVar("LINUX_VERSION", d, 1)
+ # 2.6.34 signifies the old-style tree, so we need some temporary
+ # conditional processing based on the kernel version.
+ if version == "2.6.34":
+ bb.data.setVar("KBRANCH", "${KMACHINE}-${LINUX_KERNEL_TYPE}", d)
+ bb.data.setVar("KMETA", "wrs_meta", d)
+ mach = bb.data.getVar("KMACHINE", d, 1)
+ if mach == "UNDEFINED":
+ bb.data.setVar("KBRANCH", "standard", d)
+ bb.data.setVar("KMACHINE", "${MACHINE}", d)
+ # track the global configuration on a bootstrapped BSP
+ bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
+ bb.data.setVar("BOOTSTRAP", "t", d)
+ else:
+ # The branch for a build is:
+ # yocto/<kernel type>/${KMACHINE} or
+ # yocto/<kernel type>/${KMACHINE}/base
+ bb.data.setVar("KBRANCH", bb.data.expand("yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}",d), d)
+ bb.data.setVar("KMETA", "meta", d)
+
+ mach = bb.data.getVar("KMACHINE", d, 1)
+ # drop the "/base" if it was on the KMACHINE
+ kmachine = mach.replace('/base','')
+ # and then write KMACHINE back
+ bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d), kmachine, d)
+
+ if mach == "UNDEFINED":
+ bb.data.setVar("KBRANCH", "yocto/standard/base", d)
+ bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d), bb.data.expand("${MACHINE}",d), d)
+ bb.data.setVar("SRCREV_machine", "standard", d)
+ bb.data.setVar("BOOTSTRAP", "t", d)
+}
+
+do_patch() {
+ cd ${S}
+ if [ -f ${WORKDIR}/defconfig ]; then
+ defconfig=${WORKDIR}/defconfig
+ fi
+
+ if [ -n "${BOOTSTRAP}" ]; then
+ kbranch="yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
+ else
+ kbranch=${KBRANCH}
+ fi
+
+ # simply ensures that a branch of the right name has been created
+ createme ${ARCH} ${kbranch} ${defconfig}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not create ${kbranch}"
+ exit 1
+ fi
+
+ # updates or generates the target description
+ if [ -n "${KERNEL_FEATURES}" ]; then
+ addon_features="--features ${KERNEL_FEATURES}"
+ fi
+ updateme ${addon_features} ${ARCH} ${WORKDIR}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not update ${kbranch}"
+ exit 1
+ fi
+
+ # executes and modifies the source tree as required
+ patchme ${kbranch}
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not modify ${kbranch}"
+ exit 1
+ fi
+}
+
+do_kernel_checkout() {
+ if [ -d ${WORKDIR}/.git/refs/remotes/origin ]; then
+ echo "Fixing up git directory for ${LINUX_KERNEL_TYPE}/${KMACHINE}"
+ rm -rf ${S}
+ mkdir ${S}
+ mv ${WORKDIR}/.git ${S}
+
+ if [ -e ${S}/.git/packed-refs ]; then
+ cd ${S}
+ rm -f .git/refs/remotes/origin/HEAD
+IFS='
+';
+ for r in `git show-ref | grep remotes`; do
+ ref=`echo $r | cut -d' ' -f1`;
+ b=`echo $r | cut -d' ' -f2 | sed 's%refs/remotes/origin/%%'`;
+ dir=`dirname $b`
+ mkdir -p .git/refs/heads/$dir
+ echo $ref > .git/refs/heads/$b
+ done
+ cd ..
+ else
+ cp -r ${S}/.git/refs/remotes/origin/* ${S}/.git/refs/heads
+ rmdir ${S}/.git/refs/remotes/origin
+ fi
+ fi
+ cd ${S}
+
+ # checkout and clobber and unimportant files
+ git checkout -f ${KBRANCH}
+}
+do_kernel_checkout[dirs] = "${S}"
+
+addtask kernel_checkout before do_patch after do_unpack
+
+do_kernel_configme() {
+ echo "[INFO] doing kernel configme"
+
+ cd ${S}
+ configme --reconfig
+ if [ $? -ne 0 ]; then
+ echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
+ exit 1
+ fi
+
+ echo "# Global settings from linux recipe" >> ${B}/.config
+ echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >> ${B}/.config
+}
+
+do_kernel_configcheck() {
+ echo "[INFO] validating kernel configuration"
+ cd ${B}/..
+ kconf_check ${B}/.config ${B} ${S} ${B} ${LINUX_VERSION} ${KMACHINE}-${LINUX_KERNEL_TYPE}
+}
+
+
+# Ensure that the branches (BSP and meta) are on the locatios specified by
+# their SRCREV values. If they are NOT on the right commits, the branches
+# are reset to the correct commit.
+do_validate_branches() {
+ cd ${S}
+ branch_head=`git show-ref -s --heads ${KBRANCH}`
+ meta_head=`git show-ref -s --heads ${KMETA}`
+ target_branch_head="${SRCREV_machine}"
+ target_meta_head="${SRCREV_meta}"
+
+ # nothing to do if bootstrapping
+ if [ -n "${BOOTSTRAP}" ]; then
+ return
+ fi
+
+ current=`git branch |grep \*|sed 's/^\* //'`
+ if [ -n "$target_branch_head" ] && [ "$branch_head" != "$target_branch_head" ]; then
+ if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
+ git show ${target_branch_head} > /dev/null 2>&1
+ if [ $? -eq 0 ]; then
+ echo "Forcing branch $current to ${target_branch_head}"
+ git branch -m $current $current-orig
+ git checkout -b $current ${target_branch_head}
+ else
+ echo "ERROR ${target_branch_head} is not a valid commit ID."
+ echo "The kernel source tree may be out of sync"
+ exit 1
+ fi
+ fi
+ fi
+
+ if [ "$meta_head" != "$target_meta_head" ]; then
+ if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
+ git show ${target_meta_head} > /dev/null 2>&1
+ if [ $? -eq 0 ]; then
+ echo "Forcing branch meta to ${target_meta_head}"
+ git branch -m ${KMETA} ${KMETA}-orig
+ git checkout -b ${KMETA} ${target_meta_head}
+ else
+ echo "ERROR ${target_meta_head} is not a valid commit ID"
+ echo "The kernel source tree may be out of sync"
+ exit 1
+ fi
+ fi
+ fi
+
+ # restore the branch for builds
+ git checkout -f ${KBRANCH}
+}
+
+# Many scripts want to look in arch/$arch/boot for the bootable
+# image. This poses a problem for vmlinux based booting. This
+# task arranges to have vmlinux appear in the normalized directory
+# location.
+do_kernel_link_vmlinux() {
+ if [ ! -d "${B}/arch/${ARCH}/boot" ]; then
+ mkdir ${B}/arch/${ARCH}/boot
+ fi
+ cd ${B}/arch/${ARCH}/boot
+ ln -sf ../../../vmlinux
+}
+
+
diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc
index 7f3468d..fa6d785 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -56,7 +56,7 @@ SRCREV_pn-gypsy ??= "147"
SRCREV_pn-inputproto ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-native ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
SRCREV_pn-inputproto-nativesdk ??= "7203036522ba9d4b224d282d6afc2d0b947711ee"
-SRCREV_pn-kern-tools-native ??= "9722d8decacd2b750f079b3fde7918810700f80e"
+SRCREV_pn-kern-tools-native ??= "c85dcdd2dc50d71476a11c2960bf14c2b144b3c7"
SRCREV_pn-libdrm ??= "3f3c5be6f908272199ccf53f108b1124bfe0a00e"
SRCREV_pn-libfakekey ??= "2031"
SRCREV_pn-libgdbus ??= "aeab6e3c0185b271ca343b439470491b99cc587f"
@@ -83,17 +83,29 @@ SRCREV_pn-linux-omap-zoomsync ??= "015cbaf1035cd9a61d33a27de2a22902555db3c5"
SRCREV_pn-linux-omap2 ??= "d3b3ae0fe6c71641da19c8de466ec366d39847e3"
SRCREV_pn-linux-omap3 ??= "de1121fdb899f762b9e717f44eaf3fae7c00cd3e"
SRCREV_pn-linux-omap3-pm ??= "totallybroken"
-SRCREV_machine_pn-linux-yocto_qemuarm ?= "4f4177b4bea5b8858acc1eeb788d80b7af0df962"
-SRCREV_machine_pn-linux-yocto_qemumips ?= "81f3cd467b9d51fa1dfa2d5939337cc756ae8061"
-SRCREV_machine_pn-linux-yocto_qemuppc ?= "9ac0daee43dd19d8bea828cf79450c9748ae0daa"
-SRCREV_machine_pn-linux-yocto_qemux86 ?= "0431115c9d720fee5bb105f6a7411efb4f851d26"
-SRCREV_machine_pn-linux-yocto_qemux86-64 ?= "0431115c9d720fee5bb105f6a7411efb4f851d26"
-SRCREV_machine_pn-linux-yocto_emenlow ?= "aae69fdf104b0a9d7b3710f808aac6ab303490f7"
-SRCREV_machine_pn-linux-yocto_atom-pc ?= "0431115c9d720fee5bb105f6a7411efb4f851d26"
-SRCREV_machine_pn-linux-yocto_routerstationpro ?= "2ec2edaf256dd8500ee3d4763fee6ca3ecd6da4b"
-SRCREV_machine_pn-linux-yocto_mpc8315e-rdb ?= "986e6eb66c26007cee7916d5d12f4756e6b5436f"
-SRCREV_machine_pn-linux-yocto_beagleboard ?= "0431115c9d720fee5bb105f6a7411efb4f851d26"
-SRCREV_meta_pn-linux-yocto ?= "d1cd5c80ee97e81e130be8c3de3965b770f320d6"
+SRCREV_machine_pn-linux-yocto-stable_qemuarm ?= "4f4177b4bea5b8858acc1eeb788d80b7af0df962"
+SRCREV_machine_pn-linux-yocto-stable_qemumips ?= "81f3cd467b9d51fa1dfa2d5939337cc756ae8061"
+SRCREV_machine_pn-linux-yocto-stable_qemuppc ?= "9ac0daee43dd19d8bea828cf79450c9748ae0daa"
+SRCREV_machine_pn-linux-yocto-stable_qemux86 ?= "0431115c9d720fee5bb105f6a7411efb4f851d26"
+SRCREV_machine_pn-linux-yocto-stable_qemux86-64 ?= "0431115c9d720fee5bb105f6a7411efb4f851d26"
+SRCREV_machine_pn-linux-yocto-stable_emenlow ?= "aae69fdf104b0a9d7b3710f808aac6ab303490f7"
+SRCREV_machine_pn-linux-yocto-stable_atom-pc ?= "0431115c9d720fee5bb105f6a7411efb4f851d26"
+SRCREV_machine_pn-linux-yocto-stable_routerstationpro ?= "2ec2edaf256dd8500ee3d4763fee6ca3ecd6da4b"
+SRCREV_machine_pn-linux-yocto-stable_mpc8315e-rdb ?= "986e6eb66c26007cee7916d5d12f4756e6b5436f"
+SRCREV_machine_pn-linux-yocto-stable_beagleboard ?= "0431115c9d720fee5bb105f6a7411efb4f851d26"
+SRCREV_meta_pn-linux-yocto-stable ?= "d1cd5c80ee97e81e130be8c3de3965b770f320d6"
+# development SRCREVs
+SRCREV_machine_pn-linux-yocto_qemuarm = "87e00a2d47ba80b4ad1f9170cb3f6cf81f21d739"
+SRCREV_machine_pn-linux-yocto_qemumips = "7231e473dd981a28e3cea9f677ed60583e731550"
+SRCREV_machine_pn-linux-yocto_qemuppc = "3ab3559637130b65d8889fa74286fdb57935726f"
+SRCREV_machine_pn-linux-yocto_qemux86 = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_qemux86-64 = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_emenlow = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_atom-pc = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_machine_pn-linux-yocto_routerstationpro = "773d3a1c8eba563ffcdbf61057ef6e39cee0c88b"
+SRCREV_machine_pn-linux-yocto_mpc8315e-rdb = "5ff609967ffe87c49d534d7861a7e0b150517726"
+SRCREV_machine_pn-linux-yocto_beagleboard = "87aacc373557f8849dde8618fbe1f7f8f2af6038"
+SRCREV_meta_pn-linux-yocto ?= "ee0a10ab687b29c4d22d47e5b28bc8b3ebb7a8d9"
SRCREV_pn-linux-libc-headers-yocto ??= "09a39c638dd65dc27c549c119abe1af2631b2ae0"
SRCREV_pn-matchbox-config-gtk ??= "2081"
SRCREV_pn-matchbox-desktop-sato ??= "76"
diff --git a/meta/conf/machine/atom-pc.conf b/meta/conf/machine/atom-pc.conf
index 7ca952a..8cf09b8 100644
--- a/meta/conf/machine/atom-pc.conf
+++ b/meta/conf/machine/atom-pc.conf
@@ -13,7 +13,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 wifi \

KERNEL_IMAGETYPE = "bzImage"

-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri"
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite"
diff --git a/meta/conf/machine/beagleboard.conf b/meta/conf/machine/beagleboard.conf
index 657bd36..1b73250 100644
--- a/meta/conf/machine/beagleboard.conf
+++ b/meta/conf/machine/beagleboard.conf
@@ -22,7 +22,8 @@ EXTRA_IMAGECMD_jffs2 = "-lnp "
# Guesswork
SERIAL_CONSOLE = "115200 ttyS2"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

KERNEL_IMAGETYPE = "uImage"

diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
index 1b1b888..502e24f 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -16,5 +16,6 @@ RDEPENDS_kernel-base = ""

# Use a common kernel recipe for all QEMU machines
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
diff --git a/meta/conf/machine/mpc8315e-rdb.conf b/meta/conf/machine/mpc8315e-rdb.conf
index 3341186..1b7982a 100644
--- a/meta/conf/machine/mpc8315e-rdb.conf
+++ b/meta/conf/machine/mpc8315e-rdb.conf
@@ -13,4 +13,5 @@ SERIAL_CONSOLE = "115200 ttyS0"

MACHINE_FEATURES = "kernel26 keyboard pci ext2 ext3 serial"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
diff --git a/meta/conf/machine/routerstationpro.conf b/meta/conf/machine/routerstationpro.conf
index 485ee3c..4f1bbbb 100644
--- a/meta/conf/machine/routerstationpro.conf
+++ b/meta/conf/machine/routerstationpro.conf
@@ -12,7 +12,8 @@ MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 \
KERNEL_IMAGETYPE = "vmlinux"
KERNEL_ALT_IMAGETYPE = "vmlinux.bin"

-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-stable"
+#PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

SERIAL_CONSOLE = "115200 ttyS0"

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
index 6ae6d5f..3e3c1fa 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb
@@ -4,7 +4,7 @@ INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "unifdef-native"
PROVIDES = "linux-libc-headers"
PV = "2.6.34+git-${SRCPV}"
-PR = "r0"
+PR = "r1"

SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;fullclone=1"

@@ -45,7 +45,7 @@ do_compile () {

do_install() {
set_arch
- oe_runmake headers_install_all INSTALL_HDR_PATH=${D}${exec_prefix} ARCH=$ARCH
+ oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix} ARCH=$ARCH
}

BBCLASSEXTEND = "nativesdk"
diff --git a/meta/recipes-kernel/linux/linux-tools.inc b/meta/recipes-kernel/linux/linux-tools.inc
new file mode 100644
index 0000000..714207f
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-tools.inc
@@ -0,0 +1,19 @@
+# included by kernel recipes if they want to build/provide
+# perf functionality from their tree.
+
+do_compile_perf() {
+ oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix}
+}
+
+do_install_perf() {
+ oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix} DESTDIR=${D} install
+}
+
+
+# perf tasks
+addtask compile_perf after do_compile before do_install
+addtask install_perf after do_install before do_package do_deploy
+
+do_compile_perf[depends] = "virtual/libc:do_populate_sysroot"
+do_compile_perf[depends] =+ "elfutils:do_populate_sysroot"
+RDEPENDS_perf += "python perl elfutils"
diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
new file mode 100644
index 0000000..8ecd86f
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
@@ -0,0 +1,41 @@
+inherit kernel
+require linux-yocto.inc
+
+KMACHINE_qemux86 = "common_pc/base"
+KMACHINE_qemux86-64 = "common_pc_64"
+KMACHINE_qemuppc = "qemu_ppc32"
+KMACHINE_qemumips = "mti_malta32_be"
+KMACHINE_qemuarm = "arm_versatile_926ejs"
+KMACHINE_atom-pc = "atom-pc"
+KMACHINE_routerstationpro = "routerstationpro"
+KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
+KMACHINE_beagleboard = "beagleboard"
+
+LINUX_VERSION ?= "2.6.34"
+LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+PR = "r0"
+PV = "${LINUX_VERSION}+git${SRCPV}"
+SRCREV_FORMAT = "meta_machine"
+
+# this performs a fixup on the SRCREV for new/undefined BSPs
+python __anonymous () {
+ import bb, re
+
+ rev = bb.data.getVar("SRCREV_machine", d, 1)
+ if rev == "standard":
+ bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
+}
+
+SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
+ git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"
+
+
+# Functionality flags
+KERNEL_REVISION_CHECKING ?= "t"
+KERNEL_FEATURES=features/netfilter
+
+# extra tasks
+addtask kernel_link_vmlinux after do_compile before do_install
+addtask validate_branches before do_patch after do_kernel_checkout
+
+require linux-tools.inc
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
new file mode 100644
index 0000000..095b337
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -0,0 +1,23 @@
+DESCRIPTION = "Yocto Kernel"
+SECTION = "kernel"
+LICENSE = "GPL"
+
+# A KMACHINE is the mapping of a yocto $MACHINE to what is built
+# by the kernel. This is typically the branch that should be built,
+# and it can be specific to the machine or shared
+KMACHINE = "UNDEFINED"
+
+COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro)"
+
+# Set this to 'preempt_rt' in the local.conf if you want a real time kernel
+LINUX_KERNEL_TYPE ?= standard
+
+do_patch[depends] = "kern-tools-native:do_populate_sysroot"
+
+addtask kernel_configme before do_configure after do_patch
+addtask kernel_configcheck after do_configure before do_compile
+
+# Pick up shared functions
+inherit kernel-yocto
+
+B = "${WORKDIR}/linux-${KMACHINE}-${LINUX_KERNEL_TYPE}-build"
diff --git a/meta/recipes-kernel/linux/linux-yocto_git.bb b/meta/recipes-kernel/linux/linux-yocto_git.bb
index ef005ae..1e3df47 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -1,21 +1,7 @@
-DESCRIPTION = "Yocto Kernel"
-SECTION = "kernel"
-LICENSE = "GPL"
-
-# Set this to 'preempt_rt' in the local.conf if you want a real time kernel
-LINUX_KERNEL_TYPE ?= standard
-SRCREV_FORMAT = "meta_machine"
-PV = "2.6.34+git${SRCPV}"
-
-# To use a staged, on-disk bare clone of a Wind River Kernel, use a
-# variant of the below
-# SRC_URI = "git://///path/to/kernel/default_kernel.git;fullclone=1"
-SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
- git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"
+inherit kernel
+require linux-yocto.inc

-# map the poky machine to a 'kernel machine'
-KMACHINE = "UNDEFINED"
-KMACHINE_qemux86 = "common_pc"
+KMACHINE_qemux86 = "common_pc/base"
KMACHINE_qemux86-64 = "common_pc_64"
KMACHINE_qemuppc = "qemu_ppc32"
KMACHINE_qemumips = "mti_malta32_be"
@@ -25,199 +11,22 @@ KMACHINE_routerstationpro = "routerstationpro"
KMACHINE_mpc8315e-rdb = "fsl-mpc8315e-rdb"
KMACHINE_beagleboard = "beagleboard"

-# Determine which branch to fetch and build. Not all branches are in the
-# upstream repo (but will be locally created after the fetchers run) so
-# a fallback branch needs to be chosen.
-#
-# The default machine 'UNDEFINED'. If the machine is not set to a specific
-# branch in this recipe or in a recipe extension, then we fallback to a
-# branch that is always present 'standard'. This sets the KBRANCH variable
-# and is used in the SRC_URI. The machine is then set back to ${MACHINE},
-# since futher processing will use that to create local branches
-python __anonymous () {
- import bb, re
-
- bb.data.setVar("KBRANCH", "${KMACHINE}-${LINUX_KERNEL_TYPE}", d)
- mach = bb.data.getVar("KMACHINE", d, 1)
- if mach == "UNDEFINED":
- bb.data.setVar("KBRANCH", "standard", d)
- bb.data.setVar("KMACHINE", "${MACHINE}", d)
- # track the global configuration on a bootstrapped BSP
- bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
- bb.data.setVar("BOOTSTRAP", "t", d)
-}
-
-COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64|atom-pc|routerstationpro|mpc8315e-rdb|beagleboard)"
+LINUX_VERSION ?= "2.6.37"
+LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+PR = "r14"
+PV = "${LINUX_VERSION}+git${SRCPV}"
+SRCREV_FORMAT = "meta_machine"

-LINUX_VERSION = "v2.6.34"
-LINUX_VERSION_EXTENSION = "-wr-${LINUX_KERNEL_TYPE}"
-PR = "r13"
+SRC_URI = "git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
+ git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;noclone=1;branch=meta;name=meta"

-S = "${WORKDIR}/linux"
-B = "${WORKDIR}/linux-${KMACHINE}-${LINUX_KERNEL_TYPE}-build"

-# functionality flags
+# Functionality flags
KERNEL_REVISION_CHECKING ?= "t"
KERNEL_FEATURES=features/netfilter

-do_patch() {
- cd ${S}
- if [ -f ${WORKDIR}/defconfig ]; then
- defconfig=${WORKDIR}/defconfig
- fi
-
- # simply ensures that a branch of the right name has been created
- createme ${ARCH} ${KMACHINE}-${LINUX_KERNEL_TYPE} ${defconfig}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not create ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- # updates or generates the target description
- if [ -n "${KERNEL_FEATURES}" ]; then
- addon_features="--features ${KERNEL_FEATURES}"
- fi
- updateme ${addon_features} ${ARCH} ${WORKDIR}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not update ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- # executes and modifies the source tree as required
- patchme ${KMACHINE}-${LINUX_KERNEL_TYPE}
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not modify ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-}
-
-validate_branches() {
- branch_head=`git show-ref -s --heads ${KBRANCH}`
- meta_head=`git show-ref -s --heads wrs_meta`
- target_branch_head="${SRCREV_machine}"
- target_meta_head="${SRCREV_meta}"
-
- if [ -n "$target_branch_head" ] && [ "$branch_head" != "$target_branch_head" ]; then
- if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
- git show ${target_branch_head} > /dev/null 2>&1
- if [ $? -eq 0 ]; then
- echo "Forcing branch ${KMACHINE}-${LINUX_KERNEL_TYPE} to ${target_branch_head}"
- git branch -m ${KMACHINE}-${LINUX_KERNEL_TYPE} ${KMACHINE}-${LINUX_KERNEL_TYPE}-orig
- git checkout -b ${KMACHINE}-${LINUX_KERNEL_TYPE} ${target_branch_head}
- else
- echo "ERROR ${target_branch_head} is not a valid commit ID."
- echo "The kernel source tree may be out of sync"
- exit 1
- fi
- fi
- fi
-
- if [ "$meta_head" != "$target_meta_head" ]; then
- if [ -n "${KERNEL_REVISION_CHECKING}" ]; then
- git show ${target_meta_head} > /dev/null 2>&1
- if [ $? -eq 0 ]; then
- echo "Forcing branch wrs_meta to ${target_meta_head}"
- git branch -m wrs_meta wrs_meta-orig
- git checkout -b wrs_meta ${target_meta_head}
- else
- echo "ERROR ${target_meta_head} is not a valid commit ID"
- echo "The kernel source tree may be out of sync"
- exit 1
- fi
- fi
- fi
-}
-
-do_kernel_checkout() {
- if [ -d ${WORKDIR}/.git/refs/remotes/origin ]; then
- echo "Fixing up git directory for ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- rm -rf ${S}
- mkdir ${S}
- mv ${WORKDIR}/.git ${S}
-
- if [ -e ${S}/.git/packed-refs ]; then
- cd ${S}
- rm -f .git/refs/remotes/origin/HEAD
-IFS='
-';
-
- for r in `git show-ref | grep remotes`; do
- ref=`echo $r | cut -d' ' -f1`;
- b=`echo $r | cut -d'/' -f4`;
- echo $ref > .git/refs/heads/$b
- done
- cd ..
- else
- mv ${S}/.git/refs/remotes/origin/* ${S}/.git/refs/heads
- rmdir ${S}/.git/refs/remotes/origin
- fi
- fi
- cd ${S}
-
- # checkout and clobber and unimportant files
- git checkout -f ${KBRANCH}
-
- if [ -z "${BOOTSTRAP}" ]; then
- validate_branches
- fi
-
- # this second checkout is intentional, we want to leave ourselves
- # on the branch to be built, but validate_branches could have changed
- # our initial checkout. So we do it a second time to be sure
- git checkout -f ${KBRANCH}
-}
-do_kernel_checkout[dirs] = "${S}"
-
-addtask kernel_checkout before do_patch after do_unpack
-
-do_kernel_configme() {
- echo "Doing kernel configme"
-
- cd ${S}
- configme --reconfig
- if [ $? -ne 0 ]; then
- echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
- exit 1
- fi
-
- echo "# CONFIG_WRNOTE is not set" >> ${B}/.config
- echo "# Global settings from linux recipe" >> ${B}/.config
- echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >> ${B}/.config
-}
-
-do_kernel_configcheck() {
- echo "[INFO] validating kernel configuration"
- cd ${B}/..
- kconf_check ${B}/.config ${B} ${S} ${B} ${LINUX_VERSION} ${KMACHINE}-${LINUX_KERNEL_TYPE}
-}
-
-do_kernel_link_vmlinux() {
- if [ ! -d "${B}/arch/${ARCH}/boot" ]; then
- mkdir ${B}/arch/${ARCH}/boot
- fi
- cd ${B}/arch/${ARCH}/boot
- ln -sf ../../../vmlinux
-}
-
-do_compile_perf() {
- oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix}
-}
-
-do_install_perf() {
- oe_runmake -C ${S}/tools/perf CC="${KERNEL_CC}" LD="${KERNEL_LD}" prefix=${prefix} DESTDIR=${D} install
-}
-
-do_patch[depends] = "kern-tools-native:do_populate_sysroot"
-addtask kernel_configme before do_configure after do_patch
+# extra tasks
addtask kernel_link_vmlinux after do_compile before do_install
-addtask kernel_configcheck after do_configure before do_compile
-
-inherit kernel
-
-# perf tasks
-addtask compile_perf after do_compile before do_install
-addtask install_perf after do_install before do_package do_deploy
+addtask validate_branches before do_patch after do_kernel_checkout

-do_compile_perf[depends] = "virtual/libc:do_populate_sysroot"
-do_compile_perf[depends] =+ "elfutils:do_populate_sysroot"
-RDEPENDS_perf += "python perl elfutils"
+require linux-tools.inc
--
1.7.0.4


[PATCH 0/3] linux-yocto: refactor recipes and update the kernel

Bruce Ashfield <bruce.ashfield@...>
 

Richard,

Consider these patches for merging. I've been building and working
with these for 2 weeks now, and while they may not be perfect, they
work and we need more eyes on 2.6.37.

What we get is the following:

- factoring of the code into some reusable routines in the form
of a linux-yocto bbclass. The -stable, -devel and libc headers
recipes are all using this common code

- A new branching scheme for the 2.6.37 kernel that generalizes
the branch names and shows their hierarchy. The tools that
process the kernel needed a lot of 'unlearning' about the
old structure (this took a lot of my time working on this).

If this needs to be tweaked more, we can do it later, since
the big changes are done and agreed on, and we can't delay
scaling this out to more boards much longer.

- A -stable recipe that continues to build the 2.6.34 kernel
and a move of the main recipe to track the development
2.6.37-rc5 tree. The qemu* targets have their defaults
changed to 2.6.37-rc, while the hardware targets remain
on 2.6.34 for a bit longer

** As discussed. The -stable naming of a recipe is
transitional and will eventually be removed and we'll
switch between kernels via a different mechanism

- perf is moved into a linux-tools.inc, we can add more to
this and re-use it more easily from here

- BSP boostrapping is streamlined (docs to follow).

Note: The temporary commenting of the preferred libc-headers provider
was intentional. There is something strange happening when
headers are generated for 2.6.34 that was breaking libc builds.
To avoid holding up this series, we'll go with the default
libc headers for a short while.

I've built and booted all the qemu* targets on 2.6.37
(minimal and sato), I've built most of the hardware
targets. I noticed some strangeness with the mouse on
ARM, and that will need to be looked at further. I've done
some audits on the kernel configuration in 2.6.37, and
while it looks sane, full BSP testing will tell us if
anything major changed (that I missed).

If there are better suggestions on how we can stage and
get mileage on this code, I'm all ears, but this is a kernel
uprev, so I expect some issues (there always is even though
I've done plenty of these). If we don't want anything
destabilizing in the tree, I'm fine with this and we just
need to come up with a plan.

What remains (I'm only one person!):

- BSP porting and full BSP testing
- Investigation into the libc-headers issue
- Continued cleanup
- Feature merging into 2.6.37 (lttng, yaffs, etc)

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield <bruce.ashfield@...>
---


Bruce Ashfield (3):
yocto-kernel: factor common routes, update to 2.6.37 and branch
renaming
linux-libc-headers-yocto: use common linux-yocto routines
qemu: update arm timer handling

meta-emenlow/conf/machine/emenlow.conf | 3 +-
meta/classes/kernel-yocto.bbclass | 202 ++++++++++++++++++
.../conf/distro/include/poky-default-revisions.inc | 36 +++-
meta/conf/machine/atom-pc.conf | 3 +-
meta/conf/machine/beagleboard.conf | 3 +-
meta/conf/machine/include/qemu.inc | 1 +
meta/conf/machine/mpc8315e-rdb.conf | 3 +-
meta/conf/machine/routerstationpro.conf | 3 +-
.../qemu-0.12.4/arm_timer-fix-oneshot-mode.patch | 32 +++
.../arm_timer-reload-timer-when-enabled.patch | 40 ++++
meta/recipes-devtools/qemu/qemu_0.12.4.bb | 4 +-
.../linux-libc-headers-yocto_git.bb | 25 +--
meta/recipes-kernel/linux/linux-tools.inc | 19 ++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
meta/recipes-kernel/linux/linux-yocto.inc | 23 ++
meta/recipes-kernel/linux/linux-yocto_git.bb | 219 ++------------------
16 files changed, 420 insertions(+), 237 deletions(-)
create mode 100644 meta/classes/kernel-yocto.bbclass
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
create mode 100644 meta/recipes-kernel/linux/linux-tools.inc
create mode 100644 meta/recipes-kernel/linux/linux-yocto-stable_git.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto.inc


Re: Add extra parameters for qemu script

Richard Purdie <rpurdie@...>
 

On Thu, 2010-12-09 at 12:44 -0800, Garman, Scott A wrote:
However, one thing I feel the need to run by Richard, as he expressed
some preferences with how the poky-qemu script would work with regard to
options.

Richard: Criping's patch would remove the standalone options we had to
the poky-qemu script (e.g, nographic, serial) and instead requires the
user to specify them in one command option which can take any qemu
command switch.

So for example:

poky-qemu qemux86 nographic

would become:

poky-qemu qemux86 "<-nographic>"

The benefit of this is that this allows the user to specify any qemu
option they wish. Previously they were limited by the options we allowed
them to specify (which were quite limited).

I tend to feel that this approach is more flexible, and scales better
than having to support each and every qemu option with our own script
syntax. Is this acceptable, or should we continue to support our own
custom options in addition to Criping's new approach?
My gut feeling is that having some simplified way to trigger possibly
complex option combinations is still desirable but adding a way to pass
additional custom commandline is equally good. This gives us the maximum
flexibility moving forwards but keeps the script easy to use?

Cheers,

Richard