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:
- A way to package my blob.
- 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