Hacking the Rigol DHO800/900 Scope

[Randy222]

@Randy222 show me Your start script. Whole file from beginning to the last line, even if its a empty line.

attached

[Randy222]

What does your file look like from hexdump?

xxd on my file shows "00000000: 08" without -p switch
with -p switch xxd shows "08"

so same as yours.

[Randy222]

How gpio pins are arranged via resistors could be mixed, like 12 8 11 4, due to ability to connect PCB traces to RK gpio pins. But your side resistors appear as 3 stacked with last one missing. In 4bit word, to get "8", that missing one has to be most significnat value in the 4bit word, aka gpio pin 12. Example, 1110 nor 0111 nor 0001 can't be 8, but 1000 is 8.

my original config (you can see in picture) top resistors = 1010, side resistors = 1110, this make FW  (About menu) reporting HW 12 (the original from factory), now i changed the resistor.... top resistors = 1010 (still same), and now side resistors = 1111, with this, FW reporting HW 8... how do you explain that? with binary theory and  hdcode_gpio KLM code?

to add to the fun for anyone interested in digital mental gymnastic: another combination (top 4 bit + side 4 bit):

1010,1110 = HW12 (my scope's default from factory)
1010,1010 = HW12
1010,1111 = HW8
1010,1011 = HW8

0000,1110 = HW4
0001,1110 = HW5
0010,1110 = HW13

for more combination fun, you can combine side bit 1110 with top bit in this combo image we've done earlier (when the side resistors of my scope still defaulted to 1110).



nomenclature: 1 = 10Kohm resistor presents, 0 = 10Kohm resistor missing.

You have to explain it.

After hardware chage, go into the kernel debug dir I listed a few posts back, read the gpio file, what gpio pins (and values) have changed ?

From what I found, the hdcode KLM only acts on RK gpio pins 12 11 8 and 4.

So perhaps there's more code somewhere else that's reading more pins, but hdcode.ko maps to those 4 pins in the gpio file. I posted the pics.

[swiperf0x]

Thank you @AndyBig for this nice and complete recap on the hack! And of course a big thanks to @zelea2 for implenting the hack.

I've discovered last year this topic and I've just bought in March a DHO804. Obviously I came back here this week and I wasn't able to find the last and "official" procedure to hack it. I remember something about the sdcard and the firmware from a DHO924 but still... Luckily I came to your post !

Also, for those who will be in the same situation as me, that's to say with a fresh brand new DHO804, here are some additional information to this hacking tutorial:

• if you upgrade hack your DHO804 into a DHO924 model with the vendor methode, as recommended in the tuto, you'll get the 250MHz bandwidth, the 50 Mpts depth and the additional decoding protocol (Parallel,RS232, I2C, SPI, LIN, CAN). Also you'll have the SLA tab on the display which of course won't work as no SLA hardware is present on the DHO804.
• 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

For the story, in my case, I first hacked to DHO924, discovered the incorrect bad offset so I ran a self-calibration with no success. I restored back to DHO804 model by push back my original vendor.bin and rebooted. Then also pushed back my calibration file (.cal) and rebooted again (I don't remember the offset was at that moment OK, anyway). I then upgraded to 00.01.02.00.02 and after the reboot I ran the self-calibration which resulted with a correct offset calibration. Finaly I hacked again to DHO924 model and after the reboot the offset calibration was still OK and of course the hack was working (250 MHz BW, 50 Mpts, ...). I've run a quick test with an eMMC running with 50MHz clock and I was able to clearly see the data bits while capturing the clock on chan 1 and one dataline on chan 2 @ 625 MSa/s while with the DHO804 model it was kind of inaccurate (the frequency measurement of the clock wasn't stable at all).

Well that's all folks ! I hope it will be helpful for other DHO804 owners


 

[Mechatrommer]

After hardware chage, go into the kernel debug dir I listed a few posts back, read the gpio file, what gpio pins (and values) have changed ?

this thread is a curse, i thought i saw your "kernel report"about gpio pins, now i cant find it i wish to ask how to do that step by step.. found it! https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389235/#msg5389235 then how to do it? into the kernel debug mode?

Screenshots...

ah there was a time when i was on HW12 that was few minutes ago yeah big thanks to AndyBig and participants/contributors here...

[AceyTech]

I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?

because we dont have a clue where to put it... maybe later as we gain comprehension. i guess what you meant is editing start_rigol_app.sh and pushing it back again? will sure try later.

You can put it into start_rigol_app.sh or execute it manually in a shell and after that execute /rigol/shell/restartScope.sh

Dont forget to comment out insmod to prevent loading this module.

In my case changing this value doesnt change anything. Or I didnt catch the change.

BTW. chmod can be changed to 444 (read only) and it still works. Most likely some Rigol developer was lazy and (s)he put just 777...

sounds easy for you, but not for me... i'll cope with this later. cheers.

We can't all be amazing software wizards @Mech.,
if so, there wouldn't be any software jobs... or wizards.

[swiperf0x]

I've dug in the previous post but I can't see clearly what you can do by changing the HW version ? I've seen here https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781 that you need to modify HW version to change the DHO804 into a DHO924 which what I have done without changing this HW version...So I'm kind of WTF ? Can you please tell me a little bit about the HW version ? I'm curious 

[Randy222]

After hardware chage, go into the kernel debug dir I listed a few posts back, read the gpio file, what gpio pins (and values) have changed ?

this thread is a curse, i thought i saw your "kernel report"about gpio pins, now i cant find it i wish to ask how to do that step by step.. found it! https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389235/#msg5389235 then how to do it? into the kernel debug mode?

Screenshots...

ah there was a time when i was on HW12 that was few minutes ago yeah big thanks to AndyBig and participants/contributors here...

In retrospect to your resistor stack on the side, if they represent an "8" then I suspect RK gpio pins are coded with internal pull-up to avoid floats. But this is TBD.

[AceyTech]

I've dug in the previous post but I can't see clearly what you can do by changing the HW version ? I've seen here https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781 that you need to modify HW version to change the DHO804 into a DHO924 which what I have done without changing this HW version...So I'm kind of WTF ? Can you please tell me a little bit about the HW version ? I'm curious 

@Mechatrommer has built his own ARB or AFG module that only the 9x4S models have, normally.  He also has built and is using a custom LA pod. 
He discovered some issues with full compatibility when using the upgraded hardware, and is currently investigating "full hardware" compatibility mode(by adapting the config(I.e., GPIO) resistors), as opposed to software hack methods.

This probably doesn't pertain to "normal" 800 -> 900 scope users.

[Mechatrommer]

We can't all be amazing software wizards @Mech.,
if so, there wouldn't be any software jobs... or wizards.

i'm no wizard, but if you ask me, i can edit REM autoexec.bat a little bit

I've dug in the previous post but I can't see clearly what you can do by changing the HW version ? I've seen here https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781 that you need to modify HW version to change the DHO804 into a DHO924 which what I have done without changing this HW version...So I'm kind of WTF ? Can you please tell me a little bit about the HW version ? I'm curious 

in order to understand this, you need to fully hack your DHO804 into DHO9x4S with LA probe hardware and punching out a good rectangle front of your dso enclosure. you can follow my posts up to dho800/900 bug and fix thread and then Howardlongs reply, its my recent finding so probably not finalized yet, i think you are the first "single post" poster who heard about this tonight... not even the other super posters who are probably sleeping right now . but if you are not intending to extend to HW hack, just 50Mpts and BW hack, HW 12 is probably fine for you... cheers.

[Randy222]

I've dug in the previous post but I can't see clearly what you can do by changing the HW version ? I've seen here https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5383781/#msg5383781 that you need to modify HW version to change the DHO804 into a DHO924 which what I have done without changing this HW version...So I'm kind of WTF ? Can you please tell me a little bit about the HW version ? I'm curious 

You can change 800's into 924 via just the vendor.bin and lic hack using zelea2 tool.
You do not need to change HW number.

The 800's simply do not have the extra hardware that the 900's have, thuse HW number change does not really help.

If you go beyond the basic software hack, you'll need to change HW number.

[Mechatrommer]

After hardware chage, go into the kernel debug dir I listed a few posts back, read the gpio file, what gpio pins (and values) have changed ?

this thread is a curse, i thought i saw your "kernel report"about gpio pins, now i cant find it i wish to ask how to do that step by step.. found it! https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389235/#msg5389235 then how to do it? into the kernel debug mode?

In retrospect to your resistor stack on the side, if they represent an "8" then I suspect RK gpio pins are coded with internal pull-up to avoid floats. But this is TBD.

i asked how to get to this console. but if you need me to have one linux pc, i'm sorry i dont have one.

[norbert.kiszka]

@Randy222 show me Your start script. Whole file from beginning to the last line, even if its a empty line.

attached

After some problems with home network and accidentially pushing it via adb non-root with no execute permissions (because of this I saw interesting things in the logs...), finally I made to boot with executing Your script. Looks like You added something more or it was like that before.

After running my scope on Your script I see two things...

One is this:

Code: [Select]

# 加载 MIPI 触摸屏驱动 - focaltech for guoxian
#sleep 20
insmod /rigol/driver/focaltech_ts.ko

sleep 20
echo ":STOP;:SYST:DATE 2099,12,31;:SYST:TIME 23,59,59;:DIS:CLOC 1" |toybox nc -q 2 localhost 5555
sleep 5
echo ":CHAN1:DISP 0" |toybox nc -q 2 localhost 5555
Why You (or somebody else) moved sleep 20 later instead leaving it? Somebody for some reason decided to make a delay before loading focaltech_ts.ko. I suggest to not change this behavior,

Second thing, now I have HW 0. I added echo before and after this printf and I can see it in log. Also file is created as it should.

So looks like something is wrong in Your script (before uploading it on my scope, printf trick was working). I dont want to waste time to debug this, so grab my script instead (attached) and try if it works as it should. This is almost original from 924S beside of printf, insmod commented out and chmod 444.

BTW. Im using FPGA flash from a DHO1000 (works the same). H12S2**** is for DHO1000 with single ADC as in readme.txt (GEL for DHO100 and DHO4000) from Rigol.

[ebastler]

In retrospect to your resistor stack on the side, if they represent an "8" then I suspect RK gpio pins are coded with internal pull-up to avoid floats. But this is TBD.

While it is difficult to figure out which BGA pad each resistor is connected to, it is trivial to figure out whether their other ends are connected to GND or to a supply voltage. I don't understand why this aspect still seems to be a matter of guesswork?

(Of course, whatever the hardware readout of the GPIO is, it could still be inverted in software. Or used to index a lookup table to find the eventual "hardware version" ID, for that matter.)

[norbert.kiszka]

@Randy222 show me Your start script. Whole file from beginning to the last line, even if its a empty line.

attached

After some problems with home network and accidentially pushing it via adb non-root with no execute permissions (because of this I saw interesting things in the logs...), finally I made to boot with executing Your script. Looks like You added something more or it was like that before.

After running my scope on Your script I see two things...

One is this:

Code: [Select]

# 加载 MIPI 触摸屏驱动 - focaltech for guoxian
#sleep 20
insmod /rigol/driver/focaltech_ts.ko

sleep 20
echo ":STOP;:SYST:DATE 2099,12,31;:SYST:TIME 23,59,59;:DIS:CLOC 1" |toybox nc -q 2 localhost 5555
sleep 5
echo ":CHAN1:DISP 0" |toybox nc -q 2 localhost 5555
Why You (or somebody else) moved sleep 20 later instead leaving it? Somebody for some reason decided to make a delay before loading focaltech_ts.ko. I suggest to not change this behavior,

Second thing, now I have HW 0. I added echo before and after this printf and I can see it in log. Also file is created as it should.

So looks like something is wrong in Your script (before uploading it on my scope, printf trick was working). I dont want to waste time to debug this, so grab my script instead (attached) and try if it works as it should. This is almost original from 924S beside of printf, insmod commented out and chmod 444.

BTW. Im using FPGA flash from a DHO1000 (works the same). H12S2**** is for DHO1000 with single ADC as in readme.txt (GEL for DHO100 and DHO4000) from Rigol.

Damn... After restoring back start_rigol_app.sh I still have HW in app as 0... So looks like something was changed permanently :/

Edit: Earlier I posted my 924S SD card image if somebody wants to test it.

[Mechatrommer]

In retrospect to your resistor stack on the side, if they represent an "8" then I suspect RK gpio pins are coded with internal pull-up to avoid floats. But this is TBD.

While it is difficult to figure out which BGA pad each resistor is connected to, it is trivial to figure out whether their other ends are connected to GND or to a supply voltage. I don't understand why this aspect still seems to be a matter of guesswork?

i didnt think of this. my scope is reassembled and i dont see much point to it anymore. thinking of it, even if the other end of resistors are connected to gnd, why the other ends also seemed paralleled? if they are connected directly to mcu pin? and with various and seemingly random resistor combination coming up with same HW number, all this binary theory seem nonsensical, better get ass down to soldering iron imho... anyway, lets other to discover this, i'm finished for the night.

Damn... After restoring back start_rigol_app.sh I still have HW in app as 0... So looks like something was changed permanently :/

told you its gonna bite! thanks for your start_rigol_app.sh.txt link but now i'm too afraid to push it to my scope

[norbert.kiszka]

told you its gonna bite! thanks for your start_rigol_app.sh.txt link but now i'm too afraid to push it to my scope

Just for curiosity I tried to bring back hdcode_gpio module and I still have HW 0.

In last resort we (or just maybe only me?) have backup of sd card.

[Randy222]

@Randy222 show me Your start script. Whole file from beginning to the last line, even if its a empty line.

attached

After some problems with home network and accidentially pushing it via adb non-root with no execute permissions (because of this I saw interesting things in the logs...), finally I made to boot with executing Your script. Looks like You added something more or it was like that before.

After running my scope on Your script I see two things...

One is this:

Code: [Select]

# 加载 MIPI 触摸屏驱动 - focaltech for guoxian
#sleep 20
insmod /rigol/driver/focaltech_ts.ko

sleep 20
echo ":STOP;:SYST:DATE 2099,12,31;:SYST:TIME 23,59,59;:DIS:CLOC 1" |toybox nc -q 2 localhost 5555
sleep 5
echo ":CHAN1:DISP 0" |toybox nc -q 2 localhost 5555
Why You (or somebody else) moved sleep 20 later instead leaving it? Somebody for some reason decided to make a delay before loading focaltech_ts.ko. I suggest to not change this behavior,

Second thing, now I have HW 0. I added echo before and after this printf and I can see it in log. Also file is created as it should.

So looks like something is wrong in Your script (before uploading it on my scope, printf trick was working). I dont want to waste time to debug this, so grab my script instead (attached) and try if it works as it should. This is almost original from 924S beside of printf, insmod commented out and chmod 444.

BTW. Im using FPGA flash from a DHO1000 (works the same). H12S2**** is for DHO1000 with single ADC as in readme.txt (GEL for DHO100 and DHO4000) from Rigol.

I tested delay before loading KLM for touchscreen. 'sleep 0' made no diff, so why delay the startup with a 'sleep 20'? I suspect much in the 800-900 start script (lots of code) is carry-over from other scope coding projects. Example, Rigol no longer starts the scope app in start script, it's just commeneted out. I posted about all of this long ago in this thread. If you mod the OEM start script and just comment out that sleep 20 before ts KLM, the unit will boot that much faster.

The 20 delay before sending scpi commands is because scope app is not yet ready to take actions from scpi commands. It's coincidence that the two are same number 20.
There's multiple scpi lines because if you send commands back-back the scope may ignore the aft items because it needs to wait for one scpi to complete before working on the next one. AT least from my testing and reading up on scpi, the commands should all be individual sends, but I was able to stack them to limit the number of nc's. If you send scpi commands individually but too fast back-back, you get same issue where some commands are ignored, so there really needs to be a delay bewteen commands so each one can complete before next one is received.

[AceyTech]

if souldevelop's report is correct... i just did some photoshop fun (attached) to find where are the 25AA, 28U, 30U, 26V pins are, somewhere in red circle... based on possible closest route, another candidate for config resistor could be in yellow circle.. we went through the blue circle fun be warned you could damage something if not careful...
Those are some awesome Ps skillz you got there, Mister!  Wicked.  Wish I would've thought of & did that.   

otoh i dont tend to do your sd card mod. possibly one day this thing is fixed whether in HW or SW, so we dont need to switch sd card anymore, so you'll be left with irreversible cutted top enclosure for no good reason. not a big deal really.

That's ok.  My card hack isn't for everyone.  I just posted it in case it might benefit someone.

Fantastic job figuring out the HW config bits, buddy.! 

[Randy222]

told you its gonna bite! thanks for your start_rigol_app.sh.txt link but now i'm too afraid to push it to my scope

There's nothing in that start script that impacts and HW number. The start script is sequences fpga, ts, does a boot counter, yada yada yada. Very boring stuff.

I added sysctl commands for tuning, and added some scpi commands to stop scope, turn off ch1, enable clock, and to set clock & date.

HW number in scope app comes from something reading the 4 gpio pin values. The pin states are read by the hdcode_gpio KLM.
How that 4bit word is read is TBD I guess.
I'll do some sleuthing.

[norbert.kiszka]

told you its gonna bite! thanks for your start_rigol_app.sh.txt link but now i'm too afraid to push it to my scope

There's nothing in that start script that impacts and HW number. The start script is sequences fpga, ts, does a boot counter, yada yada yada. Very boring stuff.

I added sysctl commands for tuning, and added some scpi commands to stop scope, turn off ch1, enable clock, and to set clock & date.

HW number in scope app comes from something reading the 4 gpio pin values. The pin states are read by the hdcode_gpio KLM.
How that 4bit word is read is TBD I guess.
I'll do some sleuthing.

Theoretically it shoudlnt. But You have additional SCPI commands and sysctl values changed.

Nah, I will try to reinstall app - maybe it will help. If not, then I will reflash SD card.

Almost forget, I reflashed back original FPGA image, so I will try DHO100 back again.

[AndyBig]

While it is difficult to figure out which BGA pad each resistor is connected to, it is trivial to figure out whether their other ends are connected to GND or to a supply voltage. I don't understand why this aspect still seems to be a matter of guesswork?

I couldn't stand it, curiosity got the better of me. Although I don’t need this hardware hack, I’m just very interested in clarifying this issue myself. So, I disassembled and measured the resistances and connections between them. The result is a picture in the photo. Red are power connections, blue are ground connections, black are signal connections.
It turns out that four pairs of resistors take part in encoding the HW version: R1+R2, R3+R4, R7+R8 and R9+R10. Depending on which resistor of the pair is installed, the GPIO will be pulled to ground or to power.
Resistors R5 and R6 clearly stand out from the overall picture in terms of their values and location; this is something not related to HW coding.

[norbert.kiszka]

told you its gonna bite!

Little strange, but I figured out direct cause.

[pid  3008] openat(AT_FDCWD, "/dev/hdcode_gpio", O_RDWR|O_NONBLOCK) = -1 EACCES (Permission denied)

File descriptor is opened with O_RDWR flag (why???), like it was always (I was using strace before), but according to current strace, now it fails.

Previously it was working with 444 (-r--r--r--) and now not so much. I changed it to 666 (rw) and now it works again (both printf and original module).

Probably Your script changed something, but who cares?

[norbert.kiszka]

Anybody knows some deassembler or decompiler capable of arm64 and to view+change values in hex?

I tried gdb and Relyze (under Wine) - first displays values in other format (stackoverflow doesnt help) and second one fails with unknown opcode. So I cant change libscope-auklet.so.

[AndyBig]

It looks like the version encoding bits are arranged like this: