I use PCAN Driver for Linux v8 developed by PEAK SYSTEMS.
After successful compilation when tried to load the Linux Kernel Module (LKM) named pcan
sudo modprobe pcan
lspcan -T -t -a
Devices are not getting displayed under /dev
Note: I have not connected actual device or hardware in my PC.
Is it expected behavior? Or regardless of actual device connection, those should get displayed? Which is expected behavior?
Reason why I am asking is, when doing insmod with my own LKM, I got the devices under /dev.
Is it expected behavior? Or regardless of actual device connection, those should get displayed? Which is expected behavior?
In general, a driver should only create the /dev entries for devices that it is actually handling.
Since you don't have the hardware, it is normal that the driver did not create anything.
It is possible that PCAN driver doesn't create entry in /dev on its own, and you need to do it manually. Not every driver creates those files automatically. Try to look at /proc/devices file if there is the device you are expecting. If yes - try to create appropriate device node in /dev using mknod.
Edit: If you have no connected device in your PC - how driver could recognize it and create appropriate files in /dev?
Related
I'm working on a Cyclone V SOC FPGA from Altera with a double Cortex-A9 processor. The embedded system (linux 4.15.7) is created with Buildroot-2018.02. U-boot is used to load the system i-e FPGA.rbf file, device tree blob and zImage and everything works fine.
I want now to integrate the RBF file to my linux and program the FPGA from Linux. I found several methods and the one I understand is the most common is to use CONFIGFS with a device-tree overlay.
So I changed my device tree to integrate the overlay, the u-boot boot script to disable FPGA load and also the following options in the linux ".config" file with make linux-xconfig :
+CONFIG_OF_OVERLAY=y
+CONFIG_ALTERA_STAPL=y
+CONFIG_CONFIGFS_FS=y
+CONFIG_SAMPLES=y
+CONFIG_SAMPLE_CONFIGFS=m
These options are the state were I am now after several try.
After a make and a reboot, once the kernel is loaded, I enter the following command in the console :
mkdir /config
mount -t configfs none /config
At this state, I'm expecting to see some device tree files in the /config folder but there wasn't any, only one rdma_cm folder :
# ls /config
rdma_cm
I continued my reading on this topic and found that I must enable the CONFIG_OF_CONFIGFS option in my linux kernel.
PROBLEM: This option is not available in my linux kernel. Also, file drivers/of/configfs.c is no here too. I've searched in vain to find how to enable device tree overlay for my kernel version.
How can I configure my kernel to make device-tree available in configfs ?
I had the same problem as you. So I had to make a device driver by myself.
This device driver is tentative and I expect Linux mainline to officially support Device Tree Overlay ConfigFS.
The device driver I made is available at the following URL.
https://github.com/ikwzm/dtbocfg
If you are using Debian, you can build the Debian Package of the device driver with the following URL.
https://github.com/ikwzm/dtbocfg-kmod-dpkg
If you want to try Device Tree Overlay using this device driver, please refer to the following URL.
https://github.com/ikwzm/FPGA-SoC-Linux
https://github.com/ikwzm/FPGA-SoC-Linux-Example-1-DE10-Nano
Hi I am trying to create a dvb frotnend for my device on ubuntu. I have created a device driver file that creates a dummy dvb file after looking at dummy_dvb_fe.c which is present in the linux kernel. For some reason when I insmod it I am not able to see anything in my /dev folder. Generally a device node under /dev/dvb/adapter should get created. I am not sure if any other files need to be changed for front end registeration. due to the lack of documentation I am not sure about the process of creating a dvb frontend device driver and registering it.
Well I figured it out. Issue was I was looking into the Linux TV user space DVB-API documentation instead of the Media Kernel API documentation. In any case
You have to create, populate and register a dvb_adapter after which you have to create and register a dvb_dummy device.
I made a node which contains a USRP_UHD and a GPP (and make sure the ip_address is correct for USRP_UHD). I launched the domain based on this node. However, I got the following error:
UHD Error:
Device discovery error: AssertionError: libusb_init(&_context) == 0
in libusb_session_impl::libusb_session_impl()
at /builddir/build/BUILD/uhd-release_003_005_003/host/lib/transport/libusb1_base.cpp:37
UHD Error:
Device discovery error: AssertionError: libusb_init(&_context) == 0
in libusb_session_impl::libusb_session_impl()
at /builddir/build/BUILD/uhd-release_003_005_003/host/lib/transport/libusb1_base.cpp:37
...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
UHD Warning:
Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
I did get two unallocated (TX/RX for each) tuners, but it is not easy to allocate these two tuners for use for any parameters.
Besides, if I just launch the domain and launch the single device USRP_UHD, or simply run the discover USRP_UHD command via the command line window, I got the same error:
UHD Error:
Device discovery error: AssertionError: libusb_init(&_context) == 0
in libusb_session_impl::libusb_session_impl()
at /builddir/build/BUILD/uhd-release_003_005_003/host/lib/transport/libusb1_base.cpp:37
2016-02-01 16:59:20 WARN USRP_UHD_i:943 - WARNING: NO UHD (USRP) DEVICES FOUND!
Could anybody figure out where this problem is? Thanks in advance!
So, first of all, the good news is that this is happening during autodetection of USB devices, so your N2xx is not inherently affected, but:
UHD 3.5.3 is not only old, it's ancient. You should really uninstall it (If you've got Debian or a derived one [Ubuntu], it'd be sudo apt-get remove uhd-host libuhd003 libuhd-dev), install a new version directly from Ettus (can help you with that, if necessary) and rebuild Redhawk against that version.
Really, really do that. There's been so much improvement in behaviour like failure handling that fixing this without updating isn't really worth it.
Now, if you explicitly specify a device address that allows you to cancel USB-based USRP detection completely, you should be fine. As device address, use type=usrp2 for USRP2, N200 and N210.
I ran into this issue trying to install UHD v3.9.3 in a CentOS 7 Docker container - the error message points to a usb issue, not related to Redhawk. The Redhawk Device, USRP_UHD, is just an abstraction layer on top of the Ettus UHD drivers, so the easiest way to tell whether the problem is Redhawk or something else is to try one of the UHD commands directly from a terminal to generate the same error, like uhd_usrp_probe.
To check if the problem is directly related to the usb drivers try the command lsusb. This should list all usb devices connected to your OS. These are good debug tips to isolate where the problem is.
If you happen to be doing this using Linux containers or Docker you have to give the proper privileges, see docker-any-way-to-give-access-to-host-usb-or-serial-device. Otherwise, assuming you built UHD from source, check the output of make test step - if all the tests passed there shouldn't be anything wrong with the UHD library.
Edit: Also if you're running this inside a VM you have to make sure your host has given network/USB/etc privileges to the hypervisor (ex. VirtualBox) during installation, or that you've attached the correct virtual hardware in the VM configuration.
Cutting to the Chase
Does the Linux composite USB gadget mass storage function support hot swapping of its LUN media backing files? If so, has anyone gotten it to work?
Background
The Linux USB composite gadget includes a Mass Storage function which can support multiple logical units, each of which maps to a drive image file (like FAT or ISO). From what I can tell, the Mass Storage function appears to inherit some or all of it's configuration interface from the previous standalone g_mass_storage gadget
The documentation implies that you can mount a storage image as a mass storage LUN, and then, at a later time, unmount it and remount a new storage image, in a manner similar to how a physical CD/DVD drive would work. It is this functionality that I am trying to access.
What I Have Tried
I am using insmod/modprobe and rmmod to mount and unmount a single LUN mapped to an ISO image. The modprobe parameters are modified version of the stock Edison config, which it uses to expose its "firmware update" drive image.
The USB slave is an Intel Edison board running a slightly modified Yocto build, the host is OS X 10.10.2:
# Step 1: mount an ISO
modprobe g_multi file=/home/root/first_image.iso removable=1 ro=1 stall=0 idVendor=0x8087 idProduct=0x0A9E iProduct=Edison iManufacturer=Intel
# at this point, the ISO appears on the host (I'm testing with OS X)
# Step 2, at some later time
rmmod g_multi
# The storage disappears from the OS X desktop.
# It does not seem to complain unless you had files open on the media
# Step 3: mount a different ISO
modprobe g_multi file=/home/root/second_image.iso removable=1 ro=1 stall=0 idVendor=0x8087 idProduct=0x0A9E iProduct=Edison iManufacturer=Intel
# The operation appears to work on the device side,
# but the new media does not appear in OS X.
# You can usually get it to work by unplugging the USB cable,
# which presumably resets the port somehow.
I have tried to find a way to reset the OTG device port under software control. That may be the ultimate solution.
I have not (yet) tried using the configfs interface to build and configure the device. That may also be an option, but I'm still working through the docs on that.
Thanks!
At least on:
$ uname -r
4.9.87
I've found this:
$ find /sys -type f -a -name file
/sys/devices/soc0/soc/2100000.aips-bus/2184000.usb/ci_hdrc.0/gadget/lun0/file
/sys/module/g_multi/parameters/file
The prefix will be heavily dependent on your hardware, but the gadget/lun0/file one is writable. You'd then:
echo "/where/is/your/file" >.../lun0/file
and voila. Of course, you need the removable=1 passed go g_file as the OP implied.
To "eject" the device, you simply do the following:
echo >.../lun0/file
This last one may fail if the filesystem is still mounted on the host.
I'm working on a project where I have a management system that exports PCIe hardware devices to other systems via PCI Express. I have a working management kernel module but need to find a way to ensure that a device I export doesn't have a driver already loaded for it on the management system. Without that, the device will end up with conflicts since the same driver will be accessing it from 2 different systems & obviously cause problems.
For example, assume I have a dual-port Intel 100MBps NIC device installed on the Manager which will show up 2 PCIe Endpoints in the system (eg Fn 0 & 1). The Intel module e1000 will be loaded for both devices. If I want to export port 2 of that device to another system, I would like to "detach" it from the e1000 module.
Does anyone know a clean way of doing this without hacking the kernel or tweaking the e1000's driver's probe function? I can't simply do an rmmod because that will remove the module all-together for both NIC devices. I would like the NIC I'm not exporting to remain functional in the Management system with the e1000 driver still loaded for it.
Essentially, rmmod does this but will remove the driver for all devices probed for & owned by the driver. Any way to tell Linux just "unload module for only this specific device"? On Windows, I guess this would be the equivalent of right-clicking on a device in Device Manager & select "Disable".
You can disable driver for your device by writting following method:
Use sudo -i or before any command write sudo to operate as root user.And follow below procedure:
Goto /sys/bus/pci/<driver_name>/ folder.
Give command echo -n 0000:03:00.1 > unbind
Where 0000:03:00.1 is device you want to detech your driver.
Read this link for getting idea about sysfs for pci bus.
The mechanism responsible for device/driver pairing in Linux driver model is called "bus" (usually controlled through entries in /sys/bus). The problem is, the particular bus driver your device is attached to must support this sort of action (and it is far from trivial supporting this functionality in general case).
Specifically for PCI, if you've got "pci hotplug" enabled, you will be able to kick devices off pci bus by writing numbers to corresponding "hotplug" entries in /sys/bus/pci (you can also reconnect them back by triggering the bus rescan). The problems will start later, as you will have to somehow convince the Linux device subsystem to prefer your driver over the one already registered for the device id in question.
Normally registered drivers are added to some sort of list and then tried out one by one to see if either of them is listing the new or re-enabled device in their "*_device_id" tables. If PCI subsystem prefers to try drivers in "first registered, first tried" order you will have to hack it to achieve your goal.
To unbind a PCI driver from a device, use the unbind file of the driver in sysfs.
From Documentation/ABI/testing/sysfs-bus-pci:
/sys/bus/pci/drivers/.../unbind
Description:
Writing a device location to this file will cause the
driver to attempt to unbind from the device found at
this location. This may be useful when overriding default
bindings. The format for the location is: DDDD:BB:DD.F.
That is Domain:Bus:Device.Function and is the same as
found in /sys/bus/pci/devices/. For example:
# echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind
you can disable a particular pci device by resetting enable value for the corresponding device
Eg:
echo 0 > /sys/bus/pci/devices/0000:00:1a.2/enable