Subject: Re: [PATCH] Add support for binary includes.

From: Bartlomiej Sieka <[email-masked]>
Date: Fri, 22 Feb 2008 09:34:49 +0100

Grant Likely wrote:
> On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <[email-masked]> wrote:
>> A property's data can be populated with a file's contents
>>  as follows:
>>
>>  node {
>>         prop = /incbin/("path/to/data");
>>  };
>>
>>  A subset of a file can be included by passing start and size parameters.
>>  For example, to include bytes 8 through 23:
>>
>>  node {
>>         prop = /incbin/("path/to/data", 8, 16);
>>  };
> 
> 
> Can I ask; what is the intended usage of such a thing?  How large
> would a typical binary blob be?

Binary includes are a critical feature of the new image format for
U-Boot. In short: we're describing image's content and other data
(architecture, os, image type, etc) in dts format, and then use dtc to
generate the file that is transferred to the target and booted by
U-Boot. Excerpt from an actual file describing an image:

/{
         images {
                 kernel@1 {
                         data = /incbin/("./vmlinux.bin.gz");
                         type = "kernel";
                         arch = "ppc";
                         os = "linux";
                         compression = "gzip";
                         load = <00000000>;
                         entry = <00000000>;
                 };
         };
};

As to the size of the final blob in our case, it depends. It seems that
in case of a powerpc Linux booting scenario, most of the times the size
will be roughly the size of a compressed kernel + the size of the FDT
blob, eventually plus the size of a ramdisk. Note however, that the new
image format has provisions for handling multiple components of the same
type in one image, so for example you could have three kernels, two
ramdisks and a couple of fdt blobs in one image, and the actual booting
configuration could be selected in U-Boot. In such a case, the final
blob can be arbitrarily large.

Regards,
Bartlomiej