Products > Test Equipment

Siglent .ads firmware file format

<< < (16/85) > >>

tv84:
janeviki,

Looking at SDS1000X_V100R001B01D02P1503.ADS:


--- Code: ---01  0000002C --- 2.1.1.9   [000000C4-000DED94]
      000000C4 - Checksum: FFBDDCC9
      000000C8 - Name: 2.1.1.8
      000000C8 - Section Data [000000C8-000DED94]  CKSM OK
02  0000003B --- 20170310  [000DED95-0024A9E3]
      000DED95 - Header Size: 00000048
      000DEDDD - Data Size: 0016BC07
03  0000004A --- 0208 310  [0024A9E4-00276BF3]
      0024A9E4 - Header Size: 00000048
      0024AA2C - Data Size: 0002C1C8
04  00000059 --- 20170207  [00276BF4-002E84BE]
      00276BF4 - Header Size: 00000048
      00276C3C - Data Size: 00071883
05  00000068 --- 1.1.2.15  [002E84BF-00417E4E]
002E84BF - Removing block encapsulations from Block Area [002E84BF-00417E4E]

Total bytes extracted (from the blocks): 000FB396    Block area processed OK

Buffer Size: 00006374 bytes (after converting: 8bit-dma-from-16bit)

Processor Type: BF54x - BF542/BF544/BF547/BF548/BF549
Orig Offset     Offset          Block Code      Target Add      Byte Count      Argument        BFlags
00000000        00000000        AD9F5002        FFA00000        00000000        0000635C        ignore first
00000020        00000010        ADC50102        FF800000        00000014        00000000        fill
00000040        00000020        ADD90102        FF800014        0000001C        00000000        fill
00000060        00000030        ADC80002        FF800030        00000028        00000000
000000D0        00000068        ADA90102        FF800058        00000020        00000000        fill
000000F0        00000078        AD200002        FF800078        00002CA4        00000000
00005A58        00002D2C        ADC50102        FF802D1C        00000124        00000000        fill
00005A78        00002D3C        ADD60002        FFA00000        00003610        00000000
0000C6B8        0000635C        ADF80802        FFA00000        00000000        00000000        init

0000C6D8 --- ZLIB Decompressed Size: 00287728
0000C6E0 --- ZLIB Compressed Block Size: 000EECAE [0000C6E8-000FB395]
****************************************************
  Section Processed OK
06  00000077 ---
07  00000086 --- 3.1.1.13  [00417E4F-00497E4D]
      00417E4F - ?????: 0000DCBB
      00417E53 - Data Size: 0006B930
      00417E57 - Name: 3.1.1.13 ???
      00417E63 - Section Data [00417E63-00483792]
08  00000095 ---
--- End code ---

alfishe:

--- Quote from: janekivi on June 01, 2017, 02:57:38 pm ---...but normal UBI-reader is hard to find.
Couple of times I was successful with ubidump but now I use something with Ubuntu.

--- End quote ---

Found the only thing that work flawlessly - https://github.com/jrspruitt/ubi_reader
so was able to unpack every single UBI file from Siglent FWs.

janekivi:
https://github.com/jrspruitt/ubi_reader
Yes, I think this is the one I'm using with Ubuntu now but can't get it working in windows under the python there.
__________________________________________________________________________________________

But now that BlackFin stuff is bit strange to me, I don't know much about it.
I lost track from there:

--- Code: ---Buffer Size: 00006374 bytes (after converting 16bit to 8bit)

Processor Type: BF54x - BF542/BF544/BF547/BF548/BF549
Offset          Block Code      Address         Byte Count      Argument
00000000        AD9F5002

--- End code ---
So I can't see this stuff right now. In other words, I don't have a clue about this BlackFin part.
Eeee... what you do there?

But seems in SDS header the file version numbers can have different lengths. All this is
like there is written something in the header. May be file names and some data. And then
all is overwritten with file versions which is number or date plus one 00 byte.
Bit strange it looks. For example
03  0000004A --- 0208 310 looks like there was
XXXXXXXX.bin which is overwritten with shorter XXXXX310 and 00 buffer byte
XXXXX310 bin which is now overwritten with shorter 0208 and 00 buffer byte
0208 310 bin
so all file versions are probably numbers to the first 00 byte and the rest is leftover crap.
One strong feeling there is like -  to grow header the whole previous row is added again
and overwritten with correct info, next row is made from this and overwritten and empty
lines are skipped so part 7 has part 5 background there. This is leftover 3 after 00 buffer.

And now there is actually
05  00000068 --- 1.1.2.15  [002E84BF-00417E4E]
05  00000068 --- 1.1.2.15.3  [002E84BF-00417E4E]
because it is V1.1.1.2.15R3

In header first file version showing 2.1.1.9 and first part is beginning with CRC and 2.1.1.8

tv84:
I changed the code that I had submitted. See the previous post again.

After removing the blocks, you have to convert the section that exists before the ZLIB block from 16 bit to 8 bit.

Then that area will have the Blackfin code that decompresses the ZLIB.

The code has:

                  16-byte block headers

The 1st 4 bytes:
                    0xXX------ - 1st byte -> Header Sign (Magic) - Must be 0xAD ("Analog Devices")
                    0x--XX---- - 2nd byte -> Header Checksum (calculated with 0 in this byte)
                    0x----XXX- - 3rd & 4th bytes -> Block flag (excluding the last nibble)
                    0x-------X - Last nibble -> DMA Code (0x00 -> 0x0F)

The others you can deduce from my parsing in the previous post.


--- Code: ---string[] DMA_code = {"dma-reserved" , "8bit-dma-from-8bit", "8bit-dma-from-16bit", "8bit-dma-from-32bit",
                "8bit-dma-from-64bit", "8bit-dma-from-128bit", "16bit-dma-from-16bit", "16bit-dma-from-32bit",
                "16bit-dma-from-64bit", "16bit-dma-from-128bit", "32bit-dma-from-32bit", "32bit-dma-from-64bit",
                "32bit-dma-from-128bit", "64bit-dma-from-64bit", "64bit-dma-from-128bit", "128bit-dma-from-128bit" };
           
string[] bflag = { "safe", "aux", "", "", "fill", "quickboot", "callback", "init", "ignore", "indirect", "first", "final" };
--- End code ---

As you can see I've discovered where my mistake was. Because I was convinced that the Section 5 was only a Blackfin code block but I discovered that I had missed the ZLIB block. Then, the decompressed size and bytes remaining made sense. It's the same thing in the SDG1000 files.

tv84:
SDS1000X_V100R001B01D02P1503.ADS saved as a 8-bit BMP starting at offset 0x27 (to align the blocks) (cropped in length).

It's visible in Section 2 a curious data arrangement (blocks of 64*21 bytes plus 64*9 bytes (whiter...))

I assume it is the Xilinx FPGA since the Section starts with the FFFF FFFF area and the FPGA bitstream SYNCWORD (AA 99 55 66) re-mixed.

(If we save the file with width=320, the block encapsulation of Section 5 is perfectly visible.)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod