[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2015 03:03:34 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: ztex 1.15y boards, pre-development
On Mon, Jul 27, 2015 at 02:54:14AM +0300, Aleksey Cherepanov wrote:
> On Sun, Jul 26, 2015 at 11:58:47PM +0300, Aleksey Cherepanov wrote:
> > On Sun, Jul 26, 2015 at 08:51:42PM +0200, Katja Malvoni wrote:
> > > On 26 July 2015 at 20:12, Aleksey Cherepanov <lyosha@...nwall.com> wrote:
> > > >
> > > > But for me, it segfaulted first several runs and then it fails on every
> > > > run:
> > > >
> > > > S[0][0] = 0xd1310ba6 0xd131f12c <<< failure
> > > > S[0][1] = 0x98dfb5ac 0x98dfb5ac ok
> > > > S[0][2] = 0x2ffd72db 0x2ffd72db ok
> > > > S[0][3] = 0xd01adfb7 0xd01adfb7 ok
> > > > S[0][4] = 0xb8e1afed 0xb8e1afed ok
> > > > S[0][5] = 0x6a267e96 0x6a267e96 ok
> > > > S[0][6] = 0xba7c9045 0xba7c9045 ok
> > > > S[0][7] = 0xf12c7f99 0xf12c7f99 ok
> > > >
> > >
> > > Hm... this looks like first word written by FPGA is the last one from the
> > > previous read/write cycle (0xf12c). And it's not the same problem as I get
> > > on my board :(
>
> It seems I solved this problem: s/512/1024/ for reading
> // read string back from ucecho device
> - i = usb_bulk_read(handle, 2, (char *)(received), 512, 1000);
> + i = usb_bulk_read(handle, 2, (char *)(received), 1024, 1000);
>
> I guess you need a buffer of respective size, not just 8 uints.
>
> - unsigned int received[8] = {0};
> + unsigned int received[0x100] = {0};
>
> 1024 is quite strange for me: we need 8*4 bytes of data, why do we
> need to read 1024 bytes to get them?
Actually it reads 34 bytes back. I can't reproduce relation between
512 vs 1024 and good vs bad behaviour.
> BTW if I upload bitstream before firmware, I get
> Error sending data: No error
>
> > I think I can reproduce your problem too: I changed integers
> >
> > sent[2] += 9;
> >
> > I tried various timings, including pause between write and read: it
> > takes 5 runs to get new value back. (It does not affect the first
> > word.)
> >
> > So first 4 runs of 5 give:
> >
> > S[0][0] = 0xd1310ba6 0xd131f12c <<< failure
> > S[0][1] = 0x98dfb5ac 0x98dfb5ac ok
> > S[0][2] = 0x2ffd72e3 0x2ffd72e4 <<< failure
> > S[0][3] = 0xd01adfb7 0xd01adfb7 ok
> > [...]
> >
> > then there is only the first failure.
>
> 4 runs lag remains.
I think, I got how to bypass it: read 5 times and skip results from
first 4 times. Also there is a difference: with wrong data I got 32
bytes back, while good data come in 34 bytes "packet".
I tried up to 20 reads, only fifth seem to be right.
Thanks!
--
Regards,
Aleksey Cherepanov
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
