Re: [RFC] New target 'cuImage' - compatibility uImage

Re: [RFC] New target 'cuImage' - compatibility uImage

[Milton Miller]

On Thu Aug  3 2006 10:30:13 AM CDT, Matthew McClintock wrote:
> On Thu, 2006-08-03 at 04:47 -0700, Li Yang-r58472 wrote:
> > If my understanding to Matt's idea is correct, it will be a good way,
> > IMHO.  How about use the naming of uwImage(U-boot Wrapped Image) or
> > utImage(u-boot device-Tree Image). 
> 
> I am completely open to a better name. Anyone else care to share their
> opinion?

Do newer versions of uboot support device tree kernels directly?  If not, then
I would say make this uimage.  Otherwise,  I would say uzImage unless we
decide to call the wrapper that adds the tree something else, like uImage.dt.

Or maybe its uImage and config vars say which it is.

milton

Re: [RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

On Thu, 2006-08-03 at 13:17 -0500, Milton Miller wrote:
> On Thu Aug  3 2006 10:30:13 AM CDT, Matthew McClintock wrote:
> > On Thu, 2006-08-03 at 04:47 -0700, Li Yang-r58472 wrote:
> > > If my understanding to Matt's idea is correct, it will be a good way,
> > > IMHO.  How about use the naming of uwImage(U-boot Wrapped Image) or
> > > utImage(u-boot device-Tree Image). 
> > 
> > I am completely open to a better name. Anyone else care to share their
> > opinion?
> 
> Do newer versions of uboot support device tree kernels directly?  If not, then
> I would say make this uimage.  Otherwise,  I would say uzImage unless we
> decide to call the wrapper that adds the tree something else, like uImage.dt.
> 
> Or maybe its uImage and config vars say which it is.
> 

There is an unofficial way to boot device tree kernels directly from
U-Boot. There was an older method that has been in U-Boot a long time
(and still is), however I just submitted a series of patches which
updates that method.

As far as I know the new method is liked better by Wolfgang, so maybe he
will start accepted board patches based on my work? Either way, for
boards with newer U-Boots (at some point) will not boot using this
method.

Wolfgang, care to comment?

-Matthew

Re: [RFC] New target 'cuImage' - compatibility uImage

[Milton Miller]

On Wed Aug  2 2006 03:59:06 PM CDT, Matthew McClintock wrote:
> The following is a patch which creates a new target called 'cuImage'. It
> is designed to correctly package the kernel along with the
> 'arch/powerpc/boot' wrapper code into a uImage to be loaded and started
> by U-Boot.
> 
> The purpose of this target is to allow boards with older versions of
> U-Boot to utilize the 'bootm' command within U-Boot to run new powerpc
> kernels. 
...

> And the new cuImage will look like this:
> 
[add 'ompressed' uimage header and use uncompressed kernel]

Wolfgang already asked why you were using the uncompressed
kernel, and whart you meant by compressed uimage header.

Please describe when this would be used vs the existing uimage.
Can newer uboot boot the current uimage kernels?

> 
> -Matthew


I'm going to switch styles here during the patch.  I'll mark my comments
with  leading ; on the line.


diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 13e583f..2d2c39a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -96,11 +96,21 @@ config GENERIC_TBSYNC
 	default n
 
 config DEFAULT_UIMAGE
-	bool
+	bool "Set uImage to be the default build target"
 	help
 	  Used to allow a board to specify it wants a uImage built by default
 	default n

; If we are going to do this, it seems like this should be part of a choice or multiselect.

+config UIMAGELOADADDR
+	hex "Set the uImage load address"
+	default 400000
+	depends on DEFAULT_UIMAGE 
+
+config UIMAGEENTRY
+	hex "Set the uImage entry address"
+	default 400010
+

; Make these questions, not the variables, the if clause to avoid the ifdef in the makefile.
:
: Is the entry point independent of the load address?
:

	depends on DEFAULT_UIMAGE 
+
 menu "Processor support"compatibility 
 choice
 	prompt "Processor Type"
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 01667d1..eefbe16 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -141,12 +141,13 @@ # Default to zImage, override when neede
 defaultimage-y			:= zImage
 defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
 defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
+defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage

; We need both?

 KBUILD_IMAGE := $(defaultimage-y)
 all: $(KBUILD_IMAGE)
 
 CPPFLAGS_vmlinux.lds	:= -Upowerpc
 
-BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin
+BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin cuImage
 
 PHONY += $(BOOT_TARGETS)
 
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index daad857..72e8ad8 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -23,7 +23,8 @@ #	in the toplevel makefile.
 
 HOSTCC		:= gcc
 BOOTCFLAGS	:= $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
-		   $(shell $(CROSS32CC) -print-file-name=include) -fPIC
+		   $(shell $(CROSS32CC) -print-file-name=include) -fPIC \
+		   -fno-schedule-insns -fno-schedule-insns2 -fno-inline

; Where did this come from? Seperate patch???


 BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
 OBJCOPYFLAGS    := contents,alloc,load,readonly,data
 OBJCOPY_COFF_ARGS := -O aixcoff-rs6000 --set-start 0x500000
@@ -198,10 +199,18 @@ cmd_mygzip = gzip -f -9 < $< > $@.$$$$ &
 quiet_cmd_objbin = OBJCOPY $@
       cmd_objbin = $(OBJCOPY) -O binary $< $@
 
+ifndef CONFIG_UIMAGELOADADDR
+CONFIG_UIMAGELOADADDR = 00000000
+endif
+
+ifndef CONFIG_UIMAGEENTRY
+CONFIG_UIMAGEENTRY = 00000000
+endif
+

; See comments in Kconfig  Or, we can leave them undefied if we aren't making this

 quiet_cmd_uimage = UIMAGE $@
       cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc -O linux -T kernel
\
-               -C gzip -a 00000000 -e 00000000 -n
'Linux-$(KERNELRELEASE)' \
-               -d $< $@
+	-C gzip -a $(CONFIG_UIMAGELOADADDR) -e $(CONFIG_UIMAGEENTRY)  \
+	-n 'Linux-$(KERNELRELEASE)' -d $< $@
 
 MKIMAGE		:= $(srctree)/scripts/mkuboot.sh
 targets		+= uImage
@@ -223,3 +232,40 @@ install: $(CONFIGURE) $(BOOTIMAGE)
 	sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux
System.map "$(INSTALL_PATH)" "$(BOOTIMAGE)"
 
 clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip)
+
+#-----------------------------------------------------------
+# build compatiblity u-boot images
+#-----------------------------------------------------------
+
+targets += cuImage
+
+quiet_cmd_addsection_cuimage = ADDSEC  $@
+      cmd_addsection_cuimage = $(CROSS32OBJCOPY) $@ \
+		--add-section=.kernel:vmlinux.elf=vmlinux \
+		--set-section-flags=.kernel:vmlinux.elf=$(OBJCOPYFLAGS)
+
+$(obj)/kernel-compat.c:
+	@touch $@
+
+$(obj)/kernel-compat.o: $(obj)/kernel-compat.c vmlinux 
+	$(call if_changed_dep,bootcc)
+	$(call cmd,addsection_cuimage)
+
+$(obj)/vmlinux-compat.elf: $(obj-boot) $(obj)/kernel-compat.o
+	$(call cmd,bootld,$(obj-boot) $(obj)/kernel-compat.o,cuImage.lds)
+
+$(obj)/vmlinux-compat.bin: $(obj)/vmlinux-compat.elf
+	$(call if_changed,objbin)
+
+$(obj)/vmlinux-compat.gz: $(obj)/vmlinux-compat.bin
+	$(call if_changed,mygzip)
+
+$(obj)/cuImage: $(obj)/vmlinux-compat.gz $(obj-boot)
+	$(Q)rm -f $@
+	$(call cmd,uimage)
+	@echo -n '  Image: $@ '
+	@if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
+
+clean-files += vmlinux-compat.elf vmlinux-compat.bin vmlinux-compat.gz
cuImage
+
+

[RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

Hi all,

The following is a patch which creates a new target called 'cuImage'. It
is designed to correctly package the kernel along with the
'arch/powerpc/boot' wrapper code into a uImage to be loaded and started
by U-Boot.

The purpose of this target is to allow boards with older versions of
U-Boot to utilize the 'bootm' command within U-Boot to run new powerpc
kernels. The bootwrapper will begin execution and can correctly setup a
flat device tree based on values passed in the bd_t structure, something
old versions of U-Boot are not capable of.

One might ask why not just use the 'bootelf' command in u-boot. Well,
not all boards have that option compiled in, and some other boards might
not even have access to the console. Also, the bd_t structure is not
passed from U-Boot when using the bootelf command so we would have no
method to correctly fill in values in the device tree. This would
theoretically allow an old board to start a new kernel without access to
the console if required.

Currently the zImage looks like this:

---------------------------------
- 	_start			-
-	boot wrapper code	-
- ----------------------------- -
- -	device tree	      - -
- ----------------------------- -
- ----------------------------- -
- - 			      - -
- - 	compressed	      - -
- - 	kernel image	      - -
- -			      - -
- ----------------------------- -
---------------------------------

And the new cuImage will look like this:

-------------------------------------
-	compressed uImage	  - -
- ------------------------------- - -
- - 	_start			- - -
- -	boot wrapper code	- - -
- - ----------------------------- - -
- - -	device tree	      	- - -
- - ----------------------------- - -
- - ----------------------------- - -
- - - 			      	- - -
- - - 	UNcompressed	      	- - -
- - - 	kernel image	      	- - -
- - -			      	- - -
- - ----------------------------- - -
- --------------------------------- -
-------------------------------------

-Matthew

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 13e583f..2d2c39a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -96,11 +96,21 @@ config GENERIC_TBSYNC
 	default n
 
 config DEFAULT_UIMAGE
-	bool
+	bool "Set uImage to be the default build target"
 	help
 	  Used to allow a board to specify it wants a uImage built by default
 	default n
 
+config UIMAGELOADADDR
+	hex "Set the uImage load address"
+	default 400000
+	depends on DEFAULT_UIMAGE 
+
+config UIMAGEENTRY
+	hex "Set the uImage entry address"
+	default 400010
+	depends on DEFAULT_UIMAGE 
+
 menu "Processor support"compatibility 
 choice
 	prompt "Processor Type"
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 01667d1..eefbe16 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -141,12 +141,13 @@ # Default to zImage, override when neede
 defaultimage-y			:= zImage
 defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
 defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
+defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage
 KBUILD_IMAGE := $(defaultimage-y)
 all: $(KBUILD_IMAGE)
 
 CPPFLAGS_vmlinux.lds	:= -Upowerpc
 
-BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin
+BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin cuImage
 
 PHONY += $(BOOT_TARGETS)
 
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index daad857..72e8ad8 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -23,7 +23,8 @@ #	in the toplevel makefile.
 
 HOSTCC		:= gcc
 BOOTCFLAGS	:= $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
-		   $(shell $(CROSS32CC) -print-file-name=include) -fPIC
+		   $(shell $(CROSS32CC) -print-file-name=include) -fPIC \
+		   -fno-schedule-insns -fno-schedule-insns2 -fno-inline
 BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
 OBJCOPYFLAGS    := contents,alloc,load,readonly,data
 OBJCOPY_COFF_ARGS := -O aixcoff-rs6000 --set-start 0x500000
@@ -198,10 +199,18 @@ cmd_mygzip = gzip -f -9 < $< > $@.$$$$ &
 quiet_cmd_objbin = OBJCOPY $@
       cmd_objbin = $(OBJCOPY) -O binary $< $@
 
+ifndef CONFIG_UIMAGELOADADDR
+CONFIG_UIMAGELOADADDR = 00000000
+endif
+
+ifndef CONFIG_UIMAGEENTRY
+CONFIG_UIMAGEENTRY = 00000000
+endif
+
 quiet_cmd_uimage = UIMAGE $@
       cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc -O linux -T kernel
\
-               -C gzip -a 00000000 -e 00000000 -n
'Linux-$(KERNELRELEASE)' \
-               -d $< $@
+	-C gzip -a $(CONFIG_UIMAGELOADADDR) -e $(CONFIG_UIMAGEENTRY)  \
+	-n 'Linux-$(KERNELRELEASE)' -d $< $@
 
 MKIMAGE		:= $(srctree)/scripts/mkuboot.sh
 targets		+= uImage
@@ -223,3 +232,40 @@ install: $(CONFIGURE) $(BOOTIMAGE)
 	sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux
System.map "$(INSTALL_PATH)" "$(BOOTIMAGE)"
 
 clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip)
+
+#-----------------------------------------------------------
+# build compatiblity u-boot images
+#-----------------------------------------------------------
+
+targets += cuImage
+
+quiet_cmd_addsection_cuimage = ADDSEC  $@
+      cmd_addsection_cuimage = $(CROSS32OBJCOPY) $@ \
+		--add-section=.kernel:vmlinux.elf=vmlinux \
+		--set-section-flags=.kernel:vmlinux.elf=$(OBJCOPYFLAGS)
+
+$(obj)/kernel-compat.c:
+	@touch $@
+
+$(obj)/kernel-compat.o: $(obj)/kernel-compat.c vmlinux 
+	$(call if_changed_dep,bootcc)
+	$(call cmd,addsection_cuimage)
+
+$(obj)/vmlinux-compat.elf: $(obj-boot) $(obj)/kernel-compat.o
+	$(call cmd,bootld,$(obj-boot) $(obj)/kernel-compat.o,cuImage.lds)
+
+$(obj)/vmlinux-compat.bin: $(obj)/vmlinux-compat.elf
+	$(call if_changed,objbin)
+
+$(obj)/vmlinux-compat.gz: $(obj)/vmlinux-compat.bin
+	$(call if_changed,mygzip)
+
+$(obj)/cuImage: $(obj)/vmlinux-compat.gz $(obj-boot)
+	$(Q)rm -f $@
+	$(call cmd,uimage)
+	@echo -n '  Image: $@ '
+	@if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
+
+clean-files += vmlinux-compat.elf vmlinux-compat.bin vmlinux-compat.gz
cuImage
+
+

Re: [RFC] New target 'cuImage' - compatibility uImage

[Wolfgang Denk]

In message <1154552346.5550.51.camel@localhost> you wrote:
> 
> And the new cuImage will look like this:
> 
> -------------------------------------
> -	compressed uImage	  - -
> - ------------------------------- - -
> - - 	_start			- - -
> - -	boot wrapper code	- - -
> - - ----------------------------- - -
> - - -	device tree	      	- - -
> - - ----------------------------- - -
> - - ----------------------------- - -
> - - - 			      	- - -
> - - - 	UNcompressed	      	- - -
> - - - 	kernel image	      	- - -
> - - -			      	- - -
> - - ----------------------------- - -
> - --------------------------------- -
> -------------------------------------

Please explain.

In my understanding, an "uImage" file is a  image  consisting  of  an
U-Boot  header (64 bytes) followed by an (compressed or uncompressed)
Linux kernel image.

So what do you mean by "compressed uImage"? If you take  an  "uImage"
file  according  to  above definition and compress it, it will not be
recognized by U-Boot.

And why do you need a second, "UNcompressed  kernel  image"  in  your
setup?  I  must  be missing something, because including *two* kernel
images makes no sense to me, and I don't  understand  why  you  would
want to insist of an "UNcompressed" image...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
1st Old Man:  Gee, its windy today.
2nd Old Man:  No it's not... it's Thursday.
3rd Old Man:  Yeh, me too.  Let's go for a beer.

RE: [RFC] New target 'cuImage' - compatibility uImage

[Li Yang-r58472]

> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of
> Wolfgang Denk
> Sent: Thursday, August 03, 2006 6:33 AM
> To: McClintock Matthew-R56630
> Cc: linuxppc-dev
> Subject: Re: [RFC] New target 'cuImage' - compatibility uImage
>=20
> In message <1154552346.5550.51.camel@localhost> you wrote:
> >
> > And the new cuImage will look like this:
> >
> > -------------------------------------
> > -	compressed uImage	  - -
> > - ------------------------------- - -
> > - - 	_start			- - -
> > - -	boot wrapper code	- - -
> > - - ----------------------------- - -
> > - - -	device tree	      	- - -
> > - - ----------------------------- - -
> > - - ----------------------------- - -
> > - - - 			      	- - -
> > - - - 	UNcompressed	      	- - -
> > - - - 	kernel image	      	- - -
> > - - -			      	- - -
> > - - ----------------------------- - -
> > - --------------------------------- -
> > -------------------------------------
>=20
> Please explain.
>=20
> In my understanding, an "uImage" file is a  image  consisting  of  an
> U-Boot  header (64 bytes) followed by an (compressed or uncompressed)
> Linux kernel image.
>=20
> So what do you mean by "compressed uImage"? If you take  an  "uImage"
> file  according  to  above definition and compress it, it will not be
> recognized by U-Boot.

I don't know if my understanding is exactly what Matt means.  But the
compressed uImage seems to be (u-boot header + compress(wrapper + FDT +
kernel image)), instead of original (u-boot header + compress(kernel
image)).  A better naming probably is needed to prevent misleading.

>=20
> And why do you need a second, "UNcompressed  kernel  image"  in  your
> setup?  I  must  be missing something, because including *two* kernel
> images makes no sense to me, and I don't  understand  why  you  would
> want to insist of an "UNcompressed" image...
>=20
> Best regards,
>=20
> Wolfgang Denk

Re: [RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

On Thu, 2006-08-03 at 00:33 +0200, Wolfgang Denk wrote:
> 
> In my understanding, an "uImage" file is a  image  consisting  of  an
> U-Boot  header (64 bytes) followed by an (compressed or uncompressed)
> Linux kernel image.

Yes

> 
> So what do you mean by "compressed uImage"? If you take  an  "uImage"
> file  according  to  above definition and compress it, it will not be
> recognized by U-Boot.

I mean that the data contained within the uImage is compressed. In this
case where the uImage data is compressed I choose to skip compressing
the kernel section in the zImage (because have it compressed twice was
wasteful)

> 
> And why do you need a second, "UNcompressed  kernel  image"  in  your
> setup?  I  must  be missing something, because including *two* kernel
> images makes no sense to me, and I don't  understand  why  you  would
> want to insist of an "UNcompressed" image...

So to clarify. The current method has a zImage with a compressed kernel
section where the actual kernel lives. The zImage uncompressed this code
to the kernel load address. The 'cuImage' would be packaged in a uImage
with the entire zImage compressed, except in this case the kernel
section would not be compressed (to avoid have a compressed image within
a compressed image)

-Matthew

Re: [RFC] New target 'cuImage' - compatibility uImage

[Li Yang]

On 8/3/06, Matthew McClintock <msm@freescale.com> wrote:
> On Thu, 2006-08-03 at 00:33 +0200, Wolfgang Denk wrote:
> >
> > In my understanding, an "uImage" file is a  image  consisting  of  an
> > U-Boot  header (64 bytes) followed by an (compressed or uncompressed)
> > Linux kernel image.
>
> Yes

If U-boot supports uncompressed kernel image in uImage, I think it
will be better to use this scheme:

u-boot header + wrapper + FDT + compressed kernel image

As kernel image will be uncompressed to its loading address directly.
While in your proposal, it needs to be moved one more time.

>
> >
> > So what do you mean by "compressed uImage"? If you take  an  "uImage"
> > file  according  to  above definition and compress it, it will not be
> > recognized by U-Boot.
>
> I mean that the data contained within the uImage is compressed. In this
> case where the uImage data is compressed I choose to skip compressing
> the kernel section in the zImage (because have it compressed twice was
> wasteful)
>
> >
> > And why do you need a second, "UNcompressed  kernel  image"  in  your
> > setup?  I  must  be missing something, because including *two* kernel
> > images makes no sense to me, and I don't  understand  why  you  would
> > want to insist of an "UNcompressed" image...
>
> So to clarify. The current method has a zImage with a compressed kernel
> section where the actual kernel lives. The zImage uncompressed this code
> to the kernel load address. The 'cuImage' would be packaged in a uImage
> with the entire zImage compressed, except in this case the kernel
> section would not be compressed (to avoid have a compressed image within
> a compressed image)
>
> -Matthew
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>

Re: [RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

On Thu, 2006-08-03 at 23:56 +0800, Li Yang wrote:
> 
> If U-boot supports uncompressed kernel image in uImage, I think it
> will be better to use this scheme:
> 
> u-boot header + wrapper + FDT + compressed kernel image
> 
> As kernel image will be uncompressed to its loading address directly.
> While in your proposal, it needs to be moved one more time.
> 

This is an option. But, I do not see a reason why you would not still
opt to compress everything. Especially since it is already working.
Comments anyone?

-Matthew

Re: [RFC] New target 'cuImage' - compatibility uImage

[Li Yang]

On 8/4/06, Matthew McClintock <msm@freescale.com> wrote:
> On Thu, 2006-08-03 at 23:56 +0800, Li Yang wrote:
> >
> > If U-boot supports uncompressed kernel image in uImage, I think it
> > will be better to use this scheme:
> >
> > u-boot header + wrapper + FDT + compressed kernel image
> >
> > As kernel image will be uncompressed to its loading address directly.
> > While in your proposal, it needs to be moved one more time.
> >
>
> This is an option. But, I do not see a reason why you would not still
> opt to compress everything. Especially since it is already working.
> Comments anyone?

Though it will need more space, the increase won't be too much as
wrapper and FDT should be very small.  The benefit is that kernel can
be extract directly to it's destination(address 0), rather than
extract to another place and then move it there.  A classical
time/space tradeoff.

>
> -Matthew

Re: [RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

On Fri, 2006-08-04 at 00:17 +0800, Li Yang wrote:
> 
> Though it will need more space, the increase won't be too much as
> wrapper and FDT should be very small.  The benefit is that kernel can
> be extract directly to it's destination(address 0), rather than
> extract to another place and then move it there.  A classical
> time/space tradeoff.
> 

I'm not sure that is correct. Let me walk through the steps to verify.

1) Load cuImage at a load address 
2) Extract zImage at an address and begin execution
3) Copy kernel to load address and fixup DTB, etc.
4) Start kernel execution

versus...

1) Load cuImage at a load address
2) Copy zImage to an address and begin execution
3) Extract kernel to load address and fixup DTB, etc.
4) Start kernel execution

There will always be that extra copy in there vs. just running the
zImage itself. This is to maintain compatibility with older u-boots,
which is the main point of this target.

Am I missing something here?

-Matthew

Re: [RFC] New target 'cuImage' - compatibility uImage

[Li Yang]

On 8/4/06, Matthew McClintock <msm@freescale.com> wrote:
> On Fri, 2006-08-04 at 00:17 +0800, Li Yang wrote:
> >
> > Though it will need more space, the increase won't be too much as
> > wrapper and FDT should be very small.  The benefit is that kernel can
> > be extract directly to it's destination(address 0), rather than
> > extract to another place and then move it there.  A classical
> > time/space tradeoff.
> >
>
> I'm not sure that is correct. Let me walk through the steps to verify.
>
> 1) Load cuImage at a load address
> 2) Extract zImage at an address and begin execution
> 3) Copy kernel to load address and fixup DTB, etc.
> 4) Start kernel execution
>
> versus...
>
> 1) Load cuImage at a load address
> 2) Copy zImage to an address and begin execution

Don't know if it's possible to by-pass this by setting in u-boot
header.  If not, please ignore my suggestion.

- Leo
> 3) Extract kernel to load address and fixup DTB, etc.
> 4) Start kernel execution
>
> There will always be that extra copy in there vs. just running the
> zImage itself. This is to maintain compatibility with older u-boots,
> which is the main point of this target.
>
> Am I missing something here?
>
> -Matthew
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>

Re: [RFC] New target 'cuImage' - compatibility uImage

[Wolfgang Denk]

In message <1154622246.5094.18.camel@localhost> you wrote:
>
> I'm not sure that is correct. Let me walk through the steps to verify.
> 
> 1) Load cuImage at a load address 
> 2) Extract zImage at an address and begin execution
> 3) Copy kernel to load address and fixup DTB, etc.
> 4) Start kernel execution
> 
> versus...
> 
> 1) Load cuImage at a load address
> 2) Copy zImage to an address and begin execution
> 3) Extract kernel to load address and fixup DTB, etc.
> 4) Start kernel execution

Both approaches seem broken to me.

You should make sure that  your  bootstrap  code  comes  *after*  the
kernel  image,  so  you  can  load  the  whole blob at address 0x0000
(mkimage option "-a 0") while starting  it  at  the  bootstrap  entry
point (mkimage option "-e <your_address>").

This way U-Boot will load (and if necessary  uncompress)  the  kernel
image plus your attached bootstrap code to it's normal start address.
Then  it starts your bootstrap code which can fixup DTB and then just
start the kernel.

Please avoid any aditional memory copy. It's not necessary.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"In Christianity neither morality nor religion come into contact with
reality at any point."                          - Friedrich Nietzsche

Re: [RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

On Thu, 2006-08-03 at 22:14 +0200, Wolfgang Denk wrote:
> Both approaches seem broken to me.
> 
> You should make sure that  your  bootstrap  code  comes  *after*  the
> kernel  image,  so  you  can  load  the  whole blob at address 0x0000
> (mkimage option "-a 0") while starting  it  at  the  bootstrap  entry
> point (mkimage option "-e <your_address>").

However, currently the zImage has an elfheader which will come before
the code. But, since we are making a new target we don't actually need
to preserve this. I like this idea. I will look into it further.

> 
> This way U-Boot will load (and if necessary  uncompress)  the  kernel
> image plus your attached bootstrap code to it's normal start address.
> Then  it starts your bootstrap code which can fixup DTB and then just
> start the kernel.
> 

We do not need to worry about this with cuImage because the kernel
section will not be compressed. If compression is desired it will be
done at the U-Boot level (were U-Boot would do the uncompressing).

> Please avoid any aditional memory copy. It's not necessary.
> 

Agreed.

-Matthew

Re: [RFC] New target 'cuImage' - compatibility uImage

[Wolfgang Denk]

In message <1154636438.5094.45.camel@localhost> you wrote:
> 
> However, currently the zImage has an elfheader which will come before

May it have whatever it wants. It's irrelevant.

WE DO NOT USE zImage FILES FOR U-BOOT.

> > This way U-Boot will load (and if necessary  uncompress)  the  kernel
> > image plus your attached bootstrap code to it's normal start address.
> > Then  it starts your bootstrap code which can fixup DTB and then just
> > start the kernel.
> > 
> 
> We do not need to worry about this with cuImage because the kernel
> section will not be compressed. If compression is desired it will be
> done at the U-Boot level (were U-Boot would do the uncompressing).

Yes,  we  do  need  to  care  about  this.  A  useless  copy  of  the
uncompressed  kernel  image  is  just  a  waste  of boot time. Not to
mention that you have to copy your bootstrapo loader out of  the  way
before it gets overwritten.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is research but a blind date with knowledge?      -- Will Harvey

Re: [RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

On Thu, 2006-08-03 at 22:25 +0200, Wolfgang Denk wrote:
> In message <1154636438.5094.45.camel@localhost> you wrote:
> > 
> > However, currently the zImage has an elfheader which will come before
> 
> May it have whatever it wants. It's irrelevant.
> 
> WE DO NOT USE zImage FILES FOR U-BOOT.

I've explained this well enough at this point, if you don't want to ask
more questions to figure it out then I can not really help anymore.

> 
> > > This way U-Boot will load (and if necessary  uncompress)  the  kernel
> > > image plus your attached bootstrap code to it's normal start address.
> > > Then  it starts your bootstrap code which can fixup DTB and then just
> > > start the kernel.
> > > 
> > 
> > We do not need to worry about this with cuImage because the kernel
> > section will not be compressed. If compression is desired it will be
> > done at the U-Boot level (were U-Boot would do the uncompressing).
> 
> Yes,  we  do  need  to  care  about  this.  A  useless  copy  of  the
> uncompressed  kernel  image  is  just  a  waste  of boot time. Not to
> mention that you have to copy your bootstrapo loader out of  the  way
> before it gets overwritten.

I agree. Your previous advice is something I am going to try to reduce
memory copying. Keeping the bootloader after the kernel image should
prevent any overwritting problems, as you said.

-Matthew

Re: [RFC] New target 'cuImage' - compatibility uImage

[Wolfgang Denk]

In message <a0bc9bf80608030917y7fde2b75n6719dc675cad8cfe@mail.gmail.com> you wrote:
>
> Though it will need more space, the increase won't be too much as
> wrapper and FDT should be very small.  The benefit is that kernel can
> be extract directly to it's destination(address 0), rather than
> extract to another place and then move it there.  A classical
> time/space tradeoff.

You probably cannot expect a perfect solution when  retrofitting  new
features  into  an  old  system  (this  we should keep in mind: we're
talking about old U-Boot versions only, not  about  current  versions
which will support DT).


BTW: Another option is using U-Boot's multifile image format...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
That said, there may be good reasons for what you did beyond obsequi-
ous sycophantic parody. Perhaps you might be so kind as to elucidate.
         -- Tom Christiansen in <5ldjbm$jtk$1@csnews.cs.colorado.edu>

Re: [RFC] New target 'cuImage' - compatibility uImage

[Mark A. Greer]

On Thu, Aug 03, 2006 at 11:02:14AM -0500, Matthew McClintock wrote:
> On Thu, 2006-08-03 at 23:56 +0800, Li Yang wrote:
> > 
> > If U-boot supports uncompressed kernel image in uImage, I think it
> > will be better to use this scheme:
> > 
> > u-boot header + wrapper + FDT + compressed kernel image
> > 
> > As kernel image will be uncompressed to its loading address directly.
> > While in your proposal, it needs to be moved one more time.
> > 
> 
> This is an option. But, I do not see a reason why you would not still
> opt to compress everything. Especially since it is already working.
> Comments anyone?

Yes...sort of.  I believe that one of the goals is to be able to tack
an fdt onto a zImage/uImage/whatever long after that image has been
built.  That would be simpler if the fdt wasn't compressed. 

A proper tool can handle this, of course, but it would be simpler and
not a huge waste of space to keep the fdt uncompressed.

But, as long as we have tools to view and modify the fdt that in the
clump of bits, I don't really care that much.

Mark

Re: [RFC] New target 'cuImage' - compatibility uImage

[Wolfgang Denk]

In message <a0bc9bf80608030856p45870487of2646c4f9393869b@mail.gmail.com> you wrote:
>
> If U-boot supports uncompressed kernel image in uImage, I think it
> will be better to use this scheme:
> 
> u-boot header + wrapper + FDT + compressed kernel image

No, this must not be made the only way to build images. It must  also
possible to use uncompressed kernel images.

> As kernel image will be uncompressed to its loading address directly.

Only if it was compressed. This is NOT mandatory.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
You don't have to worry about me. I might have been born yesterday...
but I stayed up all night.

Re: [RFC] New target 'cuImage' - compatibility uImage

[Wolfgang Denk]

In message <1154618945.5094.6.camel@localhost> you wrote:
>
> > In my understanding, an "uImage" file is a  image  consisting  of  an
> > U-Boot  header (64 bytes) followed by an (compressed or uncompressed)
> > Linux kernel image.
> 
> Yes

OK.

> I mean that the data contained within the uImage is compressed. In this

This is only one option. Some configurations  prefer  to  use  uncom-
pressed images because these canbe booted faster.

> case where the uImage data is compressed I choose to skip compressing
> the kernel section in the zImage (because have it compressed twice was
> wasteful)

We don't use zImage !

> So to clarify. The current method has a zImage with a compressed kernel

No, it does not. We do  not  use  zImage  (which  includes  bootstrap
wrapper  code).  U-Boot  uses  a plain stripped and compressed kernel
image, i. e. something like this:

	objcopy  -O binary vmlinux vmlinux.bin
	gzip -f -9 <vmlinux.bin >vmlinux.gz
	mkimage ... -C gzip -d vmlinux.gz uImage

> section where the actual kernel lives. The zImage uncompressed this code
> to the kernel load address. The 'cuImage' would be packaged in a uImage
> with the entire zImage compressed, except in this case the kernel
> section would not be compressed (to avoid have a compressed image within
> a compressed image)

You would have to create a new image type which has  executable  code
at the start and carries the kernel image as payload, similar to what
zImage does. 

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The shortest unit of time in the multiverse is the News York  Second,
defined  as  the  period  of  time between the traffic lights turning
green and the cab behind you honking.
                                - Terry Pratchett, _Lords and Ladies_

Re: [RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

On Thu, 2006-08-03 at 22:00 +0200, Wolfgang Denk wrote:
> > So to clarify. The current method has a zImage with a compressed
> kernel
> 
> No, it does not. We do  not  use  zImage  (which  includes  bootstrap
> wrapper  code).  U-Boot  uses  a plain stripped and compressed kernel
> image, i. e. something like this:
> 
>         objcopy  -O binary vmlinux vmlinux.bin
>         gzip -f -9 <vmlinux.bin >vmlinux.gz
>         mkimage ... -C gzip -d vmlinux.gz uImage 

I'm referring to the zImage target as what the current method does. My
changes would in no way effect the current method of booting, with the
current method being a plain uImage target.

The zImage can have a compressed kernel section or an uncompressed
kernel section. The new 'cuImage' always has an uncompressed kernel
section and which is packaged in the U-Boot image format.

You might refer to the code in my original email for clarification. This
in no way effects the current method of booting, it simply adds a method
to package the bootwrapper + kernel + fdt to pass to old version of
U-Boot so they can use the new 'powerpc' kernels

As a side note, the final cuImage (which is a U-Boot image) can be
either compressed or uncompressed. That is irrelevant. The major point
is the kernel section within the cuImage is not compressed, and the
final cuImage is in fact a U-Boot image which can be started with the
'bootm' command from within U-Boot.

Phew!

-Matthew

Re: [RFC] New target 'cuImage' - compatibility uImage

[Wolfgang Denk]

In message <1154635939.5094.37.camel@localhost> you wrote:
>
> I'm referring to the zImage target as what the current method does. My

This is highly confusing. zImage is a special make target, which  has
NOTHING  to  do with U-Boot. Please don't use this name in the U-Boot
context unleass you really mean it.

> The zImage can have a compressed kernel section or an uncompressed

I stop parsing here. zImage has *nothing* to do with this topic.

> As a side note, the final cuImage (which is a U-Boot image) can be
> either compressed or uncompressed. That is irrelevant. The major point
> is the kernel section within the cuImage is not compressed, and the
> final cuImage is in fact a U-Boot image which can be started with the
> 'bootm' command from within U-Boot.

As explained in a previous message, you should change  the  order  of
parts  (sections?)  in  your  image.  Put the kernel image first, and
attach your stuff at the end. This allows to use standard mechanisms,
keep all the existing flexibility and avoid useless memory copy.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Ninety-Ninety Rule of Project Schedules:
        The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.

Re: [RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

On Thu, 2006-08-03 at 22:23 +0200, Wolfgang Denk wrote:
> > I'm referring to the zImage target as what the current method does.
> My
> 
> This is highly confusing. zImage is a special make target, which  has
> NOTHING  to  do with U-Boot. Please don't use this name in the U-Boot
> context unleass you really mean it.
> 

AFAIK, there are no other targets that include the bootwrapper code
other than zImage. It was a very nice starting point for me to explain
the differences. If you don't want to ask questions and have me try to
further clarify things I cannot help.

The 'cuImage' target as I described is *basically* the following:

$ make zImage
$ mkimage -A ppc -O linux -T kernel -C gzip -a 400000 -e 400010 -n
'Linux-2.6.18' -d arch/powerpc/boot/zImage arch/powerpc/boot/cuImage

> > The zImage can have a compressed kernel section or an uncompressed
> 
> I stop parsing here. zImage has *nothing* to do with this topic. 

Your loss.

-Matthew

Re: [RFC] New target 'cuImage' - compatibility uImage

[Tom Rini]

On Wed, Aug 02, 2006 at 03:59:06PM -0500, Matthew McClintock wrote:

[snip]
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 01667d1..eefbe16 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -141,12 +141,13 @@ # Default to zImage, override when neede
>  defaultimage-y			:= zImage
>  defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
>  defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
> +defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage

This means we never default to a regular 'uImage', and should either
modify the existing line, or a DEFAULT_CUIMAGE.  No preference/etc, just
noting.

-- 
Tom Rini

Re: [RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

On Wed, 2006-08-02 at 17:30 -0700, Tom Rini wrote:
> On Wed, Aug 02, 2006 at 03:59:06PM -0500, Matthew McClintock wrote:
> 
> [snip]
> > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> > index 01667d1..eefbe16 100644
> > --- a/arch/powerpc/Makefile
> > +++ b/arch/powerpc/Makefile
> > @@ -141,12 +141,13 @@ # Default to zImage, override when neede
> >  defaultimage-y			:= zImage
> >  defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
> >  defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
> > +defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage
> 
> This means we never default to a regular 'uImage', and should either
> modify the existing line, or a DEFAULT_CUIMAGE.  No preference/etc, just
> noting.
> 

Note taken, if I ever submit a formal patch I will be sure to include
this.

Thanks,
Matthew

RE: [RFC] New target 'cuImage' - compatibility uImage

[Li Yang-r58472]

If my understanding to Matt's idea is correct, it will be a good way,
IMHO.  How about use the naming of uwImage(U-boot Wrapped Image) or
utImage(u-boot device-Tree Image).

-Leo
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of
> Matthew McClintock
> Sent: Thursday, August 03, 2006 4:59 AM
> To: linuxppc-dev
> Subject: [RFC] New target 'cuImage' - compatibility uImage
>=20
> Hi all,
>=20
> The following is a patch which creates a new target called 'cuImage'.
It
> is designed to correctly package the kernel along with the
> 'arch/powerpc/boot' wrapper code into a uImage to be loaded and
started
> by U-Boot.
>=20
> The purpose of this target is to allow boards with older versions of
> U-Boot to utilize the 'bootm' command within U-Boot to run new powerpc
> kernels. The bootwrapper will begin execution and can correctly setup
a
> flat device tree based on values passed in the bd_t structure,
something
> old versions of U-Boot are not capable of.
>=20
> One might ask why not just use the 'bootelf' command in u-boot. Well,
> not all boards have that option compiled in, and some other boards
might
> not even have access to the console. Also, the bd_t structure is not
> passed from U-Boot when using the bootelf command so we would have no
> method to correctly fill in values in the device tree. This would
> theoretically allow an old board to start a new kernel without access
to
> the console if required.
>=20
> Currently the zImage looks like this:
>=20
> ---------------------------------
> - 	_start			-
> -	boot wrapper code	-
> - ----------------------------- -
> - -	device tree	      - -
> - ----------------------------- -
> - ----------------------------- -
> - - 			      - -
> - - 	compressed	      - -
> - - 	kernel image	      - -
> - -			      - -
> - ----------------------------- -
> ---------------------------------
>=20
> And the new cuImage will look like this:
>=20
> -------------------------------------
> -	compressed uImage	  - -
> - ------------------------------- - -
> - - 	_start			- - -
> - -	boot wrapper code	- - -
> - - ----------------------------- - -
> - - -	device tree	      	- - -
> - - ----------------------------- - -
> - - ----------------------------- - -
> - - - 			      	- - -
> - - - 	UNcompressed	      	- - -
> - - - 	kernel image	      	- - -
> - - -			      	- - -
> - - ----------------------------- - -
> - --------------------------------- -
> -------------------------------------
>=20
> -Matthew
>=20

RE: [RFC] New target 'cuImage' - compatibility uImage

[Matthew McClintock]

On Thu, 2006-08-03 at 04:47 -0700, Li Yang-r58472 wrote:
> If my understanding to Matt's idea is correct, it will be a good way,
> IMHO.  How about use the naming of uwImage(U-boot Wrapped Image) or
> utImage(u-boot device-Tree Image). 

I am completely open to a better name. Anyone else care to share their
opinion?

-Matthew