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 your DHO914 with 3 DDR3 RAM chips?yes, 3* K4B4G1646E-BYMA
Ooooh! This is great! A different memory and more common!!!!
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
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.
In order not to look for answers, you can install those chips yourself that you consider necessaryNot 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!
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?
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???
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.
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.
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.
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...
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...
[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]#
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.
@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
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?)
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 fsblelfOffset 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...t
it must be SPU_H12S1.bitOffset 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
Cutter appears to dissemble/decompile just fine.
Yes, that's ARM assembly code, which has nothing to do with the FPGA configuration itself.
So what exactly is the FPGA BOOT.bin file ?
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.
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