Hacking the Rigol DHO800/900 Scope

[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.

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.

Theoretical?

[AndyBig]

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.

Ghidra, IDA.

[AceyTech]

I have 924S, later I will do some photosmodules

@norbert.kiszka I still dare to remind you.....

As for now I never removed heatsink. I was going to modify one channel, but I didnt. Also I cant find thermopads - Im not sure if I can reuse existing ones after heatisnk removal (maybe clean them with isopropyl?).

Anyway, I just did two photos just above heatsink. If You need something more (right now without removing heatsink), just give me a sign.

If You going to change only HW number, then read my previous posts about it, because You can change it in "soft" way, without changing resistors or decompiling anything.

Will somebody please tell @norbert.kiszka that:
  a.) the "thermopads" can be re-used safely. 100% re-workable
  b.) he doesn't need to clean them, and probably shouldn't to keep from degrading the pad.
  c.) he can but probably doesn't need to, clean the chips or heatsink., unless it gets contaminated for some reason.
  d.) he should leave the pads attached to whatever surface they are stuck to., as @Mechatrommer suggested.
  e.) we would still love to see the "bottom side" pics of an authentic 900 series scope.

[Randy222]

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?

So chmod 666 and not 444?

666 works, but I see no changes in scope. Lets see if a remove a lic file.

And I need to make a correction, I run my 804 with a 914 vebdor.bin file. I ight have said 924 in the past.

[AndyBig]

Will somebody please tell @norbert.kiszka that:
  a.) the "thermopads" can be re-used safely. 100% re-workable
  b.) he doesn't need to clean them, and probably shouldn't to keep from degrading the pad.
  c.) he can but probably doesn't need to, clean the chips or heatsink., unless it gets contaminated for some reason.
  d.) he should leave the pads attached to whatever surface they are stuck to., as @Mechatrommer suggested.
  e.) we would still love to see the "bottom side" pics of an authentic 900 series scope.

But to access the back side of the board you don’t need to remove the heatsink at all

[Mechatrommer]

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.

i think you nailed it. R1+R2 is most significant bit, and R7+R8 is the second. although there are still inconsistency in earlier table such as HW4 (0000) and HW13 (0010) ie R1-4. i guess the RK's pins are floating we should not let both resistors in a pair to be missing. if both resistors (pull up and pull down) are present, they combined (middle voltage) will still read as 0. congratulation on your work deciphering it.

[AceyTech]

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.

I followed a guide and made a bootable USB stick for Ubuntu, which is super user friendly, intuitive and easy to use, to boot my Win10 machine with. 
  --I liked it so much that I used the built in boot utility to re-partition my Windoze and install Ubuntu permanently, and now I can pick which OS to run on start-up.  It's awesome.  One of the gurus here mentions Debian... A LOT. so maybe that is worth checking out.

FYI: I had to get a guide for BASH scripting, and that really helped understanding what's going on under the hood in those *.sh files. 
IMHO; It's Linux's supercharged version of *.BAT files.  Once you understand all the numbers, re-direct pipes etc., things get a bit easier.

[Mechatrommer]

Will somebody please tell @norbert.kiszka that:
  a.) the "thermopads" can be re-used safely. 100% re-workable

no, the thermopad is very vurnerable, i tried to lift the pad for FPGA with tweezer it almost chipped where i pinched the tweezer, its like cheeze. either you handle/lift it with very care, or just leave it there where it stick... there is no glue or paste for it to stick, just an oily thing.

[norbert.kiszka]

So chmod 666 and not 444?

If You try, it probably will not explode or take Your soul.

But to access the back side of the board you don’t need to remove the heatsink at all

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

[Randy222]

Will somebody please tell @norbert.kiszka that:
  a.) the "thermopads" can be re-used safely. 100% re-workable

no, the thermopad is very vurnerable, i tried to lift the pad for FPGA with tweezer it almost chipped where i pinched the tweezer, its like cheeze. either you handle/lift it with very care, or just leave it there where it stick... there is no glue or paste for it to stick, just an oily thing.

I lifted them with my fingers. They are soft like American Cheese. Maybe the psi from a tweezer pinch is too much.

[AceyTech]

Will somebody please tell @norbert.kiszka that:
  a.) the "thermopads" can be re-used safely. 100% re-workable
  b.) he doesn't need to clean them, and probably shouldn't to keep from degrading the pad.
  c.) he can but probably doesn't need to, clean the chips or heatsink., unless it gets contaminated for some reason.
  d.) he should leave the pads attached to whatever surface they are stuck to., as @Mechatrommer suggested.
  e.) we would still love to see the "bottom side" pics of an authentic 900 series scope.

But to access the back side of the board you don’t need to remove the heatsink at all

Oh yeah.  True!  I forgot that.  Thanks.

[Randy222]

So chmod 666 and not 444?

If You try, it probably will not explode or take Your soul.

But to access the back side of the board you don’t need to remove the heatsink at all

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

chmod to 666 worked. But nothing in scope seemed to have changed.

My config however may be a limiting factor. I run 804 as a 914. Maybe HW 8 changes something if the vendor.bin was a 924 version?

I also removed all my lic files and tried HW 8. The about shows 914 125-BW HW-8, and the ch still has 50M depth.

So, perhaps mem depth is just from vendor.bin. I guess I could try a 924 vendor bin to see if the 250-BW comes in by default, but I have a lic for the 914.

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?

All that, I am back to std insmod of hdcode KLM, HW-12 running as a 914 50M 250BW. I think this is the best an 800 can get without hardware hacking.

[norbert.kiszka]

chmod to 666 worked. But nothing in scope seemed to have changed.

Maybe RKey.data? Anyway, You can try my SD card image (flash it or copy single files after mounting it with offsets) which I posted some days ago... Its almost original DHO924S - only added Nova launcher and VCMI (engine for HIII game).

but you need to unscrew all the heatsink's screws because the threads are on the metal enclosure, you can do without removing heatsink but be carefull when switching pcb upside down, heatsink could fall by gravity, if it drops to hard rock floor, its possible to break into pieces, i dont know what aluminium they used, hopefuilly not brittle one.

It looks like cheap one. I dont expect aviation grade aluminium in a cheap oscilloscope.

[AndyBig]

i think you nailed it. R1+R2 is most significant bit, and R7+R8 is the second. although there are still inconsistency in earlier table such as HW4 (0000) and HW13 (0010) ie R1-4.

Yes, this confuses me a little too, but it could be, for example, due to flux residues.

i guess the RK's pins are floating we should not let both resistors in a pair to be missing. if both resistors (pull up and pull down) are present, they combined (middle voltage) will still read as 0. congratulation on your work deciphering it.

That's right, each pair must contain one of the resistors. And only one. Two resistors is also incorrect, since this is a formally undefined value.

But to access the back side of the board you don’t need to remove the heatsink at all

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.

But to access the back side of the board you don’t need to remove the heatsink at all

but you need to unscrew all the heatsink's screws because the threads are on the metal enclosure, you can do without removing heatsink but be carefull when switching pcb upside down, heatsink could fall by gravity, if it drops to hard rock floor, its possible to break into pieces, i dont know what aluminium they used, hopefuilly not brittle one.

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

[norbert.kiszka]

I just made a order for new thermopads (6 W/m⋅K). I need to remove this heatsink for many reasons - including photos and overclocking this puppy (which I already did but as for now only FPGA).

[Randy222]

chmod to 666 worked. But nothing in scope seemed to have changed.

Maybe RKey.data? Anyway, You can try my SD card image (flash it or copy single files after mounting it with offsets) which I posted some days ago... Its almost original DHO924S - only added Nova launcher and VCMI (engine for HIII game).

but you need to unscrew all the heatsink's screws because the threads are on the metal enclosure, you can do without removing heatsink but be carefull when switching pcb upside down, heatsink could fall by gravity, if it drops to hard rock floor, its possible to break into pieces, i dont know what aluminium they used, hopefuilly not brittle one.

It looks like cheap one. I dont expect aviation grade aluminium in a cheap oscilloscope.

RKey stayed the same.

However, RKey will be regen if the RKey is missing. So I am not sure if HW-8 would gen a new RKey that would unlock additional features.
With 800 being limited in actual hardware, I don't think there's much to gain when using a 914 or 924 vendor.bin, other than 250BW and 50M depth, but we can get that on a 800 vendor.bin using the zelea2 lic gen tool.

My 804 became a 914, all that really changed was the addition of the digi pad in bottom of screen, which cannot be used on 800 hardware.

[AndyBig]

I just made a order for new thermopads (6 W/m⋅K). I need to remove this heatsink for many reasons - including photos and overclocking this puppy (which I already did but as for now only FPGA).

Have you overclocked your FPGA? So you already have a confirmed sampling frequency greater than 1.25 GHz?

[AceyTech]

But to access the back side of the board you don’t need to remove the heatsink at all

but you need to unscrew all the heatsink's screws because the threads are on the metal enclosure, you can do without removing heatsink but be carefull when switching pcb upside down, heatsink could fall by gravity, if it drops to hard rock floor, its possible to break into pieces, i dont know what aluminium they used, hopefuilly not brittle one.

It's actually cast aluminum, with machining operations after casting..  Pretty typical in low budget, high volume applications, and sadly, also less thermal conductivity compared to extruded aluminum heatsinks.

[norbert.kiszka]

I just made a order for new thermopads (6 W/m⋅K). I need to remove this heatsink for many reasons - including photos and overclocking this puppy (which I already did but as for now only FPGA).

Have you overclocked your FPGA? So you already have a confirmed sampling frequency greater than 1.25 GHz?

FPGA and DAC are of course two separate things. I just found sample rate limit in a libscope-auklet.so and Im going to break this thing. PLL is capable up to 5.5 GHz, but probably DAC has own internal freq. multiplier (according to my findings in a software), so PLL is not a problem here. Anyway, PLL kernel module is just a very simple library to make SPI from GPIO pins - so we possibly can manage PLL frequency without app and FPGA, but its pointless (app needs to change that and user has to calculate time measurements every time - so its heavly time consuming and prone to errors).

Speaking of experiments. In DHA1k/4k GEL there is a many FPGA images - there is a readme of what is what (two different FPGA models and one/two DACs). I didnt make notes (lazy me) but images with _bode and end of file name, gives strange and rare spikes in a waveform (beside of that it works). However I decided to test runt trigger on it and it works perfectly.

Edit: I was thinking about changing FPGA but it takes time and money, also I dont like to (de)solder BGA. DHO4000 have two dacs and FPGA with two cores instead of one - probably because of two dacs.

[Randy222]

Calibration and Debug menu

After hitting About 3x, in the debug menu, anyone tune the ADC Clock settings?

Then in the SelfCal menu, it shows 12 cal items. If Itry to select them all, the cal fails. Should they not all pass? Maybe some are not applicable to an 804 running with a 914 vendor.bin ?

[norbert.kiszka]

Calibration and Debug menu

After hitting About 3x, in the debug menu, anyone tune the ADC Clock settings?

Then in the SelfCal menu, it shows 12 cal items. If Itry to select them all, the cal fails. Should they not all pass? Maybe some are not applicable to an 804 running with a 914 vendor.bin ?

Once I tried to select only DDR with FPGA flashed with image from DHO1000 and it works. Also it gives some data after click on "detail".

Now I tried once more and after that I see random short and big spikes on unconnected channel...

Edit: after running it third time (DDR+CH1), spikes are the same. But after restarting app spikes disapered.

[AndyBig]

FPGA and DAC are of course two separate things.

These are very closely related things, so until working sampling above 1.25 GHz has been achieved, talking about any overclocking of the FPGA makes no sense And I repeat once again that the Artix firmware will not work in Zynq. These are too different systems. No matter how much you want to believe otherwise.

DHO4000 have two dacs and FPGA with two cores instead of one - probably because of two dacs.

Did you want to write an ADC rather than a DAC? And what two cores are we talking about? What kind of cores does Artix have? Zynq actually has a dual-core processor on board, this is its main difference from Artix.

Then in the SelfCal menu, it shows 12 cal items. If Itry to select them all, the cal fails. Should they not all pass? Maybe some are not applicable to an 804 running with a 914 vendor.bin ?

No, calibration fails even in an oscilloscope without modifications if you select unnecessary items.

[norbert.kiszka]

Artix firmware will not work in Zynq

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.

Did you want to write an ADC rather than a DAC?

Yeah, my mistake.

talking about any overclocking of the FPGA makes no sense

Thats a one (small) step closer to increase sample rate.

And I repeat once again that the Artix firmware will not work in Zynq

Did You try this? Or its just me?

Zynq actually has a dual-core processor on board, this is its main difference from Artix.

Two ADC = two cores in FPGA. Probably.

No, calibration fails even in an oscilloscope without modifications if you select unnecessary items.

DDR option works. This is probably related to DMA stuff.

[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.

It won't be the other way around either. How can I explain it to you using an example that you can understand... It’s like taking a Linux image compiled for RK3399 and trying to run it on RK3368.

Thats a one (small) step closer to increase sample rate.

This is a small step in an unknown direction with an unknown result. And even with a misunderstanding whether there is any result at all

Did You try this? Or its just me?

I worked with FPGAs, wrote firmware for them. So I know what FPGAs are, how they work, what the binary for them is and how it loads and works.

Two ADC = two cores in FPGA. Probably.

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.

DDR option works. This is probably related to DMA stuff.

Well, not all options lead to calibration failure. But I know for sure that the crash is caused by even just one option included in addition to the standard ones. I don’t remember which one exactly.

[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: