I just bought a PCIE Expansion Card for USB 3.0 support. It works pretty well inside Windows. However, I did not managed to get my USB 3.0 thumbdrive booted-up (which is connected to the expansion card) as there is no option to choose from the boot menu.
So I am just wondering if there is any method to boot up my USB 3.0 devices? Is there any boot up software that extends the support of USB 3.0 expansion cards? E.g. something like Plop Boot Manager 5.0? Or, is it possible to develop one?
My expansion card is Transcend PDU3
http://www.transcend-info.com/products/catlist.asp?ModNo=291&Func1No=1
Thanks!
Booting from an expansion card (whether it be a PCIE SATA card, a PCI network card, or a PCIE USB card) works differently than booting from onboard devices. The card itself must support booting, via its own boot ROM. On some expansion cards, the boot ROM chip is optional and may not be present; other cards are incapable of having a boot ROM.
I couldn't find info online about whether your specific card has a boot ROM on it.
It looks like Plop Boot Manager doesn't currently support USB 3.0, though they plan to soon. It doesn't hurt to try. If you're booting Linux, plopKexec has experimental support for xHCI.
If you're feeling adventurous, you can try this procedure to try to dump the expansion ROM (if any) from your card, and run strings or xxd on it to see if there's any boot code there.
Related
We have an embedded board that has an iMX8M-Plus Processor and Linux v5.4.161. This board has one PCIe bus and that one is connected to an FPGA. When we power up the board, the FPGA is not yet configured, so it acts as if it was not on the PCIe bus.
Once the Linux is fully booted, we configure the FPGA and only after that it starts acting as a PCIe endpoint (device).
At this point, when I run lspci -> it returns nothing.
When I first execute echo "1" > /sys/bus/pci/rescan as suggested here and here and then lspci, I still get nothing.
But if I reboot the linux without reseting the FPGA, it starts being visible in the lspci list. Rebooting the linux is not an option for us. Somehow I need to tell the linux that whatever it's doing at the boot time, please do it again at runtime. But I couldn't find a solution for this so far.
According to the Texas Instrument support forum, they said if the PCIe link is not trained at the boot time, rescan command never works.
At the boot time, while linux loads a pci driver, it tries to establish a PCIe link, I can see that with an oscilloscope, PERST pin is asserted and PCIE_CLK generated for a while and then stops if it can not detect any device. But the rescan command never does that.
Also in the system there is no pcie device to executeecho 1 > $pcidevice/remove in order to make rescan functional. Or there is no device or bus to set power off and on back like echo 0 > /sys/bus/pci/slots/.../power
I also learned that there was a method in old linux times (v2.6) called adding a Fake PCIe Device which physically doesn't exist to solve this problem. For that I took the fakephp.c driver from an old linux repo and ported it to ours. After solving a couple of deprecated function problems, it is compiled for Linux Kernel v5.4. modprobe fakephp worked and driver loaded but somehow I didn't get this fake device in my device list. Here it is mentioned that the fakephp driver was removed from mainstream linux since PCI core has similar functionality, but he never mentioned how.
Short of the story is that, I am stuck here, I need my FPGA to be visible in the lspci list without restarting the linux.
I recommend configuring the FPGA in u-boot to get away from these kinds of problems. Connect up SPI pins to FPGA's config pins & run it in Slave configuration mode.
I am aware of that this question may seem a bit quaint. I am also aware of USB to ISA adapters, but they might not be applicable in this case.
I get search results hinting about that ISA bus support was dropped after Windows XP, but what does that even mean? Shouldn't a device driver be able to access anything connected to the processor, e.g. an ISA bus controller?
Your device driver isn't the only driver needed to operate your device. In fact there is a whole bunch of drivers riding one on top of another. Your device driver is what is called a function driver, i.e. the driver that implements (most) of your business logic. Below the function driver there will always be a bus driver (unless the device is virtual) which operates the bus, which is a piece of HW on its own. So dropping the ISA bus support by the OS means there is no driver for it. Moreover, the entire ISA architecture is obsolete and doesn't integrate into the Windows 7 eco-system (so even if you had a compatible bus driver, it wouldn't be enough). In my opinion, there is not much you can do in this situation.
I have 12 USB 2.0 devices plugged into an Intel NUC D54250WYK running Ubuntu 14.04.
Running lshw -short shows two different USB buses and two host controllers (xHCI and eHCI).
All of the USB devices appear on the same bus and use xHCI regardless of the ports they are plugged into. As a result I'm seeing the following errors in dmsg:
Not enough host controller resources for new device state.
Not enough bandwidth for altsetting 0.
Is there a way to force devices to a specific bus?
I've also read that Linux can have problems with xHCI. Is there a way to force eHCI without recompiling the kernal? Intel does not provide that option in BIOS.
Last I checked on this, you're in a bit of a bind. It seems xHCI is compiled into the kernel, not as a module, and if you compile in eHCI/aHCI/oHCI and not xHCI, USB as a whole breaks, possibly due to some built-in support for on-board USB controlled BlueTooth and WIFI devices on certain mobos. DO NOT UPDATE YOUR BIOS yet... see if the option to disable xHCI still exists on yours.
At this time, it seems your best option is to disable xHCI in your BIOS. This will likely disable all USB3 controllers, but allow USB2 controllers to work without this issue impeding you.
With respect to the Intel device you described, I don't see many USB ports on it, so I assume you're using hubs. From the tech specs for your device, it looks like you'll have to get access to the internal header to get at the USB2 ports.
Good news for anyone else facing this issue. Intel released a new bios (v40) that adds back the option to disables xHCI. In my case I updated the bios, disabled xHCI, and everything works as expected.
Beware of platforms that have XHCI ONLY (Apollolake, Denverton).
You will brick your HW if you disable XHCI there.
I'm investigating options available for creating a virtual USB device (say, a keyboard or a mass storage device), so to emulate its function as needed and to allow a userspace app to emulate its insertion/removal at will.
What I am not clear about is how to go about the emulation of insertion/removal. It seems that one option is to emulate a (virtual) USB hub and have it fake the device arrival/departure events (and I would also supply the device driver for my virtual USB device and that's where my device logic will reside).
I know my way around Windows kernel (having written NDIS miniport drivers), not afraid of SoftICE, but USB is not my domain, just starting out with it.
Am I on the right track with the virtual hub approach? If so, is developing virtual hub drivers supported by WDK (it doesn't seem to be)?
Any other options?
--
(Edit) Forgot to mention - I am aware of DSF, but it is not supported on W8.
Am I on the right track with the virtual hub approach?
In short - yes, I was right.
That's how USBIP does it and it's a relatively simple way to go. Also, see this comment by Eugen.
I don't know if you are aware, but Microsoft released to Win10 the UDE (USB device emulation).
In the section Write a UDE client driver they describe exactly what you want.
I need to create a application that will allow a Windows PC (XP/Vista) to emulate a thumbdrive. That is, when the PC is plugged into either another Windows system, or in this case, a piece of hardware that allows for USB thumbdrives to be plugged in, a folder on the computer looks like a giant thumbdrive. Any thoughts on where a guy would start to investigate this?
Update (more specific description):
I need to connect my PC to one of the newer multifuction devices that support scanning to a USB thumbdrive that is inserted into the front of the device. These units do not support WIA or TWAIN via the rear USB connector that you'd typically use for connectivity to a PC.
Most USB controllers in regular pc's dont have the possibility to function as an USB slave. So I'd start with investigating what kind of hardware you're going to use.
Another way to go: there are USB Link cables to link up 2 pc's over USB, maybe that's usable for you?
You cannot do this in an application. At the lowest level, the USB ports on your computer are controlled by an Host Controller Interface. This chip will manage up to 127 slave USB devices. You would need to seriously reprogram this chip before it implements the slave side of the USB protocol. Of course, at that point any USB hub in your PC will break down - those 8 USB ports you probably have are usually implemented by 2 smart USB hubs connecting to both USB1 and USB2 host controllers. Next, your USB keyboard and mouse will stop working.
Take an MCU with two Slave USBs. Write a simple frimware which makes one USB act as a Special Device Class and wait until PC on this USB provides mandatory data (including Device Class, of course) for the other USB. Write a PC program which connects to the Special Device (your MCU), uploads Mass Storage Device Class and redirects I/O to a dedicated partition. The other USB on the MCU will become an emulated Mass Storage Device.
Some of those code can be taken from Linux.