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

[Stefan Roese <sr@denx.de>]

On Thursday 04 January 2007 10:23, Wolfgang Denk wrote:
> > Wolfgang Denk wrote:
> > > Now this is what I want to understand. What exactly is the "potential
> > > problem"?
> >
> > That's the issue in the flash 'Spinsion S29GL064M90TFIR6' with x16
> > connection. After running flash_read_jedec_ids(), any follow CFI query
> > command will get the data with high 8bit = 0xff, but the low 8bit is
> > valid. And if we only read low 8bit, we'll get the 0xff too. In
> > addition, the second follow CFI query command has no that issue. So, I
> > read the full 16bit date and only take the valid low 8bit.
>
> etc. etc.
>
> I didn't see any new facts in your current posting. My  position  has
> not  changed  either:  I don't see how your character-wise copy using
> memcpy() would be different from accessing the flash through a  uchar
> pointer;  also  I  still  think  that if the compiler version changes
> behaviour then we don't really understand what's going on here.
>
> Maybe Tolunay or Stefan can comment now that both are back from their
> Xmas breaks; they both know the CFI driver much better than me.

What I noticed after looking at the flash access functions like 
flash_read_uchar() is that no access macros and even no volatile pointer 
access is used to read from the flash. This looks like a potential problem, 
that can show when using different compiler versions.

Please find attached a small patch that adds fixes this potential problem for 
the 3 functions flash_read_uchar/ushort/long. Please give it a try and let me 
know if this changed the behavior somehow.

Thanks.

Best regards,
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfi_flash_volatile.patch
Type: text/x-diff
Size: 908 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070105/bb1f4dcd/attachment.patch