I have a kernel module "A" which detects an optical H/W on device. This device needs to have some calibration data configured to perform correctly. I do this using i2cset from command line.
As, there is no EEPROM/persistent storage for this module to read information from during the boot, the module does not work immediately after power cycle. It works after soft reboot if i2cset is done.
Can we program this data in kernel space itself after "A" is detected by i2c on the bus and reload the module immediately? Can the data be programmed somewhere even before the module "A" is detected?
Related
I am working on a Linux device driver for a piece of hardware that relies on some configuration specific to each implementation. On the first boot-up, we require a user-space application to generate this configuration data through a calibration process. Naturally, I would store this configuration data in a file and read this file when the driver is loaded or the hardware is configured.
Reading from a file from inside kernel-space, however, is highly discouraged.
All user-space/kernel-space interaction should occur through the sysfs interface. This confuses me a little bit for two reasons:
The sysfs file-system is virtual, so every time the kernel is booted, the user (or user-space application) would have to write the configuration data to the sysfs filesystem for the kernel to use it.
The driver probe function is run long before a user-space application would have the the ability to write to sysfs.
Are my assumptions about sysfs correct? How would I be able to get this configuration data to the kernel without having to rely on a user-space application to write it to sysfs?
If use of the ramdisk is possible in your case, you could do the configuration in some script in this ramdisk, like for example:
# insmod module.ko
# cat config.file > /sys/sys_file
Such a solution will allow you to configure quite early your kernel module.
Hi I am new to kernel driver developement. I am using the raspberry pi as my hostI am trying to create an I2C driver for a custom board we have. The custom board will act as the slave. I am confused about how do I go about entering the devices slave address. From what I understand
You need to either have a board setup file which I dont since its a custom board.
You can edit the device tree
Or you can do it in the user space application.
I am not sure where exactly to edit the device tree if I go with the second option. More over I would like to somehow register the slave address in the I2C driver itself. That way I donot need to rebuild the kernel. One method i was looking at was to set the i2c client from the driver code but that was advised by commentators I am not sure why. Any help would be appreciated.
Instantiating Drivers
So I have finally a working way in which I can bind the I2C device without needing a kernel rebuild. I create two driver files(.ko files). One for registering and one for the actual driver.
The way I did it is I got the bus number to which the device was connected.
(You can look into i2c user space code. i2cdetect -y (busnumber) will help you detect which bus number it is)
Once I knew that I created a driver file which would register my device by getting access to the adapter and then registering it. My bus number was 1 and slave address 0x10
static struct i2c_board_info board_info[] __initdata =
{
{
I2C_BOARD_INFO("my_device", 0x10),
},
};
And in the init function of the driver I register the device by
i2c_new_device(i2c_get_adapter(1), board_info[0])
Thats it. Now once you build this insmod the ko file before insmoding the actual driver file and everything should work.
Secondary bootloader for NXP LPC1114/5
Reference NXP app note 10995
Need to use same interrupts in bootloader and user application.
According to NXP AN10995, int vector is only at location 0, and no vector offset reg is available offsetting to other int vector. According to app note, secondary bootloader must redirect processor to handler in user application flash.
Problem/question I have -user application flash will be overwritten during firmware update, so not possible to locate handler there. What is recommended approach, when interrupt will be used by bootloader and user application.
Does this require a conditional redirect, based on the application running (bootloader/user application), such as 1) if bootloader running, re-direct to int handler in bootloader area, 2) if user app running, re-direct to int. handler in user app, or 3) use shared memory between bootloader and user app?
I've coded many boot loaders / firmware upgrades. If you cannot change the interrupt vectors you need to use polled code, i.e.
Copy the firmware upgrader to RAM, or make sure it's located in an area of FLASH that will not be erased
It's likely that the setup for say the UART is already setup to use interrupts, you need to reconfigure all required hardware to use polled methods, i.e. no interrupts.
Disable Interrupts !
Jump to the firmware upgrade function
The firmware upgrade function will not return, it will poll for messages via the UART and erase, program, verify flash section at the request of the client application.
DO NOT ENABLE INTERRUPTS!
When finished, you can reset the Processor using the watchdog to reboot it and execute the new code.
From a general standpoint, I am trying to figure out how to access a platform device from userspace. To be more specific, I have a EMIF controller on and SoC of which I have added to my device tree and I believe it is correctly bound to a pre-written EMIF platform device driver. Now I am trying to figure out how I can access this EMIF device from a userspace application. I have come accross a couple different topics that seem to have some connection to this issue but I cannot quite find out how they relate.
1) As I read it seems like most I/O is done through the use of device nodes which are created by mknod(), do I need to create a device node in order to access this device?
2) I have read a couple threads that talk about writting a Kernel module (Character?, Block?) that can interface with both userspace and the platform device driver, and use it as an intermediary.
3) I have read about the possibility of using mmap() to map the memory of my platform device into my virtual memory space. Is this possible?
4) It seems that when the EMIF driver is instantiated, it calls the probe() fucntion. What functions would a userpace application call in the driver?
It's not completely clear what you're needing to do (and I should caveat that I have no experience with EMIF or with "platform devices" specifically), but here's some overview to help you get started:
Yes, the usual way of providing access to a device is via a device node. Usually this access is provided by a character device driver unless there's some more specific way of providing it. Most of the time if an application is talking "directly" to your driver, it's a character device. Most other types of devices are used in interfacing with other kernel subsystems: for example, a block device is typically used to provide access from a file system driver (say) to an underlying disk drive; a network driver provides access to the network from the in-kernel TCP/IP stack, etc.
There are several char device methods or entry points that can be supported by your driver, but the most common are "read" (i.e. if a user-space program opens your device and does a read(2) from it), "write" (analogous for write(2)) and "ioctl" (often used for configuration/administrative tasks that don't fall naturally into either a read or write). Note that mknod(2) only creates the user-space side of the device. There needs to be a corresponding device driver in the kernel (the "major device number" given in the mknod call links the user-space node with the driver).
For actually creating the device node in the file system, this can be automated (i.e. the node will automatically show up in /dev) if you call the right kernel functions while setting up your device. There's a special daemon that gets notifications from the kernel and responds by executing the mknod(2) system call.
A kernel module is merely a dynamically loadable way of creating a driver or other kernel extension. It can create a character, block or network device (et al.), but then so can a statically linked module. There are some differences in capability mostly because not all kernel functions you might want to use are "exported" to (i.e. visible to) dynamically loaded modules.
It's possible to support mapping of the device memory into user virtual memory space. This would be implemented by yet another driver entry point (mmap). See struct file_operations for all the entry points a char driver can support.
This is pretty much up to you: it depends on what the application needs to be able to do. There are many drivers in the kernel that provide no direct function to user-space, only to other kernel code. As to "probe", there are many probe functions defined in various interfaces. In most cases, these are called by the kernel (or perhaps by a 'higher level "class" driver') to allow the specific driver to discover, identify and "claim" individual devices. They (probe functions) don't usually have anything directly to do with providing access from user-space but I might well be missing something in a particular interface.
You need to create a device node in order to access the device.
The probe function is called when the driver finds a matching device.
For information on platform device API, the following articles could be useful.
The platform device API
Platform devices and device trees
Sometimes I have observed, when an application is run or calls any kernel module functions, respective kernel module is loaded automatically.
I want to build a similar kernel module which will be loaded automatically when my application executes and calls its ioctls.
Actually i want to know, what I need to write in my kernel module so that it will be loaded automatically by my application at runtime.
I looked for it a lot but didn't find anything that is satisfactory.
The keyword to search for is kmod, being the part of the Linux kernel which handles requests for loading kernel modules on the fly.
There are too many details to list in an answer here, but have a look at Linux Device Drivers, 2nd Edition' book, chapter 11 which goes into detail about kernel module autoloading.
Note that module load requests must come from within the kernel. So, if you have a device driver in a custom module but it's not loaded, the kernel has no way of knowing how to match up an ioctl request to your driver. But let's say you have a driver and some ioctl functions split into different modules A and B, it would be possible to insert the main module A to provide the device interface, and then when ioctls were requested of driver A, it could auto load the additional module B containing the ioctl functions using the kmod mechanism