[U-Boot-Users] [PATCH] CFI driver AMD Command Set Top boot geometry reversal, etc. [Updated]

[Timur Tabi <timur@freescale.com>]

Stefan Roese wrote:

> As you may notice, even the ID's are not correct (0020 and 22c4 are correct) 
> and the geometry is not correct (bottom instead of top).

It looks like the problem with the IDs (I have them too) is that 
flash_read_jedec_ids() is broken.  After sending the commands, the function 
just reads the regular data instead of the command reply.

I'm reading the CFI spec, and I see this:

"The software must write a 90h to the first location in the device. If the
device returns a Manufacturer?s ID and Component ID, the flash device may be 
accessed as it has been in the past, based on the Manufacturer and Component 
ID. If the device does not return a Manufacturer and Component ID, then the 
device is not a flash memory and other routines are necessary to determine 
what type of device is installed."

The address that flash_read_jedec_ids() uses is fe000000, which is definitely 
the first byte of flash, so I don't know how it can claim that it isn't.  It 
gets even more screwy.  According to the flowchart in appendix A1, after 
writing 90h to fe000000, you're supposed to read back a 90h.  Well, I get a 
4h, which is what's normally there.  I presume these reads and writes only 
work if the memory hasn't been erased?  Because then, if I write anything to 
fe000000, I better get back the same value.

But isn't it possible to write to unerased flash anyway?  Erasing just changes 
all the zeros to ones, and writing can only change a 1 to a 0, so if I write a 
90h to a flash location, I should get back, 0, 90h, 80h, or 10h, right?

The flowchart says that if you don't get back 90h, you're supposed to restore 
the previous value.  But how can you restore it without erasing the entire sector?

Is it possible that my AMD flash chips just don't support the JEDEC interface 
at all, and only CFI?  Does the even make sense?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale