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 10:29:51 -0600 Message-ID: References: <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> <20100614160201.GD9550@shareable.org> 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+glppd-linuxppc64-dev=m.gmane.org@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+glppd-linuxppc64-dev=m.gmane.org@lists.ozlabs.org To: Nicolas Pitre Cc: microblaze-uclinux@itee.uq.edu.au, devicetree-discuss , Jamie Lokier , 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 10:23 AM, Nicolas Pitre wrote: > On Mon, 14 Jun 2010, Jamie Lokier wrote: >> So requiring that a bootloader can update the DT _independently_ of >> everything else is a bit much for some devices. > > In my opinion, this use case you're illustrating above simply could > continue to _not_ use DT at all. =A0If your NOR flash is so small that you > cannot spare some extra erase blocks, then this is a deeply embedded > profile the current DT-on-ARM push is not really meant for. =A0You would > be much better with a minimally configured kernel with all the hardware > info statically compiled into the kernel and get away without all the DT > parsing code altogether, like you're already doing today. > > While I think DT for ARM has advantages, I don't see us dropping the > legacy ARM methods anytime soon, especially for existing or extremely > constrained targets. I completely agree. g.