A few days ago, we discussed the possibility of detecting, at the
time the "standby" bitstream executes, whether the FPGA had just
cold-booted (power-on reset) or whether it had done a reset under
software control.
I suggested the BOOTSTS register in the "boot thingy" (the - as
far as I know - unnamed entity in the FPGA that takes care of
loading bitstreams and configuring the rest of the FPGA) may hold
such information.
I've now examined it a bit further and found that it doesn't work
this way, but has other uses.
Background: when the FPGA configures ("resets"), it can try to
load the bitstream from a number of sources. The results of the
load attempts are recorded in the BOOTSTS register.
This register is described on pages 100 and 127 of
http://www.xilinx.com/support/documentation/user_guides/ug380.pdf
One interesting difference between the two descriptions is that
table 7-2 on page 127 mentions an IPROG bit whereas table 5-48 on
page 100 calls it "RESERVED". The revision history on page 3
further explains that table 5-48 was changed to "Reserved" with
version 2.0.
My conjecture was that - if implemented - the IPROG bit would be
set on a "soft" reboot while it would be clear after a power-on
reset.
I wrote a little script to query BOOTSTS over JTAG:
http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1rc3/norruption/2/bootsts
Findings:
1) after a successful configuration, no matter whether I loaded
the "standby" bitstram or the "soc" bitstream, BOOTSTS was
0x0001.
2) if I changed the standby bitstream in NOR such that it had a
CRC error and the M1 thus didn't boot, BOOTSTS was 0.
3) no matter what I did, I never saw any of the IPROG/reserved
bits set.
4) after reading BOOTSTS via JTAG, attempts to reconfigure under
software control, i.e., booting out of standby with the middle
button or a "power off" from Flickernoise would freeze the M1.
It would still respond to forced reconfiguration over JTAG,
e.g., with
http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/jtag-boot
1) and 2) mean that I can use BOOTSTS for my NOR corruption
experiments to test whether corruption has occurred. I'm putting
this to use in a new script that also automates forensics and
recovery.
Unfortuantely, 3) means that BOOTSTS does not help with our
search for a way to determine how the M1 booted.
4) is a little fly in the ointment but of no practical
consequence for the uses described above. It may not be a
limitation of the FPGA itself but a bug in how UrJTAG implements
some of the "pld" commands.
- Werner
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
