Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2015 02:54:14 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: ztex 1.15y boards, pre-development

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?


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.

Thanks!

-- 
Regards,
Aleksey Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ