For the moment my DM500 project is put on hold since I need a quite nice soldering iron to access the small pads. I do have access to a laboratory with that equipment but it is quite a hassle to gain access to the building it is located in.
In order to keep myself occupied and continue learning JTAG I wanted to physically do something related. I own a Gateworks Avila platform that features access to JTAG via a normal 2x6 pin header. Also, I am quite used to working with that platform which makes me quite confident in its inner workings.
As a test, I wanted to make a dump of all the internal flash memory.
Looking at the memory output I noticed that the string "Warning:" was represented as "aWnrni:g" which made me believe that it was a problem with endianness - since the platform is an armeb and my mac is little endian it would make sense. The only problem with that idea is that the strings are single byte ASCII characters and they would thus be uneffected by endianness.
My next though was that perhaps the wiring between SoC and flash is simply reversed (perhaps some PCB issue that was resolved that way?) making the lower byte the higher byte and the other way around. A quick fix in the urjtag file for the boundary scan bits fixed the output. Success!
I have yet to decide if this is a good solution, but it should work with the write commands as well. Comments and thoughts are very welcome.
In order to keep myself occupied and continue learning JTAG I wanted to physically do something related. I own a Gateworks Avila platform that features access to JTAG via a normal 2x6 pin header. Also, I am quite used to working with that platform which makes me quite confident in its inner workings.
As a test, I wanted to make a dump of all the internal flash memory.
jtag> cable arm-usb-ocd
Connected to libftdi driver.
jtag> detect
IR length: 7
Chain length: 1
Device Id: 00011001001001110111000000010011 (0x0000000019277013)
Manufacturer: Intel
Part(0): IXP425-266MHz
Stepping: B0
Filename: /usr/share/urjtag/intel/ixp425/ixp425
jtag> readmem 0 0x2000000 avila.mem
address: 0x00000000
length: 0x02000000
reading:
addr: 0x00001000
Looking at the memory output I noticed that the string "Warning:" was represented as "aWnrni:g" which made me believe that it was a problem with endianness - since the platform is an armeb and my mac is little endian it would make sense. The only problem with that idea is that the strings are single byte ASCII characters and they would thus be uneffected by endianness.
My next though was that perhaps the wiring between SoC and flash is simply reversed (perhaps some PCB issue that was resolved that way?) making the lower byte the higher byte and the other way around. A quick fix in the urjtag file for the boundary scan bits fixed the output. Success!
--- /usr/share/urjtag/intel/ixp425/ixp425 2010-10-17 22:26:40.000000000 +0200
+++ ixp425 2011-02-16 14:57:33.626074001 +0100
@@ -65,38 +65,38 @@
signal EX_ADDR[23] P5
signal EX_ADDR[24] T5
signal EX_ADDR[25] P4
-signal EX_DATA[0] N4
-signal EX_DATA[1] M5
-signal EX_DATA[2] L5
-signal EX_DATA[3] T6
-signal EX_DATA[4] N6
-signal EX_DATA[5] T7
-signal EX_DATA[6] M6
-signal EX_DATA[7] M7
-signal EX_DATA[8] M9
-signal EX_DATA[9] T10
-signal EX_DATA[10] R9
-signal EX_DATA[11] T11
-signal EX_DATA[12] P11
-signal EX_DATA[13] N10
-signal EX_DATA[14] T12
-signal EX_DATA[15] M10
-signal EX_DATA[16] H3
-signal EX_DATA[17] H5
-signal EX_DATA[18] J4
-signal EX_DATA[19] K3
-signal EX_DATA[20] L4
-signal EX_DATA[21] M2
-signal EX_DATA[22] N1
-signal EX_DATA[23] T3
-signal EX_DATA[24] P6
-signal EX_DATA[25] R7
-signal EX_DATA[26] P7
-signal EX_DATA[27] P8
-signal EX_DATA[28] L8
-signal EX_DATA[29] P10
-signal EX_DATA[30] R11
-signal EX_DATA[31] P12
+signal EX_DATA[0] M9
+signal EX_DATA[1] T10
+signal EX_DATA[2] R9
+signal EX_DATA[3] T11
+signal EX_DATA[4] P11
+signal EX_DATA[5] N10
+signal EX_DATA[6] T12
+signal EX_DATA[7] M10
+signal EX_DATA[8] N4
+signal EX_DATA[9] M5
+signal EX_DATA[10] L5
+signal EX_DATA[11] T6
+signal EX_DATA[12] N6
+signal EX_DATA[13] T7
+signal EX_DATA[14] M6
+signal EX_DATA[15] M7
+signal EX_DATA[16] P6
+signal EX_DATA[17] R7
+signal EX_DATA[18] P7
+signal EX_DATA[19] P8
+signal EX_DATA[20] L8
+signal EX_DATA[21] P10
+signal EX_DATA[22] R11
+signal EX_DATA[23] P12
+signal EX_DATA[24] H3
+signal EX_DATA[25] H5
+signal EX_DATA[26] J4
+signal EX_DATA[27] K3
+signal EX_DATA[28] L4
+signal EX_DATA[29] M2
+signal EX_DATA[30] N1
+signal EX_DATA[31] T3
signal GPIO[0] U25
signal GPIO[1] U22
signal GPIO[2] V24
@@ -312,22 +312,22 @@
bit 320 O ? EX_CS[5] 265 1 Z
bit 319 O ? EX_CS[6] 264 1 Z
bit 318 O ? EX_CS[7] 263 1 Z
-bit 317 B ? EX_DATA[0] 262 1 Z
-bit 316 B ? EX_DATA[1] 261 1 Z
-bit 315 B ? EX_DATA[2] 260 1 Z
-bit 314 B ? EX_DATA[3] 259 1 Z
-bit 313 B ? EX_DATA[4] 258 1 Z
-bit 312 B ? EX_DATA[5] 257 1 Z
-bit 311 B ? EX_DATA[6] 256 1 Z
-bit 310 B ? EX_DATA[7] 255 1 Z
-bit 309 B ? EX_DATA[8] 254 1 Z
-bit 308 B ? EX_DATA[9] 253 1 Z
-bit 307 B ? EX_DATA[10] 252 1 Z
-bit 306 B ? EX_DATA[11] 251 1 Z
-bit 305 B ? EX_DATA[12] 250 1 Z
-bit 304 B ? EX_DATA[13] 249 1 Z
-bit 303 B ? EX_DATA[14] 248 1 Z
-bit 302 B ? EX_DATA[15] 247 1 Z
+bit 317 B ? EX_DATA[8] 262 1 Z
+bit 316 B ? EX_DATA[9] 261 1 Z
+bit 315 B ? EX_DATA[10] 260 1 Z
+bit 314 B ? EX_DATA[11] 259 1 Z
+bit 313 B ? EX_DATA[12] 258 1 Z
+bit 312 B ? EX_DATA[13] 257 1 Z
+bit 311 B ? EX_DATA[14] 256 1 Z
+bit 310 B ? EX_DATA[15] 255 1 Z
+bit 309 B ? EX_DATA[0] 254 1 Z
+bit 308 B ? EX_DATA[1] 253 1 Z
+bit 307 B ? EX_DATA[2] 252 1 Z
+bit 306 B ? EX_DATA[3] 251 1 Z
+bit 305 B ? EX_DATA[4] 250 1 Z
+bit 304 B ? EX_DATA[5] 249 1 Z
+bit 303 B ? EX_DATA[6] 248 1 Z
+bit 302 B ? EX_DATA[7] 247 1 Z
bit 301 I ? EX_RDY[0]
bit 300 I ? EX_RDY[1]
bit 299 I ? EX_RDY[2]
I have yet to decide if this is a good solution, but it should work with the write commands as well. Comments and thoughts are very welcome.
Comments
Post a Comment