[U-Boot-Users] RFC: new bootm syntax

[Bartlomiej Sieka]

Hello Wolfgang,

You wrote:
[...]
>> A address of old style single image B address of old style multi
>> image (with two or three components) C address of new uImage D new
>> uImage sub-image specification E new uImage configuration
>> specification F address in memory
> 
> What is "address in memory" ? All A...E before are "addresses in 
> memory", too.

Not true for D and E, but otherwise your comment is valid, the
classification might be confusing. F was meant to be an address in
memory, but not of type A, B, C. I'll probably drop the A-F
classification and use concrete syntax instead.

> 
>> 1.  bootm               boot default image, equivalent to cases
>> 2,3,8
> 
> equivalent to cases 2, 3, 8, 9, amd 10.
> 
> There is no such thing as a "default image". bootm without arguments 
> (like "iminfo") simply uses the last image address set, for example, 
> by a load command (like tftp).

"Default image" meant an image located at address set most recently by a
load command etc, or located at CFG_LOAD_ADDR. Better wording might be
"image at current image address", or something similar. I'll reword this.

> 
>> Old uImage: 2.  bootm A             single image, kernel/standalone
>> 
> 
> OS image. Maybe Linux Kernel, maybe another OS image (whatever that 
> may contain).
> 
> Not a standalone image. Standalone images  are  supposed  to  be  run
>  using the "go" command.

See below for questions on standalone apps.

> 
>> 3.  bootm B             multi image, kernel+initrd[+fdt]
> 
> OK.
> 
>> 4.  bootm B -           multi image, kernel[+fdt]
> 
> OK.
> 
>> 5.  bootm A F           single image,
>> kernel+initrd/standalone+load_addr
> 
> No, not a single image. These are *two* images: a Linux kernel image 
> at address A and a ramdisk image at address F.

A is a single image, as opposed to a mutli-file image.

> 
> What do you mean by "+load_addr" ? Looks bogus to me.

Let's consider the following example:

bootm 200000 10000

If the image at address 200000 is of type IH_TYPE_STANDALONE, then the
current code will use 10000 as the load address, no matter what is
specified in header->ih_load. Then the control will be passed to
header->ih_ep (entry point).

> 
>> 6.  bootm A F F         single image, kernel+initrd+fdt
> 
> No, not a single image. These are *two* images plus a FDT blob.
> 
>> 7.  bootm A - F         single image, kernel+fdt
> 
> ok.
> 
>> New uImage: 8.  bootm C             default configuration 9.  bootm
>> D             kernel/standalone 10. bootm E             specific
>> configuration 11. bootm D D|F
>> kernel+initrd/standalone+load_addr 12. bootm D D|F D|F
>> kernel+initrd+fdt 13. bootm D  -  D|F     kernel+fdt
> 
> This makes no sense to me. The whole purpose of the new image  format
>  is  to  make  the image self-describing; I don't see how 8, 9, or 10
>  would be different.

They are different syntactically:

8. bootm 400000
9. bootm 400000:kernel at 1
10. bootm 400000#cfg at 1

But this will become clearer when A-F notation is dropped.

[...]
>> Ad. 2. If A is a kernel image, it is booted. If A is a standalone 
>> application image, it is loaded to the load address specified in
>> the image, and started.
> 
> Note: the officially documented method to start a standalone program 
> is "go".

Well, there's quite a bit of support for standalone applications outside
of the "go" command. For example current image format has provisions for
it; from include/image.h:
dress of new uImage D new
 >> uImage sub-image specification E new uImag
/*
* Image Types
*
* "Standalone Programs" are directly runnable in the environment
* provided by U-Boot; it is expected that (if they behave
* well) you can continue to work in U-Boot after return from
* the Standalone Program.

Also, do_bootm (as indicated already) knows how to handle and run
standalone applications.

The question now is: what to do with support for standalone apps that is
outside of "go"? Should the code be changed to match the documentation?
I'll be more than happy to remove standalone apps support from both
bootm and old/new image format, as it does not logically belong there,
and unnecessarily complicates the code. What is your opinion on such a
change?

[...]
> I think we should try to keep the syntax simple. Please avoid that we
>  have to specify the same address more than once. Please continue to 
> support the notation of the "current" image address, i. e. something 
> like
> 
> bootm or bootm 400000 or bootm 400000 800000>
> 
> should continue to work, no matter if new or old style images are 
> being used.

Yes, "current" image address notation will be supported with the new
image format. Actually, supporting it is the rationale for having
default configuration in the image. This is needed to specify what
should happen when the image at the "current" address has for example
two kernels, etc.

> 
> Instead of
> 
> bootm 200000:kernel at 2 - 200000:fdt at 1
> 
> we probably should be able to write
> 
> bootm 200000:kernel at 2 - :fdt at 1

OK.

> 
> or (assuming that the image was just downloaded to 200000)
> 
> bootm :kernel at 2 - :fdt at 1

OK.

Thanks for your comments.

Regards,
Bartlomiej