[PATCH 0/7] Add basic fitImage support

[PATCH 0/7] Add basic fitImage support

[Marek Vasut]

This series cleans up the code in kernel.bbclass and
separates out the uImage generation. The last patch
in this series then adds support for generation of the
advanced successor of the uImage, the fitImage.

This series adds only very rudimentary support for
generation of fitImage. The advanced features might
be added in subsequent patches.

I would also like to thank Richard for explaining to
me how to properly do the implementation and I hope
this series is at least close to that.

Marek Vasut (7):
  kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE
  kernel: Rework do_uboot_mkimage
  kernel: Pull out the linux.bin generation
  kernel: Pull uImage generation into separate class
  kernel: Separate out uboot_prep_kimage
  kernel: Build DTBs early
  kernel: Add basic fitImage support

 meta/classes/kernel-fitimage.bbclass    | 250 ++++++++++++++++++++++++++++++++
 meta/classes/kernel-uboot.bbclass       |  25 ++++
 meta/classes/kernel-uimage.bbclass      |  20 +++
 meta/classes/kernel.bbclass             |  35 +----
 meta/recipes-kernel/linux/linux-dtb.inc |  14 +-
 5 files changed, 311 insertions(+), 33 deletions(-)
 create mode 100644 meta/classes/kernel-fitimage.bbclass
 create mode 100644 meta/classes/kernel-uboot.bbclass
 create mode 100644 meta/classes/kernel-uimage.bbclass

Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>

-- 
2.1.1

[PATCH 1/7] kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE

[Marek Vasut]

Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and instead
set it in the anonymous python function. This also allows us to handle
image types which are not supported directly by kernel, but require some
other kernel target to be built. This is the case for example with the
fitImage, which is the uImage successor.

There is no functional change.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/kernel.bbclass | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f300fa3..762d3df 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -12,12 +12,16 @@ INITRAMFS_TASK ?= ""
 INITRAMFS_IMAGE_BUNDLE ?= ""
 
 python __anonymous () {
+    import re
+
     kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
     if kerneltype == 'uImage':
         depends = d.getVar("DEPENDS", True)
         depends = "%s u-boot-mkimage-native" % depends
         d.setVar("DEPENDS", depends)
 
+    d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '', kerneltype))
+
     image = d.getVar('INITRAMFS_IMAGE', True)
     if image:
         d.appendVarFlag('do_bundle_initramfs', 'depends', ' ${INITRAMFS_IMAGE}:do_rootfs')
@@ -79,8 +83,6 @@ KERNEL_ALT_IMAGETYPE ??= ""
 # they are staged.
 KERNEL_SRC_PATH = "/usr/src/kernel"
 
-KERNEL_IMAGETYPE_FOR_MAKE = "${@(lambda s: s[:-3] if s[-3:] == ".gz" else s)(d.getVar('KERNEL_IMAGETYPE', True))}"
-
 copy_initramfs() {
 	echo "Copying initramfs into ./usr ..."
 	# In case the directory is not created yet from the first pass compile:
-- 
2.1.1

[PATCH 2/7] kernel: Rework do_uboot_mkimage

[Marek Vasut]

Rework the function so part it's internals can be re-used by fitImage
image type. The name of the temporary file , linux.bin , is recycled
a little more as it's now used for both the case where it is gzip
compressed and where it is not. This should be fine, since the file
is temporary and removed after the uImage was created anyway.

There is no functional change here.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/kernel.bbclass | 32 +++++++++++++++++++++-----------
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 762d3df..a216b5a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -451,22 +451,32 @@ MODULE_TARBALL_DEPLOY ?= "1"
 do_uboot_mkimage() {
 	if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then 
 		if test "x${KEEPUIMAGE}" != "xyes" ; then
+			if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+				vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
+				linux_suffix=""
+				linux_comp="none"
+			else
+				vmlinux_path="vmlinux"
+				linux_suffix=".gz"
+				linux_comp="gzip"
+			fi
+
+			${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
+
+			if [ "${linux_comp}" != "none" ] ; then
+				rm -f linux.bin
+				gzip -9 linux.bin
+				mv -f "linux.bin${linux_suffix}" linux.bin
+			fi
+
 			ENTRYPOINT=${UBOOT_ENTRYPOINT}
 			if test -n "${UBOOT_ENTRYSYMBOL}"; then
 				ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
 					awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
 			fi
-			if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
-				${OBJCOPY} -O binary -R .note -R .comment -S arch/${ARCH}/boot/compressed/vmlinux linux.bin
-				uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
-				rm -f linux.bin
-			else
-				${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
-				rm -f linux.bin.gz
-				gzip -9 linux.bin
-				uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C gzip -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz arch/${ARCH}/boot/uImage
-				rm -f linux.bin.gz
-			fi
+
+			uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
+			rm -f linux.bin
 		fi
 	fi
 }
-- 
2.1.1

[PATCH 3/7] kernel: Pull out the linux.bin generation

[Marek Vasut]

Pull the generation of linux.bin image, which is then packed into uImage,
into a separate function. No functional change.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/kernel.bbclass | 40 +++++++++++++++++++++++-----------------
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a216b5a..ec4d930 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -448,26 +448,32 @@ MODULE_TARBALL_BASE_NAME ?= "${MODULE_IMAGE_BASE_NAME}.tgz"
 MODULE_TARBALL_SYMLINK_NAME ?= "modules-${MACHINE}.tgz"
 MODULE_TARBALL_DEPLOY ?= "1"
 
+uboot_prep_kimage() {
+	if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+		vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
+		linux_suffix=""
+		linux_comp="none"
+	else
+		vmlinux_path="vmlinux"
+		linux_suffix=".gz"
+		linux_comp="gzip"
+	fi
+
+	${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
+
+	if [ "${linux_comp}" != "none" ] ; then
+		rm -f linux.bin
+		gzip -9 linux.bin
+		mv -f "linux.bin${linux_suffix}" linux.bin
+	fi
+
+	echo "${linux_comp}"
+}
+
 do_uboot_mkimage() {
 	if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then 
 		if test "x${KEEPUIMAGE}" != "xyes" ; then
-			if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
-				vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
-				linux_suffix=""
-				linux_comp="none"
-			else
-				vmlinux_path="vmlinux"
-				linux_suffix=".gz"
-				linux_comp="gzip"
-			fi
-
-			${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
-
-			if [ "${linux_comp}" != "none" ] ; then
-				rm -f linux.bin
-				gzip -9 linux.bin
-				mv -f "linux.bin${linux_suffix}" linux.bin
-			fi
+			uboot_prep_kimage
 
 			ENTRYPOINT=${UBOOT_ENTRYPOINT}
 			if test -n "${UBOOT_ENTRYSYMBOL}"; then
-- 
2.1.1

[PATCH 4/7] kernel: Pull uImage generation into separate class

[Marek Vasut]

Pull the uImage image format generation from kernel.bbclass into
a separate kernel-uimage.bbclass. The recipes which now need to
generate an uImage will have to inherit kernel-uimage instead of
kernel class.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/kernel-uimage.bbclass | 44 +++++++++++++++++++++++++++++++++++++
 meta/classes/kernel.bbclass        | 45 --------------------------------------
 2 files changed, 44 insertions(+), 45 deletions(-)
 create mode 100644 meta/classes/kernel-uimage.bbclass

diff --git a/meta/classes/kernel-uimage.bbclass b/meta/classes/kernel-uimage.bbclass
new file mode 100644
index 0000000..f51321b
--- /dev/null
+++ b/meta/classes/kernel-uimage.bbclass
@@ -0,0 +1,44 @@
+inherit kernel
+
+DEPENDS += " u-boot-mkimage-native "
+
+uboot_prep_kimage() {
+	if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+		vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
+		linux_suffix=""
+		linux_comp="none"
+	else
+		vmlinux_path="vmlinux"
+		linux_suffix=".gz"
+		linux_comp="gzip"
+	fi
+
+	${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
+
+	if [ "${linux_comp}" != "none" ] ; then
+		rm -f linux.bin
+		gzip -9 linux.bin
+		mv -f "linux.bin${linux_suffix}" linux.bin
+	fi
+
+	echo "${linux_comp}"
+}
+
+do_uboot_mkimage() {
+	if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
+		if test "x${KEEPUIMAGE}" != "xyes" ; then
+			uboot_prep_kimage
+
+			ENTRYPOINT=${UBOOT_ENTRYPOINT}
+			if test -n "${UBOOT_ENTRYSYMBOL}"; then
+				ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+					awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
+			fi
+
+			uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
+			rm -f linux.bin
+		fi
+	fi
+}
+
+addtask uboot_mkimage before do_install after do_compile
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index ec4d930..f3ba19c 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -15,10 +15,6 @@ python __anonymous () {
     import re
 
     kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
-    if kerneltype == 'uImage':
-        depends = d.getVar("DEPENDS", True)
-        depends = "%s u-boot-mkimage-native" % depends
-        d.setVar("DEPENDS", depends)
 
     d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '', kerneltype))
 
@@ -448,47 +444,6 @@ MODULE_TARBALL_BASE_NAME ?= "${MODULE_IMAGE_BASE_NAME}.tgz"
 MODULE_TARBALL_SYMLINK_NAME ?= "modules-${MACHINE}.tgz"
 MODULE_TARBALL_DEPLOY ?= "1"
 
-uboot_prep_kimage() {
-	if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
-		vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
-		linux_suffix=""
-		linux_comp="none"
-	else
-		vmlinux_path="vmlinux"
-		linux_suffix=".gz"
-		linux_comp="gzip"
-	fi
-
-	${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
-
-	if [ "${linux_comp}" != "none" ] ; then
-		rm -f linux.bin
-		gzip -9 linux.bin
-		mv -f "linux.bin${linux_suffix}" linux.bin
-	fi
-
-	echo "${linux_comp}"
-}
-
-do_uboot_mkimage() {
-	if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then 
-		if test "x${KEEPUIMAGE}" != "xyes" ; then
-			uboot_prep_kimage
-
-			ENTRYPOINT=${UBOOT_ENTRYPOINT}
-			if test -n "${UBOOT_ENTRYSYMBOL}"; then
-				ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
-					awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
-			fi
-
-			uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
-			rm -f linux.bin
-		fi
-	fi
-}
-
-addtask uboot_mkimage before do_install after do_compile
-
 kernel_do_deploy() {
 	install -m 0644 ${KERNEL_OUTPUT} ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
 	if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
-- 
2.1.1

[PATCH 5/7] kernel: Separate out uboot_prep_kimage

[Marek Vasut]

Separate the function which prepares the kernel for packing into
uImage into separate class, so this function can be reused by the
fitImage class.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/kernel-uboot.bbclass  | 25 +++++++++++++++++++++++++
 meta/classes/kernel-uimage.bbclass | 26 +-------------------------
 2 files changed, 26 insertions(+), 25 deletions(-)
 create mode 100644 meta/classes/kernel-uboot.bbclass

diff --git a/meta/classes/kernel-uboot.bbclass b/meta/classes/kernel-uboot.bbclass
new file mode 100644
index 0000000..57bb950
--- /dev/null
+++ b/meta/classes/kernel-uboot.bbclass
@@ -0,0 +1,25 @@
+inherit kernel
+
+DEPENDS += " u-boot-mkimage-native "
+
+uboot_prep_kimage() {
+	if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+		vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
+		linux_suffix=""
+		linux_comp="none"
+	else
+		vmlinux_path="vmlinux"
+		linux_suffix=".gz"
+		linux_comp="gzip"
+	fi
+
+	${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
+
+	if [ "${linux_comp}" != "none" ] ; then
+		rm -f linux.bin
+		gzip -9 linux.bin
+		mv -f "linux.bin${linux_suffix}" linux.bin
+	fi
+
+	echo "${linux_comp}"
+}
diff --git a/meta/classes/kernel-uimage.bbclass b/meta/classes/kernel-uimage.bbclass
index f51321b..1ea0400 100644
--- a/meta/classes/kernel-uimage.bbclass
+++ b/meta/classes/kernel-uimage.bbclass
@@ -1,28 +1,4 @@
-inherit kernel
-
-DEPENDS += " u-boot-mkimage-native "
-
-uboot_prep_kimage() {
-	if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
-		vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
-		linux_suffix=""
-		linux_comp="none"
-	else
-		vmlinux_path="vmlinux"
-		linux_suffix=".gz"
-		linux_comp="gzip"
-	fi
-
-	${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
-
-	if [ "${linux_comp}" != "none" ] ; then
-		rm -f linux.bin
-		gzip -9 linux.bin
-		mv -f "linux.bin${linux_suffix}" linux.bin
-	fi
-
-	echo "${linux_comp}"
-}
+inherit kernel-uboot
 
 do_uboot_mkimage() {
 	if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
-- 
2.1.1

[PATCH 6/7] kernel: Build DTBs early

[Marek Vasut]

Pull out the compilation of the DTB blobs right after the kernel's
own do_compile function finishes. This makes them available just in
time for the kernel image construction functions.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/recipes-kernel/linux/linux-dtb.inc | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-dtb.inc b/meta/recipes-kernel/linux/linux-dtb.inc
index 6b8f1a5..ee3a5e1 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -5,6 +5,18 @@ python __anonymous () {
     d.appendVar("PACKAGES", " kernel-devicetree")
 }
 
+do_compile_append() {
+	if test -n "${KERNEL_DEVICETREE}"; then
+		for DTB in ${KERNEL_DEVICETREE}; do
+			if echo ${DTB} | grep -q '/dts/'; then
+				bbwarn "${DTB} contains the full path to the the dts file, but only the dtb name should be used."
+				DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
+			fi
+			oe_runmake ${DTB}
+		done
+	fi
+}
+
 do_install_append() {
 	if test -n "${KERNEL_DEVICETREE}"; then
 		for DTB in ${KERNEL_DEVICETREE}; do
@@ -13,10 +25,8 @@ do_install_append() {
 				DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
 			fi
 			DTB_BASE_NAME=`basename ${DTB} .dtb`
-			DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"`
 			DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"`
 			DTB_PATH="${B}/arch/${ARCH}/boot/dts/${DTB}"
-			oe_runmake ${DTB}
 			if [ ! -e "${DTB_PATH}" ]; then
 				DTB_PATH="${B}/arch/${ARCH}/boot/${DTB}"
 			fi
-- 
2.1.1

[PATCH 7/7] kernel: Add basic fitImage support

[Marek Vasut]

This patch adds support for generating a kernel fitImage, which is
a a successor to the uImage format. Unlike uImage, which could only
contain the kernel image itself, the fitImage can contain all kinds
of artifacts, like the kernel image, device tree blobs, initramfs
images, binary firmwares etc. Furthermore, the fitImage supports
different kinds of checksums, not only CRC32 like the uImage did.
Last, but not least, fitImage supports signatures such that either
the whole image or it's parts can be signed and then in turn can
be verified by the bootloader.

So far we only add support for wrapping the kernel image and DTB
into the fitImage. The fitImage uses the sha1 checksum, which is
the default.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/kernel-fitimage.bbclass | 250 +++++++++++++++++++++++++++++++++++
 1 file changed, 250 insertions(+)
 create mode 100644 meta/classes/kernel-fitimage.bbclass

diff --git a/meta/classes/kernel-fitimage.bbclass b/meta/classes/kernel-fitimage.bbclass
new file mode 100644
index 0000000..54406bd
--- /dev/null
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -0,0 +1,250 @@
+# The fitImage explicitly packs zImage into it for now
+KERNEL_IMAGETYPE_FOR_MAKE = "zImage"
+
+inherit kernel-uboot
+
+DEPENDS += " dtc-native "
+
+python __anonymous () {
+    import re
+
+    # Only change the KERNEL_IMAGETYPE_FOR_MAKE if it is not already set.
+    # There are image formats (like uImage and fitImage), which need to
+    # build a different kernel image type than KERNEL_IMAGETYPE specifies.
+    kmaketype = d.getVar('KERNEL_IMAGETYPE_FOR_MAKE', True)
+    if not kmaketype:
+        kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
+        d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '', kerneltype))
+
+    image = d.getVar('INITRAMFS_IMAGE', True)
+    if image:
+        d.appendVarFlag('do_bundle_initramfs', 'depends', ' ${INITRAMFS_IMAGE}:do_rootfs')
+        d.appendVarFlag('do_assemble_fitimage', 'depends', ' ${INITRAMFS_IMAGE}:do_rootfs')
+
+    # NOTE: setting INITRAMFS_TASK is for backward compatibility
+    #       The preferred method is to set INITRAMFS_IMAGE, because
+    #       this INITRAMFS_TASK has circular dependency problems
+    #       if the initramfs requires kernel modules
+    image_task = d.getVar('INITRAMFS_TASK', True)
+    if image_task:
+        d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
+}
+
+#
+# Emit the fitImage ITS header
+#
+fitimage_emit_fit_header() {
+	cat << EOF >> fit-image.its
+/dts-v1/;
+
+/ {
+        description = "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}";
+        #address-cells = <1>;
+EOF
+}
+
+#
+# Emit the fitImage section bits
+#
+# $1 ... Section bit type: imagestart - image section start
+#                          confstart  - configuration section start
+#                          sectend    - section end
+#                          fitend     - fitimage end
+#
+fitimage_emit_section_maint() {
+	case $1 in
+	imagestart)
+		cat << EOF >> fit-image.its
+
+        images {
+EOF
+	;;
+	confstart)
+		cat << EOF >> fit-image.its
+
+        configurations {
+EOF
+	;;
+	sectend)
+		cat << EOF >> fit-image.its
+	};
+EOF
+	;;
+	fitend)
+		cat << EOF >> fit-image.its
+};
+EOF
+	;;
+	esac
+}
+
+#
+# Emit the fitImage ITS kernel section
+#
+# $1 ... Image counter
+# $2 ... Path to kernel image
+# $3 ... Compression type
+fitimage_emit_section_kernel() {
+
+	kernel_csum="sha1"
+
+	ENTRYPOINT=${UBOOT_ENTRYPOINT}
+	if test -n "${UBOOT_ENTRYSYMBOL}"; then
+		ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+			awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
+	fi
+
+	cat << EOF >> fit-image.its
+                kernel@${1} {
+                        description = "Linux kernel";
+                        data = /incbin/("${2}");
+                        type = "kernel";
+                        arch = "${UBOOT_ARCH}";
+                        os = "linux";
+                        compression = "${3}";
+                        load = <${UBOOT_LOADADDRESS}>;
+                        entry = <${ENTRYPOINT}>;
+                        hash@1 {
+                                algo = "${kernel_csum}";
+                        };
+                };
+EOF
+}
+
+#
+# Emit the fitImage ITS DTB section
+#
+# $1 ... Image counter
+# $2 ... Path to DTB image
+fitimage_emit_section_dtb() {
+
+	dtb_csum="sha1"
+
+	cat << EOF >> fit-image.its
+                fdt@${1} {
+                        description = "Flattened Device Tree blob";
+                        data = /incbin/("${2}");
+                        type = "flat_dt";
+                        arch = "${UBOOT_ARCH}";
+                        compression = "none";
+                        hash@1 {
+                                algo = "${dtb_csum}";
+                        };
+                };
+EOF
+}
+
+#
+# Emit the fitImage ITS configuration section
+#
+# $1 ... Linux kernel ID
+# $2 ... DTB image ID
+fitimage_emit_section_config() {
+
+	conf_csum="sha1"
+
+	# Test if we have any DTBs at all
+	if [ -z "${2}" ] ; then
+		conf_desc="Boot Linux kernel"
+		fdt_line=""
+	else
+		conf_desc="Boot Linux kernel with FDT blob"
+		fdt_line="fdt = \"fdt@${2}\";"
+	fi
+	kernel_line="kernel = \"kernel@${1}\";"
+
+	cat << EOF >> fit-image.its
+                default = "conf@1";
+                conf@1 {
+                        description = "${conf_desc}";
+			${kernel_line}
+			${fdt_line}
+                        hash@1 {
+                                algo = "${conf_csum}";
+                        };
+                };
+EOF
+}
+
+do_assemble_fitimage () {
+	if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+		kernelcount=1
+		dtbcount=""
+		rm -f fit-image.its
+
+		fitimage_emit_fit_header
+
+		#
+		# Step 1: Prepare a kernel image section.
+		#
+		fitimage_emit_section_maint imagestart
+
+		uboot_prep_kimage
+		fitimage_emit_section_kernel "${kernelcount}" linux.bin "${linux_comp}"
+
+		#
+		# Step 2: Prepare a DTB image section
+		#
+		if test -n "${KERNEL_DEVICETREE}"; then
+			dtbcount=1
+			for DTB in ${KERNEL_DEVICETREE}; do
+				if echo ${DTB} | grep -q '/dts/'; then
+					bbwarn "${DTB} contains the full path to the the dts file, but only the dtb name should be used."
+					DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
+				fi
+				DTB_PATH="arch/${ARCH}/boot/dts/${DTB}"
+				if [ ! -e "${DTB_PATH}" ]; then
+					DTB_PATH="arch/${ARCH}/boot/${DTB}"
+				fi
+
+				fitimage_emit_section_dtb ${dtbcount} ${DTB_PATH}
+				dtbcount=`expr ${dtbcount} + 1`
+			done
+		fi
+
+		fitimage_emit_section_maint sectend
+
+		# Force the first Kernel and DTB in the default config
+		kernelcount=1
+		dtbcount=1
+
+		#
+		# Step 3: Prepare a configurations section
+		#
+		fitimage_emit_section_maint confstart
+
+		fitimage_emit_section_config ${kernelcount} ${dtbcount}
+
+		fitimage_emit_section_maint sectend
+
+		fitimage_emit_section_maint fitend
+
+		#
+		# Step 4: Assemble the image
+		#
+		uboot-mkimage -f fit-image.its arch/${ARCH}/boot/fitImage
+	fi
+}
+
+addtask assemble_fitimage before do_install after do_compile
+
+kernel_do_deploy_append() {
+	cd ${B}
+
+	# Update deploy directory
+	if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+		echo "Copying fit-image.its source file..."
+		its_base_name="${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
+		its_symlink_name=${KERNEL_IMAGETYPE}-its-${MACHINE}
+		install -m 0644 fit-image.its ${DEPLOYDIR}/${its_base_name}.its
+		linux_bin_base_name="${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
+		linux_bin_symlink_name=${KERNEL_IMAGETYPE}-linux.bin-${MACHINE}
+		install -m 0644 linux.bin ${DEPLOYDIR}/${linux_bin_base_name}.bin
+	fi
+
+	cd ${DEPLOYDIR}
+	if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+		ln -sf ${its_base_name}.its ${its_symlink_name}.its
+		ln -sf ${linux_bin_base_name}.bin ${linux_bin_symlink_name}.bin
+	fi
+}
-- 
2.1.1

Re: [PATCH 1/7] kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE

[Otavio Salvador]

On Sun, Oct 19, 2014 at 5:15 PM, Marek Vasut <marex@denx.de> wrote:
> Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and instead
> set it in the anonymous python function. This also allows us to handle
> image types which are not supported directly by kernel, but require some
> other kernel target to be built. This is the case for example with the
> fitImage, which is the uImage successor.
>
> There is no functional change.

This is not really what the code shows; your regexp is more permissive
than the previous lambda.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 0/7] Add basic fitImage support

[Otavio Salvador]

On Sun, Oct 19, 2014 at 5:15 PM, Marek Vasut <marex@denx.de> wrote:
> This series cleans up the code in kernel.bbclass and
> separates out the uImage generation. The last patch
> in this series then adds support for generation of the
> advanced successor of the uImage, the fitImage.
>
> This series adds only very rudimentary support for
> generation of fitImage. The advanced features might
> be added in subsequent patches.
>
> I would also like to thank Richard for explaining to
> me how to properly do the implementation and I hope
> this series is at least close to that.

I really liked the series and I will start testing it; the only remark
I had is the first patch which says it has no functional change but
uses a more permissive regexp.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 1/7] kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE

[Marek Vasut]

On Sunday, October 19, 2014 at 09:25:36 PM, Otavio Salvador wrote:
> On Sun, Oct 19, 2014 at 5:15 PM, Marek Vasut <marex@denx.de> wrote:
> > Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and instead
> > set it in the anonymous python function. This also allows us to handle
> > image types which are not supported directly by kernel, but require some
> > other kernel target to be built. This is the case for example with the
> > fitImage, which is the uImage successor.
> > 
> > There is no functional change.
> 
> This is not really what the code shows; your regexp is more permissive
> than the previous lambda.

Do you happen to have a suggestion how to improve the patch please ? I'm
not really a python guru so any help is welcome ...

Best regards,
Marek Vasut

Re: [PATCH 1/7] kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE

[Otavio Salvador]

On Sun, Oct 19, 2014 at 7:13 PM, Marek Vasut <marex@denx.de> wrote:
> On Sunday, October 19, 2014 at 09:25:36 PM, Otavio Salvador wrote:
>> On Sun, Oct 19, 2014 at 5:15 PM, Marek Vasut <marex@denx.de> wrote:
>> > Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and instead
>> > set it in the anonymous python function. This also allows us to handle
>> > image types which are not supported directly by kernel, but require some
>> > other kernel target to be built. This is the case for example with the
>> > fitImage, which is the uImage successor.
>> >
>> > There is no functional change.
>>
>> This is not really what the code shows; your regexp is more permissive
>> than the previous lambda.
>
> Do you happen to have a suggestion how to improve the patch please ? I'm
> not really a python guru so any help is welcome ...

I like the code, just the commit log needs improvement as you did
change the functionality here.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 5664 bytes --]

On Sunday, October 19, 2014, Marek Vasut <marex@denx.de> wrote:

> Pull the uImage image format generation from kernel.bbclass into
> a separate kernel-uimage.bbclass. The recipes which now need to
> generate an uImage will have to inherit kernel-uimage instead of
> kernel class.
>
>
Does it trigger a doc change as well ?


> Signed-off-by: Marek Vasut <marex@denx.de <javascript:;>>
> Cc: Richard Purdie <richard.purdie@linuxfoundation.org <javascript:;>>
> Cc: Koen Kooi <koen@dominion.thruhere.net <javascript:;>>
> Cc: Paul Eggleton <paul.eggleton@linux.intel.com <javascript:;>>
> ---
>  meta/classes/kernel-uimage.bbclass | 44
> +++++++++++++++++++++++++++++++++++++
>  meta/classes/kernel.bbclass        | 45
> --------------------------------------
>  2 files changed, 44 insertions(+), 45 deletions(-)
>  create mode 100644 meta/classes/kernel-uimage.bbclass
>
> diff --git a/meta/classes/kernel-uimage.bbclass
> b/meta/classes/kernel-uimage.bbclass
> new file mode 100644
> index 0000000..f51321b
> --- /dev/null
> +++ b/meta/classes/kernel-uimage.bbclass
> @@ -0,0 +1,44 @@
> +inherit kernel
> +
> +DEPENDS += " u-boot-mkimage-native "
> +
> +uboot_prep_kimage() {
> +       if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
> +               vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
> +               linux_suffix=""
> +               linux_comp="none"
> +       else
> +               vmlinux_path="vmlinux"
> +               linux_suffix=".gz"
> +               linux_comp="gzip"
> +       fi
> +
> +       ${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}"
> linux.bin
> +
> +       if [ "${linux_comp}" != "none" ] ; then
> +               rm -f linux.bin
> +               gzip -9 linux.bin
> +               mv -f "linux.bin${linux_suffix}" linux.bin
> +       fi
> +
> +       echo "${linux_comp}"
> +}
> +
> +do_uboot_mkimage() {
> +       if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
> +               if test "x${KEEPUIMAGE}" != "xyes" ; then
> +                       uboot_prep_kimage
> +
> +                       ENTRYPOINT=${UBOOT_ENTRYPOINT}
> +                       if test -n "${UBOOT_ENTRYSYMBOL}"; then
> +                               ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux
> | \
> +                                       awk '$3=="${UBOOT_ENTRYSYMBOL}"
> {print $1}'`
> +                       fi
> +
> +                       uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel
> -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
> "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
> +                       rm -f linux.bin
> +               fi
> +       fi
> +}
> +
> +addtask uboot_mkimage before do_install after do_compile
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index ec4d930..f3ba19c 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -15,10 +15,6 @@ python __anonymous () {
>      import re
>
>      kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
> -    if kerneltype == 'uImage':
> -        depends = d.getVar("DEPENDS", True)
> -        depends = "%s u-boot-mkimage-native" % depends
> -        d.setVar("DEPENDS", depends)
>
>      d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '',
> kerneltype))
>
> @@ -448,47 +444,6 @@ MODULE_TARBALL_BASE_NAME ?=
> "${MODULE_IMAGE_BASE_NAME}.tgz"
>  MODULE_TARBALL_SYMLINK_NAME ?= "modules-${MACHINE}.tgz"
>  MODULE_TARBALL_DEPLOY ?= "1"
>
> -uboot_prep_kimage() {
> -       if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
> -               vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
> -               linux_suffix=""
> -               linux_comp="none"
> -       else
> -               vmlinux_path="vmlinux"
> -               linux_suffix=".gz"
> -               linux_comp="gzip"
> -       fi
> -
> -       ${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}"
> linux.bin
> -
> -       if [ "${linux_comp}" != "none" ] ; then
> -               rm -f linux.bin
> -               gzip -9 linux.bin
> -               mv -f "linux.bin${linux_suffix}" linux.bin
> -       fi
> -
> -       echo "${linux_comp}"
> -}
> -
> -do_uboot_mkimage() {
> -       if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
> -               if test "x${KEEPUIMAGE}" != "xyes" ; then
> -                       uboot_prep_kimage
> -
> -                       ENTRYPOINT=${UBOOT_ENTRYPOINT}
> -                       if test -n "${UBOOT_ENTRYSYMBOL}"; then
> -                               ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux
> | \
> -                                       awk '$3=="${UBOOT_ENTRYSYMBOL}"
> {print $1}'`
> -                       fi
> -
> -                       uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel
> -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
> "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
> -                       rm -f linux.bin
> -               fi
> -       fi
> -}
> -
> -addtask uboot_mkimage before do_install after do_compile
> -
>  kernel_do_deploy() {
>         install -m 0644 ${KERNEL_OUTPUT}
> ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
>         if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e
> '^CONFIG_MODULES=y$' .config); then
> --
> 2.1.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org <javascript:;>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 7801 bytes --]

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Bruce Ashfield]

On Sun, Oct 19, 2014 at 3:15 PM, Marek Vasut <marex@denx.de> wrote:
> Pull the uImage image format generation from kernel.bbclass into
> a separate kernel-uimage.bbclass. The recipes which now need to
> generate an uImage will have to inherit kernel-uimage instead of
> kernel class.

The commit log doesn't tell us why. What's the benefit or functionality we gain
via the change ?

Bruce

>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
> Cc: Koen Kooi <koen@dominion.thruhere.net>
> Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
>  meta/classes/kernel-uimage.bbclass | 44 +++++++++++++++++++++++++++++++++++++
>  meta/classes/kernel.bbclass        | 45 --------------------------------------
>  2 files changed, 44 insertions(+), 45 deletions(-)
>  create mode 100644 meta/classes/kernel-uimage.bbclass
>
> diff --git a/meta/classes/kernel-uimage.bbclass b/meta/classes/kernel-uimage.bbclass
> new file mode 100644
> index 0000000..f51321b
> --- /dev/null
> +++ b/meta/classes/kernel-uimage.bbclass
> @@ -0,0 +1,44 @@
> +inherit kernel
> +
> +DEPENDS += " u-boot-mkimage-native "
> +
> +uboot_prep_kimage() {
> +       if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
> +               vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
> +               linux_suffix=""
> +               linux_comp="none"
> +       else
> +               vmlinux_path="vmlinux"
> +               linux_suffix=".gz"
> +               linux_comp="gzip"
> +       fi
> +
> +       ${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
> +
> +       if [ "${linux_comp}" != "none" ] ; then
> +               rm -f linux.bin
> +               gzip -9 linux.bin
> +               mv -f "linux.bin${linux_suffix}" linux.bin
> +       fi
> +
> +       echo "${linux_comp}"
> +}
> +
> +do_uboot_mkimage() {
> +       if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
> +               if test "x${KEEPUIMAGE}" != "xyes" ; then
> +                       uboot_prep_kimage
> +
> +                       ENTRYPOINT=${UBOOT_ENTRYPOINT}
> +                       if test -n "${UBOOT_ENTRYSYMBOL}"; then
> +                               ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
> +                                       awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
> +                       fi
> +
> +                       uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
> +                       rm -f linux.bin
> +               fi
> +       fi
> +}
> +
> +addtask uboot_mkimage before do_install after do_compile
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index ec4d930..f3ba19c 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -15,10 +15,6 @@ python __anonymous () {
>      import re
>
>      kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
> -    if kerneltype == 'uImage':
> -        depends = d.getVar("DEPENDS", True)
> -        depends = "%s u-boot-mkimage-native" % depends
> -        d.setVar("DEPENDS", depends)
>
>      d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '', kerneltype))
>
> @@ -448,47 +444,6 @@ MODULE_TARBALL_BASE_NAME ?= "${MODULE_IMAGE_BASE_NAME}.tgz"
>  MODULE_TARBALL_SYMLINK_NAME ?= "modules-${MACHINE}.tgz"
>  MODULE_TARBALL_DEPLOY ?= "1"
>
> -uboot_prep_kimage() {
> -       if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
> -               vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
> -               linux_suffix=""
> -               linux_comp="none"
> -       else
> -               vmlinux_path="vmlinux"
> -               linux_suffix=".gz"
> -               linux_comp="gzip"
> -       fi
> -
> -       ${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
> -
> -       if [ "${linux_comp}" != "none" ] ; then
> -               rm -f linux.bin
> -               gzip -9 linux.bin
> -               mv -f "linux.bin${linux_suffix}" linux.bin
> -       fi
> -
> -       echo "${linux_comp}"
> -}
> -
> -do_uboot_mkimage() {
> -       if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
> -               if test "x${KEEPUIMAGE}" != "xyes" ; then
> -                       uboot_prep_kimage
> -
> -                       ENTRYPOINT=${UBOOT_ENTRYPOINT}
> -                       if test -n "${UBOOT_ENTRYSYMBOL}"; then
> -                               ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
> -                                       awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
> -                       fi
> -
> -                       uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
> -                       rm -f linux.bin
> -               fi
> -       fi
> -}
> -
> -addtask uboot_mkimage before do_install after do_compile
> -
>  kernel_do_deploy() {
>         install -m 0644 ${KERNEL_OUTPUT} ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
>         if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
> --
> 2.1.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Marek Vasut]

On Monday, October 20, 2014 at 12:08:57 AM, Bruce Ashfield wrote:
> On Sun, Oct 19, 2014 at 3:15 PM, Marek Vasut <marex@denx.de> wrote:
> > Pull the uImage image format generation from kernel.bbclass into
> > a separate kernel-uimage.bbclass. The recipes which now need to
> > generate an uImage will have to inherit kernel-uimage instead of
> > kernel class.
> 
> The commit log doesn't tell us why. What's the benefit or functionality we
> gain via the change ?

Ah right. I will be recycling some of those functions later on in the fitImage 
support. Also, it was suggested to me that there should be a separate class for
each image type -- that all the image types should not be in kernel.bbclass .

Does that make sense please?

Best regards,
Marek Vasut

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Marek Vasut]

On Sunday, October 19, 2014 at 11:29:15 PM, Khem Raj wrote:
> On Sunday, October 19, 2014, Marek Vasut <marex@denx.de> wrote:
> > Pull the uImage image format generation from kernel.bbclass into
> > a separate kernel-uimage.bbclass. The recipes which now need to
> > generate an uImage will have to inherit kernel-uimage instead of
> > kernel class.
> 
> Does it trigger a doc change as well ?

How can I tell please? Where exactly do I look please ? The 'kernel' keyword
is rather vague, so git grep spits a lot of results.

Best regards,
Marek Vasut

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Bruce Ashfield]

On Sun, Oct 19, 2014 at 6:29 PM, Marek Vasut <marex@denx.de> wrote:
> On Monday, October 20, 2014 at 12:08:57 AM, Bruce Ashfield wrote:
>> On Sun, Oct 19, 2014 at 3:15 PM, Marek Vasut <marex@denx.de> wrote:
>> > Pull the uImage image format generation from kernel.bbclass into
>> > a separate kernel-uimage.bbclass. The recipes which now need to
>> > generate an uImage will have to inherit kernel-uimage instead of
>> > kernel class.
>>
>> The commit log doesn't tell us why. What's the benefit or functionality we
>> gain via the change ?
>
> Ah right. I will be recycling some of those functions later on in the fitImage

Yep. And that's what is missing from the commit log. As a standalone commit,
the reader is left wondering why.

> support. Also, it was suggested to me that there should be a separate class for
> each image type -- that all the image types should not be in kernel.bbclass .

Factoring code and cleanups are great .. but sometimes it is just churn. I've
never had any problems with the image code being in a single class. So if
things are broken out, it would be nice to have a technical reason or
new feature
to go along with the changes.

Bruce

>
> Does that make sense please?
>
> Best regards,
> Marek Vasut



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

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Koen Kooi]

> Op 19 okt. 2014, om 21:15 heeft Marek Vasut <marex@denx.de> het volgende geschreven:
> 
> Pull the uImage image format generation from kernel.bbclass into
> a separate kernel-uimage.bbclass. The recipes which now need to
> generate an uImage will have to inherit kernel-uimage instead of
> kernel class.

To keep backward compatibility, could you rework this into something like:

kernel.bbclass:
	inherit kernel-${KERNEL_IMAGETYPE}

kernel-${KERNEL_IMAGETYPE}:
	inherit kernel-base
	imagetype stuff

kernel-base:
	old kernel.bbclass stuff

That would keep existing BSPs working *and* split out the image types.

regards,

Koen

> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
> Cc: Koen Kooi <koen@dominion.thruhere.net>
> Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
> meta/classes/kernel-uimage.bbclass | 44 +++++++++++++++++++++++++++++++++++++
> meta/classes/kernel.bbclass        | 45 --------------------------------------
> 2 files changed, 44 insertions(+), 45 deletions(-)
> create mode 100644 meta/classes/kernel-uimage.bbclass
> 
> diff --git a/meta/classes/kernel-uimage.bbclass b/meta/classes/kernel-uimage.bbclass
> new file mode 100644
> index 0000000..f51321b
> --- /dev/null
> +++ b/meta/classes/kernel-uimage.bbclass
> @@ -0,0 +1,44 @@
> +inherit kernel
> +
> +DEPENDS += " u-boot-mkimage-native "
> +
> +uboot_prep_kimage() {
> +	if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
> +		vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
> +		linux_suffix=""
> +		linux_comp="none"
> +	else
> +		vmlinux_path="vmlinux"
> +		linux_suffix=".gz"
> +		linux_comp="gzip"
> +	fi
> +
> +	${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
> +
> +	if [ "${linux_comp}" != "none" ] ; then
> +		rm -f linux.bin
> +		gzip -9 linux.bin
> +		mv -f "linux.bin${linux_suffix}" linux.bin
> +	fi
> +
> +	echo "${linux_comp}"
> +}
> +
> +do_uboot_mkimage() {
> +	if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
> +		if test "x${KEEPUIMAGE}" != "xyes" ; then
> +			uboot_prep_kimage
> +
> +			ENTRYPOINT=${UBOOT_ENTRYPOINT}
> +			if test -n "${UBOOT_ENTRYSYMBOL}"; then
> +				ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
> +					awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
> +			fi
> +
> +			uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
> +			rm -f linux.bin
> +		fi
> +	fi
> +}
> +
> +addtask uboot_mkimage before do_install after do_compile
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index ec4d930..f3ba19c 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -15,10 +15,6 @@ python __anonymous () {
>     import re
> 
>     kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
> -    if kerneltype == 'uImage':
> -        depends = d.getVar("DEPENDS", True)
> -        depends = "%s u-boot-mkimage-native" % depends
> -        d.setVar("DEPENDS", depends)
> 
>     d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '', kerneltype))
> 
> @@ -448,47 +444,6 @@ MODULE_TARBALL_BASE_NAME ?= "${MODULE_IMAGE_BASE_NAME}.tgz"
> MODULE_TARBALL_SYMLINK_NAME ?= "modules-${MACHINE}.tgz"
> MODULE_TARBALL_DEPLOY ?= "1"
> 
> -uboot_prep_kimage() {
> -	if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
> -		vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
> -		linux_suffix=""
> -		linux_comp="none"
> -	else
> -		vmlinux_path="vmlinux"
> -		linux_suffix=".gz"
> -		linux_comp="gzip"
> -	fi
> -
> -	${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
> -
> -	if [ "${linux_comp}" != "none" ] ; then
> -		rm -f linux.bin
> -		gzip -9 linux.bin
> -		mv -f "linux.bin${linux_suffix}" linux.bin
> -	fi
> -
> -	echo "${linux_comp}"
> -}
> -
> -do_uboot_mkimage() {
> -	if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then 
> -		if test "x${KEEPUIMAGE}" != "xyes" ; then
> -			uboot_prep_kimage
> -
> -			ENTRYPOINT=${UBOOT_ENTRYPOINT}
> -			if test -n "${UBOOT_ENTRYSYMBOL}"; then
> -				ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
> -					awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
> -			fi
> -
> -			uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C "${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
> -			rm -f linux.bin
> -		fi
> -	fi
> -}
> -
> -addtask uboot_mkimage before do_install after do_compile
> -
> kernel_do_deploy() {
> 	install -m 0644 ${KERNEL_OUTPUT} ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
> 	if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
> -- 
> 2.1.1
> 
> 

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Marek Vasut]

On Monday, October 20, 2014 at 12:26:04 PM, Koen Kooi wrote:
> > Op 19 okt. 2014, om 21:15 heeft Marek Vasut <marex@denx.de> het volgende
> > geschreven:
> > 
> > Pull the uImage image format generation from kernel.bbclass into
> > a separate kernel-uimage.bbclass. The recipes which now need to
> > generate an uImage will have to inherit kernel-uimage instead of
> > kernel class.
> 
> To keep backward compatibility, could you rework this into something like:
> 
> kernel.bbclass:
> 	inherit kernel-${KERNEL_IMAGETYPE}
> 
> kernel-${KERNEL_IMAGETYPE}:
> 	inherit kernel-base
> 	imagetype stuff
> 
> kernel-base:
> 	old kernel.bbclass stuff
> 
> That would keep existing BSPs working *and* split out the image types.

Yes, this makes sense. Are there any traps inside kernel.bbclass I should
be careful about? Like for example ${PN} or other possible variables which
are set based on the name of the file?

Thanks!

Best regards,
Marek Vasut

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Koen Kooi]

> Op 22 okt. 2014, om 01:28 heeft Marek Vasut <marex@denx.de> het volgende geschreven:
> 
> On Monday, October 20, 2014 at 12:26:04 PM, Koen Kooi wrote:
>>> Op 19 okt. 2014, om 21:15 heeft Marek Vasut <marex@denx.de> het volgende
>>> geschreven:
>>> 
>>> Pull the uImage image format generation from kernel.bbclass into
>>> a separate kernel-uimage.bbclass. The recipes which now need to
>>> generate an uImage will have to inherit kernel-uimage instead of
>>> kernel class.
>> 
>> To keep backward compatibility, could you rework this into something like:
>> 
>> kernel.bbclass:
>> 	inherit kernel-${KERNEL_IMAGETYPE}
>> 
>> kernel-${KERNEL_IMAGETYPE}:
>> 	inherit kernel-base
>> 	imagetype stuff
>> 
>> kernel-base:
>> 	old kernel.bbclass stuff
>> 
>> That would keep existing BSPs working *and* split out the image types.
> 
> Yes, this makes sense. Are there any traps inside kernel.bbclass I should
> be careful about? Like for example ${PN} or other possible variables which
> are set based on the name of the file?

You should be safe, PN is supposed to be completely ignored since the output packages will all be 'kernel-<foo>' instead of 'linux-myfirstbsp-<foo>'

regards,

Koen

Re: [PATCH 1/7] kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE

[Marek Vasut]

On Sunday, October 19, 2014 at 11:26:32 PM, Otavio Salvador wrote:
> On Sun, Oct 19, 2014 at 7:13 PM, Marek Vasut <marex@denx.de> wrote:
> > On Sunday, October 19, 2014 at 09:25:36 PM, Otavio Salvador wrote:
> >> On Sun, Oct 19, 2014 at 5:15 PM, Marek Vasut <marex@denx.de> wrote:
> >> > Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and
> >> > instead set it in the anonymous python function. This also allows us
> >> > to handle image types which are not supported directly by kernel, but
> >> > require some other kernel target to be built. This is the case for
> >> > example with the fitImage, which is the uImage successor.
> >> > 
> >> > There is no functional change.
> >> 
> >> This is not really what the code shows; your regexp is more permissive
> >> than the previous lambda.
> > 
> > Do you happen to have a suggestion how to improve the patch please ? I'm
> > not really a python guru so any help is welcome ...
> 
> I like the code, just the commit log needs improvement as you did
> change the functionality here.

So what do you suggest, just zap the following line from the commit message?
"
There is no functional change.
"

Best regards,
Marek Vasut

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Marek Vasut]

On Monday, October 20, 2014 at 12:26:04 PM, Koen Kooi wrote:
> > Op 19 okt. 2014, om 21:15 heeft Marek Vasut <marex@denx.de> het volgende
> > geschreven:
> > 
> > Pull the uImage image format generation from kernel.bbclass into
> > a separate kernel-uimage.bbclass. The recipes which now need to
> > generate an uImage will have to inherit kernel-uimage instead of
> > kernel class.
> 
> To keep backward compatibility, could you rework this into something like:
> 
> kernel.bbclass:
> 	inherit kernel-${KERNEL_IMAGETYPE}
> 
> kernel-${KERNEL_IMAGETYPE}:
> 	inherit kernel-base
> 	imagetype stuff
> 
> kernel-base:
> 	old kernel.bbclass stuff
> 
> That would keep existing BSPs working *and* split out the image types.

There are multiple KERNEL_IMAGETYPE options than just uImage, so I will change
the kernel.bbclass like so instead:

kernel.bbclass:
	inherit kernel-base
	inherit kernel-uimage

This will keep the BSPs working and then the new imagetypes (not fitImage,
since fitImage will inherit kernel-uimage) will do this:

kernel-${KERNEL_IMAGETYPE).bbclass:
	inherit kernel-base
	imagetype stuff

Does this make sense please ?

[...]

Best regards,
Marek Vasut

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Marek Vasut]

On Wednesday, October 22, 2014 at 10:42:09 AM, Koen Kooi wrote:
> > Op 22 okt. 2014, om 01:28 heeft Marek Vasut <marex@denx.de> het volgende
> > geschreven:
> > 
> > On Monday, October 20, 2014 at 12:26:04 PM, Koen Kooi wrote:
> >>> Op 19 okt. 2014, om 21:15 heeft Marek Vasut <marex@denx.de> het
> >>> volgende geschreven:
> >>> 
> >>> Pull the uImage image format generation from kernel.bbclass into
> >>> a separate kernel-uimage.bbclass. The recipes which now need to
> >>> generate an uImage will have to inherit kernel-uimage instead of
> >>> kernel class.
> >> 
> >> To keep backward compatibility, could you rework this into something
> >> like:
> >> 
> >> kernel.bbclass:
> >> 	inherit kernel-${KERNEL_IMAGETYPE}
> >> 
> >> kernel-${KERNEL_IMAGETYPE}:
> >> 	inherit kernel-base
> >> 	imagetype stuff
> >> 
> >> kernel-base:
> >> 	old kernel.bbclass stuff
> >> 
> >> That would keep existing BSPs working *and* split out the image types.
> > 
> > Yes, this makes sense. Are there any traps inside kernel.bbclass I should
> > be careful about? Like for example ${PN} or other possible variables
> > which are set based on the name of the file?
> 
> You should be safe, PN is supposed to be completely ignored since the
> output packages will all be 'kernel-<foo>' instead of
> 'linux-myfirstbsp-<foo>'

The kernel_do_configure() and do_configure stuff in kernel.bbclass now bit me.
I'm not even sure I can explain the problem well, so please bear with me.

The build system now cannot find do_configure() when building kernel recipe, 
since by moving kernel.bbclass contents into kernel-base.bbclass, the 
expectations of prefix of functions passed to 'addtask ... do_configure' and 
'EXPORT_FUNCTIONS ... do_configure' are no longer met. Before, the functions
in kernel.bbclass, namely kernel_do_configure() , kernel_do_compile() and 
kernel_do_install() had prefix matching the name of the bbclass (kernel_) and 
were used by the addtask...do_configure() and EXPORT_FUNCTIONS...do_configure() 
without the kernel_ prefix.

Now that I moved the contents of kernel.bbclass into kernel-base.bbclass, the 
name of the kernel_do_*() functions no longer matches the bbclass name and so
I presume the addtask... and EXPORT_FUNCTIONS... things are confused. 
Furthermore, I presume we want to keep the name of those kernel_do_*() functions
in case some recipes wanted to override those functions.

Do you happen to have any suggestion please ?

Best regards,
Marek Vasut

Re: [PATCH 0/7] Add basic fitImage support

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

On 19 October 2014 20:15, Marek Vasut <marex@denx.de> wrote:

> This series cleans up the code in kernel.bbclass and
> separates out the uImage generation. The last patch
> in this series then adds support for generation of the
> advanced successor of the uImage, the fitImage.
>
> This series adds only very rudimentary support for
> generation of fitImage. The advanced features might
> be added in subsequent patches.
>
> I would also like to thank Richard for explaining to
> me how to properly do the implementation and I hope
> this series is at least close to that.
>

For what it's worth I pulled these patches for initial testing and I got
build failures with the fsl-ppc kernel:

| "mkimage" command not found - U-Boot images will not be built
https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/builds/77/steps/BuildImages/logs/stdio

These patches were not the only ones pulled into that branch, but they're
the only relevant change that I can see.  It looks like a native dependency
disappeared somewhere, can you have a look at this?

Ross

[-- Attachment #2: Type: text/html, Size: 1850 bytes --]

Re: [PATCH 0/7] Add basic fitImage support

[Marek Vasut]

On Thursday, October 23, 2014 at 01:26:01 AM, Burton, Ross wrote:
> On 19 October 2014 20:15, Marek Vasut <marex@denx.de> wrote:
> > This series cleans up the code in kernel.bbclass and
> > separates out the uImage generation. The last patch
> > in this series then adds support for generation of the
> > advanced successor of the uImage, the fitImage.
> > 
> > This series adds only very rudimentary support for
> > generation of fitImage. The advanced features might
> > be added in subsequent patches.
> > 
> > I would also like to thank Richard for explaining to
> > me how to properly do the implementation and I hope
> > this series is at least close to that.
> 
> For what it's worth I pulled these patches for initial testing and I got
> 
> build failures with the fsl-ppc kernel:
> | "mkimage" command not found - U-Boot images will not be built
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/buil
> ds/77/steps/BuildImages/logs/stdio
> 
> These patches were not the only ones pulled into that branch, but they're
> the only relevant change that I can see.  It looks like a native dependency
> disappeared somewhere, can you have a look at this?

Yes, thank you for spotting this. I will keep this in mind when submitting V2.

I believe this is what Koen had in mind when he mentioned this patchset might 
break the BSPs. He even proposed a solution, but I need to dig in it a bit
more and properly understand and implement it.

Best regards,
Marek Vasut

Re: [PATCH 1/7] kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE

[Otavio Salvador]

On Wed, Oct 22, 2014 at 6:39 PM, Marek Vasut <marex@denx.de> wrote:
> On Sunday, October 19, 2014 at 11:26:32 PM, Otavio Salvador wrote:
>> On Sun, Oct 19, 2014 at 7:13 PM, Marek Vasut <marex@denx.de> wrote:
>> > On Sunday, October 19, 2014 at 09:25:36 PM, Otavio Salvador wrote:
>> >> On Sun, Oct 19, 2014 at 5:15 PM, Marek Vasut <marex@denx.de> wrote:
>> >> > Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and
>> >> > instead set it in the anonymous python function. This also allows us
>> >> > to handle image types which are not supported directly by kernel, but
>> >> > require some other kernel target to be built. This is the case for
>> >> > example with the fitImage, which is the uImage successor.
>> >> >
>> >> > There is no functional change.
>> >>
>> >> This is not really what the code shows; your regexp is more permissive
>> >> than the previous lambda.
>> >
>> > Do you happen to have a suggestion how to improve the patch please ? I'm
>> > not really a python guru so any help is welcome ...
>>
>> I like the code, just the commit log needs improvement as you did
>> change the functionality here.
>
> So what do you suggest, just zap the following line from the commit message?
> "
> There is no functional change.
> "

Works for me :)


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 1/7] kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE

[Marek Vasut]

On Thursday, October 23, 2014 at 02:32:55 AM, Otavio Salvador wrote:
[...]
> >> > Do you happen to have a suggestion how to improve the patch please ?
> >> > I'm not really a python guru so any help is welcome ...
> >> 
> >> I like the code, just the commit log needs improvement as you did
> >> change the functionality here.
> > 
> > So what do you suggest, just zap the following line from the commit
> > message? "
> > There is no functional change.
> > "
> 
> Works for me :)

OK, thanks

Best regards,
Marek Vasut

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Koen Kooi]

> Op 22 okt. 2014, om 23:45 heeft Marek Vasut <marex@denx.de> het volgende geschreven:
> 
> On Wednesday, October 22, 2014 at 10:42:09 AM, Koen Kooi wrote:
>>> Op 22 okt. 2014, om 01:28 heeft Marek Vasut <marex@denx.de> het volgende
>>> geschreven:
>>> 
>>> On Monday, October 20, 2014 at 12:26:04 PM, Koen Kooi wrote:
>>>>> Op 19 okt. 2014, om 21:15 heeft Marek Vasut <marex@denx.de> het
>>>>> volgende geschreven:
>>>>> 
>>>>> Pull the uImage image format generation from kernel.bbclass into
>>>>> a separate kernel-uimage.bbclass. The recipes which now need to
>>>>> generate an uImage will have to inherit kernel-uimage instead of
>>>>> kernel class.
>>>> 
>>>> To keep backward compatibility, could you rework this into something
>>>> like:
>>>> 
>>>> kernel.bbclass:
>>>> 	inherit kernel-${KERNEL_IMAGETYPE}
>>>> 
>>>> kernel-${KERNEL_IMAGETYPE}:
>>>> 	inherit kernel-base
>>>> 	imagetype stuff
>>>> 
>>>> kernel-base:
>>>> 	old kernel.bbclass stuff
>>>> 
>>>> That would keep existing BSPs working *and* split out the image types.
>>> 
>>> Yes, this makes sense. Are there any traps inside kernel.bbclass I should
>>> be careful about? Like for example ${PN} or other possible variables
>>> which are set based on the name of the file?
>> 
>> You should be safe, PN is supposed to be completely ignored since the
>> output packages will all be 'kernel-<foo>' instead of
>> 'linux-myfirstbsp-<foo>'
> 
> The kernel_do_configure() and do_configure stuff in kernel.bbclass now bit me.
> I'm not even sure I can explain the problem well, so please bear with me.
> 
> The build system now cannot find do_configure() when building kernel recipe, 
> since by moving kernel.bbclass contents into kernel-base.bbclass, the 
> expectations of prefix of functions passed to 'addtask ... do_configure' and 
> 'EXPORT_FUNCTIONS ... do_configure' are no longer met. Before, the functions
> in kernel.bbclass, namely kernel_do_configure() , kernel_do_compile() and 
> kernel_do_install() had prefix matching the name of the bbclass (kernel_) and 
> were used by the addtask...do_configure() and EXPORT_FUNCTIONS...do_configure() 
> without the kernel_ prefix.
> 
> Now that I moved the contents of kernel.bbclass into kernel-base.bbclass, the 
> name of the kernel_do_*() functions no longer matches the bbclass name and so
> I presume the addtask... and EXPORT_FUNCTIONS... things are confused. 
> Furthermore, I presume we want to keep the name of those kernel_do_*() functions
> in case some recipes wanted to override those functions.
> 
> Do you happen to have any suggestion please ?

Hmmm, it looks like there isn't a way to make this "just work" for 'old' BSPs :(

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Marek Vasut]

On Sunday, October 26, 2014 at 12:29:18 PM, Koen Kooi wrote:
[...]
> >>>> To keep backward compatibility, could you rework this into something
> >>>> like:
> >>>> 
> >>>> kernel.bbclass:
> >>>> 	inherit kernel-${KERNEL_IMAGETYPE}
> >>>> 
> >>>> kernel-${KERNEL_IMAGETYPE}:
> >>>> 	inherit kernel-base
> >>>> 	imagetype stuff
> >>>> 
> >>>> kernel-base:
> >>>> 	old kernel.bbclass stuff
> >>>> 
> >>>> That would keep existing BSPs working *and* split out the image types.
> >>> 
> >>> Yes, this makes sense. Are there any traps inside kernel.bbclass I
> >>> should be careful about? Like for example ${PN} or other possible
> >>> variables which are set based on the name of the file?
> >> 
> >> You should be safe, PN is supposed to be completely ignored since the
> >> output packages will all be 'kernel-<foo>' instead of
> >> 'linux-myfirstbsp-<foo>'
> > 
> > The kernel_do_configure() and do_configure stuff in kernel.bbclass now
> > bit me. I'm not even sure I can explain the problem well, so please bear
> > with me.
> > 
> > The build system now cannot find do_configure() when building kernel
> > recipe, since by moving kernel.bbclass contents into
> > kernel-base.bbclass, the expectations of prefix of functions passed to
> > 'addtask ... do_configure' and 'EXPORT_FUNCTIONS ... do_configure' are
> > no longer met. Before, the functions in kernel.bbclass, namely
> > kernel_do_configure() , kernel_do_compile() and kernel_do_install() had
> > prefix matching the name of the bbclass (kernel_) and were used by the
> > addtask...do_configure() and EXPORT_FUNCTIONS...do_configure() without
> > the kernel_ prefix.
> > 
> > Now that I moved the contents of kernel.bbclass into kernel-base.bbclass,
> > the name of the kernel_do_*() functions no longer matches the bbclass
> > name and so I presume the addtask... and EXPORT_FUNCTIONS... things are
> > confused. Furthermore, I presume we want to keep the name of those
> > kernel_do_*() functions in case some recipes wanted to override those
> > functions.
> > 
> > Do you happen to have any suggestion please ?
> 
> Hmmm, it looks like there isn't a way to make this "just work" for 'old'
> BSPs :(

So uh, what exactly would you propose then? Ask the BSPs to cater for the
change ? I don't quite like that option, since it's like breaking an API
(or similar interface, I'm not sure what the local equivalent of that would
be).

Thanks!

Best regards,
Marek Vasut

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Koen Kooi]

> Op 26 okt. 2014, om 23:52 heeft Marek Vasut <marex@denx.de> het volgende geschreven:
> 
> On Sunday, October 26, 2014 at 12:29:18 PM, Koen Kooi wrote:
> [...]
>>>>>> To keep backward compatibility, could you rework this into something
>>>>>> like:
>>>>>> 
>>>>>> kernel.bbclass:
>>>>>> 	inherit kernel-${KERNEL_IMAGETYPE}
>>>>>> 
>>>>>> kernel-${KERNEL_IMAGETYPE}:
>>>>>> 	inherit kernel-base
>>>>>> 	imagetype stuff
>>>>>> 
>>>>>> kernel-base:
>>>>>> 	old kernel.bbclass stuff
>>>>>> 
>>>>>> That would keep existing BSPs working *and* split out the image types.
>>>>> 
>>>>> Yes, this makes sense. Are there any traps inside kernel.bbclass I
>>>>> should be careful about? Like for example ${PN} or other possible
>>>>> variables which are set based on the name of the file?
>>>> 
>>>> You should be safe, PN is supposed to be completely ignored since the
>>>> output packages will all be 'kernel-<foo>' instead of
>>>> 'linux-myfirstbsp-<foo>'
>>> 
>>> The kernel_do_configure() and do_configure stuff in kernel.bbclass now
>>> bit me. I'm not even sure I can explain the problem well, so please bear
>>> with me.
>>> 
>>> The build system now cannot find do_configure() when building kernel
>>> recipe, since by moving kernel.bbclass contents into
>>> kernel-base.bbclass, the expectations of prefix of functions passed to
>>> 'addtask ... do_configure' and 'EXPORT_FUNCTIONS ... do_configure' are
>>> no longer met. Before, the functions in kernel.bbclass, namely
>>> kernel_do_configure() , kernel_do_compile() and kernel_do_install() had
>>> prefix matching the name of the bbclass (kernel_) and were used by the
>>> addtask...do_configure() and EXPORT_FUNCTIONS...do_configure() without
>>> the kernel_ prefix.
>>> 
>>> Now that I moved the contents of kernel.bbclass into kernel-base.bbclass,
>>> the name of the kernel_do_*() functions no longer matches the bbclass
>>> name and so I presume the addtask... and EXPORT_FUNCTIONS... things are
>>> confused. Furthermore, I presume we want to keep the name of those
>>> kernel_do_*() functions in case some recipes wanted to override those
>>> functions.
>>> 
>>> Do you happen to have any suggestion please ?
>> 
>> Hmmm, it looks like there isn't a way to make this "just work" for 'old'
>> BSPs :(
> 
> So uh, what exactly would you propose then? Ask the BSPs to cater for the
> change ? I don't quite like that option, since it's like breaking an API
> (or similar interface, I'm not sure what the local equivalent of that would
> be).

Personally, I'd try to keep the kernel_foo() methods the same since those are very popular, a lot of BSPs append the configure one. So maybe something like:

kernel.bbclass:
	do_configure
	do_install
	addtask
	etc
	inherit kernel-${KERNEL_IMAGETYPE.bbclass}

kernel-${KERNEL_IMAGETYPE.bbclass}
	do_install (overrides the one in kernel.bbclass)

Someone more familiar with bbclass method (re)naming and scoping should weigh in on the method override above, but I think it should work.

regards,

Koen
	

Re: [PATCH 0/7] Add basic fitImage support

[Marek Vasut]

On Thursday, October 23, 2014 at 01:26:01 AM, Burton, Ross wrote:
> On 19 October 2014 20:15, Marek Vasut <marex@denx.de> wrote:
> > This series cleans up the code in kernel.bbclass and
> > separates out the uImage generation. The last patch
> > in this series then adds support for generation of the
> > advanced successor of the uImage, the fitImage.
> > 
> > This series adds only very rudimentary support for
> > generation of fitImage. The advanced features might
> > be added in subsequent patches.
> > 
> > I would also like to thank Richard for explaining to
> > me how to properly do the implementation and I hope
> > this series is at least close to that.
> 
> For what it's worth I pulled these patches for initial testing and I got
> 
> build failures with the fsl-ppc kernel:
> | "mkimage" command not found - U-Boot images will not be built
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/buil
> ds/77/steps/BuildImages/logs/stdio
> 
> These patches were not the only ones pulled into that branch, but they're
> the only relevant change that I can see.  It looks like a native dependency
> disappeared somewhere, can you have a look at this?

Yikes, right. I found this and I'll repost the patches tomorrow. Sorry
this took so long.

Best regards,
Marek Vasut

Re: [PATCH 0/7] Add basic fitImage support

[Marek Vasut]

On Sunday, October 19, 2014 at 09:32:11 PM, Otavio Salvador wrote:
> On Sun, Oct 19, 2014 at 5:15 PM, Marek Vasut <marex@denx.de> wrote:
> > This series cleans up the code in kernel.bbclass and
> > separates out the uImage generation. The last patch
> > in this series then adds support for generation of the
> > advanced successor of the uImage, the fitImage.
> > 
> > This series adds only very rudimentary support for
> > generation of fitImage. The advanced features might
> > be added in subsequent patches.
> > 
> > I would also like to thank Richard for explaining to
> > me how to properly do the implementation and I hope
> > this series is at least close to that.
> 
> I really liked the series and I will start testing it; the only remark
> I had is the first patch which says it has no functional change but
> uses a more permissive regexp.

Fixed.

Best regards,
Marek Vasut

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Marek Vasut]

On Monday, October 27, 2014 at 07:59:42 AM, Koen Kooi wrote:

Hi!

sorry for the very late reply.

> > So uh, what exactly would you propose then? Ask the BSPs to cater for the
> > change ? I don't quite like that option, since it's like breaking an API
> > (or similar interface, I'm not sure what the local equivalent of that
> > would be).
> 
> Personally, I'd try to keep the kernel_foo() methods the same since those
> are very popular, a lot of BSPs append the configure one. So maybe
> something like:
> 
> kernel.bbclass:
> 	do_configure
> 	do_install
> 	addtask
> 	etc
> 	inherit kernel-${KERNEL_IMAGETYPE.bbclass}
> 
> kernel-${KERNEL_IMAGETYPE.bbclass}
> 	do_install (overrides the one in kernel.bbclass)
> 
> Someone more familiar with bbclass method (re)naming and scoping should
> weigh in on the method override above, but I think it should work.

I wonder, is it possible to inherit bbclass if it exists as a file and inherit
nothing otherwise ?

In case I do:
inherit kernel-${@d.getVar("KERNEL_IMAGETYPE", True).lower()}
I get a nasty spit from bitbake in case I'm building with zImage 
KERNEL_IMAGETYPE . The reason is obvious, the file kernel-zimage.bbclass
doesn't exist. So I wonder if there's some easy way to check if the class
actually exists.

Best regards,
Marek Vasut

Re: [PATCH 4/7] kernel: Pull uImage generation into separate class

[Paul Eggleton]

Hi Marek,

On Tuesday 28 April 2015 04:39:32 Marek Vasut wrote:
> On Monday, October 27, 2014 at 07:59:42 AM, Koen Kooi wrote:
> > > So uh, what exactly would you propose then? Ask the BSPs to cater for
> > > the
> > > change ? I don't quite like that option, since it's like breaking an API
> > > (or similar interface, I'm not sure what the local equivalent of that
> > > would be).
> > 
> > Personally, I'd try to keep the kernel_foo() methods the same since those
> > are very popular, a lot of BSPs append the configure one. So maybe
> > something like:
> > 
> > kernel.bbclass:
> > 	do_configure
> > 	do_install
> > 	addtask
> > 	etc
> > 	inherit kernel-${KERNEL_IMAGETYPE.bbclass}
> > 
> > kernel-${KERNEL_IMAGETYPE.bbclass}
> > 
> > 	do_install (overrides the one in kernel.bbclass)
> > 
> > Someone more familiar with bbclass method (re)naming and scoping should
> > weigh in on the method override above, but I think it should work.
> 
> I wonder, is it possible to inherit bbclass if it exists as a file and
> inherit nothing otherwise ?
> 
> In case I do:
> inherit kernel-${@d.getVar("KERNEL_IMAGETYPE", True).lower()}
> I get a nasty spit from bitbake in case I'm building with zImage
> KERNEL_IMAGETYPE . The reason is obvious, the file kernel-zimage.bbclass
> doesn't exist. So I wonder if there's some easy way to check if the class
> actually exists.

FYI, one way to handle this is to make the item being inherited an empty 
string if you don't want to inherit anything. You'd probably need to define a 
python function with def... and then call that from the inherit line.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre