Hi,
Is dominic is going to extend OpenOCD for ARM11MPCORE…
There are currently no plans to add support for this platform, mostly because I lack ARM11 hardware, but also due to a lack of time. The ARM11 debug architecture is significantly different from ARM7/9, and would thus require quite a lot of work.
Regards,
Dominic
Thanks for the reply, we would like to pursue this. any inputs on this appreciated.
our main road block is - how to get the arm multicore board?
can Jtag interface of multicore can be simulated in software?
… waiting for reply…
thanks.
Well, I would suppose you already have an MPCore board? Why else would you want to extend a debugger to support it? I don’t know any MPcore implementation, but I’m sure ARM would be more than willing to help you select a suitable microcontroller.
Of course the JTAG interface can be simulated in hardware - given enough resources there’s no reason why you shouldn’t be able to, but the question is why you want to do it, and how much effort you’re willing to put into the simulation…
Regards,
Dominic
Hello,
Can you elaborate a little on this topic :
The ARM11 debug architecture is significantly different from ARM7/9, and would thus require quite a lot of work.
I’m trying to enable support for my ARM11 board, specifically a Freescale I.MX31.
Here is the log I get for now:
Info: openocd.c:93 main(): Open On-Chip Debugger 1.0 (2008-01-22-12:02) svn:272
Info: openocd.c:94 main(): $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
Info: jtag.c:1256 jtag_examine_chain(): JTAG device found: 0x2b900f0f (Manufacturer: 0x787, Part: 0xb900, Version: 0x2)
Info: jtag.c:1256 jtag_examine_chain(): JTAG device found: 0x07b3601d (Manufacturer: 0x00e, Part: 0x7b36, Version: 0x0)
Info: jtag.c:1256 jtag_examine_chain(): JTAG device found: 0x2190101d (Manufacturer: 0x00e, Part: 0x1901, Version: 0x2)
Error: jtag.c:1311 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x002011
Error: jtag.c:1311 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x002011
Error: jtag.c:1311 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x002011
Error: jtag.c:1311 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x002011
Error: jtag.c:1311 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x002011
Error: jtag.c:1311 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x002011
Error: jtag.c:1415 jtag_init(): Could not validate JTAG chain, exit
I’m quite happy because I can see the part number 0x7b36 on the second device, which is according to the ARM11 documentation the code for a ARM1136.
However I don’t recognize the other bits, neither the other parts (although I suspect there is really multiple devices on the chain, internally to the system-on-chip, since this fact is indicated in the i.MX31 docs).
The Freescale documentation on the JTAG parts are really really slim, and mostly refers to the official ARM11 one.
For what I could find, the 'jtag_validate_chain() fails because out of the 3 devices displayed, one of them does not returns ‘0x01’ on IR scan (and this is not the ARM11 core), and thus the function returns in error.
I don’t understand if this 0x01 value is a must-have on all JTAG chains, or only for ARM-based devices.
(The ARM11 core does return the value 0x01 value on IR scan, check with a debugger attached to openocd)
Thanks for this wonderfull work !
OB
PS: Here is my (actual) config file :
#daemon configuration
telnet_port 4444
gdb_port 3333
gdb_memory_map enable
gdb_flash_program enable
#interface
interface ft2232
ft2232_device_desc "Amontec JTAGkey"
ft2232_layout "jtagkey"
ft2232_vid_pid 0x0403 0xcff8
ft2232_latency 2
jtag_speed 10
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst
#reset_config trst_only
#reset_config srst_only
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
# 4 devices otherwise openocd complains, the last one returns 0x0 for all bytes
jtag_device 4 0x1 0xf 0xe
jtag_device 4 0x1 0xf 0xe
jtag_device 4 0x1 0xf 0xe
jtag_device 4 0x1 0xf 0xe
jtag_nsrst_delay 500
jtag_ntrst_delay 500
#target configuratiorst_delay
daemon_startup reset
#target <type> <endianess> <reset mode>
target arm966e little reset_halt 0
run_and_halt_time 0 5000
The fourth device on the JTAG chain is the SJC (Secure JTAG Challenge or something like that). The two other devices are the ETM buffer for the ETM Trace Macrocell and the microcontoler used for the SDMA subsystem.
We have developped an i.MX31 based board, and although we have bought a realView ICE for our design purposes, I would love to be able to use OpenOCD with our system (http://mobots.epfl.ch/mx31MoBoard.html).
I am willing (and I have time to) help you on this openOCD port for ARM1136. Where could I buy a simple FTDI based board that I could directly connect to my board (that has a standard 20-pin ARM JTAG connector) ?
OB: send me a PM so that we can go on by e-mail.
Sounds good.
Please contact me on laurent.gauch -at- amontec.com .
… I have to go at EPFL on the begin of February …
Regards,
Laurent
Hello !
Many thanks to Longfield for his informations !
I had found the SDMA chip from the documentation, and also fond out that its IR register has only 4 bits (BTW, this thing is a pain to work with…)
I could not find any other informations on the SJC and ETM, even if the i.MX31 user’s manual mention it.
Now I think I have to modify OpenOCD to relax its checks and let it try to communicate usefully with the core.
I will report here any success I achieve.
PS: I could have some informations with urjtag as well - check out this project as well ! (it is more oriented to the reflashing process, but usefull anyway)
We are currently working on an ARM1176JZF-S based design.
If any OpenOCD code is (becomes) available for ARM11 we would be happy to test that on our design. We could also arrange for a sample with that processor if that helps with the porting.
Regards,
Michael
Hello michael !
My design is based on a arm1136JF-S .
I don’t know if this has any effect on the JTAG, ETM and ICE mechanisms but I would think it does not.
One thing you may do to help :
Try to connect a jtag and scan the chain to see all IDCODES from the device chain, to see if the 1136 and 1176 are similar on this matter.
What I need are the lines similar to these ones from openocd :
Info: jtag.c:1256 jtag_examine_chain(): JTAG device found: 0x2b900f0f (Manufacturer: 0x787, Part: 0xb900, Version: 0x2)
Info: jtag.c:1256 jtag_examine_chain(): JTAG device found: 0x07b3601d (Manufacturer: 0x00e, Part: 0x7b36, Version: 0x0)
Info: jtag.c:1256 jtag_examine_chain(): JTAG device found: 0x2190101d (Manufacturer: 0x00e, Part: 0x1901, Version: 0x2)
(You might want to use my previously posted config file as template)
Maybe you have access to another jtag pod which may give you this information as well.
Thanks !
I’ll let you (and the list) know if I can get something working.
Maybe Dominic would be interested in a sample of you board ?
OB
We expect to receive actual hardware within the next two weeks, I will post the data then.
Regarding samples, they are currently (= for at least 3-4 months) extremely limited. I can organize only one extra and my understanding from the discussion above was that Dominic has no time at the moment to work on ARM11. So I would prefer to keep that for whoever can put it to use immediately.
Michael
OB,
here are the messages:
Info: jtag.c:1261 jtag_examine_chain(): JTAG device found: 0x2b900f0f (Manufacturer: 0x787, Part: 0xb900, Version: 0x2)
Info: jtag.c:1261 jtag_examine_chain(): JTAG device found: 0x07b76009 (Manufacturer: 0x004, Part: 0x7b76, Version: 0x0)
Michael
The second device reported is the ARM core:
Part 7b76 identifies the ARM1176JZF-S
The first device is the ETB:
Vendor 0x787 is ARM’s dummy vendor ID, Part b900 identifies an ARM11 ETB.
You need two jtag_device entries in your .cfg file:
jtag_device 4 0x1 0xf 0xe
jtag_device 5 0x1 0x1f 0xe
The hypothetical target line would be
target arm1176jzfs little reset_halt 1
The ‘1’ in the target line informs the OpenOCD that the second jtag_device is the ARM core identified by this target specification.
Regards,
Dominic
The IDCODE parameter to jtag_device should be 0x1E according to spec, but I understand its ignored anyway from what I’ve seen in the code.
Is there a particular reason to use these very specific target names. My understanding is that it should be possible to use an “arm11” (or armv6?) target and auto-detect the rest from there?
Michael
Is there a particular reason to use these very specific target names. My
understanding is that it should be possible to use an “arm11” (or
armv6?) target and auto-detect the rest from there?
For the ARM7 and ARM9 devices supported so far it was necessary to identify a particular core, or at least a group of cores (arm920t works for arm922t, too).
I don’t know enough about ARM11 devices to say whether they’re similar enough to use common code sequences.
Regards,
Dominic
I posted some ARM11 patches here, if someone is interested in testing:
https://lists.berlios.de/pipermail/open … 01080.html
Michael
I’ll test your patch as soon as possible.
I’m sorry I’ve been silent lately, I was working on other projects for a while but i’m getting back on tracks.
I’ll test your patch on the i.MX31 and report back to you concerning the ARM1136 issues.
Eventually, we may even be able to enter this target into OpenOCD !
(For now, I’ll be happy with just a arm11 target that can do 1136 and 1176).
After that, I’m willing to work on the hard breakpoints stuff (if I can find the time) , I need this.
Thanks for this good work !
If you are ready with implementing ARM11
Can you repair the functions for ARM7TDMI-S ?
Now, I cannot start the debug-session. (Speicherzugriffsverletzung, und Absturz)
Any update on the ARM11 patch/support for OpenOCD?
Is there a link to download it? I would like to try it.
Thanks,
Joseph
I have now a JTAGkey I can work with.
However I still cannot connect correctly to the mx31 (ARM1136JF-S inside as you can see on the next log):
Open On-Chip Debugger 1.0 (2008-03-28-09:36) svn:525
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
Info: jtag.c:1328 jtag_examine_chain(): JTAG device found: 0x2b900f0f (Manufacturer: 0x787, Part: 0xb900, Version: 0x2)
Info: jtag.c:1328 jtag_examine_chain(): JTAG device found: 0x07b3601d (Manufacturer: 0x00e, Part: 0x7b36, Version: 0x0)
Info: jtag.c:1328 jtag_examine_chain(): JTAG device found: 0x1190101d (Manufacturer: 0x00e, Part: 0x1901, Version: 0x1)
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1494 jtag_init(): Could not validate JTAG chain, exit
What does that mean, the lenghts for registers is not correct ? Does someone have a working configuration for ARM1136 ?
In fact, I have to configure 4 devices (ETM, arm1136, SDMA microcontroller and SJC) and openocd finds only 3 devices ? is the length of the last one incorrect ?
Here is my config file:
#daemon configuration
telnet_port 4444
gdb_port 3333
gdb_memory_map enable
gdb_flash_program enable
#interface
interface ft2232
ft2232_device_desc "Amontec JTAGkey"
ft2232_layout "jtagkey"
ft2232_vid_pid 0x0403 0xcff8
ft2232_latency 2
jtag_speed 10
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst
#reset_config trst_only
#reset_config srst_only
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
# 4 devices otherwise openocd complains, the last one returns 0x0 for all bytes
jtag_device 4 0x1 0xf 0xe
jtag_device 5 0x1 0x1f 0x1e
jtag_device 4 0x1 0xf 0xe
jtag_device 5 0x1 0x1f 0x1e
jtag_nsrst_delay 500
jtag_ntrst_delay 500
#target configuratiorst_delay
daemon_startup reset
#target <type> <endianess> <reset mode>
target arm11 little reset_halt 1
run_and_halt_time 0 5000