[U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.

[Chris Fester]

I'm interested in how this discussion pans out.  I have encountered this
problem (with flinfo) with my MPC8641HPCN.  The patch presented by Zhang
Wei (and other freescale employees) does seem to allieviate the problem
when I compile u-boot with ELDK 4.0.

However, some scenarios here worry me:
-- with the patch, compiled with ELDK 4.0 is peachy.
-- without the patch, compiled with ELDK 4.0 FAILS.
-- without the patch, compiled with ELDK 3.1.1 is peachy.

At the time of my testing (early this week) I was using a git tree about
2 weeks old from jdl.com, which is what the freescale folks seem to be
using at the moment.  It worries me that changing a compiler version
could affect this bug, but I guess I've seen stranger things.

Could this be a subtle timing problem with the processor?  Could it be a
timing problem with the flash?  Am I nuts?  :P

Merry Christmas!
Chris

On Fri, 2006-12-22 at 15:11 +0100, Wolfgang Denk wrote:
> In message <458BBB5D.1030005 at 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
>