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. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
