<wpwrak>
enjoys the lofty feeling of control when issuing labsw ch1=0 ch2=0 and labsw ch1=1 ch2=1 and watching the M1 power-cycle :)
<wpwrak>
lekernel: hmm, to write to that ICAP, should  pld writereg  do the trick ? it accepts all the things i sent it quite willingly, but doesn't boot
<lekernel>
(labsw) cool !!
<lekernel>
hm... maybe you need to write the bits in the opposite order (just guessing)
<lekernel>
invert the bits in each 16-bit word
<rejon>
wpwrak, that is awesome
<wpwrak>
scary :)
<lekernel>
also, power cycle before a new try, as you may have confused the configuration system
<wpwrak>
yeah, i just noticed that it wouldn't take a normal boot either
<lekernel>
btw, you are not using the ICAP through JTAG - the ICAP is only for FPGA designs who want to access the configuration system of the chip they're running on
<wpwrak>
ah, i see. well, the config-thingy then :)
<wpwrak>
flipped the data bits -> no luck; swapped the data bytes -> neither
<lekernel>
anyway, if JTAG becomes too annoying, it won't be too hard to modify the standby bitstream so it boots on any serial port activity
<wpwrak>
(init_b) isn't it held low until the config completes anyway ?
<wpwrak>
or it could just boot if the button is held, not just on an edge. that way, i could simply clamp it down :)
<lekernel>
what do you think of the "boot on serial activity" solution?
<lekernel>
it did that before, but the problem is that FN uses the same button to shut it down
<wpwrak>
it is galling that jtag wouldn't want to work, though
<wpwrak>
ah, crap
<wpwrak>
hmm, i could of course hack urtag to just emit the right sequence, without all the other noise around it
<lekernel>
"boot on serial activity" is ~3 lines of verilog, guaranteed to work, no need to install urjtag on the host machine
<lekernel>
and no more JTAG woes
<wpwrak>
lemme first try to hack urtag
<wpwrak>
you never know what surprising side effects the serial activity may produce :)
<wpwrak>
i actually like urtag. works very smoothly so far. at openmoko, we used openocd. the pain ...
<lekernel>
in the same vein, it should also boot on IR activity... but a bit more filtering would be needed there
<wpwrak>
or on USB activity ;-)
<wpwrak>
interesting. when i do the pld writereg sequence, it goes unconfigured immediately after the IPROG
<lekernel>
IPROG is actually supposed to clear configuration (and hopefully re-read it)
<wpwrak>
with my hacked urtag sequence, it stays configured (but doesn't boot either). only goes unconfigured when i try to send the sequence again. seems to be some urjtag-internal state, though
<wpwrak>
tricky stuff :)
<wpwrak>
i'll have my mornig coffee ... maybe some ideas will come
<lekernel>
weird
<lekernel>
let's just use the "boot on serial activity" solution then :-)
<wpwrak>
naw, i don't give up so easily. stubborn is my middle name :)
<lekernel>
yes, but pick your battles
<wpwrak>
i'll need jtag anyway. maybe not the config thingy, but a lot of the rest
<wpwrak>
aha .. the number of NOPs after the CMD write determines whether something happens or nor
<wpwrak>
my current theory is that there same bus is used when loading from NOR and when writing from JTAG. so if the configuration process gets kicked off while JTAG still scribbles things on the bus, there could be confusion
<lekernel>
so, what was the problem? the extra NOPs at the end?
<wpwrak>
basically replaces "pld reconfigure" with the prelude of a register write and ends it with part of the xlx_configure (load .bit file) sequence
<wpwrak>
i think some of the stuff in the write register sequence interrupt this. plus, you need to urj_tap_reset_bypass before flushing the chain. otherwise it doesn't work.
<wpwrak>
i should be able to make a .bit files that does all this without the need to hack urjtag
<wpwrak>
pity urjtag doesn't like .bin files ...
<wpwrak>
oh, and in the config user guide, they say that the CRC check at the end is a _command_ and optional ? that's what i call confidence ;-)
<lekernel>
yeah, urjtag needs a .bit header
<lekernel>
for pld load
<lekernel>
there's also an (undocumented) 24-bit frame CRC on spartan6
<lekernel>
which you can't disable (afaik)
<wpwrak>
(crc) ah, good. making the crc check basically disappear on failure seemed eerily tepco-ish
<lekernel>
well, i'm actually not totally sure how this works
<lekernel>
most isn't documented
<lekernel>
"just load the .bit file from ISE"
<wpwrak>
cf. "learned helplessness" :)
<lekernel>
by the way, do you know methods for guessing the CRC polynomial based on data and corresponding CRC values?
<wpwrak>
okay, bit stream seems to work too
<lekernel>
brute force?
<lekernel>
it's a 24-bit CRC, shouldn't take too long
<wpwrak>
pheew ... no, you can solve it analytically
<wpwrak>
i think
<wpwrak>
that's what makes LSFRs unsuitable for secure hashing
<lekernel>
another problem is if it's really a CRC or not...
<wpwrak>
(lsfrs unsuitable) i mean without adding a real crypto component. they can be used as part of a secure hash algorithm.
<wpwrak>
for an LFSR of length n, you need 2 n output bits from the generator to "break" it
<wpwrak>
now .. let's see if i can get some signs of life from the serial console ... nice, neocon works :)
<wpwrak>
and there's an "echo" command. very nice.
<wpwrak>
okay, my M1 is now being torture-tested :)
<xiangfu>
wpwrak, what is the 'boot.bit' doing?  I need under the mkboot#L14~23 .
<xiangfu>
seems it's very very simple .
<wpwrak>
xiangfu: it forces an M1 to load the "regular" bitstream, i.e., to boot into flickernoise
<wpwrak>
xiangfu: it does that from any state, as long as the M1 is supplied with power. in particular, this also works out of "standby". so you don't need to press any buttons after power-cycling
<xiangfu>
wpwrak, cool.
<xiangfu>
wpwrak, where I can learn more info about boot.bit ?