Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 14 Nov 2016 07:27:58 +0000 (UTC)
From:  <>
To: "" <>
Subject: Re: USB-FPGA development


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)
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 <> 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.


Powered by blists - more mailing lists

Your e-mail address:

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