<tnt>
kc8apf: I don't think it's a CRC. I think it's something simpler.
<tnt>
I have 2 dumps, one valid and one where I suspect there is a small corruption. The only idfference in the data is the serial number of the board and the checksum values are very close to each other.
<whitequark>
kc8apf: ooooh that's super neat
<whitequark>
I looked for a tool like that but never found any
<kc8apf>
Sum every byte and truncate result to desired width was pretty common for a while
<tnt>
kc8apf: yeah, must be something like that because doing it for both the good and what I think is a 'fixed' bad image (i.e. the bad image where I fixed the byte which I think is wrong), and including the checksum, the sum comes up to the same value ... but it's not 0xffff or 0x0000 or anything 'recognizable'.
<tnt>
but still it'd be weird if this was just a coincidence.
<whitequark>
it could be an arbitrary value, like a "crc residue"
<gruetzkopf>
neat
<gruetzkopf>
this will be quite useful to me once i get a certain bus sniffer working
<tnt>
whitequark: yup, that's what I'm guessing. So I will flash my "hopefully fixed" eeprom image and see if that works out.
<tnt>
but I need to finish writing microwise and 93xx support first.
pie__ has quit [Ping timeout: 252 seconds]
<tnt>
So in migen is x[0] the MSB or LSB ?
<whitequark>
tnt: like in Python, so LSB
<tnt>
whitequark: Ok, thanks.
<tnt>
whitequark: I'm reading the spi master code atm and more specifically the clkgen part and something is bothering me
<tnt>
The whole state machine can get held up if for some reason the fifo (in/out) are not ready. Which makes sense. However AFAICT the SCK edge won't be paused and will still happen ...
<tnt>
I must be missing something.
<whitequark>
tnt: without looking again at the code: it is 100% possible that the SPI master applet is buggy.
<whitequark>
in fact, rewriting it in a more principled way has been on my TODO list for a while.
<whitequark>
mostly so that it can support IOB registers..