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

Chris Fester
2006-12-22T17:07:37Z

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@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
>