So, the zynq.bit parsing is below:
00000000 - FFFFFFFF Padding
00000004 - FFFFFFFF Padding
00000008 - FFFFFFFF Padding
0000000C - FFFFFFFF Padding
00000010 - FFFFFFFF Padding
00000014 - FFFFFFFF Padding
00000018 - FFFFFFFF Padding
0000001C - FFFFFFFF Padding
00000020 - 000000BB Bus width auto detect, word 1
00000024 - 11220044 Bus width auto detect, word 2
00000028 - FFFFFFFF Padding
0000002C - FFFFFFFF Padding
00000030 - AA995566 Sync Word (BPI/SPI Mode)
00000034 - 20000000 T1 - 00000000 NOP (1x)
00000038 - 30022001 00000000 T1 W 00000001 TIMER
00000040 - 30020001 00000000 T1 W 00000001 WBSTAR
00000048 - 30008001 00000000 T1 W 00000001 CMD NULL - No Operation
00000050 - 20000000 T1 - 00000000 NOP (1x)
00000054 - 30008001 00000007 T1 W 00000001 CMD RCRC - Reset CRC
0000005C - 20000000 T1 - 00000000 NOP (2x)
00000064 - 30026001 00000000 T1 W 00000001 FALL_EDGE
0000006C - 30012001 02003FE5 T1 W 00000001 COR0
00000074 - 3001C001 00000000 T1 W 00000001 COR1
0000007C - 30018001 0373B093 T1 W 00000001 IDCODE
00000084 - 30008001 00000009 T1 W 00000001 CMD SWITCH - Switch CCLK Frequency
0000008C - 20000000 T1 - 00000000 NOP (1x)
00000090 - 3000C001 00000401 T1 W 00000001 MASK
00000098 - 3000A001 00000501 T1 W 00000001 CTL0
000000A0 - 3000C001 00000000 T1 W 00000001 MASK
000000A8 - 30030001 00000000 T1 W 00000001 CTL1
000000B0 - 20000000 T1 - 00000000 NOP (8x)
000000D0 - 30002001 00000000 T1 W 00000001 FAR
000000D8 - 30008001 00000001 T1 W 00000001 CMD WCFG - Write Config Data
000000E0 - 20000000 T1 - 00000000 NOP (1x)
000000E4 - 30004000 T1 W 00000000 FDRI
000000E8 - 500D621C T2 W 000D621C
00358964 - 20000000 T1 - 00000000 NOP (2x)
0035896C - 30008001 0000000A T1 W 00000001 CMD GRESTORE - Pulse GRESTORE Signal
00358974 - 20000000 T1 - 00000000 NOP (1x)
00358978 - 30008001 00000003 T1 W 00000001 CMD DGHIGH/LFRM - Last Frame Write
00358980 - 20000000 T1 - 00000000 NOP (100x)
00358B10 - 30008001 00000005 T1 W 00000001 CMD START - Begin Startup Sequence
00358B18 - 20000000 T1 - 00000000 NOP (1x)
00358B1C - 30002001 03BE0000 T1 W 00000001 FAR
00358B24 - 3000C001 00000501 T1 W 00000001 MASK
00358B2C - 3000A001 00000501 T1 W 00000001 CTL0
00358B34 - 30000001 E3AD7EA5 T1 W 00000001 CRC
00358B3C - 20000000 T1 - 00000000 NOP (2x)
00358B44 - 30008001 0000000D T1 W 00000001 CMD DESYNC - Reset DALIGN Signal
00358B4C - 20000000 T1 - 00000000 NOP (400x)
The IDCODE = 0373B093 corresponds to the Xilinx Zynq-7015. The same as in the DS7000.
The decrypted scripts (full) are attached.
The file /tmp/env.bin is protected by a CRC-32 (ISO-HDLC) in it's first 4 bytes. cfger tests this CRC before doing anything.
That's the same bit as from the MSO7000 thread right? Nice to have it all in one place
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/xsmiley.gif.pagespeed.ic.R8GFI-pF6f.png)
Not sure what I'm seeing in the zynq bit file, more curious as to whether its possible to do any partial reconfiguration. I know FPGA's support it, just need to know what's needed, as I desperately want to overwrite some bits (like the display unit).
As for the env.bin; a u-boot environment is a \n separated text file, usually with the .cmd extension. It's just a lit of environment variables per line. mkimage will turn this into a .bin file, where the \n's are more or less replaced with \0's and a header is prepended. Part of the header is indeed a checksum (Don't recall if the header is only the checksum).
Anyhow, they basically re-invented the wheel with their cfger, as the fw_printenv and fw_setenv tools do exactly this
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/xsmiley.gif.pagespeed.ic.R8GFI-pF6f.png)
I think fw_printenv can even do it directly on /dev/mtd0 rather then dumping it locally and modifying it locally. Besides, they should have kept the env in the spi flash; as having it on raw nand storage (as they do now) and writing it (hopefully only during updates) is error prone. Raw flash access (via write) is not wear-leveled, no bit correction preformed etc (but u-boot can't access it otherwise, well not their ancient u-boot version).