[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <759195123.3517136.1479108478182@mail.yahoo.com>
Date: Mon, 14 Nov 2016 07:27:58 +0000 (UTC)
From: <apingis@...nwall.net>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: Re: USB-FPGA development
Hi,
Thank you all for the testing. I appreciate feedback and suggestions. Some issues, including severe ones, emerged after testing on more boards.
The major issue is: on some boards bitstream upload fails.
Actually bitstream upload consists of two steps: 1)upload and 2)check if bitstream operates.
1) - The following error:
"SN XXXXXXXXXX: uploading bitstreams.. SN XXXXXXXXXX: usb_bulk_write returns -1 (LIBUSB_ERROR_IO)
failed"
means general USB I/O error while upload. That can be faulty hardware, cable, etc. (You often get same error when you unplug or power-off the board while upload). On such error please try uploading bitstream using FWLoader from Ztex SDK - repeat 10 times or so to see it problem persists.
Usage: java -cp [<path to>]FWLoader.jar FWLoader [-sf <fpga_id:0-3>] -uf <jtr_dir>/run/ztex/ztex115y_descrypt.bit
2) - The other error:
"SN XXXXXXXXXX: uploading bitstreams.. ok
SN XXXXXXXXXX: device_list_check_bitstreams(): no bitstream or wrong type"
means upload was done but subsequent check results in error.
It looks like there's some issue with Low-speed communication interface (the one that's via usb_control_messages, endpoint 0 and MCU). That's used to check if bitstream operates.There's not very well written asynchronous circuitry there in HDL unit I was going to rewrite.
In such case could you please use FWLoader to upload bitstream on all 4 FPGAs and then run JtR several times. That would help to narrow down the problem.
On Monday, November 7, 2016 7:57 PM, atom <atom@...hcat.net> wrote:
> 1. I have three boards, but they all had some custom firmware installed, one that wasn't "USB-FPGA Module 1.15y (default)". The following line in ztex_scan.c will fail:
> else if (!strncmp("USB-FPGA Module 1.15y (default)", dev->product_string, 31)) {
> The user will end up with an error "no valid ZTEX devices found" and JtR will quit. I've recompiled ZTEX_DEBUG with ZTEX_DEBUG=1, then it will print the current firmware name on the board. I used that name to replace string in the comparison above, then it worked. I think you need to find a different solution to that, if not simply ignore the firmware running and simply overwrite it.
When I was implementing that, I thought if a board has 3rd party firmware then the user intentionally dedicated the board to some other application. BTC miners (at least those I did take a look at) often allow the user to select what devices to use, never write firmware into EEPROM. I guessed the user typically would write custom firmware into EEPROM (using Ztex SDK) to reduce power-up time or/and to simplify running from command-line. Anyway this is a good question what would be the best for JtR to do in such case. "Greedy behavior" to use all boards regardless of what's installed - looks an easy solution but what if somebody runs several applications? For now, I'm going to introduce an informational message when there're boards with 3rd party firmware.
Denis
Content of type "text/html" skipped
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.
