From: Reeve Yang <hidden> Date: 2006-09-29 21:08:32
Hello linux-ppc experts,
I'm trying to use using wind river jtag probe to download uboot to our
switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M. The
JTAG software I'm using is visionclick8.
The problem now is that I even couldn't erash flash, with following error
message:
TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
Erasing Flash(s) ... Failed
!ERROR! - [msg100000] Failed while erasing the device(s)
From: Michael Galassi <hidden> Date: 2006-09-29 21:33:45
Hello linux-ppc experts,
I'm trying to use using wind river jtag probe to download uboot to our
switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M. The
JTAG software I'm using is visionclick8.
The problem now is that I even couldn't erash flash, with following error
message:
TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
Erasing Flash(s) ... Failed
!ERROR! - [msg100000] Failed while erasing the device(s)
Does anyone has experiece to bring up this CPU, and could shed some lights
on it? Thank you in advance.
- Reeve
Your flash part[s] are almost certainly write-protected, or part of them
is. Get the data-sheet for them and find what combination to write to
them to un-protect them and try again. For the parts I'm using (micron
MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does
the trick.
-michael
From: Michael Galassi <hidden> Date: 2006-09-29 21:39:42
quoted
Hello linux-ppc experts,
I'm trying to use using wind river jtag probe to download uboot to our
switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M. The
JTAG software I'm using is visionclick8.
The problem now is that I even couldn't erash flash, with following error
message:
TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
Erasing Flash(s) ... Failed
!ERROR! - [msg100000] Failed while erasing the device(s)
Does anyone has experiece to bring up this CPU, and could shed some lights
on it? Thank you in advance.
- Reeve
Your flash part[s] are almost certainly write-protected, or part of them
is. Get the data-sheet for them and find what combination to write to
them to un-protect them and try again. For the parts I'm using (micron
MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does
the trick.
-michael
I must be lonely, responding to my own email :-).
The other option you have is re-build u-boot to run from ram (presumably
at some lower address), then use u-boot itself to clear the write
protect bits on your flash. U-boot's makefile has config targets for
ram & flash for some target boards which you may be able to take
advantage of. My first solution is probably still quicker if you're not
trying to debug u-boot itself.
-michael
From: Reeve Yang <hidden> Date: 2006-09-29 22:03:24
Thanks Machael.
On my flash data sheet, there are some command about security:
Lock Block | Block Address | 0060h | Block Address | 0001h
Unlock Block|Block Address| 0060h | Block Address | 00d0h
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!
:(
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.
- Reeve
On 9/29/06, Michael Galassi [off-list ref] wrote:
quoted
quoted
Hello linux-ppc experts,
I'm trying to use using wind river jtag probe to download uboot to our
switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).
Memory mapping is starting from 0xFF000000 to 0xFFFFFFFF which is 16M.
The
quoted
quoted
JTAG software I'm using is visionclick8.
The problem now is that I even couldn't erash flash, with following
error
quoted
quoted
message:
TF ERASE FFF00000..FFFFFFFF INTEL 28F128Jx ( 8192 x 16 ) 1 Device
Erasing Flash(s) ... Failed
!ERROR! - [msg100000] Failed while erasing the device(s)
Does anyone has experiece to bring up this CPU, and could shed some
lights
quoted
quoted
on it? Thank you in advance.
- Reeve
Your flash part[s] are almost certainly write-protected, or part of them
is. Get the data-sheet for them and find what combination to write to
them to un-protect them and try again. For the parts I'm using (micron
MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does
the trick.
-michael
I must be lonely, responding to my own email :-).
The other option you have is re-build u-boot to run from ram (presumably
at some lower address), then use u-boot itself to clear the write
protect bits on your flash. U-boot's makefile has config targets for
ram & flash for some target boards which you may be able to take
advantage of. My first solution is probably still quicker if you're not
trying to debug u-boot itself.
-michael
From: Michael Galassi <hidden> Date: 2006-09-29 22:14:46
Thanks Machael.
On my flash data sheet, there are some command about security:
Lock Block | Block Address | 0060h | Block Address | 0001h
Unlock Block|Block Address| 0060h | Block Address | 00d0h
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!
:(
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.
- Reeve
Actually no, I made the assumption that you have two 16 bit wide flash
parts, one providing bits 0:15, the other 16:31. Most PPC projects end
up doing this. The write 0x00600060 ends up sending a 0x60 to the flash
on the low bits and another 0x60 to the flash part on the high bits.
The second write of 0x00d000d0 likewise sends a single 0xd0 to each
flash part.
If your tool gave you a command called mw which had a usage somewhat
like:
mw <size> <address> <data>
where size is b/byte, w/word, l/longword you might you might try:
mw l 0x00600060 0xff000000
mw l 0x00d000d0 0xff000000
Does that make sense to you?
PS: some people here have nothing better to do than whine about
top-posting, safe yourself the grief and respond bellow the
post.
PS: Technicaly this is not a Linux topic, I'm responding here
because this does turn out to be of general interest.
-michael
From: Mathews, Phil <hidden> Date: 2006-09-29 22:46:15
From: linuxppc-embedded-bounces+phil.mathews=innocon.com@ozlabs.org on behalf of Michael Galassi
Sent: Fri 9/29/2006 6:14 PM
To: Reeve Yang
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Need help on PPC8343E bringup
Thanks Machael.
On my flash data sheet, there are some command about security:
Lock Block | Block Address | 0060h | Block Address | 0001h
Unlock Block|Block Address| 0060h | Block Address | 00d0h
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!
:(
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.
- Reeve
Actually no, I made the assumption that you have two 16 bit wide flash
parts, one providing bits 0:15, the other 16:31. Most PPC projects end
up doing this. The write 0x00600060 ends up sending a 0x60 to the flash
on the low bits and another 0x60 to the flash part on the high bits.
The second write of 0x00d000d0 likewise sends a single 0xd0 to each
flash part.
If your tool gave you a command called mw which had a usage somewhat
like:
mw <size> <address> <data>
where size is b/byte, w/word, l/longword you might you might try:
mw l 0x00600060 0xff000000
mw l 0x00d000d0 0xff000000
Does that make sense to you?
PS: some people here have nothing better to do than whine about
top-posting, safe yourself the grief and respond bellow the
post.
PS: Technicaly this is not a Linux topic, I'm responding here
because this does turn out to be of general interest.
-michael
Actually the comands should be:
mw l 0xff000000 0x00600060
mw l 0xff000000 0x00d000d0
BTW - you don't have to bellow the post, you can just type them quietly :-)
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded