EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: konnor on March 31, 2018, 07:28:10 pm
-
Change List
30.03.2018 - first pub version.
1) Ext port 6000 funcs - read/write/call (see rigolif programm)
2) pluses -> pulses
3) rnage -> range (decoder:conf:range)
4) Changed USB Buffer Size (40->200) - test, please. I don't use USB IF
5) Disabled set bandwidth to license maximum on start (BW20 fix)
31.03.2018
fixed bug on pic<->bmp conversion
Links to additional resources:
-Current version of the library and utilities for plug-ins (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1501693/#msg1501693)
Plugins & tools work only with patched firmware.
You can write a small application that you can load into the oscilloscope's memory and perform any action there.
If the oscilloscope hangs or the result does not work, simply reboot the oscilloscope. This allows you to test patches and add-ons with a significantly lower risk to turn the oscilloscope into a brick.
Additionally, you can write an application that constantly works inside the oscilloscope (telnet, ftp, fast load/reload wave, tetris ;), etc).
Content of archive:
add_info - firmware patch bin, diff-file, function address list and lst-file with initial initialization procedure of DS1000Z
lib - library and headers
lib_src - libray for plugin (with sources and tool for create sources)
patch - patch project for IAR (for gel)
plugin_simple - an example of a simple application that blink out all the LEDs and exit (memory is freed).
plugin_thread - an example of an application that launches an endless stream with all LEDs flashing (memory is NOT
freed). To stop it, just reboot the oscilloscope.
plugin_sw - Start War melody plugin.
plugin_backup - save nvram and hidden (/sys) files to USB flash
rigolif - Very primitive program for working with an oscilloscope. It is given in the source texts. Allows you to read and write memory of the oscilloscope, call internal functions, load plug-ins. In the directory there are bat-files with examples.
-Hardware info (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1484577/#msg1484577)
-LED and key codes (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1473448/#msg1473448)
-How to kill your oscilloscope(secret usb-flash) (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1473517/#msg1473517)
-Decompiled content of guiResData.hex (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1478454/#msg1478454)
Current firmware update: 31.03.2018 (NOT 01.04.2018!)
I can not attach one archive (1MB limit) and multi-volume zip has problems with unpacking. Therefore, the rar archives, renamed to zip, are attached. If anyone knows how to solve this problem by the more correct method - let me know, please.
-
Plugin samples for patched firmware.
Plugins & tools work only with patched firmware.
You can write a small application that you can load into the oscilloscope's memory and perform any action there.
If the oscilloscope hangs or the result does not work, simply reboot the oscilloscope. This allows you to test patches and add-ons with a significantly lower risk to turn the oscilloscope into a brick.
Additionally, you can write an application that constantly works inside the oscilloscope (telnet, ftp, fast load/reload wave, tetris ;), etc).
Content of archive:
add_info - firmware patch bin, diff-file, function address list and lst-file with initial initialization procedure of DS1000Z
libb - libray for plugin (with sources)
patch - patch project for IAR
plugin_simple - an example of a simple application that blink out all the LEDs and exit (memory is freed).
plugin_thread - an example of an application that launches an endless stream with all LEDs flashing (memory is NOT freed). To stop it, just reboot the oscilloscope.
rigolif - Very primitive program for working with an oscilloscope. It is given in the source texts. Allows you to read and write memory of the oscilloscope, call internal functions, load plug-ins. In the directory there are bat-files with examples (do not forget to change the IP-address to your own).
-
Can you explain a bit on how hard it is to setup the development environment and what is needed to create a plugin?
-
I use IAR (7.x) standart install. You may just compile plugin from samples directory, all in source codes.
-
Did you use the latest firmware version of rigol ds1000z? What is this modification, I do not understand it?
5) Disabled set bandwidth to license maximum on start (BW20 fix)
-
janekivi,
A patched CRC.
00000000 - File Type: DS1000Z
00000010 - Version: 00.04.04.03.02
00000020 - Bitmask: 00000700
00000024 - # Sections: 10
Offset Section Name SectiSz StartAdr CRC32 Type
00000028 /sys/SparrowAPP.out 001045C6 00000280 6E08406C 00000001 [00000280-00104845] CRC OK
00000064 /sys/SparrowFPGA.hex 000C4372 00104846 679334B7 00000005 [00104846-001C8BB7] CRC OK
000000A0 /sys/SparrowDGFPGA.hex 00046F04 001C8BB8 E4FDFCA9 00000006 [001C8BB8-0020FABB] CRC OK
000000DC /sys/logo.hex 000BB818 0020FABC AC2CE5C4 0000000A [0020FABC-002CB2D3] CRC OK
00000118 /sys/guiResData.hex 000B6A2C 002CB2D4 EFF83A4B 0000000C [002CB2D4-00381CFF] CRC OK
00000154 /sys/guiPicData.hex 0001E995 00381D00 C1DBFD83 00000011 [00381D00-003A0694] CRC OK
00000190 /sys/SparrowConfig.hex 000BB818 003A0695 BAD12B30 00000010 [003A0695-0045BEAC] CRC OK
000001CC /sys/SparrowWaveTable.hex 000020E8 0045BEAD B0445B96 0000000B [0045BEAD-0045DF94] CRC OK
00000208 /sys/SparrowCalFile.hex 0002329C 0045DF95 FBE2BA34 0000000F [0045DF95-00481230] CRC OK
00000244 00000118 00481231 6AD11BAE 00000032 [00481231-00481348] CRC OK
Offset CRC32 Flags Filesize Endianes Version Rsvd
00000280 A7E7BDB2 00000003 001045AE AA5555AA 4040302 00000000 [00000298-00104845] CRC OK SparrowAPP.out CRC-PATCH OK
00104846 C9AF5D56 00000000 000C435A AA5555AA 4040302 00000000 [0010485E-001C8BB7] CRC OK
001C8BB8 138E13B9 00000000 00046EEC AA5555AA 4040302 00000000 [001C8BD0-0020FABB] CRC OK
0020FABC 9B4EA177 00000000 000BB800 AA5555AA 4040302 00000000 [0020FAD4-002CB2D3] CRC OK
002CB2D4 D7825E44 00000000 000B6A14 AA5555AA 4040302 00000000 [002CB2EC-00381CFF] CRC OK
00381D00 D34B79C8 00000001 0001E97D AA5555AA 4040302 00000000 [00381D18-003A0694] CRC OK
003A0695 5DEF7058 00000000 000BB800 AA5555AA 4040302 00000000 [003A06AD-0045BEAC] CRC OK
0045BEAD 558BD392 00000000 000020D0 AA5555AA 4040302 00000000 [0045BEC5-0045DF94] CRC OK
0045DF95 7717C897 00000000 00023284 AA5555AA 4040302 00000000 [0045DFAD-00481230] CRC OK
File Processed OK
-
Now you can see from what this is made an what inside. RigolPacker in our thread don't read it,
I have somewhere patched RigolPacker for this...
It's nice to show what you made, from what and what inside - it's very easy to brick scope and
sometimes very hard to get it working again. Thread is starting with... change list, and no word
what it actually is...
Patched CRC - he told about this...
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/msg1467148/#msg1467148 (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/msg1467148/#msg1467148)
-
Did you use the latest firmware version of rigol ds1000z? What is this modification, I do not understand it?
5) Disabled set bandwidth to license maximum on start (BW20 fix)
Error N5 in buglist:
The 20M Bandwidth Limit setting for each channel is not saved, it resets of OFF each power cycle.
Actually, Rigol save and restore this parameter to non-volatile ram. But (after restore) starts some procedure, what setup bandwith to max license value (50, 70 or 100 MHz).
-
I can not attach one archive (1MB limit) and multi-volume zip has problems with unpacking. Therefore, the rar archives, renamed to zip, are attached. If anyone knows how to solve this problem by the more correct method - let me know, please.
Just use an external filehost like ie. mega
https://mega.nz/#!FChXURiQ!u3c1yOyWV23bScS1ArV-3CwG-oY7ktjv6HUZ3LdJ8Nw
(Send a message, if i should delete the link)
-
The two files attached in the first post can be unpacked just fine, all it is needed is to rename them:
rename DS1000ZUpdate.part1.zip as DS1000ZUpdate.part1.rar
rename DS1000ZUpdate.part2.zip as DS1000ZUpdate.part2.rar
then extract the gel file.
It is OK to store them as attachments on EEVblog, files stored on cloud will be deleted after a while.
-
A little joke at Fool’s Day.
After loading plugin, oscilloscope work and play SW-melody.
-
Renamed the zipfiles to rar's and unpacked the GEL file. Firmware updated took perfectly fine, no issues. Also, confirming that the BMP problem was fixed. Did a self-cal and everything looks good. I'll test the USB later. Nice job!
I already miss the pluses.... :'(
-
Images are stock now, original logo and guiPicData which is repacked, why?
What was changed there in last release?
In windows there is no need to rename any files if you use any 3rd party packer...
-
Images are stock now, original logo and guiPicData which is repacked, why?
My program completely parses the firmware on the components (with the creation of BMP-files) and then collects it back. If the package algorithm parameters used by me work for the elf firmware file, then they will be correct for the rest of the files. If not - the original version of the images does not help the oscilloscope to start.
What was changed there in last release?
Fixed a conversion from 16-bit images used in firmware to a 24-bit BMP used for disassembled firmware. There was a mistake in the mask of the color channel. The module was written for a long time, and for half a year I was already accustomed to the non-standard color scheme and believed that it should be so. Approximately, as with the "pluses" :D
In windows there is no need to rename any files if you use any 3rd party packer...
Yes, Winarar will unpack these files and without renaming. But I prefer to warn about a different format. It is better to make an unnecessary warning than not to do the necessary warning.
-
zip files can be muliti-part, too.
Or... maybe we could admit that 7zip is now available everywhere, that zip and rar are legacy (almost).
-
konnor Is it possible to share the disassembly database of original firmware?
-
Very good, vsjo ponjatno!
Disassembly should be interesting to see as we "inventing the same wheel" but going bit deeper...
-
Is it possible to modify firmware that it will allow use protocol decoders in segmented memory mode (option is greyed out) or maybe even better to decod from whole memory and not just from screen?
-
Thanks for your work on this konnor. I will get to try this in a couple of months when I and my equipment meet in Canada
-
Is it possible to modify firmware that it will allow use protocol decoders in segmented memory mode (option is greyed out) or maybe even better to decod from whole memory and not just from screen?
I never understood why Rigol took such an idiotic decision to disable the ability of combining segmented memory and protocol decoding. That's just way too disappointing.
-
Is it possible to modify firmware that it will allow use protocol decoders in segmented memory mode (option is greyed out) or maybe even better to decod from whole memory and not just from screen?
I still studied the decoding protocol modules to a minimum, only in some of the names of functions, associated with LXI. A list of the names of functions of the latest Rigol firmware (with binding to addresses) is available in the plugin archive.
If the decoding is done in the central processor, then there should not be any fundamental problems. As a first step, you need to find the module, write an alternative module, and load it into memory with the utility. When/if it is debugged, you can inject it into the firmware. The work is certainly very large, but really feasible.
If FPGA resources are used for decoding, this will significantly complicate the process. I do not really know the working programs that allow you to "disassemble" the firmware of large FPGAs. To understand all the details of FPGA functioning only on the basis of calls from the firmware is very difficult, if at all possible. This is a typical "blackbox" study.
-
I never understood why Rigol took such an idiotic decision to disable the ability of combining segmented memory and protocol decoding. That's just way too disappointing.
Product segmentation? The DS2000 models (would imagine 4000 and 6000 as well) work with segmented memory and decoding. Isn't this how most equipment manufactures do things. Limit certain things in the lower (cheaper) models, to encourage people who need that functionality to buy the more expensive models.
-
Is it possible to modify firmware that it will allow use protocol decoders in segmented memory mode (option is greyed out) or maybe even better to decod from whole memory and not just from screen?
I still studied the decoding protocol modules to a minimum, only in some of the names of functions, associated with LXI. A list of the names of functions of the latest Rigol firmware (with binding to addresses) is available in the plugin archive.
If the decoding is done in the central processor, then there should not be any fundamental problems. As a first step, you need to find the module, write an alternative module, and load it into memory with the utility. When/if it is debugged, you can inject it into the firmware. The work is certainly very large, but really feasible.
If FPGA resources are used for decoding, this will significantly complicate the process. I do not really know the working programs that allow you to "disassemble" the firmware of large FPGAs. To understand all the details of FPGA functioning only on the basis of calls from the firmware is very difficult, if at all possible. This is a typical "blackbox" study.
I thought that there is just software lock on decoders functions while in segmented memory mode and just remove that lock will be enough, not redesigning decoders from scratch. I know that decoding from whole memory would need making new modules and would be more complicated.
-
If the decoding is done in the central processor, then there should not be any fundamental problems.
None, apart from the fact that the central processor probably doesn't have any access to the full sample memory. It can probably only see a 1200 byte downsampled buffer. The downsampling is what the FPGA does.
-
can you extract and insert modules from other Rigol firmware?
like other protocol decoders??
-
The term "module" is conditional. The executable part of the firmware is a monolithic elf-file. The firmware includes several additional data files (graphics, firmware fpga, etc.), but all the CPU code is in the elf.
Therefore, "extract and insert" - is a non-trivial task, weakly amenable to any automation.
It's easier to write your own module on your own, than to cut out a binary image from another firmware, manually adjust the addresses (by a binary editor) and paste result into the existing firmware.
I'm currently considering the option to add firmware functionality by automatically downloading additional modules from the system or user partition (when you turn on the oscilloscope) or from a flash drive. If you do not try to write "Windows For Rigol", then free internal memory is enough.
-
but can it play DOOM?? ;)
-
install for testing that firware that modifies among other things "Changed USB Buffer Size (40-> 200) - test, please.I do not use USB IF" I connect the rigol to the usb and the data transmission is still slow, realy that I should improve.
-
I would like to see additional protocols decoding added if that's possible.
-
I connect the rigol to the usb and the data transmission is still slow, realy that I should improve.
Speed should not change. This patch was supposed to fix the problem of non-compliance with the standard.
The implementation of SCPI commands from Rigol is very suboptimal. They tried to formalize the splitting of the program into components, and as a result, reading one parameter word (basically accessible and for direct access to memory) requires a dozen calls, including calling the module via a text name with a table search. It turned out even worse than OLE in Windows.
-
but can it play DOOM?? ;)
Maybe. The first versions required only a few megabytes of memory.
When saving pictures, the Rigol calls malloc on 4 megabytes:
P4_rw:400D1BB4 MOV R0, #4096000 ; size_t
P4_rw:400D1BB8 BL malloc ; Branch with Link
The operating memory of the CPU is 64MB, of which the firmware takes about 10 at startup. Another 64 MB are connected to FPGA.
You have not decided to write Windows yet? ;)
-
i dont write windows, i erase it! :-DD
-
I decided to test in practice how much Rigol memory can allocate via malloc().
I was pleasantly surprised by the result: the limit is about 23 MB (0x1660000). The attempt to get 0x1680000 bytes - failed.
The number of channels turned on, the selected memory depth or the recorded samples did not affect the result.
Thus, more than a third of the CPU memory is free and can be used for any extensions.
-
I decided to test in practice how much Rigol memory can allocate via malloc().
I was pleasantly surprised by the result: the limit is about 23 MB (0x1660000). The attempt to get 0x1680000 bytes - failed.
The number of channels turned on, the selected memory depth or the recorded samples did not affect the result.
Thus, more than a third of the CPU memory is free and can be used for any extensions.
That is a very interesting finding, good to know, thank you!
Yet, those 23MB might not be _always_ free to use. I am saying this because, when I tested how many RAW data points can be requested at once by the SCPI command ":WAV:DATA?", sometimes it was possible to extract up to 1 700 000 data samples at once (with only one channel active, byte mode). When more functions were activated, the maximum data points fell down to about 1 000 000 points (for only one channel active). The programming manual for DS1054Z specify the limit should be maximum 250 000 points at once.
That makes me think that there are situations were _all_ the RAM is used, when additional functions like Fourier/filters/decoders/whatever are activated. If we were to have 23 MB free at all time, then I don't see the reason for not being able to extract the same 1.7mil data points when additional functions are enabled.
Of course, this is not such a big inconvenient, because it can be tested if a malloc() was successful, but I won't bet on having all those 23MB available all the time.
-
I am surprised that this has not gone viral. What am I missing?
-
I am saying this because, when I tested how many RAW data points can be requested at once by the SCPI command ":WAV:DATA?", sometimes it was possible to extract up to 1 700 000 data samples at once (with only one channel active, byte mode). When more functions were activated, the maximum data points fell down to about 1 000 000 points (for only one channel active). The programming manual for DS1054Z specify the limit should be maximum 250 000 points at once.
It is possible that this is due to some other reasons. I watched (though not in great detail): WAV: DATA? - the function uses a permanently allocated (at the startup) buffer of 2 MB. The same buffer is used in the part of the functions of the decoder. I did not find allocate additional memory of noticeable volume. That, however, does not guarantee that this capture is not performed in any function at the thirty-seventh level of nesting.
Of course, the oscilloscope sometimes uses this memory (a fragment from the image saving function I previously mentioned). The question is in the other - no one ever calculates the required amount of memory to the accuracy of percents. Probably, the developers Rigol went the following way: 32MB of memory for the CPU is not enough - we will put 64.
As a result of the study, we can draw the following conclusion: it is possible to freely load plugins or patches with the size of hundreds of kilobytes. With some caution - the size of megabytes. Considering that Rigol's firmware is a microkernel operating system with a network stack, a host USB and device USB, libraries for saving in png, jpg and tiff, with fonts and many many others, take less than 4MB, my imagination is not enough to imagine a megabyte plugin.
-
Thanks for all the work you put into this project!
I love where this is heading :-+
-
The implementation of SCPI commands from Rigol is very suboptimal. They tried to formalize the splitting of the program into components, and as a result, reading one parameter word (basically accessible and for direct access to memory) requires a dozen calls, including calling the module via a text name with a table search. It turned out even worse than OLE in Windows.
Can you trace the calls?
I have a long standing suspicion that the vertical position controls are slow because somewhere internally they're converting them into multiple SCPI commands. Is it possible to confirm that?
-
I watched (though not in great detail): WAV: DATA? - the function uses a permanently allocated (at the startup) buffer of 2 MB. The same buffer is used in the part of the functions of the decoder.
Great info, thanks!
Considering that Rigol's firmware is a microkernel operating system with a network stack, a host USB and device USB, libraries for saving in png, jpg and tiff, with fonts and many many others, take less than 4MB
Could that be BusyBox, or do you think it is rather a proprietary Rigol microkernel?
The thread https://www.eevblog.com/forum/projects/rigol-ds10xxz-firmware-re-write/ (https://www.eevblog.com/forum/projects/rigol-ds10xxz-firmware-re-write/) seems very interesting, too.
While it is not directly related to writing plugins, tmbinc has a working U-Boot for DS1000Z, and in the pages 3 and 4 there is some info about the keyboard pinout. The pinout might help for disassembling (or writing) code for the keyboard.
-
I am surprised that this has not gone viral. What am I missing?
DOOM isn't running yet.
-
I would like to repeat my naive question, is this cool firmware compatible with MSO1074Z ?
Cheers,
DC1MC
-
Can you trace the calls?
I have a long standing suspicion that the vertical position controls are slow because somewhere internally they're converting them into multiple SCPI commands. Is it possible to confirm that?
I see calls in disassembler.
I will give an example of how the simplest command for obtaining the channel bandwidth is produced. (SYSTEM:BW?)
In the firmware there is a huge table (more than 1000 elements) for all SCPI commands. The main handler parses the command to separate components, finds the desired element in the table, and calls the subroutine. Up to this point everything has been done normally.
First subroutine: LXI_SYSTEM_BW_Ack ; DATA XREF: P4_rw:402086C4o
P4_rw:4030F3F4 STMFD SP!, {R4,LR} ; Store Block to Memory
P4_rw:4030F3F8 MOV R4, #0 ; Rd = Op2
P4_rw:4030F3FC BL LXI_SYSTEM_BW_Ack_ ; Branch with Link
P4_rw:4030F400 MOVS R4, R0 ; Rd = Op2
P4_rw:4030F404 CMP R4, #0 ; Set cond. codes on Op1 - Op2
P4_rw:4030F408 BEQ loc_4030F414 ; Branch
P4_rw:4030F40C ADDS R4, R4, #0xB0000 ; Rd = Op1 + Op2
P4_rw:4030F410 B loc_4030F418 ; Branch
P4_rw:4030F414 ; ---------------------------------------------------------------------------
P4_rw:4030F414
P4_rw:4030F414 loc_4030F414 ; CODE XREF: LXI_SYSTEM_BW_Ack+14j
P4_rw:4030F414 BL LXI_SetBackAnswerFlags ; Branch with Link
P4_rw:4030F418
P4_rw:4030F418 loc_4030F418 ; CODE XREF: LXI_SYSTEM_BW_Ack+1Cj
P4_rw:4030F418 MOVS R0, R4 ; Rd = Op2
P4_rw:4030F41C LDMFD SP!, {R4,PC} ; Load Block from Memory
Second subroutinr:
P4_rw:402E1344 LXI_SYSTEM_BW_Ack_ ; CODE XREF: LXI_SYSTEM_BW_Ack+8p
P4_rw:402E1344
P4_rw:402E1344 BWCode = -0xB0
P4_rw:402E1344
P4_rw:402E1344 STMFD SP!, {R4,LR} ; Store Block to Memory
P4_rw:402E1348 SUB SP, SP, #0xB0 ; Rd = Op1 - Op2
P4_rw:402E134C MOV R4, #0 ; Rd = Op2
P4_rw:402E1350 MOVS R0, SP ; Target
P4_rw:402E1354 LDR R1, =dword_4000DE68 ; Source
P4_rw:402E1358 MOV R2, #0xB0 ; '-' ; Len
P4_rw:402E135C BL memcpy ; Branch with Link
P4_rw:402E1360 ;--
P4_rw:402E1360 MOVS R2, SP ; Buffer
P4_rw:402E1364 MOV R1, #6 ; Id
P4_rw:402E1368 LDR R0, =aConfig_16 ; OptCONFIG
P4_rw:402E136C BL GetSettings ; Branch with Link
P4_rw:402E1370 ;--
P4_rw:402E1370 LDR R0, [SP,#0xB8+BWCode] ; Load from Memory
P4_rw:402E1374 MOVS R4, R0 ; Rd = Op2
P4_rw:402E1378 MOVS R1, R4 ; Rd = Op2
P4_rw:402E137C ADR R0, aU_3 ; "%u"
P4_rw:402E1380 BL LXI_PrinfOut ; Branch with Link
P4_rw:402E1384 ADD SP, SP, #0xB0 ; Rd = Op1 + Op2
P4_rw:402E1388 LDMFD SP!, {R4,PC} ; Load Block from Memory
Here you can see a call to the GetSettings with three parameters: the module name (char []), the request code to the module, and the query format descriptor. The specified subroutine searches for the desired module (by direct search through the table via strcmp!!!), creates a special block of query, puts it in the queue for processing and and falls asleep.
The system thread periodically looks at the request queue and calls the desired subroutine (each module also has the ID and subprogram matching tables, the search for them is also linear). Here's a subroutine for BW:
P4_rw:402521F8 Cfg_GetMaxFreq ; DATA XREF: P6_rw:40601EC0o
P4_rw:402521F8
P4_rw:402521F8 var_18 = -0x18
P4_rw:402521F8
P4_rw:402521F8 STMFD SP!, {R4-R6,LR} ; Store Block to Memory
P4_rw:402521FC SUB SP, SP, #8 ; Rd = Op1 - Op2
P4_rw:40252200 MOVS R4, R0 ; Rd = Op2
P4_rw:40252204 MOVS R5, R1 ; Rd = Op2
P4_rw:40252208 MOVS R6, R2 ; Rd = Op2
P4_rw:4025220C BL RetMaxFreqX ; Branch with Link
P4_rw:40252210 CMP R0, #100 ; Set cond. codes on Op1 - Op2
P4_rw:40252214 BNE loc_40252220 ; Branch
P4_rw:40252218 MOV R4, #100 ; Rd = Op2
P4_rw:4025221C B loc_40252224 ; Branch
P4_rw:40252220 ; ---------------------------------------------------------------------------
P4_rw:40252220
P4_rw:40252220 loc_40252220 ; CODE XREF: Cfg_GetMaxFreq+1Cj
P4_rw:40252220 MOV R4, #70 ; Rd = Op2
P4_rw:40252224
P4_rw:40252224 loc_40252224 ; CODE XREF: Cfg_GetMaxFreq+24j
P4_rw:40252224 MOVS R0, R6 ; Dsc
P4_rw:40252228 BL InitStrParamDescr ; Branch with Link
P4_rw:4025222C MOV R0, #0 ; Rd = Op2
P4_rw:40252230 STR R0, [SP,#0x18+var_18] ; Store to Memory
P4_rw:40252234 MOV R3, #0 ; Rd = Op2
P4_rw:40252238 MOV R2, #1 ; Rd = Op2
P4_rw:4025223C MOVS R1, R4 ; Index
P4_rw:40252240 MOVS R0, R6 ; int
P4_rw:40252244 BL RetValFmt_02 ; Branch with Link
P4_rw:40252248 LDMFD SP!, {R0,R1,R4-R6,PC} ; Load Block from Memory
P4_rw:400F5F00 RetMaxFreqX ; CODE XREF: Cfg_GetMaxFreq+14p
P4_rw:400F5F00 ; ConfigMaxFreq2Operate+14p
P4_rw:400F5F00 ; ConfigMaxFreq2Operate:No70Mhzp
P4_rw:400F5F00 ; ConfigMaxFreq2Operate+6Cp
P4_rw:400F5F00 LDR R0, =ManufacturerName ; Load from Memory
P4_rw:400F5F04 LDR R0, [R0,#(FreqVersion2 - 0x40761C9C)] ; Load from Memory
P4_rw:400F5F08 BX LR ; Branch to/from Thumb mode
Having received the required parameter, the subroutine fills the response field, after which the data goes in the opposite direction - the system thread copies the data to the source buffer, frees the previously occupied memory blocks and awakens the requesting. And this is all for the sake of reading one word. In some cases, one module may give nested queries to other modules when processing a request. It reminds me very much of SendMessage / PostMessage from Windows, but can this mechanism be fast?
-
Could that be BusyBox, or do you think it is rather a proprietary Rigol microkernel?
No BusyBox. Rigol use MQX.
The thread https://www.eevblog.com/forum/projects/rigol-ds10xxz-firmware-re-write/ (https://www.eevblog.com/forum/projects/rigol-ds10xxz-firmware-re-write/) seems very interesting, too.
While it is not directly related to writing plugins, tmbinc has a working U-Boot for DS1000Z, and in the pages 3 and 4 there is some info about the keyboard pinout. The pinout might help for disassembling (or writing) code for the keyboard.
I saw this topic. in my opinion, project has no real prospects. Completely rewrite the firmware, in which more than 12000 functions, without having complete hardware documentation - are practically unrealistic, especially considering the need to work with two FPGAs (one of which firmware is unavailable in principle, and the second one does not have a disassembly mechanism).
As for the keys and LEDs, I do not need to know their wiring. I know the functions from the firmware, which are already debugged by programmers Rigol.
Key codes with mnemonic names are available from the SCPI commands:
enum Keys
{
Keys_None = 0x0,
Keys_HMENU = 0x11,
Keys_REF = 0x12,
Keys_HELP = 0x13,
Keys_LA = 0x14,
Keys_TMENU = 0x15,
Keys_TLEVEL = 0x16,
Keys_ZTLEVEL = 0x18,
Keys_CURSOR = 0x21,
Keys_MEASURE = 0x22,
Keys_F2 = 0x23,
Keys_DISPLAY = 0x24,
Keys_F4 = 0x25,
Keys_HPOSITION = 0x26,
Keys_ZHPOSITION = 0x28,
Keys_UTILITY = 0x31,
Keys_STORAGE = 0x32,
Keys_SINGLE = 0x33,
Keys_SOURCE = 0x34,
Keys_MNEXT = 0x35,
Keys_VSCALE = 0x36,
Keys_ZVSCALE = 0x38,
Keys_QOFF = 0x41,
Keys_MSF2 = 0x42,
Keys_CLEAR = 0x43,
Keys_MATH = 0x44,
Keys_TMODE = 0x45,
Keys_VPOSITION = 0x46,
Keys_ZVPOSITION = 0x48,
Keys_MSF6 = 0x51,
Keys_MSF1 = 0x52,
Keys_QM1 = 0x52,
Keys_AUTO = 0x53,
Keys_ACQUIRE = 0x54,
Keys_TFORCE = 0x55,
Keys_HSCALE = 0x56,
Keys_ZHSCALE = 0x58,
Keys_QPREVIOUS = 0x61,
Keys_MSF3 = 0x62,
Keys_F1 = 0x63,
Keys_CH1 = 0x64,
Keys_F6 = 0x65,
Keys_KFUNCTION = 0x66,
Keys_ZKFUNCTION = 0x68,
Keys_MSF5 = 0x71,
Keys_CH3 = 0x72,
Keys_F3 = 0x73,
Keys_CH2 = 0x74,
Keys_F5 = 0x75,
Keys_CH4 = 0x78,
Keys_QNEXT = 0x81,
Keys_MSF4 = 0x82,
Keys_MPREVIOUS = 0x83,
Keys_RSTOP = 0x84,
Keys_QPRINT = 0x85,
};
LED codes are easily determined experimentally:enum LEDS
{
LED_KFUNCTION = 0x1,
LED_CH1 = 0x2,
LED_CH2 = 0x4,
LED_CH3 = 0x8,
LED_CH4 = 0x10,
LED_LA = 0x20,
LED_GENERATOR = 0x40,
LED_RUNSTOP_GREEN = 0x80,
LED_SINGLE = 0x100,
LED_REF = 0x200,
LED_MATH = 0x400,
LED_RUNSTOP_RED = 0x800,
LED_TRIG_SINGLE = 0x1000,
LED_TRIG_NORMAL = 0x2000,
LED_TRIG_AUTO = 0x4000,
};
-
I would like to repeat my naive question, is this cool firmware compatible with MSO1074Z ?
I did not test it on this model, but there should not be any differences in behavior on different models. Rigol has one firmware for all models of the DS1000Z series.
-
I would like to repeat my naive question, is this cool firmware compatible with MSO1074Z ?
I expect so. Rigol only supplies one firmware for both models.
-
After cracking last bits of GEL file, I think this FLASH signature sounds interesting.
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/msg1466288/#msg1466288 (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/msg1466288/#msg1466288)
I made even windows XXTEA program for crypt and decrypt but didn't know how and where
to write this to see it in action. Is this in some file or in specific sector somewhere there?
I'm not so bright to understand everything (anything) in that complex (boring) disassembly stuff...
-
After cracking last bits of GEL file, I think this FLASH signature sounds interesting.
I made even windows XXTEA program for crypt and decrypt but didn't know how and where
to write this to see it in action. Is this in some file or in specific sector somewhere there?
source fragment:
static const unsigned char DecryptKeyString[]={
0x01, 0x00, 0x92, 0x03,
0x41, 0x08, 0x41, 0x08,
0x04, 0x21, 0xC3, 0x18,
0xC7, 0x39, 0x86, 0x31
};
static const char Sign[]="RIGOL TECHNOLOGIES,DS1000Z,SPARROW,201212";
#define DELTA 0x9e3779b9
#define MX (((z>>5^y<<2) + (y>>3^z<<4)) ^ ((sum^y) + (key[(p&3)^e] ^ z)))
static void pascal XXTEA(DWORD *v, int n, const DWORD *key)
{
size_t y, z, sum;
unsigned p, rounds, e;
if (n > 1){
rounds = 6 + 52/n;
sum = 0;
z = v[n-1];
do {
sum += DELTA;
e = (sum >> 2) & 3;
for (p=0; p<n-1; p++){
y = v[p+1];
z = v[p] += MX;
}
y = v[0];
z = v[n-1] += MX;
} while (--rounds);
}
else if (n < -1)
{
n = -n;
rounds = 6 + 52/n;
sum = rounds*DELTA;
y = v[0];
do {
e = (sum >> 2) & 3;
for (p=n-1; p>0; p--){
z = v[p-1];
y = v[p] -= MX;
}
z = v[n-1];
y = v[0] -= MX;
} while ((sum -= DELTA) != 0);
}
}
void TestTea(void)
{
unsigned char Buf[0x200];
FILE *OutFile;
memset(Buf, 0, sizeof(Buf));
memcpy(Buf, Sign, sizeof(Sign));
// ????????????
XXTEA((DWORD *)&Buf, 0x80, (DWORD *)DecryptKeyString);
if(NULL != (OutFile = fopen("SIGN", "wb"))){
fwrite(Buf, 1, 0x200, OutFile);
fclose(OutFile);
}
// ?????????????
XXTEA((DWORD *)&Buf, -0x80, (DWORD *)DecryptKeyString);
Buf[0x1FF]=0;
}
The SIGN file must be written to the last reserved sector of FAT32.
It should be taken into account that this signature gives access to all destructive functions, such as the formatting of the built-in drive and the erasure of the bootloader in NVRAM. I would not want to be responsible for the consequences in not very experienced hands. I will assume that the ability to compile this code and write down the result is a minimal test for experience. >:D
-
So ... when I can run DOSBox in there ? ... j/k guys ... ;D
Really appreciate all the works here, thank you. :-+
Subscribed.
-
I had this plain signature file and crypted signature file and xxtea.exe in zip ready.
Good I didn't post them all in there...
-
Yes, You can format local 90M disk and SYS directory is there with all files,
You can delete them... But where is the bootloader?
And yes, this menu is super secret and won't be visible on screenshots.
That's why here is my professional webcam images...
-
konnor -- just wanted to say thanks for the great work you have done, and for sharing your findings freely. Very much appreciated!
-
Yes, You can format local 90M disk and SYS directory is there with all files,
You can delete them...
This is one of the reasons why I doubted - to publish this secret key, or not. There is at least one experimenter who will delete the system file and suffer.
But where is the bootloader?
In NVRAM. The lower part is reserved for the boot loader, the high part is reserved for saving the settings. The processor can boot by SPI.
What I definitely will not publish - is the secret key sequences of the boot loader, which allow to erase NVRAM with the inserted special flash drive.
By the way, you need to be very careful when inserting a special flash drive when the loader is running. There are several sequences of only three keys, that will kill an oscilloscope without the possibility of a simple recovery.
Without a special flash drive, only relatively safe commands are available, such as disabling downloading saved settings at startup.
And yes, this menu is super secret and won't be visible on screenshots.
That's why here is my professional webcam images...
What??? :o This file menu is no more invisible than the usual file selection menu (without a special flash drive).
-
Yes, You can format local 90M disk and SYS directory is there with all files,
You can delete them...
This is one of the reasons why I doubted - to publish this secret key, or not. There is at least one experimenter who will delete the system file and suffer.
Not your problem.
What I definitely will not publish - is the secret key sequences of the boot loader, which allow to erase NVRAM with the inserted special flash drive.
By the way, you need to be very careful when inserting a special flash drive when the loader is running. There are several sequences of only three keys, that will kill an oscilloscope without the possibility of a simple recovery.
If it were me I'd publish it later, when all the other procedures are running smoothly.
It may be that somebody has a 'scope with broken input circuitry and they want to turn it into an instant-boot Tetris machine or something.
-
And yes, this menu is super secret and won't be visible on screenshots.
That's why here is my professional webcam images...
What??? :o This file menu is no more invisible than the usual file selection menu (without a special flash drive).
Just joking, screenshot does not capture this drive and file box, only background.
Menu is standard, only this Local SYS is extra. In Utility menu I saw TestModel.
There was many delete and test functions. One was 70M BW - add 70MHz bandwidth?
btw, I don't have special flash... I was cheating :-[
-
There was many delete and test functions. One was 70M BW - add 70MHz bandwidth?
There's a 70MHz model in the DS1000Z lineup (the DS1074Z).
-
I was looking around in my DS1054Z with all options enabled.
What may be there in other models menu...
-
Yesterday, I modified my decompiler for the guiResData.hex file to get a readable result.
I do not know, if there is a full description of the format of this file somewhere?
In short, the file consists of four large blocks:
1) Menu
2) six fonts
3) Table of text strings (for menus).
4) help
You can see the menu in the attached file.
Fonts have a binary format (the same as for fonts, compiled in elf). The fonts are completely raster, no truetype or vectors.
Text strings do not have independent meaning, they are used only in the menu.
The help is only in two languages, each language includes two blocks - a reference table and text strings. The format of the tables I have not yet understood (and do not plan).
-
Update plugin.
Changes:
1) Added the mode of automatic determination of the network address of the oscilloscope to the control utility + a pair of minor corrections.
2) Reordered catalogs with examples, deleted extra and duplicate files
3) Several mathematical functions have been added to the library.
-
Konnor,
Is it also possible to develop a plugin and take the full memory dump of the unit without using a JTAG adaptor and extract the private keys to unlock the MSO versions?
-
For a simple copying of the RAM to disk, a plugin is not required. You can just save it using the utility. The speed of copying is several hundred kilobytes per second.
-
For a simple copying of the RAM to disk, a plugin is not required. You can just save it using the utility. The speed of copying is several hundred kilobytes per second.
I'd appreciate if you explain the process with more details, which utility (dumb question perhaps)?
-
In the archive of plugins there is a directory of rigolif.
Please see file save_fw_4K.bat
Change the starting address and size to the ones you need and run.
The utility works only with patched firmware.
If you have any problems - write to me.
-
In the archive of plugins there is a directory of rigolif.
Please see file save_fw_4K.bat
Change the starting address and size to the ones you need and run.
The utility works only with patched firmware.
If you have any problems - write to me.
I saw the .bat file and if my assumption is correct, the scope has to be connected with USB to a Windows machine. right?
-
No. Ethernet only.
-
No. Ethernet only.
it gives me this:
C:\rigol-plugins\rigolif>.\debug\rigolif.exe r -i 192.168.1.104 -ffw.bin -l0xCA
83A -a0x40000000
The application has failed to start because its side-by-side configuration is in
correct. Please see the application event log or use the command-line sxstrace.e
xe tool for more detail.
-
No. Ethernet only.
it gives me this:
C:\rigol-plugins\rigolif>.\debug\rigolif.exe r -i 192.168.1.104 -ffw.bin -l0xCA
83A -a0x40000000
The application has failed to start because its side-by-side configuration is in
correct. Please see the application event log or use the command-line sxstrace.e
xe tool for more detail.
Which run time do I need? Visual C++ 2010 Redistributable Package (x64)?
Edit: I checked and I had 2008, 2010 and 2015 run-time packages.
-
The utility rebuileded without using dll. Please download the archive again and try.
-
The utility rebuileded without using dll. Please download the archive again and try.
DONE! Thanks a lot man,
-
I think we need to get some (in very clear English) instructions on exactly what the process for producing new firmwares is, what the risks are, what kind of upgrade/downgrades back to normal firmware can be done, etc. This all needs to be laid out very clearly and carefully so that this most common and sensible of questions can be comprehensively answered and updated in one place.
I'm sure the source code (or binaries) that we all develop will get fragmented, but this information should be basically the same forever.
-
I also wondered if I could request some simple features to add.
The first one is from this thread (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg1137136/#msg1137136). I wonder if you guys can figure out how to add some of these "double press" actions to buttons (in particular, the Measure and Acquire buttons. And maybe the Trigger button.
The only other thing I've always wanted (other than various optimization) is the ability to input a constant into the MATH and/or FX functions. Just a constant, I don't want to even evaluate functions. This way I could do something like divide a voltage by a known resistance to get a current result. Currently, other than doing this by hand, the only way I know to do it is to input the desired constant from a e.g. power supply or a function generator.
In the next week or so I think I'll give this a try, assuming I understand the risks. I only have the one scope, so...
-
Someone could setup a Github project. It would organize everything.
-
Update plugin.
Changes:
1) Added the mode of automatic determination of the network address of the oscilloscope to the control utility + a pair of minor corrections.
2) Reordered catalogs with examples, deleted extra and duplicate files
3) Several mathematical functions have been added to the library.
Are those changes effect the .GEL file you published earlier? Sorry for asking, but I am a complete idiot regarding software, so it is hard to understand what all those files mean and do.
-
Update plugin.
Changes:
1) Added the mode of automatic determination of the network address of the oscilloscope to the control utility + a pair of minor corrections.
2) Reordered catalogs with examples, deleted extra and duplicate files
3) Several mathematical functions have been added to the library.
Are those changes effect the .GEL file you published earlier? Sorry for asking, but I am a complete idiot regarding software, so it is hard to understand what all those files mean and do.
No these files are the plug-ins you can upload to the scope using rigolif.exe utility. in the plugins folder there are a few .bat file as example to show you how to run the plugins on the scope to do weird and wonderful stuff.
-
Are those changes effect the .GEL file you published earlier?
Corrections concern only the library. There are no new versions of the gel file, only from 31.03.2018.
-
Thank you both for explaining!
-
Mixed hardware/software info
Used interfaces:
I2C_0: I2C nvram, 800h bytes (o-scope settings)
UART_0: keyboard/LED
SPI_0: 8 bit bus xilinx<->cpu
SPI_2: contol bus (multiple chip select)
CS0: SPI NVRAM (loader + calibrate ("/sys/CalData.bin") + copy "/sys/OptionData.bin" + copy "/sys/OptionPara.bin" + other)
CS1: actel (cpld). Commands (two byte):
1,x - Select device for CS2
x:
0 - ADF4360 (3 byte/packet)
1 - ADC Controll (3 byte/packet)
2 - AD5207 x 2 (3 byte/packet, 20 bit)
3 - frontend control (4 byte/packet)
4 - Load Xilinx firmware
6 - Load Altera firmware + DG settings load
7 - ?? (total offilne?)
5,x -> ADC control (02 - reset bit, 01 - ? bit)
6,0 -> 2 byte answer, second - low part of MB version
7,0 -> 2 byte answer, second - high part of MB version
8,0 -> 2 byte answer, low tetrade of second - CPLD version.
B,x -> Load Xilinx control (answer - status bits)
D,x -> Load Altera/DG control
command B,D:
x=0 - reset
x=1 - no reset, start loading
CS2: common stream (see actel command 01)
Front End Control 4 channel, 4 x SN74AHC595 (HA595):
0x01 - DC coupling (0 - AC), cosmo rele
0x02 - attenuator rele
0x04 - bandwidth bit 1
0x08 - bandwidth bit 2
0x10 - ?? (used only as 0x10000000)
0x20 - vertical offset bit 1
0x40 - Amp. select
0x80 - vertical offset bit 2
Separate Bit:
0x10000000 - ? HC4053 on CH4?
Calibrate cirquit(?):
dac860+HC4051 - control from xilinx registers C2/C3 (dac serial + mux)
DMA Channels:
0 - SPI_0
4 - NAND FLASH
CPU pin settings (pin no - as in datasheet):
Pin 1, SSP2_MOSI pin function selection: BANK2_PIN17 00= ssp2_cmd;
Pin 2, SSP0_DATA2 pin function selection: BANK2_PIN02 00= ssp0_d2;
Pin 4, SSP2_SS0 pin function selection: BANK2_PIN19 00= ssp2_d3; (SPI2/CS0?)
two var:
Pin 6, SSP0_DATA6 pin function selection: BANK2_PIN06, 11= GPIO. (SPI)
Pin 6, SSP0_DATA6 pin function selection: BANK2_PIN06 00= ssp0_d6;
Pin 7, SSP2_SS1 pin function selection: BANK2_PIN20 00= ssp2_d4; (SPI2/CS1?)
Pin 8, SAIF1_SDATA0 pin function selection: BANK3_PIN26 11= GPIO. (some gpio interrupt)
Pin 18, SSP2_SS2 pin function selection: BANK2_PIN21 00= ssp2_d5; (SPI2/CS2?)
Pin 26, AUART2_TX pin function selection:BANK3_PIN09 11= GPIO (USB-Device)
Pin 27, ENET0_RX_EN pin function selection: BANK4_PIN02 00= enet0_rx_en
Pin 29, ENET0_TX_EN pin function selection: BANK4_PIN06 00= enet0_tx_en
Pin 30, AUART0_RX pin function selection:BANK3_PIN00 00= auart0_rx;
Pin 34, SAIF0_LRCLK pin function selection: BANK3_PIN2111= GPIO. (some for FPGA)
Pin 35, ENET0_TXD1 pin function selection: BANK4_PIN08 00= enet0_txd1;
Pin 37, ENET0_TXD0 pin function selection: BANK4_PIN07 00= enet0_txd0;
Pin 38, AUART0_TX pin function selection: BANK3_PIN01 00= auart0_tx;
Pin 39, ENET0_MDIO pin function selection:BANK4_PIN01 00= enet0_mdio
Pin 45, ENET0_RXD0 pin function selection: BANK4_PIN03 00= enet0_rxd0;
Pin 47, ENET0_RXD1 pin function selection: BANK4_PIN04 00= enet0_rxd1;
Pin 54, ENET0_MDC pin function selection BANK4_PIN00 00= enet0_mdc
Pin 66, AUART0_RTS pin function selection: BANK3_PIN03 00= auart0_rts;
Pin 68, PWM2 pin function selection: BANK3_PIN18 11= GPIO (DG detect ?)
Pin 70, AUART0_CTS pin function selection: BANK3_PIN02 00= auart0_cts
Pin 81, AUART1_RX pin function selection: BANK3_PIN04 11= GPIO. (PXP)
Pin 82, AUART3_RTS pin function selection: BANK3_PIN15 00= auart3_rts;
Pin 84, PWM1 pin function selection:BANK3_PIN17 00= pwm_1; (beeper)
Pin 86, AUART3_TX pin function selection: BANK3_PIN13 00= auart3_tx;
Pin 90, AUART3_CTS pin function selection: BANK3_PIN14 00= auart3_cts;
Pin 98, AUART3_RX pin function selection:BANK3_PIN12 00= auart3_rx;
Pin 268, SSP0_SCK pin function selection: BANK2_PIN10 00= ssp0_sck;
Pin 270, SSP0_DATA0 pin function selection: BANK2_PIN00 00= ssp0_d0;
Pin 272, I2C0_SCL pin function selection: BANK3_PIN24 00= i2c0_scl;
Pin 274, SSP0_DATA3 pin function selection: BANK2_PIN03 00= ssp0_d3;
Pin 275, SSP0_DETECT pin function selection: BANK2_PIN09 00= ssp0_card_detect;
Pin 276, SSP0_CMD pin function selection: BANK2_PIN08 00= ssp0_cmd;
Pin 278, SSP0_DATA4 pin function selection: BANK2_PIN04 00= ssp0_d4;
Pin 280, SSP2_SCK pin function selection: BANK2_PIN16 00= ssp2_sck;
Pin 281, I2C0_SDA pin function selection: BANK3_PIN25 00= i2c0_sda;
Pin 282, SSP0_DATA7 pin function selection: BANK2_PIN07 00= ssp0_d7;
Pin 284, SSP0_DATA5 pin function selection: BANK2_PIN05 00= ssp0_d5;
Pin 288, SSP2_MISO pin function selection: BANK2_PIN18 00= ssp2_d0;
Pin 289, SSP0_DATA1 pin function selection: BANK2_PIN01 00= ssp0_d1;
Variables:
00007FF4 - dword flag "disable load settings"
00007FF8 - firmware version from loader
00007FFC - boot version
SPI NVAM MAP:
00000-70000: Bootloader
70000-76000: Unused ?
76000-76008: LA/DG Calibr (?)
78000-79800: /sys/OptionData.bin
79800-7A000: /sys/OptionPara.bin
7A000-7C000: /sys/_SYS_REG_CFG_0417.cfg
7E000-7F800: /sys/CalData.bin
7F800-80000: part of /sys/CalData.bin
-
3) rnage -> rnage (decoder: conf: range
I can not locate this text error in my rigol dz1054z, nor does that option?
-
offset 0x202D00 in APP.out
This is an undocumented SCPI command.
-
ok, esntonce is a mistake that can not be seen in the oscilloscope, I mean it is not in the menus of the team, as was the case of PLUSES, by pulses
-
Changes:
1) Add new plugin (plugin_backup, ld_backup.bat). It saves the contents of two nvram (i2c + spi W25X40) and several files from the system partition to USB flash. The result can be used for recovery of the device or for some ;) operations with keys. It is highly desirable to use an empty usb flash or (at least) not having a lot of files or directories.
2) changes in rigolif. I analyse network exchange by wireshark, and found strange behavior: with some slight probability (<0.01%), the oscilloscope does not forward the response udp-block to the host computer. When host issue a second request, rigol immediate send back two blocks - the old one and the new one. Now the utility has a mechanism that takes into account this behavior and does not bother the user with error messages.
3) Update list of functions, some bat files for control fron-end, etc
-
There is many FunctionNames resolved :-+
But... too many... for me. I can't fit them into IDA as my decompiled app doesn't have many of them
in such places. It says: can't rename, because this byte can't have a name (it is a tail byte).
What program do you use or how do I get different decompilation?
-
Changes:
1) Add new plugin (plugin_backup, ld_backup.bat). It saves the contents of two nvram (i2c + spi W25X40) and several files from the system partition to USB flash. The result can be used for recovery of the device or for some ;) operations with keys. It is highly desirable to use an empty usb flush or (at least) not having a lot of files or directories.
I had starting doing one but you beat me up to it... :)
Please add also the copying of the GEL file in the NAND, since it may/usually contain the bootloader. That makes available the GELs with bootloaders that are not public.
Excellent work!
Everyone can brick their devices now... :) The only thing missing is a tutorial to start from scratch with a full-erased device.
-
It says: can't rename, because this byte can't have a name (it is a tail byte).
What program do you use or how do I get different decompilation?
I'm using IDA.
It is possible that if there are examples, it would be easier for me to understand the problem.
-
Please add also the copying of the GEL file in the NAND, since it may/usually contain the bootloader. That makes available the GELs with bootloaders that are not public.
This does not make sense, since the bootloader must be in spi-nvram (the processor is loaded from there). You just need to cut off the tail of the DS1KZ_NVRAM.BIN.
Everyone can brick their devices now... :) The only thing missing is a tutorial to start from scratch with a full-erased device.
It's simple ;D
1) Open device
2) Write a file DS1KZ_NVRAM.BIN to W25X40 (by jtag, by external programmer or any other method)
3) Insert USB Flash with gel and power on
-
It says: can't rename, because this byte can't have a name (it is a tail byte).
What program do you use or how do I get different decompilation?
I'm using IDA.
It is possible that if there are examples, it would be easier for me to understand the problem.
I open SparrowApp file in IDA, I don't choose any settings and it does his magic. Now there is
all functions and disassembly in Ida View-A.
I take your Func_full.lst and make idc file from it with replace command in notepad. There is:
40000010 _task_block
400000e0 _sched_run_internal
400000f0 _CHECK_RUN_SCHEDULER
...
I replace (.*) (.*) with MakeName(0x\1, "\2" ); and get:
MakeName(0x40000010, "_task_block");
MakeName(0x400000e0, "_sched_run_internal");
MakeName(0x400000f0, "_CHECK_RUN_SCHEDULER");
...
After that I remove all with no names so I get 6480 functions at this time
in Func_full.idc file. Now I open it: File -> Script file... and most of the functions are renamed.
But I have different disassembly view and at all addresses are not functions... in 207 places.
-
The problem is that before the MakeName command it is necessary to remove the arrays, that were created incorrectly.
In addition, you can use the MakeCode / MakeFunction functions.
-
This does not make sense, since the bootloader must be in spi-nvram (the processor is loaded from there). You just need to cut off the tail of the DS1KZ_NVRAM.BIN.
I know that the "booting" bootloader is in the SPI-NVRAM. But why cut and insert a bootloader in a GEL if I can get the full assembled GEL straight from the NAND with the bootloader inside...
Most of the files that you chose to copy from /SYS/ were also extractable from the DS1KZ_NVRAM.BIN.
-
You can't.
In W25X40 is bootloader at the beginning. It is there until you use GEL update with bootloader.
So far there is only one public version with 0.0.1.0 - Sparrow(Boot)update_00.04.00.00.00
Until you don't do bootloader update you can get old bootloader from eeprom.
Now the NAND is 128MB. One part is 90,5MB Local DISK and another is 37,5MB /SYS (I think)?
In SYS are DS1000ZUpdate.GEL, all files from GEL except bootloader and some system files
as are visible on pictures before where we made that SuperSecretRigolFlash.
Now you need konnor's patched firmware for his plugins. What happens if you update GEL? :)
-
You can't.
In W25X40 is bootloader at the beginning. It is there until you use GEL update with bootloader.
So far there is only one public version with 0.0.1.0 - Sparrow(Boot)update_00.04.00.00.00
Until you don't do bootloader update you can get old bootloader from eeprom.
Now the NAND is 128MB. One part is 90,5MB Local DISK and another is 37,5MB /SYS (I think)?
In SYS are DS1000ZUpdate.GEL, all files from GEL except bootloader and some system files
as are visible on pictures before where we made that SuperSecretRigolFlash.
Now you need konnor's patched firmware for his plugins. What happens if you update GEL? :)
Didn't quite understand but...
I thought about it and, if a guy has konnor's GEL patched, then he won't have "an original" GEL with possible bootloader.
So, because of this reason, with this method it's irrelevant the GEL download. Only a external download could solve it.
We'll have to go by with NVRAM extraction.
So when anyone extracts NVRAMs with bootloaders 1.1 or 1.3 please post them.
-
It is not difficult for me to make a copy of the gel file (attached).
But I do not understand how it can be applied. If the oscilloscope has an original gel, the plugin can not be loaded. If patched, then why read it back from the oscilloscope? Just download from the first page of this topic. ;)
-
It is not difficult for me to make a copy of the gel file (attached).
But I do not understand how it can be applied. If the oscilloscope has an original gel, the plugin can not be loaded. If patched, then why read it back from the oscilloscope? Just download from the first page of this topic. ;)
I concluded that the GEL with your patch is not what I wanted (see my previous msg). But, BTW, the file that you attached can't be a GEL or it's a top-secret format.
-
I saw the message:
Please add also the copying of the GEL file in the NAND, since it may/usually contain the bootloader. That makes available the GELs with bootloaders that are not public.
I tried to explain that this function does not make sense.
But to me it's more difficult to argue than compiling a plugin with copying a gel file from nand. So I added the requested function, rebuild plugin and attach special version of the plugin to the attachment.
-
You can't.
In W25X40 is bootloader at the beginning. It is there until you use GEL update with bootloader.
So far there is only one public version with 0.0.1.0 - Sparrow(Boot)update_00.04.00.00.00
Until you don't do bootloader update you can get old bootloader from eeprom.
Now the NAND is 128MB. One part is 90,5MB Local DISK and another is 37,5MB /SYS (I think)?
In SYS are DS1000ZUpdate.GEL, all files from GEL except bootloader and some system files
as are visible on pictures before where we made that SuperSecretRigolFlash.
Now you need konnor's patched firmware for his plugins. What happens if you update GEL? :)
I continue from here...
What happens if you update GEL? You need to update it to have patched APP in scope to use
konnor's plugins for making backups for example. But then you overwrite DS1000ZUpdate.GEL
and all extracted files from it. There is no more stock GEL to backup. Even if you make GEL from
one file (SparrowApp), like I did, you overwrite old GEL. You can see it on /SYS directory image.
Mine is only 1.0 M long. So you have there GEL you just uploaded...
But, can be new bootloader made? It's booting and there is menu which you select with knob.
In the menu are SparrowApp, custom app (with plugins), Tetris, Snake, DOOM (I saw somewhere
Linux version)...
-
Hi Konnor et al.,
Sorry for necrobumping, but this seems the appropriate thread.
The custom firmware and plugin system looks really awesome.
Only downside to me seems that you still need to open up the oscilloscope and overwrite the firmware, in order to be able to use plugins.
I have long been thinking if it would be possible to exploit some part of the USB stack in the scope, to be able to create a plugin system.
That way it would be possible to load code into the RAM and execute this. This could contain a small loader which allows custom plugins, or even jumping to a Linux bootloader, or launching my port of DOOM for the Rigol :)
Do any of you have readable IDA disassemblies of the firmware, and an idea how the USB code works?
We could start looking for vulnerabilities in the USB stack to exploit these.
-
Only downside to me seems that you still need to open up the oscilloscope and overwrite the firmware, in order to be able to use plugins.
What do you mean "open up"? You don't need to open it in order to patch the FW.
User rhb is also investigating in the "booting from USB" area.
-
:popcorn:
-
Hello!
This is my 1st post, hope I am not intruding on this thread…
Does any of you have a list of all the SCPI commands the DS1000Z recognizes?
And I don't mean the programmer's guide, I mean from the disassembled firmware.
Because I noticed that some stuff is missing or undocumented:
#1 - Setting up USB file formats and triggering save (DS4000E series has :SAVE Commands). I guess Rigol left this out for some "protecting the upper price segment" reasons.
Maybe there is something the manual doesn't tell us…
#2 - The :LAN Commands (from the DS4000E manual) are such a case - they work fine on my DS1054Z, but the manual does not mention them.
-
Does any of you have a list of all the SCPI commands the DS1000Z recognizes?
And I don't mean the programmer's guide, I mean from the disassembled firmware.
Very useful, thank you.
I would like to send Beep/Bell and custom text messages using SCPI commands. Couldn't find any commands to do that. For a short beep (keypress beep style), it is possible to send a ':SYST:BEEP 1' as a workaround.
Is there any way to send a long beep (Error style beep)?
Is there any way to put a custom text message to the oscilloscope's screen, or at least to send a custom message ('Parameter Limited!' style)?
-
Thanks a lot!
Look at all those hidden gems!
PS - is there a way to pass a string for the text input fields like the filename?
-
Many thanks, Peter!
BTW, you must be the record holder in the "thank you's per post" ratio in this forum:
https://www.eevblog.com/forum/profile/?u=1913 (https://www.eevblog.com/forum/profile/?u=1913) :-+
-
a small question,
is the custom firmware still lagging behind the last release from Rigol, or was it re-based and updated?
-
Here I uploaded it, it's that of the janekivi friend,last version, I had it downloaded.https://mega.nz/#!dFZAHQoK!T-I56b2R3sNJmvYrswF6zMD9ewUzs3Xt-aTfK_BoVss
-
that does not answer the question,
which is newer, the Rigol one or the patched one??
-
Any chance there is also a set of images from the firmware?
-
Here I uploaded it, it's that of the janekivi friend,last version, I had it downloaded.https://mega.nz/#!dFZAHQoK!T-I56b2R3sNJmvYrswF6zMD9ewUzs3Xt-aTfK_BoVss
So is this the patched firmware that works with konnor plugins? Or does this just have the typo "Pluses" fixed? Cause the plugins don't seem to work with this firmware
-
this just have the typo "Pluses" fixed
-
this just have the typo "Pluses" fixed
Looking at the HELP pages, it seems that there is a LOT of REALLY wrong Engrish in this scope :-)
Also missing or double spaces, wrong prepositions, etc.
Any plans to fix those in the alternative firmware?
I can document them while I move along with my project…
-
Well, the first step to bring this project up a notch would be proper documentation. This is a really interesting and useful topic, that many could join in to make serious progress and squeze even more value from this scope. But the documentation is terrible, you have to dig through a lot of old posts scattered in this forum just to start to understand how it works and (maybe) how to do it yourself. Some stuff isn't even documented (atleast I did not find it). I believe that the developement should continue in github. That way we would be able to directly support this amazing project.
-
Hi,
@konnor, and all other people interested:
I have ported the "rigolif" application to Linux, you can find it here:
https://github.com/maximevince/rigolif
It might work on other POSIX OSes as well, like Mac OSX, although I haven't tried.
I tested dumping memory and uploading plugins, and that seems to work fine!
@konnor:
I haven't found a license that you have released rigolif under (and the other code); so I hope you are fine with this.
Would you be OK releasing this under GPLv2 or v3?
-
Hi,
My DS1104ZPlus is at version 00.04.04.03.05
When I try to use the patched fw (from first post) there is a warning on instrument's screen that an older software version is detected and it reports it as 00.04.04.03.02
On similar occasion, when I try to downgrade from the current version (00.04.04.03.05) to the official Rigol 00.04.04.03.02 the downgrade failed so I did not even try to downgrade to the patched fw.
It looks to me that if you have higher version than the initially provided patched fw from @konnor you cannot proceed, is that correct?
Is there any chance that @konnor can provide a new version (00.04.04.03.05) patched fw ?
Thanks.
-
plugin_sw - Start War melody plugin.
Does this plugin start a war or should it be Star Wars melody? ;D
-
At least it did not start a war over here ;)
Just FYI,
I have also created a demo "plugin" that can be compiled with GCC:
https://github.com/maximevince/rigolif/tree/master/plugin
You need an ARM-capable GCC,
such as the official arm-gcc-embedded: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
-
It looks to me that if you have higher version than the initially provided patched fw from @konnor you cannot proceed, is that correct?
Is there any chance that @konnor can provide a new version (00.04.04.03.05) patched fw ?
Correct.
Ask @konnor. Only him can answer.
In the meantime, you may try to contact janekivi and he might have time to release a downgradable 00.04.04.03.02.
-
Does anyone have the sources of Rigol Packer? Or know if they are open?
I'd like to have a look at the code, and make some additions to the software,
such as the ability to remove files from the .GEL image, and port it to Linux (using Mono, so .NET code can still be used).
-
[Supported Model] All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date] 2019/02/26
[Updated Contents]
--------------------
v00.04.04.04.02 2018/02/26 [editor note: <-- typo by Rigol, means 2019]
- Add new encoder drivers
[History]
-------------
v00.04.04.03.05 2018/04/28
- Fixed the login bug of lxi-web
- Fixed the bug of average measure
- Fixed the bug of information display
cheers
/j
-
[Supported Model] All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date] 2019/02/26
[Updated Contents]
--------------------
v00.04.04.04.02 2018/02/26 [editor note: <-- typo by Rigol, means 2019]
- Add new encoder drivers
Hello joerg_rw:
When you installed Firmware (FW) 00.04.04.04.02 did this fix the spelling of Pulses on the bottom of the screen (when Pulses is selected, for displaying the Quantity of the displayed Pulses)? I'm asking because several months ago I installed the konnor/janekivi FW fix to correct the Pulses spelling. I believe it was spelled Pluses before when shown on the bottom of the display. I'm asking because after I installed FW 00.04.04.04.02 Pulses is still spelled correctly. So I don't know if Rigol corrected this in the the latest FW, or if it was some embedded holdover from my previously installing the konnor/janekivi FW Fix.
-
Pulses / Pluses is fixed in the latest official firmware release.
-
Pulses / Pluses is fixed in the latest official firmware release.
Thank you for this information. This is good news, and what I hoped the answer would be.
Cheers. . .
Edit: I was initially concerned that I might have a issue updating to this new FW after reading the above about the 'konnor and/or janekivi' FW fix to correct the spelling of 'Pulses'. Anyway no problem here, and it installed smoothly.
-
Hi all!
Sorry to be a pain, but I've tried installing the Rigol firmware from konnor to enable plugins on my MSO1074Z, but after copying the firmware, the scope starts analyzing it and then reports that the firmware update failed. I've tried several times, re-extracting the .GEL file and re-copying it to the USB stick, but they all fail. I also tried downloading the file where pluses was corrected to pulses from Adrian_Arg.'s post, but it also fails to update.
I am running the current RIGOL firmware, 00.04.04. SP4.
Does anyone have any suggestions as to what else I could try to get the plugin firmware update to work? Any help would be most appreciated!
-
it is intended for the DS, not the MSO - maybe that's the issue.
-
I think it's because you can't downgrade FW, without a custom version or the USB vendor disk. But everyone could patch the FW as explained in a thread in this forum, to enable downgrade.
-
Hello
ds1054z has been hacked and many parts of its hardware is known
Then i have question
Somwhere on board there should be output of sampling time-base does maybe somebody knows where ? :)
-
Hello,
Can anyone tell me how to pack a .GEL file? I allready unpacked. I need a .GEL file with the software version grater than 00.06.01.00.00 because I accidentally upgraded the wrong firmware to the device. It was the firmware of DS1202Z-E and now I lost 2 of the 4 channels.
It will be realy nice to have them back
-
Can anyone tell me how to pack a .GEL file? I allready unpacked. I need a .GEL file with the software version grater than 00.06.01.00.00 because I accidentally upgraded the wrong firmware to the device. It was the firmware of DS1202Z-E and now I lost 2 of the 4 channels.
I have to say that that was a good (and unfortunate) experience! :(
But I think it's Rigol fault and they should solve the problem for you!
WARNING TO EVERYONE: first DS1000Z-E FW seems to have a configuration that allows it to be flashed in the old DS1000Z.
If you want to solve it by yourself, you have 2 options:
- get yourself a Rigol USB vendor disk (and use it to reflash a lower version) - search the forum
- patch the version number in the FW - this thread (https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/150/) has all the information to do it
For your reference here is the parsing of the latest FW:
00000000 - File Type: DS1000Z
00000010 - Software Branch/Version: 00.04.04.04.03
00000020 - Bitmask: 00000700
00000024 - # Sections: 10
Offset Section Name SectiSz StartAdr CRC32 Type
00000028 /sys/SparrowAPP.out 00109340 00000280 203F016D 00000001 [00000280-001095BF] CRC OK
00000064 /sys/SparrowFPGA.hex 000C4372 001095C0 46CBF128 00000005 [001095C0-001CD931] CRC OK
000000A0 /sys/SparrowDGFPGA.hex 00046F04 001CD932 3AE21D6F 00000006 [001CD932-00214835] CRC OK
000000DC /sys/logo.hex 000BB818 00214836 E734AC4C 0000000A [00214836-002D004D] CRC OK
00000118 /sys/guiResData.hex 000B6B34 002D004E 43E52B67 0000000C [002D004E-00386B81] CRC OK
00000154 /sys/guiPicData.hex 0001E6BF 00386B82 B53EE36C 00000011 [00386B82-003A5240] CRC OK
00000190 /sys/SparrowConfig.hex 000BB818 003A5241 F1C962B8 00000010 [003A5241-00460A58] CRC OK
000001CC /sys/SparrowWaveTable.hex 000020E8 00460A59 416BFB7A 0000000B [00460A59-00462B40] CRC OK
00000208 /sys/SparrowCalFile.hex 00022EFD 00462B41 0FB592A3 0000000F [00462B41-00485A3D] CRC OK
00000244 00000118 00485A3E 00000000 00000032 [00485A3E-00485B55]
Offset CRC32 Flags Filesize Endianes Branch/Version
00000280 84C41652 00000003 00109328 AA5555AA 00.04.04.04.03 [00000298-001095BF] CRC OK
001095C0 A006D034 00000000 000C435A AA5555AA 00.04.04.04.03 [001095D8-001CD931] CRC OK
001CD932 138E13B9 00000000 00046EEC AA5555AA 00.04.04.04.03 [001CD94A-00214835] CRC OK
00214836 9B4EA177 00000000 000BB800 AA5555AA 00.04.04.04.03 [0021484E-002D004D] CRC OK
002D004E 271E3AB5 00000000 000B6B1C AA5555AA 00.04.04.04.03 [002D0066-00386B81] CRC OK
00386B82 01873014 00000001 0001E6A7 AA5555AA 00.04.04.04.03 [00386B9A-003A5240] CRC OK
003A5241 5DEF7058 00000000 000BB800 AA5555AA 00.04.04.04.03 [003A5259-00460A58] CRC OK
00460A59 27F4C06F 00000000 000020D0 AA5555AA 00.04.04.04.03 [00460A71-00462B40] CRC OK
00462B41 1E61A8F6 00000000 00022EE5 AA5555AA 00.04.04.04.03 [00462B59-00485A3D] CRC OK
File Processed OK
-
Would this method work with an DS1074Z Plus or in this model the only viable method would be the JTAG dumping?
-
Hello!
Sorry, I don't know if I chose the right topic, but I need help or advice.
When updating the firmware on the Rigol DS1102Z-E, the power was accidentally lost. Now, after turning on, the RIGOL splash screen appears, the button backlights turn on one by one, but then everything stops. How can I resurrect the oscilloscope, what should I do?
-
I solved the problem thanks to this post - https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg3608676/#msg3608676 (https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg3608676/#msg3608676)
Everything has been restored to its best.
Thanks to the forum. :)