Hacking the Rigol DHO800/900 Scope

[S2084]

Did gabiz_ro's question regarding the choice of memory chips ever get answered? From what I see in teardown photos and datasheets, he seems right about a potential mismatch:

In order not to look for answers, you can install those chips yourself that you consider necessary

Look, there are a few simple potential answers to my question which I can think of:

• "You are mistaken; the DRAM I used is the correct type because ..."
• "I know it's not the exact type; I chose this one as a workaround because..."
• "Oh shit."

But I can't think of an explanation why you would first come back with a snide comment, then ignore my polite request to clarify. What's wrong?

I have not found exactly the same memory chips on sale.  But somewhere on the network I saw a debug board with FPGA ZYNQ, on which exactly the same memory chips were installed that I installed in my Rigol.  From this I concluded that they must be compatible..... That's all..... Was there such a great need for this explanation of mine???

[ebastler]

Well, there was (and still is?) the question: "In your tests, did the scope simply not use the memory since it is the wrong type and therefore failed some self test?" 

So I was curious whether you already have a conclusive answer to that, i.e. an argument why this RAM type can (or even must) be used for testing. That's why I asked.

[S2084]

I repeat, there are no changes in the operation of the oscilloscope!  I didn’t do anything with it..... Secondly, I never said that the DDR chips I installed are the only true alternative to those installed in the 900 series.  I don't understand where you got this from?

[Veteran68]

Was there such a great need for this explanation of mine???

This is a discussion forum. The whole point of a discussion forum is to discuss. That's what we do. We're engineers, technicians, scientists. Someone posts something. Others ask questions, poke holes, challenge, correct misinformation, etc. If you don't want people to question you, then maybe reconsider engaging in the first place. It makes you look pretty arrogant to think you can post and nobody should be expected to question you about it.

[Randy222]

I loaded the pwm_fan.ko driver into 804 , driver from the 1000/4000 GEL FW bundle.
Loads ok, no errors. lsmod show 4 instances, but I can't find where to set PWM freq or %.
Perhaps all moot if the fan wires simpley attach to Vcc-Gnd, but I simply don't know where thise wires go.
The driver appears to be written by someone at Samsung.

Any thoughts?

[AndyBig]

Some say that 25Q128 is used to store some initialization for FPGA and firmware is loaded by startup script, a little strange to use 16MB chip only for that, if my memory serve well that firmware or boot from FPGA folder is around 4MB
 

The oscilloscope firmware contains two binaries for FPGAs - BOOT.bin and BOOT_SelfTest.bin. And most likely both of these files are loaded into 25Q128, that is, at least 8 MB is already needed. Perhaps some other data is loaded there, but even if not, it seems reasonable to me to install flash memory with a reserve, and not exactly according to the size currently required

[shapirus]

I loaded the pwm_fan.ko driver into 804 , driver from the 1000/4000 GEL FW bundle.
Loads ok, no errors. lsmod show 4 instances, but I can't find where to set PWM freq or %.

Check if there's anything under /sys/class/hwmon after the module is loaded. If there is a supported fan controlling chip, there will be symlinks to respective directories which may contain files with "fan" and "pwm" in their names.

Also, why don't you post that .ko here so that others might take a look too? :)

Perhaps all moot if the fan wires simpley attach to Vcc-Gnd, but I simply don't know where thise wires go.

IIRC Dave measured voltage at the fan connector to be 8V, so it's at least not the main 12V rail, meaning there's a chance.

[S2084]

Fine! Job is done! And there is a result! Since the absence of a result is also a result! Then let competent people tell you whether such RAM is suitable? mt41k256m16tw-093

I don't think anyone can answer you competently.  The best option for you would be to try this on your own... In the worst case, nothing will change in the operation of the oscilloscope.  On my own behalf, I can advise you not to be lazy and change the balls on the chips to lead-containing ones with a lower melting point.... All soldering on the board is done using lead-containing solder.  This action will save you a lot of nerves...

[AndyBig]

I have not found exactly the same memory chips on sale.  But somewhere on the network I saw a debug board with FPGA ZYNQ, on which exactly the same memory chips were installed that I installed in my Rigol.  From this I concluded that they must be compatible..... That's all..... Was there such a great need for this explanation of mine???

The fact that somewhere Zynq with its configuration and its firmware worked with these memory chips does not mean at all that it will work with the same memory in Rigol, in which a completely different firmware and configuration is loaded into the FPGA. There is a high probability that this will not work.

[S2084]

Do you really think that I don’t understand this?  Of course, this probability is quite high... But how can you estimate the probability that the guys from Rigol prescribed a strictly defined model of RAM chips in the FPGA?

[AndyBig]

Do you really think that I don’t understand this?  Of course, this probability is quite high... But how can you estimate the probability that the guys from Rigol prescribed a strictly defined model of RAM chips in the FPGA?

I think this probability is close to 100%. It makes no sense for them to prescribe settings for dozens of memory chip models.

[Randy222]

I loaded the pwm_fan.ko driver into 804 , driver from the 1000/4000 GEL FW bundle.
Loads ok, no errors. lsmod show 4 instances, but I can't find where to set PWM freq or %.

Check if there's anything under /sys/class/hwmon after the module is loaded. If there is a supported fan controlling chip, there will be symlinks to respective directories which may contain files with "fan" and "pwm" in their names.

Also, why don't you post that .ko here so that others might take a look too?

Perhaps all moot if the fan wires simpley attach to Vcc-Gnd, but I simply don't know where thise wires go.

IIRC Dave measured voltage at the fan connector to be 8V, so it's at least not the main 12V rail, meaning there's a chance.

ko attached as txt file
my local MD5
58070b2e6c5ced96ef685e17fb019192  1000-4000v00.02.11.pwm_fan.ko.txt

the devicetree has files and such, but I cannot ID an actual device or find anything that resembles settings.

[Randy222]

Some say that 25Q128 is used to store some initialization for FPGA and firmware is loaded by startup script, a little strange to use 16MB chip only for that, if my memory serve well that firmware or boot from FPGA folder is around 4MB
 

The oscilloscope firmware contains two binaries for FPGAs - BOOT.bin and BOOT_SelfTest.bin. And most likely both of these files are loaded into 25Q128, that is, at least 8 MB is already needed. Perhaps some other data is loaded there, but even if not, it seems reasonable to me to install flash memory with a reserve, and not exactly according to the size currently required

The BOOT_SelfTest.bin is not installed (flashed) with a GEL update.

Only BOOT.bin gets an spi2flash to FPGA address 0x400000
They actually do a "spi2erase" at 0x400000 before flashing the bin from GEL

I suspect if you need SelfTest it needs to be flashed to 0x400000, but done manually.

I'll try it and see what happens.

[Mechatrommer]

@S2084
From what I found after a quick search
DHO924 use GDP2BFLM-CA  DDR3(L)  4Gb
but you use
H5TQ2G63FFR-PBC DDR3 2Gb

last time i did the homework, i put IS43TR16256BL-125KBLI in my aliexpress cart just in case one day i decide to choose that route (if later after LA probe experiment or others DHO900S owners prove it to be beneficial to install) its 4Gb ram from the datasheet but i'm not expert in DDR3 tech, there are 16bits and 8bits lanes and plethora of DDR3 speed and signal integrity specs that easily confuses me. advices are welcomed...
https://www.aliexpress.com/item/1005006042462729.html
https://my.mouser.com/datasheet/2/198/43_46TR16256A_85120AL-268426.pdf

Are you familiar with the concept of "surface tension of a liquid"

during reflow, if we wiggle the ic a little bit, it should get back to its least surface tension position,usually if all pins are reflowed/melted properly. at least this is a poor mens indication a proper reflow process is made. i've seen other videos using 45degree angled mirror and camera to see the side of the ic for proper reflow. btw no need to get offended by others, think positively they merely provide suggestions and thoughts for the proper process. we appreciate what you did... doing it and reporting findings (regardless of success or failure) is alot better than speculative talk imho, ymmv.

[Fungus]

3) maybe for possible future feature releases?

Nah.

I wonder if anything changes if you change vendor.bin so the 800 thinks it's a 914 or 924?

It works perfectly.

[Randy222]

3) maybe for possible future feature releases?

Nah.

I wonder if anything changes if you change vendor.bin so the 800 thinks it's a 914 or 924?

That's not what I mean.

There are some properties of the hardware that persist. Look at "getprop" settings. Device serial # there does not match my vendor.bin serial.
Next you have hardware type ID. 800's are different than 900's.
So maybe due to some other properties the code does not go after the additional memory that was added?

Throwing ideas out there.

It works perfectly.

[Aleksandr]

The question is completely different. How do you even understand that the DHO900 is using this additional memory? Maybe it's just there for beauty and not used during work!!! That's the point! This memory may not be needed at all!!! How to understand that it is used in DHO900?

[Randy222]

I noticed something odd on my 804 that has 00.01.02.00.00

The GEL update script stuff appears to use 0x400000 as the base address to erase and flash the BOOT.bin using spi2flash
In those same update scripts it does a setprop for the persist fpga boot address 0x400000 used by the start script which loads fpga using spi2boot.
But I noticed my getprop setting is 0x00000

I flashed the test bin in using teh reload_fpga script, it does the erase and flash commands, then reloads pcie and xdma ko drivers, and reloads the scope app.
Upon one of my tests I thought I saw a two option tounch menu behind the rigol logo during boot, but scope app loads over it. I think I need to am kill scope and launcher to get back to base android screen, or at least minimize those apps.

If I use spi2flash directly and provide anything less than 0x400000, i get err saying the bin needs min 0x400000 (4MB). The spi2flash address argument does not appear to be a start address, seems to be just how big the flash dest needs to be, so then what does the getprop "boot address" mean?

[Randy222]

The question is completely different. How do you even understand that the DHO900 is using this additional memory? Maybe it's just there for beauty and not used during work!!! That's the point! This memory may not be needed at all!!! How to understand that it is used in DHO900?

Why would Rigol buy and place SMA mem chips onto the board if they are not used at all? Maybe the mem devices in 900 are just dummy chips?
We must use some logic, and the not used at all logic does not make sense to me.

[Mechatrommer]

Maybe it's just there for beauty and not used during work!!! That's the point!

by any stretch, i cannot imagine why some designer will put 2 of them on pcb and connect traces and resistors to fpga just for fun.. the fact is, its still unknown why they are there, so imho its pointless to expand such speculative discussion unless you have something physically or programmatically proven.

[ebastler]

Why would Rigol buy and place SMA mem chips onto the board if they are not used at all? Maybe the mem devices in 900 are just dummy chips?

by any stretch, i cannot imagine why some designer will put 2 of them on pcb and connect traces and resistors to fpga just for fun..

I had offered one possible explanation. Any thoughts on that?

I think it is entirely possible that the RAM is unused (at this time). I have speculated earlier that Rigol had originally designed it in to store the digital data, providing extra capacity and extra bandwidth for these. But ran into problems, maybe routing congestions in the FPGA, and decided to share the main RAM between analog and digital data, as a fallback solution. Which would explain the somewhat embarrassing reduction of the analog sampling rate when the digital channels are used.   

Edit: Maybe Rigol are still hoping to eventually enable the extra RAM, by fixing/improving the FPGA configuration for the DHO900. They have not updated the datasheet to make the reduced analog sampling rate in LA mode official and final.

[Aleksandr]

Here's a link I found to view replacement RAM on the manufacturer's website https://www.gigadevice.com.cn/technical-resource/dram-cross-reference?wd=mt41k256m16tw-093

[shapirus]

ko attached as txt file
my local MD5
58070b2e6c5ced96ef685e17fb019192  1000-4000v00.02.11.pwm_fan.ko.txt

So it does create an entry under /sys/class/hwmon, and there is indeed a "pwm1" control file, but whatever value you write to it, it has no effect, even if you write "0", which would normally stop the fan.

This driver may be for a different chip, or there may be no chip at all, or the module may need some options to recognize what the DHO800/900 have.

I wonder if there's a way to run lm-sensors on android... It has a sensors-detect tool that scans hardware for the presence of any of the supported chips. Need to search on this.

[ebastler]

So it does create an entry under /sys/class/hwmon, and there is indeed a "pwm1" control file, but whatever value you write to it, it has no effect, even if you write "0", which would normally stop the fan.

This driver may be for a different chip, or there may be no chip at all, or the module may need some options to recognize what the DHO800/900 have.

The larger models, DHO1000 and 4000, do provide PWM control for the fan on the hardware and driver level. The current firmware always sets it to 100%, but a slower fan speed can be set via the startup batch files. Maybe the driver installed on the DHO800 is a leftover from porting the firmware, but is not actually supported in hardware?

[Mechatrommer]

I think it is entirely possible that the RAM is unused (at this time). I have speculated earlier that Rigol had originally designed it in to store the digital data, providing extra capacity and extra bandwidth for these. But ran into problems, maybe routing congestions in the FPGA, and decided to share the main RAM between analog and digital data, as a fallback solution. Which would explain the somewhat embarrassing reduction of the analog sampling rate when the digital channels are used.   

if this speculation/possibility is true:
1) then they dont have to populate the extra RAM on new currently produced DHO900 series.
2) or... the extra ram got some possible use anyway, if not now, then in the future. just wait for FW update.
either way, they were not put there just for fun (or mere decoration) in the first place.