On Mon, Jul 31, 2017 at 3:53 PM, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jul 27, 2017 at 09:12:40PM -0500, Rob Herring wrote: >> On Thu, Jul 27, 2017 at 7:51 PM, Tom Rini <trini@xxxxxxxxxxxx> wrote: >> > On Thu, Jul 27, 2017 at 06:00:00PM -0500, Rob Herring wrote: >> >> On Thu, Jul 27, 2017 at 4:46 PM, Pantelis Antoniou >> >> <pantelis.antoniou@xxxxxxxxxxxx> wrote: >> >> > Hi Frank, >> >> > >> >> > On Thu, 2017-07-27 at 13:22 -0700, Frank Rowand wrote: >> >> >> Hi Pantelis, >> >> >> >> >> >> Keep in mind one of the reasons Linus says he is very direct is to >> >> >> avoid leading a developer on, so that they don't waste a lot of time >> >> >> trying to resolve the maintainer's issues instead of realizing that >> >> >> the maintainer is saying "no". Please read my current answer as being >> >> >> "no, not likely to ever be accepted", not "no, not in the current form". >> >> >> >> >> >> My first reaction is: no, this is not a good idea for the Linux kernel. >> >> >> >> >> > >> >> > This has nothing to do with the kernel. It spits out valid DTBs that the >> >> > kernel (or anything else) may use. >> >> >> >> Let me rephrase Frank's statement: this is not a good idea for the >> >> main repository of dts files. >> >> >> >> But sure, DTS is already not the only source of DTBs. It comes from >> >> firmware on Power systems. >> > >> > Yes, but unless they're generated from something other than a (at the >> > time) normal DTS, that's not a good example, IMHO. >> >> They aren't. I'm talking about IBM systems. The firmware has its own >> representation and flattens that to a DTB is how I understand it. > > That's correct. To elaborate a bit, for a partition under PowerVM, > there's a real IEEE1275 Open Firmware which generates a "live" device > tree. Early boot code in the kernel flattens that to dtb to pass it > to later boot (this was actually the very first use of dtb, before > anyone thought about directly creating them). > > Under KVM it's a bit more complicated, there's still an IEEE1275 > implementation (SLOF) and a "live" tree, but it builds that tree based > largely on a dtb supplied by qemu. qemu does build that directly > using libfdt and it's own knowledge of the virtual hardware; there's > no dts. > For bare metal boots the firmware (OPAL) supplies a dtb to the kernel, > I believe. I suspect that's essentially built from scratch (probably > using libfdt), although it's possible it has some core piece that's > precompiled from dts. Depending on the boot environment we can either get a hand-crafted DTB (lab) or a DTB that was generated by the low-level firmware that handles system initialisation (production). In either case OPAL converts that DTB into it's own internal representation, probes and populates PCI devices, then generates a new DTB to pass to the kernel. As you can imagine there are a lot of moving parts here so extra tooling to validate the output tree would be nice to have Oliver -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
