[U-Boot-Users] minimum bdi config to read flash on 85xx

[David Hawkins <dwh@ovro.caltech.edu>]

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?

> 1) 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 :)

> 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.

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