Hacking the Rigol DHO800/900 Scope

[gabiz_ro]

Looking at some schematics with DDR3 and tracing connections looks like only pins E7 D3 F3 G3 C7 B7 are individual connected to CPU, in our case FPGA.
So if measuring on unpopulated place on this pins and find that is not connected then may be dummy chips.
If there are some readings then PCB have traces from unpopulated place to FPGA but that not means that if soldered will be used.
I think we need to compare content of SPI flash chip between models.

https://www.eevblog.com/forum/blog/eevblog-1563-new-$389-12bit-rigol-dho800-scope-teardown/msg5046301/#msg5046301
Looking at boot log of FPGA and at BOOT.bin from latest firmware and seems to be match on partition addresses and checksums.
Don't know what version was on Dave scope at that date and I search for older firmware and I found one in which BOOT.bin(from DHO800_DHO900(Software)UpdateV00.01.00) is different but partition addresses and checksums are identical.
So either checksums are dummy or are for something else.

Code: [Select]

value offset
Partition Number: 1
Image Word Len: 0x000D6468 0x00000CC0 ?
Data Word Len: 0x000D6468 0x00000CC4 ?
Partition Word Len: 0x000D6468 0x00000CC8 ?
Load Addr: 0x00000000 0x00000CCC ?
Exec Addr: 0x00000000 0x00000CD0 ?
Partition Start: 0x000045D0 0x00000CD4
Partition Attr: 0x00000020 0x00000CD8
Section Count: 0x00000001 0x00000CDC ?
Partition Checksum Offset: 0x00000000 ` 0x00000CE0 ?
Unknown 0x00000250 0x00000CE4
Unknown 0x00000000 0x00000CE8
Unknown 0x00000000 0x00000CEC
Unknown 0x00000000 0x00000CF0
Unknown 0x00000000 0x00000CF4
Unknown 0x00000000 0x00000CF8
Checksum: 0xFFD78A86 ` 0x00000CFC

Partition Number: 2
Image Word Len: 0x00003002 0x00000D00 ?
Data Word Len: 0x00003002 0x00000D04 ?
Partition Word Len: 0x00003002 0x00000D08 ?
Load Addr: 0xFFFF0000 0x00000D0C ?
Exec Addr: 0xFFFF0000 0x00000D10 ?
Partition Start: 0x000DAA40 0x00000D14
Partition Attr: 0x00000010 0x00000D18
Section Count: 0x00000001 0x00000D1C
Partition Checksum Offset:  0x00000000 ` 0x00000D20 ?
Unknown 0x00000260 0x00000D24
Unknown 0x00000000 0x00000D28
Unknown 0x00000000 0x00000D2C
Unknown 0x00000000 0x00000D30
Unknown 0x00000000 0x00000D34
Unknown 0x00000000 0x00000D38
Checksum: 0xFFF3C348 0x00000D3C

Partition Number: 0
Image Word Len: 0x00004002 0x00000C80 ?
Data Word Len: 0x00004002 0x00000C84 ?
Partition Word Len: 0x00004002 0x00000C88 ?
Load Addr: 0x00000000 0x00000C8C ?
Exec Addr: 0x00000000 0x00000C90 ?
Partition Start: 0x000005C0 0x00000C94
Partition Attr: 0x00000010 0x00000C98
Section Count: 0x00000001 0x00000C9C ?
Partition Checksum Offset: 0x00000000 ` 0x00000CA0 ?
Unknown 0x00000240 0x00000CA4
Unknown 0x00000000 0x00000CA8
Unknown 0x00000000 0x00000CAC
Unknown 0x00000000 0x00000CB0
Unknown 0x00000000 0x00000CB4
Unknown 0x00000000 0x00000CB8
Checksum: 0xFFFF37E8 0x00000CBC

[Aleksandr]

Looking at some schematics with DDR3 and tracing connections looks like only pins E7 D3 F3 G3 C7 B7 are individual connected to CPU, in our case FPGA.
So if measuring on unpopulated place on this pins and find that is not connected then may be dummy chips.
If there are some readings then PCB have traces from unpopulated place to FPGA but that not means that if soldered will be used.
I think we need to compare content of SPI flash chip between models.

https://www.eevblog.com/forum/blog/eevblog-1563-new-$389-12bit-rigol-dho800-scope-teardown/msg5046301/#msg5046301
Looking at boot log of FPGA and at BOOT.bin from latest firmware and seems to be match on partition addresses and checksums.
Don't know what version was on Dave scope at that date and I search for older firmware and I found one in which BOOT.bin(from DHO800_DHO900(Software)UpdateV00.01.00) is different but partition addresses and checksums are identical.
So either checksums are dummy or are for something else.

Code: [Select]

value offset
Partition Number: 1
Image Word Len: 0x000D6468 0x00000CC0 ?
Data Word Len: 0x000D6468 0x00000CC4 ?
Partition Word Len: 0x000D6468 0x00000CC8 ?
Load Addr: 0x00000000 0x00000CCC ?
Exec Addr: 0x00000000 0x00000CD0 ?
Partition Start: 0x000045D0 0x00000CD4
Partition Attr: 0x00000020 0x00000CD8
Section Count: 0x00000001 0x00000CDC ?
Partition Checksum Offset: 0x00000000 ` 0x00000CE0 ?
Unknown 0x00000250 0x00000CE4
Unknown 0x00000000 0x00000CE8
Unknown 0x00000000 0x00000CEC
Unknown 0x00000000 0x00000CF0
Unknown 0x00000000 0x00000CF4
Unknown 0x00000000 0x00000CF8
Checksum: 0xFFD78A86 ` 0x00000CFC

Partition Number: 2
Image Word Len: 0x00003002 0x00000D00 ?
Data Word Len: 0x00003002 0x00000D04 ?
Partition Word Len: 0x00003002 0x00000D08 ?
Load Addr: 0xFFFF0000 0x00000D0C ?
Exec Addr: 0xFFFF0000 0x00000D10 ?
Partition Start: 0x000DAA40 0x00000D14
Partition Attr: 0x00000010 0x00000D18
Section Count: 0x00000001 0x00000D1C
Partition Checksum Offset:  0x00000000 ` 0x00000D20 ?
Unknown 0x00000260 0x00000D24
Unknown 0x00000000 0x00000D28
Unknown 0x00000000 0x00000D2C
Unknown 0x00000000 0x00000D30
Unknown 0x00000000 0x00000D34
Unknown 0x00000000 0x00000D38
Checksum: 0xFFF3C348 0x00000D3C

Partition Number: 0
Image Word Len: 0x00004002 0x00000C80 ?
Data Word Len: 0x00004002 0x00000C84 ?
Partition Word Len: 0x00004002 0x00000C88 ?
Load Addr: 0x00000000 0x00000C8C ?
Exec Addr: 0x00000000 0x00000C90 ?
Partition Start: 0x000005C0 0x00000C94
Partition Attr: 0x00000010 0x00000C98
Section Count: 0x00000001 0x00000C9C ?
Partition Checksum Offset: 0x00000000 ` 0x00000CA0 ?
Unknown 0x00000240 0x00000CA4
Unknown 0x00000000 0x00000CA8
Unknown 0x00000000 0x00000CAC
Unknown 0x00000000 0x00000CB0
Unknown 0x00000000 0x00000CB4
Unknown 0x00000000 0x00000CB8
Checksum: 0xFFFF37E8 0x00000CBC

But no one has the contents of the SPI flash chip :-

[gabiz_ro]

Just did some checks.
Hard to measure under bga chips.
Just poke on external balls for better result need to desolder actual chip.
First I look at pins E7 D3 F3 G3 C7 B7 of not mounted chips, good news is there are some readings in diode mode on multimeter so this pins are connected somewhere.
Pins T3 T7 T8 (address line A13 A14 A8 ) seems to be connected via some resistors (that line of resistors under GDP2BFLM-CA) to their corespondent on GDP2BFLM-CA mounted chip
But T2 (reset) seems to be connected somewhere else or is connected via a higher value resistor.
On address lines value of resistor was around 43 ohms
Also pins A2 A3 A7 (data lines of not mounted chips) doesn't seems to be connected to their corespondent on mounted chip or are connected via a higher value resistor.

In simple words.
PCB seems to have tracks for missing DDR3 chips.
Address lines seems to be common for all three chips.
Data lines seems at first that are not common for DDR3 chips but are connected somewhere.
Reset also seems like is not shared for all chips.

So I'll order 3 MT41K256M16TW-093 and  replace GDP2BFLM-CA and if all OK populate also missing chips.
It will take a while until that.

Also take a dump of that 25Q128.
Need to do some comparation.
I don't know on what version is my scope since in about is only 00.01.01

Now let's hope that someone will upload one from other models with more RAM

[Aleksandr]

Just did some checks.
Hard to measure under bga chips.
Just poke on external balls for better result need to desolder actual chip.
First I look at pins E7 D3 F3 G3 C7 B7 of not mounted chips, good news is there are some readings in diode mode on multimeter so this pins are connected somewhere.
Pins T3 T7 T8 (address line A13 A14 A8 ) seems to be connected via some resistors (that line of resistors under GDP2BFLM-CA) to their corespondent on GDP2BFLM-CA mounted chip
But T2 (reset) seems to be connected somewhere else or is connected via a higher value resistor.
On address lines value of resistor was around 43 ohms
Also pins A2 A3 A7 (data lines of not mounted chips) doesn't seems to be connected to their corespondent on mounted chip or are connected via a higher value resistor.

In simple words.
PCB seems to have tracks for missing DDR3 chips.
Address lines seems to be common for all three chips.
Data lines seems at first that are not common for DDR3 chips but are connected somewhere.
Reset also seems like is not shared for all chips.

So I'll order 3 MT41K256M16TW-093 and  replace GDP2BFLM-CA and if all OK populate also missing chips.
It will take a while until that.

Also take a dump of that 25Q128.
Need to do some comparation.
I don't know on what version is my scope since in about is only 00.01.01

Now let's hope that someone will upload one from other models with more RAM

 

[gabiz_ro]

Comparing dump FPGA_SPI_DHO804.bin with files result

0x00000000 - 0x00376907 something size 0x376908
0x00376908 - 0x003FFFFF blank , FF's only
0x00400000 - 0x00776907 is BOOT.bin from FPGA folder size 0x376908
0x00776908 - 0x007FFFFF blank , FF's only
0x00800000 - 0x00B76907 is BOOT_SelfTest.bin from FPGA folder size 0x376908
0x00B76908 -  0x00FFFFFF blank ,  FF's only

So only area 0x00000000 - 0x00376907 contain something can't identify.
Looks similar to other files, maybe old version of BOOT.bin or maybe something used for FPGA initialization, who knows?
This may be those three partitions from log messages, partition 1 is BOOT.bin, partition 2 is BOOT_SelfTest.bin and maybe partition 0 is that unknown from 0x0 - 0x376908

[ebastler]

So only area 0x00000000 - 0x00376907 contain something can't identify.
Looks similar to other files, maybe old version of BOOT.bin or maybe something used for FPGA initialization, who knows?

Might be the "factory default" FPGA configuration, which always stays in there as a fallback?

[Aleksandr]

I already asked in another post what the hidden DDR functions are in the oscilloscope menu. If I may repeat again, what are these hidden settings, especially for DDR?

[gabiz_ro]

It may be
from reload_fpga.sh
is declared as option for --default command option
default_fw_path=/rigol/FPGA/BOOT.bit
default_download_addr=0x000000

But there is no BOOT.bit only bin
bit file is SPU_H12S1.bit I don;t know what is used for.

Also looking at that script I see that after doing and inserting xdma.ko module check for a file and  based on that set FPGA boot address

[empeka]

Now let's hope that someone will upload one from other models with more RAM

DHO914 (with 924 vendor.bin)

[Randy222]

It may be
from reload_fpga.sh
is declared as option for --default command option
default_fw_path=/rigol/FPGA/BOOT.bit
default_download_addr=0x000000

But there is no BOOT.bit only bin
bit file is SPU_H12S1.bit I don;t know what is used for.

Also looking at that script I see that after doing and inserting xdma.ko module check for a file and  based on that set FPGA boot address

That script is jacked in some ways. It appears Rigol took some other script and just jacked it up to "work" with the GEL update script.
the syntax has $1 and $2 as args

Syntax is $1 only , it must be "--default", or you must pass actual $1 and $2

$1 = --default will run the update on the default addr using "BOOT.bit". I simply cp-paste BOOT.bin to BOOT.bit and it works fine.
$1 and $2 args (file and address) and the script uses those for spi2erase and spi2flash and spi2boot, using the $2 address for boot and in setprop

However, if I run script from FPGA dir, passing "BOOT.bin 0x400000" as args, getprop for boot addr still shows 0x00000

spi2flash wont accept "0x000000" as addr, err's with "must be at least 0x400000 (4MB)". So it's not clear to me how default in script is "0x000000".

spi2flash addr arg must be how big space to flash into, does not appear where to park the start of the flash image. Which is interesting because of the FPGA boot addr found in the startup script in /rigol/shell/

If I try and flash BOOT.bin into addr arg 0x800000, the running system will panic and reboot. Probably have stepped on xdma0 in doing that flash, which I assume the tool padded out to 8MB.

So, some more digging in this area is needed.

[gabiz_ro]

Thanks! @empeka
Is your DHO914 with 3 DDR3 RAM chips?

Compared and
0x00400000 - 0x00776907 is BOOT.bin from FPGA folder size 0x376908
0x00776908 - 0x007FFFFF blank , FF's only
0x00800000 - 0x00B76907 is BOOT_SelfTest.bin from FPGA folder size 0x376908
0x00B76908 -  0x00FFFFFF blank ,  FF's only

are identical with my DHO804

But area 0x00000000 - 0x00376907 many differences.

[Randy222]

The decompiles SMALI files are in the zips I posted back a few pages. APKTOOL decompiles of all 3 or the Rigol APK's (web scope launcher). Edit the SMALI files all day if you like.

Here's what the .com.rigol.scope MainActivity looks like. attached as .smail.txt

Yes, thank you, I saw your message with a link to a decompiled application, but to be honest, I’m not yet sure that I’m ready to dive even into Java, not to mention SMALI The last time I dealt with Java was about 12 years ago )

However, I am not sure you need to edit SMALI files. The process is to code in Java, compile it, convert to dex using Android dx tool, dex --> smali using baksmali tool

Read these links
https://stackoverflow.com/questions/29051781/convert-java-file-to-smali-file#29052019
https://payatu.com/blog/an-introduction-to-smali/

I have seen many reports that the Java code obtained during the decompilation process has inaccuracies and obvious errors. For example, a function may contain a return statement first and then the function code itself. I'm afraid that it will be almost impossible to find and fix all such jambs. At the same time, SMALI has code that matches the application exactly. In addition, I have come across mentions that when compiling from Java, some kind of fiddling is necessary with the external dependencies to be plugged in, or rather with their versions. But here I'm not sure, because... I haven't studied this issue in depth. In fact, the first reason is already quite enough to be very skeptical about assembling from decompiled Java sources

I think I have a method to edit some in basic APK (java) stuff. Not anything in the .so C files (not yet).
So, maybe I try to change CH1 to be "not yellow" ?

If we can achieve that then we know we can edit and run mods.

[Aleksandr]

Thanks! @empeka
Is your DHO914 with 3 DDR3 RAM chips?

Compared and
0x00400000 - 0x00776907 is BOOT.bin from FPGA folder size 0x376908
0x00776908 - 0x007FFFFF blank , FF's only
0x00800000 - 0x00B76907 is BOOT_SelfTest.bin from FPGA folder size 0x376908
0x00B76908 -  0x00FFFFFF blank ,  FF's only

are identical with my DHO804

But area 0x00000000 - 0x00376907 many differences.

It is the upper part of the address space that is responsible for initializing FPGA modules!

[Randy222]

Thanks! @empeka
Is your DHO914 with 3 DDR3 RAM chips?

Compared and
0x00400000 - 0x00776907 is BOOT.bin from FPGA folder size 0x376908
0x00776908 - 0x007FFFFF blank , FF's only
0x00800000 - 0x00B76907 is BOOT_SelfTest.bin from FPGA folder size 0x376908
0x00B76908 -  0x00FFFFFF blank ,  FF's only

are identical with my DHO804

But area 0x00000000 - 0x00376907 many differences.

Perhaps this space is the FPGA bootloader code? Like an MBR record for the FPGA?
The start script uses 0x000000 as FPGA boot address when calling spi2boot

Also noted, the update GEL scripts do not flash in the BOOT_SelfTest.bin file. Someone please dbl-check.

[Randy222]

I already asked in another post what the hidden DDR functions are in the oscilloscope menu. If I may repeat again, what are these hidden settings, especially for DDR?

Is this from a native 924?
What hardware type # is the device?

My 804 runs as a 914, but I don't see such items in any menu. FW 00.01.02.00.00

[ebastler]

It is the upper part of the address space that is responsible for initializing FPGA modules!

What makes you think so?
Not true for the Xilinx FPGAs I have used.

[Randy222]

Looking at some schematics with DDR3 and tracing connections looks like only pins E7 D3 F3 G3 C7 B7 are individual connected to CPU, in our case FPGA.
So if measuring on unpopulated place on this pins and find that is not connected then may be dummy chips.
If there are some readings then PCB have traces from unpopulated place to FPGA but that not means that if soldered will be used.
I think we need to compare content of SPI flash chip between models.

How can you ID all the traces on PCB, wont some be in multi-layer pcb?

[Aleksandr]

I already asked in another post what the hidden DDR functions are in the oscilloscope menu. If I may repeat again, what are these hidden settings, especially for DDR?

Is this from a native 924?
What hardware type # is the device?

My 804 runs as a 914, but I don't see such items in any menu. FW 00.01.02.00.00

I have an 804. If you press "About" three times you will enter debug mode.

[Randy222]

It is the upper part of the address space that is responsible for initializing FPGA modules!

What makes you think so?
Not true for the Xilinx FPGAs I have used.

The GEL file update scripts setprop to 0x000000

The rigol start script checks the value and uses it.

Code: [Select]

fpga_boot_addr=$(getprop persist.rigol.fpga.boot.addr)
if [[ x"${fpga_boot_addr}" == x"" ]]; then
    fpga_boot_addr=0x000000
   
/rigol/tools/spi2boot ${fpga_boot_addr}

[gabiz_ro]

@Aleksandr
I think is only for some testing
Translated is
starting address      length
document name
document path
save                         load

I think load some file into memory then save it then you need to compare and if identical then OK if not identical then problems.

@Randy222
I take a look on schematics not on PCB and identified that pins are alone connected to another chip, and not sharing any connection like in case of data and address and clock lines that are common between chips.
As for what I measure on PCB was only on edge of chip inserting thin wire attached to multimeter probe under chip and on pads where was missing chips.

[empeka]

Is your DHO914 with 3 DDR3 RAM chips?

yes, 3* K4B4G1646E-BYMA

[AndyBig]

I think I have a method to edit some in basic APK (java) stuff. Not anything in the .so C files (not yet).
So, maybe I try to change CH1 to be "not yellow" ?

If we can achieve that then we know we can edit and run mods.

Yes, such a check will be quite sufficient I don’t have enough free time to do this yet. It would be great if you check it out

[Aleksandr]

Is your DHO914 with 3 DDR3 RAM chips?

yes, 3* K4B4G1646E-BYMA

Ooooh! This is great! A different memory and more common!!!!

[Randy222]

I have an 804. If you press "About" three times you will enter debug mode.

"TestModel" is the mode. I don't see anything that says "debug".

[Fungus]

I think they're fake/defective chips put there to make people think they can't convert their DHO800 into a DHO900 for the price of a connector.

It's as plausible as any other theory I've seen.