I'm writing a linux driver for a custom RF board. The RF board have an EEPROM contain some information and I want to load this information to my driver. Linux kernel already has EEPROM module, this module read all memory of the EEPROM and export to userspace by sysfs.
Can I read this sysfs to get EEPROM's memory? If not, how can I get this information? Thank you.
There are userspace applications which read the data exported by the eeprom module. So if you know Perl a bit, I suggest that you will consider looking at the following i2c-tools link:
https://github.com/groeck/i2c-tools/tree/master/eeprom
Rami Rosen
Related
I built a certain driver as module (m) for Linux, the spi-imx by NXP. Nontheless, Linux probes this driver when booting. I'm struggling to find out what process/other module/driver requests this spi-imx driver. A depmod does not show any dependencies between the spi-imx an other modules (except for the spidev as submodule).
After some research, I found out that Linux automatically (?) calls modprobe when it detects a new device. So does Linux actually call modprobe because the ecSPI'S status in the device tree as "okay"? If so, how can I prevent this? I would like to dynamically load the spi-imx from a user space application via modprobe. The story behind it: a coprocessor uses this SPI line in parallel to the Linux boot process. This interferes of course and interrupts the coprocessor's use of the SPI line. When the coprocessor has finished its transfer via SPI (a boot mechanism as well), it should hand over the SPI line to Linux.
I'm very thankful for any kind of tips, links, hints and comments on this.
Thanks a lot for the answers. As you guys mentioned, I also found out that Linux itself probes the device if present ("okay").
One possible solution is to complete cut off the modprobe call via an entry like "install spi-imx /bin/false" in the *.conf file. But that makes it impossible to load the driver via modprobe, for Linux and for user space.
"blacklist spi-imx" inside a *.conf located at /etc/modprobe.d/ is the way to prevent Linux from probing the driver when booting. After that, a modprobe from user space can successfully load the driver afterwards.
Thanks again & best regards
What would be the simplest and most portable way (in the sense of only having to copy a few files to the target machine, like procdump is) to generate a kernel dump that has handle information?
procdump has the -mk option which generates a limited dump file pertaining to the specified process. It is reported in WinDbg as:
Mini Kernel Dump File: Only registers and stack trace are available. Most of the commands I try (!handle, !process 0 0) fail to read the data.
Seems that officially, windbg and kd would generate dumps (which would require kernel debugging).
A weird solution I found is using livekd with -ml: Generate live dump using native support (Windows 8.1 and above only).. livekd still looks for kd.exe, but does not use it :) so I can trick it with an empty file, and does not require kernel debugging. Any idea how that works?
LiveKD uses the undocumented NtSystemDebugControl API to capture the memory dump. While you can easily find information about that API online the easiest thing to do is just use LiveKD.
I'm trying to get MSI-X working on an iMX6 (Freescale/NXP/Qualcomm) CPU in Linux v4.1 for a PCIe character device driver. Whenever I call either pci_enable_msix() or pci_enable_msix_range() or pci_enable_msix_exact() I get an EINVAL value returned. I do have the CONFIG_PCI_MSI option selected in the kernel configuration and I am also able to get single MSI working with pci_enable_msi(), but I cannot get multiple MSI working either.
I have tested my driver code on an Intel i7 running kernel v3 with the same PCIe hardware attached and I was able to get MSI-X working without any problems so I know my code is correctly written and the hardware is correctly functioning.
When running on the iMX6 I can use lspci -v to view that the hardware has MSI-X capabilities and see the number of IRQs it allows. I can even get the same correct number in my driver when calling pci_msix_vec_count().Questions
Are there any other kernel configuration flags I need to set?
Is there anything specific to the iMX6 CPU I need to consider?
Does anyone have any experience with the iMX6 and either MSI-X or
multiple MSI?
My question is how operating system loads
User space application to RAM. I know how
Bootloader works when we first turn computer on Bios simply reads 512 kb data till aa55 bootloader signature and loads bootloader to ram. Do regular userspace programms are handled in this way? If yes how? Because bootloader activated by bios and how user space program handled by operating system? More specifacally how execv() load program to RAM and start execution point for user space ?
Thanks in advance
Userspace programs are not handled like the bios, the Kernel will be involved in running a userspace program.
In general:
When a program is executed in shell, the shell will invoke system calls to create a new task in a new address space, read in the executable binary, and begin executing it.
To understand the details, you need to understand:
The elf format. Of course there are also other formats which can be used in Linux, elf is just the most common one, and a good starting point. Understanding elf will help you understand how the kernel loads the executable binary into memory precisely.
Linux process management; this will help you to understand how a program starts to run.
Reading the related codes in the kernel. fs/exec.c will be of great help.
The procedure varies among operating systems. Some systems have a background command interpreter that exists through the life of a process and within the process itself. When a program is run, the command interpreter stays in the background (in protected from user mode access). When the program completes, the command interpreter comes to the foreground and can run another program in the same process.
In the Eunuchs-world, the command interpreter is just a user-mode program. Whenever it runs a program it kicks off another process.
Both of these types of systems use a loader to configure the process address space for running a program. The executable file is a set of instructions that define how to lay out the address space,
This is significantly different from a bootloader. A bootloader blindly loads a block of stored data into memory. A program loader contains complex instructions for laying out a process address space that include handling shared libraries and doing address fixups.
Using ioctl interface various info can be fetched. How do you get extra info like product name, class, vendor name, subsystem name etc?
There are couple of command line tools available such as:
1. lshw -C network
2. detecting nic and ports on systems loaded with linux
You can start a process and get the result but Is there any raw c/c++ method to get above mentioned information?
Cheers
Prashant
All the information you seek is in /sys/bus/pci/devices/*/*:
class
device
driver
modalias
subsystem
subsystem_device
subsystem_vendor
vendor
You can see how lspci(8) reads through the files with strace -o /tmp/out lspci, /tmp/out will have plenty of details. (I don't know any easy way to restrict this to just the NICs; I think both lspci(8) and the kernel have hard-coded lists of PCI ID -> name mappings.)
Look in sysfs or procfs, unfortunately this information has a habit of being changed and so cannot be relied on :(