On Wed, Oct 6, 2010 at 6:49 PM, Mike Frysinger <[email protected]> wrote:
> On Wednesday, October 06, 2010 09:13:13 Drasko DRASKOVIC wrote:
>> do different cores inside same chip count as different parts ?
>
> urjtag knows nothing of "cores". it only knows what devices report themselves
> via the JTAG scan chain. and that is dictated by the chip/board designer.
>
>> jtag> detect
>> IR length: 48
>> Chain length: 7
>
> you've got 7 devices and the IR length of each adds up to 48. i dont think
> there's any requirement that says each device must have the same IR length.
> but i could be wrong.
The thing is that what we call "device" here is called "part" in
UrJTAG terminology. I thought that "part" is chip itself, but it seems
to be anything that has it's own TAP controller. Thus, SoC composed of
5 cores will have 5 distinct "parts".
It can be the case that some cores are absolutly the same, and let's
take an example that we have 3 Lattice LM32 cores and 2 ARM926 cores.
Definition for parts 0, 1 and 2 is the same (LM32 parts) and should be
put into urjtag/share/urjtag/lattice directory. There PARTS file
should be modified in order to add new part definition (which UrJTAG
will use for cores (or devices) 0, 1 and 2), and also new directory
has to be created : urjtag/share/urjtag/lattice/lm32, in which we will
have STEPPINGS file and configuration file derived from BDSL.
Similar thing has to be done for ARM926 cores, only that arm directory
does not exist at all inside urjtag/share/urjtag/ and has to be
created.
All new devices (i.e. "parts") have also to be reported in
urjtag/share/urjtag/MANUFACTURERS file.
Finally, and the most tricky part was generation of configuration file
within urjtag/share/urjtag/lattice/lm32, since I din not have BSDL
file. But BSDL file is not really needed at all for internal DEBUG,
which is what I really wanted. It is a description of "signals" and
"bits" on the I/O pins of the chip, needed for doing boundary scan on
the I/O pins. I do not want that - what I wanted is observing internal
state of the core, and for this all that is needed is :
1) data register definition ("register" here presents local variable
in which content will be put) with appropriate length
2) instruction length
3) instruction definition, which will be used to set and shift ir
Example :
##############################################################################
#
# MY_CORE part description file
#
##############################################################################
register DR 16
register BR 1
register ID 32
instruction length 4
instruction IDCODE 1010 DR
instruction BYPASS 1111 BR
instruction INTEST 1100 ID
And that is all, and can be hand-written, and not generated from BSDL file.
After that we can read ID of a core 3 in the scan chain like this :
jtag> patr 3
jtag> instruction IDCODE
jtag> shift ir
jtag> shift dr
jtag> dr <--- to observe dr content
00001000000101111011100011000101 <--- ID code that was shifted in
and put in dr
>
>> If they are defined as one part, how do we handle different
>> instruction length, because different cores within the same chip might
>> have different instruction length.
>
> if a device in the JTAG scan chain reports the same JTAG ID info but in
> reality has different JTAG command sets, then that is stupid hardware that
> you'll manually need to work around.
This is not the case here. Reported ID is different for the ARM and
LM32, which is normal, although they are all on the same scan chain
within same SoC. The thing is that I understood that whole SoC should
be a "part", when it is (which not clearly explained at all) that each
core (that has distinct TAP controller) should be a different "part".
Hope that this will help to others who run into similar problem.
BR,
Drasko
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
UrJTAG-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/urjtag-development
