Hacking the Rigol DHO800/900 Scope

[Fungus]

So, probably some code leftovers.

So that firmware updates will be compatible with pre-release 'scopes.

[Fungus]

I don't have the scope (yet) so I can't tell you what each code means. Sorry

Me either. 

I'm 100% sure it'll be possible, it's just a question of how many hoops need to be jumped through.

[ptluis]

The HDO was Rigol's initial designation before having to change to DHO.

Regarding the lics generation, look into the HDO/DHO1000/4000 thread. It's all there so there is no need to reinvent the wheel.

Fungus see what tv84 wrote  If the same process works on DHO800/900 it would be easy to activate just what we need.

[akkk44]

The HDO was Rigol's initial designation before having to change to DHO.

Regarding the lics generation, look into the HDO/DHO1000/4000 thread. It's all there so there is no need to reinvent the wheel.

Fungus see what tv84 wrote  If the same process works on DHO800/900 it would be easy to activate just what we need.

I had tried the method for HDO1000/4000 scope and managed to unlock the 70MHz to 100MHz upgrade on my DHO804, and @hubertyoung managed to add the BODE option with the every same methpod. Therefore, I can confirmed that the existing method still works perfectly fine.

[akkk44]

I was sniffing Dave's DHO800 dump file and found references to 2 other models whose initial letters were swapped. Should they be the same models but launched in another country? maybe yes maybe no.

They were called "HDO" when they were announced but that turned out to be a trademark (of Lecroy?) or something so they changed it to "DHO".

The firmware probably works both ways.

While messing around with my DHO804, I happened to somehow made it identify it self as HDO1074, which is interesting.
https://lh3.google.com/u/0/d/1xLgXzNZY_h51uqBLpfh9jRs5dM9yPVog=w3840-h1984-iv1

[Fungus]

I had tried the method for HDO1000/4000 scope and managed to unlock the 70MHz to 100MHz upgrade on my DHO804, and @hubertyoung managed to add the BODE option with the every same methpod. Therefore, I can confirmed that the existing method still works perfectly fine.

What about 50mpts memory? That's not an official option so it might need a different method.

(same with 125MHz bandwidth...)

[souldevelop]

Hi all, attached is the DHO tool I created, I hope it will be more helpful to you guys.
You can now use the latest firmware version and upgrade with it, which will no longer have the problem of zero potential offset. Its only drawback is that upgrading from the 800 series to the 900 series may not be correct across series.

[souldevelop]

The forum setting cannot exceed 5Mb, which is embarrassing.

This Pack A

The version has been updated
v1.0.2

[souldevelop]

This is Pack B

[souldevelop]

Theoretically, DHO800 series upgrade to DHO900 or DHO1000, the system in addition to checking the device model recorded in the Vendor .bin, RigolAPP also detects some bit bits on the hardware motherboard, so to perfectly skip this detection must build a driver to hook out the bit information read from the hardware. I firmly believe that the whole detection is no more.

[akkk44]

Theoretically, DHO800 series upgrade to DHO900 or DHO1000, the system in addition to checking the device model recorded in the Vendor .bin, RigolAPP also detects some bit bits on the hardware motherboard, so to perfectly skip this detection must build a driver to hook out the bit information read from the hardware. I firmly believe that the whole detection is no more.

Thanks a lot for your hard work!
I tried writing the idendity to 924 on my 804. However, the drift still presents and can not be eliminated by self-cal. Did I missed something? Many thanks.

[souldevelop]

Theoretically, DHO800 series upgrade to DHO900 or DHO1000, the system in addition to checking the device model recorded in the Vendor .bin, RigolAPP also detects some bit bits on the hardware motherboard, so to perfectly skip this detection must build a driver to hook out the bit information read from the hardware. I firmly believe that the whole detection is no more.

Thanks a lot for your hard work!
I tried writing the idendity to 924 on my 804. However, the drift still presents and can not be eliminated by self-cal. Did I missed something? Many thanks.

I emphasized, there is still one step left to do, different series of upgrades 800\900\1000 we need to develop a hook driver to mount to the device to let the system detect that hardware you specified to complete this step will end all hacks, but this work takes time, please wait....

[hbozyq]

Hero arrived!

[tv84]

RigolAPP also detects some bit bits on the hardware motherboard, so to perfectly skip this detection must build a driver to hook out the bit information read from the hardware. I firmly believe that the whole detection is no more.

What does the app do with those bits? In what form are they related to model and/or options?

[souldevelop]

RigolAPP also detects some bit bits on the hardware motherboard, so to perfectly skip this detection must build a driver to hook out the bit information read from the hardware. I firmly believe that the whole detection is no more.

What does the app do with those bits? In what form are they related to model and/or options?

so easy, it is the hardware version:

         model                                                   hardware version
DHO804 and DHO814                                             12   
DHO802  DHO812                                                   4     
DHO914S DHO924S  DHO914   DHO924                   8     
DHO1072                                                               9     
DHO4000                                                               0

RIGOL manages the driver location for the hardware version :  /rigol/driver/hdcode_gpio.ko

root@rigol:~/rigol/driver# modinfo hdcode_gpio.ko
filename:       /rigol/driver/hdcode_gpio.ko
license:        GPL
description:    gpio-hdcode devices driver
author:         rigol sn03950
depends:
intree:         Y
vermagic:       4.4.126 SMP preempt mod_unload modversions aarch64

All secrets have been revealed, I wish you guys fun.
 

[tv84]

What does the app do with those bits? In what form are they related to model and/or options?

so easy, it is the hardware version:

         model                                                   hardware version
DHO804 and DHO814                                             12   
DHO802  DHO812                                                   4     
DHO914S DHO924S  DHO914   DHO924                   8     
DHO1072                                                               9     
DHO4000                                                               0

 

Can't you change the table in software? Is the version configured in the OTP SOC area or in a Rigol ASIC?

[souldevelop]

What does the app do with those bits? In what form are they related to model and/or options?

so easy, it is the hardware version:

         model                                                   hardware version
DHO804 and DHO814                                             12   
DHO802  DHO812                                                   4     
DHO914S DHO924S  DHO914   DHO924                   8     
DHO1072                                                               9     
DHO4000                                                               0

 

Can't you change the table in software? Is the version configured in the OTP SOC area or in a Rigol ASIC?

The RK3399 chip corresponds to the GPIO in the hardware version number:

bit0= GPIO0_A4   PIN 4   
bit1= GPIO0_B0   PIN 8
bit2= GPIO0_B3   PIN 11
bit3= GPIO0_B4   PIN 12

I don't have a cross-compilation environment for RK3399 here, if anyone can compile a hdcode_gpio.ko by themselves to replace the original factory, you can achieve hardware version number customization.

[iMo]

The version number could be in a form of solder bridges on the pcb somewhere as well..
The RK3399 just reads its inputs pins and gets the version number from "somewhere".

[tv84]

The RK3399 chip corresponds to the GPIO in the hardware version number:

bit0= GPIO0_A4   PIN 4   
bit1= GPIO0_B0   PIN 8
bit2= GPIO0_B3   PIN 11
bit3= GPIO0_B4   PIN 12

I don't have a cross-compilation environment for RK3399 here, if anyone can compile a hdcode_gpio.ko by themselves to replace the original factory, you can achieve hardware version number customization.

If you lift the PIN 11, all is good, right? 

Please share the original file here.

[souldevelop]

The RK3399 chip corresponds to the GPIO in the hardware version number:

bit0= GPIO0_A4   PIN 4   
bit1= GPIO0_B0   PIN 8
bit2= GPIO0_B3   PIN 11
bit3= GPIO0_B4   PIN 12

I don't have a cross-compilation environment for RK3399 here, if anyone can compile a hdcode_gpio.ko by themselves to replace the original factory, you can achieve hardware version number customization.

If you lift the PIN 11, all is good, right? 

Please share the original file here.

If the GPIO is dangling instead of grounded, or if there is an internal pulldown, there may be a problem.
The only thing I'm not sure about now is whether the GPIO input is fixed resistors or wires or connected to the internal logic circuitry of the FPGA? Capable friends can track RK3399 chip pins by themselves:
GPIO0_A4     4PIN
GPIO0_B0     8PIN
GPIO0_B3    11PIN
GPIO0_B4    12PIN

[dreamcat4]

driver location for the hardware version :  /rigol/driver/hdcode_gpio.ko

root@rigol:~/rigol/driver# modinfo hdcode_gpio.ko
filename:       /rigol/driver/hdcode_gpio.ko
license:        GPL
description:    gpio-hdcode devices driver
author:         rigol sn03950
depends:
intree:         Y
vermagic:       4.4.126 SMP preempt mod_unload modversions aarch64

All secrets have been revealed,

hang on... does not this indicate that rigol has this kernel module under gpl license? and also 'intree' to mean it is indeed kernel tree?

because under gpl terms it's necessary to provide the full source code (for this kernel module), at least by writing when requested. or by some other mechanism(s).

so to obtain this kmod code, it remains still. but rigol should be legally obliged to provide it to any customers (at least those who purchased the oscilloscope in 1st instance, and then those customers are subsequently not obliged to sign nda, they are in turn themselves free to openly redistribute it).

this is assuming it is correct infos there (about the gpl license, and it being intree). that this is not been honestly mistaken. and it assumes rigol respects the terms of the linux kernel, and the terms of the gpl license?

 

[souldevelop]

The version number could be in a form of solder bridges on the pcb somewhere as well..
The RK3399 just reads its inputs pins and gets the version number from "somewhere".

Maybe.you are right.. 

[tv84]

this is assuming it is correct infos there (about the gpl license, and it being intree). that this is not been honestly mistaken. and it assumes rigol respects the terms of the linux kernel, and the terms of the gpl license?

Correct. And I would say they will send you the code.

They sent all the GPL code for the MSO5000 to @Olliver. And he has it on his Github page...

[dreamcat4]

ah right... so this is just to identify the hardware alone. it's not general device drivers. sorry my mistake. however at least that can be done easily (with the source code, tweak and rebuild new kmod).

[niino]

Can anyone give an overview over the H/W variants of the 800/900 series scopes? E.g. which ones do have hardware capabilites preinstalled for the AWG and stuff like that.

Are all DHO900 series scopes identical hardware-wise, since all of them have the LA connector preinstalled as well as the AWG output at the back? I'd like to avoid having to cut into the case, so I'd go for the DHO914 in that case, as long as all the DHO924S features can be hacked software-wise.