On 9/6/07, David Hawkins dwh@ovro.caltech.edu wrote:
Eg. to read the manufacturer ID perform the following sequence, where wm.b means write memory byte, but you'll need to replace this with the BDI2000 equivalent, which I can't recall at the moment :) (and the 0x might be optional too). The point is this will help you understand how to use the table:
wm.b 0x555 0xAA wm.b 0x2AA 0x55 wm.b 0x555 0x90 wm.b 0x000 0x01
and then read say 8 bytes from the flash
md.b 8
Somewhere in the data sheet it'll tell you what the Spansion manufacturer ID is supposed to be.
The 0x555 0xAA 0x2AA 0x55 is called the unlock sequence, the remaining bytes are then command codes.
Thanks all for the help so far. I'm going to jump back in the discussion at this part in the thread. We ran out of S29GL01GP chips so we temporarily moved to the S29GL512P 64MB chip, with a chip size of 4000000. The good news is after jumpering the board to the correct addresses we can do a "mdf 0xfc000000" and get all F's . We can also do a "erase 0xfc000000 CHIP" and the command completes successfully.
When we do a "prog 0xfc000000 uboot.bin bin" however, we get ""Programming flash memory failed" . Our questions at this point are:
1) If we can do an erase as shown above does that mean our unlocking sequence has been performed correctly?
What's confusing us here is that the "0x555 0xAA 0x2AA 0x55" sequence seems to be the same for our current S29GL512P, the S29GL01GP, Ben's S29GL064M, and the MPC8548CDS chip , the AM29LV641D. Maybe some CFI standard thing? Anyways. Ben's sequence and an example I found for the CDS board is this:
; Enable flash programming WM16 0xfe000000 0x0060 ;clear flash lock-bits WM16 0xfe000000 0x00d0 DELAY 1000 WM16 0xfe000000 0xffff
In our case 0xfe000000 becomes 0xfc000000. We found a 8540ads with the same code. In the 8548cds case they seem to use the equivalent for 0xFF800000 with WM32. In all these examples where not sure where these addresses come from as they don't seem to be clearly from the respective manuals.
We also can execute the unlock command successfully, with this entry in our config files:
ERASE 0xFc000000 CHIP; Erase whole Chip
2) Any other ideas on why we can read and erase but not write our flash?
Thanks all, been quite a ride but I think we're almost ready to get into debugging our u-boot code.
Robert