From mboxrd@z Thu Jan  1 00:00:00 1970
From: Timur Tabi <timur@freescale.com>
Date: Thu, 25 Jan 2007 10:10:18 -0600
Subject: [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.
In-Reply-To: <46B96294322F7D458F9648B60E15112C082EB6@zch01exm26.fsl.freescale.net>
References: <20070107104008.C0083352636@atlas.denx.de>	<45A8863C.1040303@orkun.us>
	<46B96294322F7D458F9648B60E15112C082EB6@zch01exm26.fsl.freescale.net>
Message-ID: <45B8D66A.6080209@freescale.com>
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

Zhang Wei-r63237 wrote:
> Hi, Wolfgang,
> 
> It's so pity that the flash got wrong 'num_erase_regions' issue is still
> in u-boot 1.2.0.
> 
> The byte by byte accessing is not preferred. But the flash_read_ushort()
> and flash_read_long() in drivers/cfi_flash.c are both implemented by
> byte accessing. How about it?
> 
> Can the instruction '
> 	retval = (addr[0] << 16) | (addr[(info->portwidth)] << 24) |
> 		(addr[(2 * info->portwidth)]) | (addr[(3 *
> info->portwidth)] << 8);'
> In flash_read_long() be replaced by memcpy() function?

I really don't think we should be using mempcy().  You're not supposed 
to care about the internal implementation of mempcy(), so if we start 
using it for specific-sized reads, then we start caring about how it's 
implemented.

If you want to read 32 bits at one time, then just do a 32-bit read!

	retval = * (ulong *) addr;

Looking at the code, I don't understand why it's so complicated.  If 
portwidth is 2, then retval above will be a conglomeration of addr[0], 
addr[2], addr[4], and addr[6].  Why isn't it just reading from 
[0][1][2][3]??