I had written one driver for serial communication. Now I want to add it to my linux kernel. So for that I have to change Kconfig file in drivers/usb/serial.
I have rerffered Kconfig file in that. But I don't understand the names written after config, tristate etc.
What that names indicate? Where they belong or link(I don't find that particular name in that dedicatory)?
The name that you write after tristate (it is not always tristate), is just the name of the driver. To see it, try to use:
make ARCH=ARM menuconfig
Go into:
-> Device Drivers
-> Character devices
-> Serial drivers
Here you can see the name ARM AMBA PL010 serial port support associated to the PL011 driver
Related
I am working on a project with SAMA5D3-xplained board with CortexA5 processor and embedded Linux. I would like to send and receive some data via UART during U-Boot is running and before a kernel is loaded to the RAM. I have no idea what I should do. Should I add the second UART to U-Boot device tree source file? Should I change something in a board configuration file? Do you have any ideas on what steps I should take to achieve my goal? Thank you in advance for any help.
EDIT
I would like to use UART from U-Boot C code, not from U-Boot commands. I need to communicate with one of a peripheral device before the kernel is loaded to the RAM.
I assume that you are using the upstream U-Boot from https://source.denx.de/u-boot/u-boot.git.
The device-tree arch/arm/dts/at91-sama5d3_xplained.dts already contains the definitions for six different uarts called serial0 - serial5. serial0 is set in the /chosen node as the standard serial connection. You should be able to see all six devices with the 'dm tree' command.
The currently used UART can be switched by setting the stdin and stdout environment variables.
If you do not want to switch these variables, because you still want output on the default UART you will have to access the device driver. Unfortunately drivers/serial/serial-uclass.c does not yet export functions for this. But _serial_putc(), __serial_getc(), and __serial_tstc() should give you an idea how this is done.
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
I have an FTDI 232RQ chip that I used the FT_PROG application to change the VID on in order to use custom udev rules with it. However now that I have done that Windows will not enumerate it on a COM port. I can see the device and I can see that it has the correct settings. The chip is also no longer seen in my Linux environment.
I have used the FT_INF program to create custom ftdibus and ftdiport inf files using a clean download of the driver files from the ftdichip.com website. Attempting to install these new drivers that have the correct VID on them do not work and the chip reports ftdi chip cannot start code 10
I know now that I should have just changed one of the descriptor strings and keyed off the attributes string instead of the VID. But I can not get the chip to enumerate on a COM port so that I can reprogram the VID to be default.
Is there any way to fix this or is the chip just busted?
I am developing a device driver for a device.I wanted to know besides writing the device driver what and when it is necessary for it - a device tree blob (dtb) or a device tree overlay (dtbo).
Is it possible to dynamically insert the dtb (after compiling it using dtc compiler) and test the driver(dynamically loadable) .
For statically building dtb is there any Kconfig for the dtb files which I have to take care of apart from the device driver's Kconfig.
You don't mention what platform this is, but I'm assuming it is one of the architectures that extensively uses devicetrees for HW description e.g. ARM, PPC and that you actually need devicetree.
Device tree overlays require support from userspace, in the form of a overlay manager that knows what overlays to load at runtime. Unless your device is in a very dynamic environment where it might go away, for most cases, you want a simple hardcoded device tree.
After writing your driver, you need to define the compatible property to tell the kernel when to load this driver and then add a node to the devicetree (.dts/.dtsi) file under arch/<foo>/boot/dts/*/* that best describes your board.
e.g. See this compatible registration and the corresponding HW description in a bunch of devicetrees 1,2,3 that are SoC-specific. This one driver works on all those SoC by quirking SoC-specific fucntionality behind compatible flags.
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