| Products > Test Equipment |
| Rigol DSXXXX .GEL firmware file format |
| << < (33/38) > >> |
| tv84:
--- Quote from: janekivi on April 12, 2018, 09:27:37 pm ---Files itself coming after header with their own 24 byte headers. File headers first 4 bytes is file CRC32 in little endian. Next 4 bytes are info about compression. This is probably in hex format and also bitmask. 03 00 00 00 (bitmask 0011) - if there is LZMA packed app 01 00 00 00 (bitmask 0001) - if there is LZMA packed gui data 00 00 00 00 (bitmask 0000) - if there is plain file Next 4 bytes are file length in little endian. Next 4 bytes are AA 55 55 AA - unknown. Next 4 bytes are software version in little endian like 6E A6 3D 00 = 4040302. Next 4 bytes are software branch 00 00 00 00. tv84 explanation --- End quote --- An addon to the explanation of these last 8 bytes: The model's version (as placed in the GEL's header) is: 00.04.04.03.02 the RED is the software branch the BLUE is the version number In the region of the 24-bytes headers, quoted above, the last 8 bytes are: 4 bytes are software version in little endian like 6E A6 3D 00 = 04.04.03.02 4 bytes are software branch 00 00 00 00 = 00 If we look at the whole 8 bytes in little-endian the (4 bytes) branch comes before the (4 bytes) version. This is important because when we want to upload a "temporary version" (like the one in the attached picture), one must change these "branch" bytes of the SparrowAPP file. An "official version" appears when there is a previous "temporary version" installed in the scope, and we change the branch to 00. |
| janekivi:
--- Quote from: tv84 on April 19, 2018, 08:31:56 am --- --- Quote from: Shock on April 18, 2018, 09:53:10 pm ---0.04.04.03.02 2017/02/06 almost suggests it might have the file as the release notes mentioned a bootloader fix, but it's not listed in the header. Have you checked that version? --- End quote --- As you can see in my parsing file DS1000_parsing_v2.txt, in previous msgs, the only 04.04.03.02 that is publicly available doesn't have a bootloader. But, someone who has a factory 4.4.3.2 might have a bootloader in it's NAND. So, if they could extract it or from NVRAM... Then I would assume 4.4.1.1 is 1.3 and the 4.4.3.2 has a 1.4. Needs to be checked by you guys. --- End quote --- In 00.04.00.00.00 is bootloader 0.0.1.0. I got mine from factory with 0.0.1.2 and have extracted it from memory here. From NAND I extracted this 00.04.04.01.01 where was bootloader 0.0.1.4. Now you need to find out how this is stored there because I can't find it by debuging... |
| konnor:
LOAD:41047414 MainProcess ; DATA XREF: LOAD:MQX_template_listo LOAD:41047414 STMFD SP!, {R12,LR} LOAD:41047418 MOV R0, BootVersion LOAD:41047420 MOV R1, 0x10010 LOAD:41047428 STR R1, [R0] |
| Shock:
According to Rigol, these three firmware had associated bootloader: 00.04.00.00.00 0.0.1.0 released on 20140318 00.04.01.02.00 0.0.1.1 released on 20140728 00.04.02.03.00 0.0.1.2 released on 20141021 Then there was: 00.04.02.04.07 0.0.1.? released on 20141231 My scope (build date 2015/03) came with: 00.04.03.00.01 0.0.1.3 released on 20150505 |
| janekivi:
--- Quote from: konnor on April 21, 2018, 01:36:21 pm ---LOAD:41047414 MainProcess ; DATA XREF: LOAD:MQX_template_listo LOAD:41047414 STMFD SP!, {R12,LR} LOAD:41047418 MOV R0, BootVersion LOAD:41047420 MOV R1, 0x10010 LOAD:41047428 STR R1, [R0] --- End quote --- So bootloader is writing it into memory? I see app is reading it from somewhere. Where the version is hidden in bootloader? |
| Navigation |
| Message Index |
| Next page |
| Previous page |