Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 27 Jul 2011 18:20:40 +0400
From: Solar Designer <>
Subject: Re: Yuri's Status Report - #11 of 15

Hi Yuri -

On Tue, Jul 26, 2011 at 04:37:24PM -0300, Yuri Gonzaga wrote:
>    - Accomplishments
>       - David has set a remote machine with a M501 board. It is working
>       fine!
>       - Helloworld example run properly both by "purty" (using ssh -X) and
>       "PicoBus128_Helloworld.cpp"
>       - Eksblowfish loop verilog was adapted to PicoBus128, including some
>       simulation
>       - Modification to JtR code to communicate with a single loop core.

Sounds good.  I don't know what you mean by "purty", though.

> In this point, I need some help.
> I changed the JtR's Makefile to include the search path
> "$PICOBASE/software/include" in CFLAGS variable.

Do you mean you used the "-I" option to list that include directory?

> Moreover, I run make on folder $PICOBASE/software/pico_drv and copied pico.o
> to JtR's source folder.
> So, I included the pico.o to JOHN_OBJS variable in JtR's Makefile.
> Apparently, it compiled well, but returned the following error message:
> > make[1]: *** No rule to make target `BF_std.o', needed by `../run/john'.
> >  Stop.
> > make[1]: Leaving directory `/home/yuri/john-1.7.8/src'
> > make: *** [linux-x86-64] Error 2
> How is the best way to tell make where to find Pico includes and compiled
> library for PicoDrv?

As David wrote, you need object files built from
$PICOBASE/software/source, not $PICOBASE/software/pico_drv.  Yes, you'd
include them in JOHN_OBJS.  For the header files, I suggest that rather
than use -I... in CFLAGS, you simply place the directory at a specific
relative path to your JtR tree, then use directives like:

#include "../pico/whateverfile.h"

in your interfacing code in the JtR source tree.

As to the specific build error you mention above, this means that you
made an error in editing the Makefile.  I can't guess what exact error
you made.  You might want to run "diff -u" on the original and your
edited Makefile and post this "patch" - then I'd be able to comment.

>    - Verilog for multiple cores manager (not finished)
>    - Priorities
>       - Correct JtR's makefile to compile and link properly
>          - It will be useful both to one as multiple cores
>       - Test JtR's on M501 for single core
>       - Finish verilog for Manager of multiple cores
>       - Integrate to Alexander's patch for JtR multiple cores
>       - Test JtR's on M501 for multiple cores

You really should _start_ by integrating the patch I provided, even when
interfacing to just one core.  You'd simply set BF_N to 1 initially, or
you'd interface to your one core from a loop with a higher BF_N - this is
up to you.  When you actually have multiple cores, you'd simply make
sure to have BF_N set to higher than 1 and you'd adjust the interfacing
loop accordingly.

With one core, the loop may be like:

	for_each_index() {
		send_to_fpga(BF_current INDEX, salt, BF_exp_key);
		read_from_fpga(BF_current INDEX);

When you revise the code for multiple cores and set BF_N to exactly
match the number of cores, the loop will be split in two:

		send_to_fpga(index, BF_current INDEX, salt, BF_exp_key);
	for_each_index() {
		read_from_fpga(index, BF_current INDEX);

Please don't hesitate to ask if anything is unclear.



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.