On Thu, Mar 25, 2010 at 2:04 PM, Timur Tabi <ti...@freescale.com> wrote: > Scott Wood wrote: > >> I don't know that it's strictly necessary in this case -- it looks like >> there is a magic number in the firmware blob -- but I don't understand >> the objection as a matter of principle. These device tree discussions >> have a tendency to get awfully bikesheddy. > > I don't want this discussion, and any binding definitions that come from it, > to be limited to the specifics of a QE firmware. I want to make sure that > any binding that we come up with can be easily extended to any kind of > firmware, including firmware that has no headers. > > Many companies will distribute their firmware as a generic sequence of bytes > (no header), and a simple code fragment that demonstrates uploading the > binary to the hardware. The license for these files sometimes precludes the > option of wrapping that microcode inside or with another binary. That is, if > you want to distribute this firmware, it must be distributed as-is. > > Example: > > Freescale buys a chip from some vendor and puts the chip on a reference > board. The chip requires some microcode to be uploaded, and the vendor > distributes some binary blob and a code snippet. Freescale embeds the code > snippet in Linux, and puts the microcode somewhere in flash. The license for > the microcode says, "thou shalt not merge this microcode with any other > binary". Freescale decides, for whatever reason, that putting a header > around the microcode and putting *that* in flash is a violation of the > license, but having U-Boot dynamically embed it into a DTB isn't. Ok, maybe > that's a bit ridiculous, but just humor me. In this case, it would useful to > have the microcode in its own node with properties describing the microcode. > > Anyway, I may have gone off in the weeds with this discussion.
No, this isn't off in the weeds. I concede the point of needing to store firmware in a separate node, but I still don't agree with the argument that it needs to be anything more than an anonymous named blob. The fact that another node references it implicitly defines the format the blob needs to be in. If the blob format changes, then in practice the existing binding is no longer compatible because older drivers just won't work. It probably doesn't justify creation of a new compatible value, but I would handle firmware in a different format with a different property name to reference it. g. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
