The new license processing rules error if dtc-native itself
doesn't have license information. Previously only the .inc
files contained this information, so we make a copy and leave
the existing license info to be removed pending further review.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
meta/recipes-kernel/dtc/dtc-native_git.bb | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-kernel/dtc/dtc-native_git.bb b/meta/recipes-kernel/dtc/dtc-native_git.bb
index 2d6f092..fd5bde5 100644
--- a/meta/recipes-kernel/dtc/dtc-native_git.bb
+++ b/meta/recipes-kernel/dtc/dtc-native_git.bb
@@ -1,2 +1,5 @@
+LIC_FILES_CHKSUM = "file://GPL;md5=94d55d512a9ba36caa9b7df079bae19f \
+ file://libfdt/libfdt.h;beginline=3;endline=52;md5=fb360963151f8ec2d6c06b055bcbb68c"
+
require dtc-native.inc
require dtc_git.inc
--
1.7.0.4

Fixes [BUGID #610]

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.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
meta/recipes-kernel/linux/linux-dtb.inc | 27 +++++++++++++++++++++++++++
meta/recipes-kernel/linux/linux-yocto.inc | 1 +
meta/recipes-kernel/linux/linux.inc | 27 +--------------------------
3 files changed, 29 insertions(+), 26 deletions(-)
create mode 100644 meta/recipes-kernel/linux/linux-dtb.inc

diff --git a/meta/recipes-kernel/linux/linux-dtb.inc b/meta/recipes-kernel/linux/linux-dtb.inc
new file mode 100644
index 0000000..0b27d18
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -0,0 +1,27 @@
+# Support for device tree generation
+FILES_kernel_devicetree = "/boot/devicetree*"
+KERNEL_DEVICETREE_FLAGS = "-R 8 -p 0x3000"
+
+python __anonymous () {
+ import bb
+
+ devicetree = bb.data.getVar("KERNEL_DEVICETREE", d, 1) or ''
+ if devicetree:
+ depends = bb.data.getVar("DEPENDS", d, 1)
+ bb.data.setVar("DEPENDS", "%s dtc-native" % depends, d)
+ packages = bb.data.getVar("PACKAGES", d, 1)
+ bb.data.setVar("PACKAGES", "%s kernel-devicetree" % packages, d)
+}
+
+do_install_append() {
+ if test -n "${KERNEL_DEVICETREE}"; then
+ dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o devicetree ${KERNEL_DEVICETREE}
+ install -m 0644 devicetree ${D}/boot/devicetree-${KERNEL_VERSION}
+ install -d ${DEPLOY_DIR_IMAGE}
+ install -m 0644 devicetree ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}.dtb
+ cd ${DEPLOY_DIR_IMAGE}
+ rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
+ ln -sf ${KERNEL_IMAGE_BASE_NAME}.dtb ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
+ fi
+}
+
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
index 03935fa..0812144 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -18,5 +18,6 @@ addtask kernel_configme before do_configure after do_patch

# Pick up shared functions
inherit kernel-yocto
+require linux-dtb.inc

B = "${WORKDIR}/linux-${MACHINE}-${LINUX_KERNEL_TYPE}-build"
diff --git a/meta/recipes-kernel/linux/linux.inc b/meta/recipes-kernel/linux/linux.inc
index 93859bb..726d3d6 100644
--- a/meta/recipes-kernel/linux/linux.inc
+++ b/meta/recipes-kernel/linux/linux.inc
@@ -3,6 +3,7 @@ SECTION = "kernel"
LICENSE = "GPL"

inherit kernel
+require linux-dtb.inc

DEPENDS_append_em-x270 = " mtd-utils "

@@ -15,21 +16,6 @@ CMDLINE_at91sam9263ek = "mem=64M console=ttyS0,115200 root=/dev/mmcblk0p1 rootfs
#boot from nfs
#CMDLINE_at91sam9263ek = "mem=64M console=ttyS0,115200 root=301 root=/dev/nfs nfsroot=172.20.3.1:/data/at91 ip=172.20.0.5:::255.255.0.0"

-# Support for device tree generation
-FILES_kernel_devicetree = "/boot/devicetree*"
-KERNEL_DEVICETREE_FLAGS = "-R 8 -p 0x3000"
-
-python __anonymous () {
- import bb
-
- devicetree = bb.data.getVar("KERNEL_DEVICETREE", d, 1) or ''
- if devicetree:
- depends = bb.data.getVar("DEPENDS", d, 1)
- bb.data.setVar("DEPENDS", "%s dtc-native" % depends, d)
- packages = bb.data.getVar("PACKAGES", d, 1)
- bb.data.setVar("PACKAGES", "%s kernel-devicetree" % packages, d)
-}
-
do_configure_prepend() {
echo "" > ${S}/.config

@@ -105,14 +91,3 @@ do_install_prepend() {
fi
}

-do_install_append() {
- if test -n "${KERNEL_DEVICETREE}"; then
- dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o devicetree ${KERNEL_DEVICETREE}
- install -m 0644 devicetree ${D}/boot/devicetree-${KERNEL_VERSION}
- install -d ${DEPLOY_DIR_IMAGE}
- install -m 0644 devicetree ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}.dtb
- cd ${DEPLOY_DIR_IMAGE}
- rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
- ln -sf ${KERNEL_IMAGE_BASE_NAME}.dtb ${KERNEL_IMAGE_SYMLINK_NAME}.dtb
- fi
-}
--
1.7.0.4

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

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


Bruce Ashfield (3):
linux: factor dts/dtc/dtb handling into a specific include
dtc: add LIC_FILES_CHKSUM to dtc-native
mpc8315-rdb: add dtb generation configuration

meta/conf/machine/mpc8315e-rdb.conf | 1 +
meta/recipes-kernel/dtc/dtc-native_git.bb | 3 +++
meta/recipes-kernel/linux/linux-dtb.inc | 27 +++++++++++++++++++++++++++
meta/recipes-kernel/linux/linux-yocto.inc | 1 +
meta/recipes-kernel/linux/linux.inc | 27 +--------------------------
5 files changed, 33 insertions(+), 26 deletions(-)
create mode 100644 meta/recipes-kernel/linux/linux-dtb.inc

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.ashfield@...>

foo

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
meta/classes/kernel-yocto.bbclass | 71 +++-----------------
.../conf/distro/include/poky-default-revisions.inc | 3 +-
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 10 ++--
meta/recipes-kernel/linux/linux-yocto.inc | 4 +-
meta/recipes-kernel/linux/linux-yocto_git.bb | 4 +
5 files changed, 23 insertions(+), 69 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 4c52bca..15802fa 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -1,61 +1,5 @@
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
-
-SRCPV_prepend = "${@yoctokernel_variables_fixup(d)}"
-
-def yoctokernel_variables_fixup(d):
- if d.getVar("PVFIXUPDONE", False) is "done":
- return ""
-
- import bb, re, string
-
- 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", bb.data.expand("${MACHINE}",d) + "-standard", d)
- else:
- # The branch for a build is:
- # yocto/<kernel type>/${KMACHINE} or
- # yocto/<kernel type>/${KMACHINE}/base
- mach = bb.data.getVar("KMACHINE_" + bb.data.expand("${MACHINE}",d), d, 1)
- if mach == None:
- mach = bb.data.getVar("KMACHINE", d, 1)
-
- bb.data.setVar("KBRANCH", mach, d)
- bb.data.setVar("KMETA", "meta", d)
-
- # drop the "/base" if it was on the KMACHINE
- kmachine = mach.replace('/base','')
- # drop everything but the last segment
- kmachine = os.path.basename( kmachine )
- # and then write KMACHINE back
- bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d), kmachine, d)
-
- if mach == "UNDEFINED":
- bb.data.setVar('KMACHINE_' + bb.data.expand("${MACHINE}",d), bb.data.expand("${MACHINE}",d), d)
- bb.data.setVar("KBRANCH", "yocto/standard/base", d)
- bb.data.setVar("BOOTSTRAP", "yocto/standard/" + bb.data.expand("${MACHINE}",d), d)
- d.setVar("PVFIXUPDONE", "done")
- return ""
-
do_patch() {
cd ${S}
if [ -f ${WORKDIR}/defconfig ]; then
@@ -63,12 +7,11 @@ do_patch() {
fi

kbranch=${KBRANCH}
- if [ -n "${BOOTSTRAP}" ]; then
+ if [ -n "${YOCTO_KERNEL_EXTERNAL_BRANCH}" ]; then
# switch from a generic to a specific branch
- kbranch=${BOOTSTRAP}
+ kbranch=${YOCTO_KERNEL_EXTERNAL_BRANCH}
fi

-
# simply ensures that a branch of the right name has been created
createme ${ARCH} ${kbranch} ${defconfig}
if [ $? -ne 0 ]; then
@@ -131,8 +74,14 @@ addtask kernel_checkout before do_patch after do_unpack
do_kernel_configme() {
echo "[INFO] doing kernel configme"

+ kbranch=${KBRANCH}
+ if [ -n "${YOCTO_KERNEL_EXTERNAL_BRANCH}" ]; then
+ # switch from a generic to a specific branch
+ kbranch=${YOCTO_KERNEL_EXTERNAL_BRANCH}
+ fi
+
cd ${S}
- configme --reconfig --output ${B} ${KBRANCH} ${MACHINE}
+ configme --reconfig --output ${B} ${kbranch} ${MACHINE}
if [ $? -ne 0 ]; then
echo "ERROR. Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
exit 1
@@ -165,7 +114,7 @@ do_validate_branches() {
target_meta_head="${SRCREV_meta}"

# nothing to do if bootstrapping
- if [ -n "${BOOTSTRAP}" ]; then
+ if [ -n "${YOCTO_KERNEL_EXTERNAL_BRANCH}" ]; then
return
fi

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
@@ -1,6 +1,7 @@
inherit kernel
require linux-yocto.inc

+KMACHINE = "common_pc"
KMACHINE_qemux86 = "common_pc"
KMACHINE_qemux86-64 = "common_pc_64"
KMACHINE_qemuppc = "qemu_ppc32"
@@ -14,20 +15,19 @@ KMACHINE_beagleboard = "beagleboard"
LINUX_VERSION ?= "2.6.34"
LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE_EXTENSION}"

+KMETA = wrs_meta
+KBRANCH = ${KMACHINE}-${LINUX_KERNEL_TYPE_EXTENSION}
+
PR = "r1"
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
+# this performs a fixup on historical kernel types with embedded _'s
python __anonymous () {
import bb, re, string

- rev = bb.data.getVar("SRCREV_machine", d, 1)
- if rev == "standard":
- bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
-
kerntype = string.replace(bb.data.expand("${LINUX_KERNEL_TYPE}", d), "_", "-")
bb.data.setVar("LINUX_KERNEL_TYPE_EXTENSION", kerntype, d)
}
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
index 3ad849e..03935fa 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
# 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"
+# KMACHINE = "UNDEFINED"

# Set this to 'preempt_rt' in the local.conf if you want a real time kernel
LINUX_KERNEL_TYPE ?= standard
@@ -19,4 +19,4 @@ addtask kernel_configme before do_configure after do_patch
# Pick up shared functions
inherit kernel-yocto

-B = "${WORKDIR}/linux-${KMACHINE}-${LINUX_KERNEL_TYPE}-build"
+B = "${WORKDIR}/linux-${MACHINE}-${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 cc52397..75c6fb1 100644
--- a/meta/recipes-kernel/linux/linux-yocto_git.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_git.bb
@@ -1,6 +1,7 @@
inherit kernel
require linux-yocto.inc

+KMACHINE = "yocto/standard/base"
KMACHINE_qemux86 = "yocto/standard/common-pc/base"
KMACHINE_qemux86-64 = "yocto/standard/common-pc-64/base"
KMACHINE_qemuppc = "yocto/standard/qemu-ppc32"
@@ -11,6 +12,9 @@ KMACHINE_routerstationpro = "yocto/standard/routerstationpro"
KMACHINE_mpc8315e-rdb = "yocto/standard/fsl-mpc8315e-rdb"
KMACHINE_beagleboard = "yocto/standard/beagleboard"

+KBRANCH = ${KMACHINE}
+KMETA = meta
+
LINUX_VERSION ?= "2.6.37"
LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
PR = "r15"
--
1.7.0.4

Richard/Saul,

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.

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: streamline BSP bootstrapping

meta/classes/kernel-yocto.bbclass | 71 +++-----------------
.../conf/distro/include/poky-default-revisions.inc | 3 +-
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 10 ++--
meta/recipes-kernel/linux/linux-yocto.inc | 4 +-
meta/recipes-kernel/linux/linux-yocto_git.bb | 4 +
5 files changed, 23 insertions(+), 69 deletions(-)

Bruce,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/

On 11-02-08 12:31 PM, Diego Sueiro wrote:

Bruce,

I've updated my yocto tree but I'm still getting this error:

ERROR: Function 'do_kernel_checkout' failed (see
/home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330
for further information)
ERROR: Logfile of failure stored in:
/home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330
Log data follows:
| Fixing up git directory for standard/devkit8000
| error: pathspec 'devkit8000-standard' did not match any file(s) known
to git.
| ERROR: Function 'do_kernel_checkout' failed (see
/home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330
for further information)
NOTE: package
linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1:
task do_kernel_checkout: Failed
ERROR: Task 1
(/home/dev-2/yocto/poky/meta-boardware/recipes-kernel/linux/linux-yocto-stable_git.bb
<http://linux-yocto-stable_git.bb>, do_kernel_checkout) failed with exit
code '1'

This is the typical BSP bootstrap 'problem'. Hold on for
just a little while longer, with the new fetcher changes
in master, I'm updating the recipes (literally now) to
fix this and am testing the workflow for adding a new board
as part of these changes.

Cheers,

Bruce

I've tried this two options on
SRCREV_machine_pn-linux-yocto-stable_devkit8000:

"ef7f944e773950d4016b7643f9ecf052bbe250cd" = beagleboard-standard branch
"2b1caf6ed7b888c95a1909d343799672731651a5" = master branch
"72ca49ab08b8eb475cec82a10049503602325791" = standard branch


There isn't an specific devki8000 branch.

Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


On Tue, Feb 8, 2011 at 12:11 PM, Bruce Ashfield
<bruce.ashfield@... <mailto:bruce.ashfield@...>> wrote:

On 11-02-08 08:46 AM, Diego Sueiro wrote:

Folks,

I'm trying to get devkit8000 kernel compiled with
linux-yocto-stable recipe.
I've added devkit8000 on COMPATIBLE_MACHINE and on
KMACHINE_dekvkit800.

But I don't know what pokylinux branch to use to make the kernel
build
works.

I believe that I have to config these variables:

LINUX_KERNEL_TYPE


This one defaults to something sane, so you don't need
to set this line.


SRCREV_machine_pn-linux-yocto-stable_devkit8000


You would need to set this, to a SRCREV of the branch you'll
end up building.



Any suggestions?


Are you working out of an up to date master ? I've made some
changes recently that allow BSPs to bootstrap/reuse existing
branches. If you aren't on the latest master the procedure
is different.

Cheers,

Bruce


Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/



_______________________________________________
yocto mailing list
yocto@... <mailto:yocto@...>
https://lists.yoctoproject.org/listinfo/yocto

Bruce,

"ef7f944e773950d4016b7643f9ecf052bbe250cd" = beagleboard-standard branch

"2b1caf6ed7b888c95a1909d343799672731651a5" = master branch

"72ca49ab08b8eb475cec82a10049503602325791" = standard branch

On 11-02-08 08:46 AM, Diego Sueiro wrote:

Folks,

I'm trying to get devkit8000 kernel compiled with linux-yocto-stable recipe.
I've added devkit8000 on COMPATIBLE_MACHINE and on KMACHINE_dekvkit800.

But I don't know what pokylinux branch to use to make the kernel build
works.

I believe that I have to config these variables:

LINUX_KERNEL_TYPE

This one defaults to something sane, so you don't need
to set this line.

SRCREV_machine_pn-linux-yocto-stable_devkit8000

You would need to set this, to a SRCREV of the branch you'll
end up building.

Any suggestions?

Are you working out of an up to date master ? I've made some
changes recently that allow BSPs to bootstrap/reuse existing
branches. If you aren't on the latest master the procedure
is different.

Cheers,

Bruce

Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/



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

Folks,

LINUX_KERNEL_TYPE

SRCREV_machine_pn-linux-yocto-stable_devkit8000

Any suggestions?

Dear Elizabeth,

In message <4D503519.8010706@...> you wrote:

It is indeed 4.0.1, the commits for 7fa2b1c and d1fd60f were incorrect
(there was some confusion on my part as to the numbering scheme). These
issues were corrected @ 45526f5. Sorry for any confusion.

Understood - thanks!

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
Winners never talk about glorious victories. That's because they're
the ones who see what the battlefield looks like afterwards. It's
only the losers who have glorious victories.
- Terry Pratchett, _Small Gods_

Wolfgang,

It is indeed 4.0.1, the commits for 7fa2b1c and d1fd60f were incorrect
(there was some confusion on my part as to the numbering scheme). These
issues were corrected @ 45526f5. Sorry for any confusion.

Regards,

------------------
Elizabeth Flanagan
Yocto Project
Release Engineer

Dear Elizabeth Flanagan,

In message <4D4C9919.6060708@...> you wrote:

We are pleased to announce the first bug-fix release of Poky Laverne,
4.0.1. This release is available at:

http://mirrors.kernel.org/yocto/poky/poky-laverne-4.0.1.tar.bz2

Is this Laverne 4.0.1 or 4.1 ? The git tag is laverne-4.0.1, but the
7fa2b1c commit message says:

Laverne 4.1 release: NOTES and CHANGELOG

Name: Laverne
Version: 4.0.1
Built from Revision: fd7a07b3a2153826bedda2ef76b9a33ab2791680
Build Date: Jan 26 2011
Builder: autobuilder.pokylinux.org

Commit of final release notes and changelog for Laverne 4.1

And in d1fd60f I see this:

Setting Yocto rev number to 4.1: poky.conf
...
-DISTRO_NAME = "Yocto Linux (Built by Poky 4.0)"
+DISTRO_NAME = "Yocto Linux (Built by Poky 4.1)"


So I'm a bit confused?

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
Some people march to the beat of a different drummer. And some people
tango!

On 02/04/2011 04:54 PM, Darren Hart wrote:

On 02/04/2011 02:29 PM, Gary Thomas wrote:

On 02/04/2011 03:21 PM, Darren Hart wrote:

I picked up your do_src_move change as it resolves the issue - but I
can't say that I really understand the problem being solved - can you
elaborate on why you took this approach?
I'll credit you properly in the commit in the final set of branches.

I made this change because do_unpack_append() was being treated
as a Python function, so the syntax was wrong. By using that
function to run a shell function, the problem is solved. I patterned
this after similar functions, e.g. in the eglibc recipe. It took me
a while to find and understand this, but then it became obvious.

Ewww, that's pretty obfuscated. Did you determine why one function is treated as python and the other as bash?

No clue, I was just following precedent. Richard probably
knows the details.

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------

We are pleased to announce the first bug-fix release of Poky Laverne,
4.0.1. This release is available at:

http://mirrors.kernel.org/yocto/poky/poky-laverne-4.0.1.tar.bz2

This release fixes issues with Poky Laverne on systems running
Fedora 14 and Opensuse 11.3, fixes issues with the poky-qemu script, and
fixes several other bugs. For a full list of bug fixes and known issues,
please see the Laverne 4.0.1 Errata at the bottom of this email.

Thanks to everyone who helped with reporting and fixing bugs!

------------------
Elizabeth Flanagan
Yocto Project
Release Engineer


--------------------
Laverne 4.0.1 Errata
--------------------
Name: Laverne
Version: 4.0.1
MD5 Sum: 0564df3a756c7ccdf2b34e980e6f56d8
Tagged Rev: 45526f5ecfd7fec22ce8022b46c311e77ee0fa9f
Build Rev: fd7a07b3a2153826bedda2ef76b9a33ab2791680
Build Date: Jan 26 2011
Builder: autobuilder.pokylinux.org

Fixes
------------------------

* Make 3.82, as shipped with Fedora 14, included parser bug fixes
that resulted in a much stricter parser. As a result, the Makefiles
could not be parsed for many of the software versions shipped with
Laverne. The Makefiles in the following recipes were fixed:

o eglibc
o busybox
o procps
o linux-libc-headers
o gstreamer
o gst-plugins
o libowl-av
o owl-video-widget
o dates
o contacts
o web-webkit

* The ability to build openssl-native on a system that has SELINUX
enabled was restored. (We disabled the execstack flag at compile time.)

* A host-intrusion issue caused by a failure in QEMU to find zlib
headers during configure was fixed. The issue was causing qemu-native to
use the system zlib if it was present. If the system zlib was not
present the build would fail.

* Stability and usability enhancements, which included handling
relative filesystem paths, were made to poky-qemu scripts.

* The run-time remapping of package names when adding extra packages
to an image via the IMAGE_INSTALL mechanism were fixed.

* The configure test in quilt for GNU patch was fixed to that it
correctly detects the version.

Known Issues
------------------------

* The mpc3815e-rbd and routerstationpro machines were untested and
not a part of the official Laverne 4.0 release. These machines are still
unusable for this Laverne 4.0.1 release.
o mpx3815e-rdb will not boot due to a kernel/uboot issue Bug #685
o routerstation will not boot (by default) due to incorrect boot
parameters Bug #681
o routerstationpro debug messages related to the ethernet driver
print during boot Bug #679

* Shutdown/poweroff on qemuarm does not cleanly halt the virtual
machine. To workaround this issue use the reboot command. Using this
command avoids a "power-cycle" and instead cleanly shuts down the VM Bug
#684

* Two "Connection Manager" icons appear in the Sato UI. This
duplication has been fixed in master. Note that you can use either icon
to launch the connectivity UI. Bug #683

* The on-screen keyboard incorrectly launches in the qemumips
machine. This issue is due to a mis-configured formfactor file Bug #682

On 02/04/2011 02:29 PM, Gary Thomas wrote:

On 02/04/2011 03:21 PM, Darren Hart wrote:

I picked up your do_src_move change as it resolves the issue - but I
can't say that I really understand the problem being solved - can you
elaborate on why you took this approach?
I'll credit you properly in the commit in the final set of branches.

I made this change because do_unpack_append() was being treated
as a Python function, so the syntax was wrong. By using that
function to run a shell function, the problem is solved. I patterned
this after similar functions, e.g. in the eglibc recipe. It took me
a while to find and understand this, but then it became obvious.

Ewww, that's pretty obfuscated. Did you determine why one function is treated as python and the other as bash?

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

On 02/04/2011 03:21 PM, Darren Hart wrote:

On 02/03/2011 11:08 PM, Darren Hart wrote:

On 02/03/2011 03:19 PM, Gary Thomas wrote:

n.b. this is a continuation of "Kernel Panics on armv4t with gcc.4.5.1"
but the actual discussion has changed enough and there was too much
noise in the previous thread.

Hi Gary,

We're both pounding away on the meta-linaro layer at the same time
unfortunately. I've reorganized things a bit and cleaned up how the
layer is configured. I believe this layer ran into some trouble when gcc
and binutils changed, but also suffered from a bad BBFILES variable as
well (as you noted below). I'll push my changes to
poky-contrib/dvhart/meta-linaro just as soon as they build.

--
Darren

Trying to use the meta-linaro layer (to solve my problems
with GCC/4.5.1 on armv5te ), I was able to include and use
the layer with the attached changes. I added this layer
intact, moving meta-linaro into my poky tree at the same
level as meta, meta-extras, etc.

I also had to copy meta/recipes-devtools/gcc/gcc-4.5.1 into
meta-linaro/recipes-devtools/gcc (I didn't know how to expand
the FILESPATH variable to suck from the main meta tree)

The next problem is this:

| configure: WARNING: unrecognized options: --enable-languages,
--enable-threads, --enable-target-optspace, --enable-lto,
--enable-libssp, --disable-bootstrap, --disable-libgomp,
--disable-libmudflap, --with-float, --with-local-prefix, --with-sysroot,
--with-build-sysroot, --disable-libunwind-exceptions,
--enable-__cxa_atexit
| Checking autotools environment for common misconfiguration
| NOTE: Checking autotools environment for common misconfiguration
| This autoconf log indicates errors, it looked at host includes.
| Rerun configure task after fixing this. The path was
'/home/local/efacec_omap_linaro/tmp/work/armv5te-poky-linux-gnueabi/gcc-runtime-4.5.1.linaro-r0/gcc-4.5.1.linaro/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/libstdc++-v3'


| ERROR: This autoconf log indicates errors, it looked at host includes.
| Rerun configure task after fixing this. The path was
'/home/local/efacec_omap_linaro/tmp/work/armv5te-poky-linux-gnueabi/gcc-runtime-4.5.1.linaro-r0/gcc-4.5.1.linaro/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/libstdc++-v3'


| Function 'do_qa_configure' failed
| ERROR: Function 'do_qa_configure' failed
NOTE: package gcc-runtime-4.5.1.linaro-r0: task do_qa_configure: Failed

Ideas? I'm really anxious to see if this fixes my kernel problems.

I'm hitting something similar with libtool. I've pushed my dev branch out so you can see how things have changed. I've also asked Nitin to take a look at the libtool issues (and if
they are related to the linaro gcc).

My branch is available here:

poky-extras/dvhart/meta-linaro-dev

I picked up your do_src_move change as it resolves the issue - but I can't say that I really understand the problem being solved - can you elaborate on why you took this approach?
I'll credit you properly in the commit in the final set of branches.

I made this change because do_unpack_append() was being treated
as a Python function, so the syntax was wrong. By using that
function to run a shell function, the problem is solved. I patterned
this after similar functions, e.g. in the eglibc recipe. It took me
a while to find and understand this, but then it became obvious.

Also note, this branch WILL be rebased and otherwise abused as I get it in shape for a pull request.

Thanks for your time

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------

On 02/03/2011 11:08 PM, Darren Hart wrote:

On 02/03/2011 03:19 PM, Gary Thomas wrote:

n.b. this is a continuation of "Kernel Panics on armv4t with gcc.4.5.1"
but the actual discussion has changed enough and there was too much
noise in the previous thread.

Hi Gary,

We're both pounding away on the meta-linaro layer at the same time
unfortunately. I've reorganized things a bit and cleaned up how the
layer is configured. I believe this layer ran into some trouble when gcc
and binutils changed, but also suffered from a bad BBFILES variable as
well (as you noted below). I'll push my changes to
poky-contrib/dvhart/meta-linaro just as soon as they build.

--
Darren

Trying to use the meta-linaro layer (to solve my problems
with GCC/4.5.1 on armv5te ), I was able to include and use
the layer with the attached changes. I added this layer
intact, moving meta-linaro into my poky tree at the same
level as meta, meta-extras, etc.

I also had to copy meta/recipes-devtools/gcc/gcc-4.5.1 into
meta-linaro/recipes-devtools/gcc (I didn't know how to expand
the FILESPATH variable to suck from the main meta tree)

The next problem is this:

| configure: WARNING: unrecognized options: --enable-languages,
--enable-threads, --enable-target-optspace, --enable-lto,
--enable-libssp, --disable-bootstrap, --disable-libgomp,
--disable-libmudflap, --with-float, --with-local-prefix, --with-sysroot,
--with-build-sysroot, --disable-libunwind-exceptions,
--enable-__cxa_atexit
| Checking autotools environment for common misconfiguration
| NOTE: Checking autotools environment for common misconfiguration
| This autoconf log indicates errors, it looked at host includes.
| Rerun configure task after fixing this. The path was
'/home/local/efacec_omap_linaro/tmp/work/armv5te-poky-linux-gnueabi/gcc-runtime-4.5.1.linaro-r0/gcc-4.5.1.linaro/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/libstdc++-v3'


| ERROR: This autoconf log indicates errors, it looked at host includes.
| Rerun configure task after fixing this. The path was
'/home/local/efacec_omap_linaro/tmp/work/armv5te-poky-linux-gnueabi/gcc-runtime-4.5.1.linaro-r0/gcc-4.5.1.linaro/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/libstdc++-v3'


| Function 'do_qa_configure' failed
| ERROR: Function 'do_qa_configure' failed
NOTE: package gcc-runtime-4.5.1.linaro-r0: task do_qa_configure: Failed

Ideas? I'm really anxious to see if this fixes my kernel problems.

I'm hitting something similar with libtool. I've pushed my dev branch out so you can see how things have changed. I've also asked Nitin to take a look at the libtool issues (and if they are related to the linaro gcc).

My branch is available here:

poky-extras/dvhart/meta-linaro-dev

I picked up your do_src_move change as it resolves the issue - but I can't say that I really understand the problem being solved - can you elaborate on why you took this approach? I'll credit you properly in the commit in the final set of branches.

Also note, this branch WILL be rebased and otherwise abused as I get it in shape for a pull request.

Thanks,

Darren

Thanks



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

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

On 11-02-04 01:14 PM, Saul Wold wrote:

On 02/04/2011 08:43 AM, Zhang, Jessica wrote:

Wold, Saul wrote:

On 02/04/2011 06:16 AM, Bruce Ashfield wrote:

On 11-02-04 12:20 AM, Zhang, Jessica wrote:

Has anyone run into the following failure, this is for
meta-toolchain for x86_64:

This is lurking in various forms at the moment, the fetcher
updates + new branches and the mirrors with old copies (my
guess), is causing this undesirable behaviour.

Fetcher accessed the network with the command git fetch

git.pokylinux.org/linux-yocto-2.6.37

NOTE: Fetcher accessed the network with the command git fetch

git.pokylinux.org/linux-yocto-2.6.37

Fetching origin
error: unable to resolve reference

refs/remotes/origin/yocto/standard/common-pc-64/base: Not a
directory

From git://git.pokylinux.org/linux-yocto-2.6.37
! [new branch] yocto/standard/common-pc-64/base ->

origin/yocto/standard/common-pc-64/base (unable to update local ref)

error: unable to resolve reference

This is due to the way that git manages things on disk. In
this case, make sure to completely remove your old downloaded
copy of the repo and re-fetch.

Yes, I am working from clean downloads,

Saul, you're saying that you're testing the clean downloads or the fetch
failures you ran into was from a clean download?

Both, I am pretty much dead in the water right now, I can't build a
complete system at all.

I have removed git* from my downloads and started with a clean build
area. Git fetches are not working.

The problem here is that the mirrors are causing problems
now. I don't have (any) access to address this, but if
anyone is block on a local build, feel free to ping me
and I can show you what you can do to get your build
up and running.

I've sent Richard some information resulting from tests
I ran this morning, and that should fixup the fetching for
incremental builds. Purging the mirrors may be a different
question, since in my tests the fetches are returning remote
refs to branches that have been deleted a month ago.

Bruce

Sau!

I remembered hearing this

before I am going to test some of Richard's changes in a private
branch but right now, I am deal in the water getting more testing
done!

Sau!

I'm trying to find a way to have git properly deal with
this at the moment.

Cheers,

Bruce

refs/remotes/origin/yocto/standard/common-pc-64/sugarbay: Not a
directory

! [new branch] yocto/standard/common-pc-64/sugarbay ->

origin/yocto/standard/common-pc-64/sugarbay (unable to update local
ref)

error: some local refs could not be updated; try running
'git remote prune origin' to remove any old, conflicting branches
error: Could not fetch origin Function 'Fetch failed: Unable to
fetch URL

git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;fullclone=1;branch=y

octo/standard/base;name=machine

from any source.' failed

ERROR: Function 'Fetch failed: Unable to fetch URL

git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;fullclone=1;branch=y

octo/standard/base;name=machine

from any source.' failed
NOTE: package

linux-libc-headers-yocto-2.6.37+git-0+a9d833fda90e2f1257888a97e092135610b5f2

59_0+standard-r2:

task Fetch failed: Unable to fetch URL

git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;fullclone=1;branch=y

octo/standard/base;name=machine

from any source.: Failed
NOTE: package gcc-cross-4.5.1-r2: task do_unpack: Started
ERROR: Task 441

(/home/jzhang/poky-master/meta/recipes-kernel/linux-libc-headers/linux-libc-

headers-yocto_git.bb,

do_fetch) failed with exit code '1'
Thanks,
Jessica



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

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


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