From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hawkins Date: Wed, 12 Sep 2007 11:00:57 -0700 Subject: [U-Boot-Users] minimum bdi config to read flash on 85xx In-Reply-To: References: <46DDCAED.8080006@ovro.caltech.edu> <46DEDAC0.10602@ovro.caltech.edu> <46DF1D78.2000001@ovro.caltech.edu> <50d8dde80709061403t576d0720lf1461bd6ee9e6730@mail.gmail.com> <46E079E5.5000102@ovro.caltech.edu> <50d8dde80709061841o61fa17ecmcebee9229c696190@mail.gmail.com> <46E0B0A6.8050306@ovro.caltech.edu> Message-ID: <46E82959.2090107@ovro.caltech.edu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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