|
Re: [poky] Milestone 2 Stabilization Branch Created (Resend)
Xu, Jiajun <jiajun.xu@...>
[Resend with correct mailing lists]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. ThanksBest 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 betterHi, Scottthan having to support each and every qemu option with our own scriptMy gut feeling is that having some simplified way to trigger possibly 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,
|
|
|
|
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 meThese 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,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 expressedMy 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
|
|
|
|
[patch] meta-environment
Lu, Lianhao <lianhao.lu@...>
Hi all,
The attached patch is to create environment file package used by the ADT installer during ADT installation. This patch should be applied upon my previous pull request of bug#528 fixing (see the following summary of the previous pull request): 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 Best Regards, -Lianhao Lu
|
|
|
|
Some simple tests about pseudo performance
Xu, Dongxiao <dongxiao.xu@...>
Hi,
I did some simple tests for pseudo performance. I wrote a simple program which is repeatedly calling fopen, fflush, and fclose, which should be sensitive to pseudo/fakeroot since they trap the system calls. I run the program on native, fakeroot, and pseudo. int main() { FILE *fp; int i; for (i = 0; i < 1000000; i++) { fp = fopen("/tmp/12321.txt", "w"); fflush(fp); fclose(fp); } return 0; } Test results are: Native: 2.729 secs Fakeroot: 2.752 secs Pseudo: 51.814 secs We saw pseudo cost about 20 times of seconds than native and fakeroot. I did a profile when the program is running. From the following table we saw that a lot of cycles are within sqlite3 operations... I am wondering whether this point can be optimized? For example, is it workable to cache those database operations in memory and finally flush it into disk when pseudo exits? It's just a first thought and any suggestion and comment is welcome. Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000 samples % image name app name symbol name 693127 58.2980 no-vmlinux no-vmlinux /no-vmlinux 211108 17.7560 libsqlite3.so.0.8.6 libsqlite3.so.0.8.6 /usr/lib/libsqlite3.so.0.8.6 112269 9.4428 libc-2.10.1.so libc-2.10.1.so /lib/tls/i686/cmov/libc-2.10.1.so 16792 1.4124 [vdso] (tgid:28674 range:0xfd0000-0xfd1000) a.out [vdso] (tgid:28674 range:0xfd0000-0xfd1000) 15256 1.2832 libpthread-2.10.1.so libpthread-2.10.1.so pthread_mutex_lock 13163 1.1071 libpthread-2.10.1.so libpthread-2.10.1.so __pthread_mutex_unlock_usercnt 7386 0.6212 libpseudo.so libpseudo.so pseudo_client_op 6753 0.5680 libpseudo.so libpseudo.so pseudo_debug_real 6680 0.5618 pseudo pseudo pseudo_server_start 6663 0.5604 [vdso] (tgid:28676 range:0x8d6000-0x8d7000) pseudo [vdso] (tgid:28676 range:0x8d6000-0x8d7000) 5049 0.4247 pseudo pseudo pseudo_op 4906 0.4126 [vdso] (tgid:28467 range:0xd32000-0xd33000) a.out [vdso] (tgid:28467 range:0xd32000-0xd33000) 4427 0.3723 [vdso] (tgid:28607 range:0x5c0000-0x5c1000) a.out [vdso] (tgid:28607 range:0x5c0000-0x5c1000) 4391 0.3693 [vdso] (tgid:29027 range:0x6d0000-0x6d1000) a.out [vdso] (tgid:29027 range:0x6d0000-0x6d1000) 4188 0.3522 [vdso] (tgid:29172 range:0x41a000-0x41b000) a.out [vdso] (tgid:29172 range:0x41a000-0x41b000) 3584 0.3014 [vdso] (tgid:2411 range:0x892000-0x893000) a.out [vdso] (tgid:2411 range:0x892000-0x893000) 2985 0.2511 pseudo pseudo pseudo_debug_real 2921 0.2457 postgres postgres /usr/lib/postgresql/8.3/bin/postgres 2905 0.2443 vim.basic vim.basic /usr/bin/vim.basic 2449 0.2060 bash bash /bin/bash 2439 0.2051 libpseudo.so libpseudo.so fopen 2163 0.1819 [vdso] (tgid:28609 range:0x3da000-0x3db000) pseudo [vdso] (tgid:28609 range:0x3da000-0x3db000) 2096 0.1763 [vdso] (tgid:29029 range:0xfef000-0xff0000) pseudo [vdso] (tgid:29029 range:0xfef000-0xff0000) 2086 0.1755 libpseudo.so libpseudo.so pseudo_append_element 1917 0.1612 [vdso] (tgid:28469 range:0xe72000-0xe73000) pseudo [vdso] (tgid:28469 range:0xe72000-0xe73000) 1835 0.1543 libpseudo.so libpseudo.so wrap_fopen 1833 0.1542 libpseudo.so libpseudo.so pseudo_msg_receive 1819 0.1530 libpseudo.so libpseudo.so __lxstat64 1762 0.1482 libpseudo.so libpseudo.so __i686.get_pc_thunk.bx Thanks, Dongxiao
|
|
|
|
Re: PULL] ADT installer script implementation, Liping Ke
Ke, Liping <liping.ke@...>
Hi, Richard & Jessica
toggle quoted messageShow quoted text
Actually I am not sure user requirement about the configuration input UI interactive interface One possible solution is 1) For those can't be changed by users (supported archs, supported os, it is defined by us), I prefer no UI interaction, and hard code in script 2) For those could be changed, but rarely (log file location, image downloading temporary folder, opkg configuration filename), I will still let it in the configuration file, If configuration file does not exist, I will give a default value. {Question here, do you need I prompt user each of those configurations, and in screen give another chance of changing instead of changing configuration file?) 3) For those need user input (mostly in yocto_installer.conf), if this file does not exist, directly prompt user errors and exit installation? Since without this file, we don't know user want to install what? So still the question, if already having configuration file, we still need user to input something in screen besides Y or N? Another question is that since we need to bitbake the installation tarball out. So we will fetch opkg source tarball by bitbake instead of providing a default one in the local folder. Is that right? Thanks & Regards, criping
I think it would make most sense for the user to be prompted for unset
|
|
|
|
Re: PULL] ADT installer script implementation, Liping Ke
Ke, Liping <liping.ke@...>
That definitely a bug regarding how to locate .config that we need toHi, Jessica For the configuration in .config file, I found it has problem too as a hidden file those days. It might be missed in some file ops. I was thinking whether I should remove this file and directly assign values in the common file (such as util script). Normally user will not change it. If he's capable enough, of course he can change the opkg file name as well as log file? As for the rootfs default downloading value, I will remove it to the Yocto_installer.conf Thanks & Regards, criping
|
|
|
|
Re: PULL] ADT installer script implementation, Liping Ke
Ke, Liping <liping.ke@...>
Oh, I am sorry that I should not send the [pull] request, instead I should send a review request.The first thing I read was in the patch was:Sorry for this obvious mistake. Need to do a better job before sending I meant to collect some review comments before finalize the code. This is for testing. So I did not remove this part. When going into tree, it will definitely be removed. I then decided to try it. That definitely a bug regarding how to locate .config that we need toYes, this is a problem. After source .config (default location), if we Failed to locate the file, I should prompt to exit instead of going forward. OK, I will give default values for all those variables. If user needs toNow, reading the script I suddenly realise the user doesn't getunset change it, he can use a config file to override it. Thanks for the suggestion. So in summary, I think the right pieces are there in terms ofLianhao has a testing opkg repo setup on his machine which mimic the Also I did not attach the opkg source tar ball, so the script can't be run actually. I plan to dynamically fetch opkg source file when using bitbake to generate adt-installer tarball. But for reviewing, next time, I will include the opkg source file tarball in the installer tarball. Thanks& Regards, criping toYes, and will attach the tar ball with in the next review request
|
|
|
|
Re: [PATCH 1/3] yocto-kernel: factor common routes, update to 2.6.37 and branch renaming
Bruce Ashfield <bruce.ashfield@...>
On 10-12-09 3:49 PM, Darren Hart wrote:
On 12/08/2010 06:35 AM, Bruce Ashfield wrote:FYI: I've solved this 'for real' now, and I've fixed the SRCREVIn order to extend and create more kernel recipes based on theNow that the git tree permissions for 2.6.37 are public (not sure how issue that I found at the end of my day. I wasn't thinking straight when I set this up, and I simply neglected to provide valid SRCREVs for the -stable variant of the kernel. That has allowed me to remove the SRCREVs from the specific recipes and centralize the support. The hack I sent earlier is no longer needed and everything now looks good. v2 of the series for merge will be out shortly. Bruce
|
|
|
|
Re: PULL] ADT installer script implementation, Liping Ke
Zhang, Jessica
Richard Purdie wrote:
Hi Liping, Jessica and team,http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=lke/adt_instal ler_initial&id=a06769b01d7b18894ad413daa8159f74c90f6c0f Really appreciated your time and feedbacks. Sorry for this obvious mistake. Need to do a better job before sending our a review request next time I then decided to try it.That definitely a bug regarding how to locate .config that we need to address. As to the different config files, the .config is on purpose non user editable that's why we set it as hidden file by default. And the yocto_installer.conf is the customizable config user should change and we have prompt for the user as regard to the configuration values to be used and where they're from along the installation process... Now, reading the script I suddenly realise the user doesn't getAgree and will make improvement on that.. So in summary, I think the right pieces are there in terms ofLianhao has a testing opkg repo setup on his machine which mimic the release package repo and we've been using it test things out toYes, and will attach the tar ball with in the next review request
|
|
|
|
Re: Add extra parameters for qemu script
Zhang, Jessica
Garman, Scott A wrote:
On 12/09/2010 12:44 AM, Ke, Liping wrote:Liping and I had the discussion regarding this before she went on taking theHi, ScottHi Criping, approach. Since we now provide this capability to allow user to provide their qemu params, then why we still in our qemu scripts isolate certain qemu params out, which may make things complicated unnecessarily and be more error prone...
|
|
|
|
Re: [PATCH 1/3] yocto-kernel: factor common routes, update to 2.6.37 and branch renaming
Bruce Ashfield <bruce.ashfield@...>
On 10-12-09 03:49 PM, Darren Hart wrote:
On 12/08/2010 06:35 AM, Bruce Ashfield wrote:Yep. This is what I found and fixed yesterday. I can'tIn order to extend and create more kernel recipes based on theNow that the git tree permissions for 2.6.37 are public (not sure how say that I completely understand my fix, but it is building all my trees here today, with all the right SRCREVs. I'm digging a bit more before sending updated patches. Bruce
|
|
|