3.3.5. LTP-DDT Validation¶
This work is licensed under the Creative Commons Attribution-Share Alike 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/us/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
LTP-DDT is a test application used by Texas Instruments to validate Linux releases.
LTP-DDT uses LTP’s test infrastructure, such as:
- Test execution drivers (PAN)
- Top-level test scripts (i.e. runltp)
- Same Folder Hierarchy and test case definition format
LTP-DDT test cases are LTP test cases and vice-versa.
The main additions or ‘enhacements’ of LTP-DDT compared to LTP are:
- PLATFORM files. LTP-DDT uses PLATFORM files to identify platform hardware and software features.
- OVERRIDE mechanism. Default test case parameters are automatically overridden based on PLATFORM features.
- ATOMIC scripts. Code reuse is foster by writing scripts that implement small well-defined actions. Test scripts rely on these atomic scripts to execute their actions.
- AUTOMATIC FILTERING. Test cases are filtered based on the test requirements and the PLATFORM features.
- TESTCASE ANNOTATIONS. Test scenario files are annotated with following annotations @name, @desc, @requires and @setup_requires. The @requires and @setup_requires are used to select test cases at run time based on the PLATFORM features.
- All LTP-DDT test cases and test code reside in <testcases-root>/ddt/ and <testcode-root>/ddt/ folders respectively.
- Easy to use (automatically filter test cases not applicable for platform)
- Easy to support new platforms (just define the platform file)
- Test cases can be easily wrap or imported to Test Management Systems (Use of testcase annotations facilitates this)
- High Code Reuse (atomic scripts and test scripts are reused and parameters are adjusted on the fly)
- cpu hotplug
- gstreamer (multimedia)
- latency under different use cases (important for RT kernel)
- memory tests
- mm (ltp’s memory management)
- pipes (ltp)
- power management
- programmable real-time unit (PRU)
- realtime (ltp)
- scheduler (ltp)
- sgx (graphics)
- syscalls (ltp)
- system (use-cases, e.g. multiple tests running in parallel)
- timers (ltp)
- usb host (multiple tests with different classes)
- usb device
Device Under Tests Supported
LTP-DDT has been used on following devices:
am170x-evm am335x-ice am389x-evm am43xx-hsevm beagleboard dm365-evm dra71x-evm dra7xx-hsevm k2g-evm omap3evm ti811x-evm am180x-evm am335x-sk am437x-idk am571x-idk beaglebone dm368-evm dra71x-hsevm dragonboard410c k2g-ice omap5-evm ti813x-evm am181x-evm am3517-evm am437x-sk am572x-idk beaglebone-black dm385-evm dra72x-evm hikey k2hk-evm omapl138-lcdk am335x-evm am37x-evm am43xx-epos am57xx-evm da830-omapl137-evm dm6467-evm dra72x-hsevm k2e-evm k2l-evm tci6614-evm am335x-hsevm am387x-evm am43xx-gpevm am57xx-hsevm da850-omapl138-evm dm813x-evm dra7xx-evm k2e-hsevm
Host Platform Requirements
Linux host is required :
- for compiling LTP-DDT.
- to host the NFS server to boot the EVM with NFS as root filesystem
- to run host utilities - e.g.iperf
Host Software Requirements
- GCC Tool chain for ARM
- Serial console terminal application
- TFTP and NFS servers. NFS server is required only in case of NFS boot.
- iperf utility on the host.
LTP-DDT relies on other open source test tools. The following test tools must be available in the target filesystem to run ltp-ddt:
- alsa utilities
- rt-tests (cyclictest)
There is an Arago/OE recipe here that builds a filesystem image w/ the above tools plus:
Clone the project
git clone http://arago-project.org/git/projects/test-automation/ltp-ddt.git
- Run DDT tests the same way you run LTP tests. Use ltprun program and pass to
it the test scenario file in the runtest directory (option -f) to run and the platform (option -P) to use. For example:
./runltp -P am180x-evm -f ddt/lmbench
- In addition to selecting test scenarios using -f option, users can also
- The runltp script have lot of options. Some useful ones for stress tests are:
-t DURATION: Define duration of the test in s,m,h,d. -x INSTANCES: Run multiple test instances in parallel. -c <options>: Run test under additional background CPU load -D <options>: Run test under additional background load on Secondary storage -m <options>: Run test under additional background load on Main memory -i <options>: Run test under additional background load on IO Bus -n : Run test with network traffic in background.
Please refer to README-DDT file section 8) for more details.
- Running NAND Sanity Tests
– Run all NAND sanity tests
Using below command to run NAND sanity tests.
./runltp -P <platform> -s "NAND_S_" -S skiplist
If there are more than one flash filesystem supported, say, jffs2 and ubifs and you don’t run jffs2 test cases. You need create a file called ‘skiplist’ (this filename could be anything) and put to-be-skipped test case tag in this file. Here is the content of skiplist to skip jffs2 test cases.
@ cat skiplist _JFFS2
– Run NAND performance test
./runltp -P <platform> -s "NAND_L_PERF" -S skiplist