[U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.
listmember at orkun.us
Sun Jan 7 11:12:07 CET 2007
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
>>> 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.
More information about the U-Boot