Wolfgang Denk wrote:
I'm not sure if such firmware shouldbe part of the device tree, or rather a separate image or part of the image.
The firmware itself is not part of the device tree, just a few pieces of information about the firmware. I need some way to pass information from U-Boot to the kernel, and my choices are the device tree or command line. The command line is clunky, and so I thought the device tree is best place. This design decision has already been reviewed (and approved by Arnd) on the kernel mailing lists.
The firmware blob needs to be a separate image because the code and firmware layout is meant to be cross-platform, so I can't use any U-Boot-specific wrapper. In addition, the firmware itself is not GPL, so I can't merge it with GPL code, or anything else for that matter. It needs to exist as an independent entity. The code which uploads the blob into the QE is GPL, of course.
Actually I think the definition of such a blob, if needed at all, should only be a tamporary workaround unti we have the new image format in place. Then this should become part of the new image implementation.
The design and layout of the firmware blob is specific to the needs of the QE. I don't see how a new image format will help. I'll only use the new image format to wrap the binary.
The goal is to have this firmware blob sitting in flash somewhere, all I need to do to upload it is:
qe fw $fwaddr
The ability to upload firmware to the QE in U-Boot is needed by QE microcode developers.
Please follow the ongoing discussions of this topic and make sure to voice your wishes and requirements.
Are you talking about "RFC: New U-boot image format"? If so, then I just don't see how that applies. I don't want a new binary format, because I already have one defined that works. If you want me to add support for my binary blob wrapped in some other kind of image format, I can add that *after* this patch has been applied, since the ability to accept these binary blobs as-is is necessary.