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

[Marian Balakowicz]

Timur Tabi wrote:
> Marian Balakowicz wrote:
>>
>> 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.

The hooks idea sounds reasonable but, the problem
is that there isn't really any such thing like
"main fromat processing code".

The 'bootm' command code does a lot of image
related manipulation but it's not generic or main
format processing code. It is rather a specialized
command that handles one thing, starting
executables, like kernels or standalone
applications. And it's a command, it will not do
anything unless directly called.

So, having hooks in bootm, you would need to call
bootm and then your 'qe fw' command which is sort
of wired.

There are also other commands that deal with the
images, these are other boot commands like
scsiboot, usbboot, etc, and also imls, imxtract.
And all of them process images directly, finding
necessary information on their own.

Your command seem to be of the same type, it needs
information from the uImage (soon from the New
uImage) and it knows best what it needs.
IMHO, reasonable is to make it get this
information from New uImage directly.

Your current syntax is:
> qe fw <addr>

Extended syntax could be:
qe fw 200000:fw_image at 1

Where 200000 is the address of New uImage and
"fw_image at 1" is a example node name of your blob
data. The New uImage API will allow, in simple way
(one, two calls),  to get other details for a
given image, so you would be able to get the blob
data start address.

More on the New uImage format soon, stay tuned.

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

Cheers,
Marian