I'm trying to backport a Linux kernel driver (the PCF85063 RTC, specifically) from the 3.17+ kernel into a 3.14 kernel I'm using, and I'm running into a few issues. I don't have any experience with adding/modifying kernel drivers, so I'm not sure if what I've done so far is correct:
I took the rtc-pcf85063.c file from the newer kernel, and added it to my drivers/rtc/ directory in the kernel source.
I added the following line to drivers/rtc/Makefile:
obj-$(CONFIG_RTC_DRV_PCF85063) += rtc-pcf85063.o
I added this snippet to drivers/rtc/Kconfig
config CONFIG_RTC_DRV_PCF85063
tristate "NXP PCF85063"
help
If you say yes here, you get support for the NXP PCF85063 RTC.
From my understanding, that should be all it takes to add driver support for the new RTC. When I execute make menuconfig, I can see my new RTC entry under Device Drivers > Real Time Clock, labeled as NXP PCF85063 with the correct help information. So it's clear that the third step above was successful.
The problem is, when I include this driver (by selecting it in menuconfig and saving/exiting) in my kernel build, it doesn't actually get built in. If I deploy the kernel and read /lib/modules/3.14.17/modules.builtin, the new driver is nowhere to be found. Also, if I check drivers/rtc/ after building the kernel, there are object files for every RTC driver included through menuconfig except the new one; the kernel isn't even compiling the driver.
I found one interesting thing that might give some hint as to what's going on. When I go to include/config in the linux source after running menuconfig, I have a bunch of directories, some of which correspond to drivers. There's an rtc directory, and when I navigate to include/config/rtc/drv, there's a header file for every RTC driver included in the build except the one I added.
The thing is, the header file corresponding to the new driver is in include/config; it's hidden away in include/config/config/rtc/drv. It looks like menuconfig isn't treating the new driver as a regular RTC driver.
I know this is a pretty specific problem, but I was hoping that someone might notice that I'm missing a step or going about this the wrong way. Thanks.
Related
I am making a project which send out 40khz signal from antenna.
I have found the signal is not too accurate so I have decided to try a real-time kernel.
I run Raspbian Jessie on my Raspberry-Pi 2B.
After clean install, the script run without any problem.
bcm2835_delayMicroseconds could be run.
I follow this tutorial http://www.frank-durr.de/?p=203 compiled and installed the RT kernal.
However, the script could no longer be run successfully.
After showing "HIGH SLEEP", and it is held up.
This is the code snippet:
fprintf(stdout , "HIGH\n");
bcm2835_gpio_write(PIN, HIGH);
fprintf(stdout , "SLEEP\n");
bcm2835_delayMicroseconds(12);
fprintf(stdout , "LOW\n");
bcm2835_gpio_write(PIN, LOW);
fprintf(stdout , "SLEEP\n");
bcm2835_delayMicroseconds(12);
Do I miss anything when compiling the kernel?
To use PREEMPT_RT you just have to:
retrieve the configuration of your current kernel
retrieve the kernel sources
patch the kernel sources with the PREEMPT_RT patch (or obtain an already patched kernel)
configure the new kernel as the current kernel (i.e., using make oldconfig)
enable full preemtability in kernel config (e.g., by running make menuconfig).
compile the kernel in the standard way
install the new kernel
Therefore, no particular action is needed.
Then, if performance is still not sufficient, you may want to tune priorities of specific IRQ threads.
From your specific error, it seems that the new kernel has been conpiled with a different configuration than the current kernel (e.g., GPIOs not enabled).
I have just seen and remembered this thread.
About half year ago, I want to generate 40khz from a Raspberry.
But finally I found I am using the wrong tool.
I believe Raspberry cannot handle such a task, since it is running an OS.
I switched to Arduino, and the problem is solved immediately without any problem.
Using the right tool for your task is very important!
Thanks to every one,
This is the question asked in one of the interview i faced.
I have a Linux device driver which was compiled in Linux kernel version 2.6.I would like to port the same driver in a Linux PC which has kernel 3.X without compiling in new versions.
Is it possible ? If it is possible please let me know how. If it is not possible please let me know why not ?
Thanks & Regards
Siva
No you cannot port module which is compiled for one version to other version.
The reason is as follows
Modules are strongly tied to the data structures and function prototypes defined in a particular kernel version;
the interface seen by a module can change significantly from one kernel version to
the next. This is especially true of development kernels, of course
The kernel does not just assume that a given module has been built against the
proper kernel version. One of the steps in the build process is to link your module
against a file (called vermagic.o) from the current kernel tree; this object contains a
fair amount of information about the kernel the module was built for, including the
target kernel version, compiler version, and the settings of a number of important
configuration variables. When an attempt is made to load a module, this information
can be tested for compatibility with the running kernel. If things don’t match,
the module is not loaded; instead, you see something like:
# insmod hello.ko
Error inserting './hello.ko': -1 Invalid module format
A look in the system log file (/var/log/messages or whatever your system is configured
to use) will reveal the specific problem that caused the module to fail to load.
Kernel interfaces often change between releases. If you are writing a module that is
intended to work with multiple versions of the kernel (especially if it must work
across major releases), you likely have to make use of macros and #ifdef constructs
to make your code build properly.
now it's not possible:
usually, a "driver" is a binary kernel-module
porting will involve code-changes to the kernel module. if you change the code, you need to compile it, in order to get a binary.
since kernel modules run in kernel space, it is crucial that they are robust. since parts of the kernel-API change every now and then, trying to use a module compiled for kernel-X with another kernel-Y, might either not load because of missing symbols (if you are lucky) or lead to a kernel panic because semantics have changed.
btw, all this is not really related to 2.6.x vs 3.y, but holds true for any kernel version
but then: of course in theory it is possible to "write" a kernel-module as binary code in your favourite hex-editor, without resorting to compilers and such. this would allow you to "port" a driver from one kernel to another without recompilation. i guess this is not for humans though...
I have a BeagleBoard XM on which I installed Ubuntu from rcn-ee. Now, I'm looking to install the 8192cu driver because I can't get WiFi to work with the kernel driver. However, the makefile for the driver needs a path to the kernel source, which I can't find.
I think the kernel is in /lib/modules/3.6.2-x3/kernel, but that doesn't seem to have the source. How/where can I get the source for this in order to install the driver?
Note: If I give
KSRC := /lib/modules/3.6.2-x3/
I get
No rule to make target 'modules'. Stop.
To build drivers you should only need the kernel headers. There is a thread on the beagleboard group that explains where to find the source and headers (note that it is fairly old, so you may need to adjust for your build).
This post also looks relevant
I work with raling rt73 usb device on Ubuntu 8.04 (kernel version 2.6.24) on lpia (Intel Atom) platform. The device is handled by rt2x00 drivers that are part of the kernel. The scan routines are performed incorrect (eg. wrong signal quality and redundant networks are detected). I want to fix these issues, but I cannot find the place in the driver code where those mentioned values are calculated. Unfortunately neither the driver is exhaustively documented, nor the website of the project provided me with useful information.
I wanted to track how the ioctl commands are executed (e.g. SIOCSIWSCAN or SIOCGIWSCAN commands) but they are not mentioned in the code (grep SIOCSIWSCAN * returns nothing). Also the struct, where the scan results are stored (struct iwreq) does not exist in the code.
I am fresh to drivers so maybe I am approaching the problem in wrong way. Can you push me in right direction?
I got a RFID reader (GigaTek PCR330A-00) that is meant to be recognized under linux/windows as a (Human Interface Device) keyboard/USB.
I hate to say this but it is working as a charm under Win7 but not "really" under Linux.
Under Debian-like distros (x/k/Ubuntu, Debian,..), or Gentoo, or... I just can't have the device working at all: the device scan well (it has its USB 5V, so it is happy/beeping/blinking) something happened in the dmesg, but no immediate screen display of the RFID Tag code as expected (and seen under win7)
Support is claiming it is ok under RHEL or SLED "enterprises" distros... and I must admit I saw it working under a RHEL4... I tried stealing the driver but did not succeed having my reader working...
My question is thus double:
1./ How can I hack the kernel to add support to my device (simply register PID/VID?) ?
2./ What is different at all in a "enterprise" proprietary distro? how can I re-use it?
Thank you for any hint/help.
Cheers,
If you have the source code of the driver you can compile it against the current Kernel your system uses, since the Kernel only allows drivers for its current version. Then you can try to load it as a Kernel module, notice that by doing this, you do not hack the Kernel you just need your current system's Kernel header to compile the driver against it.
You may want to check this http://www.freesoftwaremagazine.com/articles/drivers_linux in order to grasp the basics.
Hope this helps.