[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 27 Jul 2011 18:20:40 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com
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);
wait_for_fpga();
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:
for_each_index()
send_to_fpga(index, BF_current INDEX, salt, BF_exp_key);
for_each_index() {
wait_for_fpga(index);
read_from_fpga(index, BF_current INDEX);
}
Please don't hesitate to ask if anything is unclear.
Thanks,
Alexander
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.
