From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Subject: Re: RFC: Host-endian device tree format Date: Thu, 20 Jan 2011 09:47:55 +1000 Message-ID: <20110119234755.GA20128@yookeroo> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: 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: Dave Martin Cc: Nicolas Pitre , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org On Wed, Jan 19, 2011 at 04:09:39PM +0000, Dave Martin wrote: > On Wed, Jan 19, 2011 at 3:52 PM, Grant Likely = wrote: > > On Wed, Jan 19, 2011 at 8:41 AM, Nicolas Pitre wrote: > >> On Wed, 19 Jan 2011, Dave Martin wrote: > >>> On Wed, Jan 19, 2011 at 1:41 PM, Grant Likely wrote: > >>> > The dtb isn't so much bigendian as it is network byte order. > >>> > >>> (For me, "network byte order" is a euphemism ... >>> unconstructive rant here>) > >> > >> I concur. > > > > meh. it's all about conventions. =A0When talking about external data, it > > is far more important for everyone to agree on the same representation > > than it is to tailor to each platforms preferences. =A0That said, rant > > away! =A0I love a good tangent. > = > I guess a good example of what I mean is ELF - the endianness of an > ELF image is discoverable, and cross tools do exist -- but because ELF > images are strongly bound to their target platform, running the image > takes precedence over the simplicity of the tools: so the images are > specified in such a way that they can always be host-endian for the > machine they run on, without creating format ambiguities. Yes, there's no technical impediment to making a little-endian dtb format. In fact dtc and libfdt were written with this possibility in mind, to the extent that there are hooks / functions in the right places to make this reasonably straightforward. The fact that there are actually two questions here - the endianness of the framing dtb format, and the endianness of the property values themselves complicates the issue. > Of course, it's stretching things rather a lot to claim that fdt > parsing is performance critical ... or that ELF cross tools work well > in all host/target combinations ... rather it's a niggle. But, there is just no point in creating a variant format. The performance cost is completely negligible (even using the rather stupid conversion macros from libfdt which gcc generates horrible code for). The simplicity of having only one variant for tools to deal with wins, no contest. -- = David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson