I am using mcp3021.c file for Microchip MCP3021 IC. My module's init and exit functions are replaced with module_i2c_driver(mcp3021_driver), But I don't see the driver register print in my Kernel log when I ran the code. Can anybody please help me with this ?
First thing which kernel version you are using ? because this macro is introduced in Linux kernel after version 3.3 .
So if your are using kernel version below this you should actually get error while compiling the kernel.
You have verify are few things to make it work,
Ensure that I2C device is properly mounted in hardware.
Confirm that your device is not in reset state.
Ensure that in your device tree you are using the appropriate I2C bus and driver id is properly configured.
Check your kernel configuration(.config) that your driver is enabled.
I2C Probe will be called only if above all conditions are met.
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.
Good day all!
I have an issue in code that I cannot find.
See here
Is it possible to setup GDB to see what the UART is getting in incoming serial data?
Thanks!
I'd suggest you to modify UART driver for Linux kernel and inside of this driver dump the incoming data. The GDB works in user space but you need to do this on the lower level - in UART driver. GDB has no access to registers of the physical device as the UART is.
Am trying to validate I2c communication on xilinx zynq zc702 evaluation board in u-boot(as a part of board bring up) with i2c commands but i observed the logs in minicom console saying i2c command not found. Please can i know how to fix this type of issue and how to make the commands work in u-boot
It seems, you didn't enable I2C command in your u-boot configuration and hence it not compile as part of your u-boot.
CONFIG_CMD_I2C=y should be =y, check and recompile your u-boot source
I've not clear what is the difference between drivers that can be "embedded" inside a monolithic kernel and drivers available only as external modules.
What kind of effort is requested to "port" some driver (provided as "external module" only) to a monolithic kernel?
I would like to be able to run Vmware Tools disabling loadable modules support and getting rid of the initrd bazaar.
Though the driver more or less remains the same(in both cases),there are definitely benefits for using "drivers" embedded in monolithic kernel.
I'll try to explain the "effort in porting" the driver part which you've asked.
Depending on the kind of driver you've, essentially you've to figure out how it will fit in the current kernel source tree, its compilation(include your .ko in the uImage) and loading of it while kernel booting. Let's illustrate each step a bit:
a.) Locate the folder (in the kernel source tree) where you think it is best suited to keep your driver code.
b.) Work on to make sure your driver code is getting compiled.[i.e ultimately it will be part of monolithic kernel image(uImage or whatever you call it)]. In this context, You've to work on your Makefile for your driver. You might have to introduce some CONFIG flags to compile your driver code. There are tons of Makefiles' and driver code lying in the source tree. Roam around and you will get a good reference of how it is being done.
c.) Make sure that your driver code is independent of any other
loadable kernel module(i.e such modules which are not part of the
"monolithic" kernel image). Because if you invoke your driver
code(which is monolithic now and is in memory) which depends on
loadable module code then it may cause some kernel
panic/segmentation fault kind of error.
d.) Make sure that your driver is registered with a higher level of
subsystem which will be initializing all the registered drivers
during boot-up time.(for example: an i2c driver once registered
with i2c driver framework will be loaded automatically when i2c subsystem is initialized during system startup). This step might not be really required if you can figure out another way of invoking your driver's __init and __exit functions.
e.) Now, Your Driver _init and (_exit sections) "should" be called
if it is getting loaded by any device driver framework or directly(i.e. while
kernel is booting up ).
f.) In case of h/w drivers, we have .probe implementation in driver
which will be invoked once the kernel finds a corresponding device.
In case of s/w drivers, I guess __init and __exit is all you have.
g.) Once it is loaded, you can use it like you were using it earlier as a loadable kernel module
h.) I'll recommend reading source code of similar device drivers in the linux kernel tree and see how they are operating.
Hope this helps.
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