All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Sieka <tur@semihalf.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Scott Wood <scottwood@freescale.com>,
	linuxppc-dev@ozlabs.org, jdl@jdl.com
Subject: Re: [PATCH] Add support for binary includes.
Date: Fri, 22 Feb 2008 09:34:49 +0100	[thread overview]
Message-ID: <47BE8929.3050805@semihalf.com> (raw)
In-Reply-To: <fa686aa40802212205p38c3793bg8793740955b1e91@mail.gmail.com>

Grant Likely wrote:
> On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <scottwood@freescale.com> 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

  reply	other threads:[~2008-02-22  9:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-20 19:19 [PATCH] Add support for binary includes Scott Wood
2008-02-22  5:34 ` David Gibson
2008-02-22 18:12   ` Jon Loeliger
2008-02-25  3:38     ` David Gibson
2008-02-22  6:05 ` Grant Likely
2008-02-22  8:34   ` Bartlomiej Sieka [this message]
2008-02-22  9:02   ` David Woodhouse
2008-02-22 15:50     ` Grant Likely
2008-02-22 16:08   ` Scott Wood
2008-02-22 16:24     ` Jon Loeliger
2008-02-22 16:28       ` Scott Wood
2008-02-26  0:39 ` David Gibson
2008-02-26 17:26   ` Scott Wood
2008-05-27 15:27   ` Kumar Gala
2008-05-27 17:59     ` Jon Loeliger
2008-05-28 23:58       ` David Gibson
2008-05-29  0:02         ` David Gibson
2008-05-30 18:54           ` Scott Wood
2008-06-04  4:13             ` David Gibson
2008-06-04 12:36               ` Bartlomiej Sieka
2008-06-04 14:26               ` Jon Loeliger
2008-06-05  3:11                 ` Josh Boyer
2008-06-11  1:58                 ` dtc: " David Gibson
2008-06-12 16:43                   ` Scott Wood
2008-06-13  0:01                     ` David Gibson
2008-06-13  0:46                       ` Jon Loeliger
2008-06-13  3:41                         ` David Gibson
2008-05-29 14:04         ` [PATCH] " Jon Loeliger
2008-05-30  1:34           ` David Gibson
2008-06-02 20:22             ` Jon Loeliger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47BE8929.3050805@semihalf.com \
    --to=tur@semihalf.com \
    --cc=grant.likely@secretlab.ca \
    --cc=jdl@jdl.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.