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

[Wolfgang Denk]

Dear Bartek,

in message <477CB301.8070207 at semihalf.com> 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.

> 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).

> 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.

> 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.

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

> 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. 


> Ad. 1. This is equivalent to cases 2,3,8, depending on what the default
> load address points to.
> - boot method: see cases 2,3,8

See above - it's also identical to cases 9 and 10.

> 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".

> Ad. 3. First and second components of B are assumed to be the kernel and
> the initrd, respectively. The kernel is booted with initrd.

kernel and ramdisk images, to be exact (i. e. with 64 byte U-Boot
header).

Note: U-Boot should be able to pass ramdisk addresses as  is,  i.  e.
without  copy  operation, to the Linux kernel. The kernel.org version
of some architectures (like ARM) does not  support  this  (yet),  but
U-Boot shall continue to support this.

> Ad. 5. If A is a kernel image, then F is assumed to be an initrd address,
> and the kernel is booted with the initrd. If A is a standalone
> application image, F is assumed to be an address in memory that overrides
> load address specified in the image. Application is loaded to F and
> started.

Note: AFAICT the standalone case is not documented.

> Ad. 6. A is assumed to be a kernel image. Arguments second and third are
> assumed to be addresses in memory of initrd and FDT, respectively.
> Kernel is booted with initrd.
> - boot method: FDT

Again, it's kernel and ramdisk images.

> Ad. 8. C is assumed to contain a default configuration, which is booted.
> - boot method: FDT or non-FDT, depending on whether the default
>    configuration defines FDT

The classification is not clear to me. I think I understand what  you
mean,  but  without  actually  using the example notations below it's
completely unclear what the differences between 8, 9 and 10 might be.

C is an image, and it shall be booted, depending on what it contains. 

> Ad. 9. Equivalent to case 2, with the only difference being that the
> kernel/standalone application is given as a sub-image specification.
> - boot method: non-FDT

All this becomes overly complicated....

> - boot kernel "kernel at 1" stored in a new uImage located at 200000:
> bootm 200000:kernel at 1
> 
> - boot configuration "cfg at 1" from a new uImage located at 200000:
> bootm 200000#cfg at 1

> - boot "kernel at 1" from a new uImage at 200000 with initrd "ramdisk at 2"
>    found in some other new uImage stored at address 800000:
> bootm 200000:kernel at 1 800000:ramdisk at 2
> 
> - boot "kernel at 2" from a new uImage at 200000, with initrd "ramdisk at 1"
>    and FDT "fdt at 1", both stored in some other new uImage located at
>    800000:
> bootm 200000:kernel at 1 800000:ramdisk at 1 800000:fdt at 1
> 
> - boot kernel "kernel at 2" with initrd "ramdisk at 2", both stored in a new
>    uImage at address 200000, with a raw FDT blob stored at address 600000:
> bootm 200000:kernel at 2 200000:ramdisk at 2 600000
> 
> - boot kernel "kernel at 2" from new uImage at 200000 with FDT "fdt at 1" from
>    the same new uImage:
> bootm 200000:kernel at 2 - 200000:fdt at 1

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.

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

or (assuming that the image was just downloaded to 200000)

	bootm :kernel at 2 - :fdt at 1


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
If the hours are long enough and the pay  is  short  enough,  someone
will say it's women's work.