Hacking the Rigol DHO800/900 Scope

[gabiz_ro]

Is not in FPGA it is attached to to FPGA via a SPI bus
From that external memory or JTAG (selection made by jumper) FPGA boot and load its configuration etc.

[Randy222]

Interesting, the spi2flash binary has the BOOT.bin file location-name hardcoded in it.

[gabiz_ro]

https://docs.xilinx.com/r/en-US/ug1283-bootgen-user-guide/Introduction
Good lecture

[zelea2]

I was trying to expand my program which reads and writes the FRAM memory to the Serial Flash memory.
By examining the 3 example programs spi2erase, spi2flash and spi2boot I saw that they were using the kernel /dev/spidev1.0 device.
In my naivety I thought that the flash is connected directly to one of the RK3399 chip SPI interfaces which is not true!
The SPI interface is connected to the Zynq-7000 FPGA.

To erase the flash the main CPU writes 6 bytes "\rPROG\r" followed by 4 bytes (MSB) of address followed by 4 bytes (MSB) of length.
To write the flash you have to send 256 byte chunks with 1ms delay in between.
To select the boot image the main CPU writes 6 bytes "\rBOOT\r" followed by 4 bytes (MSB) of address then wait 5 seconds.
As far as I can see there is no way to read back to content of the serial flash (without an external programmer). This chip is connected to the FPGA
and it is the ARM32 inside the FPGA which is responsible for sending commands. Multiple serial flash chip vendors are supported.

If you examine the /rigol/FPGA/BOOT.bin file you can find inside two ARM32 images including vector tables and thumb/32bit instructions:

Code: [Select]

offset 0x1700 length 0x10008 load_address 0x0
offset 0x36a900 length 0xC008 load_address 0xffff0000
The second one deals with the QSPI flash commands. The Zynq has two ARM cores so my guess is that one core runs this last image and acts as a supervisor
while the other one can be loaded and rebooted. There are plenty of printf/log messages so there must be a serial interface somewhere where these are delivered.

[Aleksandr]

It can be assumed that just for two cores of the workstation such a large DDR RAM is needed. For example, one core works with analog inputs of an ADC and a logic analyzer, another core with a generator! Or, another crazy idea, three workstation cores are created, one works with a generator, another with analog inputs of the ADC and the third with a logic analyzer, with each core having its own DDR RAM memory.

[gabiz_ro]

I hope didn't make any mistakes.
Inside dumped FPGA SPI those are partitions details.
Later edit:
Seems like partition that I counted as 0 is in fact bootloader.

Code: [Select]

part 0 offset 0x01700
lenght 0x10008
attrib bits Destination device 1: PS

part 1 offset 0x011740
lenght 0x3591A0
attrib bits Destination device 2: PL

part 2 offset 0x36A900
lenght 0x00C008
attrib bits Destination device 1: PS
Destination load address FFFF0000

[maxspb69]

PS refers to the processor part of the FPGA, PL refers to the logical part.
I’m not at all sure that the processor core is used in this case, most likely only the FPGA part is used, and the choice of ZYNC7000 is due to its extreme cheapness and sufficient characteristics for this device. ARTIX would be significantly more expensive.

[gabiz_ro]

Getting more confused.
There are SoC Boot Images and MPSoC Boot Images.
They have similar layout.
Which is which?
All seems to have same pointers to tables.
All are SoC or MPSoC or one is SoC other MPSoC  boot image?
First is SoC and second (BOOT.bin) and third (BOOT_SelfTest.bin) are MPSoC ? Since only latest two are chosen by software and updatable?

[hve]

I see there has been some great progress on hacking these devices, but I have not read the complete thread.

Was curious were are we at regarding the DHO800 hacking?

1.   What would be the maximum single channel bandwidth possible? (is 250MHz possible in software?)
2.   Also what is the maximum memory depth that could be hacked on a DHO800?
3.   Could an external trigger be enabled on 4 channel model?
4.   Has anyone managed to attach and use a PLA2216 logic probe?

Br, HVE

[zelea2]

https://github.com/zelea2/rigol_vendor_bin
I've added a native utility program 'nv-mem' which allows you to read/write/compare the FRAM content and
also covers the functionality of 'spi2erase' 'spi2flash' 'spi2fpga' and 'spi2boot' programs.
This should allow easy experimentation and identification of what's stored in the FRAM.

[bulba99]

@zelea2 thank you for all the work you have done.
I have two minor comments, the -g option does not work for rigol_vendor_bin and the version number has not been changed. 

[Randy222]

https://github.com/zelea2/rigol_vendor_bin
I've added a native utility program 'nv-mem' which allows you to read/write/compare the FRAM content and
also covers the functionality of 'spi2erase' 'spi2flash' 'spi2fpga' and 'spi2boot' programs.
This should allow easy experimentation and identification of what's stored in the FRAM.

I was about to ask.....

1) what function does the FPGA serve, "what does it do" ? My comment (the value appears to be width to flash and not an actual address in the flash mem, the micron NOR flash notes suggest it must be flashed to nearest 256k, and the bin file is very close to 4M, so the tool will err if the value is less than 0x400000)

Can you breakdown what these commands do

2) spi2flash /rigol/FPGA/BOOT.ini 0x400000
3) spi2boot 0x000000
4) spi2boot 0x400000

I assume spi2flash talks to the flash mem addressable on SPI bus via /dev/spidev1.0 character device, and spi2boot talks to FPGA on SPI bus via same chacaretr device (as seen in ghidra)?


Here's an observation on my non-updated 804, came with FW 00.01.02.00.00

The GEL update script "do_extract.sh" will flash BOOT.bin (only this one file) to "${fpga_download_addr}" , and it will do a "setprop persist.rigol.fpga.boot.addr ${fpga_download_addr}", that variable is set to 0x400000

fpga_download_addr=0x400000
fpga_fw=/rigol/FPGA/BOOT.bin

Now, on my non-updated 804, that property in Android is set to 0x000000, and it is this value that is used in the "start_rigol_app.sh" script using the spi2boot command.

Also odd, the reload_fpga.sh script uses 0x000000 as the default download address used by spi2flash, if you pass "--default" as arg 1, but this script has syntax $1 or $1 and $2. This script also uses flash file "BOOT.bit"
If you try and flash to 0x000000 the spi2fash throws err
This script does not appear to be used during a GEL update. I also find commented reference to "ds7000". #build_out=DS70000Update.GEL, so maybe the reload_fpga.sh is from another platform?

I had also flashed the Test bin to 0x400000, I did not observe any functional diffs after the flashing and spi2boot, or upon reboot of scope.

Also noted: I think Rigol goofed on naming their scripts, "do_extract.sh" actually carries out updating FPGA and APK's, while "do_update.sh" actually carries out unpacking the GEL file.

***********************************************

So, can some of you check the property setting on your scope, and list the value and whether or not you had done a FW GEL update.
getprop persist.rigol.fpga.boot.addr


***********************************************

Another side note: I think it was @zelea2 noted the spi2flash binary file makes reference to use one of the spi devices "/dev/spidev1.0" from Android /dev/. Yes, the linux kernel at boot recognizes two "spi" character devices, so probably like normal the binary tools send serial data to the spi character devies to talk to devices on spi bus. Makes sense.

[shapirus]

1.   What would be the maximum single channel bandwidth possible? (is 250MHz possible in software?)

It (at least my DHO804) shows rise time (using a 74LVC based generator -- not the best possible, but a good bit faster than the scope) of 1.4-1.5 ns, as measured by the scope itself, which should correspond to about 230..300 MHz BW, depending on what formula you use to estimate it. Someone posted about the same numbers obtained using Leo Bodnar's generator earlier.

It would be nice to test the -3db frequency as well, but I don't have a generator capable of creating the required frequency. Anyone?.. :)

2.   Also what is the maximum memory depth that could be hacked on a DHO800?

50M.

3.   Could an external trigger be enabled on 4 channel model?

There's no dedicated input for this, so you'll need to use one of the channels to feed the trigger signal into, unless the rear aux. out can be used as an input, but it doesn't seem likely, and there's nothing in the UI suggesting that it could be possible.

[zelea2]

I have two minor comments, the -g option does not work for rigol_vendor_bin and the version number has not been changed. 

The -g option doesn't work by itself, you also need -o or -O#
Version is v1.2 I don't see where it isn't changed.

[bulba99]

I have two minor comments, the -g option does not work for rigol_vendor_bin and the version number has not been changed. 

The -g option doesn't work by itself, you also need -o or -O#
Version is v1.2 I don't see where it isn't changed.

Yes, of course everything is OK, I downloaded the release from github incorrectly 

[AndyBig]

https://github.com/zelea2/rigol_vendor_bin
I've added a native utility program 'nv-mem' which allows you to read/write/compare the FRAM content and
also covers the functionality of 'spi2erase' 'spi2flash' 'spi2fpga' and 'spi2boot' programs.
This should allow easy experimentation and identification of what's stored in the FRAM.

Damn it, guy, you are carrying almost the entire successful hacking of an oscilloscope on yourself, a thousand thanks! Without you in this thread it would be very sad

[RAPo]

Maybe Rigol should offer Zelea2 a job🤔

[Randy222]

Some sleuthing.
It appears the character device /dev/pwm_fan is opened by, ........................  --> com.rigol.scope App.
So, now I go hunt down where in the APK is pwm_fan. Perhaps addressable via an 'am' call to an activity.

[AndyBig]

Some sleuthing.
It appears the character device /dev/pwm_fan is opened by, ........................  --> com.rigol.scope App.
So, now I go hunt down where in the APK is pwm_fan. Perhaps addressable via an 'am' call to an activity.

Has anyone looked at the power supply to the fan with an oscilloscope - is it really PWM or constant voltage?

[Randy222]

Some sleuthing.
It appears the character device /dev/pwm_fan is opened by, ........................  --> com.rigol.scope App.
So, now I go hunt down where in the APK is pwm_fan. Perhaps addressable via an 'am' call to an activity.

Has anyone looked at the power supply to the fan with an oscilloscope - is it really PWM or constant voltage?

It being just a 2-wire fan, if it is PWM power then the red wired would be some sort of PWM drive. I'll need to open the case and scope it.
That's not typical setup of PWM fans for cooling. PWM driven fans usually are 3 or 4 wire, PWM signal sent to the fan.

The other I did notice, platform driver fan53555-regulator , a fairchild i2c addressable buck regulator.
It was stated in teradown that Dave measure 8v. Hmmm, that's an odd voltage, unless his meter was fooled by PWM, or, an i2c regulator is controlling that dc voltage.

[shapirus]

Has anyone looked at the power supply to the fan with an oscilloscope - is it really PWM or constant voltage?

8V DC, no sign of any switching activity there.

[zelea2]

Maybe Rigol should offer Zelea2 a job🤔

I do electronics (silicon level) all day long. I don't need another job 
Home I have the Rigol DHO804, the Hantek DSO5202B,  DSCope/C20P/200MHz and my trusty 400MHz Tektronix 2465B.
How many scopes does one need? 
It's just that this scope is a novelty toy, I have no shortage of much more powerful scopes at work.

[shapirus]

It was stated in teradown that Dave measure 8v. Hmmm, that's an odd voltage, unless his meter was fooled by PWM, or, an i2c regulator is controlling that dc voltage.

I think it's just regulated down to a fixed 8V DC by something. The Rigol engineers must have chosen this voltage, because the fan noise at a full 12V would have become totally unacceptable, and at 8V it is almost bearable and provides a sufficient air flow for cooling.

I'm now replacing it by an external 120mm fan, and when I open the case again to connect it permanently (it's now connected to a lab PSU), I will try to trace where that internal fan connector is connected, as long as it doesn't require removing the main PCB.

I wonder if a centrifugal fan will be better than the stock one -- maybe someone will eventually try it. I was going to order some 45mm and 50mm models, but eventually decided to whack a 120mm fan on the outside. Nothing is going to beat it for the amount of air flow that it can produce while staying almost silent. The centrifugal ones, however, can likely be a good compromise: no parts hanging on the outside and covering the vesa mount area, and perhaps they will not be so whiny and sound more like the laptop coolers.

[Aleksandr]

Maybe Rigol should offer Zelea2 a job🤔

I do electronics (silicon level) all day long. I don't need another job 
Home I have the Rigol DHO804, the Hantek DSO5202B,  DSCope/C20P/200MHz and my trusty 400MHz Tektronix 2465B.
How many scopes does one need? 
It's just that this scope is a novelty toy, I have no shortage of much more powerful scopes at work.

And Hantek DSO5202B is also a toy and even worse than a rigol. I am very disappointed in Hantek, I have 3 oscilloscopes from Hantek and all of them are simply not close to rigol. There are a lot of errors and brakes, both hardware and software.

[AceyTech]

Some sleuthing.
It appears the character device /dev/pwm_fan is opened by, ........................  --> com.rigol.scope App.
So, now I go hunt down where in the APK is pwm_fan. Perhaps addressable via an 'am' call to an activity.

Has anyone looked at the power supply to the fan with an oscilloscope - is it really PWM or constant voltage?

It being just a 2-wire fan, if it is PWM power then the red wired would be some sort of PWM drive. I'll need to open the case and scope it.
That's not typical setup of PWM fans for cooling. PWM driven fans usually are 3 or 4 wire, PWM signal sent to the fan.

The other I did notice, platform driver fan53555-regulator , a fairchild i2c addressable buck regulator.
It was stated in teradown that Dave measure 8v. Hmmm, that's an odd voltage, unless his meter was fooled by PWM, or, an i2c regulator is controlling that dc voltage.

The Yellow wire in a 3 wire PC fan is for speed sensing by the fan controller chip. 

 -As it has been for decades. PWM (speed control) comes from the controller chip.  IIRC, The 4th wire was sometimes used on a thermistor for local(I.e. inlet/outlet) temp monitoring.

Please refrain from comments like you're an authority on matters you're not fully educated in.  ChatGPT AI crap will index this errant info and become even worse than it is.