General methods for device-driven commissioning and porting

Linux low-level software has been working for two years, to calculate the post-graduate study of the underlying software, add up also nearly four years. Slowly found it necessary to summarize some general methods. Because the general method has the macroscopic guidance significance, after the debugging and the transplant drive, the regular aftertaste these general method can prevent oneself to make the same mistake, then avoids detours, completes the work with the highest efficiency.

When it comes to the underlying software, we generally think of bootloader, BSP, device driver, Linux kernel, and so on. This article will focus on the general approach to debugging Linux device driver. In addition, the method of device-driven porting is given in the form of a supplemental description at the end of the article.

Note that the general method here is not a fixed routine, which means you don't have to read it as a textbook. You only need to choose some of these steps flexibly depending on the situation.

In general, before you perform a device-driven commissioning, you must have the following conditions:

L device-driven code and application layer test software (or code)

Because the ultimate goal of your drive is to operate on top-level applications. Therefore, a test application for the driver is required. The application layer test software here is usually provided by the supplier, or the existing application of the system can be used, if not, you must write it yourself.

L the datasheet, specifications and related information of the equipment you want to debug

As much as possible to get detailed chip-related information and related instructions, because these are your subsequent debugging drive guidance.

l schematic and patch diagram of the Development Board

In general, you may not need a patch map, but if your hardware engineer does not support you enough, you will need a patch map of the board. There are several possible reasons for this:

(1) If it is a flying line over the module, and you are not sure that the hardware engineer's operation is completely correct, is not every line is connected to the right, then you must get the patch diagram and schematic, and then the board on the fly line a line of check again. If it's accurate, then you're going to start.

(2) When your hardware engineer does not provide you with the hardware board pin specific on the board where the instructions, you must get a patch map.

(3) In addition, the regular patch diagram helps to improve the hardware quality of a driver engineer.

L Multimeter, oscilloscope

Multimeters and oscilloscopes are essential, and secondly, you may use spectrum analyzers and logic analysers as needed.

ok! When you get this information, you'll be able to make a drastic device-driven commissioning. In general, device-driven debugging goes through the following steps:

First, add device-driven code into kernel

It is important to note that different scheme providers give different methods of adding. For example, for MediaTek scenario providers, adding device-driven methods is not the same as generalization,

Because the architecture of MediaTek is different from kernel traditional architecture such as telechips, Qualcomm and so on. So, for a special supplier like MediaTek, you have to follow a set of add-on-drive processes (MTK support is good and SOP is generally provided). Traditional architecture, it is very simple, usually involves a few steps:

L New Device driver directory

L Add header File

L CREATE the makefile of the current directory

L CREATE the makefile of the upper directory

L add kconfig option in upper directory

L ADD the corresponding item in the board file.

If you do not want to use Menuconfig configuration every time, you can add a compile item in Kernel/arch/arm/configs/xxx_defconfig

Specific examples I do not write, Google a lot of, this article will not involve too much detail issues.

Second, so that the added device driver can be compiled through

After the device driver is added, in general, you need to add, delete, modify some content, to ensure that its compilation pass. If it is debug, this may not change much, because the driver text

Pieces are generally provided by the original chip, they have been modified by the basic can be compiled through. But if it is a transplant, the amount of energy spent here is generally relatively large, which is mentioned in the additional instructions later in this article.

Third, check the device driver is normal initialization

To do this, you need to check to see if the device driver can be initialized smoothly, which is simple, you just need to add a print to the device-driven probe function or the init function.

Information can be seen in the serial port whether there is printing, if not printed, the driver is not initialized at all. At this point, you should:

L First, you quickly ran over to ask and you cooperate with hardware engineer: "Hi, I this piece of board, that XXX chip is affixed?" "or ask them:" Are these fly lines connected OK? ”。 It is necessary to ask these questions because there is a good chance that the hardware is not ready, or that the hardware connection is inherently problematic. So, to avoid wasting time, you have to ask them.

Second, if the chip is indeed affixed and the hardware is connected to the right (later you do not rest assured that you have checked again), this time the problem is you. Immediately check the device driver add whether there is any problem, whether the board file is not modified, whether the driver itself is not registered well and so on.

First, check whether the application can be used properly

If the driver is properly initialized, then you start checking to see if the device driver's application is working properly (or writing a device-driven test application). If you can use normal, then you are too lucky, this means that the original chip for you to consider very thoughtful, you can save n more time to do other things.

Unfortunately, often things don't go so well, and when you check the application, you find that the application doesn't respond properly--for example, when you've worked hard to add the camera driver to kernel and successfully initialized, you're excited to enter the system to open the camera discovery: black screen! You are depressed, but depressed can not solve the problem, this time the real so-called device-driven "tune" and "Try" to come. Hurry to find a multimeter and an oscilloscope.

Second, the device-driven "tune" and "Test"

The so-called "tune", you are based on the device chip datasheet, master control datasheet, related specifications and other data, as well as observation and measurement results, constantly drive code into the device

Add, delete, and modify rows.

The so-called "test" is that you add, delete and modify at the same time to continue to:

L Observe the feedback information through the serial port;

l Measurement of each power supply pin voltage through a multimeter;

L measure each pin by oscilloscope on the clock (input and output) frequency of the chip ( including the measurement of crystal oscillator ), the waveform of the data signal, the waveform of some kind of bus signal, etc.

Observe the device's power-up sequence, data interaction timing, and so on (refer to datasheet).

L test the driver by testing the application and repeatedly observe the operating state of the device driver.

Testing is not just about testers, you have to make sure that the driver you are debugging can run stably before you can commit the code and send a lot of tests to the tester. Test your own debug device drivers in the following ways:

(1) Testing with existing applications within the system

This is the most straightforward test, and it saves you the time to write your own test program.

(2) Write your own Linux application to test the driver

If you are not comfortable with the existing applications of the system, or are not satisfied, write your own test drive.

(3) using the Read and write functions of the proc or SYS file system

If you add the read and write functions of the proc or SYS file system to the device driver, you can manually test the device-driven parameters at the command line via the cat or echo command.

Note: The above test method is I used to use, in addition to these, there are some other test methods I did not list out, interested in the words can Google a bit.

In addition, you should develop a good habit, that is, when measuring each pin, you'd better create a Excel table, the voltage and waveform of each pin are recorded, in order to N The comparison between multiple revisions is also more of a function of memo.

The process of "tuning" and "testing" here is the most time-consuming and the most critical step in device-driven debugging, so you should take this step with great patience. It should also be noted that device-driven debugging is not only a matter of your own, sometimes you have to work hard for one weeks is not necessarily able to handle. Therefore, while debugging, you must have a hardware engineer to cooperate with you, because the drive is not working properly and it is likely that the hardware design flaws caused. In addition, do not behind closed doors, after all, you in a large development team inside, you need to timely and colleagues to communicate effectively, avoid detours. Finally, if there is still a problem, you have to invite the original chip fae come over.

Additional Information

To perform a device-driven migration, in general, you must have the following conditions:

An existing driver code for a chip similar to or similar to the current device chip.

This sentence is a bit of a mouthful, for instance. For example, if you are porting a driver to G-sensor (bma250e), you should now try to

To find the driver code corresponding to the chip bma250e similar chip. At this time, you happy to find, eh?! There's also a BMA250 code on hand, so lucky. At this point you can do the porting based on the BMA250 code. But sometimes it's not so lucky. At this time you can completely find other types of g-sensor ah, if you do not have BMA250 code, but you have a ADXL345 code, it is also possible, you can be based on ADXL345 code to do the porting. Why choose the driver code corresponding to the chip similar to the current device chip, the reason is four words "improve efficiency".

L detailed datasheet of the current chip, as well as the relevant instructions for the chip

L schematic diagram of the Development Board

If there is a pads version of the schematic and patch diagram, it is the best, convenient to measure the parameters of the pin later.

L Multimeter and Oscilloscope

This is an essential device for debugging, porting, and developing device drivers.

With these conditions in place, go on to the first and second steps in the article, especially in the second step, you may have to pay a great deal of effort to modify the driver files for your current development Board. Modifications typically include i\o configuration, interrupt settings, bus configuration (such as I²c, SPI, SDIO, etc.), configuration of registers, and even the framework of the driver code. When you're done with this step, proceed to the third step mentioned above, and then walk down one step at a glance.

Summarize the drive transplant in a nutshell. The drive's migration is actually: " by adding, deleting and modifying, so that the existing chip similar to the driver code can be on the target chip and the target board to run up and run very stable!" "

General methods for device-driven commissioning and porting