From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: Request review of device tree documentation Date: Sat, 12 Jun 2010 20:48:04 +1000 Message-ID: <1276339684.1962.186.camel@pasglop> References: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com> <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1276339529.1962.184.camel@pasglop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Mitch Bradley Cc: microblaze-uclinux-rVRm/Wmeqae7NGdpmJTKYQ@public.gmane.org, devicetree-discuss , linuxppc-dev , Dan Malek , Jeremy Kerr List-Id: devicetree@vger.kernel.org On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote: > > It seems that many of the differences at the CPU level can be determined > > by looking at "coprocessor" registers. For what purpose(s) do we need > > to identify the core? That will inform our choice of a core ID schema. > > The primary thing I see would be architecture version compliance, > though this is better carried additionally via a binary field in > the header or a GPR at the entry point, to help the initial asm > code to setup the MMU etc... before getting into C code. Also, if you're going to revive a "real" OF port to ARM (with client interface etc...), should we start considering moving some of powerpc's prom_init.c to a generic place ? IE. prom_init is a trampoline that uses the client interface to essentially create a flatten device-tree and enter the kernel via the common "epapr" style entry point. The main drawback is that it doesn't allow to keep OF alive along with the OS, but then, only sparc does that successfully and I'm not sure it's something that would be practical to do on ARM either. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id A1190B7DA9 for ; Sat, 12 Jun 2010 20:48:23 +1000 (EST) Subject: Re: Request review of device tree documentation From: Benjamin Herrenschmidt To: Mitch Bradley In-Reply-To: <1276339529.1962.184.camel@pasglop> References: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com> <4C13430B.5000907@firmworks.com> <1276339529.1962.184.camel@pasglop> Content-Type: text/plain; charset="UTF-8" Date: Sat, 12 Jun 2010 20:48:04 +1000 Message-ID: <1276339684.1962.186.camel@pasglop> Mime-Version: 1.0 Cc: microblaze-uclinux@itee.uq.edu.au, devicetree-discuss , linuxppc-dev , Olof Johansson , Dan Malek , Jeremy Kerr List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote: > > It seems that many of the differences at the CPU level can be determined > > by looking at "coprocessor" registers. For what purpose(s) do we need > > to identify the core? That will inform our choice of a core ID schema. > > The primary thing I see would be architecture version compliance, > though this is better carried additionally via a binary field in > the header or a GPR at the entry point, to help the initial asm > code to setup the MMU etc... before getting into C code. Also, if you're going to revive a "real" OF port to ARM (with client interface etc...), should we start considering moving some of powerpc's prom_init.c to a generic place ? IE. prom_init is a trampoline that uses the client interface to essentially create a flatten device-tree and enter the kernel via the common "epapr" style entry point. The main drawback is that it doesn't allow to keep OF alive along with the OS, but then, only sparc does that successfully and I'm not sure it's something that would be practical to do on ARM either. Cheers, Ben.