On Thu, 2015-04-23 at 16:13 +0200, Jacek Anaszewski wrote: > How the firmware is related to kernel? These bindings are for kernel, > not for the firmware.
There should be no relation. DT bindings should be kernel agnostic and represent the HW layout, not be designed based on what a given kernel driver wants, but I'm digressing... > DT bindings are compiled to *.dtb file which is concatenated with > zImage. No. First, a "binding" isn't compiled to a dtb, a binding is a piece documentation. A flat device tree *might* be compiled from a dts to a dtb but that isn't necessarily the case. For example, any machine with an actual implementation of Open Firmware will essentially flatten OF internal tree into a dtb at boot time, and that tree is itself generated by forth code. In our case, the device tree is procedurally generated by two layers of firmware, there is no dts "compilation" happening. HostBoot generates a shell and OPAL extends it before flattening it and passing it to the kernel. The "concatenated with zImage" point you make is also a very ARM centric one. ARM provides the *optional* ability to concatenate a dtb with a zImage, but that's specific to ARM zImage wrapper. For example, powerpc can do something similar (but not identical) using the "wrapper" script we have in arch/powerpc/boot where we embed the dtb. However, this too is optional, we have a longer history of having firwmares generating device-trees. Note: We invented the whole FDT business :-) > During system boot device drivers are matched with DT bindings > through 'compatible' property. A driver should have single matching DT > node, i.e. no other driver can probe with the same DT node. > This implies that the node should contain only the properties required > for configuring the related device. I don't see how you goes from A to implying B here. Yes, a device generally will have a single representing node but that doesn't mean that the node only contains what the driver needs. The DT node can contain all sort of auxilliary informations that the driver may or may not be interested in that was deemed potentially relevant or useful by the platform designer. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
