From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerry Van Baren <gerald.vanbaren@ge.com>
Date: Tue, 18 Dec 2007 10:33:35 -0500
Subject: [U-Boot-Users] RFC: New U-boot image format
In-Reply-To: <4767E487.8020103@freescale.com>
References: <475EB857.4080104@semihalf.com> <4767E487.8020103@freescale.com>
Message-ID: <4767E84F.3010805@ge.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Timur Tabi wrote:
> Marian Balakowicz wrote:
>> Hello,
>>
>> New format for U-boot images has been on the list few times already.
>> There were different ideas and features discussed but no final
>> conclusion has been made.
> 
> I have a request for a new feature.  I think we need image-format plug-ins. 
> That is, we need a way for a plug-in to register itself with the main format 
> processing code.  When the processing code sees a blob that it doesn't 
> understand, it calls the plug-in to handle it.
> 
> This would be a handy way to handle stuff like the QE firmware binary blob 
> format (see the thread titled "[PATCH] 85xx: add ability to upload QE 
> firmware").  The format of the QE firmware blob has already been decided, so all 
> I would need from the multi-image format is:
> 
> 1) A way to package my blob.
> 2) A way to pass the address of the blob to the QE code
> 
> For option #2, setting an environment variable would be the easiest.  To do 
> that, the QE code could register a call-back that says, "If you see a QE 
> firmware blob, call this function and pass the address of the blob".

Hi Timur,

#1 is already in there in the form of properties:
<http://article.gmane.org/gmane.comp.boot-loaders.u-boot/34055>
- 'component' subnode shall support:
     - label property
     - type property
     - hash properties (crc32, md5, sha1, etc.)
     - data compression type property (compressions
       currently supported by U-boot)
     - data size property
     - timestamps property

     - properties corresponding to remaining header
       fields from the old image format:

         os type, cpu architecture properties
         data load address
         entry points for executable images

I think you have #2 backwards.  I envision the board/CPU specific code 
querying the multi-image blob for specific QE firmware (for instance, 
some boards may want serial fixup firmware rather than ethernet 
enhancement firmware, both of which could be in the multi-image) and 
loading it.  I envision this as part of the board/CPU QE handling code 
(the part-of-u-boot GPL code you wrote).

Since libfdt can find the QE firmware and the properties associated with 
that firmware, including the necessary address(es), your "qe" command 
(and the C function corresponding to it) would not need an address at 
all (I would make it optional rather than removing it, so the 
multi-image value could be overridden).

Best regards,
gvb