[U-Boot-Users] RFC: New U-boot image format

[Jerry Van Baren <gerald.vanbaren@ge.com>]

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