From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Subject: Re: [RFC] Introducing yamldt, a yaml to dtb compiler Date: Mon, 31 Jul 2017 18:38:34 +1000 Message-ID: References: <1501174151.1055.8.camel@hp800z> <1501181931.1055.18.camel@hp800z> <597A4B80.7000106@gmail.com> <1501191985.1055.50.camel@hp800z> <20170728005140.GF26163@bill-the-cat> <20170731055316.GG2652@umbus.fritz.box> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WHd9vrGlqw/UgozotE+ncy9j5e4plNZrTCAEWz5UYNU=; b=hoQ2g6RIMJgyk5C72/3pIYjAFfIuEpWUci7WioP8Sauwof9OpAtnme/FI6k0zLh0co /8eLEGOCFyxYiB040zYrwfEUUyKGldRg+opRAa0eV8es2X66KiDZvgn/R0iOosTFoPV2 Qq7FGNNkYJc8PhMWtiTyZpTll5PvNFsFgJuEQu2CuIZXa9rEmrHi823b011qwPtCsLGF IiT6xSmGh7GdrD7gNKNA2rffV4L6mQpemj3+MGLUYVFtcXPrwIFj0GcqLl1PJh005wFe vQsvL7XCeRcjWjMFNhj6yummc8qMHPZZeffGSwExWWs1NOeqL62dtWJDNZa3xbA4xZFq Hygg== In-Reply-To: <20170731055316.GG2652-K0bRW+63XPQe6aEkudXLsA@public.gmane.org> Sender: devicetree-compiler-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Gibson Cc: Rob Herring , Tom Rini , Pantelis Antoniou , Frank Rowand , Grant Likely , Franklin S Cooper Jr , Matt Porter , Simon Glass , Phil Elwell , Geert Uytterhoeven , Marek Vasut , Devicetree Compiler , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" On Mon, Jul 31, 2017 at 3:53 PM, David Gibson 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 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 >> >> 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