Arnd Bergmann wrote: > What does the firmware node contain then? The way I read it, you only put > metadata about the uploaded firmware in there, but not the blob itself, right?
That's correct. The meta-data is only the information that a device driver would need to identify and interact with the microcode. > Is there a case where you don't need the firmware in order to start the > kernel, but still want to provide it in flash? I don't think you'll ever need the firmware to *start* the kernel. > In that case, I think it > would really be better to just put the blob into the tree and only > have the fw loading code in the kernel instead of duplicating it in the boot > loader. That would require the firmware to present in RAM for all time, since the device tree cannot be unloaded. Besides, you might need to have the firmware loaded in U-Boot anyway. If your console is connected to the QE, then you'll need the UART firmware loaded before you can see anything. That's why U-Boot needs its own version. > Regarding the question whether the firmware should be a device node or > a property of another node, I'd prefer a simple property, because the > firmware itself is not really a device you can access, but I don't care > much about that. Technically, the firmware could be considered a device on the QE, because it's loaded into I-RAM and it can significantly alter the behavior of the device. Having it its own node also lets me compartmentalize it. If I want to expand the node and add more properties, it's cleaner. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
