Re: [yocto] [PATCH 0/1] linux-yocto/stable: streamline BSP processing
Hi Bruce, On Wed, 2011-02-09 at 01:22 -0500, Bruce Ashfield wrote: The subject is a bit deceiving, since the 'streamlining' that I've been working on for BSP / external board building for a while, actually solves a lot of the SRCREV/race conditions that we've been seeing. With the new fetcher and some factoring of the code, I've been able to delete 99% of the anonymous python and simply the processing for new BSPs. To create a BSP against the yocto kernels all one must do is put the variable YOCTO_KERNEL_EXTERNAL_BRANCH and indicate the branch name that should be used. The tools and processing does the rest. I built all existing boards, and bootstrapped a BSP against the stable and devel yocto kernels while testing this. Everything worked well. Darren: I haven't touched the preempt_rt recipes (yet), but we can streamline them as well. This is the first step in some other refactoring and cleanups for easier inclusion of the yocto kernel parts, but we'll let this soak first before stacking more changes on top. Looks good, nice to see this cleaning up, thanks! :) Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] linux-yocto: streamline BSP bootstrapping
On Wed, 2011-02-09 at 01:22 -0500, Bruce Ashfield wrote: In order to build BSPs that were not already integrated into the upstream linux yocto kernel AND keep the git fetcher happy, some fairly complex anonymous python sections were required. These sections cause problems with variable expansion and SRCREV processing. With the updated git fetcher code, we can streamline the BSP boostrapping process and drop 99% of the anonymous python code. This commit has the following changes to support BSP boot strapping and simplication for existing BSPs. - KMETA is set per-recipe rather than in python code - undefined machines are no longer used, but instead common branch names are set per-recipe - fallback machine SRCREVs are present in the default revisions file - A new variable YOCTO_KERNEL_EXTERNAL_BRANCH should be set in the local.conf for new BSPs instead of being programatically determined in the anonymous python. - No more explicity KMACHINE variable expansion and manipulation, since the tools and build phases no longer require it due to the per-recipe fallbacks. Integrated/merged BSPs are unaffected by the changes and have been regression tested. Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc index 9abc4a5..a04fa9e 100644 --- a/meta/conf/distro/include/poky-default-revisions.inc +++ b/meta/conf/distro/include/poky-default-revisions.inc @@ -59,7 +59,7 @@ SRCREV_pn-gypsy ??= 147 SRCREV_pn-inputproto ??= 7203036522ba9d4b224d282d6afc2d0b947711ee SRCREV_pn-inputproto-native ??= 7203036522ba9d4b224d282d6afc2d0b947711ee SRCREV_pn-inputproto-nativesdk ??= 7203036522ba9d4b224d282d6afc2d0b947711ee -SRCREV_pn-kern-tools-native ??= fde7ef8fa8043607752563b9b7908f487eb2f7dd +SRCREV_pn-kern-tools-native ??= 4f13a46499261ea181fdc13db5459067df08aca7 SRCREV_pn-libdrm ??= 3f3c5be6f908272199ccf53f108b1124bfe0a00e SRCREV_pn-libfakekey ??= e8c2e412ea4a417afc1f30e32cb7bdc508b1dccc SRCREV_pn-libgdbus ??= aeab6e3c0185b271ca343b439470491b99cc587f @@ -110,6 +110,7 @@ SRCREV_machine_pn-linux-yocto_mpc8315e-rdb ?= 68fb0b8d73bbb336ffa4a47bc70ec1eab SRCREV_machine_pn-linux-yocto_beagleboard ?= 343c06b25b221aa7f7019aee83b2d976041fddce SRCREV_machine_pn-linux-yocto ?= cb4faf3af527e25feee584f39c3956ca0c9448c8 SRCREV_meta_pn-linux-yocto ?= 5a32d7fe3b817868ebb697d2d883d743903685ae +SRCREV_machine_pn-linux-yocto ?= cb4faf3af527e25feee584f39c3956ca0c9448c8 SRCREV_pn-linux-libc-headers-yocto ??= 343c06b25b221aa7f7019aee83b2d976041fddce SRCREV_pn-matchbox-config-gtk ??= 3ed74dfb7c57be088a5ab36e446c0ccde9fa1028 SRCREV_pn-matchbox-desktop-sato ??= 76 diff --git a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb index d4bee77..3c1e669 100644 --- a/meta/recipes-kernel/linux/linux-yocto-stable_git.bb +++ b/meta/recipes-kernel/linux/linux-yocto-stable_git.bb I merged this with the exception of the second hunk above since it just adds a duplicate line. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/3] linux: factor dts/dtc/dtb handling into a specific include
On Wed, 2011-02-09 at 01:27 -0500, Bruce Ashfield wrote: Richard/Saul, This fixes BUGID 610, and kicks off a bit of cleaning with the various kernel include files. Patch 1/3 says it all: [ The powerpc linux-yocto kernels were not creating dtb images in the deploy directories. This was due to two problems: - the dtb generation rules were not being configured - the boards were not specifying a device tree in their config This change addresses the first point by factoring out the dtb generation routines into a new include that can be used by multiple recipes. ] With these changes I've built and generated a dtb for the mpc8315-rdb. Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: zedd/dtb Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/dtb Looks good, merged to master, thanks. Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Default list settings: avoid duplicate mail
I've noticed that p...@yoctoproject.org and yocto@yoctoproject.org both default to avoiding sending of duplicate mail. This is different to most other lists I subscribe to. By default it makes to me to allow users to perform their own filtering. Is there a reason we're disabling duplicates by default? It is a per-user setting, so I was able to enable duplicates for my account. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
