I am following this link http://mt-system.ru/sites/default/files/documents/how_to_use_the_sim7100_module_in_linux-driver.pdf to compile and install GobiSerial drivers so I can interface Sim7100 module with it. I have successfully compiled the drivers but when I run the command
sudo modprobe usbserial && sudo insmod GobiSerial.ko
it executes without displaying any error but usbserial doesnt appear in lsmod output, neither /dev/ttyUSB* are created.
Check dmesg before you do any of these commands to see where it stops at. Then do the modprobe by itself, check what was added to dmesg. Follow this by the insmod, check dmesg again. Then plug in and unplug the USB device, see what dmesg adds to this. If possible, use “sudo lsusb -vvv” to see what USB layer has to say about the device (if you do plain lsusb first you’ll see an ID you can use to query just the one device, e.g., “lsusb -d 1b1c:1b05 -vvv” is verbose output for just a particular Corsair mouse).
We’re running into the same problem. We’re also using a SIM7100 module, on a small PCIE card. After “insmod GobiSerial.ko” it just registers (visible in “dmesg”), but nothing else happens and no /dev/ttyUSB* are created.
It appears the card is only using USB2 though, not PCIE. However we’re unsure if the card is (or is not) using some of the usual PCIE power. This is of course just a wild guess without further detailed diagrams of the PCIE card, however if that is the case maybe that is why the card isn’t working. Looking at the “dmesg” output early on we see the following:
PCIE: Disable power rails
(and no way to control / override this automatic power saving).
I don’t know the details of your driver, but sometimes udev renames devices as they are created. If that card allows plugging in something which is USB, then no ttyUSB* will exist until that item is plugged in, regardless of a controller presence. If you look at “lsusb -t” you’ll see a tree view of USB devices, and the 5000M implies USB3, 480M is USB2. Anything slower is probably a keyboard or mouse using USB1.1.
The PCIe side might use one driver, you can see this with “lspci”, but the USB devices will not know they are going through PCIe controllers and essentially be independent…this would be a separate driver. The PCIe can load without USB succeeding; USB over PCIe cards cannot succeed unless PCIe is good. If USB sees the device, you then have to load yet another driver specifically for the device or that device’s class…the final device driver does not know it is talking through USB even if it is a standardized device (e.g., video class may be defined by USB, but the driver specific to that class is actually separate from the USB communications driver). For a PCIe USB card you have at minimum 3 drivers to load for a given device to show up.
I do not know what the PCIE message is about.
Some information on performance which shows disabling low power mode for various things is here:
[url]http://elinux.org/Jetson/TX1_Controlling_Performance[/url]
Both “lsusb” as well as “lspci” do not list the device at all. I would expect the device to show up, even without drivers being present.
The device we have is a SimCom 7100 modem+GPS as a mPCIe card. However it only uses the (independant) USB2 interface, it doesn’t really use the PCIe bus, it’s only a mPCIe physical format. Interestingly when not inserting the card into the PCIe slot, but hooking it up to the normal USB connectors (soldering some wires onto the correct pins on the mPCIe card) it does show up with “lsusb” and everything appears to work.
This is why we have a suspicion that the TX1 is switching of power to the PCIe socket (including the USB part) when no PCIe device is found.
I’ve looked at the kernel source of R24.1 in drivers/pci/host/pci-tegra.c and it appears there is no way to control the power savings behavior for the PCIE bus through the /sys system.
To verify, the PCIe card provides USB ports, is that correct? If this is working, the lspci should show the presence of the card. Note that PCIe should find the card even if a driver specific to the card is not present. Once PCIe sees the card, a hardware-specific USB root HUB driver can be loaded.If not, then the USB root HUB driver cannot be loaded and the USB controller is inert. If lspci shows the device, then the USB controller can be active with the presence of the right driver.
If the USB controller is active, then plugging in a USB device should cause the device to be seen in lsusb, and an event to be noted in dmesg about any USB device plugged in or unplugged…if this does not happen it implies the HUB internal to the card has no driver. Should this event be noted, there will not yet be a “/dev” file created…but it means the device special file can be created if the message of device insert on dmesg triggers a driver to claim ownership of the device. It is this final driver which creates the actual “/dev” file. The dmesg is from the same event which asks for the final driver to take ownership…no message, then nobody is asked to take ownership.
In many cases the final driver file is present by default for some standardized class of device (e.g., human interface devices like keyboards and mice). Should the device be custom (custom hardware not handled by generic class definitions), then a custom driver must be added.
Regardless of custom driver or standardized device class driver, some third party user space application or management daemon may not find the device special file if udev has used a naming convention not known by the application or daemon.
The observation that plugging the USB device into a non-PCIe USB controller generates an event, but plugging into the PCIe USB controller does not generate an event, shows the PCIe subsystem never got an answer from a driver that understands the USB root HUB in it (PCIe has broadcast an event to ask for a USB root HUB driver since lspci shows it, but no driver knows it can handle this PCIe HUB and does not respond). Note that lspci itself shows that the PCIe bus sees a device…but this does not mean a driver has taken control of the device (the USB hardware in the card). If the PCIe card used the same chipset as the other USB port which works, then you would have had a driver to take control; it looks like the PCIe card uses a different chipset than what current drivers support. You need a driver for the USB card’s specific chipset.
In cases where PCIe broadcasts the presence of a PCIe device, and in which some driver answered to take ownership, “sudo lspci -v” names the driver which answered. An example of what that answer shows up like via “sudo lspci -v” will look like this:
Kernel driver in use: ahci
If that line does not exist or if a line claims no driver, then you are guaranteed the USB root HUB driver specific to the PCIe device is at fault (it is missing or misconfigured). No USB hotplug event can be broadcast because the USB hardware is inert.
I have not read through all of that documentation of that card, but if there is some compatibility issue with the driver, or some missing configuration, then this would be the same as not having a driver for the chipset. What is the source of your GobiSerial.ko module?