135
edits
Changes
Jump to navigation
Jump to search
m
[[File:VIVERIS BOUNDARY SCANNER.png|thumb|Viveris JTAG Boundary Scanner]]
[[File:DIF AT FLASH SETTINGS.png|thumb|T48 programmer settings and dump - note the very interesting strings!]]
Also maybe the Alesis ASIC remaps certain memory addresses at run time? (more research has shown that this is likely)
[[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]]
I think that, Probably the ADAT and TASCAM tape machines, will have had a video sync input, so they could be used . Used to sync to video gear to and score music for TV / video productions. The video sync will input to those machines, and the the DIF-AT sees the 'passed through' video sync source from the ADAT tape machine or the DA88TASCAM. It's not possible to sync the DIF-AT to video without it coming from a tape machine. I'm sure the manual for an ADAT machine will have this info. If I locate the info I will update this section.
<br />===DFU Python Script===
→Firmware Banks -
PCB photos, Pinouts, Pin header, Device operation, Connections between subsystems. Notes on firmware structure, Machine language monitor program, DFU, firmware extraction, firmware update script (python) <br />[[File:DIFAT 24.jpg|thumb|Roland publicity image |alt=]]
===Brief outline -===
Device has 2 buttons on the PCB: '''Switch 1''' - RESET, reset circuit (dedicated IC) '''Switch''' '''2''' - Launch monitor diagnostic mode.
A 50 pin header provides easy access to most address lines and relevant (to operation) CPU/RAM/Flash lines. This will be convenient to run a logic capture during boot and operation later. I beeped out the 50 pin connector - Many pins have multiple connections. Happily; the vias were not tented - this was a long endeavour even with continuity through the vias : ) Below, the findings and some general notes: <gallery>
File:DIFat 50 pin header1 .png|alt=dif at pin header pins 1 - 16|'''Header pins 1 - 16'''
File:DIFat 50 pin header2.png|alt=header pins 16 - 24|'''Header pins 16 - 24'''
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, [https://www.alldatasheet.com/datasheet-pdf/download/249501/RENESAS/H8SLASH300H.html H8300H ] (Hitachi/Renesas) is not equipped with JTAG at all. Low level CPU operation is done through a bootloader mode]
I connected to the [https://www.datasheet.live/pdfviewer?url=https%3A%2F%2Fwww.datasheet.live%2Fdatasheet%2Fxilinxsemi%2FXC95144XL-7TQ100C0962.pdf Xilinx XC95144 ] using [https://github.com/Aodrulez/blueTag/tree/main Bluetag], [https://openocd.org/ OpenOCD ] and [https://github.com/MPLew-is/xc3sprog 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.
===BSDL Scan -===
[[File:VIVERIS BOUNDARY SCANNER.png|thumb|Viveris JTAG Boundary Scanner]]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 Extest scanning.
<br />
==Extract Flash Firmware -==
At some point in the repair attempt, I heard a strange flapping sound from the NOR Flash as I moved the device around. ALL of the pins 25 - 48 had detached from the PCB with zero damage to the traces or pins. I surmise that this was the original failure point of the device - dry joints on the Flash chip. After I desoldered the other half using hot air, I could proceed to read out the contents - <br />
===T48 Programmer-===
[[File:DIF AT FLASH SETTINGS.png|thumb|T48 programmer settings and dump - note the very interesting strings!]]I used a T48 programmer with a 48pin TTSOP to read the NOR Flash firmware contents -
In the image below the python code on the right, are the settings needed for a good read. The NOR flash is 16 bit wide, but the CPU is reading it in 8 bit mode (8 bit mode pin is tied low). SHARP LH28F400BVE Parallel NOR Flash 512kb. The chip is from the late 1990s as the device is also, turn of the century 2000s.
Although the strings are legible in the T48 preview, this is because the T48 is re-arranging the byte order automatically. The byte order must be swapped (little endian) in order to correctly view and disassemble the firmware. I found this out after nonsensical strings were seen, without swapping byte order. I tried some 8 bit reads, but this garbled the strings in the T48.
It was clear 16 bit wide was correct, but then byte order needed changing. I used a python script to swap the byte order of the entire dumped firmware file. : <syntaxhighlight lang="python3">
# swap_bytes.py
==Examine Firmware -==
===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 [https://github.com/ReFirmLabs/binwalk Binwalk], which I *think* is more suited to SOC work (at least, I think Binwalk is able to find files and systems within bin images, which this firmware does not contain) Anyway Binwalk was able to provide an informative image showing the entropy of the file - low entropy = low chance of corruption or encryption.
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 firmware banks. [[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]]
===Firmware 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.
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 from active code to 0xFF region.
Probably some of these are the as yet un-mapped SRAM, and Alesis IC addresses. I've added peripheral mapping for the SCI. I'm learning a lot as I go! Also maybe the Alesis ASIC remaps certain memory addresses at run time? (more research has shown that this is likely). These images show the mirrored banked addresses - some lead to empty regions (maybe ram?) and some have near identical code (version differences?) and some have different data (bytes table for strings) [[File:DIFAT Bank Example.png|alt=DIF-AT firmware with mirrored bank -near identical addressing much higher in ROM region|left|thumb|DIF-AT firmware with mirrored bank - almost identical addressing just much higher in ROM region]][[File:DIF-ATBanked ROM2.png.png|thumb|DIF-AT firmware showing mirrored 'blank' bank location. |alt=]]
<br />
===Firmware Strings -===
Alright we've heard enough about them; here is the list - '''''strings -n 6 INTEL_HEX_DIF_AT_LH28F400BVE@TSOP48_byte_swapped.bin'''''
You can see how, it does look like corruption in some of the strings - gaps in the text.
The '''**Roland xx ''' looks like a boot banner and is called differently in the firmware. I'm sure that's why it has different start and stop markers. Ditto for the early Version string. Interestingly, the early Version is way at the other end of the addresses in the code. This adds to the DFU / Bank swap theory.
When I finally load the firmware (I still haven't at this point) I spend ages looking for what calls these strings. I find it difficult to navigate but fascinating. It is difficult to navigate any production firmware disassembly I expect. I have no prior experience, but it seems the H8300H is kind of a different level, a bit of an oddity. It's used a lot in Japanese electronics. It is in a lot of Roland devices. Apparently it interleaves code and data frequently which makes static disassembly trickier. '''''Especially in Cutter, which won't decompile H8 instructions (it either links to Ghidra method, which does not support the H8, or JS, which can't de-compile either)'''''
===User / Monitor Strings -===
This is an interesting one. The DIF-AT syncing to video?!
==Firmware Disassembly -==
I have not yet performed a Diff of my firmware and the midi updates. I would have to reconstruct them first into a full image. I think my firmware is not corrupted though at this point. I will try and send the DFU command and the payload using a python script instead (see below)
The midi files are 4x33kb. Minus headers etc; 32kb actual payload x 4 = 128kb firmware. A 512kb NOR flash is generous space for this (4x bigger) Though remember its banked for DFU (when the update is written and verified it will switch active bank flag) Also it seems remapped to different addresses in runtime operation also. There are plenty of 0xFF regions though, so not everything is written with instructions (though some of these are un-mapped memory regions for SRAM etc at the moment). These images show the mirroring - [[File:DIF-ATBanked ROM2.png.png|thumb|DIF-AT firmware showing mirrored 'blank' bank location. Not all mirrors are blank, and some mirrors contain different code, some near identical. ]][[File:DIFAT Bank Example.png|alt=DIF-AT firmware with mirrored bank -near identical addressing much higher in ROM region|left|thumb|DIF-AT firmware with mirrored bank - almost identical addressing just much higher in ROM region]]
With more help from LLM I made a DFU Update python script which first sends the (probable) DFU command, and then sends sequentially all midi files over serial (at midi baud) I compared the received payload to the sent, and it is correct. I have yet to test on the device.<syntaxhighlight lang="python3">
import serial
