Hacking the Rigol DHO800/900 Scope

[AceyTech]

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?

FYI: there's several extra menu pages/items(plus extra calibration items) that show up once you enable debug mode i.e., "testmodel on". 












My theory: these menus are for during Design Verification Testing. --like for manually setting/fixing ADC errors, scale, & offsets etc.,

Also, a guess to your Q: After translation, it looks like the DDR menu might be used to Save/Load the DDR3 contents to a file, again as a debug tool. 
Maybe the discussion topic today about "populated vs. unpopulated DDR3" could benefit from using this...?tool?

EDIT: Sorry, I took too long to reply, others have chimed in.  Decided to post since some may benefit from seeing the menus.

[Aleksandr]

Is your DHO914 with 3 DDR3 RAM chips?

yes, 3* K4B4G1646E-BYMA

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

AliExpress! DDR3 K4B4G1646E-BYMA 4 Gb
https://sl.aliexpress.ru/p?key=u9Q7Ogb

[AceyTech]

Is your DHO914 with 3 DDR3 RAM chips?

yes, 3* K4B4G1646E-BYMA

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

AliExpress! DDR3 K4B4G1646E-BYMA 4 Gb
https://sl.aliexpress.ru/p?key=u9Q7Ogb

Interesting: In comparison of the datasheets, those Samsung parts are:
512 Mb x8 @ 1866 Mbps (didn't bother looking up the timing)

The GigaDevice GDP2BFLM-CA parts are:
256 Mb x16 @ 2133 Mbps with 14-14-14 timing. which matches K4B4G1646D-BYNB from Samsung. 

They must've designed a bit of flexibility into the FPGA DDR3 controller.
Ref:
https://semiconductor.samsung.com/us/dram/ddr/ddr3/k4b4g1646e-byma/
https://semiconductor.samsung.com/us/dram/ddr/ddr3/k4b4g1646d-bynb/

[Aleksandr]

Is your DHO914 with 3 DDR3 RAM chips?

yes, 3* K4B4G1646E-BYMA

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

AliExpress! DDR3 K4B4G1646E-BYMA 4 Gb
https://sl.aliexpress.ru/p?key=u9Q7Ogb

Interesting: In comparison of the datasheets, those Samsung parts are:
512 Mb x8 @ 1866 Mbps (didn't bother looking up the timing)

The GigaDevice GDP2BFLM-CA parts are:
256 Mb x16 @ 2133 Mbps with 14-14-14 timing. which matches K4B4G1646D-BYNB from Samsung. 

They must've designed a bit of flexibility into the DDR3 controller.

Take a closer look at the decoding of the markings, K4B4G1646E-BYMA 256Mb x 16. Timing doesn't really matter here, I think.

[AceyTech]

Take a closer look at the decoding of the markings, K4B4G1646E-BYMA 256Mb x 16. Timing doesn't really matter here, I think.

RAS/CAS, Setup, etc timings don't matter in a Dram controller?

BTW:  I was going by the Samsung website(links above), comparing it to the decoded part number of the GigaRam parts originally stuffed.  Looks like they put slower parts in newer builds.  Maybe they were never taking full advantage of the first parts.

[AceyTech]

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

Not sure whether it was meant that way, but your comment comes across as disparaging. Which would be unwarranted, since my question was sincere:

If indeed you populated 2 GB DRAM chips instead of 4 GB, that would obviously be an explanation why they did not work. Since you seem to know what you are doing, I assume you had a good reason to choose those chips. Hence I would hope that you can share that reason. Thanks!

@2084's experiment was worthwhile.

I think 2GB vs 4GB might not absolutely cause it to not work
Point:  the controller may not see anything above the 2GB boundary, but the values in the first 2 gigs should've been ok, therefore it probably wouldn't outright fail..
Anyone who has debugged enough Dram designs with a solder short/open on an address line knows what I mean.

Well, the naked lands could have been probed before trying to solder in the chip, yes?

If you have a DHO800 with no chips blocking the pads you can probe them to look for activity at boot up.

PS: Has anybody looked in the boot log for messages to do with extra memory?

Point 1:  Most of the signals(address/data) are routed to each of the Drams, only control lines differ, so you have to find the individual Chip Selects, to see if they're being addressed.
Point 2:  I thought it was already discussed/agreed that the FPGA DDR3's aren't connected to the system., so how would Android know to look for/log it?

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???

I say again: I think you did a good job the reflowing the DDR's on your unit.  No shorts, and it boots and still works?  Fantastic.
The chips you found don't appear to be DDR3L, which may be a problem, since they may not always work well at that lower voltage. (1.35 vs 1.5 volts)

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.

Actually, it is bad design to NOT plan for several "memory chip models".  Horrible., considering how volatile the Ram market is/has been historically.  Single sourced parts are avoided at all costs, if the company wants to stay in business for very long.

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.

@ebastler I think you nailed it.  This is the most probable scenario.  The extra DDR3's aren't in use in the 900's, but probably/hopefully will be used via an update, some time in the future.

[maxspb69]

The extra DDR3's aren't in use in the 900's, but probably/hopefully will be used via an update, some time in the future.

Or (and we all know Rigol, this is most often the case with them) these memory chips will never be used. There is also an assumption that the chips were originally used, but Rigol could not get the entire system to work correctly and disabled them at the last moment in the release firmware. Many PCBs had already been assembled at that time. They didn't remove the chips...

[ebastler]

There is also an assumption that the chips were originally used, but Rigol could not get the entire system to work correctly and disabled them at the last moment in the release firmware. Many PCBs had already been assembled at that time. They didn't remove the chips...

Those two assumptions are not mutually exclusive. I also hypothesized that a relatively late change to a fallback solution is responsible for the fact that the two unused chips were populated.

But it seems that Rigol continues to populate these chips, even in recent builds (with different DDR3 RAM types); I have not read about any DHO9xx which does not have them. And they have not "downgraded" the datasheet specs so far to reflect the limitations of the fallback solution.

That might suggest that Rigol still hope to fix this via a firmware update. Where "hoping" would, of course, not imply a guarantee that it will actually happen... The upcoming SDS800X HD launch should at least give Rigol some motivation to up their game!

[gabiz_ro]

What about logic analyzer?
Still no one made hardware upgrade to logic analyzer and compare with models with logic analyzer from factory.
(at least I don't know anyone that confirmed that)

[Randy222]

The extra DDR3's aren't in use in the 900's, but probably/hopefully will be used via an update, some time in the future.

Or (and we all know Rigol, this is most often the case with them) these memory chips will never be used. There is also an assumption that the chips were originally used, but Rigol could not get the entire system to work correctly and disabled them at the last moment in the release firmware. Many PCBs had already been assembled at that time. They didn't remove the chips...

Which firmware? I don't think Android code in GEL would do it, but the FPGA BOOT.bin code could.
So maybe we need to compare the initial FW BOOT.bin with the latest 00.01.02.00.02 BOOT.bin , which was something I was about to do today.
If there is significant change then maybe that's where use of extra DDR was cut out.

On last few posts:
It was mentioned about FPGA log file on Android. This file is not from the FPGA, it's log data that comes from std-out std-err from running FPGA related commands "spi2", etc.

It was also mentioned something about using 4GB chip when FPGA only uses 2GB. That's typically ok, the addresser simply won't call out to mem blocks beyond some programmed limit. But I find this an odd method given how flexible FPGA's are, BOOT.bin should just have a mem function for something like get_mem_size(), and then use it. Unless the AMD FPGA itself is made to have 2GB max addressable.

I read app data sheet on the micron DDR mem that was listed some posts back. They make note about using the L mem in the 1.5v space, but no notes about using the 1.5v mem in the 1.3v space. I suspect using 1.5v mem in 1.3v space may cause the mem to not function as expected.

[Randy222]

I need to get the 1st FW image to compare to, v00.01.00.00.19  2023/07/24 is the initial. Anyonone have this FW zip / link, or just the FPGA BOOT.bin from this version?

But, so far no changes to FPGA BOOT.bin

As for updating FPGA via GEL update, kinda odd they just do it even if BOOT.bin is the same. The update script should 1st check if the old vs new are different, then only spi2flash the FPGA if there's a diff, hash check is easy to do. There's always risk if a push of code goes badly, so don't do it unless you need to.

Also take a look at the attached strings found in BOOT.bin. References to "micron", and the biggest reference to memory (MB, Gb, etc) is "2G Bits".

Code: [Select]

[roott@localhost DHO]# md5sum BOOT.01.01.00.00.bin
80b92f7ab2b60552737fcf12ddb39bb6  BOOT.01.01.00.00.bin

[roott@localhost DHO]# md5sum BOOT.01.02.00.00.bin
80b92f7ab2b60552737fcf12ddb39bb6  BOOT.01.02.00.00.bin

[roott@localhost DHO]# md5sum BOOT.01.02.00.02.bin
80b92f7ab2b60552737fcf12ddb39bb6  BOOT.01.02.00.02.bin
[root@localhost DHO]#

[maxspb69]

As for updating FPGA via GEL update, kinda odd they just do it even if BOOT.bin is the same. The update script should 1st check if the old vs new are different, then only spi2flash the FPGA if there's a diff, hash check is easy to do. There's always risk if a push of code goes badly, so don't do it unless you need to.

Apparently Rigol has excellent circuit engineers and interface designers. But very bad programmers. And it shows in all their products. It’s interesting that they themselves don’t understand where their weakest point is.

[gabiz_ro]

@Randy222
I have found one that is different
Don't know what version is, it may be the initial one that was on scope when brand new, since I found it on an backup of one USB pen drive in Rigol FPGA folder.
Need to switch to linux to mount and extract files from sdcard backup I made at that time and compare files.
BOOT_SelfTest.bin is identical

[Randy222]

@Randy222
I have found one that is different
Don't know what version is, it may be the initial one that was on scope when brand new, since I found it on an backup of one USB pen drive in Rigol FPGA folder.
Need to switch to linux to mount and extract files from sdcard backup I made at that time and compare files.
BOOT_SelfTest.bin is identical

Thanks.
I now using Cutter to do some analysis.
Your bin has 21 functions.

All the others have 24 functions.

I don't know what new or what's changed yet.

[ebastler]

Just sayin': Nobody claimed that Rigol ever shipped a DHO900 which used that extra RAM.

Oh, and are you sure Cutter can do anything meaningful on FPGA binaries? (That's what you are looking at, right?)

[Randy222]

Just sayin': Nobody claimed that Rigol ever shipped a DHO900 which used that extra RAM.

Oh, and are you sure Cutter can do anything meaningful on FPGA binaries? (That's what you are looking at, right?)

Cutter appears to dissemble/decompile just fine.

[maxspb69]

Xilinx configuration bitstream files practically cannot be parsed, disassembled, etc. You can only do a byte-by-byte comparison, but you will never know what exactly the two files differ in, what functionality they have.
But even differences in two files will not be proof that the FPGA will have a different configuration; even changing the project synthesis  parameters &  settings will produce different files with completely identical functionality.

[gabiz_ro]

I don't know about Cutter, just take a look now.
At firs sight seems is in x64 mode.
I don't think that is FPGA format.
Also file use some unknown for me endianness  little endian in dword or 4 bytes ?
Also maxspb69 is right.

Code: [Select]

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000910   6C 62 73 66 66 6C 65 2E  00 00 00 00 00 00 00 00   lbsffle.........it may be fsblelf

Code: [Select]

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000950   5F 55 50 53 53 32 31 48  69 62 2E 31 00 00 00 74   _UPSS21Hib.1...tit must be SPU_H12S1.bit

Code: [Select]

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000990   61 64 70 75 65 2E 65 74  00 00 66 6C 00 00 00 00   adpue.et..fl....is update.elf

[ebastler]

Cutter appears to dissemble/decompile just fine.

What language does it decompile or disassemble into? 

Maybe there's code for the on-chip ARM processor somewhere in there. But that's not the FPGA configuration which would drive the DRAM. I would be very surprised if Cutter had anything to say about FPGA configuration data proper.

We have that saying in Germany, "I am looking at it like a pig staring into clockworks."  But at least you describe what you see with a lot of conviction.

[Randy222]

Attached pics from Cutter

[ebastler]

Yes, that's ARM assembly code, which has nothing to do with the FPGA configuration itself.

[Randy222]

Yes, that's ARM assembly code, which has nothing to do with the FPGA configuration itself.

That's the FPGA BOOT.bin that comes in DHO GEL package, gets "flashed" using spi2flash.

So what exactly is the FPGA BOOT.bin file ?

[ebastler]

So what exactly is the FPGA BOOT.bin file ?

I assume it is the FPGA configuration file. But since the FPGA contains an ARM core, among much other stuff, there will (also) be ARM code in there -- unless that is loaded from external ROM separately. You are clearly looking at ARM code there. I assume that there are also proper FPGA configuration data in the .bin file, which Cutter ignores since it can't recognize anything.

If you are not familiar with FPGAs, it may be helpful to read up on them. While the high-level languages used to describe their behavior (Verilog and VHDL) do look somewhat similar to C, the functionality they encode is very different from what a CPU with a sequential program does. Essentially you create a "wired" circuit, made from individual flip-flops, logic lookup tables, and programmable interconnects. This circuit will behave like a hard-wired one, with massively parallel operation of the different parts of the circuit.

The binary configuration file describes (on a rather low "close to the metal" level) how all the internal "switches" in the FPGA matrix are set which select the active interconnects, define the logic tables etc.

[Randy222]

So what exactly is the FPGA BOOT.bin file ?

I assume it is the FPGA configuration file. But since the FPGA contains an ARM core, among much other stuff, there will (also) be ARM code in there -- unless that is loaded from external ROM separately. You are clearly looking at ARM code there. I assume that there are also proper FPGA configuration data in the .bin file, which Cutter ignores since it can't recognize anything.

If you are not familiar with FPGAs, it may be helpful to read up on them. While the high-level languages used to describe their behavior (Verilog and VHDL) do look somewhat similar to C, the functionality they encode is very different from what a CPU with a sequential program does. Essentially you create a "wired" circuit, made from individual flip-flops, logic lookup tables, and programmable interconnects. This circuit will behave like a hard-wired one, with massively parallel operation of the different parts of the circuit.

The binary configuration file describes (on a rather low "close to the metal" level) how all the internal "switches" in the FPGA matrix are set which select the active interconnects, define the logic tables etc.

Well, you made me go read some.
In this hack thread the mention of the "N25Q128" tells me the spi2flash is flashing this micron serial NOR flash memory. Is this memory in the FPGA ?

In the BOOT.bin I find references to the AMD API stuff:
xqspips_options.c
xdevcfg_intr.c
xqspips.c
xdevcfg.c

AMD API:
https://xilinx.github.io/embeddedsw.github.io/qspips/doc/html/api/xqspips__flash__intr__example_8c.html
https://xilinx.github.io/embeddedsw.github.io/qspips/doc/html/api/xqspips__options_8c.html

[AceyTech]

So what exactly is the FPGA BOOT.bin file ?

I assume it is the FPGA configuration file. But since the FPGA contains an ARM core, among much other stuff, there will (also) be ARM code in there -- unless that is loaded from external ROM separately. You are clearly looking at ARM code there. I assume that there are also proper FPGA configuration data in the .bin file, which Cutter ignores since it can't recognize anything.

If you are not familiar with FPGAs, it may be helpful to read up on them. While the high-level languages used to describe their behavior (Verilog and VHDL) do look somewhat similar to C, the functionality they encode is very different from what a CPU with a sequential program does. Essentially you create a "wired" circuit, made from individual flip-flops, logic lookup tables, and programmable interconnects. This circuit will behave like a hard-wired one, with massively parallel operation of the different parts of the circuit.

The binary configuration file describes (on a rather low "close to the metal" level) how all the internal "switches" in the FPGA matrix are set which select the active interconnects, define the logic tables etc.

Well, you made me go read some.
In this hack thread the mention of the "N25Q128" tells me the spi2flash is flashing this micron serial NOR flash memory. Is this memory in the FPGA ?

In the BOOT.bin I find references to the AMD API stuff:
xqspips_options.c
xdevcfg_intr.c
xqspips.c
xdevcfg.c

AMD API:
https://xilinx.github.io/embeddedsw.github.io/qspips/doc/html/api/xqspips__flash__intr__example_8c.html
https://xilinx.github.io/embeddedsw.github.io/qspips/doc/html/api/xqspips__options_8c.html

@Randy222  FPGA's don't have flash memory(per se), and are almost always loaded/programmed by a BINary file from an external IC.  At least that's how they always were when I was designing stuff with them

@ebastler  That was a nice brief synopsis re: FPGA