Hi Robert,
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:
Before assuming an address that reads 0xFFFFFFFF is really your flash, you did double-check that the Flash CE# and OE# signals are active for those accesses correct?
- If we can do an erase as shown above does that mean our unlocking
sequence has been performed correctly?
As I have commented before; if you're unsure, *do it manually*, read the manufacturer ID first, and sector protection, or whatever.
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?
Don't be confused; read the data sheet :)
Yes, its a CFI thing. However, non-CFI JEDEC flash has something similar.
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
I don't see an unlock sequence here though. Perhaps there is an unlock-bypass command earlier on.
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.
I explained earlier the fact that the processor starts off with a default memory map that you can then override. So 0xFF800000 is the default map with an 8MB window at the top of memory, while 0xFE000000 is a 32MB window setup by writes to the local bus registers (OR/BR or whatever they're called).
We also can execute the unlock command successfully, with this entry in our config files:
ERASE 0xFc000000 CHIP; Erase whole Chip
If the chip started out with 0xFFFFFFFF, then you can't really say you've had success :)
- 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.
Go back to basics first;
1. Confirm that accesses to the addresses you believe the Flash are located generate CE# and OE#
(I'm sure you did this, but you didn't re-state it)
2. Use memory commands to read the manufacturer ID
3. Use memory commands to write a word
4. Use memory commands to erase that sector
5. Repeat 3
6. Use memory commands to erase the chip
Then try the software equivalents. Then try programming U-boot.
Cheers, Dave