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

[Tolunay Orkun <listmember@orkun.us>]

Stefan Roese wrote:
> 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.

I think this is a good idea given GCC 4.x is agressive in optimizations. 
I do not think converting these to use memcpy() is a good idea. I am 
with Wolfgang on this.

I think we should commit Stefan's patch even if it might or might not 
solve the problem Zhang is experiencing.

Best regards,
Tolunay