[U-Boot] [PATCH v2 18/22] armv7: embed u-boot size within u-boot for use from SPL

[Wolfgang Denk]

Dear Aneesh V,

In message <4DD352EA.3090007 at ti.com> you wrote:
> 
> > What you are doing here is defining an image format. Such an image
> > format must be good enough not only for OMAP4 and for loading U-Boot
> > as second stage, but for all other architectures and use cases as
> > well.
> 
> I am not defining and publishing a format for the external world. It's

In the essence this is what you are doing: you are defining an
interface how the payload has to look like.  Anything not meeting this
"specification" or "image format" or "ABI" or whatever you call it
will not be directly loadable by the SPL.

But I want to make sure that we can load arbitrary payloads as second
stage, not only U-Boot images.  Because we cannot guarantee that we
can embed such information into other payloads we may want to load, we
must prepend or append such information, but not embed it somewhere
within the image itself.

> just an internal information much like any other info embedded in
> start.S such as  _bss_end_ofs, _end_ofs etc. It's just that SPL, being
> an insider, can take advantage of it.

This is not quite correct. SPL needs this information.  We are defining
an API here, and we should make sure it fits the use cases we can see
now (and ideally is flexible enough so we can adjust/extend it for
future use).

> I feel creating a new mkimage target just for this will be an overkill.

We don't have to create a new format. We can, for example, use the
existing format with a prepended 64 byte header. The only thing that
needs changes is that we now have to consider the header when loading
the image, but the same problem will always exist when we accept that
we cannot embed the information within the payload. We don't need any
new code to implement this solution. We can easily create the images
using "mkimage -T firmware -O u-boot".

> I will be happy loading the maximum image size always.

This makes no sense.  What is "the maximum image size always"? 4 MB,
so we can also load a Linux kernel as payload? 8 MB, so we can stil do
this in a year from now?

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
A metaphor is like a simile.