Hey guys, Well I bricked a $15k board today :)
The Flash on this ARM926EJ-S core board is 2 512Mbit NOR Spansion S29GL512N-11F chips arranged 32M x 32bit. I was reading & writing to a blank sector just to test out my configs and I noticed that when I did any fill command (b,h,w) to flash, when I read back I didn't get the same results. Here is what a flash fillb 0x20000000 0xaa 128 looks like: 0x20030000: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa 0x20030020: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa 0x20030040: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa 0x20030060: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa Uhhh, that don't look right! I get the same thing if I use fillh or fillw. My cfi config is: flash bank cfi 0x20000000 0x04000000 4 4 0 (length was 0x08000000 but flash probe said it was 0x04000000). flinfo in uboot (when it was working) displayed from 0x20000000 to three sectors shy of 0x27ffffff so don't know if I believe the 0x04000000. But that wasn't the bad news ... when I rebooted ... no u-boot. Displaying memory where uboot "was" showed that half the words of the address where it lived were filled with 0xffff so something went crazy and hosed my flash in areas I wasn't even messing with. I have three versions from SVN I tried, 1411, 1470M and I can't remember the other one. They pretty much did similiar things. I'm behind a firewall and can't update until I leave work so I'll try that in case this is a result of some of the recent churn. Anyone seen anything like this before? The good news is unlike my at91sam9260 board that I hosed last week, I can still talk to the board so that is good! Brain is fried ... looking for suggestions. I'll go home and do a svn update and pray that magically fixes it. Regards, Brian
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
