[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Stephen Warren]

The legacy uImage format includes an absolute load and entry-point
address. When bootm operates on a kernel uImage in memory that isn't
loaded at the address in the image's load address, U-Boot will copy
the image to its address in the header.

Some kernel images can actually be loaded and used at any arbitrary
address. An example is an ARM Linux kernel zImage file. To represent
this capability, IH_TYPE_KERNEL_ANYLOAD is implemented, which operates
just like IH_TYPE_KERNEL, except that the load address header is
ignored, and U-Boot does not copy the image to its load address, but
rather uses it in-place.

This is useful when sharing a single (uImage-wrapped) zImage across
multiple boards with different memory layouts; in this case, a specific
load address need not be picked when creating the uImage, but instead
is selected by the board-specific U-Boot environment used to load and
boot that image.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This is a third attempt to support ARM Linux zImage's ability to run from
anywhere in RAM.

This patch actually ended up being much smaller (patch file size) than
previous attempts. Both my previous attempts could probably be rewritten
to adjust the image load address in the same way as this patch and hence
also be just as small; I don't recommend using any of my previous patches
wthout rework because of this.

before this patch:

   text	   data	    bss	    dec	    hex	filename
 166642	   3568	 217020	 387230	  5e89e	./u-boot

with this patch:

   text	   data	    bss	    dec	    hex	filename
 166761	   3568	 217020	 387349	  5e915	./u-boot

Is this small enough to do without a config option? I certainly hope so,
because ifdefing every one of these tiny code changes would look ugly.

Tested on NVIDIA Tegra Seaboard:

*  Legacy uImage containing a kernel (and appended DT), of type
IH_TYPE_KERNEL.

*  Legacy uImage containing a kernel (and appended DT), of type
IH_TYPE_KERNEL_ANYLOAD.

*  Legacy uImage containing a kernel, of type IH_TYPE_KERNEL_ANYLOAD,
plus a separate plain FDT (no uImage wrapping).

*  Legacy uImage containing a kernel, of type IH_TYPE_KERNEL_ANYLOAD,
plus a uImage-wrapped initrd, plus a separate plain FDT (no uImage
wrapping).

* FIT image containing both kernel of type IH_TYPE_KERNEL_ANYLOAD
and FDT.

* FIT image containing just a kernel of type IH_TYPE_KERNEL_ANYLOAD,
plus a separate plain FDT (no FIT/legacy uImage wrapping).

 common/cmd_bootm.c    |   10 +++++++++-
 common/image.c        |    1 +
 include/image.h       |    1 +
 tools/default_image.c |    3 ++-
 4 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index d301332..2e9df58 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -271,7 +271,13 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]
 		return 1;
 	}
 
+	if (images.os.type == IH_TYPE_KERNEL_ANYLOAD) {
+		images.os.load = images.os.image_start;
+		images.ep += images.os.load;
+	}
+
 	if (((images.os.type == IH_TYPE_KERNEL) ||
+	     (images.os.type == IH_TYPE_KERNEL_ANYLOAD) ||
 	     (images.os.type == IH_TYPE_MULTI)) &&
 	    (images.os.os == IH_OS_LINUX)) {
 		/* find ramdisk */
@@ -795,7 +801,8 @@ static int fit_check_kernel(const void *fit, int os_noffset, int verify)
 	}
 
 	show_boot_progress(106);
-	if (!fit_image_check_type(fit, os_noffset, IH_TYPE_KERNEL)) {
+	if (!fit_image_check_type(fit, os_noffset, IH_TYPE_KERNEL) &&
+	    !fit_image_check_type(fit, os_noffset, IH_TYPE_KERNEL_ANYLOAD)) {
 		puts("Not a kernel image\n");
 		show_boot_progress(-106);
 		return 0;
@@ -873,6 +880,7 @@ static void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc,
 		/* get os_data and os_len */
 		switch (image_get_type(hdr)) {
 		case IH_TYPE_KERNEL:
+		case IH_TYPE_KERNEL_ANYLOAD:
 			*os_data = image_get_data(hdr);
 			*os_len = image_get_data_size(hdr);
 			break;
diff --git a/common/image.c b/common/image.c
index 555d9d9..8e66e01 100644
--- a/common/image.c
+++ b/common/image.c
@@ -136,6 +136,7 @@ static const table_entry_t uimage_type[] = {
 	{	IH_TYPE_FIRMWARE,   "firmware",	  "Firmware",		},
 	{	IH_TYPE_FLATDT,     "flat_dt",    "Flat Device Tree",	},
 	{	IH_TYPE_KERNEL,	    "kernel",	  "Kernel Image",	},
+	{	IH_TYPE_KERNEL_ANYLOAD, "kernel_anyload",  "Kernel Image (any load address)", },
 	{	IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
 	{	IH_TYPE_IMXIMAGE,   "imximage",   "Freescale i.MX Boot Image",},
 	{	IH_TYPE_INVALID,    NULL,	  "Invalid Image",	},
diff --git a/include/image.h b/include/image.h
index c56a18d..1b3f40a 100644
--- a/include/image.h
+++ b/include/image.h
@@ -162,6 +162,7 @@
 #define IH_TYPE_UBLIMAGE	11	/* Davinci UBL Image		*/
 #define IH_TYPE_OMAPIMAGE	12	/* TI OMAP Config Header Image	*/
 #define IH_TYPE_AISIMAGE	13	/* TI Davinci AIS Image		*/
+#define IH_TYPE_KERNEL_ANYLOAD	14	/* OS Kernel Image, can run from any load address */
 
 /*
  * Compression Types
diff --git a/tools/default_image.c b/tools/default_image.c
index 6ea3b46..bfcaf76 100644
--- a/tools/default_image.c
+++ b/tools/default_image.c
@@ -35,7 +35,8 @@ static image_header_t header;
 
 static int image_check_image_types(uint8_t type)
 {
-	if ((type > IH_TYPE_INVALID) && (type < IH_TYPE_FLATDT))
+	if (((type > IH_TYPE_INVALID) && (type < IH_TYPE_FLATDT)) ||
+	    (type == IH_TYPE_KERNEL_ANYLOAD))
 		return EXIT_SUCCESS;
 	else
 		return EXIT_FAILURE;
-- 
1.7.0.4

[U-Boot] [PATCH 2/2] image: Don't detect XIP images as overlapping.

[Stephen Warren]

bootm_load_os() detects when it writes the decompressed image over
the top of the compressed image. If this happens, the original image
is corrupted. When the original image is a multi-component legacy image,
or a (potentially multi-component) FIT image, this implies that other
components may be corrupted. In turn, this means that booting is unlikely
to be successful.

However, in the case of no image compresssion coupled with an image with
load address equal to where the image is already located (e.g. an XIP
kernel, or IH_TYPE_KERNEL_ANYLOAD), there has been no copy and hence no
corruption, no matter whether it's a single-component legacy image, a
multi-component legacy image, or a FIT image. In this case, disable the
overlap detection, and allow boot to continue.

Without this change, when booting a single-component legacy image that
contains an IH_TYPE_KERNEL_ANYLOAD, bootm_load_os() would have returned
BOOTM_ERR_OVERLAP, but the caller ignores this, and boot continues and
succeeds. Now, the false error is no longer even returned.

Without this change, when booting a FIT image that contains an
IH_TYPE_KERNEL_ANYLOAD, bootm_load_os() would have returned
BOOTM_ERR_OVERLAP, which would then cause the caller to reset the board.
Now, the false error is no longer returned, and boot succeeds.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 common/cmd_bootm.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 2e9df58..8f3c97f 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -319,6 +319,7 @@ static int bootm_load_os(image_info_t os, ulong *load_end, int boot_progress)
 	ulong image_start = os.image_start;
 	ulong image_len = os.image_len;
 	uint unc_len = CONFIG_SYS_BOOTM_LEN;
+	int no_overlap = 0;
 #if defined(CONFIG_LZMA) || defined(CONFIG_LZO)
 	int ret;
 #endif /* defined(CONFIG_LZMA) || defined(CONFIG_LZO) */
@@ -329,6 +330,7 @@ static int bootm_load_os(image_info_t os, ulong *load_end, int boot_progress)
 	case IH_COMP_NONE:
 		if (load == blob_start || load == image_start) {
 			printf("   XIP %s ... ", type_name);
+			no_overlap = 1;
 		} else {
 			printf("   Loading %s ... ", type_name);
 			memmove_wd((void *)load, (void *)image_start,
@@ -423,7 +425,7 @@ static int bootm_load_os(image_info_t os, ulong *load_end, int boot_progress)
 	if (boot_progress)
 		show_boot_progress(7);
 
-	if ((load < blob_end) && (*load_end > blob_start)) {
+	if (!no_overlap && (load < blob_end) && (*load_end > blob_start)) {
 		debug("images.os.start = 0x%lX, images.os.end = 0x%lx\n",
 			blob_start, blob_end);
 		debug("images.os.load = 0x%lx, load_end = 0x%lx\n", load,
-- 
1.7.0.4

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Marek Vasut]

> The legacy uImage format includes an absolute load and entry-point
> address. When bootm operates on a kernel uImage in memory that isn't
> loaded at the address in the image's load address, U-Boot will copy
> the image to its address in the header.
> 
> Some kernel images can actually be loaded and used at any arbitrary
> address. An example is an ARM Linux kernel zImage file. To represent
> this capability, IH_TYPE_KERNEL_ANYLOAD is implemented, which operates
> just like IH_TYPE_KERNEL, except that the load address header is
> ignored, and U-Boot does not copy the image to its load address, but
> rather uses it in-place.
> 
> This is useful when sharing a single (uImage-wrapped) zImage across
> multiple boards with different memory layouts; in this case, a specific
> load address need not be picked when creating the uImage, but instead
> is selected by the board-specific U-Boot environment used to load and
> boot that image.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---

Hi Stephen,

just a silly question, but didn't we agree on cmd_bootz? Or is this unrelated ?

M

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Wolfgang Denk]

Dear Stephen Warren,

In message <1320860840-6347-1-git-send-email-swarren@nvidia.com> you wrote:
> The legacy uImage format includes an absolute load and entry-point
> address. When bootm operates on a kernel uImage in memory that isn't
> loaded at the address in the image's load address, U-Boot will copy
> the image to its address in the header.
> 
> Some kernel images can actually be loaded and used at any arbitrary
> address. An example is an ARM Linux kernel zImage file. To represent

You write: an example is...

Are there other Linux kernel image types in addition to zImage that
have this property?

> this capability, IH_TYPE_KERNEL_ANYLOAD is implemented, which operates

I don't like this name.  "ANYLOAD" doesn't really make sense to me; I
would interpet this as "U-Boot is free to load the image to any
address it likes" - which is not what I think you mean.  I guess
"IH_TYPE_KERNEL_NOLOAD" would better mach what the code is supposed to
do.

But then, I'd like "IH_TYPE_ZIMAGE" even better - assuming of course
that only zImages are used here.  Are we sure about this?

> +	if (images.os.type == IH_TYPE_KERNEL_ANYLOAD) {
> +		images.os.load = images.os.image_start;
> +		images.ep += images.os.load;
> +	}

I'm not sure if we give up flexibility here without need.

Suggestion:  IH_TYPE_KERNEL_NOLOAD images should read the entry point
address from the image header, and interpret it as an offset relative
to the image_start.  This adds basicly no code size, an no effort if
you don't want to use it (when running mkimage you will probably
always use "-a 0 -e 0" anyway), but in case you ever need a different
EP you have it, more or less for free.

> +	{	IH_TYPE_KERNEL_ANYLOAD, "kernel_anyload",  "Kernel Image (any load address)", },

...IH_TYPE_KERNEL_NOLOAD ..."Kernel Image (no loading done)" ?


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 at denx.de
I'm a programmer: I don't buy software, I write it.
                                                  -- Tom Christiansen

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Stephen Warren]

On 11/10/2011 02:58 AM, Marek Vasut wrote:
>> The legacy uImage format includes an absolute load and entry-point
>> address. When bootm operates on a kernel uImage in memory that isn't
>> loaded at the address in the image's load address, U-Boot will copy
>> the image to its address in the header.
>>
>> Some kernel images can actually be loaded and used at any arbitrary
>> address. An example is an ARM Linux kernel zImage file. To represent
>> this capability, IH_TYPE_KERNEL_ANYLOAD is implemented, which operates
>> just like IH_TYPE_KERNEL, except that the load address header is
>> ignored, and U-Boot does not copy the image to its load address, but
>> rather uses it in-place.
>>
>> This is useful when sharing a single (uImage-wrapped) zImage across
>> multiple boards with different memory layouts; in this case, a specific
>> load address need not be picked when creating the uImage, but instead
>> is selected by the board-specific U-Boot environment used to load and
>> boot that image.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> ---
> 
> Hi Stephen,
> 
> just a silly question, but didn't we agree on cmd_bootz? Or is this unrelated ?

bootz did seem to be agreed upon initially, but Wolfgang's most recent
response suggested that a new IH_TYPE would be acceptable, and it's a
lot less code to implement. At a later point, bootz could still be
implemented if desired.

-- 
nvpublic

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Stephen Warren]

On 11/10/2011 04:59 AM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <1320860840-6347-1-git-send-email-swarren@nvidia.com> you wrote:
>> The legacy uImage format includes an absolute load and entry-point
>> address. When bootm operates on a kernel uImage in memory that isn't
>> loaded at the address in the image's load address, U-Boot will copy
>> the image to its address in the header.
>>
>> Some kernel images can actually be loaded and used at any arbitrary
>> address. An example is an ARM Linux kernel zImage file. To represent
> 
> You write: an example is...
> 
> Are there other Linux kernel image types in addition to zImage that
> have this property?

I'm sorry, I really don't know.

Note that I even specifically said /ARM/ Linux kernel zImage, because I
have no idea if zImage on other architectures is relocatable or not.

>> this capability, IH_TYPE_KERNEL_ANYLOAD is implemented, which operates
> 
> I don't like this name.  "ANYLOAD" doesn't really make sense to me; I
> would interpet this as "U-Boot is free to load the image to any
> address it likes" - which is not what I think you mean.

I think ANYLOAD describes the situation correctly:

For IH_TYPE_KERNEL, the image is physically loaded to whatever address
the U-Boot environment/script loads it to, and then U-Boot relocates the
image to the load address in the header if it's not already there (for
uncompressed images).

With ANYLOAD, there is still a load address (wherever the U-Boot
environment/script placed the image), yet any load address is accepted
without relocation rather than just the one specified in the image
header, so U-Boot always just skips the relocation.

Put another way: extload/fatload load the image, and bootm just
relocates/copies the image rather than loads it.

> I guess "IH_TYPE_KERNEL_NOLOAD" would better match what the code is
> supposed to do.

I did consider that name too, but decided not to use it given my
explanation above. I can rename it if you want though.

> But then, I'd like "IH_TYPE_ZIMAGE" even better - assuming of course
> that only zImages are used here.  Are we sure about this?

I deliberately didn't pick ZIMAGE, since I can't say for certain that
only zImages are relocatable across all kernel image formats across all
architectures. And note that ANYLOAD could well be applicable to
non-Linux OSs for all I know; bootm appears to be able to boot a whole
variety of other OSs, and I wouldn't be entirely surprised if at least
one of them had fully relocatable images like ARM Linux kernel zImages.

>> +	if (images.os.type == IH_TYPE_KERNEL_ANYLOAD) {
>> +		images.os.load = images.os.image_start;
>> +		images.ep += images.os.load;
>> +	}
> 
> I'm not sure if we give up flexibility here without need.
> 
> Suggestion:  IH_TYPE_KERNEL_NOLOAD images should read the entry point
> address from the image header, and interpret it as an offset relative
> to the image_start.

Isn't that exactly what the code is doing; note ep is calculated as +=
not just =.

> This adds basicly no code size, an no effort if
> you don't want to use it (when running mkimage you will probably
> always use "-a 0 -e 0" anyway), but in case you ever need a different
> EP you have it, more or less for free.
> 
>> +	{	IH_TYPE_KERNEL_ANYLOAD, "kernel_anyload",  "Kernel Image (any load address)", },
> 
> ...IH_TYPE_KERNEL_NOLOAD ..."Kernel Image (no loading done)" ?

Perhaps "(no relocation)"?

-- 
nvpublic

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Marek Vasut]

> On 11/10/2011 02:58 AM, Marek Vasut wrote:
> >> The legacy uImage format includes an absolute load and entry-point
> >> address. When bootm operates on a kernel uImage in memory that isn't
> >> loaded at the address in the image's load address, U-Boot will copy
> >> the image to its address in the header.
> >> 
> >> Some kernel images can actually be loaded and used at any arbitrary
> >> address. An example is an ARM Linux kernel zImage file. To represent
> >> this capability, IH_TYPE_KERNEL_ANYLOAD is implemented, which operates
> >> just like IH_TYPE_KERNEL, except that the load address header is
> >> ignored, and U-Boot does not copy the image to its load address, but
> >> rather uses it in-place.
> >> 
> >> This is useful when sharing a single (uImage-wrapped) zImage across
> >> multiple boards with different memory layouts; in this case, a specific
> >> load address need not be picked when creating the uImage, but instead
> >> is selected by the board-specific U-Boot environment used to load and
> >> boot that image.
> >> 
> >> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> >> ---
> > 
> > Hi Stephen,
> > 
> > just a silly question, but didn't we agree on cmd_bootz? Or is this
> > unrelated ?
> 
> bootz did seem to be agreed upon initially, but Wolfgang's most recent
> response suggested that a new IH_TYPE would be acceptable, and it's a
> lot less code to implement. At a later point, bootz could still be
> implemented if desired.

Well DAMN. I think I'll probably implement bootz, because it seems superior 
solution which I DID NEED for one of my devices for a while now (if noone is 
working on it already). I can't say what ETA will be on that, maybe next week, 
maybe two weeks.

M

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Stephen Warren]

On 11/10/2011 10:01 AM, Marek Vasut wrote:
>> On 11/10/2011 02:58 AM, Marek Vasut wrote:
>>>> [Description of IH_TYPE_KERNEL_ANYLOAD]
>>>
>>> just a silly question, but didn't we agree on cmd_bootz? Or is this
>>> unrelated ?
>>
>> bootz did seem to be agreed upon initially, but Wolfgang's most recent
>> response suggested that a new IH_TYPE would be acceptable, and it's a
>> lot less code to implement. At a later point, bootz could still be
>> implemented if desired.
> 
> Well DAMN. I think I'll probably implement bootz, because it seems superior 
> solution which I DID NEED for one of my devices for a while now (if noone is 
> working on it already). I can't say what ETA will be on that, maybe next week, 
> maybe two weeks.

Out of curiosity, why doesn't this bootm feature work for you?
Admittedly you still need to wrap the zImage inside a uImage, but I
don't think that's insurmountable? Aside from that, doesn't it work
exactly like a bootz command would?

-- 
nvpublic

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Marek Vasut]

> On 11/10/2011 10:01 AM, Marek Vasut wrote:
> >> On 11/10/2011 02:58 AM, Marek Vasut wrote:
> >>>> [Description of IH_TYPE_KERNEL_ANYLOAD]
> >>> 
> >>> just a silly question, but didn't we agree on cmd_bootz? Or is this
> >>> unrelated ?
> >> 
> >> bootz did seem to be agreed upon initially, but Wolfgang's most recent
> >> response suggested that a new IH_TYPE would be acceptable, and it's a
> >> lot less code to implement. At a later point, bootz could still be
> >> implemented if desired.
> > 
> > Well DAMN. I think I'll probably implement bootz, because it seems
> > superior solution which I DID NEED for one of my devices for a while now
> > (if noone is working on it already). I can't say what ETA will be on
> > that, maybe next week, maybe two weeks.
> 
> Out of curiosity, why doesn't this bootm feature work for you?
> Admittedly you still need to wrap the zImage inside a uImage, but I
> don't think that's insurmountable? Aside from that, doesn't it work
> exactly like a bootz command would?

Do you still have those +12bytes (sizeof(uImage header)) offset there? I don't 
like it. Also, I think using zImage might be plain easier.

M

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Stephen Warren]

On 11/10/2011 10:47 AM, Marek Vasut wrote:
>> On 11/10/2011 10:01 AM, Marek Vasut wrote:
>>>> On 11/10/2011 02:58 AM, Marek Vasut wrote:
>>>>>> [Description of IH_TYPE_KERNEL_ANYLOAD]
>>>>>
>>>>> just a silly question, but didn't we agree on cmd_bootz? Or is this
>>>>> unrelated ?
>>>>
>>>> bootz did seem to be agreed upon initially, but Wolfgang's most recent
>>>> response suggested that a new IH_TYPE would be acceptable, and it's a
>>>> lot less code to implement. At a later point, bootz could still be
>>>> implemented if desired.
>>>
>>> Well DAMN. I think I'll probably implement bootz, because it seems
>>> superior solution which I DID NEED for one of my devices for a while now
>>> (if noone is working on it already). I can't say what ETA will be on
>>> that, maybe next week, maybe two weeks.
>>
>> Out of curiosity, why doesn't this bootm feature work for you?
>> Admittedly you still need to wrap the zImage inside a uImage, but I
>> don't think that's insurmountable? Aside from that, doesn't it work
>> exactly like a bootz command would?
> 
> Do you still have those +12bytes (sizeof(uImage header)) offset there?
> I don't like it.

The uImage file itself certainly includes the uImage header.

The code in my latest patches should be pointing images.os.load right at
the image start itself (i.e. pointing past the header), so I don't think
there's any incorrect offset within the code. This was really just a bug
in the "-1 load address" patches I posted anyway.

> Also, I think using zImage might be plain easier.

Well, admittedly it's slightly simpler not to wrap zImage in uImage,
since there's no need to run mkimage. However, with this new IH_TYPE,
all the mkimage parameters can be hard-coded (there's no need to specify
any real value for the addresses; just use 0), so the command-line is
pretty simple. Besides, I imagine the kernel uImage target can be
updated (or a new one added) to continue to do this for you.

I did consider that not running mkimage at all would be simpler, but
there are other places mkimage would still be needed anyway:

a) Any initrd would still need to be wrapped in a uImage for bootm to
recognize it. If you wrote a bootz to accept a raw unwrapped initrd, I
imagine that same raw initrd recognition code could just as easily be
applied to bootm.

b) The distro will most likely want to specify either the entire Linux
command-line, or at least something to append to it. I imagine this will
work by the distro creating a uImage-wrapped U-Boot script e.g.
/boot/script.uimg. Creating that script would require mkimage too.
Perhaps again U-Boot could be modified to support loading scripts from
disk and executing them without requiring a uImage header though.

So, I don't think eliminating mkimage entirely is all that likely. And
as such, using mkimage for the kernel itself doesn't seem like a big deal.

Still, I'm not a distro vendor, so I don't know what their feelings are
on this topic.

-- 
nvpublic

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Marek Vasut]

> On 11/10/2011 10:47 AM, Marek Vasut wrote:
> >> On 11/10/2011 10:01 AM, Marek Vasut wrote:
> >>>> On 11/10/2011 02:58 AM, Marek Vasut wrote:
> >>>>>> [Description of IH_TYPE_KERNEL_ANYLOAD]
> >>>>> 
> >>>>> just a silly question, but didn't we agree on cmd_bootz? Or is this
> >>>>> unrelated ?
> >>>> 
> >>>> bootz did seem to be agreed upon initially, but Wolfgang's most recent
> >>>> response suggested that a new IH_TYPE would be acceptable, and it's a
> >>>> lot less code to implement. At a later point, bootz could still be
> >>>> implemented if desired.
> >>> 
> >>> Well DAMN. I think I'll probably implement bootz, because it seems
> >>> superior solution which I DID NEED for one of my devices for a while
> >>> now (if noone is working on it already). I can't say what ETA will be
> >>> on that, maybe next week, maybe two weeks.
> >> 
> >> Out of curiosity, why doesn't this bootm feature work for you?
> >> Admittedly you still need to wrap the zImage inside a uImage, but I
> >> don't think that's insurmountable? Aside from that, doesn't it work
> >> exactly like a bootz command would?
> > 
> > Do you still have those +12bytes (sizeof(uImage header)) offset there?
> > I don't like it.
> 
> The uImage file itself certainly includes the uImage header.
> 
> The code in my latest patches should be pointing images.os.load right at
> the image start itself (i.e. pointing past the header), so I don't think
> there's any incorrect offset within the code. This was really just a bug
> in the "-1 load address" patches I posted anyway.
> 
> > Also, I think using zImage might be plain easier.
> 
> Well, admittedly it's slightly simpler not to wrap zImage in uImage,
> since there's no need to run mkimage. However, with this new IH_TYPE,
> all the mkimage parameters can be hard-coded (there's no need to specify
> any real value for the addresses; just use 0), so the command-line is
> pretty simple. Besides, I imagine the kernel uImage target can be
> updated (or a new one added) to continue to do this for you.
> 
> I did consider that not running mkimage at all would be simpler, but
> there are other places mkimage would still be needed anyway:
> 
> a) Any initrd would still need to be wrapped in a uImage for bootm to
> recognize it. If you wrote a bootz to accept a raw unwrapped initrd, I
> imagine that same raw initrd recognition code could just as easily be
> applied to bootm.

Well if you want an image where you have kernel+initrd, why not use initramfs ?
> 
> b) The distro will most likely want to specify either the entire Linux
> command-line, or at least something to append to it. I imagine this will
> work by the distro creating a uImage-wrapped U-Boot script e.g.
> /boot/script.uimg. Creating that script would require mkimage too.
> Perhaps again U-Boot could be modified to support loading scripts from
> disk and executing them without requiring a uImage header though.
> 
> So, I don't think eliminating mkimage entirely is all that likely. And
> as such, using mkimage for the kernel itself doesn't seem like a big deal.

Hm, isn't FDT supposed to contain the command line now ?
> 
> Still, I'm not a distro vendor, so I don't know what their feelings are
> on this topic.

It's good to discuss stuff actually! It only mustn't turn into flamewar ;-)

M

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Stephen Warren]

On 11/10/2011 11:07 AM, Marek Vasut wrote:
> Stephen Warren wrote:
...
>> I did consider that not running mkimage at all would be simpler, but
>> there are other places mkimage would still be needed anyway:
>>
>> a) Any initrd would still need to be wrapped in a uImage for bootm to
>> recognize it. If you wrote a bootz to accept a raw unwrapped initrd, I
>> imagine that same raw initrd recognition code could just as easily be
>> applied to bootm.
> 
> Well if you want an image where you have kernel+initrd, why not use initramfs ?

As I understand it, initramfs is embedded into the kernel image, and
initrd is a separate file.

(existing desktop) distros typically want their initrd as a separate
file, so they can rebuild the initrd separately from the kernel image -
i.e. ship a binary zImage for the kernel, but build the initrd at
(distro or kernel update) install time based on whether the user needs
RAID, LVM, crypto, random driver, ... modules or not. Rebuilding a
separate initrd file is pretty easy. Rebuilding the initramfs already
embedded into the kernel zImage is probably not.

>> b) The distro will most likely want to specify either the entire Linux
>> command-line, or at least something to append to it. I imagine this will
>> work by the distro creating a uImage-wrapped U-Boot script e.g.
>> /boot/script.uimg. Creating that script would require mkimage too.
>> Perhaps again U-Boot could be modified to support loading scripts from
>> disk and executing them without requiring a uImage header though.
>>
>> So, I don't think eliminating mkimage entirely is all that likely. And
>> as such, using mkimage for the kernel itself doesn't seem like a big deal.
> 
> Hm, isn't FDT supposed to contain the command line now ?

Well, I don't think FDT supoprt is far enough along for any (ARM) SoC
that a distro could exclusively rely on it yet. But, I may be wrong. I'm
also thinking only of mainline; downstream support may be far more
advanced in many cases.

Either way, the physical mechanism of passing the command-line to the
kernel (ATAGs vs. FDT) isn't relevant to this discussion; it's just a
transport mechanism.

Distros will probably still need to adjust the command-line, e.g. to add
"quiet splash" to it or not based on whether a recovery or regular boot
is required.

The idea is that the board vendor will supply the FDT image somehow,
with either a minimal Linux cmdline or perhaps even none at all. The FDT
might be stored in some non-filesystem location; perhaps embedded into
U-Boot, perhaps in SPI/NOR/NAND flash without a filesystem. As such, the
distro can't expect to be able to directly modify the FDT contents at
install time in order to set up the cmdline it wants. Even if the FDT
were stored in /boot/fdt.uimg, the distro would probably be well advised
not to manipulate it on disk, to make it easier for an end-user to
install an updated FDT with bugfixes.

Instead, U-Boot must write the cmdline into the FDT/ATAG when it boots
the kernel, and the value it writes may need to be manipulated by the
distro, I assume by the distro providing a U-Boot script to do the
manipulation.

-- 
nvpublic

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Marek Vasut]

> On 11/10/2011 11:07 AM, Marek Vasut wrote:
> > Stephen Warren wrote:
> ...
> 
> >> I did consider that not running mkimage at all would be simpler, but
> >> there are other places mkimage would still be needed anyway:
> >> 
> >> a) Any initrd would still need to be wrapped in a uImage for bootm to
> >> recognize it. If you wrote a bootz to accept a raw unwrapped initrd, I
> >> imagine that same raw initrd recognition code could just as easily be
> >> applied to bootm.
> > 
> > Well if you want an image where you have kernel+initrd, why not use
> > initramfs ?
> 
> As I understand it, initramfs is embedded into the kernel image, and
> initrd is a separate file.
> 
> (existing desktop) distros typically want their initrd as a separate
> file, so they can rebuild the initrd separately from the kernel image -
> i.e. ship a binary zImage for the kernel, but build the initrd at
> (distro or kernel update) install time based on whether the user needs
> RAID, LVM, crypto, random driver, ... modules or not. Rebuilding a
> separate initrd file is pretty easy. Rebuilding the initramfs already
> embedded into the kernel zImage is probably not.

This is definitelly a good point. But then, if you can load zImage, can't you 
load initrd with u-boot?
> 
> >> b) The distro will most likely want to specify either the entire Linux
> >> command-line, or at least something to append to it. I imagine this will
> >> work by the distro creating a uImage-wrapped U-Boot script e.g.
> >> /boot/script.uimg. Creating that script would require mkimage too.
> >> Perhaps again U-Boot could be modified to support loading scripts from
> >> disk and executing them without requiring a uImage header though.
> >> 
> >> So, I don't think eliminating mkimage entirely is all that likely. And
> >> as such, using mkimage for the kernel itself doesn't seem like a big
> >> deal.
> > 
> > Hm, isn't FDT supposed to contain the command line now ?
> 
> Well, I don't think FDT supoprt is far enough along for any (ARM) SoC
> that a distro could exclusively rely on it yet. But, I may be wrong. I'm
> also thinking only of mainline; downstream support may be far more
> advanced in many cases.
> 
> Either way, the physical mechanism of passing the command-line to the
> kernel (ATAGs vs. FDT) isn't relevant to this discussion; it's just a
> transport mechanism.
> 
> Distros will probably still need to adjust the command-line, e.g. to add
> "quiet splash" to it or not based on whether a recovery or regular boot
> is required.

That's true, but you can have the generic command line in FDT and then pass 
changed command line through u-boot environment. I don't see a reason why you'd 
want to push it into uImage.

> 
> The idea is that the board vendor will supply the FDT image somehow,
> with either a minimal Linux cmdline or perhaps even none at all. The FDT
> might be stored in some non-filesystem location; perhaps embedded into
> U-Boot, perhaps in SPI/NOR/NAND flash without a filesystem. As such, the
> distro can't expect to be able to directly modify the FDT contents at
> install time in order to set up the cmdline it wants. Even if the FDT
> were stored in /boot/fdt.uimg, the distro would probably be well advised
> not to manipulate it on disk, to make it easier for an end-user to
> install an updated FDT with bugfixes.
> 
> Instead, U-Boot must write the cmdline into the FDT/ATAG when it boots
> the kernel, and the value it writes may need to be manipulated by the
> distro, I assume by the distro providing a U-Boot script to do the
> manipulation.

Exactly, so the command line has nothing to do with uImage.

So basically, in the end, we need to 1) load zImage, 2) load initrd and 3) 
adjust command line. 1) and 2) can be done via standard commands, 3) via some 
script.

M

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Wolfgang Denk]

Dear Stephen Warren,

In message <4EBBF894.2000409@nvidia.com> you wrote:
>
> > I don't like this name.  "ANYLOAD" doesn't really make sense to me; I
> > would interpet this as "U-Boot is free to load the image to any
> > address it likes" - which is not what I think you mean.
> 
> I think ANYLOAD describes the situation correctly:

Sorry about the nitpicking, but I disagree.

> For IH_TYPE_KERNEL, the image is physically loaded to whatever address
> the U-Boot environment/script loads it to, and then U-Boot relocates the
> image to the load address in the header if it's not already there (for
> uncompressed images).

In principle you are right, butthe terms you are using are not really
correct. "Relocate" has a well-defined meaning, and includes the
modification of addresses to adapt the relocated code to it's now
position in memory.  This is not what's going on.

U-Boot is given an image that is stored somewhere in memory (that's
the "M" in "bootm": boot an image in memory), and it _copies_ (or
loads) it to the "load address", eventually uncompressing it in this
process.

> With ANYLOAD, there is still a load address (wherever the U-Boot
> environment/script placed the image), yet any load address is accepted

No.  In the zImage case, U-Boot does exactly NOT perform the loading
(= copying) to the address given in the "load adress" header entry. It
just leaves the image wherever it happens to bein memory.  This is why
I would like to call this "NO LOAD" - because no loading is done.

> without relocation rather than just the one specified in the image
> header, so U-Boot always just skips the relocation.

In no case any relocation is ever done by the "bootm" command.

> Put another way: extload/fatload load the image, and bootm just
> relocates/copies the image rather than loads it.

Wrong.  "bootm" loads the image from it's original location in memory
to the address given in the "load address" entry of the image header.
That's why this field is named ih_load : "Data  Load  Address".

> > I guess "IH_TYPE_KERNEL_NOLOAD" would better match what the code is
> > supposed to do.
> 
> I did consider that name too, but decided not to use it given my
> explanation above. I can rename it if you want though.

Please reconsider.

> I deliberately didn't pick ZIMAGE, since I can't say for certain that
> only zImages are relocatable across all kernel image formats across all
> architectures. And note that ANYLOAD could well be applicable to
> non-Linux OSs for all I know; bootm appears to be able to boot a whole
> variety of other OSs, and I wouldn't be entirely surprised if at least
> one of them had fully relocatable images like ARM Linux kernel zImages.

No. "bootm" follows exactly the Linux kernel calling conventions in
all details from passing specific values in specific registers,
putting specific data at certain addresses / address ranges, etc.
"bootm" is to boot Linux.  I am not aware of any other OS that can be
successfully booted with the "bootm" command (and ifso, it probably
gould be started with "go" as well).

> >> +	if (images.os.type == IH_TYPE_KERNEL_ANYLOAD) {
> >> +		images.os.load = images.os.image_start;
> >> +		images.ep += images.os.load;
> >> +	}
> > 
> > I'm not sure if we give up flexibility here without need.
> > 
> > Suggestion:  IH_TYPE_KERNEL_NOLOAD images should read the entry point
> > address from the image header, and interpret it as an offset relative
> > to the image_start.
> 
> Isn't that exactly what the code is doing; note ep is calculated as +=
> not just =.

Oops. I have to admit that I overlooked the +=.  But that - where is
the value set that you are adding to?

> > ...IH_TYPE_KERNEL_NOLOAD ..."Kernel Image (no loading done)" ?
> 
> Perhaps "(no relocation)"?

Definitely not.  There is no relocation involved anywhere 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 at denx.de
It is wrong always, everywhere and for everyone to  believe  anything
upon  insufficient  evidence.  - W. K. Clifford, British philosopher,
circa 1876

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Wolfgang Denk]

Dear Marek Vasut,

In message <201111101907.39470.marek.vasut@gmail.com> you wrote:
>
> Well if you want an image where you have kernel+initrd, why not use initramfs ?

Because it may be nice to have this separate, so you can change one and
leave the other in place?  Or download them separately, only if
needed?  etc. etc.

> Hm, isn't FDT supposed to contain the command line now ?

You can pass the command line there. as you can hard-code a command
line in the kernel image.

Guess how many U-Boot users actually do that, and how many _love_ the
flexibility they get from "bootargs"?

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 at denx.de
(null cookie; hope that's ok)

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Stephen Warren]

On 11/10/2011 11:53 AM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <4EBBF894.2000409@nvidia.com> you wrote:
>>
>>> I don't like this name.  "ANYLOAD" doesn't really make sense to me; I
>>> would interpet this as "U-Boot is free to load the image to any
>>> address it likes" - which is not what I think you mean.
>>
>> I think ANYLOAD describes the situation correctly:
> 
> Sorry about the nitpicking, but I disagree.

OK, I'll rework the patch based on your desired naming.

However, I do wish to point out that U-Boot's use of the term "load" for
what is really a "copy"/"move" is incorrect according to the typically
accepted meaning of the word "load". The extload/fatload commands use
"load" correctly. I admit relocate is also not a correct phrase to
describe what's happening.

...
>> I deliberately didn't pick ZIMAGE, since I can't say for certain that
>> only zImages are relocatable across all kernel image formats across all
>> architectures. And note that ANYLOAD could well be applicable to
>> non-Linux OSs for all I know; bootm appears to be able to boot a whole
>> variety of other OSs, and I wouldn't be entirely surprised if at least
>> one of them had fully relocatable images like ARM Linux kernel zImages.
> 
> No. "bootm" follows exactly the Linux kernel calling conventions in
> all details from passing specific values in specific registers,
> putting specific data at certain addresses / address ranges, etc.
> "bootm" is to boot Linux.  I am not aware of any other OS that can be
> successfully booted with the "bootm" command (and ifso, it probably
> gould be started with "go" as well).

I didn't want to burden my previous email with details, and I quite
admit I may be wrong here since I'm not familiar with U-Boot's code, but
what about the following in cmd_bootm.c:

static boot_os_fn *boot_os[] = {
#ifdef CONFIG_BOOTM_LINUX
	[IH_OS_LINUX] = do_bootm_linux,
#endif
#ifdef CONFIG_BOOTM_NETBSD
	[IH_OS_NETBSD] = do_bootm_netbsd,
#endif
#ifdef CONFIG_LYNXKDI
	[IH_OS_LYNXOS] = do_bootm_lynxkdi,
#endif
#ifdef CONFIG_BOOTM_RTEMS
	[IH_OS_RTEMS] = do_bootm_rtems,
#endif
#if defined(CONFIG_BOOTM_OSE)
	[IH_OS_OSE] = do_bootm_ose,
#endif
#if defined(CONFIG_CMD_ELF)
	[IH_OS_VXWORKS] = do_bootm_vxworks,
	[IH_OS_QNX] = do_bootm_qnxelf,
#endif
#ifdef CONFIG_INTEGRITY
	[IH_OS_INTEGRITY] = do_bootm_integrity,
#endif
};

Don't they allow the bootm command to boot other OSs? Those functions
certainly appear to be called at the end of cmd_bootm() to do the actual
kernel parameter setup and boot.

-- 
nvpublic

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Wolfgang Denk]

Dear Marek Vasut,

In message <201111101940.40863.marek.vasut@gmail.com> you wrote:
>
> So basically, in the end, we need to 1) load zImage, 2) load initrd and 3) 
> adjust command line. 1) and 2) can be done via standard commands, 3) via some 
> script.

Actually there is a _little_ more to do for the boot loader. There are
obvious functions (like passing information about size and addresses
of avialable memory), less obvious things (like inserting the MAC
addresses for the network interfaces into the device tree, thus
passing them to the LInux kernel - something that has been impossible
so far in ARM land), and even adaption of the device troo to the
actual hardware - boards that come in different versions canuse this
do disable non-existing (on this board) function blocks in the DT,
etc. etc.  

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 at denx.de
Real programmers can write assembly code in any language.   :-)
                      - Larry Wall in  <8571@jpl-devvax.JPL.NASA.GOV>

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Stephen Warren]

On 11/10/2011 11:40 AM, Marek Vasut wrote:
>> On 11/10/2011 11:07 AM, Marek Vasut wrote:
>>> Stephen Warren wrote:
>> ...
>>
>>>> I did consider that not running mkimage at all would be simpler, but
>>>> there are other places mkimage would still be needed anyway:
>>>>
>>>> a) Any initrd would still need to be wrapped in a uImage for bootm to
>>>> recognize it. If you wrote a bootz to accept a raw unwrapped initrd, I
>>>> imagine that same raw initrd recognition code could just as easily be
>>>> applied to bootm.
>>>
>>> Well if you want an image where you have kernel+initrd, why not use
>>> initramfs ?
>>
>> As I understand it, initramfs is embedded into the kernel image, and
>> initrd is a separate file.
>>
>> (existing desktop) distros typically want their initrd as a separate
>> file, so they can rebuild the initrd separately from the kernel image -
>> i.e. ship a binary zImage for the kernel, but build the initrd at
>> (distro or kernel update) install time based on whether the user needs
>> RAID, LVM, crypto, random driver, ... modules or not. Rebuilding a
>> separate initrd file is pretty easy. Rebuilding the initramfs already
>> embedded into the kernel zImage is probably not.
> 
> This is definitelly a good point. But then, if you can load zImage, can't you 
> load initrd with u-boot?

Well maybe. I don't exactly follow what you're saying. My main point was
the if you need/want an initrd (which I think will become more common),
you're going to have to use mkimage to get U-Boot to accept it. If
you're using mkimage on the initrd anyway, then using mkimage on the
zImage seems like basically no extra work; just one more command to run
using tools you already have. I /think/ the only advantage of a bootz
command over bootm is the ability not to run mkimage on the zImage.
Hence, there's not much advantage to a bootz command.

Still, if you don't have an initrd, I guess a bootz command would save
you the mkimage step on the zImage.

Either way, I'm not really arguing against a bootz command; just
pointing out that in many cases it doesn't buy you that much. Still, it
does in other cases.

>>>> b) The distro will most likely want to specify either the entire Linux
>>>> command-line, or at least something to append to it. I imagine this will
>>>> work by the distro creating a uImage-wrapped U-Boot script e.g.
>>>> /boot/script.uimg. Creating that script would require mkimage too.
>>>> Perhaps again U-Boot could be modified to support loading scripts from
>>>> disk and executing them without requiring a uImage header though.
>>>>
>>>> So, I don't think eliminating mkimage entirely is all that likely. And
>>>> as such, using mkimage for the kernel itself doesn't seem like a big
>>>> deal.
>>>
>>> Hm, isn't FDT supposed to contain the command line now ?
>>
>> Well, I don't think FDT supoprt is far enough along for any (ARM) SoC
>> that a distro could exclusively rely on it yet. But, I may be wrong. I'm
>> also thinking only of mainline; downstream support may be far more
>> advanced in many cases.
>>
>> Either way, the physical mechanism of passing the command-line to the
>> kernel (ATAGs vs. FDT) isn't relevant to this discussion; it's just a
>> transport mechanism.
>>
>> Distros will probably still need to adjust the command-line, e.g. to add
>> "quiet splash" to it or not based on whether a recovery or regular boot
>> is required.
> 
> That's true, but you can have the generic command line in FDT and then pass 
> changed command line through u-boot environment. I don't see a reason why you'd 
> want to push it into uImage.

How can you get the cmdline modifications into U-Boot other that through
a (uImage-based) U-Boot script? I don't think a distro installer is
going to grovel in U-Boot's saved environment and modify that to its
wishes (and even if it could, it shouldn't)

-- 
nvpublic

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Wolfgang Denk]

Dear Stephen Warren,

In message <4EBC2096.905@nvidia.com> you wrote:
>
> OK, I'll rework the patch based on your desired naming.

Thanks.

> However, I do wish to point out that U-Boot's use of the term "load" for
> what is really a "copy"/"move" is incorrect according to the typically
> accepted meaning of the word "load". The extload/fatload commands use
> "load" correctly. I admit relocate is also not a correct phrase to
> describe what's happening.

I agree that these terms are often used intermixed, and few people
actually think about their meaning.  [Just look up in the mailing list
how many people complained that "bootm" did not work when they
"loaded" the images to the address given in the "load adress" field.]

However, I still think that as far as "bootm" is related, the term
"load" is the correct one.  Quoting for example wikipedia:

	In computing, a loader is the part of an operating system that
	is responsible for loading programs. It is one of the
	essential stages in the process of starting a program, as it
	places programs into memory and prepares them for execution.
	Loading a program involves reading the contents of executable
	file, the file containing the program text, into memory, and
	then carrying out other required preparatory tasks to prepare
	the executable for running. Once loading is complete, the
	operating system starts the program by passing control to the
	loaded program code.

	[http://en.wikipedia.org/wiki/Program_loader]

As for extload/fatload - well, these perform "loading" functions to,
in the sense of "reading the contents of a file into memory".

I agree that these terms are often used intermixed, and few people
actually think about their meaning.  [Just look up in the mailing list
how many people complained that "bootm" did not work when they
"loaded" the images to the address given in the "load adress" field.]

However, I still think that as far as "bootm" is related, the term
"load" is the correct one.  Quoting for example wikipedia:

	In computing, a loader is the part of an operating system that
	is responsible for loading programs. It is one of the
	essential stages in the process of starting a program, as it
	places programs into memory and prepares them for execution.
	Loading a program involves reading the contents of executable
	file, the file containing the program text, into memory, and
	then carrying out other required preparatory tasks to prepare
	the executable for running. Once loading is complete, the
	operating system starts the program by passing control to the
	loaded program code.

	[http://en.wikipedia.org/wiki/Program_loader]

As for extload/fatload - well, these perform "loading" functions to,
in the sense of "reading the contents of a file into memory".  But I
don't think much thought was spent on these names when they were
chosen...

> > "bootm" is to boot Linux.  I am not aware of any other OS that can be
> > successfully booted with the "bootm" command (and ifso, it probably
> > gould be started with "go" as well).
> 
> I didn't want to burden my previous email with details, and I quite
> admit I may be wrong here since I'm not familiar with U-Boot's code, but
> what about the following in cmd_bootm.c:

Indeed, you are right.  I had completely forgotten about these.  Heck,
how long didn't I use any of these any more...

> Don't they allow the bootm command to boot other OSs? Those functions
> certainly appear to be called at the end of cmd_bootm() to do the actual
> kernel parameter setup and boot.

Yes, you are right.  Please ignore my comment.

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 at denx.de
Remember that Beethoven wrote his first symphony in C ...

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Marek Vasut]

> Dear Marek Vasut,
> 
> In message <201111101940.40863.marek.vasut@gmail.com> you wrote:
> > So basically, in the end, we need to 1) load zImage, 2) load initrd and
> > 3) adjust command line. 1) and 2) can be done via standard commands, 3)
> > via some script.
> 
> Actually there is a _little_ more to do for the boot loader. There are
> obvious functions (like passing information about size and addresses
> of avialable memory), less obvious things (like inserting the MAC
> addresses for the network interfaces into the device tree, thus
> passing them to the LInux kernel - something that has been impossible
> so far in ARM land), and even adaption of the device troo to the
> actual hardware - boards that come in different versions canuse this
> do disable non-existing (on this board) function blocks in the DT,
> etc. etc.

Of course, but for that we have external functions (or functions which can be 
made external).

M

[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Marek Vasut]

> On 11/10/2011 11:40 AM, Marek Vasut wrote:
> >> On 11/10/2011 11:07 AM, Marek Vasut wrote:
> >>> Stephen Warren wrote:
> >> ...
> >> 
> >>>> I did consider that not running mkimage at all would be simpler, but
> >>>> there are other places mkimage would still be needed anyway:
> >>>> 
> >>>> a) Any initrd would still need to be wrapped in a uImage for bootm to
> >>>> recognize it. If you wrote a bootz to accept a raw unwrapped initrd, I
> >>>> imagine that same raw initrd recognition code could just as easily be
> >>>> applied to bootm.
> >>> 
> >>> Well if you want an image where you have kernel+initrd, why not use
> >>> initramfs ?
> >> 
> >> As I understand it, initramfs is embedded into the kernel image, and
> >> initrd is a separate file.
> >> 
> >> (existing desktop) distros typically want their initrd as a separate
> >> file, so they can rebuild the initrd separately from the kernel image -
> >> i.e. ship a binary zImage for the kernel, but build the initrd at
> >> (distro or kernel update) install time based on whether the user needs
> >> RAID, LVM, crypto, random driver, ... modules or not. Rebuilding a
> >> separate initrd file is pretty easy. Rebuilding the initramfs already
> >> embedded into the kernel zImage is probably not.
> > 
> > This is definitelly a good point. But then, if you can load zImage, can't
> > you load initrd with u-boot?
> 
> Well maybe. I don't exactly follow what you're saying. My main point was
> the if you need/want an initrd (which I think will become more common),
> you're going to have to use mkimage to get U-Boot to accept it. If
> you're using mkimage on the initrd anyway, then using mkimage on the
> zImage seems like basically no extra work; just one more command to run
> using tools you already have. I /think/ the only advantage of a bootz
> command over bootm is the ability not to run mkimage on the zImage.
> Hence, there's not much advantage to a bootz command.
> 
> Still, if you don't have an initrd, I guess a bootz command would save
> you the mkimage step on the zImage.

Well you're contradicting to yourself. You said using initramfs is bad because 
distros won't have easy way to change it. Now you say adding initrd to uImage 
via mkimage is good. Why the heck can't we just load zImage and initrd without 
the envelope at all, uboot can do that?

> 
> Either way, I'm not really arguing against a bootz command; just
> pointing out that in many cases it doesn't buy you that much. Still, it
> does in other cases.
> 
> >>>> b) The distro will most likely want to specify either the entire Linux
> >>>> command-line, or at least something to append to it. I imagine this
> >>>> will work by the distro creating a uImage-wrapped U-Boot script e.g.
> >>>> /boot/script.uimg. Creating that script would require mkimage too.
> >>>> Perhaps again U-Boot could be modified to support loading scripts
> >>>> from disk and executing them without requiring a uImage header
> >>>> though.
> >>>> 
> >>>> So, I don't think eliminating mkimage entirely is all that likely. And
> >>>> as such, using mkimage for the kernel itself doesn't seem like a big
> >>>> deal.
> >>> 
> >>> Hm, isn't FDT supposed to contain the command line now ?
> >> 
> >> Well, I don't think FDT supoprt is far enough along for any (ARM) SoC
> >> that a distro could exclusively rely on it yet. But, I may be wrong. I'm
> >> also thinking only of mainline; downstream support may be far more
> >> advanced in many cases.
> >> 
> >> Either way, the physical mechanism of passing the command-line to the
> >> kernel (ATAGs vs. FDT) isn't relevant to this discussion; it's just a
> >> transport mechanism.
> >> 
> >> Distros will probably still need to adjust the command-line, e.g. to add
> >> "quiet splash" to it or not based on whether a recovery or regular boot
> >> is required.
> > 
> > That's true, but you can have the generic command line in FDT and then
> > pass changed command line through u-boot environment. I don't see a
> > reason why you'd want to push it into uImage.
> 
> How can you get the cmdline modifications into U-Boot other that through
> a (uImage-based) U-Boot script? I don't think a distro installer is
> going to grovel in U-Boot's saved environment and modify that to its
> wishes (and even if it could, it shouldn't)

No, but uboot can (and often does) source a script on the same device storing 
zImage and initrd. You just adjust the script.