Request for JTAGID dump firmware. - General Discussion and Assistance - CHDK Forum

Request for JTAGID dump firmware.

  • 6 Replies
  • 2706 Views
*

linuxGuy

Request for JTAGID dump firmware.
« on: 07 / December / 2007, 18:08:01 »
Advertisements
I have launched an effort to see what we can learn about the Digic processors.

It appears as though some Texas Instruments ARM cores have a JTAGID written at a certain location in memory.  One core has a JTAGID register at  address location 0x01C4 0028 and its value would be 0x0B73B01F.

Would someone care to write a small piece of firmware that would dump the value of this location to the LCD so that we might check for a match ?

The background info to this request is in the following thread
http://chdk.setepontos.com/index.php/topic,119.0.html

If we could ever identify what core and hardware is in the Digic processors, it would make our lives a lot easier.
« Last Edit: 07 / December / 2007, 18:10:07 by linuxGuy »

*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: Request for JTAGID dump firmware.
« Reply #1 on: 08 / December / 2007, 03:09:57 »
It appears as though some Texas Instruments ARM cores have a JTAGID written at a certain location in memory.  One core has a JTAGID register at  address location 0x01C4 0028 and its value would be 0x0B73B01F.

Would someone care to write a small piece of firmware that would dump the value of this location to the LCD so that we might check for a match ?
I do not have to write something. CHDK has memory browser embedded. Here are the values:
* A610 (DigicII) - 0xB84DE025
* S3IS (DigicII) - 0xFFFFFFFF
P.S. I do not have any DigicIII camera.
CHDK Developer.

Re: Request for JTAGID dump firmware.
« Reply #2 on: 08 / December / 2007, 06:44:30 »
A640 (DigicII): 0xFFFFFFFF

*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: Request for JTAGID dump firmware.
« Reply #3 on: 08 / December / 2007, 07:51:33 »
A720IS (digic III): 0xFFFFFFFF


*

linuxGuy

Re: Request for JTAGID dump firmware.
« Reply #4 on: 08 / December / 2007, 11:42:14 »
Thanks, guys.

Here is a page on decoding JTAG IDs.
http://www.arm.com/support/faqip/3843.html

Lets see if this stuff works.

Texas Instruments tells us that the JTAG ID for the DM355 core is  0x0B73B01F.
We also have "A610 (DigicII) - 0xB84DE025"

According to the above FAQ, the structure of the JTAG ID word is:
(my bit numbering is 31,30,...2,1,0)

31-28: Version: 4 bits for the core revision number.
27: ARM Core ID.  Should be zero (0) if we have a valid ID.
26-24: Capability bits.  See the table in the FAQ.
23-20: Family bits.  ARM9 should be 0x09.  Another way to tell if we have a valid JTAG ID.
19-12: Device number.
11-1: Manufacturer's ID.  Set by the manufacturer.
0: Marker bit.  Should always be "1".

So for the JTAG ID that TI gave for the DM355, 0x0B73B01F (0b 0000 1011 0111 0011 1011 0000 0001 1111), we have

31-28: Core version number: 0000
27: ARM Core ID: 1 <- This is supposed to be ZERO, according to the FAQ ! 
26-24: Capability bits: 011: Used in conjunction with the ARM Core ID, we get 1011, which supposedly is "ARM Trace Buffer (2).
23-20: Family bits: 0111: Seems to imply ARM7.  But we know this device is ARM9.
19-12: Device number: 0011 1011.  Used by the manufacturer.  Meaningless to us ?
11-1: Manufacturer ID: 0000 0001 111: meaningless to us.
0: 1: marker bit.  At least that worked !

I guess I am pretty skeptical that this structure applies to the TI chips being that the JTAG ID TI gave us doesn't really work.  Am I missing something ?

Lets try the other JTAG ID, 0xB84DE025 or 0b 1011 1000 0100 1101 1110 0000 0010 0101

31-28: Core version number: 1011
27: ARM Core ID: 1 <- This is supposed to be ZERO, according to the FAQ ! 
26-24: Capability bits: 000: Used in conjunction with the ARM Core ID, we get 1000, which is Reserved, ie shouldn't be used. Hmmm...
23-20: Family bits: 0100: Not a valid ARM number.
19-12: Device number: 1101 1110  Used by the manufacturer.  Meaningless to us ?
11-1: Manufacturer ID: 0000 0010 010: meaningless to us.
0: 1: marker bit.  At least that worked !

Doesn't seem to work for either.  Have I made a mistake somewhere ?  Is it possible the byte orders are mixed up ?

If we believe the JTAG IDs in the FAQ, then right off the 3rd highest hex digit needs to be a 9, ie 0xXX9XXXXX.

Thoughts ?
« Last Edit: 08 / December / 2007, 12:54:40 by linuxGuy »

*

linuxGuy

Re: Request for JTAGID dump firmware.
« Reply #5 on: 08 / December / 2007, 11:53:02 »
This article describes how ARM cores are identified.
http://infocenter.arm.com/help/topic/com.arm.doc.dai0099c/DAI0099C_core_type_rev_id.pdf

I wonder if the JTAG ID value can be read by the core.  Any chance we could read the Reg0 Value ?

Thanks

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Request for JTAGID dump firmware.
« Reply #6 on: 01 / June / 2008, 16:18:46 »
This article describes how ARM cores are identified.
http://infocenter.arm.com/help/topic/com.arm.doc.dai0099c/DAI0099C_core_type_rev_id.pdf

I wonder if the JTAG ID value can be read by the core.  Any chance we could read the Reg0 Value ?

Thanks

I think the pdf in that url says JTAG id can only be read from JTAG.

As for Register 0, maybe it would help to find out what these commands write to R0 (see chapter B3.3 of the ARM Architecture Reference manual from ARM Documentation - Instruction Set Information):

// read main id register:
MRC    p15, 0, R0, c0, c0

// read cache type register:
MRC    p15, 0, R0, c0, c0, #1   

// read TCM (tightly coupled memory) register:
MRC    p15, 0, R0, c0, c0, #2   

// read TLB type register:
MRC    p15, 0, R0, c0, c0, #3   

// read MPU type register (PMS Av6)
MRC    p15, 0, R0, c0, c0, #4   

If one of these doesn't exist on the chip, the main id register is returned.
They will otherwise never be equal.


// read jazelle id register:
MRC    p14, 7, R0, c0, c0

// read jazelle main configuration register:
MRC    p14, 7, R0, c2, c0


 

Related Topics