How to specify which FPGA module to use

[asbridge]

Ulf,

Sorry to be a bother.

I now have two SlotScreamers in my system. Both programmed, both showing up.

How do I specify which of the two to use on the command line?

Here they are physically:

lsusb |grep 601f
Bus 002 Device 005: ID 0403:601f Future Technology Devices International, Ltd
Bus 001 Device 003: ID 0403:601f Future Technology Devices International, Ltd

lspci |grep -i xi
0e:00.0 Ethernet controller: Xilinx Corporation Device 0666 (rev 02)
19:00.0 Ethernet controller: Xilinx Corporation Device 0666 (rev 02)

I guess I'm asking for the syntax for the -device flag. I've browsed your forum but haven't hit on it yet.

Thanks again,
Vince

[ufrisk]

The short answer is that there is no such functionality, you'll either have to patch it in the code yourself or physically unplug the USB as-is right now.

The long answer: What is your use case here? If the use-case is to run multiple analysis software in parallel it's possible to do this against one single FPGA as long as each instance is running in a separate process. You can set up a "LeechAgent" (part of the LeechCore project. Multiple clients (up to 10 each time) may then connect to this LeechAgent over the network (or locally to localhost). Expect somewhat higher latency though, especially if the FPGA is busy. The LeechAgent is Windows only though.

I have some thoughts about parallelizing the LeechCore library and also to allow multiple devices at the same time, but it's not very high on my todo-list. For now the easiest would be to use the LeechAgent on WIndows, or patch the code to your needs.

[asbridge]

My goal is to send a message TLP from one PCIe device to another.
As a means of debug I thought the easiest way to test this would be to put two FPGA modules in my system and put one in "wait for TLP" mode and the other in "send TLP mode"

I think I can get the same functionality with two hosts configured like this:

host1 <-> usb <-> pciescreamer1 <-> pciescreamer2 <-> usb <-> host2

I don't need multiple instances on the same machine, only for this test case.

Thanks for all your help,
Vince

[asbridge]

Ulf,

My two system trick is not going to work because you expect to see the USB and the PCIe on the same system. I did not expect this to be the case.

Is there any way to have the code listen on one side (-tlpwait) without having the PCIe connection to the FPGA card (listen on the PCIe bus of system 1, send discovered TLPs to the USB of system 2)?

If not, going back to your "you'll either have to patch it in the code yourself", is this a simple thing or am I looking at a major change? Have you ever thought about connecting to two devices one for write and one for read?

Hate to come this far and hit a wall.

I am not a code expert or driver expert, but we have two driver guys who could handle this if the architecture allows.

Thanks,
Vince

[ufrisk]

if it were just about selecting which device to use of the two devices it's relatively easy. You'll need to change this line of code into something like this (to open by serial number):

// Open a device with serial number "000000000001"
status = ctx->dev.pfnFT_Create("000000000001", 1, &ctx->dev.hFTDI);

It would be a relatively minor thing for me to add support for this.

I however believe your main limitation is that the LeechCore library currently only supports one connection at a time - i.e. max one memory acquisition source per process. I have thought about changing it for other purposes, but it's a major update and there are quite some work involved so by looking at my calendar it's a next year thing, most likely it will slide into March since I have some conference talks in February that will eat my time. I guess you could potentially do some really cool stuff with this though and I kind of need the rewrite anyway so it would be worth the effort.

If you somehow could communicate your received packets to another process (on the same system with the change to the code line) above or to another system this would work though. I suspect it would need to be quite high speed though if doing MiTM of legitimate devices.

Also FYI, the Xilinx PCIe IP core captures some packets related to configuration of the link/device for itself.

[asbridge]

Ulf,

I added a -i parameter to the CLI which essentially tells your discovery code to "skip" N instances that it finds:
pcileech -v -vv -device fpga tlp -in 000000011900000f00001000 -i 0
[+] VBA Using FTDI USB Instance 0

[+] using FTDI device: 0403:601f (bus 1, device 3)
[+] FTDI - FTDI SuperSpeed-FIFO Bridge - serialNumber 000000000001

My second board is the R01 I originally had tried to get running and failed
I tried to order a seconds R02 from Lambda, but it's discontinued and they have none!
There is a R03 coming from Lambda that is in an m.2 form factor, which is great for me but it's not available. Have you seen the Lambda R03? I'm hoping it will just plug and play with your code.

[ufrisk]

nice that you managed to fix your issue with the code, then I don't have to look into it with a hurry at the very least - even tho it's something I'll definitely have to change.

About the PCIeScreamer R02, where does it say that it will be discontinued and replaced by an M.2 om their site? I don't find anything about it.

If/when an M.2 device will be released it will be supported by PCILeech though.

[asbridge]

Can you send me your private email, I will send the reply from LambdaConcepts From: Ulf Frisk [mailto:notifications@github.com] Sent: Wednesday, November 27, 2019 9:36 AM To: ufrisk/pcileech-fpga Cc: asbridge; State change Subject: Re: [ufrisk/pcileech-fpga] How to specify which FPGA module to use (#41) nice that you managed to fix your issue with the code, then I don't have to look into it with a hurry at the very least - even tho it's something I'll definitely have to change. About the PCIeScreamer R02, where does it say that it will be discontinued and replaced by an M.2 om their site? I don't find anything about it. If/when an M.2 device will be released it will be supported by PCILeech though. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub<#41?email_source=notifications&email_token=ALANRPERM6SLNJE2MKD4AGLQV2ATZA5CNFSM4JR2MUG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFJWFBI#issuecomment-559112837>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALANRPDGGYEPH7PAGFX5ISDQV2ATZANCNFSM4JR2MUGQ>.

[ufrisk]

I'm closing this issue since yo most probably already have the M.2 device by now. Also selecting which FPGA (if several are connected) will be implemented some time in the future, but it's unfortunately not a very prioritized work item - but since you got it working by a small hack I hope it's fine.