Thanks Machael.<br>
<br>
On my flash data sheet, there are some command about security:<br>
<br>
Lock Block | Block Address | 0060h | Block Address | 0001h<br>
Unlock Block|Block Address| 0060h | Block Address | 00d0h<br>
<br>
So I guess it needs two write cycle to perfomr the command, and the
unlock command should be 006000d0. I tried that but still get the same
error. Bad! :(<br>
<br>
Another questions is that is there any way to change CPU register
directy? For 8343E all registers are mapped to 1m starting from
0xff400000. I want to change on 0Xff400c08, but visionclick reject me
to write on that address.<br>
<br>
- Reeve<br><br><div><span class="gmail_quote">On 9/29/06, <b class="gmail_sendername">Michael Galassi</b> <<a href="mailto:mgalassi@c-cor.com">mgalassi@c-cor.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>>>Hello linux-ppc experts,<br>>><br>>>I'm trying to use using wind river jtag probe to download uboot to our<br>>>switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).<br>>>Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M. The
<br>>>JTAG software I'm using is visionclick8.<br>>><br>>>The problem now is that I even couldn't erash flash, with following error<br>>>message:<br>>><br>>>TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
<br>>>Erasing Flash(s) ... Failed<br>>>!ERROR! - [msg100000] Failed while erasing the device(s)<br>>>>BKM><br>>>!HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x00007404 [EVENT<br>
>>Taken]<br>>>>BKM><br>>><br>>>Does anyone has experiece to bring up this CPU, and could shed some lights<br>>>on it? Thank you in advance.<br>>><br>>>- Reeve<br>><br>>Your flash part[s] are almost certainly write-protected, or part of them
<br>>is. Get the data-sheet for them and find what combination to write to<br>>them to un-protect them and try again. For the parts I'm using (micron<br>>MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does
<br>>the trick.<br>><br>>-michael<br><br>I must be lonely, responding to my own email :-).<br><br>The other option you have is re-build u-boot to run from ram (presumably<br>at some lower address), then use u-boot itself to clear the write
<br>protect bits on your flash. U-boot's makefile has config targets for<br>ram & flash for some target boards which you may be able to take<br>advantage of. My first solution is probably still quicker if you're not
<br>trying to debug u-boot itself.<br><br>-michael<br></blockquote></div><br>