[U-Boot-Users] RFC: New U-boot image format

[Marian Balakowicz <m8@semihalf.com>]

Jerry Van Baren wrote:
> Wolfgang Denk wrote:
>> In message <475EE3AE.6060102@ge.com> you wrote:
> [snip]
> 
>>>> 				os type, cpu architecture properties
>>>> 				data load address
>>>> 				entry points for executable images
>>>>
>>>> 	  Note: the above list is considered *draft* and open to discussion
>>> Which properties are new inventions?  Data compression, timestamps, OS 
>>> Type, CPU arch, data load address, and entry point?  Not a bad thing, 
>>> just trying to understand how much we are extending.
>> All of this already exists, but in a static way.
>>
>> New is: ability to chose checksum method; ability to compine  several
>> blobs into one image in a structured way, so building and booting the
>> equivalent  of  a  multifile  image  with  any combination of kernel,
>> ramdisk and dtb blobs can be done in a clean way.
> 
> Ahh, my question wasn't clear.  The intended question was, which of 
> these properties are new OF (IEEE-1275) or "existing linux kernel" 
> *properties* (I didn't intend to ask which are new capabilities).
> 
> For instance, how to specify an address already exists, obviously, but I 
> suspect a property "data load address" is new.
> 
> The intent behind the question was thinking about how big of a 
> documentation job this will be.

We may want to try to use some of the already defined OF bindings, but I
tend to think that this kind of reuse may become evil. We would be using
properties defined for kernel device tree for purpose that has noting to
do with the real device tree, and that may bring unnecessary confusion.
So, I'd rather opt for a independent specification that introduces a
clear separation, especially that many of the properties will be new anyway.

Cheers,
Marian