From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: Request review of device tree documentation Date: Mon, 14 Jun 2010 09:08:16 -0600 Message-ID: References: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com> <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> <1276339684.1962.186.camel@pasglop> <4C13B618.1030006@firmworks.com> <1276383132.1962.195.camel@pasglop> <4C146F18.9030008@firmworks.com> <20100614124438.GF9323@yookeroo> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org To: Nicolas Pitre Cc: microblaze-uclinux@itee.uq.edu.au, devicetree-discuss , linuxppc-dev , Mitch Bradley , Dan Malek , Jeremy Kerr , linux-arm-kernel@lists.infradead.org, David Gibson List-Id: devicetree@vger.kernel.org On Mon, Jun 14, 2010 at 8:59 AM, Nicolas Pitre wrote: > On Mon, 14 Jun 2010, David Gibson wrote: > >> On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: >> Indeed. =A0In fact, the general rule of thumb is really "put as much as >> possible into the most easily replaced layer of the stack". =A0This is, >> incidentally, why I've always been dubious about simple firmwares >> supplying a flattened device tree rather than including the device >> tree template in the kernel, cuboot style. > > The biggest advantage, IMHO, for adding DT to ARM, is actually to > decouple the hardware config information and the kernel. =A0If in the end > the DT has to be shipped in the kernel then we're losing all this > advantage over the current state of things on ARM which still works > pretty well otherwise. > > In the best case, the simple firmware simply has to retrieve the > flattened device tree from flash, and pass it to the kernel just like > some anonymous blob. =A0And the simple firmware only needs to provide a > way for that DT blob to be updatable, like through an upload of a > replacement blob that was prepared offline. =A0Just like a ramdisk image > or the like. > > That doesn't need to be fancier than that, and the goal of having the DT > data tied to the hardware instead of the kernel is achieved. exactly right. g. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gy0-f170.google.com (mail-gy0-f170.google.com [209.85.160.170]) by ozlabs.org (Postfix) with ESMTP id BA624B6EFF for ; Tue, 15 Jun 2010 01:08:38 +1000 (EST) Received: by gyf2 with SMTP id 2so2552050gyf.15 for ; Mon, 14 Jun 2010 08:08:36 -0700 (PDT) MIME-Version: 1.0 Sender: glikely@secretlab.ca In-Reply-To: References: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com> <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> <1276339684.1962.186.camel@pasglop> <4C13B618.1030006@firmworks.com> <1276383132.1962.195.camel@pasglop> <4C146F18.9030008@firmworks.com> <20100614124438.GF9323@yookeroo> From: Grant Likely Date: Mon, 14 Jun 2010 09:08:16 -0600 Message-ID: Subject: Re: Request review of device tree documentation To: Nicolas Pitre Content-Type: text/plain; charset=ISO-8859-1 Cc: microblaze-uclinux@itee.uq.edu.au, devicetree-discuss , linuxppc-dev , Mitch Bradley , Dan Malek , Jeremy Kerr , linux-arm-kernel@lists.infradead.org, David Gibson List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Jun 14, 2010 at 8:59 AM, Nicolas Pitre wrote: > On Mon, 14 Jun 2010, David Gibson wrote: > >> On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: >> Indeed. =A0In fact, the general rule of thumb is really "put as much as >> possible into the most easily replaced layer of the stack". =A0This is, >> incidentally, why I've always been dubious about simple firmwares >> supplying a flattened device tree rather than including the device >> tree template in the kernel, cuboot style. > > The biggest advantage, IMHO, for adding DT to ARM, is actually to > decouple the hardware config information and the kernel. =A0If in the end > the DT has to be shipped in the kernel then we're losing all this > advantage over the current state of things on ARM which still works > pretty well otherwise. > > In the best case, the simple firmware simply has to retrieve the > flattened device tree from flash, and pass it to the kernel just like > some anonymous blob. =A0And the simple firmware only needs to provide a > way for that DT blob to be updatable, like through an upload of a > replacement blob that was prepared offline. =A0Just like a ramdisk image > or the like. > > That doesn't need to be fancier than that, and the goal of having the DT > data tied to the hardware instead of the kernel is achieved. exactly right. g. From mboxrd@z Thu Jan 1 00:00:00 1970 From: grant.likely@secretlab.ca (Grant Likely) Date: Mon, 14 Jun 2010 09:08:16 -0600 Subject: Request review of device tree documentation In-Reply-To: References: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com> <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> <1276339684.1962.186.camel@pasglop> <4C13B618.1030006@firmworks.com> <1276383132.1962.195.camel@pasglop> <4C146F18.9030008@firmworks.com> <20100614124438.GF9323@yookeroo> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jun 14, 2010 at 8:59 AM, Nicolas Pitre wrote: > On Mon, 14 Jun 2010, David Gibson wrote: > >> On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: >> Indeed. ?In fact, the general rule of thumb is really "put as much as >> possible into the most easily replaced layer of the stack". ?This is, >> incidentally, why I've always been dubious about simple firmwares >> supplying a flattened device tree rather than including the device >> tree template in the kernel, cuboot style. > > The biggest advantage, IMHO, for adding DT to ARM, is actually to > decouple the hardware config information and the kernel. ?If in the end > the DT has to be shipped in the kernel then we're losing all this > advantage over the current state of things on ARM which still works > pretty well otherwise. > > In the best case, the simple firmware simply has to retrieve the > flattened device tree from flash, and pass it to the kernel just like > some anonymous blob. ?And the simple firmware only needs to provide a > way for that DT blob to be updatable, like through an upload of a > replacement blob that was prepared offline. ?Just like a ramdisk image > or the like. > > That doesn't need to be fancier than that, and the goal of having the DT > data tied to the hardware instead of the kernel is achieved. exactly right. g.