When a problem occurs...

Today, I was thoroughly attacked and would like to jump directly from the office building.

Two weeks later, two weeks spent loading a new controller driver. In the project, this is the underlying USB driver, so it does not work, A chip is a pile of scrap iron. The last week was not very worried, but this week it was totally anxious. The team leader was unable to accept the inability of the whole group of people to work on the film. In this way, I started working overtime every day.

The chips at the underlying layer cannot work, and they have never been exposed to such underlying things, and they cannot be imagined at all. So I began to learn how to debug the driver and kernel. Then I added printk for debugging and saw that the module was gone after init. Then I thought of another driver named dummy_hcd, so I tried it, then we can understand how the master control driver works. After comparison, we know that the problem lies in probe, so we can start watching ldd3 in a painful way. After learning about the preparation of the USB driver, I started the code for nearly 0.1 million lines. I worked overtime every night to lock the office building, and then went home to continue to the painful reading at three points, the conclusion is that the problem is not in the code. Check whether the original code has been changed. Today, I made a major decision to start from the beginning!

Decompress a new kernel, try to keep its appearance, and then compile all the drivers directly into the kernel in the most conservative way. Then, make bzimage and place the image that you think is completely unusable on the board ..

S1r72v17 module init
S1r72v17: ioaddr: 0xc1852000, chip Rev: 0x0010
Gs_bind: controller 's1r72v17 'not recognized
Gs_bind: Gadget serial V2.0 bound
@ (Gs_module_init) usb_gadget_register_driver return [0]
Gs_module_init: Gadget serial V2.0 loaded
Gs_disconnect: Gadget serial disconnected

The information I wanted to see in this dream appeared. At that time, I really didn't want to admit that it was true. My job has also been transformed into a detective. What is it? Why didn't it succeed?

Then, use the kernel that you have been using in the same way ..

S1r72v17 module init
Unable to handle kernel Null Pointer Dereference at virtual address 000000e0
PGD = c0004000
[000000e0] * PGD = 00000000
Internal error: Oops: 805 [#1]
Modules linked in:
CPU: 0
PC is at usb_gadget_register_driver + 0x7c/0x108
LR is at 0x1
PC: [<c013e7fc>] LR: [<00000001>] not tainted
SP: c028bf78 IP: 60000093 FP: c028bf94
R10: 00000000 R9: 00000000 reight: 00000000
R7: c00197e8 R6: 2017001c R5: 00000000 R4: c020d7f8
R3: c01424f8 R2: c020d818 r1: 00000b7c R0: c01d1300
Flags: nzcv irqs on fiqs on mode svc_32 segment Kernel
Control: 53 17f table: 00004000 DAC: 00000017
Process Swapper (PID: 1, stack Limit = 0xc028a194)
STACK: (0xc028bf78 to 0xc028c000)
Bf60: c00197a8 c028a000
Bf80: 00000000 c00197e8 c028bfb0 c028bf98 c00160c4 c013e790 20000013 c00197a8
Bfa0: c028a000 c028bfd0 c028bfb4 c0008a44 c00160bc c023ff0c 00000000 00000000
Bfc0: 00000000 c028bfe0 c028bfd4 c0008ae0 c00089f4 c028bff4 c028bfe4 c001e0a4
Bfe0: c0008acc 00000000 00000000 c028bff8 c0036d48 c001e080 00000000 00000000
Backtrace:
[<C013e780>] (usb_gadget_register_driver + 0x0/0x108) from [<c00160c4>] (gs_module
_ Init + 0x18/0 x1b4)
R7 = c000197e8 R6 = 00000000 R5 = c028a000 r4 = c00197a8
[<C00160ac>] (gs_module_init + 0x0/0x1b4) from [<c0008a44>] (do_initcils + 0x60/0 XD
8)
R5 = c028a000 r4 = c00197a8
[<C00089e4>] (do_initcils + 0x0/0xd8) from [<c0008ae0>] (do_basic_setup + 0x24/0x28
)
R7 = 00000000 R6 = 00000000 R5 = 00000000 r4 = c023ff0c
[<C0008abc>] (do_basic_setup + 0x0/0x28) from [<c001e0a4>] (init + 0x34/0x134)
[<C001e070>] (init + 0x0/0x134) from [<c0036d48>] (do_exit + 0x0/0x3b8)
R4 = 00000000
Code: 1a000002 ebfbd8dd e3e00015 e91ba8f0 (e58520e0)
<0> kernel panic-not syncing: attempted to kill Init!

Or old errors.

Now I think of the simplest exclusion method. Replace the files of the wrong kernel with the kernel one by one, replace the compiled one, and load the file to see when an error message will appear.

So compile, load, around 20 times, finally found the culprit -- ../linux-2.6.14.6/driver/USB/gadget/makefile and kconfig

These two files I replaced last and thought were the least likely to cause errors. They left me suffering for two weeks.

However, the content in these two files is the same in the source code of the two kernels. The same script language is added, but one is successful, and the other is failed. Copy these two files to the failed kernel to solve the problem. Why, why? The same file contains exactly the same content, but there is such a thing.

The last thing that comes to mind is the hidden symbols. Is it true that some hidden symbols are not visible. In this way, all the tabs and space characters in the two files are displayed. At last, there is a space at the end of a line in the makefile in the failed kernel !!!

My day, will this cause an error? Even if the error occurs, how can it be indicated that the kernel cannot get handler when probe is returned, and a null pointer is returned, leading to system crash. I had collapsed and wanted to jump out of the building (my real thoughts at that time ).

Although it is depressing, it is worthwhile to learn to solve problems in adversity. However, I am too tired to use my mind. I want to take a rest. Fortunately, tomorrow, the company organized to go to a resort, and life was always like this, but the bitterness was full of challenges and fun.