[PATCH v2 0/3] powerpc: Add support for FIT uImages

[PATCH v2 0/3] powerpc: Add support for FIT uImages

[Peter Tyser]

These patches add support for creating the "new" FIT uImage type
that U-Boot can use.  Additional info about FIT images can be
found in the doc/uImage.FIT/ directory of the U-Boot source.
Here's a link to a howto which gives an overview of the format:
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=doc/uImage.FIT/howto.txt;h=8065e9e1d8d4d65a9b5fe0fce08d3709183d0ee4;hb=HEAD

I've only added support for PowerPC, but the arm, avr32, blackfin,
and sh arches could use the same framework in theory.  The change
is especially useful on PowerPC since it creates 1 FIT uImage that
combines the functionality of an "old" uImage format, a device
tree blob, and possibly a ramdisk.

Changes since v1:
- Add 'dts-v1' header to scripts/mkits.sh output
- Don't strip leading 0x from dts addresses
- Default to using kernel dtc if the user doesn't have it in their path

Peter Tyser (3):
  powerpc: Use scripts/mkuboot.sh instead of 'mkimage'
  powerpc: Add support for creating FIT uImages
  powerpc: Add support for ram filesystems in FIT uImages

 arch/powerpc/Makefile        |    4 +-
 arch/powerpc/boot/.gitignore |    1 +
 arch/powerpc/boot/Makefile   |    8 ++-
 arch/powerpc/boot/wrapper    |   43 +++++++++++--
 scripts/mkits.sh             |  141 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 190 insertions(+), 7 deletions(-)
 create mode 100755 scripts/mkits.sh

[PATCH v2 1/3] powerpc: Use scripts/mkuboot.sh instead of 'mkimage'

[Peter Tyser]

mkuboot.sh provides a basic wrapper for the 'mkimage' utility.  Using
mkuboot.sh provides clearer error reporting and allows a toolchain to
use its own 'mkimage' executable specified by ${CROSS_COMPILE}mkimage.
Additionally, this brings PowerPC in line with other architectures
which already call mkimage via mkuboot.sh.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
---
 arch/powerpc/boot/wrapper |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 390512a..f4594ed 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -43,6 +43,9 @@ gzip=.gz
 # cross-compilation prefix
 CROSS=
 
+# mkimage wrapper script
+MKIMAGE=$srctree/scripts/mkuboot.sh
+
 # directory for object and other files used by this script
 object=arch/powerpc/boot
 objbin=$object
@@ -267,7 +270,7 @@ membase=`${CROSS}objdump -p "$kernel" | grep -m 1 LOAD | awk '{print $7}'`
 case "$platform" in
 uboot)
     rm -f "$ofile"
-    mkimage -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
+    ${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
 	$uboot_version -d "$vmz" "$ofile"
     if [ -z "$cacheit" ]; then
 	rm -f "$vmz"
@@ -327,7 +330,7 @@ coff)
     ;;
 cuboot*)
     gzip -f -9 "$ofile"
-    mkimage -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry" \
+    ${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry" \
             $uboot_version -d "$ofile".gz "$ofile"
     ;;
 treeboot*)
-- 
1.6.2.1

[PATCH v2 2/3] powerpc: Add support for creating FIT uImages

[Peter Tyser]

Recent U-Boot versions support booting a Flattened Image Tree (FIT)
image format.  The FIT uImage format uses a tree structure to describe a
kernel image as well as supporting device tree blobs, ramdisks, etc.
The 'mkimage' and 'dtc' utilities convert this tree description into a
binary blob that bootloaders such as U-Boot can execute.

This patch adds support for automatically creating a U-Boot FIT image
using the "make uImage.fit.<boardname>" command where <boardname> is
one of arch/powerpc/boot/dts/<boardname>.dts.  The resulting
arch/powerpc/boot/uImage.fit.<boardname> file will contain a kernel
image as well as a device tree blob.  U-Boot versions compiled with FIT
support can directly boot this image using the "bootm" command.

Additional information about the FIT format and its uses can be found in
doc/uImage.FIT/howto.txt of U-Boot's source tree.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
---
Changes since v1:
- Add 'dts-v1' header to scripts/mkits.sh output
- Don't strip leading 0x from dts addresses
- Default to using kernel dtc if the user doesn't have it in their path

 arch/powerpc/Makefile        |    4 +-
 arch/powerpc/boot/.gitignore |    1 +
 arch/powerpc/boot/Makefile   |    5 ++-
 arch/powerpc/boot/wrapper    |   20 +++++++-
 scripts/mkits.sh             |  111 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 138 insertions(+), 3 deletions(-)
 create mode 100755 scripts/mkits.sh

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 1a54a3b..459aed5 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -158,7 +158,8 @@ drivers-$(CONFIG_OPROFILE)	+= arch/powerpc/oprofile/
 # Default to zImage, override when needed
 all: zImage
 
-BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
+BOOT_TARGETS = zImage zImage.initrd uImage uImage.fit.% zImage% dtbImage% \
+	       treeImage.% cuImage.% simpleImage.%
 
 PHONY += $(BOOT_TARGETS)
 
@@ -185,6 +186,7 @@ define archhelp
   @echo '* zImage          - Build default images selected by kernel config'
   @echo '  zImage.*        - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
   @echo '  uImage          - U-Boot native image format'
+  @echo '  uImage.fit.<dt> - U-Boot Flattened Image Tree image format'
   @echo '  cuImage.<dt>    - Backwards compatible U-Boot image for older'
   @echo '                    versions which do not support device trees'
   @echo '  dtbImage.<dt>   - zImage with an embedded device tree blob'
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index 3d80c3e..a443f1c 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -19,6 +19,7 @@ kernel-vmlinux.strip.c
 kernel-vmlinux.strip.gz
 mktree
 uImage
+uImage.fit.*
 cuImage.*
 dtbImage.*
 treeImage.*
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index bb2465b..e56ec21 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -310,6 +310,9 @@ $(obj)/zImage.iseries: vmlinux
 $(obj)/uImage: vmlinux $(wrapperbits)
 	$(call if_changed,wrap,uboot)
 
+$(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
+	$(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
+
 $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
 	$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
 
@@ -349,7 +352,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
 
 # anything not in $(targets)
 clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
-	zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
+	uImage.* zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
 	zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
 	simpleImage.* otheros.bld *.dtb
 
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index f4594ed..1f35b66 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -46,6 +46,9 @@ CROSS=
 # mkimage wrapper script
 MKIMAGE=$srctree/scripts/mkuboot.sh
 
+# script to generate an .its file for uImage.fit.* images
+MKITS=$srctree/scripts/mkits.sh
+
 # directory for object and other files used by this script
 object=arch/powerpc/boot
 objbin=$object
@@ -157,7 +160,7 @@ coff)
     lds=$object/zImage.coff.lds
     link_address='0x500000'
     ;;
-miboot|uboot)
+miboot|uboot|uboot.fit)
     # miboot and U-boot want just the bare bits, not an ELF binary
     ext=bin
     objflags="-O binary"
@@ -277,6 +280,21 @@ uboot)
     fi
     exit 0
     ;;
+uboot.fit)
+    rm -f "$ofile"
+    ${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
+	-d "$srctree/$dtb" -k "$srctree/$vmz" -o "$object/uImage.its"
+
+    # mkimage calls dtc for FIT images so use kernel dtc if necessary
+    export PATH=$PATH:$srctree/scripts/dtc
+
+    ${MKIMAGE} -f "$object/uImage.its" "$ofile"
+    rm "$object/uImage.its"
+    if [ -z "$cacheit" ]; then
+	rm -f "$vmz"
+    fi
+    exit 0
+    ;;
 esac
 
 addsec() {
diff --git a/scripts/mkits.sh b/scripts/mkits.sh
new file mode 100755
index 0000000..fae43dd
--- /dev/null
+++ b/scripts/mkits.sh
@@ -0,0 +1,111 @@
+#!/bin/bash
+#
+# Licensed under the terms of the GNU GPL License version 2 or later.
+#
+# Author: Peter Tyser <ptyser@xes-inc.com>
+#
+# U-Boot firmware supports the booting of images in the Flattened Image
+# Tree (FIT) format.  The FIT format uses a device tree structure to
+# describe a kernel image, device tree blob, ramdisk, etc.  This script
+# creates an Image Tree Source (.its file) which can be passed to the
+# 'mkimage' utility to generate an Image Tree Blob (.itb file).  The .itb
+# file can then be booted by U-Boot (or other bootloaders which support
+# FIT images).  See doc/uImage.FIT/howto.txt in U-Boot source code for
+# additional information on FIT images.
+#
+
+usage() {
+	echo "Usage: `basename $0` -A arch -C comp -a addr -e entry" \
+		"-v version -k kernel [-d dtb] -o its_file"
+	echo -e "\t-A ==> set architecture to 'arch'"
+	echo -e "\t-C ==> set compression type 'comp'"
+	echo -e "\t-a ==> set load address to 'addr' (hex)"
+	echo -e "\t-e ==> set entry point to 'entry' (hex)"
+	echo -e "\t-v ==> set kernel version to 'version'"
+	echo -e "\t-k ==> include kernel image 'kernel'"
+	echo -e "\t-d ==> include Device Tree Blob 'dtb'"
+	echo -e "\t-o ==> create output file 'its_file'"
+	exit 1
+}
+
+while getopts ":A:C:a:d:e:k:o:v:" OPTION
+do
+	case $OPTION in
+		A ) ARCH=$OPTARG;;
+		C ) COMPRESS=$OPTARG;;
+		a ) LOAD_ADDR=$OPTARG;;
+		d ) DTB=$OPTARG;;
+		e ) ENTRY_ADDR=$OPTARG;;
+		k ) KERNEL=$OPTARG;;
+		o ) OUTPUT=$OPTARG;;
+		v ) VERSION=$OPTARG;;
+		* ) echo "Invalid option passed to '$0' (options:$@)"
+		usage;;
+	esac
+done
+
+# Make sure user entered all required parameters
+if [ -z "${ARCH}" ] || [ -z "${COMPRESS}" ] || [ -z "${LOAD_ADDR}" ] || \
+	[ -z "${ENTRY_ADDR}" ] || [ -z "${VERSION}" ] || [ -z "${KERNEL}" ] || \
+	[ -z "${OUTPUT}" ]; then
+	usage
+fi
+
+# Create a default, fully populated DTS file
+DATA="/dts-v1/;
+
+/ {
+	description = \"Linux kernel ${VERSION}\";
+	#address-cells = <1>;
+
+	images {
+		kernel@1 {
+			description = \"Linux Kernel ${VERSION}\";
+			data = /incbin/(\"${KERNEL}\");
+			type = \"kernel\";
+			arch = \"${ARCH}\";
+			os = \"linux\";
+			compression = \"${COMPRESS}\";
+			load = <${LOAD_ADDR}>;
+			entry = <${ENTRY_ADDR}>;
+			hash@1 {
+				algo = \"crc32\";
+			};
+			hash@2 {
+				algo = \"sha1\";
+			};
+		};
+
+		fdt@1 { /* start fdt */
+			description = \"Flattened Device Tree blob\";
+			data = /incbin/(\"${DTB}\");
+			type = \"flat_dt\";
+			arch = \"${ARCH}\";
+			compression = \"none\";
+			hash@1 {
+				algo = \"crc32\";
+			};
+			hash@2 {
+				algo = \"sha1\";
+			};
+		}; /* end fdt */
+
+	configurations {
+		default = \"config@1\";
+		config@1 {
+			description = \"Default Linux kernel\";
+			kernel = \"kernel@1\";
+			fdt = \"fdt@1\";
+			ramdisk = \"ramdisk@1\";
+		};
+	};
+};"
+
+# Conditionally strip fdt information out of tree
+if [ -z "${DTB}" ]; then
+	DATA=`echo "$DATA" | sed '/start fdt/,/end fdt/d'`
+	DATA=`echo "$DATA" | sed '/fdt/d'`
+fi
+
+# Write .its file to disk
+echo "$DATA" > ${OUTPUT}
-- 
1.6.2.1

[PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

The PowerPC architecture has the ability to embed the ramdisk located
at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image.  If
the bootable kernel is in the Flattened Image Tree (FIT) format, the
ramdisk should be a node in the tree instead of being embedded directly
in the kernel executable.

A FIT uImage with a ram filesystem can be generated using the command:
"make uImage.fit.initrd.<boardname>" where <boardname> is one of
arch/powerpc/boot/dts/<boardname>.dts.  The command will generate a FIT
uImage at arch/powerpc/boot/uImage.fit.initrd.<boardname> that contains
a kernel image, device tree blob, and a ram filesystem.

The ramdisk at arch/powerpc/boot/ramdisk.image.gz can either be an older
style "ramdisk" or a newer "ramfs" gzipped cpio archive.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
---
Changes since v1:
- Don't strip leading 0x from dts ramdisk address

 arch/powerpc/boot/Makefile |    3 +++
 arch/powerpc/boot/wrapper  |   20 ++++++++++++++++----
 scripts/mkits.sh           |   34 ++++++++++++++++++++++++++++++++--
 3 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e56ec21..c2a6591 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -313,6 +313,9 @@ $(obj)/uImage: vmlinux $(wrapperbits)
 $(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
 	$(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
 
+$(obj)/uImage.fit.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
+	$(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
+
 $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
 	$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
 
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 1f35b66..9ccaef7 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -270,6 +270,9 @@ fi
 # physical offset of kernel image
 membase=`${CROSS}objdump -p "$kernel" | grep -m 1 LOAD | awk '{print $7}'`
 
+# Size of uncompressed kernel is needed to calculate ramdisk location in RAM
+kernsize=`${CROSS}objdump -p "$kernel" | grep -m 1 rwx | awk '{print $4}'`
+
 case "$platform" in
 uboot)
     rm -f "$ofile"
@@ -282,8 +285,14 @@ uboot)
     ;;
 uboot.fit)
     rm -f "$ofile"
-    ${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
-	-d "$srctree/$dtb" -k "$srctree/$vmz" -o "$object/uImage.its"
+    if [ -n "$initrd" ]; then
+	${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
+	    -d "$srctree/$dtb" -k "$srctree/$vmz" -r "$srctree/$initrd" \
+	    -l $kernsize -o "$object/uImage.its"
+    else
+	${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
+	    -d "$srctree/$dtb" -k "$srctree/$vmz" -o "$object/uImage.its"
+    fi
 
     # mkimage calls dtc for FIT images so use kernel dtc if necessary
     export PATH=$PATH:$srctree/scripts/dtc
@@ -308,8 +317,11 @@ if [ -z "$cacheit" ]; then
     rm -f "$vmz"
 fi
 
-if [ -n "$initrd" ]; then
-    addsec $tmp "$initrd" $isection
+# FIT images have the initrd in the image tree structure
+if [ "$platform" != "uboot.fit" ]; then
+    if [ -n "$initrd" ]; then
+	addsec $tmp "$initrd" $isection
+    fi
 fi
 
 if [ -n "$dtb" ]; then
diff --git a/scripts/mkits.sh b/scripts/mkits.sh
index fae43dd..ffcf2c4 100755
--- a/scripts/mkits.sh
+++ b/scripts/mkits.sh
@@ -16,7 +16,8 @@
 
 usage() {
 	echo "Usage: `basename $0` -A arch -C comp -a addr -e entry" \
-		"-v version -k kernel [-d dtb] -o its_file"
+		"-v version -k kernel [-d dtb] [-r ramfs -l ramfs_addr]" \
+		"-o its_file"
 	echo -e "\t-A ==> set architecture to 'arch'"
 	echo -e "\t-C ==> set compression type 'comp'"
 	echo -e "\t-a ==> set load address to 'addr' (hex)"
@@ -24,11 +25,13 @@ usage() {
 	echo -e "\t-v ==> set kernel version to 'version'"
 	echo -e "\t-k ==> include kernel image 'kernel'"
 	echo -e "\t-d ==> include Device Tree Blob 'dtb'"
+	echo -e "\t-r ==> include initrd/initramfs 'ramfs'"
+	echo -e "\t-l ==> load initrd/initramfs at 'ramfs_addr'"
 	echo -e "\t-o ==> create output file 'its_file'"
 	exit 1
 }
 
-while getopts ":A:C:a:d:e:k:o:v:" OPTION
+while getopts ":A:C:a:d:e:k:l:o:r:v:" OPTION
 do
 	case $OPTION in
 		A ) ARCH=$OPTARG;;
@@ -37,7 +40,9 @@ do
 		d ) DTB=$OPTARG;;
 		e ) ENTRY_ADDR=$OPTARG;;
 		k ) KERNEL=$OPTARG;;
+		l ) RAMFS_ADDR=$OPTARG;;
 		o ) OUTPUT=$OPTARG;;
+		r ) RAMFS=$OPTARG;;
 		v ) VERSION=$OPTARG;;
 		* ) echo "Invalid option passed to '$0' (options:$@)"
 		usage;;
@@ -49,6 +54,8 @@ if [ -z "${ARCH}" ] || [ -z "${COMPRESS}" ] || [ -z "${LOAD_ADDR}" ] || \
 	[ -z "${ENTRY_ADDR}" ] || [ -z "${VERSION}" ] || [ -z "${KERNEL}" ] || \
 	[ -z "${OUTPUT}" ]; then
 	usage
+elif [ -n "${RAMFS}" ] && [ -z "${RAMFS_ADDR}" ]; then
+	usage
 fi
 
 # Create a default, fully populated DTS file
@@ -90,6 +97,23 @@ DATA="/dts-v1/;
 			};
 		}; /* end fdt */
 
+		ramdisk@1 { /* start ramdisk */
+			description = \"ramdisk\";
+			data = /incbin/(\"${RAMFS}\");
+			type = \"ramdisk\";
+			arch = \"${ARCH}\";
+			os = \"linux\";
+			load = <${RAMFS_ADDR}>;
+			compression = \"none\";
+			hash@1 {
+				algo = \"crc32\";
+			};
+			hash@2 {
+				algo = \"sha1\";
+			};
+		}; /* end ramdisk */
+	};
+
 	configurations {
 		default = \"config@1\";
 		config@1 {
@@ -101,6 +125,12 @@ DATA="/dts-v1/;
 	};
 };"
 
+# Conditionally strip ramfs information out of tree
+if [ -z "${RAMFS}" ]; then
+	DATA=`echo "$DATA" | sed '/start ramdisk/,/end ramdisk/d'`
+	DATA=`echo "$DATA" | sed '/ramdisk/d'`
+fi
+
 # Conditionally strip fdt information out of tree
 if [ -z "${DTB}" ]; then
 	DATA=`echo "$DATA" | sed '/start fdt/,/end fdt/d'`
-- 
1.6.2.1

Re: [PATCH v2 2/3] powerpc: Add support for creating FIT uImages

[Olof Johansson]

Hi,

On Mon, Dec 21, 2009 at 07:50:42PM -0600, Peter Tyser wrote:
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index bb2465b..e56ec21 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -310,6 +310,9 @@ $(obj)/zImage.iseries: vmlinux
>  $(obj)/uImage: vmlinux $(wrapperbits)
>  	$(call if_changed,wrap,uboot)
>  
> +$(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> +	$(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
> +
>  $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
>  	$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
>  
> @@ -349,7 +352,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
>  
>  # anything not in $(targets)
>  clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
> -	zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
> +	uImage.* zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \

Please no. It's not entirely uncommon that I will save a "known good"
binary in the build tree for a while, by copying it aside with a different
suffix. That'd give me one very big surprise in this case.


-Olof

Re: [PATCH v2 2/3] powerpc: Add support for creating FIT uImages

[Peter Tyser]

Hi Olof,

On Mon, 2009-12-21 at 21:48 -0600, Olof Johansson wrote:
> Hi,
> 
> On Mon, Dec 21, 2009 at 07:50:42PM -0600, Peter Tyser wrote:
> > diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> > index bb2465b..e56ec21 100644
> > --- a/arch/powerpc/boot/Makefile
> > +++ b/arch/powerpc/boot/Makefile
> > @@ -310,6 +310,9 @@ $(obj)/zImage.iseries: vmlinux
> >  $(obj)/uImage: vmlinux $(wrapperbits)
> >  	$(call if_changed,wrap,uboot)
> >  
> > +$(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> > +	$(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
> > +
> >  $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> >  	$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
> >  
> > @@ -349,7 +352,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
> >  
> >  # anything not in $(targets)
> >  clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
> > -	zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
> > +	uImage.* zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
> 
> Please no. It's not entirely uncommon that I will save a "known good"
> binary in the build tree for a while, by copying it aside with a different
> suffix. That'd give me one very big surprise in this case.

You're right that it'd probably be better if the clean pattern was
uImage.fit.* to be more restrictive, but your concern would still exist,
as it does for a number of other image formats already (cuImage.*,
simpleImage.*, etc).  I can't think of a way to work around that issue
though...  Any ideas?  Don't keep backup images in arch/powerpc/boot?:)

Thanks for the feedback,
Peter

Re: [PATCH v2 1/3] powerpc: Use scripts/mkuboot.sh instead of 'mkimage'

[Grant Likely]

On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> mkuboot.sh provides a basic wrapper for the 'mkimage' utility. =A0Using
> mkuboot.sh provides clearer error reporting and allows a toolchain to
> use its own 'mkimage' executable specified by ${CROSS_COMPILE}mkimage.
> Additionally, this brings PowerPC in line with other architectures
> which already call mkimage via mkuboot.sh.
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>

Okay by me.  I've picked this one up.

g.

> ---
> =A0arch/powerpc/boot/wrapper | =A0 =A07 +++++--
> =A01 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index 390512a..f4594ed 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -43,6 +43,9 @@ gzip=3D.gz
> =A0# cross-compilation prefix
> =A0CROSS=3D
>
> +# mkimage wrapper script
> +MKIMAGE=3D$srctree/scripts/mkuboot.sh
> +
> =A0# directory for object and other files used by this script
> =A0object=3Darch/powerpc/boot
> =A0objbin=3D$object
> @@ -267,7 +270,7 @@ membase=3D`${CROSS}objdump -p "$kernel" | grep -m 1 L=
OAD | awk '{print $7}'`
> =A0case "$platform" in
> =A0uboot)
> =A0 =A0 rm -f "$ofile"
> - =A0 =A0mkimage -A ppc -O linux -T kernel -C gzip -a $membase -e $membas=
e \
> + =A0 =A0${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a $membase -e $mem=
base \
> =A0 =A0 =A0 =A0$uboot_version -d "$vmz" "$ofile"
> =A0 =A0 if [ -z "$cacheit" ]; then
> =A0 =A0 =A0 =A0rm -f "$vmz"
> @@ -327,7 +330,7 @@ coff)
> =A0 =A0 ;;
> =A0cuboot*)
> =A0 =A0 gzip -f -9 "$ofile"
> - =A0 =A0mkimage -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry"=
 \
> + =A0 =A0${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a "$base" -e "$ent=
ry" \
> =A0 =A0 =A0 =A0 =A0 =A0 $uboot_version -d "$ofile".gz "$ofile"
> =A0 =A0 ;;
> =A0treeboot*)
> --
> 1.6.2.1
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH v2 2/3] powerpc: Add support for creating FIT uImages

[Grant Likely]

On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> Recent U-Boot versions support booting a Flattened Image Tree (FIT)
> image format. =A0The FIT uImage format uses a tree structure to describe =
a
> kernel image as well as supporting device tree blobs, ramdisks, etc.
> The 'mkimage' and 'dtc' utilities convert this tree description into a
> binary blob that bootloaders such as U-Boot can execute.
>
> This patch adds support for automatically creating a U-Boot FIT image
> using the "make uImage.fit.<boardname>" command where <boardname> is
> one of arch/powerpc/boot/dts/<boardname>.dts. =A0The resulting
> arch/powerpc/boot/uImage.fit.<boardname> file will contain a kernel
> image as well as a device tree blob. =A0U-Boot versions compiled with FIT
> support can directly boot this image using the "bootm" command.
>
> Additional information about the FIT format and its uses can be found in
> doc/uImage.FIT/howto.txt of U-Boot's source tree.
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> Changes since v1:
> - Add 'dts-v1' header to scripts/mkits.sh output
> - Don't strip leading 0x from dts addresses
> - Default to using kernel dtc if the user doesn't have it in their path

I think I need to NAK this one.  As it is, the wrapper script is a
moderately complex thing, but it has to do a non-trivial job: create a
custom linked executable that sets up the environment that the kernel
expects.  zImage.* wrappers uncompress the kernel, dtbImage.* wrappers
also contain a .dtb image.  cuImage.* wrappers adapt to the old u-boot
interface, etc.

Unfortunately, the wrapper script is also being used to do things that
are completely unrelated to creating wrapper binaries.  FIT images
(and uImages) don't use any of the wrapper bits at all.  In fact, as
seen in this patch, generating them involves bailing out of the
wrapper script early to avoid linking the wrapper bits.  I think for
all types of uImages, the wrapper script is being misused and I don't
like the extra complexity that it adds.

Rather than adding new paths to arch/powerpc/boot/wrapper, I would
rather see a new script used for generating FIT image that isn't
complicated by all the current wrapper cruft.  Also, the Makefile rule
doesn't need to depend on $(wrapperbits) which means faster build
times when only building uImages.

Bonus points if you also convert the uImage target to use the new
script; but I'm not demanding that you do that yet.

Finally, you need to add documentation about the new target to
Documentation/powerpc/bootwrapper.txt.

g.

> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index bb2465b..e56ec21 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -310,6 +310,9 @@ $(obj)/zImage.iseries: vmlinux
> =A0$(obj)/uImage: vmlinux $(wrapperbits)
> =A0 =A0 =A0 =A0$(call if_changed,wrap,uboot)
>
> +$(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> + =A0 =A0 =A0 $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
> +
> =A0$(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> =A0 =A0 =A0 =A0$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ram=
disk.image.gz)
>
> @@ -349,7 +352,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y)=
)
>
> =A0# anything not in $(targets)
> =A0clean-files +=3D $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.*=
 \
> - =A0 =A0 =A0 zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
> + =A0 =A0 =A0 uImage.* zImage zImage.initrd zImage.chrp zImage.coff zImag=
e.holly \
> =A0 =A0 =A0 =A0zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
> =A0 =A0 =A0 =A0simpleImage.* otheros.bld *.dtb
>
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index f4594ed..1f35b66 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -46,6 +46,9 @@ CROSS=3D
> =A0# mkimage wrapper script
> =A0MKIMAGE=3D$srctree/scripts/mkuboot.sh
>
> +# script to generate an .its file for uImage.fit.* images
> +MKITS=3D$srctree/scripts/mkits.sh
> +
> =A0# directory for object and other files used by this script
> =A0object=3Darch/powerpc/boot
> =A0objbin=3D$object
> @@ -157,7 +160,7 @@ coff)
> =A0 =A0 lds=3D$object/zImage.coff.lds
> =A0 =A0 link_address=3D'0x500000'
> =A0 =A0 ;;
> -miboot|uboot)
> +miboot|uboot|uboot.fit)
> =A0 =A0 # miboot and U-boot want just the bare bits, not an ELF binary
> =A0 =A0 ext=3Dbin
> =A0 =A0 objflags=3D"-O binary"
> @@ -277,6 +280,21 @@ uboot)
> =A0 =A0 fi
> =A0 =A0 exit 0
> =A0 =A0 ;;
> +uboot.fit)
> + =A0 =A0rm -f "$ofile"
> + =A0 =A0${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
> + =A0 =A0 =A0 -d "$srctree/$dtb" -k "$srctree/$vmz" -o "$object/uImage.it=
s"
> +
> + =A0 =A0# mkimage calls dtc for FIT images so use kernel dtc if necessar=
y
> + =A0 =A0export PATH=3D$PATH:$srctree/scripts/dtc
> +
> + =A0 =A0${MKIMAGE} -f "$object/uImage.its" "$ofile"
> + =A0 =A0rm "$object/uImage.its"
> + =A0 =A0if [ -z "$cacheit" ]; then
> + =A0 =A0 =A0 rm -f "$vmz"
> + =A0 =A0fi
> + =A0 =A0exit 0
> + =A0 =A0;;
> =A0esac
>
> =A0addsec() {
> diff --git a/scripts/mkits.sh b/scripts/mkits.sh
> new file mode 100755
> index 0000000..fae43dd
> --- /dev/null
> +++ b/scripts/mkits.sh
> @@ -0,0 +1,111 @@
> +#!/bin/bash
> +#
> +# Licensed under the terms of the GNU GPL License version 2 or later.
> +#
> +# Author: Peter Tyser <ptyser@xes-inc.com>
> +#
> +# U-Boot firmware supports the booting of images in the Flattened Image
> +# Tree (FIT) format. =A0The FIT format uses a device tree structure to
> +# describe a kernel image, device tree blob, ramdisk, etc. =A0This scrip=
t
> +# creates an Image Tree Source (.its file) which can be passed to the
> +# 'mkimage' utility to generate an Image Tree Blob (.itb file). =A0The .=
itb
> +# file can then be booted by U-Boot (or other bootloaders which support
> +# FIT images). =A0See doc/uImage.FIT/howto.txt in U-Boot source code for
> +# additional information on FIT images.
> +#
> +
> +usage() {
> + =A0 =A0 =A0 echo "Usage: `basename $0` -A arch -C comp -a addr -e entry=
" \
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "-v version -k kernel [-d dtb] -o its_file"
> + =A0 =A0 =A0 echo -e "\t-A =3D=3D> set architecture to 'arch'"
> + =A0 =A0 =A0 echo -e "\t-C =3D=3D> set compression type 'comp'"
> + =A0 =A0 =A0 echo -e "\t-a =3D=3D> set load address to 'addr' (hex)"
> + =A0 =A0 =A0 echo -e "\t-e =3D=3D> set entry point to 'entry' (hex)"
> + =A0 =A0 =A0 echo -e "\t-v =3D=3D> set kernel version to 'version'"
> + =A0 =A0 =A0 echo -e "\t-k =3D=3D> include kernel image 'kernel'"
> + =A0 =A0 =A0 echo -e "\t-d =3D=3D> include Device Tree Blob 'dtb'"
> + =A0 =A0 =A0 echo -e "\t-o =3D=3D> create output file 'its_file'"
> + =A0 =A0 =A0 exit 1
> +}
> +
> +while getopts ":A:C:a:d:e:k:o:v:" OPTION
> +do
> + =A0 =A0 =A0 case $OPTION in
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 A ) ARCH=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 C ) COMPRESS=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 a ) LOAD_ADDR=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 d ) DTB=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 e ) ENTRY_ADDR=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 k ) KERNEL=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 o ) OUTPUT=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 v ) VERSION=3D$OPTARG;;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 * ) echo "Invalid option passed to '$0' (op=
tions:$@)"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 usage;;
> + =A0 =A0 =A0 esac
> +done
> +
> +# Make sure user entered all required parameters
> +if [ -z "${ARCH}" ] || [ -z "${COMPRESS}" ] || [ -z "${LOAD_ADDR}" ] || =
\
> + =A0 =A0 =A0 [ -z "${ENTRY_ADDR}" ] || [ -z "${VERSION}" ] || [ -z "${KE=
RNEL}" ] || \
> + =A0 =A0 =A0 [ -z "${OUTPUT}" ]; then
> + =A0 =A0 =A0 usage
> +fi
> +
> +# Create a default, fully populated DTS file
> +DATA=3D"/dts-v1/;
> +
> +/ {
> + =A0 =A0 =A0 description =3D \"Linux kernel ${VERSION}\";
> + =A0 =A0 =A0 #address-cells =3D <1>;
> +
> + =A0 =A0 =A0 images {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 kernel@1 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 description =3D \"Linux Ker=
nel ${VERSION}\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 data =3D /incbin/(\"${KERNE=
L}\");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type =3D \"kernel\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 arch =3D \"${ARCH}\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 os =3D \"linux\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compression =3D \"${COMPRES=
S}\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 load =3D <${LOAD_ADDR}>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entry =3D <${ENTRY_ADDR}>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hash@1 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algo =3D \"=
crc32\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hash@2 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algo =3D \"=
sha1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 fdt@1 { /* start fdt */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 description =3D \"Flattened=
 Device Tree blob\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 data =3D /incbin/(\"${DTB}\=
");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type =3D \"flat_dt\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 arch =3D \"${ARCH}\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compression =3D \"none\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hash@1 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algo =3D \"=
crc32\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hash@2 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algo =3D \"=
sha1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }; /* end fdt */
> +
> + =A0 =A0 =A0 configurations {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 default =3D \"config@1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 config@1 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 description =3D \"Default L=
inux kernel\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 kernel =3D \"kernel@1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fdt =3D \"fdt@1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ramdisk =3D \"ramdisk@1\";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 };
> +};"
> +
> +# Conditionally strip fdt information out of tree
> +if [ -z "${DTB}" ]; then
> + =A0 =A0 =A0 DATA=3D`echo "$DATA" | sed '/start fdt/,/end fdt/d'`
> + =A0 =A0 =A0 DATA=3D`echo "$DATA" | sed '/fdt/d'`
> +fi
> +
> +# Write .its file to disk
> +echo "$DATA" > ${OUTPUT}
> --
> 1.6.2.1
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Grant Likely]

On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> The PowerPC architecture has the ability to embed the ramdisk located
> at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image. =A0If
> the bootable kernel is in the Flattened Image Tree (FIT) format, the
> ramdisk should be a node in the tree instead of being embedded directly
> in the kernel executable.
>
> A FIT uImage with a ram filesystem can be generated using the command:
> "make uImage.fit.initrd.<boardname>" where <boardname> is one of
> arch/powerpc/boot/dts/<boardname>.dts. =A0The command will generate a FIT
> uImage at arch/powerpc/boot/uImage.fit.initrd.<boardname> that contains
> a kernel image, device tree blob, and a ram filesystem.
>
> The ramdisk at arch/powerpc/boot/ramdisk.image.gz can either be an older
> style "ramdisk" or a newer "ramfs" gzipped cpio archive.
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> Changes since v1:
> - Don't strip leading 0x from dts ramdisk address
>
> =A0arch/powerpc/boot/Makefile | =A0 =A03 +++
> =A0arch/powerpc/boot/wrapper =A0| =A0 20 ++++++++++++++++----
> =A0scripts/mkits.sh =A0 =A0 =A0 =A0 =A0 | =A0 34 ++++++++++++++++++++++++=
++++++++--
> =A03 files changed, 51 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index e56ec21..c2a6591 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -313,6 +313,9 @@ $(obj)/uImage: vmlinux $(wrapperbits)
> =A0$(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> =A0 =A0 =A0 =A0$(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
>
> +$(obj)/uImage.fit.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> + =A0 =A0 =A0 $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb,$(obj)/ramd=
isk.image.gz)
> +

IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
Makefile so that make behaves more consistently.  Speaking of which,
the number of '.' in the name is getting rather large.  Would you
consider using 'fitImage' instead of 'uImage.fit'?

g.

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

Hi Grant,
I put U-Boot ML on CC.

On Wed, 2009-12-30 at 16:02 -0700, Grant Likely wrote:
> On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> > The PowerPC architecture has the ability to embed the ramdisk located
> > at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image.  If
> > the bootable kernel is in the Flattened Image Tree (FIT) format, the
> > ramdisk should be a node in the tree instead of being embedded directly
> > in the kernel executable.
> >
> > A FIT uImage with a ram filesystem can be generated using the command:
> > "make uImage.fit.initrd.<boardname>" where <boardname> is one of
> > arch/powerpc/boot/dts/<boardname>.dts.  The command will generate a FIT
> > uImage at arch/powerpc/boot/uImage.fit.initrd.<boardname> that contains
> > a kernel image, device tree blob, and a ram filesystem.
> >
> > The ramdisk at arch/powerpc/boot/ramdisk.image.gz can either be an older
> > style "ramdisk" or a newer "ramfs" gzipped cpio archive.
> >
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > ---
> > Changes since v1:
> > - Don't strip leading 0x from dts ramdisk address
> >
> >  arch/powerpc/boot/Makefile |    3 +++
> >  arch/powerpc/boot/wrapper  |   20 ++++++++++++++++----
> >  scripts/mkits.sh           |   34 ++++++++++++++++++++++++++++++++--
> >  3 files changed, 51 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> > index e56ec21..c2a6591 100644
> > --- a/arch/powerpc/boot/Makefile
> > +++ b/arch/powerpc/boot/Makefile
> > @@ -313,6 +313,9 @@ $(obj)/uImage: vmlinux $(wrapperbits)
> >  $(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> >        $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
> >
> > +$(obj)/uImage.fit.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> > +       $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
> > +
> 
> IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> Makefile so that make behaves more consistently.

Makes sense.

> Speaking of which,
> the number of '.' in the name is getting rather large.  Would you
> consider using 'fitImage' instead of 'uImage.fit'?

Sure, I don't have a strong opinion about the name.  I settled on
uImage.fit because all the U-Boot documentation describes the FIT images
as type of uImage.  Eg the readme is located in doc/uImage.fit, its
referred to as the "new uImage" format, etc.  So using the
"uimage.fit.*" name goes along with the concept that a FIT image is a
type of uImage.  A target like fitImage loses the uImage<->FIT
connection.

But I do agree that "."s are a bit overwhelming.  I could rework these
patches with your suggested fitImage target name and follow-up with
U-Boot patches to clear up its documentation.  In my opinion, there's
not much reason to keep the uImage<->FIT connection that currently
exists in U-Boot.  Right now U-Boot documents the "Legacy uImage" and
"FIT uImage" format when logically it would make sense to rename the
formats to "uImage" and "FIT" as there isn't much in common between the
2 formats.  The FIT image is just a blob generated by the device tree
compiler, its not tied to U-Boot in any way.

Does anyone in the U-Boot community have an opinion about this?  I'm
fine with keeping the uImage.fit naming or using fitImage for this
patch, but I think U-Boot's documentation should be on the same page
either way.

Thanks for the review,
Peter

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Grant Likely]

On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> Hi Grant,
> I put U-Boot ML on CC.

Thinking further, I do actually have another concern, at least with
regard to the way the current patch set implements things.  Is it
expected or even "recommended" that fit images will *always* contain a
.dtb image?  The current patch only handles the case of a .dtb
embedded inside the fit image.

Personally, I don't get any benefit out of the new image format, so I
haven't spent any time looking at it.  However, I'm concerned about
the drift back towards a different image per target when the move over
the last 4 years has been towards multiplatform kernel images.  I
certainly don't want to encourage embedding the device tree blob into
the kernel image, and I'm not very interested in merging code to do
that into the kernel tree.  If someone really needs to do that for
their particular target, it is certainly easy enough for them to weld
in the .dtb after the fact before transferring the image to the
target, but I want that mode to be the exception, not the rule.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

On Wed, 2009-12-30 at 17:01 -0700, Grant Likely wrote:
> On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> > Hi Grant,
> > I put U-Boot ML on CC.
> 
> Thinking further, I do actually have another concern, at least with
> regard to the way the current patch set implements things.  Is it
> expected or even "recommended" that fit images will *always* contain a
> .dtb image?  The current patch only handles the case of a .dtb
> embedded inside the fit image.

I'm not aware of any recommendations as far as what FIT images should
contain and there isn't a requirement that it should contain a .dtb
image - its just a flexible image format.

I believe in the most common FIT usage scenario the image would contain
both a kernel image and .dtb file though.  For example, most people I
deal with just have boardX and boardY that they want to boot Linux on.

Currently they have to make a "legacy" uImage, manually run the device
tree compiler with the proper flags to generate a board-specific .dtb
file, transfer the uImage to to boardX, transfer the .dtb file to
boardX, set some U-Boot variables, then boot to Linux.  For boardY they
would have to redo the steps with the exception of recreating the legacy
uImage.  (To add to the confusion, the format of device trees is a
somewhat moving target, so .dtb files aren't always compatible with
different kernel versions.)

The FIT+.dtb patches I sent make it so the same process is shortened to:
make a FIT image for boardX which contains a .dtb, download it to
boardX, and boot it.  Then repeat the same steps for boardY.

> Personally, I don't get any benefit out of the new image format, so I
> haven't spent any time looking at it.  However, I'm concerned about
> the drift back towards a different image per target when the move over
> the last 4 years has been towards multiplatform kernel images.  I
> certainly don't want to encourage embedding the device tree blob into
> the kernel image, and I'm not very interested in merging code to do
> that into the kernel tree.  If someone really needs to do that for
> their particular target, it is certainly easy enough for them to weld
> in the .dtb after the fact before transferring the image to the
> target, but I want that mode to be the exception, not the rule.

I see your point.  The main goal of the patch was to introduce FIT image
support as its the new, more flexible, "better", standard image format
for U-Boot going forward.  Also, lots people aren't aware of FIT images
and the cool stuff they can do with them, so what better way to get the
word out than getting support for FIT images included in the kernel
proper:)

I think it would be nice to generate a FIT image that contained the
kernel + .dtb as it significantly simplifies the process of booting
Linux for the common case for lots of U-Boot users and showcases one of
the benefits of the FIT format.  If you'd prefer not to have this
portion of the patch included, I can respin so that the FIT image
created only contains a kernel image, not a .dtb or initramfs.  Or I
could make targets of fitImage (no dtb included), fitImage.<board> (dtb
included), and fitImage.initrd.<board> (dtb and initramfs included).
Either way is fine with me, it'd just be nice to see FIT support get in
in some form.

Thanks,
Peter

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Korsgaard]

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

Hi,

 Grant> Personally, I don't get any benefit out of the new image format,
 Grant> so I haven't spent any time looking at it.  However, I'm
 Grant> concerned about the drift back towards a different image per
 Grant> target when the move over the last 4 years has been towards
 Grant> multiplatform kernel images.  I certainly don't want to
 Grant> encourage embedding the device tree blob into the kernel image,
 Grant> and I'm not very interested in merging code to do that into the
 Grant> kernel tree.  If someone really needs to do that for their
 Grant> particular target, it is certainly easy enough for them to weld
 Grant> in the .dtb after the fact before transferring the image to the
 Grant> target, but I want that mode to be the exception, not the rule.

I understand the advantages of being able to compile multiplatform
kernels - But for the typical embedded device, having the device tree
together with the kernel makes stuff a lot simpler when upgrading
because of the version depencies of the dts.

That's also why I submitted the (nacked) multifile uimage support some
time ago:

http://thread.gmane.org/gmane.linux.ports.ppc64.devel/46825/

The fitimage stuff is the logical continuation of that.

-- 
Bye, Peter Korsgaard

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Wolfgang Denk]

Dear Grant Likely,

In message <fa686aa40912301502x48785614ya4dd5c71815a7633@mail.gmail.com> you wrote:
>
> IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> Makefile so that make behaves more consistently.  Speaking of which,
> the number of '.' in the name is getting rather large.  Would you
> consider using 'fitImage' instead of 'uImage.fit'?

Why chose a different name at all? We could still call it "uImage",
meaning "U-Boot image" - U-Boot is clever enought o detect
automatically if we pass it an old style or a fit image.

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@denx.de
If the odds are a million to one against something occuring,  chances
are 50-50 it will.

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

Hi Wolfgang,

> > IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> > Makefile so that make behaves more consistently.  Speaking of which,
> > the number of '.' in the name is getting rather large.  Would you
> > consider using 'fitImage' instead of 'uImage.fit'?
> 
> Why chose a different name at all? We could still call it "uImage",
> meaning "U-Boot image" - U-Boot is clever enought o detect
> automatically if we pass it an old style or a fit image.

I agree with your point to an extent, but having 2 types of uImages is
somewhat confusing to a user, even if U-Boot can differentiate between
them.  And if the legacy image and FIT image had the same Make target,
how does a user specify which type they want to build?  The fact that
both "legacy" and FIT images would reside at arch/powerpc/boot/uImage
doesn't make things any less confusing to Joe User.

Currently U-Boot supports booting:
1 "legacy" uImages
2 "new" Flattened Image Tree (FIT) uImages

What do you think about changing the U-Boot documentation to rename
those 2 image types to:
1 uImages
2 FIT Images

The FIT image is a relatively generic image type - its just a blob that
dtc created from a device tree and some input binaries.  In my mind its
not intimately tied to U-Boot, at least not conceptually.  The "legacy"
uImages have to agree with U-Boot's header format defined in the U-Boot
source code, so the uImage name does make sense with respect to the
"legacy" uImages.

My vote would be to make the Linux FIT target rule "fitImage" and then
update the U-Boot documentation to make obvious the differences between
uImages and FIT images.

What do you think of that?

Thanks,
Peter

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Wolfgang Denk]

Dear Peter,

In message <1262301038.29396.137.camel@localhost.localdomain> you wrote:
> 
> > Why chose a different name at all? We could still call it "uImage",
> > meaning "U-Boot image" - U-Boot is clever enought o detect
> > automatically if we pass it an old style or a fit image.
> 
> I agree with your point to an extent, but having 2 types of uImages is
> somewhat confusing to a user, even if U-Boot can differentiate between
> them.  And if the legacy image and FIT image had the same Make target,
> how does a user specify which type they want to build?  The fact that
> both "legacy" and FIT images would reside at arch/powerpc/boot/uImage
> doesn't make things any less confusing to Joe User.

Agreed.

> Currently U-Boot supports booting:
> 1 "legacy" uImages
> 2 "new" Flattened Image Tree (FIT) uImages

The "legacy" uImage format has a number of restrictions not unsimilar
to the restrictions we had in the bootloader / kernel interface when
using the old binary bd_info data structur. For the kernel interface
this has been replaced by using the device tree, and I would like to
see the same happen in U-Boot.

The "new" FIT image type should become the default, and old "legacy"
images should only be generated upon special request (i. e. if some-
one needs these for compatibility with an old, not yet FIT-aware
version of the boot loader).

> What do you think about changing the U-Boot documentation to rename
> those 2 image types to:
> 1 uImages
> 2 FIT Images

Let's make this "uImage.old" (or "uImage.legacy" similar) and
"uImage", then.

> The FIT image is a relatively generic image type - its just a blob that
> dtc created from a device tree and some input binaries.  In my mind its
> not intimately tied to U-Boot, at least not conceptually.  The "legacy"

Correct. The intention was to provide an open and somewhat
"standardized" format that can be easily extended for new
requirements, whatever these may be.

> uImages have to agree with U-Boot's header format defined in the U-Boot
> source code, so the uImage name does make sense with respect to the
> "legacy" uImages.

Well, you can read "uImage" as "universal Image", which kind of fits
the FIT approach :-)

> My vote would be to make the Linux FIT target rule "fitImage" and then
> update the U-Boot documentation to make obvious the differences between
> uImages and FIT images.

I think we should not try to support both legacy and FIT images on the
same level - the idea is clearly that legacy images is the old, to be
replaced format, while FIT images is the new, to be used as standard
format. In this sense I vote for using plain and simple "uImage" for
the (new) standard format, and marking the old format by some ".old"
or ".legacy" suffix.

BTW: note that (IIRC) we don't even have a formal definition of the
"FIT" abbreviation yet ;-)

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@denx.de
"The more data I punch in this card,  the lighter it becomes, and the
lower the mailing cost."
                     - Stan Kelly-Bootle, "The Devil's DP Dictionary"

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Wolfgang Denk]

Dear Grant,

In message <fa686aa40912301601s6cd0ec4y85b88976159a36af@mail.gmail.com> you wrote:
>
> Thinking further, I do actually have another concern, at least with
> regard to the way the current patch set implements things.  Is it
> expected or even "recommended" that fit images will *always* contain a
> .dtb image?  The current patch only handles the case of a .dtb
> embedded inside the fit image.

I think this can be expected.

Historically, the need to pass the dtb image to the Linux kernel,
too, was what actually triggered the development of the FIT image
format, as it turned out that the old image format with it's fixed
binary header was too inflexible. So bundling the kernel image and
the device tree blob into one image file is the specific use case
this image format was created for (which does not mean that other
usage would be impossible).

> Personally, I don't get any benefit out of the new image format, so I
> haven't spent any time looking at it.  However, I'm concerned about

Assume you want to boot over DHCP or similar, where you can provide
just a single image file for download. Here it is definitely nice if
you can bundle the kernel image and the DTB into one image file. We
were able to extend the old so-called "multi-file" uImage format to
handle this situation, too, but it was clear that further extensions
were not really possible.

We consider the old legace uImage format as something we want to move
away from, and the new FIT image format shall be the new default.

> the drift back towards a different image per target when the move over
> the last 4 years has been towards multiplatform kernel images.  I
> certainly don't want to encourage embedding the device tree blob into
> the kernel image, and I'm not very interested in merging code to do
> that into the kernel tree.  If someone really needs to do that for
> their particular target, it is certainly easy enough for them to weld
> in the .dtb after the fact before transferring the image to the
> target, but I want that mode to be the exception, not the rule.

This is specific for particular targets, but for  specific  modes  of
operation,  like  booting  over  the network or other szenarios where
transferring a single image file is essential - another example where
we often see this request is upgrade procedures for devics, where the
vendor wants to be able to distribute a single file  for  his  target
systems   to  avoid  customers  bricking  their  devices  by  chosing
incompatible combinations.

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@denx.de
Perfection is reached, not when there is no longer anything  to  add,
but when there is no longer anything to take away.
                                           - Antoine de Saint-Exupery

Re: [PATCH v2 2/3] powerpc: Add support for creating FIT uImages

[Wolfgang Denk]

Dear Grant,

In message <fa686aa40912301457l704c324bk511a207d07218525@mail.gmail.com> you wrote:
>
> Unfortunately, the wrapper script is also being used to do things that
> are completely unrelated to creating wrapper binaries.  FIT images
> (and uImages) don't use any of the wrapper bits at all.  In fact, as
> seen in this patch, generating them involves bailing out of the
> wrapper script early to avoid linking the wrapper bits.  I think for
> all types of uImages, the wrapper script is being misused and I don't
> like the extra complexity that it adds.

Agreed.

> Rather than adding new paths to arch/powerpc/boot/wrapper, I would
> rather see a new script used for generating FIT image that isn't
> complicated by all the current wrapper cruft.  Also, the Makefile rule
> doesn't need to depend on $(wrapperbits) which means faster build
> times when only building uImages.
> 
> Bonus points if you also convert the uImage target to use the new
> script; but I'm not demanding that you do that yet.

I think if this is handles in a separate script, the legacy uImage
support must be handled in this new script, too. Otherwise it would be
too difficult to understanmd the relation of the two image formats.

> Finally, you need to add documentation about the new target to
> Documentation/powerpc/bootwrapper.txt.

Let's keep in mind that the uImage formats (both the old legacy and
the new FIT format) are inherently architecture independent. We want
to use this same mechanism for example on ARM, and on other
architectures as well.

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@denx.de
How many Unix hacks does it take to change a light bulb?  Let's  see,
   can you use a shell script for that or does it need a C program?

Re: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Grant Likely]

Hi Peter,

On Wed, Dec 30, 2009 at 6:10 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> On Wed, 2009-12-30 at 17:01 -0700, Grant Likely wrote:
>> On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
>> > Hi Grant,
>> > I put U-Boot ML on CC.
>>
>> Thinking further, I do actually have another concern, at least with
>> regard to the way the current patch set implements things. =A0Is it
>> expected or even "recommended" that fit images will *always* contain a
>> .dtb image? =A0The current patch only handles the case of a .dtb
>> embedded inside the fit image.
>
> I'm not aware of any recommendations as far as what FIT images should
> contain and there isn't a requirement that it should contain a .dtb
> image - its just a flexible image format.
>
> I believe in the most common FIT usage scenario the image would contain
> both a kernel image and .dtb file though. =A0For example, most people I
> deal with just have boardX and boardY that they want to boot Linux on.
>
> Currently they have to make a "legacy" uImage, manually run the device
> tree compiler with the proper flags to generate a board-specific .dtb
> file,

... or put the .dts files into arch/powerpc/boot/dts and use 'make <board>.=
dtb'

multiple <board>.dtb targets can also be added to CONFIG_EXTRA_TARGETS
so that a plain 'make' will build all needed files.

> transfer the uImage to to boardX, transfer the .dtb file to
> boardX, set some U-Boot variables, then boot to Linux. =A0For boardY they
> would have to redo the steps with the exception of recreating the legacy
> uImage. =A0(To add to the confusion, the format of device trees is a
> somewhat moving target, so .dtb files aren't always compatible with
> different kernel versions.)

The are no guarantees that new dtb files will work with old kernels,
but old dtb files should continue to work with new kernels.  There
have been growing pains in this regard, and there are a number of
examples where this hasn't been the case especially as we were
learning how best to use the device tree.  It is a lot more stable now
than it had been and new cases can be considered a kernel bug.

>> Personally, I don't get any benefit out of the new image format, so I
>> haven't spent any time looking at it. =A0However, I'm concerned about
>> the drift back towards a different image per target when the move over
>> the last 4 years has been towards multiplatform kernel images. =A0I
>> certainly don't want to encourage embedding the device tree blob into
>> the kernel image, and I'm not very interested in merging code to do
>> that into the kernel tree. =A0If someone really needs to do that for
>> their particular target, it is certainly easy enough for them to weld
>> in the .dtb after the fact before transferring the image to the
>> target, but I want that mode to be the exception, not the rule.
>
> I see your point. =A0The main goal of the patch was to introduce FIT imag=
e
> support as its the new, more flexible, "better", standard image format
> for U-Boot going forward. =A0Also, lots people aren't aware of FIT images
> and the cool stuff they can do with them, so what better way to get the
> word out than getting support for FIT images included in the kernel
> proper:)

Define 'better'.  :-)

I do understand your use-case and what problem fit images solve for
you.  However, from a "long term strategy" point of view it is a use
case that I'm not interested in actively supporting for two reasons.
The first is that I think it is in our best interest to encourage the
mind set that the hardware description is separate from the operating
system image, and so they should be stored and updated separately.  I
look at the unexpected ecosystem of distributions that has sprung up
around wireless routers (ie OpenWRT and the like) and Linux cell
phones (ie. Cyanogen Mod) where there is a huge range of hardware.
The userspace can pretty much run on any of them excepting minor
configuration changes.  The embedded space is becoming more PCs in
this regard, and I know that multiplatform is a big deal for some of
the users.  I'm not interested in encouraging any behaviour that will
scuttle deployment of multiplatform kernels.  (That being said, I'm
not going to actively sabotage people who want to put dtb sections
into the kernel images either.  I understand that at times it is
necessary, and there are numerous examples of this already in the
kernel tree; specifically to support firmware that doesn't implement
arch/powerpc's boot interface)

The second is that I no longer think it is a good idea to be building
bootloader specific image fomats if we can help it.  U-Boot is not the
only game bootloaders, especially when talking about ARM or MIPS, and
some folks are even using kexec to go from one kernel to the next.
Having the same image format for all firmware and also kexec is far
more interesting to me than the a new u-boot format.  Some form of
zImage seems to be a more likely format to standardize around than the
FIT format, mostly because kexec and a lot of firmware already
understand zImages, and it doesn't require firmware to link in libfdt.

> I think it would be nice to generate a FIT image that contained the
> kernel + .dtb as it significantly simplifies the process of booting
> Linux for the common case for lots of U-Boot users and showcases one of
> the benefits of the FIT format. =A0If you'd prefer not to have this
> portion of the patch included, I can respin so that the FIT image
> created only contains a kernel image, not a .dtb or initramfs. =A0Or I
> could make targets of fitImage (no dtb included), fitImage.<board> (dtb
> included), and fitImage.initrd.<board> (dtb and initramfs included).
> Either way is fine with me, it'd just be nice to see FIT support get in
> in some form.

I'd be okay (perhaps not happy, but okay) with merging fitImage and
fitImage.initrd targets (no dtb).  I will resist merging fitImage.%
and fitImage.initrd.% targets because I see that very much as a
project specific deployment target and I'm not convinced yet that it
the pattern is right or that it is even needed in the kernel at all.

Cheers,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Grant Likely]

On Thu, Dec 31, 2009 at 3:44 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa40912301502x48785614ya4dd5c71815a7633@mail.gmail.com> =
you wrote:
>>
>> IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
>> Makefile so that make behaves more consistently. =A0Speaking of which,
>> the number of '.' in the name is getting rather large. =A0Would you
>> consider using 'fitImage' instead of 'uImage.fit'?
>
> Why chose a different name at all? We could still call it "uImage",
> meaning "U-Boot image" - U-Boot is clever enought o detect
> automatically if we pass it an old style or a fit image.

Simply because arch/powerpc/boot/Makefile needs different target names
to decide which kind of image to build.  I don't care much about the
name, it can always be renamed at install time, but I do care that the
make build targets are sane.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Grant Likely]

On Fri, Jan 1, 2010 at 3:44 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Peter,
>
> In message <1262301038.29396.137.camel@localhost.localdomain> you wrote:
>> What do you think about changing the U-Boot documentation to rename
>> those 2 image types to:
>> 1 uImages
>> 2 FIT Images
>
> Let's make this "uImage.old" (or "uImage.legacy" similar) and
> "uImage", then.

I'm not interested in renaming the target name for the current uImage
format.  I think it will cause too much breakage and pain to do so.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Grant Likely]

On Fri, Jan 1, 2010 at 7:12 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant,
>
> In message <fa686aa40912301601s6cd0ec4y85b88976159a36af@mail.gmail.com> y=
ou wrote:
>>
>> Thinking further, I do actually have another concern, at least with
>> regard to the way the current patch set implements things. =A0Is it
>> expected or even "recommended" that fit images will *always* contain a
>> .dtb image? =A0The current patch only handles the case of a .dtb
>> embedded inside the fit image.
>
> I think this can be expected.
>
> Historically, the need to pass the dtb image to the Linux kernel,
> too, was what actually triggered the development of the FIT image
> format, as it turned out that the old image format with it's fixed
> binary header was too inflexible. So bundling the kernel image and
> the device tree blob into one image file is the specific use case
> this image format was created for (which does not mean that other
> usage would be impossible).
>
>> Personally, I don't get any benefit out of the new image format, so I
>> haven't spent any time looking at it. =A0However, I'm concerned about
>
> Assume you want to boot over DHCP or similar, where you can provide
> just a single image file for download. Here it is definitely nice if
> you can bundle the kernel image and the DTB into one image file. We
> were able to extend the old so-called "multi-file" uImage format to
> handle this situation, too, but it was clear that further extensions
> were not really possible.
>
> We consider the old legace uImage format as something we want to move
> away from, and the new FIT image format shall be the new default.
>
>> the drift back towards a different image per target when the move over
>> the last 4 years has been towards multiplatform kernel images. =A0I
>> certainly don't want to encourage embedding the device tree blob into
>> the kernel image, and I'm not very interested in merging code to do
>> that into the kernel tree. =A0If someone really needs to do that for
>> their particular target, it is certainly easy enough for them to weld
>> in the .dtb after the fact before transferring the image to the
>> target, but I want that mode to be the exception, not the rule.
>
> This is specific for particular targets, but for =A0specific =A0modes =A0=
of
> operation, =A0like =A0booting =A0over =A0the network or other szenarios w=
here
> transferring a single image file is essential - another example where
> we often see this request is upgrade procedures for devics, where the
> vendor wants to be able to distribute a single file =A0for =A0his =A0targ=
et
> systems =A0 to =A0avoid =A0customers =A0bricking =A0their =A0devices =A0b=
y =A0chosing
> incompatible combinations.

As I said in a previous email; I understand the need for certain
scenarios, but in the general case it is not the mode that I think
should be encouraged.  I don't want to merge additional targets for
.dtb embedded in the kernel image unless absolutely necessary, and I
want developers to have the mindset that .dtbs should be separate from
the kernel; and should be quasi-stable (or at least more stable than
the kernel itself) because I think that multiplatform is important,
and is going to become more important in the future.

So I don't want to support it by default; but OTOH, I'm not going to
actively prevent embedded .dtb blobs either.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH v2 2/3] powerpc: Add support for creating FIT uImages

[Grant Likely]

On Fri, Jan 1, 2010 at 7:18 AM, Wolfgang Denk <wd@denx.de> wrote:
>> Rather than adding new paths to arch/powerpc/boot/wrapper, I would
>> rather see a new script used for generating FIT image that isn't
>> complicated by all the current wrapper cruft. =A0Also, the Makefile rule
>> doesn't need to depend on $(wrapperbits) which means faster build
>> times when only building uImages.
>>
>> Bonus points if you also convert the uImage target to use the new
>> script; but I'm not demanding that you do that yet.
>
> I think if this is handles in a separate script, the legacy uImage
> support must be handled in this new script, too. Otherwise it would be
> too difficult to understanmd the relation of the two image formats.

I'm fine with this.  But if I receive a patch that does one and not
the other, I'll probably still merge it.  :-)

>> Finally, you need to add documentation about the new target to
>> Documentation/powerpc/bootwrapper.txt.
>
> Let's keep in mind that the uImage formats (both the old legacy and
> the new FIT format) are inherently architecture independent. We want
> to use this same mechanism for example on ARM, and on other
> architectures as well.

That's fine, but Documentation/powerpc/bootwrapper.txt happens to also
be the place that documents how the boot image creation on
arch/powerpc works.  I'm happy for the text about uImage and fitImage
to make reference to a different Documentation file or URL.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Korsgaard]

>>>>> "Wolfgang" == Wolfgang Denk <wd@denx.de> writes:

 >> What do you think about changing the U-Boot documentation to rename
 >> those 2 image types to:
 >> 1 uImages
 >> 2 FIT Images

 Wolfgang> Let's make this "uImage.old" (or "uImage.legacy" similar) and
 Wolfgang> "uImage", then.

No, that would break stuff for the existing users. The existing format
make/file names shouldn't change.

The FIT images could be called fitimage or uImage.new or something.

-- 
Bye, Peter Korsgaard

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Wolfgang Denk]

Dear Peter,

In message <87wrzzpq8c.fsf@macbook.be.48ers.dk> you wrote:
>
>  Wolfgang> Let's make this "uImage.old" (or "uImage.legacy" similar) and
>  Wolfgang> "uImage", then.
> 
> No, that would break stuff for the existing users. The existing format
> make/file names shouldn't change.

Well, with this argument you can block all progress and freeze all
development to some ancient state.

When the arch/ppc => arch/powerpc conversionm was done, we had similar
issues: the new "powerpc" uImages would not work as the old "ppc"
uImages dis, because you also needed the device tree blob, or you had
to use the cuImage files. Note that then the decision was made to
support the _new_ version as the default, using the default name,
which is IMO the Right Thing to do.

> The FIT images could be called fitimage or uImage.new or something.

I disagree. We want to make this the new default, so let's use the
default name for this, and continue to support he legacy image format
using another name.

Also, your approach does not scale. Assume we come up with an even
more advanced image format in the future - how should we name it then?
"uImage.newer" ? "uImage.verynew" ? "uImage.new2" ?

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@denx.de
The world is coming to an end -- save your buffers!

Re: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Wolfgang Denk]

Dear Grant Likely,

In message <fa686aa41001022108i92596d6qdf2da0e24c34767e@mail.gmail.com> you wrote:
> 
> > Currently they have to make a "legacy" uImage, manually run the device
> > tree compiler with the proper flags to generate a board-specific .dtb
> > file,
> 
> ... or put the .dts files into arch/powerpc/boot/dts and use 'make <board>.=
> dtb'
> 
> multiple <board>.dtb targets can also be added to CONFIG_EXTRA_TARGETS
> so that a plain 'make' will build all needed files.

Note that the FIT image can also be made to contain a number of DT
blobs, and selection of a "board profile" then can be used to boot the
very sane FIT image file on any of the supported boards - so FIT
images inherently support multibooting.

> > I see your point.  The main goal of the patch was to introduce FIT image
> > support as its the new, more flexible, "better", standard image format
> > for U-Boot going forward.  Also, lots people aren't aware of FIT images
> > and the cool stuff they can do with them, so what better way to get the
> > word out than getting support for FIT images included in the kernel
> > proper:)
>
> Define 'better'.  :-)

FIT images are better than the old uImage format because they:

- allow for strong checksum algorithms like MD5, SHA1, ... (the plain
  CRC32 method is not good enough if you for example want to run
  software in a slot machine in Las Vegas).

- can combine multiple kernel images, device tree blobs and root file
  system images in arbitrary combinations; this allows for example
  for multibooting the same image on different boards by selecting
  the right DTB, for software updates with automatic fall-back, etc.

- can be extended to add new features, images types or whatever in a
  standard way, using a standard technology (device tree support)
  which is already present anyway, i. e. without additional code
  overhead.

> I do understand your use-case and what problem fit images solve for
> you.  However, from a "long term strategy" point of view it is a use
> case that I'm not interested in actively supporting for two reasons.
> The first is that I think it is in our best interest to encourage the
> mind set that the hardware description is separate from the operating
> system image, and so they should be stored and updated separately.  I

How do you boot systems over network, then? Normally you always
download only a single image file.

How do you explain this to system vendors? They have a very reasonable
request to offer only one image file to their customers.

> look at the unexpected ecosystem of distributions that has sprung up
> around wireless routers (ie OpenWRT and the like) and Linux cell
> phones (ie. Cyanogen Mod) where there is a huge range of hardware.
> The userspace can pretty much run on any of them excepting minor
> configuration changes.  The embedded space is becoming more PCs in

Right. So let's be able to provide kernel images that fit intot he
same pattern - that can be used on a range of platforms, for example
by embedding multiple DTBs.

Requesting that we manage a kernel mage plus a collection of DTBs and
that eveybody has to install the only working correctly combination
seems to be a bad idea to me.

> this regard, and I know that multiplatform is a big deal for some of
> the users.  I'm not interested in encouraging any behaviour that will
> scuttle deployment of multiplatform kernels.  (That being said, I'm

You misunderstand. FIT images do not scuttle multiplatform kernels.
Instead they support this much better, as they allow to bundle the
repsective DTBs into one image file.

> not going to actively sabotage people who want to put dtb sections
> into the kernel images either.  I understand that at times it is
> necessary, and there are numerous examples of this already in the
> kernel tree; specifically to support firmware that doesn't implement
> arch/powerpc's boot interface)

Even if the boot loader supports it, it is usually pretty benefical
(especially during development) if you can do this.

> I'd be okay (perhaps not happy, but okay) with merging fitImage and
> fitImage.initrd targets (no dtb).  I will resist merging fitImage.%
> and fitImage.initrd.% targets because I see that very much as a
> project specific deployment target and I'm not convinced yet that it
> the pattern is right or that it is even needed in the kernel at all.

Is this just your personal opinion, or do you think that this is
really what a majority of kernel developers and users are wanting?

Speaking for myself, I have to admit that I don't understand and don't
share this attitude.

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@denx.de
The optimum committee has no members.
                                                   - Norman Augustine

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Wolfgang Denk]

Dear Grant Likely,

In message <fa686aa41001022113o46bad9d2xf6c026f5fa3e8677@mail.gmail.com> you wrote:
>
> > Let's make this "uImage.old" (or "uImage.legacy" similar) and
> > "uImage", then.
> 
> I'm not interested in renaming the target name for the current uImage
> format.  I think it will cause too much breakage and pain to do so.

We did this before, and the argument then was "progress". Keep in mind
that the old arch/ppc uImage file is much more compatible to the
current arch/powerpc "cuImage" target than to the current "uImage".

I think the same should be done here.

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@denx.de
Any sufficiently advanced bug is indistinguishable from a feature.
                                                      - Rich Kulawiec

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Wolfgang Denk]

Dear Grant Likely,

In message <fa686aa41001022118w6b41765ld145c646bfca9423@mail.gmail.com> you wrote:
>
> As I said in a previous email; I understand the need for certain
> scenarios, but in the general case it is not the mode that I think
> should be encouraged.  I don't want to merge additional targets for
> .dtb embedded in the kernel image unless absolutely necessary, and I
> want developers to have the mindset that .dtbs should be separate from
> the kernel; and should be quasi-stable (or at least more stable than
> the kernel itself) because I think that multiplatform is important,
> and is going to become more important in the future.
> 
> So I don't want to support it by default; but OTOH, I'm not going to
> actively prevent embedded .dtb blobs either.

But by blocking the addition of such a make target you do actively
prevent this, don;t you?

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@denx.de
The years of peak mental activity are undoubtedly between the ages of
four and eighteen. At four we know all the questions, at eighteen all
the answers.

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Korsgaard]

>>>>> "Wolfgang" == Wolfgang Denk <wd@denx.de> writes:

Hi,

 >> No, that would break stuff for the existing users. The existing format
 >> make/file names shouldn't change.

 Wolfgang> Well, with this argument you can block all progress and freeze all
 Wolfgang> development to some ancient state.

We only break backwards compatibility when we have to. There's no
technical reason for renaming the existing make targets.

 >> The FIT images could be called fitimage or uImage.new or something.

 Wolfgang> I disagree. We want to make this the new default, so let's
 Wolfgang> use the default name for this, and continue to support he
 Wolfgang> legacy image format using another name.

 Wolfgang> Also, your approach does not scale. Assume we come up with an
 Wolfgang> even more advanced image format in the future - how should we
 Wolfgang> name it then?  "uImage.newer" ? "uImage.verynew" ?
 Wolfgang> "uImage.new2" ?

Hence fitimage. The next thing will presumably be called something else
again.

-- 
Bye, Peter Korsgaard

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

Hi Wolfgang,

> The "new" FIT image type should become the default, and old "legacy"
> images should only be generated upon special request (i. e. if some-
> one needs these for compatibility with an old, not yet FIT-aware
> version of the boot loader).

Agreed.

>> What do you think about changing the U-Boot documentation to rename
>> those 2 image types to:
>> 1 uImages
>> 2 FIT Images
>
> Let's make this "uImage.old" (or "uImage.legacy" similar) and
> "uImage", then.

I'm in favor of keeping the old uImage format/naming the same, and 
calling the new image format a FIT Image.  ie no mention of uImage for 
FIT images.

<snip>

>> uImages have to agree with U-Boot's header format defined in the U-Boot
>> source code, so the uImage name does make sense with respect to the
>> "legacy" uImages.
>
> Well, you can read "uImage" as "universal Image", which kind of fits
> the FIT approach :-)

I agree that the FIT image is a type of "universal Image", but I think 
"FIT image" is much more descriptive and accurate than "universal 
Image".  The FIT naming convention is designed to match device tree 
naming, which has lots of meaning.  eg:
   Flattened Device Tree (FDT) -> Flattened Image Tree (FIT)
   device tree source (.dts) -> image tree source (.its)
   device tree blob (.dtb) -> image tree blob (.itb)

>> My vote would be to make the Linux FIT target rule "fitImage" and then
>> update the U-Boot documentation to make obvious the differences between
>> uImages and FIT images.
>
> I think we should not try to support both legacy and FIT images on the
> same level - the idea is clearly that legacy images is the old, to be
> replaced format, while FIT images is the new, to be used as standard
> format.

Agreed.

In this sense I vote for using plain and simple "uImage" for
> the (new) standard format, and marking the old format by some ".old"
> or ".legacy" suffix.

I disagree here.  I don't think calling FIT images "FIT uImages" adds 
much value and it would add confusion as there are now multiple uImage 
formats that a user needs to keep straight.  Keeping the legacy uImage 
naming/format the same, and calling the new FIT images "fitImage" (or 
possibly itbImage to line up with the dtbImage target) would make more 
sense to me.  Is there a compelling reason to keep the uImage word 
connected to FIT images?

Best,
Peter

Re: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Peter Tyser]

<snip>

> Note that the FIT image can also be made to contain a number of DT
> blobs, and selection of a "board profile" then can be used to boot the
> very sane FIT image file on any of the supported boards - so FIT
> images inherently support multibooting.

I agree with Wolfgang.  Additionally, if a FIT image does contain a .dtb 
file, firmware can ignore it and load a different .dtb file.  So for the 
fitImage.<boardname> target you could think of it as including a 
"default/fallback" .dtb file, not a mandatory one.  So the FIT image 
could still be used as a multiplatform image even if it contained dtbs.

>>> I see your point.  The main goal of the patch was to introduce FIT image
>>> support as its the new, more flexible, "better", standard image format
>>> for U-Boot going forward.  Also, lots people aren't aware of FIT images
>>> and the cool stuff they can do with them, so what better way to get the
>>> word out than getting support for FIT images included in the kernel
>>> proper:)
>>
>> Define 'better'.  :-)
>
> FIT images are better than the old uImage format because they:
>
> - allow for strong checksum algorithms like MD5, SHA1, ... (the plain
>    CRC32 method is not good enough if you for example want to run
>    software in a slot machine in Las Vegas).
>
> - can combine multiple kernel images, device tree blobs and root file
>    system images in arbitrary combinations; this allows for example
>    for multibooting the same image on different boards by selecting
>    the right DTB, for software updates with automatic fall-back, etc.
>
> - can be extended to add new features, images types or whatever in a
>    standard way, using a standard technology (device tree support)
>    which is already present anyway, i. e. without additional code
>    overhead.

Other advantages of FIT images that I see day-to-day include:
- Adding meta-data such as timestamps and version information for each 
component of the FIT image.  Its great to be able to easily display the 
contents of a FIT image to determine which kernel versions it contains, etc.

- Embed multiple OS/dtb images in one FIT image.  As a board vendor its 
nice to give a customer 1 image that has example dtb(s) and Linux, 
VxWorks, QNX, diagnostic, etc kernels.  They can boot a number of OSes 
on a number of different boards with 1 image.

- You can extract the images contained in a FIT image using 'dtc' to 
convert the FIT image to a ".dts" file that has the raw image contents. 
  Other image formats are more difficult to extract contents from.

<snip>

>> I'd be okay (perhaps not happy, but okay) with merging fitImage and
>> fitImage.initrd targets (no dtb).  I will resist merging fitImage.%
>> and fitImage.initrd.% targets because I see that very much as a
>> project specific deployment target and I'm not convinced yet that it
>> the pattern is right or that it is even needed in the kernel at all.
>
> Is this just your personal opinion, or do you think that this is
> really what a majority of kernel developers and users are wanting?
>
> Speaking for myself, I have to admit that I don't understand and don't
> share this attitude.

I agree with Wolfgang that many people would find the combined 
kernel/dtb/ramfs useful, but understand Grant's reservations.  Assuming 
I rework the patch to include a "fitImage" (no dtb) target, for the 
users that basic multiplatform images are important to, they could build 
this kernel-only FIT image.  For people such as Wolfgang, Peter, and 
myself who would like to bundle a kernel + dtb(s), we could use the 
fitImage.<boardname> target.  Wouldn't both parties be happy then?  I 
could make the FIT documentation explain the benefits of multiplatform 
images or warn about the combined kernel/dtb FIT images if that made a 
difference too.

Best,
Peter

Re: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Grant Likely]

On Sun, Jan 3, 2010 at 3:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa41001022108i92596d6qdf2da0e24c34767e@mail.gmail.com> y=
ou wrote:
>
> Note that the FIT image can also be made to contain a number of DT
> blobs, and selection of a "board profile" then can be used to boot the
> very sane FIT image file on any of the supported boards - so FIT
> images inherently support multibooting.
>> > I see your point. =A0The main goal of the patch was to introduce FIT i=
mage
>> > support as its the new, more flexible, "better", standard image format
>> > for U-Boot going forward. =A0Also, lots people aren't aware of FIT ima=
ges
>> > and the cool stuff they can do with them, so what better way to get th=
e
>> > word out than getting support for FIT images included in the kernel
>> > proper:)
>>
>> Define 'better'. =A0:-)
>
> FIT images are better than the old uImage format because they:
>
> - allow for strong checksum algorithms like MD5, SHA1, ... (the plain
> =A0CRC32 method is not good enough if you for example want to run
> =A0software in a slot machine in Las Vegas).
>
> - can combine multiple kernel images, device tree blobs and root file
> =A0system images in arbitrary combinations; this allows for example
> =A0for multibooting the same image on different boards by selecting
> =A0the right DTB, for software updates with automatic fall-back, etc.
>
> - can be extended to add new features, images types or whatever in a
> =A0standard way, using a standard technology (device tree support)
> =A0which is already present anyway, i. e. without additional code
> =A0overhead.

That's a lot of variability.  More on this at the end of my email...

>> this regard, and I know that multiplatform is a big deal for some of
>> the users. =A0I'm not interested in encouraging any behaviour that will
>> scuttle deployment of multiplatform kernels. =A0(That being said, I'm
>
> You misunderstand. FIT images do not scuttle multiplatform kernels.
> Instead they support this much better, as they allow to bundle the
> repsective DTBs into one image file.

I believe I do understand.  The problem with this model is that it
makes the assumption that the kernel image builder has access to ahead
of time the full set of bootable platforms.  That assumption doesn't
hold anymore for a lot of markets where many vendors use the same SoC
in slightly different ways.  I think hardware vendors should be
encouraged to manage dtb blobs separately from the kernel so that we
can get out of the current paradigm of only supporting boards we know
about.

Practical example: Ubuntu on ARM netbooks.  Ubuntu is really not
interested in generating new kernel images every time a vendor
releases a new or modified piece of hardware.

If a vendor still decides that they want a kernel+dtb image then fine;
but I don't think it does the Linux ecosystem any favors to make it
the default choice.

>> not going to actively sabotage people who want to put dtb sections
>> into the kernel images either. =A0I understand that at times it is
>> necessary, and there are numerous examples of this already in the
>> kernel tree; specifically to support firmware that doesn't implement
>> arch/powerpc's boot interface)
>
> Even if the boot loader supports it, it is usually pretty benefical
> (especially during development) if you can do this.

Nothing prevents using a custom install script to wrap up a custom fit
image when copying it into the tftp directory (or wherever).

>> I'd be okay (perhaps not happy, but okay) with merging fitImage and
>> fitImage.initrd targets (no dtb). =A0I will resist merging fitImage.%
>> and fitImage.initrd.% targets because I see that very much as a
>> project specific deployment target and I'm not convinced yet that it
>> the pattern is right or that it is even needed in the kernel at all.
>
> Is this just your personal opinion, or do you think that this is
> really what a majority of kernel developers and users are wanting?

I've stated my opinion, my reasons for it, and what I'm willing to
merge.  However, I'm not the only PowerPC maintainer and the others
may disagree.  While I don't particularly like the fit image format,
it won't stop me from merging fitImage and fitImage.initrd patches.

I will not merge fitImage.% and fitImage.initrd.% targets because of
the variability I commented on above.  As you mentioned, there is a
huge amount of flexability in what sections are placed into a fit
image, such as carrying multiple dtb blobs.  However, a fitImage.%
pattern can only express a very specific subset (one kernel image +
one dtb image).  I do not want to codify a particular pattern into the
build system when it seems quite apparent that make targets are
nowhere near expressive enough to do what you're talking about with
fit images.  As is, the targets with embedded .dtbs are already rife
with special cases and other nastiness.

So, I choose to punt it out of the kernel.  If you want to build fit
images beyond just containing an kernel image, then use a custom
install or postprocessing script to assemble the vmlinux, dtb and
initrd building blocks into the image you need.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Grant Likely]

On Sun, Jan 3, 2010 at 7:27 AM, Peter Korsgaard <jacmet@sunsite.dk> wrote:
>>>>>> "Wolfgang" =3D=3D Wolfgang Denk <wd@denx.de> writes:
>
> Hi,
>
> =A0>> No, that would break stuff for the existing users. The existing for=
mat
> =A0>> make/file names shouldn't change.
>
> =A0Wolfgang> Well, with this argument you can block all progress and free=
ze all
> =A0Wolfgang> development to some ancient state.
>
> We only break backwards compatibility when we have to. There's no
> technical reason for renaming the existing make targets.

I agree, and I feel pretty strongly on this point.  The meaning of the
uImage target should not change.  The new format must use a different
target name.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.