[U-Boot] Generic CFI flash driver is not so generic?

[Choe, Hyun-ho]

2008-11-26 (수), 10:58 +0100, Wolfgang Denk 쓰시길:
> Dear "Choe, Hyun-ho",
> 
> In message <1227678669.15327.62.camel at hades.legend.co.kr> you wrote:
> > I did several tests for my b'd that has CFI Nor erase/write problem.
> > 
> > My main problem is that flash_toggle() function doesn't work properly,
> > it always returns 0 even while bus writing operation is proceeding.
> > I mean, toggle bit doesn't toggle for each read operation. (refer to
> > drivers/mtd/cfi_flash.c)
> 
> Similar problems have been reported before - please see for example
> http://lists.denx.de/pipermail/u-boot/2008-October/042036.html
> 

At first, I also suspected about atomic reading issue. But, IMHO, this
is not the cause of the problem. Please refer to
http://lists.denx.de/pipermail/u-boot/2008-November/043741.html

ldrb/ldrh/ldr is load byte/half-word/word from memory operation in ARM.
I think these operation should be atomic, in all cases.


> > I found two workarounds.
> > 
> > First, small waiting between each read. So, following code doesn't work.
> > 
> > <SNIP>
> > retval = flash_read16(addr) != flash_read16(addr);
> > <SNIP>
> 
> Eventually you are not performing atomic 16 bit read operations.
> 
> > But, following code does work.
> > 
> > <SNIP>
> > u16 d = flash_read16(addr);
> > udelay(1);
> > u16 t = flash_read16(addr);
> > retval = d != t;
> 
> Hm... a plain delay would probably not change this behaviour unless
> you have another problem.
> 

I agree with you. Just a simple delay should not solve this problem.
That is another reason that I think atomic read is not the cause of it.

My second workaround is strange, too.
In ARM code, mapping physical address to logical is actually does
nothing, except re-calculating pointer with sector no. and offset.
It just eating several processor cycles.

> > I don't know exactly that this is caused by specific bus access
> > mechanism, or simply chip silicon bug.
> 
> I think the problem is that for some reason flash_read16() might  not
> result  in  16bit  bus  accesses. Do you have a chance to verify this
> suspicion, for example with a logic analyzer?
> 

Currently, not available. Maybe digital scope is possible after a couple
of days, but it may be impossible to check this kind of problem with it.

> Best regards,
> 
> Wolfgang Denk
>