I have been doing embedded development for more than ten years, and I have done everything, neither good nor bad. Looking back, I feel like I have done nothing, so on a whim, I compiled my work over the years into a document and published one article every day. Remember the past.
I can't remember when I started writing the first Linux driver. I just felt that it was very confusing at the time. I only know how to write a driver code, but how can this code enter our arm board? For a person who is new to writing drivers, sometimes it is really a bit messy, well, it is just messy.
Now, let's list the requirements of the driver. Yes, we need to list the requirements first, and then consider how to implement them. For most drivers, well, these are basically the requirements.
1. How to make our driver run on our Arm board?
Yes, the driver written must run on the target machine. So what kind of driver can run on our target machine? For the arm version, the driver must be compiled by a cross-compilation tool released by the chip manufacturer in order to run on our target machine. If you compile it with other compilation tools, it will generally not run, so please note that first you need Corresponding compilation tools. Then compile your driver before you can run it.
2. How to compile the driver into a kernel, how to compile the driver into a module, or not to compile the driver?
For drivers, there are two forms of existence in the system. One is compiled into the kernel. At this time, we do not need to manage them in the application layer or script, we only need to call them in the application layer. The other one is compiled into a module. We need to call insmod to insert the driver compiled into the module. Otherwise, you will not be able to use this driver. Speaking of compiling into the kernel, modules, or not compiling, did you quickly recall that when we trimmed the kernel, we used make menuconfig and then brought up an interface, and we can perform operations on this interface, that’s right , just make menuconfig, and then you can operate. First of all, we need to know why the make menuconfig operation displays an interface and why the contents in the interface appear. It will never fall from the sky. In fact, when make menuconfig configures the kernel, it will read the kconfig file, which describes the menu items on the interface. So we need to display our driver on this menu, then we have to have such a kconfig. This kconfig has one item used to describe our driver. After the configuration is completed using make menuconfig, it will generate a .config file. So here comes the question, in kconfig I configure it to be compiled into the kernel or compiled into a module. Is there any difference in it in .config? Of course it's different, otherwise one would have entered the kernel and the other would have become a module! But their differences are very few, well, very few, that is, one is m and the other is y. For example, if we write a simple test driver, we define it as config MY_TEST_DRIVE in kconfig. If we select it and compile it into module, then there will be such an item CONFIG_MY_TEST_DRIVE = m in the .config file; If we select to compile into the kernel, then there will be such an item CONFIG_MY_TET_DRIVE = y; in the .config file; So far, well, It is not directly related to our driver. So far, it has only generated some configuration files. If we want to produce our driver, we must need make. make, Who will make look for, of course, makefile. At this time, our other protagonist, makefile, is waiting. Makefile is a role directly related to the driver code we wrote. The kconfig and .config we talked about earlier are all Distant relatives. Think about it, since the makefile ultimately determines our driver, does it compile the driver into the kernel or into a module? It definitely needs to know, who told him, remember that he has a distant relative .config, one m and one y get that distant relative. So we need to use it in makefiel obj-$(CONFIG_MY_TEST_DRIVE) +=my_test.o. Hmm. At this point our driver was born.
Let's go back and continue walking. We wrote a driver file my_test.c. We need to compile it into a driver that can run on our target machine, so we need corresponding compilation tools. After having this corresponding tool, we need to write a makefile for it to compile. The makefile needs to know whether it is compiled into a kernel or a module, so it needs to find .config. Well, how did it get .config? It is generated by reading kconfig information when make menuconfig configures it.