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

[Aneesh V <aneesh@ti.com>]

Hi Wolfgang,

On Wednesday 18 May 2011 11:36 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4DD352EA.3090007@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.

This is not exactly true. I had implemented a fall-back option albeit
with a maximum size assumed for U-Boot.

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

Agree that mkimage approach works better for different types of
payloads.

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

The existing target u-boot.img works for me. Just a couple of questions:

1. I see that size is at offset 0xC in this header. Is this a standard?
2. I see that the header is 64 bytes. Is that again a standard for
mkimage.
3. Is it ok to add u-boot.img to the target "ALL"?
4. If not, is it ok to add it to "ALL" when CONFIG_SPL is defined? 
Something like this:

  ifeq ($(CONFIG_SPL),y)
  .PHONEY : SPL
-ALL += SPL
+ALL += SPL u-boot.img
  endif

Is it ok to add support for kernel payload as a subsequent incremental
step. That's, right now I intend to parse the mkimage header, find the
size and load address and load the image and pass control to it, but
*without* passing any parameters. Is that ok?