Hacking the Rigol DHO800/900 Scope

[AceyTech]

So, for my setup, 804 running as 914 with lics, I don't think HW number matters. Is there anything in the 914 that an 804 could gain by going to HW-8? "HW-8" perhaps just indicated availablility of the digital probe interface?

Digital probe Interface will be activated once your probe adapter pod shorts pin 1-2.  See my post here

You can even try it without the adapter using some tweezers, if you're interested.

[AndyBig]

But other way around? There are many images in GEL for DHO1000/DHO4000. I tested it and some of them works the same as original DHO800/900 (BOOT.bin) and some makes distortions in a waveform.

By the way, if you even manage to stuff the firmware from Artix into Zynq (by cutting off the extra length of the file, correcting the header, recalculating the checksums), then you have a very good chance of burning out your oscilloscope as a result - the FPGA itself, the processor or the ADC

[AndyBig]

FPGAs have no cores at all. There is not even such a thing as a kernel. In general, with FPGAs everything is very simple - it’s just a lot of elementary logical elements - latches, flip-flops, Look-Up tables. And the binary file simply defines the connections between them. That's all. There are also additional blocks, such as RAM, multipliers, PLLs, transceivers, etc., but they are simply there as auxiliary peripherals.

So what is this:

(Attachment Link)

This is the Zynq family, which is installed in 800/900, but not in 1000/4000. And this is not a pure FPGA, but a SoC, which includes both an FPGA and a processor.

[norbert.kiszka]

FPGAs have no cores at all. There is not even such a thing as a kernel. In general, with FPGAs everything is very simple - it’s just a lot of elementary logical elements - latches, flip-flops, Look-Up tables. And the binary file simply defines the connections between them. That's all. There are also additional blocks, such as RAM, multipliers, PLLs, transceivers, etc., but they are simply there as auxiliary peripherals.

So what is this:

(Attachment Link)

This is the Zynq family, which is installed in 800/900, but not in 1000/4000. And this is not a pure FPGA, but a SoC, which includes both an FPGA and a processor.

Hmmmm

FPGA bit文件说明

按照FPGA器件型号
 A100T 标识符 
 A75T  标识符 B
 
按照ADC颗粒(采样率)
2ADC 4GSa/s 标识符 S4
1ADC 2GSa/s 标识符 S2


HDO4000-FPGA-A100T
bit1 SPU_H12S4_SelfTest.bit     完成芯片和板级自检；包括DDR校准参数回读。
bit2 SPU_H12S4.bit              常规示波器程序，无Bode图功能
bit3 SPU_H12S4_bode.bit         Bode功能版本，无高分辨率

HDO2000/1000-FPGA-A100T
bit1 SPU_H12S2_SelfTest.bit     完成芯片和板级自检；包括DDR校准参数回读。
bit2 SPU_H12S2.bit              常规示波器程序，无Bode图功能
bit3 SPU_H12S2_bode.bit         Bode功能版本，无高分辨率



HDO4000-FPGA-A75T
bit1 SPU_H12S4B_SelfTest.bit     完成芯片和板级自检；包括DDR校准参数回读。
bit2 SPU_H12S4B.bit              常规示波器程序，无Bode图功能
bit3 SPU_H12S4B_bode.bit         Bode功能版本，无高分辨率

HDO2000/1000-FPGA-A75T
bit1 SPU_H12S2B_SelfTest.bit     完成芯片和板级自检；包括DDR校准参数回读。
bit2 SPU_H12S2B.bit              常规示波器程序，无Bode图功能
bit3 SPU_H12S2B_bode.bit         Bode功能版本，无高分辨率

[AndyBig]

FPGA bit文件说明

按照FPGA器件型号
 A100T 标识符 
 A75T  标识符 B

Here they told you in plain text which FPGA models are used - A75T and A100T. This is the Artix 7 family. I would highly recommend studying the base more carefully before trying to poke a stick into the unknown
Here even the difference in file sizes should alert you. The fact is that the binary for the same FPGA model always has the same size, regardless of what firmware it contains - test, working, or even from a completely different device.

P.S. An acquaintance of mine who works with both Artix and Zynq just now confirmed to me that the possibility of running firmware for one family in an FPGA of another family is completely excluded. I myself worked with FPGAs from Altera (Intel), and although all FPGAs work in the same way, I still asked him specifically about Artix and Zynq

[norbert.kiszka]

But other way around? There are many images in GEL for DHO1000/DHO4000. I tested it and some of them works the same as original DHO800/900 (BOOT.bin) and some makes distortions in a waveform.

By the way, if you even manage to stuff the firmware from Artix into Zynq (by cutting off the extra length of the file, correcting the header, recalculating the checksums), then you have a very good chance of burning out your oscilloscope as a result - the FPGA itself, the processor or the ADC

IMHO Its higher chance to burn ADC (capable of 2G) instead of FPGA. Its something like a shorting output with input of Schmitt inverter "gate" - theoretically You shouldnt, practically (in 74AC14) it becomes unstable generator of ~110 MHz (exact frequency depends on moon phase, temperature and time of a day).

FPGA bit文件说明

按照FPGA器件型号
 A100T 标识符 
 A75T  标识符 B

Here they told you in plain text which FPGA models are used - A75T and A100T. This is the Artix 7 family. I would highly recommend studying the base more carefully before trying to poke a stick into the unknown
Here even the difference in file sizes should alert you. The fact is that the binary for the same FPGA model always has the same size, regardless of what firmware it contains - test, working, or even from a completely different device.

P.S. An acquaintance of mine who works with both Artix and Zynq just now confirmed to me that the possibility of running firmware for one family in an FPGA of another family is completely excluded. I myself worked with FPGAs from Altera (Intel), and although all FPGAs work in the same way, I still asked him specifically about Artix and Zynq

Code: [Select]

rk3399_rigol:/ # ls -l /rigol/FPGA/                                                                                                                                                         
total 81520
-rwxrwxrwx 1 root root 3825893 2024-03-12 06:47 BOOT.bin
-rwxrwxrwx 1 root root 3631368 2013-01-18 09:42 BOOT.bin_
-rwxrwxrwx 1 root root 3631368 2013-01-18 09:42 BOOT_SelfTest.bin
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S2.bit
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S2_SelfTest.bit
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S2_bode.bit
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S4.bit
-rwxrwxrwx 1 root root 3825893 2024-03-12 06:47 SPU_H12S4B.bit
-rwxrwxrwx 1 root root 3825893 2024-03-12 06:47 SPU_H12S4B_SelfTest.bit
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S4_SelfTest.bit
-rwxrwxrwx 1 root root 3825894 2024-03-12 06:47 SPU_H12S4_bode.bit
-rwxrwxrwx 1 root root    1192 2024-03-12 06:47 readme.txt

Code: [Select]

rk3399_rigol:/ # /rigol/shell/reload_fpga.sh /rigol/FPGA/SPU_H12S2.bit 0x400000                                                                                                             
2024.03.14 10.03.46 509584 us
/rigol/tools/spi2erase /rigol/FPGA/SPU_H12S2.bit 0x400000
spi clock : 10 M, using bit: /rigol/FPGA/SPU_H12S2.bit
Download K7 master
Sending :0x3a60e6
Waiting 20s For Erase Flash...
done

2024.03.14 10.04.06 578167 us
/rigol/tools/spi2flash /rigol/FPGA/SPU_H12S2.bit 0x400000
spi clock : 10 M, using bit: /rigol/FPGA/SPU_H12S2.bit
Download K7 master
Sending :0x3a60e6

Start Prog Flash
done

2024.03.14 10.04.31 653066 us

/rigol/tools/spi2boot 0x400000
Boot MultiBoot Image
Waiting 5s For MultiBoot Image Boot...

done

00:00.0 Class 0604: Device 1d87:0100
01:00.0 Class 0700: Device 10ee:7022

Memory map to 0xf5ffd000
offset = 0x4000
Read(0x4000) = #0x1062919#
rk3399_rigol:/ #

[AndyBig]

my DHO804 came with an old firmware (00.01.00.something if I remember). Hacking with the vendor method on this version works but the offset calibration of the 4 channels will be inaccurate even after making the oscilloscope running a self-calibration. I've understand that the best method today is to first upgrade the firmware then apply the vendor method hack from @zelea2

By the way, yes - you need to add to the description that before increasing the model number you need to make sure that the firmware version is not less than 00.01.02.00.02. Thanks for writing about this

[AndyBig]

IMHO Its higher chance to burn ADC (capable of 2G) instead of FPGA. Its something like a shorting output with input of Schmitt inverter "gate" - theoretically You shouldnt, practically (in 74AC14) it becomes unstable generator of ~110 MHz (exact frequency depends on moon phase, temperature and time of a day).

When uploading someone else's firmware from another device, there is a very high probability that one of the pins, which was configured as an input by the native firmware, will be configured as an output by someone else's firmware. And it turns out that, for example, the processor output will be connected to the FPGA output. And if the processor sets it to 0, and the FPGA sets it to 1 (or vice versa), then there will actually be a short circuit on both of these outputs. Will both of these outputs survive, or will the output driver of one of them go into oblivion - a very interesting question. I wouldn't want to learn the answer to this from practice on my several hundred dollar oscilloscope.

Code: [Select]

rk3399_rigol:/ # /rigol/shell/reload_fpga.sh /rigol/FPGA/SPU_H12S2.bit 0x400000                                                                                                             
2024.03.14 10.03.46 509584 us
/rigol/tools/spi2erase /rigol/FPGA/SPU_H12S2.bit 0x400000
spi clock : 10 M, using bit: /rigol/FPGA/SPU_H12S2.bit
Download K7 master
Sending :0x3a60e6
Waiting 20s For Erase Flash...
done

2024.03.14 10.04.06 578167 us
/rigol/tools/spi2flash /rigol/FPGA/SPU_H12S2.bit 0x400000
spi clock : 10 M, using bit: /rigol/FPGA/SPU_H12S2.bit
Download K7 master
Sending :0x3a60e6

Start Prog Flash
done

2024.03.14 10.04.31 653066 us

/rigol/tools/spi2boot 0x400000
Boot MultiBoot Image
Waiting 5s For MultiBoot Image Boot...

done

00:00.0 Class 0604: Device 1d87:0100
01:00.0 Class 0700: Device 10ee:7022

Memory map to 0xf5ffd000
offset = 0x4000
Read(0x4000) = #0x1062919#
rk3399_rigol:/ #

This is a log of the binary being written to SPI flash. This doesn’t mean anything, the flash drive doesn’t care what they load into it, even a video instead of firmware.

[TurboTom]

FYI, here's just a comparison of the maximum data transfer rates of the high speed interfaces between Artix and ZYNQ FPGAs (taken from Xilinx's product selection guides) - see attachements.

The XC7A100T (used in DHO1000/4000) is easily four times outperforming the Z-7015 from the DHO800/900. Since this interface is used to move the data from the ADC(s) to the sampling RAM, this clearly explains why Rigol chose to limit the 800/900's sampling rate to 1.25GSa/s while the ADC could run at 2GSa/s. The fourfold performace of the Artix on the other hand, is able to serve two of Rigol's ADCs at full grunt.

I assume that Rigol chose to transfer the data to the RAM as 16bit numbers (and not 12 bit "interleaved" since the overhead would be excessive) which results at a sustained transfer rate of 20Gbit/s @ 1.25GSa/s, add some small overhead and the 25Gbit/s specified for the ZYNQ doesn't seem too generous...

Even though it's a pity, I highly doubt that an up-hack of the DHO800/900's sampling rate is possible with the existing hardware. I'ld be glad to be proven wrong... 

[AceyTech]

FYI, here's just a comparison of the maximum data transfer rates of the high speed interfaces between Artix and ZYNQ FPGAs (taken from Xilinx's product selection guides) - see attachements.

The XC7A100T (used in DHO1000/4000) is easily four times outperforming the Z-7015 from the DHO800/900. Since this interface is used to move the data from the ADC(s) to the sampling RAM, this clearly explains why Rigol chose to limit the 800/900's sampling rate to 1.25GSa/s while the ADC could run at 2GSa/s. The fourfold performace of the Artix on the other hand, is able to serve two of Rigol's ADCs at full grunt.

I assume that Rigol chose to transfer the data to the RAM as 16bit numbers (and not 12 bit "interleaved" since the overhead would be excessive) which results at a sustained transfer rate of 20Gbit/s @ 1.25GSa/s, add some small overhead and the 25Gbit/s specified for the ZYNQ doesn't seem too generous...

Even though it's a pity, I highly doubt that an up-hack of the DHO800/900's sampling rate is possible with the existing hardware. I'ld be glad to be proven wrong... 

Thanks for your voice of reason.  Something I think people tend to overlook here, is that these parts also have to gen 14bit ARB data, and capture 16 channels of digital data whilst handling 4 ADC streams, concurrently... (DHO9x4S models)   Lots of bits!

[AceyTech]

Speaking of additional calibration options..  I hadn't noticed this before tonight.  There is a "Detail" drop-down on the SelfCal window with some interesting calibration info. -if it passes- 

BTW: these are all the "additional calibration" options that I found to calibrate with success.  Anything else added will fail. 

FYI: it took 7 hours to test all the permutations, because some would go 98 or 99% before stopping or crashing.

[ebastler]

To change HW number, You dont need to remove housing at all.

Your method is not the only correct one. Some people would prefer to change the version in hardware rather than in software.

So far, the only known benefit from changing the hardware ID is better (full?) support for a logic analyser port added to the DHO800. Even with future exploration, changing the hardware ID will probably only make sense when the hardware is changed. 

Hence it makes good sense to me to actually change the ID via a hardware (i.e. resistor) modification. One has to open the scope and solder on the main PCB anyway, to make the actual hardware change/upgrade of interest. And then one ends up with a physically encoded ID which will survive all future firmware updates -- whether official ones from Rigol or "homebrew" -- without potential complications.

[Mechatrommer]

To change HW number, You dont need to remove housing at all.

Your method is not the only correct one. Some people would prefer to change the version in hardware rather than in software.

So far, the only known benefit from changing the hardware ID is better (full?) support for a logic analyser port added to the DHO800. Even with future exploration, changing the hardware ID will probably only make sense when the hardware is changed. 

Hence it makes good sense to me to actually change the ID via a hardware (i.e. resistor) modification. One has to open the scope and solder on the main PCB anyway, to make the actual hardware change/upgrade of interest. And then one ends up with a physically encoded ID which will survive all future firmware updates -- whether official ones from Rigol or "homebrew" -- without potential complications.

i wish there is easy and stable method in SW.. so we can switch back easily. There probably trap when you change ID to HW that is not deserving, such as missing ddr3 ram.. i'm on hp, so icant type long.."

[AceyTech]

The opposite side of the front panel control board.  Not much here, but posting in case anyone is curious.  It wasn't in Dave's Flickr teardown set.


In case any dho800->924S users are wondering; the gold plated switch pads (for the ARB and LA buttons) are there in my photo.  The LED's are unpopulated though, and you would need a way to push the buttons.  But hey!  There's a way, at least!

[norbert.kiszka]

When uploading someone else's firmware from another device, there is a very high probability that one of the pins, which was configured as an input by the native firmware, will be configured as an output by someone else's firmware. And it turns out that, for example, the processor output will be connected to the FPGA output. And if the processor sets it to 0, and the FPGA sets it to 1 (or vice versa), then there will actually be a short circuit on both of these outputs. Will both of these outputs survive, or will the output driver of one of them go into oblivion - a very interesting question. I wouldn't want to learn the answer to this from practice on my several hundred dollar oscilloscope.

Thats possible, but IMHO its higher chance of hardware damage caused by ESD - from my personal experience. Anyway, If I will fail, then I will have story to tell. Speaking of reverse engineering, in libscope-auklet.so there is a banch of decoding (audio, aviation buses, power calculations) options which so far currently nobody unlocked - looks like its for other models in vendor.bin and it can be disabled by hardcode. Its not easy to read dissassembled/decompiled code, but I think thats possible.

I assume that Rigol chose to transfer the data to the RAM as 16bit numbers (and not 12 bit "interleaved" since the overhead would be excessive) which results at a sustained transfer rate of 20Gbit/s @ 1.25GSa/s, add some small overhead and the 25Gbit/s specified for the ZYNQ doesn't seem too generous...

Even though it's a pity, I highly doubt that an up-hack of the DHO800/900's sampling rate is possible with the existing hardware. I'ld be glad to be proven wrong... 

So theoretically if data going from ADC to FPGA is without any checksums or other overhead, then without overclocking or changing FPGA it should be possible to do 1.25 * (25 / 20) = 1.5625 GHz. That exact number probably would by tricky in changing mentioned lib, because they made sample rate ratio with multiples of 400, 500 and... 625. I just started to decompile this .so, so there is a lot more things to read and test it...

I did the "impossible" things before. Sadly I cant tell of most "impossible" thing I done, because its a secret - somebody payed me just for trying and I succeed anyway and that took months of hard work (half of it was caused by my stupid mistake in a code...).

[Mechatrommer]

No, 6 of the 8 screws holding the heatsink are not screwed into the metal chassis, but into bonnets soldered into the board.

you are right. i've added 2b.jpg in the step, only 2 screws need to unscrew without removing heatsink. i didnt notice the bonnet things. deleted my invalid post...

https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389052/#msg5389052

i imagine its something like DLL or drv? i have free ed IDA, so i can open a little bit exe or dll, but since its Linux/android i'm pretty much zero about how things work in those system.

Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries. IDA understands these files without problems, as does Ghidra.

last night i downloaded latest version of IDA free version. it said the .ko file is ARM64 and i need to pay additional module. going to their website, it is unclear as my friend's language which version and at what price to buy. so this is beyond my paygrade. and then i downloaded ghidra as per your advice (JDK 21 also needed to install) then i can see something, it has printk and function names, if HW code is indeed is written to a file, then may as well this is what norbert mentioned about. in the mean time i'll try to gather norbert's cryptic posts hopefully i can make out something from them later. its not a one hour job though (noob learning btw the possibility of the other alternative)...

[norbert.kiszka]

last night i downloaded latest version of IDA free version. it said the .ko file is ARM64 and i need to pay additional module. going to their website, it is unclear as my friend's language which version and at what price to buy. so this is beyond my paygrade. and then i downloaded ghidra as per your advice (JDK 21 also needed to install) then i can see something, it has printk and function names, if HW code is indeed is written to a file, then may as well this is what norbert mentioned about. in the mean time i'll try to gather norbert's cryptic posts hopefully i can make out something from them later. its not a one hour job though (noob learning btw the possibility of the other alternative)...

I already posted here decompiled hdcode_gpio.ko and looks like its pretty simple module reading gpio and writing one byte into a file and nothing more. Thats why I posted to do printf (to generate one byte file) in a shell script - instead of unnecessary damaging guaranty sticker and heating PCB with components on it.

[shapirus]

Any chance on enabling the dot mode display? It really sucks that it's not possible. Has anyone come across any hints in the java app or otherwise?

[norbert.kiszka]

Any chance on enabling the dot mode display? It really sucks that it's not possible. Has anyone come across any hints in the java app or otherwise?

Im not familiar with Java language, but I found this:

Code: [Select]

        for (int i = 0; i < width2; i++) {
            this.path.lineTo(i, (float) ((this.amplitude * Math.sin((((1.0f * f) / getWidth()) * 2 * 3.141592653589793d * this.angularFrequency) + this.phaseAngle)) + (getHeight() / 2)));
        }

[RAPo]

OMG a hard coded approximation  for pi instead of using the Math.PI (a static final double constant in Java).
(sorry, I'm a mathematician and can't stand this style of programming ).

[Randy222]

I mentioned last week to have install script for mod'd APK. Attached is the bundle, read the README before using.
We are in a hacking thread, so for context, a hacking thread.

The bundle is based on AndyBig initial mod'd Scope APK, which worked but had Quick button issue that I found to be an Android permission issue, needed access to Surface_Flinger, so I edited manifest in that APK to include the permission and also updated the Android platform permissions file.

Beyond that, use as you see fit.

I will mention again, read the README before using.

[AndyBig]

OMG a hard coded approximation  for pi instead of using the Math.PI (a static final double constant in Java).
(sorry, I'm a mathematician and can't stand this style of programming ).

Here in the code this is a static constant with double precision Most likely it was Math.PI that was used in the source code.

[ebastler]

OMG a hard coded approximation  for pi instead of using the Math.PI (a static final double constant in Java).
(sorry, I'm a mathematician and can't stand this style of programming ).

Math.PI is not properly irrational either. 

[Mechatrommer]

heating PCB with components on it.

for some, this is bread and butter and hope...

decompiled hdcode_gpio.ko and looks like its pretty simple module reading gpio and writing one byte into a file and nothing more. Thats why I posted to do printf (to generate one byte file) in a shell script

but since there not yet solid and stable solution, i guess its not that simple. from fractions that i can understand, there's complication such as compiled apk/ko kernel authentication error? (MITM spoofing from inside ie modified code/compiled app file) or sleep timing complication? (MITM spoof and sniff from outside? hook/script whatever it is) btw i have no clue about how android/linux system works, you are ahead in this we are counting on you. i may do/learn this on free time next time if i can dig whats the real complications are with hints from posts of you people. cheers.

OMG a hard coded approximation  for pi instead of using the Math.PI (a static final double constant in Java).
(sorry, I'm a mathematician and can't stand this style of programming ).

but you know how to complain when the machine is stupid slow right? this is a good example of how a rough approximation is necessary (compulsory) to make things work. you need to learn to accept "good enough" in engineering, this is not theoretical physics or mathematics cheers.

Here in the code this is a static constant with double precision Most likely it was Math.PI that was used in the source code.

didnt someone told him? delusion in the sky. 14 decimal places is way more than good enough.

[Randy222]

Speaking of additional calibration options..  I hadn't noticed this before tonight.  There is a "Detail" drop-down on the SelfCal window with some interesting calibration info. -if it passes- 
(Attachment Link)
BTW: these are all the "additional calibration" options that I found to calibrate with success.  Anything else added will fail. 
(Attachment Link)
FYI: it took 7 hours to test all the permutations, because some would go 98 or 99% before stopping or crashing.

What's the ADC Clock adjustments in Debug? Is that only used when you have $50,000 calibration signal feeding the inputs?