Pavel,
You are correct.
Performed a readback of the flashed EEPROM from both upload methods. The
resulting .mcs files were converted to binaries to remove the Intel hex
file formatting.
The cryptech_upload method writes header information that the xilinx
file ignores. Offsetting a compare for this shows the files match up to
0x4FFF26.
The xilinx file has additional 0xFF padding from 0x4FFF26 – 0x4FFF9E.
From 0x500001 on the files are once again identical.
On 05/10/2018 05:02 AM, Pavel Shatov wrote:
06.05.2018 3:37, Michael пишет:
So I updated ARM firmware. Now either method , Impact using .mcs PROM
file or cryptech_upload using the .bit file load the bitstream memory
with a file that operates the cores correctly. However I am still
unable to prove that both methods create the exact same image. To
double check against the checksum difference , I performed a readback
with both loading methods and there are significant differences. Is
the cryptech method performing some obfuscation method to prevent
reverse engineering?
I'm really stumped on how to prove the cryptech method for
programming the PROM matches the original .bit file.....
Hi, Michael,
the bitstream itself (partially documented in table 5-19 on page 104
in [1]) has the following structure:
1. FFFFFFFF repeated 8 times
2. 000000BB
3. 11220044
4. FFFFFFFF repeated 2 times
5. AA995566
6. ...
The .bit file has some additional information in the beginning
(filename, timestamp, etc), I've a attached a screenshot. When iMPACT
programs the configuration memory, it skips that garbage, the first
thing it writes is those 32 0xFF bytes. If you generate an .mcs file
out of a .bit file, you'll see that it starts with 0xFF bytes and that
additional data is not included, I've attached a screenshot too. MCS
format by the way is in fact Intel HEX, just named differently for
some reason.
Our script should do exactly what iMPACT does, i.e. strip that header
from the .bit file and start writing when it sees 32 0xFF bytes. Maybe
there's something like an off-by-one error in the script and it strips
more or less bytes than necessary. This will not prevent the FPGA from
successfully configuring itself, because when it starts reading the
PROM, it discards all the bytes until it sees the bus width autodetect
pattern (000000BB, 11220044). If that is actually the case, the
checksum will be different when programming with our script and with
iMPACT tool, but both methods should work.
Another thing to check is how we deal with the last chunk of the
bitstream. Configuration memory can only be programmed one page (256
bytes) at a time. It's unlikely that the bitstream length will be a
multiple of 256 bytes, so some padding must be done. As far as I know,
iMPACT pads the very last page with 0xFF bytes ("unprogrammed" memory
contains all 1's), I don't remember exactly how our script does the
padding, maybe it pads with 0x00. This will also lead to a different
checksum, but successful configuration, because the bitstream has a
special "desync" pattern in the end, that tells FPGA to stop reading,
so those padding bytes are in fact ignored.
I don't have my programmer at hand right now, so I can't reproduce the
issue. Should be able to do this on Monday.
One thing I can suggest is do a configuration memory readback from
iMPACT, this lets you save the actual contents of the PROM into an
.mcs file. Then you can compare that to an .mcs file you generated
using iMPACT to find the difference. Note that the readback operation
reads entire memory and produces a larger file with a lot of 0xFF
bytes in the end from the unprogrammed pages, they should be ignored.
I think it's good that you noticed the issue. I believe that's more of
a cosmetic off-by-one or padding thing, but I mean if it's
straightforward to fix, why not fix it?
[1]
https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
