Roland DIF-AT: Difference between revisions

Line 60:

</gallery>

==JTAG/Programming/~~Firmware~~==

==JTAG/Programming/CPLD==

The device has two levels of firmware: NOR Flash and CPLD bitstream. The Xilinx is an older model XC95144 which is programmed over JTAG. However, due to the architecture, bitstream cannot be read out over JTAG (even if unlocked)~~. It still seems strange~~ to ~~me that, this is a 100 pin CPLD, and only 4 inputs and 4 outputs are used!~~ (~~RBUS data solely, 8 channels L/R~~)

The device has two levels of firmware: NOR Flash and CPLD bitstream. The Xilinx is an older model XC95144 which is programmed over JTAG. However, due to the architecture, bitstream cannot be read out over JTAG (even if unlocked) it has to use vendor specific tools (Platform Cable USB)

~~Perhaps Roland just had a load of~~ these ~~in house already~~ and ~~it was cheaper~~ to ~~use them than get~~ a ~~smaller device~~. ~~Or maybe it was the only suitable device in that range?~~

JTAG pads are exposed on the PCB as seen in the image above. I could connect to these to read the CPLD. Pretty soon they were pulled off the board, and I had to solder a pin to the leg temporarily to continue reading data. (before I discovered tiny IC clips!)

~~JTAG pads are exposed on the PCB as seen~~ in the ~~image above. I could connect to these to read the CPLD. Pretty soon they were pulled off the board~~, ~~and I had to solder a pin to~~ the ~~leg temporarily to continue reading data~~. ~~(before I discovered tiny IC clips!)~~

[Only one device is visible in the JTAG chain, the Xilinx. The CPU, H8300H (Hitachi/Renesas) is not equipped with JTAG at all. Low level CPU operation is done through a bootloader mode]

~~I connected using Bluetag~~, ~~OpenOCD and XC3SPROG~~ (~~open source Xilinx CLI~~) ~~and was eventually able to read back ID codes and find IR Len etc. I was happy it was responding. It was fun, confusing and difficult to set up~~ all ~~these tools~~. ~~I set most of them up on~~ a ~~Raspberry Pi as dedicated hacking server so I can connect remotely to the hot mess setup with my laptop, somewhere more comfortable : )~~

I connected to the Xilinx XC95144 using Bluetag, OpenOCD and XC3SPROG (open source Xilinx CLI) and was eventually able to read back ID codes and find IR Len etc. I was happy it was responding. It was fun, confusing and difficult to set up all these tools. I set most of them up on a Raspberry Pi as dedicated hacking server so I can connect remotely to the hot mess setup with my laptop, somewhere more comfortable : )

It seems strange to me that, this is a 100 pin CPLD, and only 4 inputs and 4 outputs are used! (solely RBUS data, 8 channels L/R in/out). Counter output from H8300H goes to clock pin of the Xilinx, through an inverter.

File:XC3SPROG id read.png|alt=XC3SPROG id read|'''XC3SPROG id read'''

Line 78:

</gallery>

===BSDL Scan===

===BSDL Scan -===

After initial ID code read, I used a [https://github.com/viveris/jtag-boundary-scanner BSDL GUI] to determine whether the CPLD was actually passing data throughput. Whilst easy to use when running, this tool took a while to set up (I mistakenly compiled it from source in Windows 7 32 bit - somehow missing the fact there there was a package release) After downloading the BSDL language file from Xilinx and setting up the tool with info from the Xilinx datasheet (super confusing naming convention, cells vs physical pins). Scanner could only run with this set up in ~~Sample~~ mode (OS not present nor running).

After initial ID code read, I used a [https://github.com/viveris/jtag-boundary-scanner BSDL GUI] to determine whether the CPLD was actually passing data throughput. Whilst easy to use when running, this tool took a while to set up (I mistakenly compiled it from source in Windows 7 32 bit - somehow missing the fact there there was a package release) After downloading the BSDL language file from Xilinx and setting up the tool with info from the Xilinx datasheet (super confusing naming convention, cells vs physical pins). Scanner could only run with this set up in Extest mode (OS not present nor running) toggling the input pins at a user defined frequency - means the corresponding output logic pulses accordingly.

It was satisfying to see my logic probe light up on the outputs during ~~BSDL~~ scanning.

It was satisfying to see my logic probe light up on the outputs during Extest scanning.

Xilinx CPLD confirmed working - big achievement! (Not tested in actual operation. I'm 99% sure its fine after these tests)

Xilinx CPLD confirmed working - big achievement! (Not tested in actual operation) I'm 99% sure its fine after these tests.

At some point I will get a Xilinx Platform Cable to attempt to read the bitstream for archival purposes. However at this stage I'd had to get a few probes etc and didn't really want to get a Xilinx only device. I've had great luck with unlocked devices so far though, everything I've looked at has been open or level 1 : )

~~[[File:VIVERIS BOUNDARY SCANNER.png|thumb|Viveris JTAG Boundary Scanner]]~~

<br />

[[File:VIVERIS BOUNDARY SCANNER.png|thumb|Viveris JTAG Boundary Scanner]]

==Extract Firmware==

== Extract Firmware - ==

Line 98:

Line 96:

After I desoldered the other half using hot air, I could proceed to read out the contents -

<br />

=== TL48 Programmer- ===

===TL48 Programmer-===

I used a TL48 programmer with a 48pin TTSOP to read the NOR Flash firmware contents -

Line 113:

Line 112:

[[File:DIF AT FLASH SETTINGS.png|thumb|T48 programmer settings and dump - note the very interesting strings!]]

=== Binwalk / Binvis - ===

I slowed down a bit here because I had no idea how to actually load the file I'd dumped to look at it. First I used Binwalk, which I think is more suited to SOC work. Anyway Binwalk was able to provide a nice image showing the entropy of the file - low entropy = low chance of corruption or encryption (or possibly I'm defining that the incorrect way around)

~~<br~~ />

I also had a look at [https://binvis.io/ Binvis]. Binvis makes for a stunning visual representation, regardless of anything else at all. I love it. It was fun to see the strings represented in coloured pixels. Also, very apparent to see in Binvis, are the banks. This firmware is banked and split. This is to facilitate DFU - the device can be firmware updated by the user while still maintaining stable OS. Then switch a flag to change/denote active bank.

~~=== Binwalk / Binvis ===~~

This device has two firmware version strings visible in the firmware (at this point the strings are the only thing I've really been able to see)

~~I slowed down a bit here because I had no idea how to actually load~~ the ~~file I'd dumped to look~~ at ~~it. First~~ I ~~used Binwalk, which isn~~'~~t so well suited to this task. Anyway he was~~ able to ~~provide a nice image showing the entropy of the file - low entropy = low chance of corruption or encryption.~~

~~I also had a look~~ in ~~Binvis~~. ~~Binvis makes for a stunning visual representation even~~ if ~~its not useful in any~~ other ~~way~~. It was ~~fun~~ to ~~see~~ the ~~strings represented in coloured pixels~~.

Appears it was already updated in the field to the last OS version (1.022) from I'm not sure if it then wipes the other bank? Possibly, because the other regions are written with FF. However it was still pretty confusing to navigate around later on; BRA to 0xFF region. I'm still not sure: maybe the Alesis CPLD remaps certain memory addresses at run time?

[[File:Binwalk entropy image.png|left|thumb|Binwalk entropy image looking good - encouraging at least]]

[[File:DIF-AT BINVIS.png|alt=binvis.io|center|thumb|BINVIS The little 'white line defined' area is where the pointer is viewing]]

@@ Line 60: / Line 60: @@
 </gallery>
-==JTAG/Programming/Firmware==
+==JTAG/Programming/CPLD==
-The device has two levels of firmware:  NOR Flash and CPLD bitstream.  The Xilinx is an older model XC95144 which is programmed over JTAG.  However, due to the architecture, bitstream cannot be read out over JTAG (even if unlocked).  It still seems strange to me that, this is a 100 pin CPLD, and only 4 inputs and 4 outputs are used!  (RBUS data solely, 8 channels L/R)
+The device has two levels of firmware:  NOR Flash and CPLD bitstream.  The Xilinx is an older model XC95144 which is programmed over JTAG.  However, due to the architecture, bitstream cannot be read out over JTAG (even if unlocked) it has to use vendor specific tools (Platform Cable USB)
-Perhaps Roland just had a load of these in house already and it was cheaper to use them than get a smaller device.  Or maybe it was the only suitable device in that range?
+JTAG pads are exposed on the PCB as seen in the image above.  I could connect to these to read the CPLD.  Pretty soon they were pulled off the board, and I had to solder a pin to the leg temporarily to continue reading data.  (before I discovered tiny IC clips!)
-JTAG pads are exposed on the PCB as seen in the image above.  I could connect to these to read the CPLD.  Pretty soon they were pulled off the board, and I had to solder a pin to the leg temporarily to continue reading data.  (before I discovered tiny IC clips!)
+[Only one device is visible in the JTAG chain, the Xilinx.  The CPU, H8300H (Hitachi/Renesas) is not equipped with JTAG at all.  Low level CPU operation is done through a bootloader mode]
-I connected using Bluetag, OpenOCD and XC3SPROG (open source Xilinx CLI) and was eventually able to read back ID codes and find IR Len etc.  I was happy it was responding.  It was fun, confusing and difficult to set up all these tools.  I set most of them up on a Raspberry Pi as dedicated hacking server so I can connect remotely to the hot mess setup with my laptop, somewhere more comfortable : )
+I connected to the Xilinx XC95144 using Bluetag, OpenOCD and XC3SPROG (open source Xilinx CLI) and was eventually able to read back ID codes and find IR Len etc.  I was happy it was responding.  It was fun, confusing and difficult to set up all these tools.  I set most of them up on a Raspberry Pi as dedicated hacking server so I can connect remotely to the hot mess setup with my laptop, somewhere more comfortable : )
+It seems strange to me that, this is a 100 pin CPLD, and only 4 inputs and 4 outputs are used!  (solely RBUS data, 8 channels L/R in/out). Counter output from H8300H goes to clock pin of the Xilinx, through an inverter.
 <gallery>
 File:XC3SPROG id read.png|alt=XC3SPROG id read|'''XC3SPROG id read'''
@@ Line 78: / Line 78: @@
 </gallery>
-===BSDL Scan===
+===BSDL Scan -===
-After initial ID code read, I used a [https://github.com/viveris/jtag-boundary-scanner BSDL GUI] to determine whether the CPLD was actually passing data throughput.  Whilst easy to use when running, this tool took a while to set up (I mistakenly compiled it from source in Windows 7 32 bit - somehow missing the fact there there was a package release)  After downloading the BSDL language file from Xilinx and setting up the tool with info from the Xilinx datasheet (super confusing naming convention, cells vs physical pins). Scanner could only run with this set up in Sample mode  (OS not present nor running).
+After initial ID code read, I used a [https://github.com/viveris/jtag-boundary-scanner BSDL GUI] to determine whether the CPLD was actually passing data throughput.  Whilst easy to use when running, this tool took a while to set up (I mistakenly compiled it from source in Windows 7 32 bit - somehow missing the fact there there was a package release)  After downloading the BSDL language file from Xilinx and setting up the tool with info from the Xilinx datasheet (super confusing naming convention, cells vs physical pins). Scanner could only run with this set up in Extest mode (OS not present nor running) toggling the input pins at a user defined frequency - means the corresponding output logic pulses accordingly.
-It was satisfying to see my logic probe light up on the outputs during BSDL scanning.
+It was satisfying to see my logic probe light up on the outputs during Extest scanning.
-Xilinx CPLD confirmed working - big achievement! (Not tested in actual operation.  I'm 99% sure its fine after these tests)
+Xilinx CPLD confirmed working - big achievement! (Not tested in actual operation)  I'm 99% sure its fine after these tests.
 At some point I will get a Xilinx Platform Cable to attempt to read the bitstream for archival purposes.  However at this stage I'd had to get a few probes etc and didn't really want to get a Xilinx only device.  I've had great luck with unlocked devices so far though, everything I've looked at has been open or level 1 : )
-[[File:VIVERIS BOUNDARY SCANNER.png|thumb|Viveris JTAG Boundary Scanner]]
 <br />
+[[File:VIVERIS BOUNDARY SCANNER.png|thumb|Viveris JTAG Boundary Scanner]]
-==Extract Firmware==
+== Extract Firmware - ==
@@ Line 98: / Line 96: @@
 After I desoldered the other half using hot air, I could proceed to read out the contents -
 <br />
-=== TL48 Programmer- ===
+===TL48 Programmer-===
 I used a TL48 programmer with a 48pin TTSOP to read the NOR Flash firmware contents -
@@ Line 113: / Line 112: @@
 [[File:DIF AT FLASH SETTINGS.png|thumb|T48 programmer settings and dump - note the very interesting strings!]]
+=== Binwalk / Binvis - ===
+I slowed down a bit here because I had no idea how to actually load the file I'd dumped to look at it.  First I used Binwalk, which I think is more suited to SOC work.  Anyway Binwalk was able to provide a nice image showing the entropy of the file - low entropy = low chance of corruption or encryption (or possibly I'm defining that the incorrect way around)
-<br />
+I also had a look at [https://binvis.io/ Binvis].  Binvis makes for a stunning visual representation, regardless of anything else at all.  I love it.  It was fun to see the strings represented in coloured pixels.  Also, very apparent to see in Binvis, are the banks.  This firmware is banked and split.  This is to facilitate DFU - the device can be firmware updated by the user while still maintaining stable OS.   Then switch a flag to change/denote active bank.
-=== Binwalk / Binvis ===
+This device has two firmware version strings visible in the firmware (at this point the strings are the only thing I've really been able to see)
-I slowed down a bit here because I had no idea how to actually load the file I'd dumped to look at it.  First I used Binwalk, which isn't so well suited to this task.  Anyway he was able to provide a nice image showing the entropy of the file - low entropy = low chance of corruption or encryption.
-I also had a look in Binvis.  Binvis makes for a stunning visual representation even if its not useful in any other way.  It was fun to see the strings represented in coloured pixels.
+Appears it was already updated in the field to the last OS version (1.022) from  I'm not sure if it then wipes the other bank?  Possibly, because the other regions are written with FF.  However it was still pretty confusing to navigate around later on; BRA to 0xFF region.  I'm still not sure: maybe the Alesis CPLD remaps certain memory addresses at run time?
+[[File:Binwalk entropy image.png|left|thumb|Binwalk entropy image looking good - encouraging at least]]
+[[File:DIF-AT BINVIS.png|alt=binvis.io|center|thumb|BINVIS The little 'white line defined' area is where the pointer is viewing]]