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

robert lazarski robertlazarski at gmail.com
Wed Sep 12 19:23:40 CEST 2007


On 9/6/07, David Hawkins <dwh at 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




More information about the U-Boot mailing list