LIB_USB_ERROR_BUSY

[Sébastien Saury]

Hi Chris,

Finally got round to playing with fpga-link on aes220 board.

However when running a simple flcli command (which I think should just download the firmware into the fx2, but I could be wrong) I get a LIBUSB_ERROR_BUSY error.

Here is the terminal input command followed by the output:

sebastien@chronos:/media/Data/Workspace/libfpgalink-20130321/lin.x64$ rel/flcli -i 04b4:8613 -v 1d50:602b
Attempting to open connection to FPGALink device 1d50:602b...
Loading firmware into 04b4:8613...
flLoadStandardFirmware(): usbOpenDevice(): LIBUSB_ERROR_BUSY

Any idea what could be causing the error?

I know the command is a bit useless on its own (not programming the FPGA) but I thought I would give it a try before trying to compile an example for the aes220.

Incidentally why does the program first attempt to open device 1d50:602b when the command line implication is that it should first open device 04b4:8613 and then programming it with the id 1d50:602b?
Am I misreading the command or is it in case the user runs it twice in a row?

Finally, I could not find the documentation pointed out in the readme file: VHDL Paper Edition: http://www.swaton.ukfsn.org/bin/fpgalink-20130321/vhdl_paper.pdf so I assume it is still work in progress.

Cheers,

Sébastien

[Chris McClelland]

Hi Sébastien,

That error is caused by something else in the system having claimed that
device. Likely candidates are:

A) Virtualisation software (e.g VMware, VirtualBox, Parallels etc). A
device is not available to the host OS because it has been claimed by
the virtualisation software on behalf of a running guest OS.

B) In the case of 04B4:8613 and Linux, there is a kernel module
"usbtest.ko" which is built into many distributions' stock kernels. You
can test this by connecting the device, then doing sudo rmmod usbtest,
and then immediately after that, the flcli line. If that does fix it you
may want to blacklist the usbtest.ko module on your system by making a
file "/etc/modprobe.d/blacklist-custom.conf" containing "blacklist
usbtest". Following that you might get away with "sudo udev restart" and
reconnecting the device; if that fails try rebooting.

C) Something else? The aes220 programmer perhaps?

The flcli behaviour you describe is (honest!) by design; it allows you
to type the same command whether or not a firmware load is necessary.
The algorithm is basically "if you *can* connect to 1d50:602b right
away, go ahead; else try loading firmware first and then trying
1d50:602b again.

I have not yet updated the docs with the slave-serial and selectmap
programming methods. You can look at the manual from the last
"production" release[1], but obviously the programming-related sections
will not match. There is a walk-through of programming an aes220[3] and
various notes about the 20130321 alpha release (including notes about
slave-serial and selectmap) on the announcement email[2].

The SDRAM readback demo I wrote is now available on GitHub with aes220
board files; I will make a walkthrough of that for you later today.

Any other problems, please let me know!

Chris

[1] http://www.swaton.ukfsn.org/docs/fpgalink/vhdl_paper.pdf
[2] https://groups.google.com/group/fpgalink-users/msg/29144e1578ad636b
[3] http://pastebin.com/raw.php?i=jXDe8DgQ

> --
> You received this message because you are subscribed to the "FPGALink
> Users" mailgroup (see
> http://www.makestuff.eu/wordpress/software/fpgalink/).
>
> To post to this group, send email to fpgalin...@googlegroups.com
> To unsubscribe from this group, send email to
> fpgalink-user...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/fpgalink-users?hl=en
>
> ---
> You received this message because you are subscribed to the Google
> Groups "FPGALink Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fpgalink-user...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[S S]

Hi Chris,

Thanks for the prompt reply. I kept looking at the fpga-link page and didn't notice it until now. I probably need new glasses...

B) did the trick and I was able to program the FPGA.

That prompted me to look at the differences between the way you open a usb device (in usbwrap) and the way it is done in the code I use (aesUSB.cpp) since we are both using libusb.
The main difference I can see is that between opening the device and claiming the interface I check the kernel driver is free with libusb_kernel_driver_active(dev_handle, 0) and if it is active I detach it with libusb_detach_kernel_driver(dev_handle, 0). Maybe that could explain the conflict with usbtest which I am not experiencing (other than when running fpga-link)?

Note that I say I but I really got the code from Dennis: http://allmybrain.com/2009/04/14/fx2-cystream-throughput-test-with-sdcc-and-fx2lib/ who did the translation (at least the one that I know of) of the FX2 to SDCC: https://github.com/mulicheng/fx2lib

I really look forward to the walkthrough of SDRAM example!

Cheers,

Sébastien

> Subject: Re: [fpgalink-users] LIB_USB_ERROR_BUSY
> From: fpgal...@m3.ath.cx
> To: fpgalin...@googlegroups.com
> Date: Mon, 15 Apr 2013 17:31:47 +0100

[Chris McClelland]

Thanks for the libusb_detach_kernel_driver() hint: I expect it will
definitely be useful.

Here is the SDRAM walkthrough:

http://pastebin.com/raw.php?i=QWx16srC

It works, but there is still something not quite right with it. There's
a bug which can cause writes to column address 0xFF to be ignored. It's
intermittent in the sense that it appears when changing timing
constraints in supposedly-innocuous ways (e.g making timings tighter).
In the end I gave up fiddling with the constraints and put it on my
"list of strange things worthy of investigation" pile, but the code in
GitHub should work on your aes220 boards.

I have a question for you: the pull-down on M2 on my aes220 appears to
be 8.2K, which is not strong enough to give the M[2:0]=011 necessary to
boot into Internal Master SPI config mode on power-on, so it's necessary
for the FX2 firmware to manually kick-start the FPGA's self-config (a
feature which doesn't yet exist in the FPGALink firmware). Is this
FX2-kickstart the correct approach for all production boards?

Chris

[S S]

Thanks for all that Chris.

If you replace R17 8.2k by a 820 ohms resistor you should be OK.
The resistor is not loaded on the production boards and the M[2:0] pins are controlled by the FX2 as you rightly point out. I think I did that so as to have the option of not having the FPGA automatically booting at power up.

Cheers,

Sébastien

> Subject: RE: [fpgalink-users] LIB_USB_ERROR_BUSY
> From: fpgal...@m3.ath.cx
> To: fpgalin...@googlegroups.com
> Date: Mon, 15 Apr 2013 22:18:57 +0100

[Peter Stuge]

Chris McClelland wrote:
> Thanks for the libusb_detach_kernel_driver() hint: I expect it will
> definitely be useful.

It's basically not portable beyond Linux, because that's the only
system that allows applications to poke around in the kernel driver
stack with such ease.

OS X and Windows both require significantly more intrusive actions to
cover the general case, so the function doesn't really work there. :\

BSD might require a kernel recompile.


//Peter

[S S]

It doesn't seem to do any harm there though (there being Windows). At least none that I have noticed so far. Maybe you can confirm that Peter as you are the person to ask about these things.

Cheers,

Sébastien

> Date: Tue, 16 Apr 2013 22:42:43 +0200
> From: pe...@stuge.se
> To: fpgalin...@googlegroups.com
> Subject: Re: [fpgalink-users] LIB_USB_ERROR_BUSY

[Peter Stuge]

(Please remember to always inline-post with trimmed quoting. Thanks!)

S S wrote:
> > > Thanks for the libusb_detach_kernel_driver() hint: I expect it will
> > > definitely be useful.
> >
> > It's basically not portable beyond Linux, because that's the only
>

> It doesn't seem to do any harm there though (there being Windows).

Yep! It does neither good nor harm - it simply does nothing. ;)


//Peter

[Chris McClelland]

Sébastien,

OK I tried holding a temporary 3.3K resistor in parallel with the
existing 8.2K to ground, and with that the FPGA boots just fine. The
existing 8.2K looks like an 0603 or even smaller package though, so I
doubt many users will want to try that approach.

Rather than spend time thinking about how to configure the firmware
startup in a general way for cases like this, I decided to just treat it
as a special case requiring a custom firmware build, like this:

http://pastebin.com/raw.php?i=4RYUY6Ad

Here I'm fetching the firmware code, adding an actual implementation for
the FPGA bootstrap, and building it into a .hex file for loading into
EEPROM. I tested this approach and it too works fine.

Also I've put together an FPGALink-based SPI tool, for talking to
config-flash, SD-cards and the like:

https://github.com/makestuff/spi_talk
https://github.com/makestuff/spi_master

There's also a rough proof-of-concept SD-card block reader ("sdread")
and an aes220 SPI-flash programmer ("flashprog") in there, but neither
are very generic yet.

Chris

[Peter Stuge]

Chris McClelland wrote:
> Also I've put together an FPGALink-based SPI tool, for talking to
> config-flash, SD-cards and the like:
>
> https://github.com/makestuff/spi_talk
> https://github.com/makestuff/spi_master
>
> There's also a rough proof-of-concept SD-card block reader ("sdread")
> and an aes220 SPI-flash programmer ("flashprog") in there, but neither
> are very generic yet.

Don't spend too much time on that wheel. Instead, add an FPGALink
programmer driver to flashrom, which by now supports a vast number of
flash chips.

http://www.flashrom.org/

Let me know if any patch you send seems to have gotten stuck.


//Peter

[S S]

Hi Chris,

Sorry for the late reply, I didn't notice your own reply and was a bit puzzled by peter's one as it didn't appear to relate to the conversation. I'll blame hotmail new interface for that although I should really ask myself some questions...

3.3k on top of 8.2k gives you 2.5k which is still slightly on the high side as Xilinx recommends something <1.1k. But then if it works it works. The pulldowns on the M[2:0] pins were there as contingency, not really for the user to play with so I didn't really mind them being small (they are 0402 in fact).

Thanks for writing a solution especially for the aes220 and sorry it had to come down to that.

The FPGALink-based SPI tool looks good. It would make sense for me to re-write the way the micro-controller talks to the SPI flash on similar lines. I had developed the solution currently implemented before I had a library in the same vein as the FPGALink one in terms of pipe and channels.

Haven't had a chance to look at the SDRAM example yet. Was distracted by other issues but hopefully they are now resolved and I'll be able to try it next.

Cheers,

Sébastien

> Subject: RE: [fpgalink-users] LIB_USB_ERROR_BUSY
> From: fpgal...@m3.ath.cx
> To: fpgalin...@googlegroups.com

> Date: Wed, 17 Apr 2013 23:12:23 +0100

[Chris McClelland]

> The FPGALink-based SPI tool looks good. It would make sense for me
> to re-write the way the micro-controller talks to the SPI flash on
> similar lines.
>

Just in case it's not obvious, I am very happy for you to make direct or
indirect use any code I publish, even though you're using it for
commercial purposes. No, *especially* because you're using it for
commercial purposes. If you wish to maintain separate implementations
for your own reasons, that's fine, but don't feel you *need* to on my
account.

> ...was a bit puzzled by peter's one as it didn't appear to relate
> to the conversation.
>
Actually Peter's response was very relevant. It *is* foolish for us to
reimplement umpteen SPI-flash programming algorithms for different chips
if a wide range of chips are already supported by the flashrom.org
project. I only wish flashrom was more modular: a no-dependency
shared-lib offering something like this would be good:

ProgStatus doProgram(
const struct spi_programmer *prog, // interface to the SPI[1]
const struct flashchip *chip, // description of the chip[2]
const uint8 *data,
uint32 length);

Throw in a function to query the JEDEC ID:

const struct flashchip *doQuery(
const struct spi_programmer *prog // interface to the SPI[1]
)

That ensures the clever stuff can be re-used without polluting it with
back-end dependencies (libftdi, libusb, libpci etc).

Chris

[1]http://tracker.coreboot.org/trac/flashrom/browser/trunk/programmer.h#L530
[2]http://tracker.coreboot.org/trac/flashrom/browser/trunk/flash.h#L112

[S S]

Hi Chris,

Thanks for making the code available for commercial purposes too that is very helpful.

I'll certainly look at using as much of the code from FPGALink as possible, I would rather concentrate on designing new boards than reinventing code that is already available. Among the reasons for having the code for the board open source was that people could contribute to it. I didn't expect it to work the other way round, that is having code already out there that would work on the board.

Anyhow, I have code which I need to support as it is being used by my customers so I cannot turn round and tell them they have to re-write it because my interface is no longer supported. I am quite happy to promote FPGALink to new customers and give them choice though.

Yes Peter reply is relevant and I need to have more than a quick look at what he has done but before I can promote something I need to be sure I can support it as at the moment it looks a bit complex to me, but feel free to prove me wrong!

Cheers,

Sébastien

> Subject: RE: [fpgalink-users] LIB_USB_ERROR_BUSY
> From: fpgal...@m3.ath.cx
> To: fpgalin...@googlegroups.com

> Date: Sat, 20 Apr 2013 17:59:34 +0100

[Bob Willis]

The blacklist procedure was necessary to prevent LIBERROR_USB_ERROR problems that I had using Pidora 18 on a Raspberry Pi.
Bob