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

Jerry Van Baren
2007-12-18T15:33:35Z

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