Hacking the Rigol DHO800/900 Scope

[norbert.kiszka]

If somebody wants to see functions list in libscope-auklet.so with args and offsets, there is a lot of it, so I put it into attachment.

[antiquant]

Mechatrommer, you've amazed us one more time! My congratulations!
(after a glance on a bottom side of the main pcb with your writings I thought I understand both configurations. But after I look at your writings on a piece of paper I get confused a little though)

BTW, would you tell us, please, something more about the design of your AFG custom-made add-on board?

[Randy222]

If somebody wants to play with HW number, there is simpler way, than I wrote before.

Code: [Select]

printf '\x8' > /dev/hdcode_gpio
Of course, get rid of hdcode_gpio module first, by unloading it (rmmod hdcode_gpio) and commenting it out in /rigol/shell/start_rigol_app.sh - above command can go into this file (personally I did it at very beginning).

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

The app does not appear to be reading a file in /dev
When you unload the ko module the whole hdcode_gpio device is removed from the device tree, so when you direct printf to /dev/hdcode_gpio it's not going into the KLM, it just creates a regular file.

So your procedure to direct data into the dev file does not work.

[norbert.kiszka]

If somebody wants to play with HW number, there is simpler way, than I wrote before.

Code: [Select]

printf '\x8' > /dev/hdcode_gpio
Of course, get rid of hdcode_gpio module first, by unloading it (rmmod hdcode_gpio) and commenting it out in /rigol/shell/start_rigol_app.sh - above command can go into this file (personally I did it at very beginning).

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

The app does not appear to be reading a file in /dev
When you unload the ko module the whole hdcode_gpio device is removed from the device tree, so when you direct printf to /dev/hdcode_gpio it's not going into the KLM, it just creates a regular file.

So your procedure to direct data into the dev file does not work.

Did You read what I wrote form beginning to the end with proper understanding? I wrote clearly to unload this module first - couple times. How many times I should repeat this until You catch it?

You cant overwrite char device, but for any app reading is reading like any other file. Doesnt matter if its a block device or regular text file. Kernel will give exact same data to the process.

[Mechatrommer]

BTW, would you tell us, please, something more about your AFG custom-made add-on board?

currently completed rev2 testing and as you can see still stucked on the dho board in recent pictures. for my usage its now so called "usable", but it still has about 3mVpp switching crosstalk and 10mVpp noises on the output, and some distortion at high Vpp at 10-15MHz, but for some others ee gurus, these figures are probably childish, so i try to fondle the last revision 3 on the board, add more decoupling caps here and there and ground plane stitching vias, hopefully there will be small improvement. at the same time along with buying more not so cheap IC/opamp parts.. i'm also spinning LA probe board rev 2 as i have one big stupid careless mistake on schematics earlier only realizing it when pcb ver1 completed , but the effect will not be so obvious on the output. those i've completed in the last 2 days, now while i'm thinking what other project to put in pcb since i have more spaces before sending to jlcpcb, here you see i'm doing some fun on the config resistor again

btw i think few people asked/PM me about this because they need to see the schematics? or even the pcb gerber files? i'll think about that. there will be higher chance for me to publish schematics in full or partly depending how people ask, or how a particular thread discussion forms. gerber files? maybe not because i have think of our competitors in the northern hemisphere they are very good at knocking competitors to the corner (we read history, even in this forum if you search hard enough, hint nanovna) i hope you get what i mean cheers.

[Randy222]

for HW mod from 12 to 8 by luck and brainstorming in this thread... i found a way.. there's another place on the side for config resistor (see attached), before modding, i measure resistance, exactly same thing as before, parallel resistor measured 6Kohm, single resistor measured 10Kohm, so it seems coincidence, why not try? i tried 3 combinations to get what i want (see attached) most significant bit is the topmost resistor in pcb picture below (pcb shows original HW 12 resistor setup).

and in this video, i now can trigger on digital channel (on original HW 12 i cant) so the conclusion is, there is/are differences in FW execution based on HW number. fwiw...



cheers.

The pics you have are very confusing.

1) 12 is not binary 1010, 12=1100
2) you show what appears to be 8 connections of some sort that define HW number. I can say 100% that the hdcode_gpio KLM only reads 4, gpio numbers 12 11 8 4 and in that binary order. The kernel shows them as 1100, aka "12".
3) the physical layout of resistors do not appear to be in binary order, because 1010 does not equal 12, and for clarity what you literally observe is not 1010. The "0" are non-connected. The RK needs to do pull up or down for non-connected to avoid floats.
4) we also do not know how the gpio pins are pulled inside the RK. If they are internally pulled up, then a non-connected pin (no resistor) is a "1" inside the RK. If they are internally pulled down, then a non-connected pin (no resistor) is a "0" inside the RK. The only way to know for sure is by way of RK datasheet, which might say "programmable", or by testing the voltage state between gpio pins and resistor.

So, I am curious, you show 8 resistors pads that define HW number. Do the top most ones goto gpio 12 11 8 and 4? Where do the others go?

[norbert.kiszka]

The kernel shows them as 1100, aka "12".

Not the kernel, but module hdcode_gpio.ko which calls printk function in the kernel. I posted decompiled this module earlier.

[Randy222]

If somebody wants to play with HW number, there is simpler way, than I wrote before.

Code: [Select]

printf '\x8' > /dev/hdcode_gpio
Of course, get rid of hdcode_gpio module first, by unloading it (rmmod hdcode_gpio) and commenting it out in /rigol/shell/start_rigol_app.sh - above command can go into this file (personally I did it at very beginning).

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

The app does not appear to be reading a file in /dev
When you unload the ko module the whole hdcode_gpio device is removed from the device tree, so when you direct printf to /dev/hdcode_gpio it's not going into the KLM, it just creates a regular file.

So your procedure to direct data into the dev file does not work.

Did You read what I wrote form beginning to the end with proper understanding? I wrote clearly to unload this module first - couple times. How many times I should repeat this until You catch it?

You cant overwrite char device, but for any app reading is reading like any other file. Doesnt matter if its a block device or regular text file. Kernel will give exact same data to the process.

I did unload the KLM.


Unload it, and then you direct printf stdout to /dev/hdcode_gpio, and all the OS does is create a regular file in /dev (the inode is a REGULAR FILE). Nothing reads that regular file.

When I printf to /dev/hdcode_gpio, that file contains the hex value, but the scope app cannot find the actual value, so it says HW Type is "0".

Please correct my observations as needed.

The kernel shows them as 1100, aka "12".

Not the kernel, but module hdcode_gpio.ko which calls printk function in the kernel. I posted decompiled this module earlier.

I was looking at gpio in kernel debug dir, the kernel writes all that info. The hdcode KLM only updates gpio 12 11 8 and 4. Sure, the KLM is the item to fetch the gpio states, but kernel writes out that gpio file.

[Mechatrommer]

(after a glance on a bottom side of the main pcb with your writings I thought I understand both configurations. But after I look at your writings on a piece of paper I get confused a little though)

sorry if i cause confusion, i've corrected the picture on which side i change the config... this is if you already own DHO8*4... here what i played with tonight... to put simply, if you want to change HW 12 to HW 8, just add another 10Kohm 0402 resistor on the bottom side where the resistor is missing... 0603 resistor should be possible with some kongfu... or move the second top most resistor to the bottom most if you dont have the extra part... fwiw...

[norbert.kiszka]

When you unload the KLM, the hdcode_gpio device is REMOVED from device tree, there is no long a /dev/hdcode_gpio char device in /dev
I say it again, When you unload the KLM, the hdcode_gpio device is REMOVED from device tree, there is no long a /dev/hdcode_gpio char device in /dev

Unload it, and then you direct printf stdout to /dev/hdcode_gpio, and all the OS does is create a regular file in /dev (the inode is a REGULAR FILE).

Thats the point. Let me repeat again, when file is being read, then it doesnt matter if its a some sort of device or a regular file.

Nothing reads that regular file.

Did You check this file permissions? If its not readable then make it readable:

Code: [Select]

chmod 444 /dev/hdcode_gpio

When I printf to /dev/hdcode_gpio, that file contains the hex value, but the scope app cannot find the actual value, so it says HW Type is "0".

Printf with \x switch makes printf to read value as hex but output is binary - it converts hex to bin. Couple examples (hex = bin = decimal):

\x0 = 0 0 0 0 0 0 0 0 = 0

\x1 = 0 0 0 0 0 0 0 0 = 1

\x8 = 0 0 0 0 1 0 0 0 = 8

\xa = 0 0 0 0 1 0 1 0 = 10

If it works in my scope, then it must work in Yours.

[Mechatrommer]

So, I am curious, you show 8 resistors pads that define HW number. Do the top most ones goto gpio 12 11 8 and 4? Where do the others go?

i dont know what theory you try explaining.. we agree from your people's expertise there a 4 config pins... but playing around with 4 resistors earlier on top side didnt come up with all binaries you theorized...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839

so i had a go on another 4 resistors on the side this night, it turned out thats where i need to change to get HW 8. i dont know what binary what logical arrangement there is, all i know now my FW reported HW 8, so i considered it as success...

[norbert.kiszka]

I was looking at gpio in kernel debug dir, the kernel writes all that info. The hdcode KLM only updates gpio 12 11 8 and 4. Sure, the KLM is the item to fetch the gpio states, but kernel writes out that gpio file.

God damn it. Everything goes thru the kernel unless process or module reads or write to ram. Module calls printk which is the same as printf but output goes into kernel log. Data is generated by a module and nothing else.

[Randy222]

Did You check this file permissions? If its not readable then make it readable:



Printf with \x switch makes printf to read value as hex but output is binary - it converts hex to bin. Couple examples (hex = bin = decimal):

\x0 = 0 0 0 0 0 0 0 0 = 0

\x1 = 0 0 0 0 0 0 0 0 = 1

\x8 = 0 0 0 0 1 0 0 0 = 8

\xa = 0 0 0 0 1 0 1 0 = 10

If it works in my scope, then it must work in Yours.

My box is an 804.
I did exactly as you said, right down to 444 in start script.
The reg file is there, hexdump shows the hex value in the file.

Scope app still shows HW type "0".

[Randy222]

So, I am curious, you show 8 resistors pads that define HW number. Do the top most ones goto gpio 12 11 8 and 4? Where do the others go?

i dont know what theory you try explaining.. we agree from your people's expertise there a 4 config pins... but playing around with 4 resistors earlier on top side didnt come up with all binaries you theorized...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839

so i had a go on another 4 resistors on the side this night, it turned out thats where i need to change to get HW 8. i dont know what binary what logical arrangement there is, all i know now my FW reported HW 8, so i considered it as success...

Ahh, I see. So the 4 down to side defines HW type number, in your pic, an 8 ?

With three resistors and a 4bit word, only the un-connected pad can be the 8 in binary, so I suspect the resistors are actually connected to GND, and the unconnected is pulled up in RK.

On the side pads, top to bottom, I suspect they are GPIO pins 4 8 11 12, 12 being most significant in the 4bit word, "12/11/8/4", aka 1000, since 1000 = 8

[norbert.kiszka]

Did You check this file permissions? If its not readable then make it readable:



Printf with \x switch makes printf to read value as hex but output is binary - it converts hex to bin. Couple examples (hex = bin = decimal):

\x0 = 0 0 0 0 0 0 0 0 = 0

\x1 = 0 0 0 0 0 0 0 0 = 1

\x8 = 0 0 0 0 1 0 0 0 = 8

\xa = 0 0 0 0 1 0 1 0 = 10

If it works in my scope, then it must work in Yours.

My box is an 804.
I did exactly as you said, right down to 444 in start script.
The reg file is there, hexdump shows the hex value in the file.

Scope app still shows HW type "0".

I see two possibilities. One is You are not doing all the steps. Second one, You are doing it in completely different way than I told it many times.

Execute this command in a shell. Its the last time when I writing this. I dont want to repeat myself 50 times in a row.

Code: [Select]

adb connect ip:5555
adb root
adb shell
rmmod hdcode_gpio
printf '\x8' > /dev/hdcode_gpio
/rigol/shell/restartScope.sh

I dont want to hear it doesnt work, beacuse its too simple to make it wrong.

[Mechatrommer]

So, I am curious, you show 8 resistors pads that define HW number. Do the top most ones goto gpio 12 11 8 and 4? Where do the others go?

i dont know what theory you try explaining.. we agree from your people's expertise there a 4 config pins... but playing around with 4 resistors earlier on top side didnt come up with all binaries you theorized...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839

so i had a go on another 4 resistors on the side this night, it turned out thats where i need to change to get HW 8. i dont know what binary what logical arrangement there is, all i know now my FW reported HW 8, so i considered it as success...

Ahh, I see. So the 4 down to side defines HW type number.

God damn it ... 4 on top also can change HW number as S2084 and those germany's forum link figured out much earlier, but you wont get HW 8, look closely the combination picture in earlier post linked above and what is the FW reporting about it. it wont match your binary pull up and pull down theory there. you need to browse all recent posts, maybe 10-20 pages back to get the feel of it... cheers.

[Mechatrommer]

if you ask me to where those 8 resistors are connected to RK3399? the answer is i dont know. and probably nobody in this and that forum knows. hacking is about getting what we want without knowing everything. the other non-hack version is full reverse engineering or going the proper education or design route, be my guest cheers.

[Randy222]

Did You check this file permissions? If its not readable then make it readable:



Printf with \x switch makes printf to read value as hex but output is binary - it converts hex to bin. Couple examples (hex = bin = decimal):

\x0 = 0 0 0 0 0 0 0 0 = 0

\x1 = 0 0 0 0 0 0 0 0 = 1

\x8 = 0 0 0 0 1 0 0 0 = 8

\xa = 0 0 0 0 1 0 1 0 = 10

If it works in my scope, then it must work in Yours.

My box is an 804.
I did exactly as you said, right down to 444 in start script.
The reg file is there, hexdump shows the hex value in the file.

Scope app still shows HW type "0".

I see two possibilities. One is You are not doing all the steps. Second one, You are doing it in completely different way than I told it many times.

Execute this command in a shell. Its the last time when I writing this. I dont want to repeat myself 50 times in a row.

Code: [Select]

adb connect ip:5555
adb root
adb shell
rmmod hdcode_gpio
printf '\x8' > /dev/hdcode_gpio
/rigol/shell/restartScope.sh

I dont want to hear it doesnt work, beacuse its too simple to make it wrong.

I did it via SSH, not adb, AND, I also commented out the KLM in start script, AND, I added printf and chmod 444 in start script directly under the commented KLM.
Using restart script or rebooting, HW type still says "0".

[norbert.kiszka]

I did it via SSH, not adb, AND, I also commented out the KLM in start script, AND, I added printf and chmod 444 in start script directly under the commented KLM.
Using restart script or rebooting, HW type still says "0".

KLM airlines?

">" is being parsed by a bash (or other shell). If You are sending it from host terminal, then ">" and everything after that is not going thru. So You are generating file in wrong machine.

[Randy222]

So, I am curious, you show 8 resistors pads that define HW number. Do the top most ones goto gpio 12 11 8 and 4? Where do the others go?

i dont know what theory you try explaining.. we agree from your people's expertise there a 4 config pins... but playing around with 4 resistors earlier on top side didnt come up with all binaries you theorized...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382839/#msg5382839

so i had a go on another 4 resistors on the side this night, it turned out thats where i need to change to get HW 8. i dont know what binary what logical arrangement there is, all i know now my FW reported HW 8, so i considered it as success...

Ahh, I see. So the 4 down to side defines HW type number.

God damn it ... 4 on top also can change HW number as S2084 and those germany's forum link figured out much earlier, but you wont get HW 8, look closely the combination picture in earlier post linked above and what is the FW reporting about it. it wont match your binary pull up and pull down theory there. you need to browse all recent posts, maybe 10-20 pages back to get the feel of it... cheers.

It's not a theory. I posted the gpio values for hardware 12. There 4 pins that are read by the hdcode_gpio KLM. Thise 4 pins are "rk gpio" 12 11 8 and 4. They are literally set hi hi lo lo per the KLM, 1100 = 8+4+0+0 = 12. Those gpio pin settings must come from SMD's on the board.

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.
 

[norbert.kiszka]

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

[Randy222]

I did it via SSH, not adb, AND, I also commented out the KLM in start script, AND, I added printf and chmod 444 in start script directly under the commented KLM.
Using restart script or rebooting, HW type still says "0".

KLM airlines?

">" is being parsed by a bash (or other shell). If You are sending it from host terminal, then ">" and everything after that is not going thru. So You are generating file in wrong machine.

What?

The terminal via ssh dumps in as sh, not bash.
The start script runs under bash

Both printf from sh or bash create the same file

Code: [Select]

0000000 0008
0000001

What does your file look like from hexdump?

[Randy222]

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

I'll grab it.

[Mechatrommer]

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.

[norbert.kiszka]

What does your file look like from hexdump?