From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Tue, 27 Nov 2007 13:11:04 -0600
Subject: [U-Boot-Users] [PATCH][RFC] Add common memory fixup function
In-Reply-To: <47F3F98010FF784EBEE6526EAAB078D1024F8805@tq-mailsrv.tq-net.de>
References: <Pine.LNX.4.64.0711261453310.22187@blarg.am.freescale.net>
	<47F3F98010FF784EBEE6526EAAB078D1024F8805@tq-mailsrv.tq-net.de>
Message-ID: <20071127191104.GA4472@loki.buserror.net>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Tue, Nov 27, 2007 at 09:13:06AM +0100, Martin Krause wrote:
> Kumar Gala wrote on Monday, November 26, 2007 9:56 PM:
> > +	addrcell = fdt_getprop(blob, 0, "#address-cells", NULL);
> > +	if ((addrcell) && (*addrcell == 2)) {
> > +		for (i = 0; i <= 7; i++)
> > +			tmp[i] = (start >> ((7 - i) * 8)) & 0xff;
> > +		len = 8;
> > +	} else {
> > +		for (i = 0; i <= 3; i++)
> > +			tmp[i] = (start >> ((3 - i) * 8)) & 0xff;
> > +		len = 4;
> > +	}
> 
> Could this perhaps lead to endianess issues under some special 
> circumstances?

I don't think so -- the device tree is defined as always being big-endian,
regardless of the host endianness (multi-cell values would get a bit weird
otherwise).

-Scott