Timur Tabi wrote:
Timur Tabi wrote:
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.
Well, I think I fixed it.
Great :)
In flash_read_jedec_ids(), make this change:
flash_write_cmd(info, 0, 0, FLASH_CMD_READ_ID);
flash_write_cmd(info, 0, AMD_ADDR_START,FLASH_CMD_READ_ID);
I think this change is what was missing which I overlooked. Intel does not need a specific address to write the command nor unlock sequence.
I got the value of AMD_ADDR_START from the MX29LV640BT/BB reference manual, which says that the third bus cycle should be a write of 90h to 555 or AAA, depending on the width.
The documentation on this matter is a bit scattered. Bits and pieces are here and there. It was educational to me as well.
Now when I run flinfo, I get this:
Bank # 1: CFI conformant FLASH (16 x 16) Size: 8 MB in 135 Sectors AMD Standard command set, Manufacturer ID: 0xC2, Device ID: 0xC9 Erase timeout: 16384 ms, write timeout: 1 ms
If this fix is real, then it means that flash_read_jedec_ids() never worked for any AMD part.
There was no flash_read_jedec_ids() before I sent the last patch. I wrote it from scratch and the bug there belongs to me :) Since, I did not have AMD style flash myself was not able to test that path and that is why I was asking you to collect debug data . It is hard to prepare patches for an issue that you do not have in house :) Anyway, I guess we will not need the debug data now.
I will update the patch tonight and resend it yet again.
Tolunay