From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wolfgang Denk <wd@denx.de>
Date: Fri, 22 Dec 2006 15:11:09 +0100
Subject: [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.
In-Reply-To: Your message of "Fri, 22 Dec 2006 19:02:53 +0800."
	<458BBB5D.1030005@freescale.com> 
Message-ID: <20061222141109.C7334352664@atlas.denx.de>
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

In message <458BBB5D.1030005@freescale.com> you wrote:
> 
> After perform flash_read_jedec_ids(), the cfi query read will get an 
> '0xff'. From this flash's specification, the read for flash commands in 
> 16bit port connection should perform 16bit read and ignore the high 8bit 
> data. Although this issue maybe occurs in the special chip, perform the 
> fully 16bit read is a safety operation.

But your patch does NOT perform a 16 bit read. It calls memcpy(); the
default implementation of memcpy [see lib_generic/string.c] does this:

	char *tmp = (char *) dest, *s = (char *) src;

	while (count--)
		*tmp++ = *s++;

i. e. it performs a character copy, too, so it makes no difference
compared to the original code.

> The modification refers to the cfi flash drivers in Linux kernel (The 
> cfi_read_query() function in include/linux/mtd/cfi.h file). It's more 
> easy and clear than making the different type date read for different 
> portwidth (such as ushort_read() for x16, ulong_read() for x32).

I understand your intentions, but your patch does  not  do  what  you
think it does, so if it really fixes the problem on your system there
must be another cause or effect.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Emotions are alien to me.  I'm a scientist.
	-- Spock, "This Side of Paradise", stardate 3417.3