How do we test the modules and drivers(like USB,I2C,HDMI etc..) of a Linux kernel running in a target board? is there any tools/frameworks doing the job? i found this thread.Can anyone suggest me the best one? thanks in advance...
-
What is your actual goal? Which exactly part of kernel you are intended to test? And what exactly you want to achieve by this testing? – Sam Protsenko May 19 '15 at 09:41
-
@SamProtsenko .. my aim is to ensure that all the device drivers and inserted modules working fine in my machine. in other words i want to test the functionalists of the drivers with any automated testing framework. my linux kernel is running in an ARM based (say) target board like pandaboard – zappy May 19 '15 at 10:21
1 Answers
I doubt that there is any solution exists for this purpose. Each maintainer should test his driver, and how each maintainer does it -- it's up to him. The thing is, it would involve a ton of hardware in order to test all the drivers in kernel.
You are using Panda board, which is OMAP-based board, and the general approach for testing drivers on OMAP-based platforms is to use DDT (Device Driver Test). See DDT at OmapPedia and DDT repository. Btw, you should hurry to clone that DDT repository from Gitorious, because Gitorious is closing in the end of the May and I didn't find any clones of that repo.
Further, if you are interested in running Android on your board, you should run CTS (Compatibility Test Suite).
All that I listed above were used by our testing team when I was working for TI, so I think it should be applicable nowadays as well.
UPDATE
Also I remember that our testers were using this device: phidget. You may need to acquire one for testing purposes.
UPDATE 2
Take a look at Linaro's LKFT (Linux Kernel Functional Test). It's more about testing syscalls from user-space, so maybe not strictly relevant to your question, but still worth mentioning. It runs kselftest (can be found in kernel source code) and LTP project mainly. You can run the same tests for your board. It can be also automated using Jenkins and LAVA.

- 14,045
- 4
- 59
- 75
-
1Test suites you mentioned don't seem to cover actual hardware you are using. They only provide test environment and maybe some generic tests. DDT provides testing of the actual hardware. So I'd recommend you to start with DDT. It may need some adaptation for your actual hardware and your kernel version though. But it still seems like best solution for your task for now. – Sam Protsenko May 19 '15 at 11:40
-
1See also [these slides](http://www.slideshare.net/joujiahe/introduction-of-unit-test-on-android-kernel). – Sam Protsenko May 19 '15 at 11:42
-
thank you so much for your help. please let me ask for one more clarification..... suppose i have build a kernel(Yocto methord) for some target board.Obviously the file system should contain some drivers and BSPs for the target board.... what if i want to ensure the reliability of these drivers ? shall i use the above tool (DDT) for the same? DDT is only applicable for omap based board? – zappy May 19 '15 at 14:28
-
Yes, DDT is intended for exactly this reason: check reliability of drivers. And it should be run on working system. And yes, it's intended for OMAP-based boards (for OMAP specific drivers). I mentioned it in the first place because you said you have Panda board. Of course, DDT is not covering 100% of drivers functionality, so manual testing should be done as well. And second thing should be mentioned -- you should check if DDT covers all of your devices. If not -- you should add tests for your devices to it. – Sam Protsenko May 19 '15 at 14:56