DockStar JTAG

[crimsonredmk]

I'll just leave this here (attached DockStar JTAG picture).

DockStar JTAG

DockStar_JTAG.png (31.34 KiB) Viewed 4390 times

[fcarolo]

Hi, Admin.

I've been lurking around since I got my Dockstar a month ago, waiting for some more info about JTAG access. Since I have some experience with Arm-based devices, getting JTAG is something I really ant to try with my Dosckstar, so this is great news.

I am assuming the signals exposed through J1 are compatible with a buffered JTAG cable. Is this right? I am about to assemble a cable to start fiddling with it.

[maso]

I got the JTAG working!
It took a little soldering though. I had to solder some teeny tiny 4.7k resistors (size 0402, mounted on their sides) across all 4 terminals of RP1, and I had to put another one at R166.

Then, using a Xilinx Parallel Cable IV (with urJTAG, telling it I was using a Parallel Cable III), it successfully identified the CPU.

My only problem now is that I know absolutely nothing about JTAG. Back to Google...

[mali]

I got the JTAG working!
My only problem now is that I know absolutely nothing about JTAG. Back to Google...

Similar here. However, I have not added any of the missing resistors. As someone explained, there should be pull-up resistors inside the CPU.

I am using OpenOCD-USB, OpenOCD and the sheevaplug config file, but have not been able to successfully write to the flash yet. Probably, the problem is the initialization done within the sheevaplug_init function, which is part of sheevaplug.cfg.

Trying to load an u-boot image into DRAM or write it to flash produces error messages similar to this one:

Code: Select all

Error: DCC write failed, expected end address 0x00052f40 got 0xffd10030


Anybody more experienced with JTAG and with the 88F6281?

Mali

[mali]

Ok, commenting out

Code: Select all

        arm7_9 dcc_downloads enable


in dockstar.cfg (which started as a copy of sheevaplug.cfg) disables DCC. After that, I am able to load a u-boot image into DRAM and start it - at least for a "working" DockStar, that has been halted during execution of the installed u-boot. No progress on the bricked one: I can load the image, but it does not seem to execute.

I think some more changes are necessary to the dockstar.cfg

Code: Select all

        # 1st bank is 128 MB
        mww 0xD0001504 0x07FFFFF1 #  CS0n Size Register   128MB

        # 2nd bank of DRAM is not used
        mww 0xD0001508 0x00000000 #  CS1n Base Register
        mww 0xD000150C 0x00000000 #  CS1n Size Register


Is anyone else looking into this at the moment?

Mali

[crimsonredmk]

I need to get aholler in on this - he'll figure this out.

[Kragorn]

Hello,

Any news about it ? Will this cable work ? http://cgi.befr.ebay.be/Buffered-JTAG-S ... 764wt_1139

I've tried to restore to default using my backup of mtd0 (taken from dd and restored with nandwrite) but now my device is broken.

Do you have any intrusctions on how can I restore the uboot image? Thank you.

[mali]

Hi,

kragorn, have a look at http://jeff.doozan.com/debian/uboot/build_uboot.htm. Jeff expains that copying mtd devices using dd will fail because of the applied ECC algorithm. He explains what to do instead. I can not comment on the cable you found. I am trying to use OpenOCD-USB, a small FT2232-based adapter ...

I still do not manage to get a U-boot image executed from DRAM or written to NAND. Downloading to DRAM seems to work, however, executing the image seems to fail: The status changes from halted to running, but I do not see any output on the serial console. I am trying to download an image read from mtd0 of another device using

Code: Select all

./nanddump -nof uboot-original -s 0 -l 0x80000 /dev/mtd0

At the moment, I do not have further ideas on that problem. Alexander: I think using the original U-Boot should ensure that it properly initializes the device, so I do not think this is the problem ...

Writing to NAND fails too, complaining that the target was not halted:

Code: Select all

> poll
background polling: on
TAP: feroceon.cpu (enabled)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0xffff0000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
>
> nand erase 0 0x0 0xa0000
erased blocks 0 to 5 on NAND flash device #0 'NAND 256MiB 3,3V 8-bit'
>
> poll                   
background polling: on
TAP: feroceon.cpu (enabled)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0xffff0000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
>
> nand write 0 nanddump/uboot-original 0 oob_softecc_kw
timed out while waiting for target halted
error executing hosted NAND write
target not halted
NAND flash access requires halted target
NAND flash access requires halted target
[...]
NAND flash access requires halted target
NAND flash access requires halted target
failed writing file nanddump/uboot-original to NAND flash 0 at offset 0x00000000>
>
> poll                                                 
background polling: on
TAP: feroceon.cpu (enabled)
target state: debug-running
>


The NAND problem could be related to the config registers related to NAND access. I just copied the corresponding lines from sheevaplug.cfg:

Code: Select all

mww 0xD0010418 0x003E07CF #  NAND Read Parameters REgister
mww 0xD001041C 0x000F0F0F #  NAND Write Parameters Register
mww 0xD0010470 0x01C7D943 #  NAND Flash Control Register


And also related to that problem: It looks like the target would change status to "running" after invocation of the nand_write command. How can that happen?

Any ideas what I should try?

Mali

[phdeez]

I can't speak for the cable, but I've noticed *any* dd dumps don't work properly for any partition. I'm sorry you bricked your device.

Let us know how it pans out for you!

/edit/ oops! Looks like mali already wrote a detailed post... my bad! Good luck to you both!

[phdeez]

mali, Are you sure you are getting the uboot from the working dockstar? According to the link you posted, the original uboot is located at 0x600000, not 0x800000 like you posted above in your nanddump command. Might have been just a mistake when posting though.

Just a thought?