[U-Boot-Users] [PATCH] CFI driver AMD Command Set Top boot geometry reversal, etc. [Updated]
timur at freescale.com
Fri Nov 10 22:31:56 CET 2006
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?
Linux Kernel Developer @ Freescale
More information about the U-Boot