IMX6Q Linux BSP Unit Test User Manual

ASRC

FSL-UT-ASRC-001

Name	Description
Summary	Test sample rate converter for ASRC driver
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_ASRC=y CONFIG_MXC_ASRC=y`
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	run the following command `$ unit_tests/autorun-asrc.sh`
Expected Result	log output: All tests passed with success The sound is heard clearly and properly from headphone of SSI or ESAI interface

FSL-UT-ASRC-002

Name	Description
Summary	Test suspend/resume for ASRC driver
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_ASRC=y CONFIG_MXC_ASRC=y`
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	make OS into suspend mode `$ /unit_tests/rtcwakeup.out -d rtc0 -m mem -s 6` after resume, re-run ASRC test cases
Expected Result	all ASRC test cases pass

CAAM

FSL-UT-CAAM-001

Name	Description
Summary	CAAM DES test
Automated	No
Kernel Config Option	CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_DEV_FSL_CAAM=y CONFIG_CRYPTO_DEV_FSL_CAAM_RINGSIZE=9 CONFIG_CRYPTO_DEV_FSL_CAAM_INTC=y CONFIG_CRYPTO_DEV_FSL_CAAM_INTC_COUNT_THLD=255 CONFIG_CRYPTO_DEV_FSL_CAAM_INTC_TIME_THLD=2048 CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API=y
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Build Testing Module in Cryptographic API as module. modprobe tcrypt.ko. `$ insmod tcrypt.ko mode=3`
Expected Result	When kernel boots, I can see some caam initialize log: caam caam.0: device ID = 0x0a16010000000000 caam caam.0: job rings = 2, qi = 0 caam caam.0: authenc-hmac-sha1-cbc-aes-caam caam caam.0: authenc-hmac-sha256-cbc-aes-caam caam caam.0: authenc-hmac-sha512-cbc-aes-caam caam caam.0: authenc-hmac-sha1-cbc-des3_ede-caam caam caam.0: authenc-hmac-sha256-cbc-des3_ede-caam caam caam.0: authenc-hmac-sha512-cbc-des3_ede-caam caam caam.0: authenc-hmac-sha1-cbc-des-caam caam caam.0: authenc-hmac-sha256-cbc-des-caam caam caam.0: authenc-hmac-sha512-cbc-des-caam caam caam.0: cbc-aes-caam caam caam.0: cbc-3des-caam caam caam.0: cbc-des-caam Then test the functionality. root@freescale /$ insmod tcrypt.ko mode=3 insmod: can’t insert tcrypt.ko: Resource temporarily unavailable Note: If you want to see evidence that CAAM is processing tests, look at /proc/interrupts, you will see incrementing counts for 2 caam-jr entries every time you run the test. When tcrypt runs without issue, it will exit with a resource usage error. This is correct behavior; it uses the error to tell insmod to unload the module, so you can re-load/re-run it without manual intervention.

FSL-UT-CAAM-002

Name	Description
Summary	CAAM 3DES test
Automated	No
Kernel Config Option	CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_DEV_FSL_CAAM=y CONFIG_CRYPTO_DEV_FSL_CAAM_RINGSIZE=9 CONFIG_CRYPTO_DEV_FSL_CAAM_INTC=y CONFIG_CRYPTO_DEV_FSL_CAAM_INTC_COUNT_THLD=255 CONFIG_CRYPTO_DEV_FSL_CAAM_INTC_TIME_THLD=2048 CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API=y
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Build Testing Module in Cryptographic API as module. modprobe tcrypt.ko. `$ insmod tcrypt.ko mode=4`
Expected Result	When kernel boots, I can see some caam initialize log: caam caam.0: device ID = 0x0a16010000000000 caam caam.0: job rings = 2, qi = 0 caam caam.0: authenc-hmac-sha1-cbc-aes-caam caam caam.0: authenc-hmac-sha256-cbc-aes-caam caam caam.0: authenc-hmac-sha512-cbc-aes-caam caam caam.0: authenc-hmac-sha1-cbc-des3_ede-caam caam caam.0: authenc-hmac-sha256-cbc-des3_ede-caam caam caam.0: authenc-hmac-sha512-cbc-des3_ede-caam caam caam.0: authenc-hmac-sha1-cbc-des-caam caam caam.0: authenc-hmac-sha256-cbc-des-caam caam caam.0: authenc-hmac-sha512-cbc-des-caam caam caam.0: cbc-aes-caam caam caam.0: cbc-3des-caam caam caam.0: cbc-des-caam Then test the functionality. root@freescale /$ insmod tcrypt.ko mode=4 insmod: can’t insert tcrypt.ko: Resource temporarily unavailable Note: If you want to see evidence that CAAM is processing tests, look at /proc/interrupts, you will see incrementing counts for 2 caam-jr entries every time you run the test. When tcrypt runs without issue, it will exit with a resource usage error. This is correct behavior; it uses the error to tell insmod to unload the module, so you can re-load/re-run it without manual intervention.

FSL-UT-CAAM-003

Name	Description
Summary	CAAM AES test
Automated	No
Kernel Config Option	CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_DEV_FSL_CAAM=y CONFIG_CRYPTO_DEV_FSL_CAAM_RINGSIZE=9 CONFIG_CRYPTO_DEV_FSL_CAAM_INTC=y CONFIG_CRYPTO_DEV_FSL_CAAM_INTC_COUNT_THLD=255 CONFIG_CRYPTO_DEV_FSL_CAAM_INTC_TIME_THLD=2048 CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API=y
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Build Testing Module in Cryptographic API as module. modprobe tcrypt.ko. `$ insmod tcrypt.ko mode=10`
Expected Result	When kernel boots, I can see some caam initialize log: caam caam.0: device ID = 0x0a16010000000000 caam caam.0: job rings = 2, qi = 0 caam caam.0: authenc-hmac-sha1-cbc-aes-caam caam caam.0: authenc-hmac-sha256-cbc-aes-caam caam caam.0: authenc-hmac-sha512-cbc-aes-caam caam caam.0: authenc-hmac-sha1-cbc-des3_ede-caam caam caam.0: authenc-hmac-sha256-cbc-des3_ede-caam caam caam.0: authenc-hmac-sha512-cbc-des3_ede-caam caam caam.0: authenc-hmac-sha1-cbc-des-caam caam caam.0: authenc-hmac-sha256-cbc-des-caam caam caam.0: authenc-hmac-sha512-cbc-des-caam caam caam.0: cbc-aes-caam caam caam.0: cbc-3des-caam caam caam.0: cbc-des-caam Then test the functionality. root@freescale /$ insmod tcrypt.ko mode=10 insmod: can’t insert tcrypt.ko: Resource temporarily unavailable Note: If you want to see evidence that CAAM is processing tests, look at /proc/interrupts, you will see incrementing counts for 2 caam-jr entries every time you run the test. When tcrypt runs without issue, it will exit with a resource usage error. This is correct behavior; it uses the error to tell insmod to unload the module, so you can re-load/re-run it without manual intervention.

CAN

FSL-UT-CAN-001

Name	Description
Summary	CAN driver suspend and resume
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Ensure CAN can enter suspend `echo standby > /sys/power/state` Press one key to resume Retest CAN function again
Expected Result	Those operations should be successful.

FSL-UT-CAN-002

Name	Description
Summary	CAN wakeup
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Note: The CAN self-wakeup function is enabled by default. Active CAN interface `ip link set can0 up type can bitrate 125000` Enter Low power mode `echo mem > /sys/power/state` Tie CAN’s Tx to GND to wakeup the systerm. `Alternatively user can use another CAN to send frames to the sleep can to wakeup it.`
Expected Result	Those operations should be successful.

FSL-UT-CAN-003

Name	Description
Summary	CAN send message
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Note If there’s no KVASER CAN, can protocal analyzer, user can use procedure B for test. For kernel earlier than 2.6.38, user still needs use the old way as before to test can. Procedure A Connect CAN interface(can0) on board with KVASER CAN Active CAN interface `ip link set can0 up type can bitrate 125000` Run cansend to transmit one message. `cantest can0 1F334455#1122334455667788` Check the data that KVASER CAN recieved. Procedure B Get a FlexCAN loop-back connector or cable lines and connect it between CAN1 and CAN2. Active CAN interface `ip link set can0 up type can bitrate 125000` `ip link set can1 up type can bitrate 125000` Put can0 into receive mode in a background process `cantest can0&` Send test packet from CAN1 to CAN0 `cantest can1 1F334455#1122334455667788`
Expected Result	The can0 should print the received frame 1F334455#1122334455667788 from can1.

FSL-UT-CAN-004

Name	Description
Summary	CAN receive message
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Note If there’s no KVASER CAN, can protocal analyzer, user can use procedure B for test. For kernel earlier than 2.6.38, user still needs use the old way as before to test can. Procedure A Connect CAN interface(can0) on board with KVASER CAN Active CAN interface `ip link set can0 up type can bitrate 125000` Running cantest to receive messages `cantest can0&` Configure KVASER CAN to send data to can0 Check the data received. `The can0 should output the data received.` Procedure B The same as FSL-UT-CAN-003 procedure B.
Expected Result	The can should receive data successfully.

DCP

FSL-UT-DCP-001

Name	Description
Summary	DCP test on i.mx50 and i.mx6sl.
Automated	No
Kernel Config Option	CONFIG_IMX_HAVE_PLATFORM_IMX_DCP=y CONFIG_CRYPTO_DEV_DCP=y
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	For AES (ECB & CBC) encryption: "modprobe tcrypt mode=10" For SHA1 hash: "modprobe tcrypt mode=2" For SHA256 hash: "modprobe tcrypt mode=6"
Expected Result	No error messages containing ecb(aes) or cbc(aes). No error messages containing sha1. No error messages containing sha256.

EPDC

FSL-UT-EPDC-001

Name	Description
Summary	EPDC frame buffer test for display updates
Automated	YES (But manual observation is required to confirming correct updates on display panel)
Kernel Config Option	`CONFIG_FB=y CONFIG_FB_MXC=y CONFIG_FB_MXC_EINK_PANEL=y CONFIG_MFD_MAX17135=y CONFIG_REGULATOR_MAX17135=y CONFIG_MXC_PXP=y CONFIG_DMA_ENGINE=y ...`
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	EPDC fb test for display updates. Features tested (no correlation to EPDC test numbers): RGB565, Y8 framebuffer format 0, 90, 180, 270 degree framebuffer rotation Framebuffer panning Use of the alternate framebuffer Auto-waveform mode selection Automatic update mode The force-monochrome update feature and animation mode updates Support for using a grayscale colormap Snapshot, Queue, and Queue and Merge update schemes The EPDC Collision Test mode EPDC tests: Basic Updates Rotation Updates Grayscale Framebuffer Updates Auto-waveform Selection Updates Panning Updates Overlay Updates Auto-Updates Animation Mode Updates Fast Updates Partial to Full Update Transitions Test Pixel Shifting Effect Colormap Updates Collision Test Mode Stress Test `$ /unit_tests/mxc_epdc_fb_test.out Usage: mxc_epdc_fb_test [-h] [-a] [-n] -h Print this message -a Enabled animation waveforms for fast updates (tests 8-9) -p Provide a power down delay (in ms) for the EPDC driver -u Select an update scheme s - Snapshot update scheme q - Queued update scheme m - Queued update scheme with update merging -n Execute the tests specified in expression Expression is a set of comma-separated numeric ranges Example: /unit_tests/mxc_epdc_fb_test.out -n 1-3,5,7`
Expected Result	The full set of tests should pass without any failure messages. For each test, a sequence of updates should be reflected on the screen. For almost all tests, the text printed out in the debug console describes the image that should be observed on the screen.

ESAI

FSL-UT-ESAI-001

Name	Description
Summary	Test playback for alsa driver with ESAI interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_ESAI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_CS42888=y CONFIG_SND_SOC_CS42888=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreAI
Test Procedure	check the esai sound card number, and adjust the n to 0 or 1… `$ aplay -l` file.wav may be 2 to 6 channel stream `$ aplay -Dhw:n,0 file.wav`
Expected Result	The sound is heard clearly and properly

FSL-UT-ESAI-002

Name	Description
Summary	Test record for alsa driver with ESAI interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_ESAI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_CS42888=y CONFIG_SND_SOC_CS42888=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreAI
Test Procedure	run the following command on target board `$ arecord -d 5 -c 2 -f S16_LE -r 44100 /tmp/mic44k.wav $ aplay /tmp/mic44k.wav`
Expected Result	The recorded sound is heard clearly and properly

FSL-UT-ESAI-003

Name	Description
Summary	Test suspend/resume for alsa driver with ESAI interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_ESAI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_CS42888=y CONFIG_SND_SOC_CS42888=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreAI
Test Procedure	run the following command on target board `$ aplay .wav $ /unit_tests/rtcwakeup.out -d rtc0 -m mem -s 6 $ aplay .wav`
Expected Result	The sound is heard clearly and properly after resume

FSL-UT-ESAI-004

Name	Description
Summary	Test playback/record duplex for alsa driver with ESAI interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_ESAI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_CS42888=y CONFIG_SND_SOC_CS42888=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreAI
Test Procedure	run the following command on target board, `$ arecord -Dplughw:0 -d 20 -f S16_LE -r 44100 -c 2 -traw \| aplay -Dplughw:0 -f S16_LE -r 44100 -c 2 -traw`
Expected Result	The sound is heard clearly and properly after resume

FSL-UT-ESAI-005

Name	Description
Summary	Test playback continuously for alsa driver with ESAI interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_ESAI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_CS42888=y CONFIG_SND_SOC_CS42888=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreAI
Test Procedure	run the following command on target board, `$ while true; do aplay -Dplughw:0 file.wav; done`
Expected Result	The sound is heard continuously

FSL-UT-ESAI-006

Name	Description
Summary	Test concurrent playback/record for alsa driver with ESAI interface; Play wav file and send process to background, record new audio file.
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_ESAI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_CS42888=y CONFIG_SND_SOC_CS42888=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreAI
Test Procedure	run the following commands on target board, `$ aplay -Dhw:0,0 file.wav >& /dev/null \| arecord -Dhw:0,0 -f S16_LE -r 48000 -c 2 rec-S16LE-48k.wav $ aplay -Dhw:0,0 rec-S16LE-48k.wav`
Expected Result	The sound is heard clearly while recording an additional audio file. The record sound file is heard clearly and properly.

FB

FSL-UT-FB-001

Name	Description
Summary	Frame buffer basic test for display. The framebuffer driver should be able to easily add new displays to the system including timings, refresh, resolution, formats, via tables in the driver.
Automated	YES (But manual observation is required to confirming correct updates on display panel)
Kernel Config Option	`CONFIG_FB=y CONFIG_FB_MXC=y CONFIG_FB_MXC_EDID=y CONFIG_FB_MXC_SYNC_PANEL=y CONFIG_FB_MXC_LDB=y CONFIG_FB_MXC_HDMI=y ...`
Software Dependency	N/A
Non-default Hardware Configuration	The fb0 and fb1 are used for tests, fb0 is background framebuffer, and fb1 is foreground overlay framebuffer.
Test Procedure	Frame buffer test for display. Features tested: Basic fb operation Set background/foreground to 16 bpp fb Global alpha blending Color key test Framebuffer Panning Gamma test `$ /unit_tests/mxc_fb_test.out Usage: execute directly.` `Example: root@freescale /unit_tests$ ./mxc_fb_test.out Opened fb0 and fb1 Set the background to 16-bpp` `Screen size = 1572864 Set the foreground to 16-bpp Testing global alpha blending... Fill the FG in black Fill the BG in white Alpha is 0, FG is opaque Alpha is 255, BG is opaque Color key enabled Color key disabled Global alpha disabled Set the background to 16-bpp Pan test start. Pan test done. Set the background to 16-bpp Pan test start. Pan test done. Gamma test start. Gamma 0.800000 Gamma 1.000000 Gamma 1.500000 Gamma 2.200000 Gamma 2.400000 Gamma test end.`
Expected Result	The test should pass without any failure messages, and the display on panel should be correct. For each test, a sequence of updates should be reflected on the screen. For almost all tests, the text printed out in the debug console describes the image that should be observed on the screen.

FSL-UT-FB-002

Name	Description
Summary	Frame buffer vsync test.
Automated	YES
Kernel Config Option	`CONFIG_FB=y CONFIG_FB_MXC=y CONFIG_FB_MXC_EDID=y CONFIG_FB_MXC_SYNC_PANEL=y CONFIG_FB_MXC_LDB=y CONFIG_FB_MXC_HDMI=y ...`
Software Dependency	N/A
Test Procedure	Make sure test framebuffer is unblank. `$ /unit_tests/mxc_fb_vsync_test.out Usage:` `./mxc_fb_vsync_test.out <fb #> <count> <fb #> the framebuffer number <count> the frames to be rendered` `Example: root@freescale /unit_tests$ echo 0 > /sys/class/graphics/fb0/blank root@freescale /unit_tests$ ./mxc_fb_vsync_test.out 0 100 total time for 100 frames = 1655674 us = 60 fps`
Expected Result	Console print out message like (the fps is depended on your display device’s refresh rate). total time for 100 frames = 1655674 us = 60 fps

FSL-UT-FB-003

Name	Description
Summary	WVGA Frame buffer test.
Automated	NO
Non-default Hardware Configuration	Config command line arguments of video=mxcfb0:dev=lcd,800x480M@55,if=RGB565
Software Dependency	N/A
Test Procedure	Connect a WVGA panel to the dumb LCD connector on the board Boot linux with an additional command line arguments of video mode Login `cat /sys/class/graphics/fb0/mode` Find the rgb image with 800x480 resolution `cat image > /dev/fb0`
Expected Result	The penguin should appear on the display. The display resolution of 800x480 will be displayed. You should see a clear rgb image filling the entire screen with correct colors.

FSL-UT-FB-004

Name	Description
Summary	LVDS Frame buffer test.
Automated	NO
Software Dependency	N/A
Test Procedure	Connect XGA LVDS panels to LVDS0/LVDS1 connectors on the board Login `cat /sys/class/graphics/fb0/mode` Find the rgb image with 1024x768 resolution `cat image > /dev/fb0`
Expected Result	The penguin should appear on the display. The display resolution of 1024x768 will be displayed. You should see a clear rgb image filling the entire screen with correct colors.

FSL-UT-FB-005

Name	Description
Summary	MIPI DSI Frame buffer test.
Automated	NO
Non-default Hardware Configuration	Config command line arguments of video=mxcfb0:dev=mipi_dsi,TRULY-WVGA,if=RGB24
Software Dependency	N/A
Test Procedure	Connect the MIPI DSI TRULY WVGA panel, ensure the cable is connected correctly Boot the kernel and check the LCD display Change the backlight brightness: `echo value(0-255) > /sys/class/backlight/mipid-bl/brightness` Check for blank/unblank: `echo value(1 or 0) > /sys/class/graphics/fb0/blank`
Expected Result	The penguin should appear on the display. The LCD panel should display correctly.

FSL-UT-FB-006

Name	Description
Summary	Dual display test.
Automated	NO
Non-default Hardware Configuration	Config command line arguments:video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 ldb=sep0
Software Dependency	N/A
Test Procedure	Connect XGA LVDS panel and HDMI display on the board Boot linux with an additional command line arguments of video mode Login Unblank the secondary display with `echo 0 > /sys/class/graphics/fb2/blank` Check the resolutions of both displays with: `cat /sys/class/graphics/fb0/mode cat /sys/class/graphics/fb2/mode` Find the rgb images with correct resolution to both displays: `cat image1 > /dev/fb0 cat image2 > /dev/fb2`
Expected Result	The display resolutions will be displayed correctly. The images should display correctly on both screens.

FEC

FSL-UT-FEC-001

Name	Description
Summary	FEC test
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	A connection via ethernet cable to hub/switcher.
Test Procedure	Following tests can be carried out using test application that is, client server programs to send or receive test packet. Test item: ping ftp (busybox 1.01) dhcp telnet telnetd nfs
Expected Result	All test pass.

FSL-UT-FEC-002

Name	Description
Summary	FEC-ifconfig test
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	A connection via ethernet cable to hub/switcher.
Test Procedure	The FEC driver shall support obtaining statistics from the device such as transmit collisions. Test_Procedure: Boot default kernel Execute "ifconfig eth1" Note statistics displayed
Expected Result	ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Base address:0x8000

FSL-UT-FEC-003

Name	Description
Summary	NFS root connection
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	A connection via ethernet cable. A server with an NFS file system.
Test Procedure	The FEC driver shall support full duplex operation and link status detect. Test steps: Build kernel with FEC on, SMSC911X? off and boot NFS root. Disconnect ethernet from FEC and reconnect. Observe kernel messages. To boot an NFS root the command line may look something like this: exec -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.1.49.15: \ /u_tmp/name/ltib-mx25/rootfs rw ip=dhcp"
Expected Result	eth0: status: link down eth0: status: link up

FSL-UT-FEC-004

Name	Description
Summary	Ethernet connection interruption.
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	An ethernet cable connection. A server with an NFS root file system.
Test Procedure	The FEC driver shall support transmit features like automatic retransmission on collision and automatic CRC generation. Test_Procedure: Build kernel with FEC on, SMSC911X? off and boot NFS root Execute "while true ; do du / ; done" Disconnect and reconnect FEC ethernet Observe kernel messages and that it recovers and continues. To boot an NFS root the command line may look something like this: exec -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.1.49.15: \ /u_tmp/name/ltib-mx25/rootfs rw ip=dhcp"
Expected Result	Sample_Log: eth0: status: link down nfs: server 172.16.1.2 not responding, still trying eth0: status: link up nfs: server 172.16.1.2 OK.

FSL-UT-FEC-005

Name	Description
Summary	Change MAC address.
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	An ethernet connection A server with an NFS root file system.
Test Procedure	The FEC driver shall support changing the default MAC address via the kernel command line. Test steps: Configure kernel with SMSC911X? off, and FEC on. Boot kernel with "fec_mac=00:00:02:19:19:61" added to kernel command line. Examine boot log for "eth0: ethernet 00:00:02:19:19:61".
Expected Result	`Kernel command line: noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.19 3.20.190:/tftpboot/10.193.20.181 init=/linuxrc ip=dhcp fec_mac=00:04:9f:00:98:2c` `ifconfig eth0: eth0 Link encap:Ethernet HWaddr 00:04:9f:00:98:2c inet addr:10.192.242.12 Bcast:10.192.242.255 Mask:255.255.255.0 ......`

GNOME

FSL-UT-GNOME-001-Lanuch

Name	Description
Summary	Gnome-mobile lanuch
Automated	No
Kernel Config Option	N/A
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Steps By using default nightly build rootfs, see whether gnome-mobile can be launched well. See whether totem can run well.
Expected Result	Gnome-mobile can run well Pass

GPU

FSL-UT-GPU-001

Name	Description
Summary	GPU function test tutorial3: test OpenGL ES 1.1 basic function tutorial4_es20: test OpenGL ES 2.0 basic function tiger: test OpenVG 1.1 basic function tvui: test Raster 2D and LibVivanteDK API
Automated	NO
Kernel Config Option	CONFIG_MXC_GPU_VIV=y
Software Dependency	N/A
Non-default Hardware Configuration	LVDS Display Panel
Test Procedure	run the following command on target board, `$ /unit_tests/gpu.sh`
Expected Result	Should get the following message: The frames can be drawn properly on screen tutorial3: a cube with texture rotating in the middle of the screen. tutorial4_es20: draws a glass sphere inside a big sphere (enviroment mapping). The glass sphere shows both reflection and refraction effects. tiger: a tiger spinning on the screen. tvui: draws several movie clips and a tv control panel.

HDMI

FSL-UT-HDMI-001-Basic

Name	Description
Summary	EPDC frame buffer test for display updates
Automated	YES (But manual observation is required to confirming correct updates on display panel)
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration
Test Procedure	Basic boot testing involves modifying the kernel command line video parameter to test for several different framebuffer/display resolutions. The resolutions to be test depends on whether the HDMI output goes to an HDTV (supporting CEA TV modes)or through an HDMI→DVI converter to a PC monitor (usually not supporting TV modes, but rather supporting VESA monitor modes) For HDMI→HDMI (output device is HDMI compatible), set the video parameter on the kernel command line: video=mxcfb0:dev=hdmi,RGB24,640x480@60 video=mxcfb0:dev=hdmi,RGB24,1920x1080@60 video=mxcfb0:dev=hdmi,RGB24,1280x720@60 For HDMI→DVI, set the video parameter on the kernel command line: video=mxcfb0:dev=hdmi,RGB24,640x480@60 video=mxcfb0:dev=hdmi,RGB24,1280x1024@60 video=mxcfb0:dev=hdmi,RGB24,1024x768@75
Expected Result	The UI should come up correctly on the display and appear in the mode that was set in the command line. If the command line mode is not supported by the display, the mode that is shown should be the mode supported by the display that is nearest to the command line mode. Note: The HDMI initialization routine calls for changing the video mode to 640x480 before ultimately changing to the desired mode. As a result, the fb console shows the tux logo during the first mode, and then does not re-show it when the mode is set to its ultimate video mode. Therefore, when using HDMI, the tux logo will not appear on the display. If the screen is blank and confirmation is needed that the framebuffer is operating correctly, follow these steps to display an image to the FB: Login to the rfs cat /sys/class/graphics/fb0/mode The display resolution will be displayed. Find the rgb image in the /unit_tests directory for display resolution. cat image > /dev/fb0 You should see a clear image filling the entire screen with correct colors.

FSL-UT-HDMI-002-Hotplug

Name	Description
Summary	EPDC frame buffer test for display updates
Automated	YES (But manual observation is required to confirming correct updates on display panel)
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration
Test Procedure	These tests cover HDMI driver state changes and ensure that the driver can properly handle hotplug events, video mode change events, and suspend/resume events. Boot with HDMI unplugged. Once system has booted to command prompt, connect (hotplug) HDMI cable. With HDMI display up and running, unplug HDMI cable and then reconnect. With HDMI display up and running, unplug HDMI cable and reconnect a different HDMI cable which connects to a different HDMI displa
Expected Result	The UI should come up correctly on the display in each case. For the unplug-replug case, the video mode should be the same as before the cable was unplugged.

I2C

FSL-UT-I2C-001

Name	Description
Summary	I2Cn Test - Support of multiple I2Cn Controllers
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Build kernel with all 3 I2Cn selects enabled as a built-in drivers. Bootup and login as root - Check /sys/class/i2c-adapter for 3 adapters Use i2c-tools to verify i2c controller r/w.
Expected Result	du /sys/class/i2c-adapter/ /sys/class/i2c-adapter/i2c-0/0-0054 /sys/class/i2c-adapter/i2c-0 /sys/class/i2c-adapter/i2c-1 /sys/class/i2c-adapter/i2c-2 /sys/class/i2c-adapter

IPU

FSL-UT-IPUDEV-001

Name	Description
Summary	IPU device interface autotest.
Automated	YES
Software Dependency	N/A
Test Procedure	Note There are some cases which ipu can not support, it will return ipu task check error info, please check the log. Go to unit test dir, run: `./autorun-ipu.sh > log` If need full test, please run test after export FULLTEST=1
Expected Result	The correct image or video can show on the fb.

MISC

FSL-UT-MISC-001-PWM-Backlight

Name	Description
Summary	PWM Backlight
Automated	No
Kernel Config Option	CONFIG_WATCHDOG=y
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	run the following command on target board, the intensity ranges from 0 to 255. `$ echo intensity > /sys/class/backlight/pwm-backlight.1/brightness`
Expected Result	The backlight changes accordingly, when the brightness is altered.

FSL-UT-MISC-002-Vmalloc-info

Name	Description
Summary	Check vmalloc info
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	run the following command on target board, `$ check vmalloc info`
Expected Result	No abnormal large memory is requested.

Mfgtool

FSL-UT-MFG-001

Name	Description
Summary	Mfgtools burn image
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Mfgtools burn image to sd card: Change the board to USB boot mode. Connect the board with USB line. Start Mfgtool.exe on the Windows. Select the board type: "Options" -→ "Configuration" -→ "Profiles" : Select "SD" in the "Options" of "Operations" section; Press "OK" button. After the Mfgtool detects your board, press "Start" to begin the burning. Change the board to SD board mode Reboot.
Expected Result	System success boot.

MMC

FSL-UT-MMC-001

Name	Description
Summary	MMC/SD read write test
Automated	Yes
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	run autorun-mmc.sh
Expected Result	Pass

FSL-UT-MMC-002

Name	Description
Summary	MMC/SD block read write test
Automated	Yes
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	run autorun-mmc-blockrw.sh
Expected Result	Pass

FSL-UT-MMC-005

Name	Description
Summary	MMC/SD fdisk test
Automated	Yes
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	run autorun-mmc-fdisk.sh
Expected Result	Pass

FSL-UT-MMC-006

Name	Description
Summary	MMC/SD mkfs test
Automated	Yes
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	run autorun-mmc-fs.sh
Expected Result	Pass

FSL-UT-MMC-007

Name	Description
Summary	MMC/SD file system test
Automated	Yes
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	run autorun-mmc-fs.sh
Expected Result	Pass

FSL-UT-MMC-008

Name	Description
Summary	MMC/SD power management test
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Steps Ensure MMC/SD/SDIO can enter suspend. `$ echo mem > /sys/power/state` Press one key to resume. Retest MMC/SD/SDIO function.
Expected Result	MMC/SD/SDIO functionality works well after resume.

NAND

FSL-UT-NAND-001

Name	Description
Summary	NAND TEST
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	After the system boots up with the NAND MTD driver, it may be tested as follows (note that mtd-utils package is needed): UBIFS : add the following to kernel parameter line when it boots: "mtdparts=gpmi-nfc:20m(boot),200m(test),-(user)" Find out the available partition(s) in the running Linux system. So user can opt to test partition after this. For example: `root@freescale ~$ cat /proc/mtd dev: size erasesize name mtd0: 00140000 00020000 "boot" mtd1: 00140000 00020000 "test" mtd2: 0001f000 00008000 "user"` Erase one of the NAND Flash partitions using flash_eraseall. Take /dev/mtd2 for example: `$flash_eraseall /dev/mtd2` Create a ubi node: `$ubiattach /dev/ubi_ctrl -m 2` create a ubi partition in this ubi node: `$ubimkvol /dev/ubi0 -N testnode -m` Mount the NAND partition and read the files: `$mkdir -p /tmp/mtdX $mount -t ubifs ubi0:testnode /tmp/mtdX $bonnie++ -d /tmp/mtdX -u 0 -s 2 -r 1 $umount /tmp/mtdX $ubidettach /dev/ubi_ctrl -m 2`
Expected Result	Those operations should be successful.

FSL-UT-NAND-002

Name	Description
Summary	NAND suspend and resume
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Ensure NAND can enter suspend `$echo mem > /sys/power/state 2. Press one key to resume 3. Retest NAND function again`
Expected Result	NAND can work normally after resume.

Power Management

FSL-UT-PM-001-Basic-Suspend-Resume

Name	Description
Summary	Test system base suspend resume
Automated	No
Kernel Config Option
Test Procedure	run the following command on target board, `$ echo mem >/sys/power/state` press power button
Expected Result	System can wake up

FSL-UT-PM-002-Quick-Stress-Suspend-Resume

Name	Description
Summary	Test system suspend resume stress test
Automated	No
Kernel Config Option
Test Procedure	run the following command on target board. `$ /unit_test/suspend_quick_auto.sh`
Expected Result	Pass 48 hours test

FSL-UT-PM-003-Random-Stree-Suspend-Resume

Name	Description
Summary	Test system suspend resume stress test
Automated	No
Kernel Config Option
Test Procedure	run the following command on target board, `$ /unit_test/suspend_random_auto.sh`
Expected Result	Pass 48 hours test

FSL-UT-PM-004-Power Off

Name	Description
Summary	Power Off System
Automated	No
Kernel Config Option
Test Procedure	run the following command on target board, `$ poweroff` or `$ poweroff -f`
Expected Result	The whole board can be power off

FSL-UT-PM-004-Stress-Power-Off-RTC-ALAM-Power-On

Name	Description
Summary	Stree test for power off and power on boot by RTC alam
Automated	No
Kernel Config Option
Test Procedure	steps copy below code into the begin of /etc/rc.d/init.d/udev `date echo +10 > /sys/class/rtc/rtc0/wakealarm poweroff -f`
Expected Result	The board can power off and power on after 10s. Pass over night test.

FSL-UT-PM-006-DVFS

Name	Description
Summary	DVFS TEST
Automated	No
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_DVFS=y`
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	To Enable DVFS: `echo 1 > /sys/devices/platform/imx_dvfscore.0/enable` To Disable DVFS: `echo 0 > /sys/devices/platform/imx_dvfscore.0/enable`
Expected Result	When DVFS core enabled, CPU voltage should be around 1.225 V when Freq is 996 MHz; CPU voltage should be around 1.10 V when Freq is 792 MHz; CPU voltage should be around 0.95 V when Freq is 396 MHz; Voltage should be around 0.85 V when Freq is 198 MHz. When DVFS core disabled, voltage should be around 1.225 V all the time with freq of 996 MHz.

FSL-UT-PM-007-CPUFREQ

Name	Description
Summary	CPUFREQ TEST
Automated	No
Kernel Config Option	N/A
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Make sure if CPUFREQ governor is userspace: `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor userspace` If yes, go to step 3. otherwise, do the following: `echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor` To show current CPU frequency in KHz (e.g. 392727 KHz): `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 392727` To show current CPU voltage in uV (e.g. 1450000 uV): `cat /sys/class/regulator/regulator.0/microvolts 1450000` To show the minimum CPU frequency (e.g. 261818 KHz) can be changed: `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 261818` To change CPU frequency to the minimum frequency (e.g. 261818 KHz): `echo 261818 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed` To show current CPU frequency in KHz (e.g. 261818 KHz): `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 261818` To show current CPU voltage in uV (e.g. 1275000 uV): `cat /sys/class/regulator/regulator.0/microvolts 1275000` To show the maximum CPU frequency (e.g. 454736 KHz) can be changed: `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 454736` To change CPU frequency to the maximum frequency (e.g. 454736 KHz): `echo 454736 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed` To show current CPU frequency in KHz (e.g. 454736 KHz): `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 454736` To show current CPU voltage in uV (e.g. 1550000 uV): `cat /sys/class/regulator/regulator.0/microvolts 1550000` To show what values of CPU frequency can be changed in KHz (The first value of each row is the frequency value can be changed into): `cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state`
Expected Result	The CPU frequency should be changed to the value requested. The CPU voltage should be changed. After changing CPU frequency to the value listed by using the thirteenth command above (ex. 996 MHz), the CPU voltage should be around 1.225V by measuring VDDARM on CPU card and ground. To see the current cpu freq you can use the third command above. After changing CPU frequency to to the value listed by using the thirteenth command above (ex. 198MHz), the CPU voltage should be around 0.85V (1.00V for i.MX6DL-ARM2) by measuring VDDARM on CPU card and ground. To see the current cpu freq you can use the third command above.

FSL-UT-PM-008-DVFS suspend resume

Name	Description
Summary	DVFS suspend/resume
Automated	No
Kernel Config Option	N/A
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Ensure DVFS can enter suspend : `echo mem > /sys/power/state` Press one key to resume Retest DVFS function again
Expected Result	DVFS can work normally after resume

FSL-UT-PM-009-CPU hotplug

Name	Description
Summary	CPU hotplug test
Automated	No
Kernel Config Option	N/A
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	run bonnie++ back ground as below: `x=1 while [1] do /unit_tests/bonnie\+\+ -f -u root -r 5 -s 10 -d /tmp echo echo echo bonnie++ test passed: $x times echo echo let x=x+1 done` run cpu hotplug test command as below: i=0; while [ "$i" -lt 10000 ]; do echo 0 > /sys/devices/system/cpu/cpu3/online;echo 0 > /sys/devices/system/cpu/cpu2/online;echo 0 > /sys/devices/system/cpu/cpu1/online;sleep 1;echo 1 > /sys/devices/system/cpu/cpu1/online;echo 1 > /sys/devices/system/cpu/cpu2/online;echo 1 > /sys/devices/system/cpu/cpu3/online; echo Pass $i times ;i=`expr $i + 1`; done
Expected Result	pass

PXP

FSL-UT-PXP-001

Name	Description
Summary	Test multiple instances of PxP DMAENGINE clients
Automated	YES
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_PXP=y CONFIG_MXC_PXP_V2=y CONFIG_MXC_PXP_CLIENT_DEVICE=y CONFIG_DMA_ENGINE=y`
Software Dependency	Need /usr/lib/libpxp.so
Non-default Hardware Configuration	N/A
Test Procedure	run the following command on target board, `$ /unit_tests/autorun-pxp.sh`
Expected Result	Should get the following message: `autorun-pxp.sh: Exiting PASS`

FSL-UT-PXP-002

Name	Description
Summary	PxP function test (via V4L2 interface)
Automated	NO
Kernel Config Option	`CONFIG_MXC_PXP=y CONFIG_DMA_ENGINE=y CONFIG_VIDEO_MXC_PXP_V4L2=y CONFIG_VIDEO_V4L2=y ...`
Software Dependency	N/A
Non-default Hardware Configuration	TBD
Test Procedure	run ./pxp_v4l2_test.out -h for available test parameters. run a real case, for example (or refer to pxp_v4l2_out_test.sh in rootfs) `$ cd /unit_tests/ $ ./pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -a 100 fb-352x240.yuv BLANK`
Expected Result	The video streaming can be viewed on LCD

RNG

RTC

FSL-UT-RTC-001

Name	Description
Summary	Test RTC function
Automated	YES
Kernel Config Option	`CONFIG_RTC_DRV_SNVS`
Test Procedure	run the following command on target board, `$ /unit_tests/autorun-rtc.sh`
Expected Result	Exit with PASS results

FSL-UT-RTC-002

Name	Description
Summary	Test RTC resume system
Automated	YES
Kernel Config Option	`CONFIG_RTC_DRV_SNVS`
Software Dependency	System suspend/resume function ready
Test Procedure	Test whether target is able to resume from standyby by RTC wakeup .Run below command `$ /unit_tests/rtcwakeup.out -d rtc0 -m mem -s 10`
Expected Result	System is wakeup after 10s.

FSL-UT-RTC-003

Name	Description
Summary	RTC time is reserved in system off state
Automated	No
Kernel Config Option	`CONFIG_RTC_DRV_SNVS`
Hardware Dependency	The voltage of coin-cell battery is enough to keep RTC alive.
Test Procedure	Test whether target is able to resume from standyby by RTC wakeup Test steps Boot-up Linux kernel. Type the command "date". It should return something like this "Thu Jan 1 00:00:30 UTC 1970". Set the date to the current date and time. The command is "date yyyyMMDDhhmm" such as "date 201012091453" for 12/03/2010 14:53 Set the HW clock to current date and time by using the command "hwclock --systohc" Make sure the new date and time are set by issuing "date" and then "hwclock --show" Shutdown the system, including a power-cycle. You can use "poweroff" command Restart the system with the Linux kernel. Run "date" command.
Expected Result	Check whether the date is reserved and right.

SATA

FSL-UT-SATA-001-Bonnie++

Name	Description
Summary	Run Bonniee++ for SATA disk
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Test Steps: Connect SATA disk. After booting up the board, the system can find the SATA disk device such as /dev/sda on the SATA interface. run bonnie++ tool to do the kinds of tests on the SATA disk.
Expected Result	Pass

FSL-UT-SATA-001-Suspend-Resume

Name	Description
Summary	Sata can work after suspend resume
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Test Steps: Suspend/Resume SATA when data transactions are on-going on SATA disks.
Expected Result	The data transactions can be continued after system resume back when there are data transaction on going before

FSL-UT-SATA-003-SATA-Boot

Name	Description
Summary	Boot from Sata
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	Test Steps: Program uBOOT to SATA disk Boot system from SATA.
Expected Result	Boot system from SATA.

SPDIF

FSL-UT-SPDIF-001

Name	Description
Summary	Test record for alsa driver with SPDIF interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_SPDIF=y CONFIG_SND_MXC_SOC_SPDIF_DAI=y CONFIG_SND_SOC_IMX_SPDIF=y CONFIG_SND_SOC_MXC_SPDIF=y`
Software Dependency	N/A
Non-default Hardware Configuration	M-Audio Transit USB sound card
Test Procedure	Setup M-Audio Transit USB sound card and install M-Audio Transit driver on PC Connect coaxial line between ARD and M-Audio transit Startup WaveLab, open a test wav file: audioXXkYYS.wav to play in loop call amixer to get rx sample rate by "RX Sample Rate" sound controller. command as: amixer cget numid=6,iface=PCM,name=RX Sample Rate,device=1 Meanwhile, on board use following command to record one wave file, and play it back on the audio stereo codec device (the recorded stream will be heard from headset) `$ arecord -D hw:[card id],[pcm id] -t wav -c 2 -r [sample rate in Hz] -f S24_LE \| aplay -D "plughw:0,0" -t wav` Note: The sample rate argument in the arecord command must be consistent with wav file playing on WaveLab.
Expected Result	Hear audio that is captured from S/PDIF being looped back out stereo codec.

FSL-UT-SPDIF-002

Name	Description
Summary	Test suspend/resume for alsa driver with SPDIF interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_SPDIF=y CONFIG_SND_MXC_SOC_SPDIF_DAI=y CONFIG_SND_SOC_IMX_SPDIF=y CONFIG_SND_SOC_MXC_SPDIF=y`
Software Dependency	N/A
Non-default Hardware Configuration	M-Audio Transit USB sound card
Test Procedure	suspend up to 6s, then resume `$ /unit_tests/rtcwakeup.out -d rtc0 -m mem -s 6` after resume, retest SPDIF function
Expected Result	The SPDIF funtion should be OK after resume

SSI

FSL-UT-SSI-001

Name	Description
Summary	Test playback for alsa driver with SSI interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_SSI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_WM8962=y CONFIG_SND_SOC_WM8962=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreSD rev.B
Test Procedure	run the following command on target board, and wav file is mono or stereo stream and may be found in mxc_ssi_test/sound_samples `$ amixer sset 'Headphone' 100 $ aplay *.wav`
Expected Result	The sound is heard clearly and properly

FSL-UT-SSI-002

Name	Description
Summary	Test record for alsa driver with SSI interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_SSI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_WM8962=y CONFIG_SND_SOC_WM8962=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreSD rev.B
Test Procedure	run the following command on target board, `$ amixer cset numid=10,iface=MIXER,name='Capture Switch' on $ amixer sset 'Capture' 120 $ amixer sset 'INPGAR IN3R' on $ amixer sset 'MIXINR IN3R' on $ arecord -r 44100 -f S16_LE -c 2 -d 5 record.wav $ aplay record.wav`
Expected Result	The recorded sound is heard clearly and properly

FSL-UT-SSI-003

Name	Description
Summary	Test suspend/resume for alsa driver with SSI interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_SSI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_WM8962=y CONFIG_SND_SOC_WM8962=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreSD rev.B
Test Procedure	run the following command on target board, `$ aplay .wav $ /unit_tests/rtcwakeup.out -d rtc0 -m mem -s 6 $ aplay .wav`
Expected Result	The sound is heard clearly and properly after resume

FSL-UT-SSI-004

Name	Description
Summary	Test playback/record duplex for alsa driver with SSI interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_SSI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_WM8962=y CONFIG_SND_SOC_WM8962=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreSD rev.B
Test Procedure	run the following command on target board, `$ amixer sset 'Headphone' 110 $ amixer cset numid=10,iface=MIXER,name='Capture Switch' on $ amixer sset 'Capture' 120 $ amixer sset 'INPGAR IN3R' on $ amixer sset 'MIXINR IN3R' on $ arecord -Dplughw:0 -d 20 -f S16_LE -r 44100 -c 2 -traw \| aplay -Dplughw:0 -f S16_LE -r 44100 -c 2 -traw`
Expected Result	The record sound may be playback clearly.

FSL-UT-SSI-005

Name	Description
Summary	Test playback continuously for alsa driver with SSI interface
Automated	NO
Kernel Config Option	`CONFIG_IMX_HAVE_PLATFORM_IMX_SSI=y CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y CONFIG_SND_SOC_IMX_WM8962=y CONFIG_SND_SOC_WM8962=y`
Software Dependency	N/A
Non-default Hardware Configuration	SabreSD rev.B
Test Procedure	run the following command on target board, `$ while true; do aplay -Dhw:0 file.wav; done`
Expected Result	The sound is heard continuously

USB

FSL-UT-USB-030-Connected-Test

Name	Description
Summary	USB Connected Test During Booting Up
Automated	No
Kernel Config Option
Software Dependency	N/A
Non-default Hardware Configuration	N/A
Test Procedure	NOTICE: please check clkcount often using dump-clocks.sh 1.1: With USB Disk connected at OTG Port /unit_tests/dump-clocks.sh
grep usb modprobe g_mass_storage file=/dev/mmcblk0p1 removable=1 modprobe -r g_mass_storage /unit_tests/dump-clocks.sh	`grep usb` 1.2: With USB Disk connected at Host 1 Port /unit_tests/dump-clocks.sh
grep usb 1.3: With USB Cable connected with PC, load gadget module /unit_tests/dump-clocks.sh	`grep usb modprobe g_mass_storage file=/dev/mmcblk0p1 removable=1 /unit_tests/dump-clocks.sh`
grep usb disconnet PC /unit_tests/dump-clocks.sh	`grep usb` 1.4: With USB Cable connected with USB Charger, load gadget module modprobe g_mass_storage file=/dev/mmcblk0p1 removable=1 /unit_tests/dump-clocks.sh
grep usb disconnect usb charger connect to pc 1.5: With Micro B-To-A cable, but without anything connected /unit_tests/dump-clocks.sh	`grep usb plug in usb disk plug out Micro B-To-A cable modprobe g_mass_storage file=/dev/mmcblk0p1 removable=1 connect to pc disconnect with pc /unit_tests/dump-clocks.sh`
grep usb	`Expected Result`

FSL-UT-USB-031-Reboot-Test

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Reboot Test With U-disk Connected

| Automated |
YES

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1. Put Below Commands at init script (at the end of /etc/rc.d/rcS, etc)
mount -t nfs -o nolock 10.192.244.61:/rootfs/wb /mnt/nfs
cd /mnt/nfs/vte_mx63_d/
source manual_test

/root/test_reboot.sh

NOTICE: 10.192.244.61:/rootfs/wb is the testing team VTE rootfs

2. Put the below test_reboot.sh at /root/

get_scsi.sh 4
if [ $? -eq 0 ]
then
echo "aa" >> /root/reboot_count.txt
echo "the time of reboot:"
cat /root/reboot_count.txt | wc -l
reboot
else
echo "the udisk can't be recognized"
fi

NOTICE: get_scsi.sh is the test application at VTE, it will judge
if the u-disk is existed or not.

3. Plug u-disk at USB port (Do another test with HUB connected)

4. Power up the board

| Expected Result |
The continueous reboot test can run more than 1000 iterations.

|====================================================================

<<<
FSL-UT-USB-032-Manually-Plug-In-Out-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Manually Plug in/out Test

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
2.1: Host/Device switch test and read/write test
modprobe g_mass_storage file=/dev/mmcblk0p1 removable=1
Plug in Micro B-To-A cable with u-disk connected
/* Mount VTE ENV */
mount -t nfs -o nolock 10.192.244.61:/rootfs/wb /mnt/nfs
cd /mnt/nfs/vte_mx63_d
source manual_test
mkdir -p /mnt/sda1; mount /dev/sda1 /mnt/sda1
bonnie\+\+ -d /mnt/sda1 -u 0:0 -s 64 -r 32
dt of=/mnt/sda1/test_file bs=4k limit=128m passes=20
Plug out usb disk
plug in usb-disk
plug out Micro B-To-A cable,
plug in USB charger, plug out USB charger,
plug in usb cable connected to PC.
At Host PC do below four commands:
mkdir -p /mnt/flash
mount -t vfat /dev/sdx1 /mnt/flash
sudo bonnie++ -d /mnt/flash -u 0:0 -s 10 -r 5
sudo dt of=/mnt/flash/test_file bs=4k limit=63m passes=20

Plug in Micro B-TO-A cable with u-disk connected
Check clk refcount(/unit_tests/dump-clocks.sh | grep usb)

2.2: Repeat Host/Device switch test
s1: Booting With USB Disk connected at OTG Port
s2: modprobe g_mass_storage file=/dev/mmcblk0p1 removable=1
s3: plug out Micro B-TO-A cable
s4: plug in usb cable connecting with PC
s5: plug out usb cable
s6: plug in Micro B-TO-A cable with u-disk connected
s7: repeat s3-s6 10 times
s8: check clk refcount (/unit_tests/dump-clocks.sh | grep usb)

| Expected Result |
No Error, No Clock Mismatch

|====================================================================

<<<
FSL-UT-USB-033-Wakeup-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Kinds of USB Wakeup Tests

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1:
/* Enable Serial Wakeup */
echo enabled > /sys/class/tty/ttymxc0/power/wakeup
echo mem > /sys/power/state
plug in USB device, the system should not be waken up
wakeup system using console
The u-disk should be enumerated successfully
2:
plug out u-disk
plug in mouse/keyboard at OTG port with micro b-to-a cable

echo enabled > /sys/bus/platform/devices/20c9000.usbphy/power/wakeup
echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup
echo enabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup
echo enabled > /sys/bus/usb/devices/usb2/power/wakeup
echo enabled > /sys/bus/usb/devices/2-1/power/wakeup

echo mem > /sys/power/state
Testing usb wakeup function using plug in/out, micro b-to-a plug
in/out, and remote wakeup.

NOTICE: If micro b-to-a cable is plugged out, the usb2 will be
removed, and the usb2 wakeup setting needs to be re-set before suspend.
If usb device is plugged out, the 2-1 wakeup setting needs to
be re-set before suspend.

3:
modprobe g_mass_storage file=/dev/mmcblk0p1 removable=1 (or ther gadgets)
echo mem > /sys/power/state
wakeup system with vbus
echo disabled > /sys/bus/platform/devices/20c9000.usbphy/power/wakeup
echo disabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup
usb cable plug in and micro-b-to-a plug in can't wake up

| Expected Result |
Can wakeup with wakeup setting, can't wakeup without wakeup setting

|====================================================================

<<<
FSL-UT-USB-034-Remote-Wakeup-Regression-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Remote Wakeup Regression Test

| Automated |
Yes

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1. Prepare a USB host which featured with remote wakeup alternatively, You can
use another i.mx board as USB device.

2. Boot up both boards, and connect two boards with USB cable.

3. At device side, do below commands:
modprobe g_zero autoresume=3  max_autoresume=8 autoresume_interval_ms=1
we can use the above three parameters to control device send resume signal time.
Autoresume is the minimum number of seconds before sending resume signal,
and the time before sending resume signal will automatically increase according
to interval value, the endms is the max number of seconds before sending
resume signal.

4. At host side, first do below command:
echo enabled > /sys/bus/platform/devices/20c9000.usbphy/power/wakeup
echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup
echo enabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup
echo enabled > /sys/bus/usb/devices/usb2/power/wakeup
echo enabled > /sys/bus/usb/devices/2-1/power/wakeup
And you need build a test script to repeat standby the system like below:
while [ 1 ] ;do echo mem  > /sys/power/state;sleep 5 ;done
Then run the test script.

5. Then USB device will enter the suspended state ,and autoresume
milliseconds later,the device will send resume signal to wake up host.
6. The expected behavior is: the host device be waked up, and there is not
re-enumeration happens.
7. The host will enter suspended state again,and test case will repeat step
5 and step 6.
8. Do the same test with HUB connected.

| Expected Result |
See setp 5-7.

|====================================================================

<<<
FSL-UT-USB-035-Loadable-Module-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Loadable Module Test

| Automated |
No

| Kernel Config Option |
Device Drivers  --->
        [*] USB support  --->
                           ChipIdea Highspeed Dual Role Controller
                           USB Gadget Support  --->
                        [*]   USB Physical Layer drivers  --->
                                   Freescale MXS USB PHY support

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1. modprobe phy_mxs_usb; modprobe ci_hdrc_imx
2. modprobe g_mass_storage file=/dev/mmcblk0p1 removable=1
3. plug in usb cable connecting with PC
4. plug out usb cable
5. plug in Micro B-TO-A cable with u-disk connected
6. plug out Micro B-TO-A cable
7. Check clk refcount(/unit_tests/dump-clocks.sh | grep usb)
8. modprobe -r phy_mxs_usb; modprobe -r g_mass_storage
9. modprobe -r ci_hdrc_imx
10. Do step 1-9 with u-disk connected during the boot.


| Expected Result |
No Error, No clock mismatch

|====================================================================

<<<
FSL-UT-USB-036-Loadable-Module-Regression-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Loadable Module Regression Test

| Automated |
Yes

| Kernel Config Option |
Device Drivers  --->
        [*] USB support  --->
                           ChipIdea Highspeed Dual Role Controller
                           USB Gadget Support  --->
                           Freescale MXS USB PHY support

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1. Run below test module load/unload script without any connection
2. Run below test module load/unload script with u-disk connection

----------------------------- test.sh----------------------------
counter=1
while [ 1 ]
do
modprobe phy_mxs_usb
modprobe ci_hdrc_imx
modprobe g_mass_storage file=/dev/mmcblk0p1 removable=1 (or other gadget)
sleep 1
sleep $( expr $RANDOM % 6)
modprobe -r g_mass_storage
modprobe -r ci_hdrc_imx
modprobe -r phy_mxs_usb
sleep 2
counter=$(( $counter + 1 ))
echo "the counter is $counter"
echo "unload module!!!!!!!!!!"
done

| Expected Result |
No Error, No clock mismatch

|====================================================================

<<<
FSL-UT-USB-037-Auto-Suspend-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Auto suspend and remote wakeup test at system ative mode

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1. Put device as well as controller to low power mode
echo auto > /sys/bus/usb/devices/1-1/power/control

2. dump clk
cat /sys/kernel/debug/clk/clk_summary | grep usb

3. For hid device, press key to wakeup device
cat /sys/kernel/debug/clk/clk_summary | grep usb

NOTE: Since the auto-suspend timeout is small, please check
clk count just finish pressing the key

| Expected Result |
The USB device as well as controller can enters low power mode
and be waken up successfully

|====================================================================

<<<
FSL-UT-USB-038-Auto-Suspend-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Using /sys to suspend and auto-resume USB device

| Automated |
Yes

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
test_auto_suspend.sh 1-1
---------------------------------------------------------------
counter=1
while [ 1 ]
do

echo auto > /sys/bus/usb/devices/$1/power/control

sleep 1
echo on > /sys/bus/usb/devices/$1/power/control

counter=$(( $counter + 1 ))
sleep 1
echo "the counter is $counter"

sleep 1

done
---------------------------------------------------------------

| Expected Result |
The USB device as well as controller can enters low power mode
and be waken up successfully, besides, there is no reset/timeout
/disconnect occur during the test

|====================================================================

<<<
FSL-UT-USB-039-HUB-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
USB Test with HUB Connected

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
NOTICE: please check clkcount often

1.1: With USB Hub connected at OTG Port boots up
1.1.1 The u-disk connected at HUB
check clk refcount is 1
plug out u-disk
check clk refcount is 0
plug out hub cable
check clk refcount is 0
plug out Micro-AB cable
check clk refcount is 0


1.1.2 Nothing is needed at HUB
After booting up, and check if clock refcount is 0
plug in usb mouse to see if works OK
plug out usb mouse to see if clock refcount is 0
plug out HUB to see if clock refcount is 0
plug out Micro AB cable to see if clock refcount is 0

1.2: Check u-disk connect/disconnect at hub
Plug in HUB
check clk refcount is 0
plug in u-disk
check clk refcount is 1
plug out u-disk
check clk refcount is 0
re-do u-disk connect/disconnect 10 times, the u-disk needs to be
recognized at every time.
plug out Micro-AB cable with u-disk connected
check clk refcount is 0

1.3: With hub connected, do system suspend/resume
u-disk is connected, do "echo mem > /sys/power/state"
after resume, the u-disk should be existed.
without u-disk connection, after system resume,
the u-disk needs to be recognized after connection.

1.4 Redo 1.1-1.3 with USB mouse

| Expected Result |
Without kernel dump, without clock mismatch

|====================================================================

<<<
FSL-UT-USB-040-system-pm-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
USB Disk connected during system suspend/resume

| Automated |
Yes

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
NOTICE: please check clkcount often using dump-clocks.sh

Pre-test operation
echo enabled > /sys/class/tty/ttymxc0/power/wakeup
mkdir -p /mnt/nfs
mount -t nfs -o nolock 10.192.244.6:/rootfs/wb /mnt/nfs
cd /mnt/nfs/vte_mx63_hf/
source ./manual_test

1.1: With USB Disk connected and copy data during suspend/resume
plug in usb disk
mount /dev/sda1 /media/sda1/
bonnie\+\+ -d /media/sda1 -u 0:0 -s 256 -r 128 & sleep 3; i=0; while [ $i -lt 200 ]; do echo "$i iterations of suspend/resume has finished"; rtc_testapp_6 -T 50; let i=i+1; sleep 5; done;
i=0; while [ $i -lt 20000 ]; do echo "$i iterations of suspend/resume has finished"; rtc_testapp_6 -T 2; let i=i+1; sleep 2; done

1.2: With USB mouse connected and do suspend/resume
plug in usb mouse
i=0; while [ $i -lt 20000 ]; do echo "$i iterations of suspend/resume has finished"; rtc_testapp_6 -T 2; let i=i+1; sleep 2; done

1.3: With USB HUB connected and do suspend/resume
plug in usb HUB
i=0; while [ $i -lt 20000 ]; do echo "$i iterations of suspend/resume has finished"; rtc_testapp_6 -T 2; let i=i+1; sleep 2; done

1.4: With USB HUB (u-disk connected) connected and do suspend/resume
plug in usb HUB (with u-disk connected)
i=0; while [ $i -lt 20000 ]; do echo "$i iterations of suspend/resume has finished"; rtc_testapp_6 -T 2; let i=i+1; sleep 2; done

| Expected Result |
Without error during suspend/resume, and the usb functions are still ok
after finishing suspend/resume test.

|====================================================================

<<<
FSL-UT-USB-041-USB-Host-Class-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Unit test for usb class test

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |

Mass storage and mouse has been tested at other tests.

1. Test camera
1.1: modprobe uvcvideo (if the module is not loaded automatically)

1.2: Try to find video device
Before the camera plug in:
root@freescale ~$ ls /dev/video*
/dev/video16  /dev/video17  /dev/video18  /dev/video19  /dev/video20

After the camera plug in:
root@freescale ~$ ls /dev/video*
/dev/video    /dev/video16  /dev/video18  /dev/video20
/dev/video0   /dev/video17  /dev/video19

So the vedio device is /dev/video0

1.3: Run unit test
./unit_tests/mxc_v4l2_capture.out -uvc -f YUYV -d /dev/video0 -ow 320 -oh 240 -c 1000 test.yuv

You can stop capture using CTRL+C, and use vooya to watch the capture.

2. Test USB sound card
2.1 modprobe snd_usb_audio (if it does not load automatically)

2.2 root@imx6qdlsolo:~# aplay -l
card 2: Pro [SB X-Fi Surround 5.1 Pro], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Pro [SB X-Fi Surround 5.1 Pro], device 1: USB Audio [USB Audio #1]
Subdevices: 1/1
Subdevice #0: subdevice #0

2.3 Play music
cd $STREAM_PATH/alsa_stream_music
aplay -Dhw:2 audio48k16S.wav (supported rate)
aplay -D plug:hw:2,0 *.wav (non supported rate)

2.4 Check the music is ok


3. Test USB Microphone (Need to borrow from test team)
3.1 run aplay -l to know which record device for USB Microphone
3.2 arecord -Dhw:1 -r 48000 -c 1 -f S16_LE -d 20 file_48.wav
3.3 arecord -Dhw:1 -r 44100 -c 1 -f S16_LE -d 20 file_44.wav
3.4 aplay -Dplughw:0 file_44.wav file_48.wav (with on board codec to check)

| Expected Result |
No error during the operation

|====================================================================

<<<
FSL-UT-USB-042-USB-Peripheral-Mode-Class-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Test kinds of class at peripheral mode

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
Since the mass storage has been tested during the role switch
test, so it only tests g_ether and g_serial

1: Test g_serial
1.1 modprobe g_serial
connect usb cable between board and pc, and you will see below message
"g_serial gadget: high-speed config #2: CDC ACM config"

1.2 Test data transfer from device to host
run "cat /dev/ttyACM0" at host side
run "echo "Happy New Year" > /dev/ttyGS0" at device side
You should see "Happy New Year" at console of host side

1.3 Test data transfer from host to device
run "cat /dev/ttyACM0" at device side
run "echo "Happy New Year" > /dev/ttyGS0" at host side
You should see "Happy New Year" at console of device side

2: Test g_ether
2.1 modprobe g_ether qmult=10
connect usb cable between board and pc, and you will see below message
"g_ether gadget: high-speed config #1: CDC Ethernet (ECM)"

2.2
At device side:
ifconfig usb0 10.0.0.2 up
At host side:
sudo ifconfig usb0 10.0.0.1 up

At device side:
ping 10.0.0.1, for ubuntu host, the ip for usb0 will lost
after several seconds, re ifconfig usb0 at host side

After ping can run more than 10 seconds, stop it

2.3 Using iperf to do ether test

At host side:
iperf -s -i 5 &
At device side:
iperf -t 1000000 -c  10.0.0.1 -d -i 5 &

2.4
The connect should be there during the overnight test
The speed is about 120Mbps.

| Expected Result |
There should be no error during the transfer

|====================================================================

<<<
FSL-UT-USB-043-USB-Performance-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Performance Test

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
For device mode, using g_ether to test
For host mode, using mass storage to test (hard disk is needed)

1: Test g_ether
1.1 modprobe g_ether qmult=10
connect usb cable between board and pc, and you will see below message
"g_ether gadget: high-speed config #1: CDC Ethernet (ECM)"

1.2
At device side:
ifconfig usb0 10.0.0.2 up
At host side:
sudo ifconfig usb0 10.0.0.1 up

At device side:
ping 10.0.0.1, for ubuntu host, the ip for usb0 will lost
after several seconds, re ifconfig usb0 at host side

After ping can run more than 10 seconds, stop it

1.3 Using iperf to do ether test

At host side:
iperf -s -i 5 &
At device side:
iperf -t 1000000 -c  10.0.0.1 -d -i 5 &

2 mass storage test
2.1 block layer Read
time -p dd if=/dev/sda2 of=/dev/null bs=4096 count=204800
2.2 block layer write
time -p dd if=/dev/zero of=/dev/sda2 bs=4096 count=204800
2.3 filesystem layer
iozone -a -i 1 -i 0 -U /media/sda2 -s 4096m -f  /media/sda2/iozone.test -b /mnt/tmp/iozone_usb_result.xls

| Expected Result |
g_ether: 15MB/s
Block layer read: 21.1MB/s
Block layer write: 17.0MB/s
Filesystem layer (ext3): 19MB/s(R), 7.2MB/s(W)
NOTES: for iozone, it should has file cache during the test.

|====================================================================

<<<
FSL-UT-USB-044-USB-DR-MODE-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Test peripheral-only and host-only mode through dt file

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
Change dts file to support it (eg: arch/arm/boot/dts/imx6qdl-sabreauto.dtsi)

1. Test dr_mode = "host"
1.1 Rebuild dtb
# modprobe -r ci_hdrc_imx; modprobe -r phy_mxs_usb; modprobe phy_mxs_usb && modprobe ci_hdrc_imx
try if peripheral function is ok, the g_serial should not be inserted.

1.2 Hotplug test in low power status without host wakeup support
# echo mem > /sys/power/state
Plugin u-disk into Host/OTG port
Resume system by POWER switch and the u-disk should be found
For ARD, use console wakeup
# echo mem > /sys/power/state
Plugout u-disk from Host/OTG port
Resume system by POWER switch and the u-disk detach disconnet should be noticed
Repeat this step 3 times
1.3 USB mouse remote wakeup test
Connect USB mouse to Host/OTG port
# low_power_usb.sh; echo mem > /sys/power/state
Click USB mouse to wakeup system
Repeat this step to verify system can suspend/resume again
1.4 Connect/disconnect wakeup
# low_power_usb.sh; echo mem > /sys/power/state
Plugin or plug out USB device from Host/OTG,
System should be wakeup
5. Special for OTG port
# echo mem > /sys/power/state
Then only plugin a microAB to female A cable(without device) to OTG port
The system should NOT be wakeup
Resume board by POWER switch and
# echo mem > /sys/power/state
Connect OTG port to PC
The system should NOT be wakeup

2 Test dr_mode = "peripheral"
2.1 boot from rebuilt kernel and dtb and usb mouse at the board
# modprobe -r ci_hdrc_imx; modprobe -r phy_mxs_usb; modprobe phy_mxs_usb && modprobe ci_hdrc_imx
The mouse should not be recognized.

2. Test g_mass_storage module
In board
# dd if=/dev/zero of=/var/storage.img bs=1M count=64
# mkfs.vfat /var/storage.img
# modprobe g_mass_storage file=/var/storage.img removable=1
In Host PC:
# mkdir -p /mnt/flash
# umount /mnt/flash
# mount -t vfat /dev/sdxx /mnt/flash (sdxx is the partition exported by g_file_storage in target board whose size is near 64M)
# bonnie++ -d /mnt/flash -u 0:0 -s 32 -r 16
# dt of=/mnt/flash/test_file bs=4k limit=63m passes=20
Above commands should pass
In board:
# modprobe -r g_mass_storage
# modprobe -r ci_hdrc_imx; modprobe -r phy_mxs_usb
Remove the USB cable from OTG port
3. Repeat steps 1 & 2

| Expected Result |
There should be no error during the test

|====================================================================

<<<
FSL-UT-USB-045-USB-Device-Host-Only-Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Test peripheral-only and host-only mode by building out other driver

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
Build out other driver through make menuconfig

1. Test host-only driver
1.1 Rebuild kernel
# modprobe -r ci_hdrc_imx; modprobe -r phy_mxs_usb; modprobe phy_mxs_usb && modprobe ci_hdrc_imx
try if peripheral function is ok, the g_serial should not be inserted.

1.2 Hotplug test in low power status without host wakeup support
# echo mem > /sys/power/state
Plugin u-disk into Host/OTG port
Resume system by POWER switch and the u-disk should be found
For ARD, use console wakeup
# echo mem > /sys/power/state
Plugout u-disk from Host/OTG port
Resume system by POWER switch and the u-disk detach disconnet should be noticed
Repeat this step 3 times
1.3 USB mouse remote wakeup test
Connect USB mouse to Host/OTG port
# low_power_usb.sh; echo mem > /sys/power/state
Click USB mouse to wakeup system
Repeat this step to verify system can suspend/resume again
1.4 Connect/disconnect wakeup
# low_power_usb.sh; echo mem > /sys/power/state
Plugin or plug out USB device from Host/OTG,
System should be wakeup
1.5 Special for OTG port
# echo mem > /sys/power/state
Then only plugin a microAB to female A cable(without device) to OTG port
The system should NOT be wakeup
Resume board by POWER switch and
# echo mem > /sys/power/state
Connect OTG port to PC
The system should NOT be wakeup

2 Test peripheral-only driver
2.1 boot from rebuilt kernel and connect usb mouse at the board
# modprobe -r ci_hdrc_imx; modprobe -r phy_mxs_usb; modprobe phy_mxs_usb && modprobe ci_hdrc_imx
The mouse should not be recognized.

2.2 Test g_mass_storage module
In board
# dd if=/dev/zero of=/var/storage.img bs=1M count=64
# mkfs.vfat /var/storage.img
# modprobe g_mass_storage file=/var/storage.img removable=1
In Host PC:
# mkdir -p /mnt/flash
# umount /mnt/flash
# mount -t vfat /dev/sdxx /mnt/flash (sdxx is the partition exported by g_file_storage in target board whose size is near 64M)
# bonnie++ -d /mnt/flash -u 0:0 -s 32 -r 16
# dt of=/mnt/flash/test_file bs=4k limit=63m passes=20
Above commands should pass
In board:
# modprobe -r g_mass_storage
# modprobe -r ci_hdrc_imx; modprobe -r phy_mxs_usb
Remove the USB cable from OTG port
2.3 Repeat above steps

2.4 Wakeup test
the ID change should not wake up system
2.4.1 dd if=/dev/zero of=/var/storage.img bs=1M count=64
2.4.2 mkfs.vfat /var/storage.img
2.4.3 modprobe g_mass_storage file=/var/storage.img removable=1
2.4.4 Enable wakeup setting: usb_wakeup.sh

#/bin/sh
        for i in $(find /sys -name wakeup | grep usb)
        do
                echo enabled > $i
                echo "echo enabled > $i"
        done
2.4.5 suspend system, echo mem > /sys/power/suspend
2.4.6 plug in Micro-AB cable should not wakeup system
2.4.7 wakeup system through serial port, nothing should be happened
for usb otg port.

| Expected Result |
There should be no error during the test

|====================================================================

<<<

V4L2
----
FSL-UT-V4L2-001
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
v4l2 video capture and display test

| Automated |
NO

| Kernel Config Option |
N/A

| Software Dependency |
N/A

| Non-default Hardware Configuration |
camera and display required.

| Test Procedure |
Check that /dev/video0 exists. If it does not exist, load the camera driver with the command:

modprobe mxc_v4l2_capture

modprobe CAMERA_MODULE (CAMERA_MODULE should be replaced by the camera module on the related platform, e.g. ov3640_camera should be used here on MX51)

Check again for /dev/video0. If it is not there, the camera driver has not loaded successfully and the test has failed.

Type the following command line in a writable directory. The 50 frames of video from the camera will be captured in the file "test.yuv" at a resolution of 352x288 with no rotation and a frame rate of 30 fps. The format will be YUV420.

 mxc_v4l2_capture.out -iw 352 -ih 288 -ow 352 -oh 288 -r 0 -c 50 -fr 30 test.yuv

| Expected Result |
There should be no errors or warnings. The file "test.yuv" will be created with a size of 7603200.

To display the video at the resolution of 176x144, use the command line below (a different resolution may be used depending on display size):

 mxc_v4l2_output.out -iw 352 -ih 288 -ow 176 -oh 144 -r 0 -fr 30 test.yuv

Verify captured file contents match viewfinder and that the image is clear and the colors correct.

|====================================================================

<<<
FSL-UT-V4L2-002
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
v4l2 still image capture and display test

| Automated |
NO

| Kernel Config Option |
N/A

| Software Dependency |
N/A

| Non-default Hardware Configuration |
camera and display required.

| Test Procedure |

Check that /dev/video0 exists. If it does not exist, load the camera driver with the command:

 modprobe mxc_v4l2_capture

modprobe CAMERA_MODULE (CAMERA_MODULE should be replaced by the camera module on the related platform, e.g. ov3640_camera should be used here on MX51)

Check again for /dev/video0. If it is not there, the camera driver has not loaded successfully and the test has failed.

Type the following command line in a writable directory. A still image at the resolution of 640x480 will be saved in the file "still.yuv" in the format YUV422 planar.

 mxc_v4l2_still.out -w 640 -h 480 -f YUV422P?


Note: YUV420 is the fommat defined by sensor(UYVY,YY), and needs to convert to YV12 format, then it can be viewed by common tool.

| Expected Result |
No errors or warnings seen.


The file "still.yuv" is created with the size of 614400.

The image can be viewed with:

 mxc_v4l2_output.out -iw 640 -ih 480 -ow 176 -oh 144 -l 100 -f 422P still.yuv

The image should be the correct image, clear and with the correct colors.


|====================================================================

<<<
FSL-UT-V4L2-003
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
camera preview

| Automated |
NO

| Kernel Config Option |
N/A

| Software Dependency |
N/A

| Non-default Hardware Configuration |
A camera and display are required.

| Test Procedure |

Check that /dev/video0 exists. If it does not exist, load the camera driver with the command:

 modprobe mxc_v4l2_capture

modprobe CAMERA_MODULE (CAMERA_MODULE should be replaced by the camera module on the related platform, e.g. ov3640_camera should be used here on MX51)

Check again for /dev/video0. If it is not there, the camera driver has not loaded successfully and the test has failed.

Type the following command.

 mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 160 -oh 160 -ot 20 -ol 20 -r 0 -t 50 -do 0 -fg -fr 30

Direct preview the camera to the foreground, and set the frame rate to 30 fps, the window of interest is 640 X 480 with a starting offset of (0,0), the preview size is 160 X 160 with a starting offset of (20,20). Use mxc_v4l2_overlay.out -help to see usage.

| Expected Result |
The image from the camera is displayed on the screen. Colors and image should be correct.

|====================================================================

<<<
FSL-UT-V4L2-004
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
camera preview - rotated

| Automated |
NO

| Kernel Config Option |
N/A

| Software Dependency |
N/A

| Non-default Hardware Configuration |
camera and display required.

| Test Procedure |
Check that /dev/video0 exists. If it does not exist, load the camera driver with the command:

 modprobe mxc_v4l2_capture

modprobe CAMERA_MODULE (CAMERA_MODULE should be replaced by the camera module on the related platform, e.g. ov3640_camera should be used here on MX51)

Check again for /dev/video0. If it is not there, the camera driver has not loaded successfully and the test has failed.

Type the following command.

 mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 160 -oh 160 -ot 20 -ol 20 -r 4 -t 50 -do 0 -fr 30

Direct preview (90 degree rotation) the camera to the background, and set frame rate to 30 fps.

| Expected Result |
The image from the camera is displayed on the screen rotated by 90 degrees. Colors and image should be correct.

|====================================================================

<<<
FSL-UT-V4L2-005
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
V4L2 auto-test

| Automated |
YES

| Kernel Config Option |
N/A

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
Go to unit test dir, run ./autorun-v4l2.sh > log

This test auto test v4l2 features.

Note: there are some cases which v4l2 output can not support by IPU, which will return error by v4l2 set format fail or set crop fail etc, pls check the log for this except case.

If need full test, please run test after export FULLTEST=1

| Expected Result |
"PASS test case:xxxx" should be print.

|====================================================================

<<<
FSL-UT-V4L2-006
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
TV-Out test

| Automated |
NO

| Kernel Config Option |
N/A

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1. test PAL mode:
#>echo U:720x576i-50 > /sys/class/graphics/fb1/mode
#>echo 0 > /sys/class/graphics/fb1/blank
#>/unit_tests/mxc_v4l2_output.out -iw 320 -ih 240 -ow 720 -oh 576 -d 5

2. test NTSC mode:
#>echo U:720x480i-60 > /sys/class/graphics/fb1/mode
#>echo 0 > /sys/class/graphics/fb1/blank
#>/unit_tests/mxc_v4l2_output.out -iw 320 -ih 240 -ow 720 -oh 480 -d 5

3. test 720p mode:
1) Add "hdtv" in the boot command line;
2) After the system boot up, execute:
#>echo U:1280x720p-60 > /sys/class/graphics/fb1/mode
#>echo 0 > /sys/class/graphics/fb1/blank
#>/unit_tests/mxc_v4l2_output.out -iw 320 -ih 240 -ow 720 -oh 480 -d 5

| Expected Result |
Color bar display on the TV.

|====================================================================

<<<
FSL-UT-V4L2-007
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Camera suspend and resume

| Automated |
NO

| Kernel Config Option |
N/A

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1. Ensure camera can enter suspend
echo standby > /sys/power/state
2. Press one key to resume
3. Retest camera function again

| Expected Result |
Camera can work normally after resume

|====================================================================

<<<
FSL-UT-V4L2-008
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
MIPI CSI preview

| Automated |
NO

| Kernel Config Option |
N/A

| Software Dependency |
N/A

| Non-default Hardware Configuration |
ov5640 sensor and MIPI extention board are requried display screen also is needed

| Test Procedure |
Check that /dev/video1 exists. If it does not exist, load the camera driver with the command:

modprobe mxc_v4l2_capture

modprobe CAMERA_MODULE (CAMERA_MODULE should be replaced by the camera module on the related platform, e.g. ov5640_camera_mipi should be used here on MX6Q)

Check again for /dev/video1. If it is not there, the camera driver has not loaded successfully and the test has failed.

Type commands to direct preview the camera to the foreground/background, and set the frame rate to 30 fps, the preview size is 640 X 480 with a starting offset of (0,0). Use mxc_v4l2_overlay.out -help to see usage.

Test foreground display:

Test 1. mxc_v4l2_overlay.out -iw 640 -ih 480 -ow 640 -oh 480 -m 0 -di /dev/video1 -fg

Test 2. mxc_v4l2_overlay.out -iw 320 -ih 240 -ow 640 -oh 480 -m 1 -di /dev/video1 -fg

Test 3. mxc_v4l2_overlay.out -iw 720 -ih 480 -ow 640 -oh 480 -m 2 -di /dev/video1 -fg

Test 4. mxc_v4l2_overlay.out -iw 720 -ih 576 -ow 640 -oh 480 -m 3 -di /dev/video1 -fg

Test 5. mxc_v4l2_overlay.out -iw 1280 -ih 720 -ow 640 -oh 480 -m 4 -di /dev/video1 -fg

Test 6. mxc_v4l2_overlay.out -iw 1920 -ih 1080 -ow 640 -oh 480 -m 5 -di /dev/video1 -fg

Test 7. mxc_v4l2_overlay.out -iw 2592 -ih 1944 -ow 640 -oh 480 -m 6 -fr 15 -di /dev/video1 -fg

Test background display:

Test 8. mxc_v4l2_overlay.out -iw 640 -ih 480 -ow 640 -oh 480 -m 0 -di /dev/video1 -bg

Test 9. mxc_v4l2_overlay.out -iw 320 -ih 240 -ow 640 -oh 480 -m 1 -di /dev/video1 -bg

Test 10. mxc_v4l2_overlay.out -iw 720 -ih 480 -ow 640 -oh 480 -m 2 -di /dev/video1 -bg

Test 11. mxc_v4l2_overlay.out -iw 720 -ih 576 -ow 640 -oh 480 -m 3 -di /dev/video1 -bg

Test 12. mxc_v4l2_overlay.out -iw 1280 -ih 720 -ow 640 -oh 480 -m 4 -di /dev/video1 -bg

Test 13. mxc_v4l2_overlay.out -iw 1920 -ih 1080 -ow 640 -oh 480 -m 5 -di /dev/video1 -bg

Test 14. mxc_v4l2_overlay.out -iw 2592 -ih 1944 -ow 640 -oh 480 -m 6 -fr 15 -di /dev/video1 -bg

| Expected Result |
The image from the camera is displayed on the screen. Colors and image should be correct.

|====================================================================

<<<
FSL-UT-V4L2-009
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
MIPI CSI Capture

| Automated |
NO

| Kernel Config Option |
N/A

| Software Dependency |
N/A

| Non-default Hardware Configuration |
ov5640 sensor and MIPI extention board are requried

| Test Procedure |
Check that /dev/video1 exists. If it does not exist, load the camera driver with the command: modprobe mxc_v4l2_capture

modprobe CAMERA_MODULE (CAMERA_MODULE should be replaced by the camera module on the related platform, e.g. ov5640_camera_mipi should be used here on MX6Q).

Check again for /dev/video1. If it is not there, the camera driver has not loaded successfully and the test has failed.

Type the following command lines in a writable directory. The 50 frames of video from the camera will be captured in the file "test.yuv" for each resolution. The format will be YUV420.

Test CSI->SMFC->MEM:

Test 1. mxc_v4l2_capture.out -iw 640 -ih 480 -ow 640 -oh 480 -m 0 -i 1 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 2. mxc_v4l2_capture.out -iw 320 -ih 240 -ow 320 -oh 240 -m 1 -i 1 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 3. mxc_v4l2_capture.out -iw 720 -ih 480 -ow 720 -oh 480 -m 2 -i 1 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 4. mxc_v4l2_capture.out -iw 720 -ih 576 -ow 720 -oh 576 -m 3 -i 1 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 5. mxc_v4l2_capture.out -iw 1280 -ih 720 -ow 1280 -oh 720 -m 4 -i 1 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 6. mxc_v4l2_capture.out -iw 1920 -ih 1080 -ow 1920 -oh 1080 -m 5 -i 1 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 7. mxc_v4l2_capture.out -iw 2592 -ih 1944 -ow 2592 -oh 1944 -m 6 -i 1 -r 0 -c 50 -fr 15 -d /dev/video1 test.yuv

Test CSI->PRP->MEM:

Test 8. mxc_v4l2_capture.out -iw 640 -ih 480 -ow 640 -oh 480 -m 0 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 9. mxc_v4l2_capture.out -iw 320 -ih 240 -ow 640 -oh 480 -m 1 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 10. mxc_v4l2_capture.out -iw 720 -ih 480 -ow 640 -oh 480 -m 2 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 11. mxc_v4l2_capture.out -iw 720 -ih 576 -ow 640 -oh 480 -m 3 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 12. mxc_v4l2_capture.out -iw 1280 -ih 720 -ow 640 -oh 480 -m 4 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 13. mxc_v4l2_capture.out -iw 1920 -ih 1080 -ow 640 -oh 480 -m 5 -r 0 -c 50 -fr 30 -d /dev/video1 test.yuv

Test 14. mxc_v4l2_capture.out -iw 2592 -ih 1944 -ow 640 -oh 480 -m 6 -r 0 -c 50 -fr 15 -d /dev/video1 test.yuv

| Expected Result |
There should be no errors or warnings. The file "test.yuv" will be created.

To display the video at the resolution of 640x480, use the command line below (a different resolution may be used depending on display size), then verify captured file contents match viewfinder and that the image is clear and the colors correct.

For Test 1. mxc_v4l2_output.out -iw 640 -ih 480 -ow 640 -oh 480 -r 0 -fr 30 test.yuv

For Test 2. mxc_v4l2_output.out -iw 320 -ih 240 -ow 640 -oh 480 -r 0 -fr 30 test.yuv

For Test 3. mxc_v4l2_output.out -iw 720 -ih 480 -ow 640 -oh 480 -r 0 -fr 30 test.yuv

For Test 4. mxc_v4l2_output.out -iw 720 -ih 576 -ow 640 -oh 480 -r 0 -fr 30 test.yuv

For Test 5. mxc_v4l2_output.out -iw 1280 -ih 720 -ow 640 -oh 480 -r 0 -fr 30 test.yuv

For Test 6. mxc_v4l2_output.out -iw 1920 -ih 1080 -ow 640 -oh 480 -r 0 -fr 30 test.yuv

For Test 7. mxc_v4l2_output.out -iw 2592 -ih 1944 -ow 640 -oh 480 -r 0 -fr 15 test.yuv

For Test 8-13. mxc_v4l2_output.out -iw 640 -ih 480 -ow 640 -oh 480 -r 0 -fr 30 test.yuv

For Test 14. mxc_v4l2_output.out -iw 640 -ih 480 -ow 640 -oh 480 -r 0 -fr 15 test.yuv

|====================================================================

<<<

VPU
---
FSL-UT-VPU-001
~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Decode one stream and display on the LCD

| Automated |
No

| Kernel Config Option |
N/A

| Software Dependency |
Need /usr/lib/libvpu.so

| Non-default Hardware Configuration |
The test files are not in unit_tests. The test files must be procured by the person running the test.

| Test Procedure |
To test MPEG-4 decode:

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.m4v -f 0"

To test H.263 decode:

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.263 -f 1"

To test H.264 decode:

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.264 -f 2"

To test VC1 decode (i.MX37 and i.MX51 VPU only):

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.rcv -f 3"

To test MPEG2 decode (i.MX37 and i.MX51 VPU only):

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.mpg -f 4"

To test MJPEG decode (i.MX51 VPU only):

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.mjpg -f 7"

You can get the mp4 test file from this location the linux-test.git server. It is located under [linux-test.git]/test/mxc_vpu_test/configs/akiyo.mp4

| Expected Result |
Stream is displayed on the LCD correctly.

|====================================================================

<<<
FSL-UT-VPU-002
~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Decode a stream and save to a file

| Automated |
No

| Kernel Config Option |
N/A

| Software Dependency |
Need /usr/lib/libvpu.so

| Non-default Hardware Configuration |
N/A

| Test Procedure |
To test MPEG-4 decode:

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.m4v -f 0 -o out.yuv"

To test H.263 decode:

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.263 -f 1 -o out.yuv"

To test H.264 decode:

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.264 -f 2 -o out.yuv"

To test VC1 decode (i.MX37 and i.MX51 VPU only):

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.rcv -f 3 -o out.yuv"

To test MPEG2 decode (i.MX37 and i.MX51 VPU only):

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.mpg -f 4 -o out.yuv"

To test MJPEG decode (i.MX51 VPU only):

 ./mxc_vpu_test.out -D "-i /usr/vectors/file.mjpg -f 7 -o out.yuv"

| Expected Result |
Stream is saved to file correctly.

|====================================================================

<<<
FSL-UT-VPU-003
~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Decode a stream using a config file

| Automated |
Yes

| Kernel Config Option |
N/A

| Software Dependency |
Need /usr/lib/libvpu.so

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1. Change options in config file, e.g, config_dec. Input correct input filename, output filename, format,etc.
2. Test with command:

 ./mxc_vpu_test.out -C config_dec

| Expected Result |
Stream can be decoded successfully.

|====================================================================

<<<
FSL-UT-VPU-004
~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Encode a YUV stream and save to a file

| Automated |
No

| Kernel Config Option |
N/A

| Software Dependency |
Need /usr/lib/libvpu.so

| Non-default Hardware Configuration |
N/A

| Test Procedure |
To test MPEG-4 encode:

 ./mxc_vpu_test.out -E "-i file.yuv -w 240 -h 320 -f 0 -o file.mpeg4"

To test H.263 encode:

 ./mxc_vpu_test.out -E "-i file.yuv -w 240 -h 320 -f 1 -o file.263"

To test H.264 encode:

 ./mxc_vpu_test.out -E "-i file.yuv -w 240 -h 320 -f 2 -o file.264"

To test MJPEG encode (i.MX51 VPU only):

 ./mxc_vpu_test.out -E "-i file.yuv -w 240 -h 320 -f 7 -o file.mjpg"

| Expected Result |
Stream can be encoded successfully.

We can use VPU decoder command to check encoded data is correct or not.

|====================================================================

<<<
FSL-UT-VPU-005
~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Encode an image from the camera and decode it to display on the LCD

| Automated |
No

| Kernel Config Option |
N/A

| Software Dependency |
Need /usr/lib/libvpu.so

| Non-default Hardware Configuration |
N/A

| Test Procedure |
To encode an MPEG4 image from the camera and display on the LCD.

 ./mxc_vpu_test.out -L "-f 0 -w 240 -h 320"

To encode an H263 image from the camera and display on the LCD.

 ./mxc_vpu_test.out -L "-f 1 -w 240 -h 320"

To encode an H264 image from the camera and display on the LCD.

 ./mxc_vpu_test.out -L "-f 2 -w 240 -h 320"

To encode an MJPG image from the camera and display on the LCD (i.MX51 VPU only).

 ./mxc_vpu_test.out -L "-f 7 -w 240 -h 320"

| Expected Result |
Captured image can be displayed on the LCD correctly.

|====================================================================

<<<
FSL-UT-VPU-006
~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Decode multiple streams with different formats simultaneously

| Automated |
No

| Kernel Config Option |
N/A

| Software Dependency |
Need /usr/lib/libvpu.so

| Non-default Hardware Configuration |
N/A

| Test Procedure |
To decode multiple streams with different formats simultaneously. For example, decoder one H264 and one MPEG4 streams.

 ./mxc_vpu_test.out -D "-i/vectors/file.264 -f 2" -D "-i ./akiyo.mp4 -f 0 -o akiyo.yuv"

| Expected Result |
Streams can be decoded correctly.

|====================================================================

<<<
FSL-UT-VPU-007
~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Decode and encode simultaneously

| Automated |
No

| Kernel Config Option |
N/A

| Software Dependency |
Need /usr/lib/libvpu.so

| Non-default Hardware Configuration |
N/A

| Test Procedure |
To decode and encode simultaneously. For example, encode one MPEG-4 stream and decode one H.264 stream simultaneously.

 ./mxc_vpu_test.out -E "-w 176 -h 144 -f 0 -o enc.m4v" -D "-i/vectors/file.264 -f 2"

| Expected Result |
Streams can be encoded/decoded correctly.

|====================================================================

<<<
FSL-UT-VPU-008
~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
VPU suspend and resume

| Automated |
No

| Kernel Config Option |
N/A

| Software Dependency |
Need /usr/lib/libvpu.so

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1. Ensure VPU can enter suspend

 echo standby > /sys/power/state

2. Press one key to resume
3. Retest VPU function again

| Expected Result |
VPU can work normally after resume

|====================================================================

<<<
FSL-UT-VPU-009
~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Test VPU with TV out

| Automated |
No

| Kernel Config Option |
N/A

| Software Dependency |
Need /usr/lib/libvpu.so

| Non-default Hardware Configuration |
Connect board to TV with correct lines.

| Test Procedure |
1. Set environment per TV mode

 NTSC mode: export VPU_TV_MODE=NTSC
 PAL mode: export VPU_TV_MODE=PAL
 720P mode (This is avaiable on MX51): export VPU_TV_MODE=720P

2. Decoder one stream as normal vpu test. For exmaple, H264 video stream

 /unit_tests/mxc_vpu_test.out -D "-i filename -f 2"

Note

Please make sure input stream is 1280 * 720 when TV mode is 720P.

| Expected Result |
Video is displayed correctly on TV

|====================================================================

<<<
FSL-UT-VPU-010
~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Test VPU with VDI (HW deinterlace via IPU)

| Automated |
No

| Kernel Config Option |
N/A

| Software Dependency |
Need /usr/lib/libvpu.so

| Non-default Hardware Configuration |
N/A

| Test Procedure |
1. Select one stream with top and bottem filelds are interlaced.

 av_stress2_dsmcc4m_1_C1_V11_A6.mp4_track1.h264

2. Decode the stream and display on LCD with command:

 /unit_tests/mxc_vpu_test.out -D "-i av_stress2_dsmcc4m_1_C1_V11_A6.mp4_track1.h264 -f2"

3. Decode the stream and display on LCD using high motion stream video De Interlacing algorithm with command:

 /unit_tests/mxc_vpu_test.out -D "-i av_stress2_dsmcc4m_1_C1_V11_A6.mp4_track1.h264 -v h -f2"

4. Decode the stream and display on LCD using low motion stream video De Interlacing algorithm with command:

 /unit_tests/mxc_vpu_test.out -D "-i av_stress2_dsmcc4m_1_C1_V11_A6.mp4_track1.h264 -v l -f2"

5. Decode the stream and display on LCD having input in NV12 pixel format with command:

 /unit_tests/mxc_vpu_test.out -D "-i av_stress2_dsmcc4m_1_C1_V11_A6.mp4_track1.h264 -v l -t 1 -f2"

| Expected Result |
The video is smooth and there is no field sawtooth for moving objects

|====================================================================

<<<

WDOG
----
FSL-UT-WDOG-001
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Check WatchDog device node

| Automated |
YES

| Kernel Config Option |
CONFIG_WATCHDOG=y

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
. run the following command on target board,

 $ /unit_tests/autorun-wdog.sh

| Expected Result |
Should get the following message:

 autorun-wdog.sh: Exiting PASS

|====================================================================

<<<
FSL-UT-WDOG-002
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
WatchDog reset when timeout

| Automated |

| Kernel Config Option |
CONFIG_WATCHDOG=y

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
. run the following command on target board,

 $ /unit_tests/wdt_driver_test.out 1 2 0 &

| Expected Result |
This should generate a reset after 3 seconds (a 1 second time-out and a 2 second sleep).

|====================================================================

<<<
FSL-UT-WDOG-003
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
WatchDog doesn't reset when timeout

| Automated |

| Kernel Config Option |
CONFIG_WATCHDOG=y

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
.Test Steps
. run the following command on target board,

 $ /unit_tests/wdt_driver_test.out 2 1 0

. The system should keep running without being reset. This test requires the kernel to be executed with the "jtag=on" on some platforms.
. Press "Ctrl+C" to terminate this test program.

| Expected Result |
The system reset after 3 seconds


|====================================================================

<<<
FSL-UT-WDOG-004
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
Watchdog suspend and resume

| Automated |

| Kernel Config Option |
CONFIG_WATCHDOG=y

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
.Test Steps
. Ensure Watchdog can enter suspend

 echo mem > /sys/power/state

. Press one key to resume
. Retest Watchdog function again

| Expected Result |
Watchdog can work normally after resume

|====================================================================

<<<
FSL-UT-WDOG-005
~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
The system can reboot well

| Automated |

| Kernel Config Option |
CONFIG_WATCHDOG=y

| Software Dependency |
N/A

| Non-default Hardware Configuration |
N/A

| Test Procedure |
.Test Steps

 reboot

| Expected Result |
reboot

|====================================================================

<<<

WIFI
----
FSL-UT-WIFI-001-Basci-Function
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
WIFI Basci test

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |

| Test Procedure |

.For Atheros AR6003
. iwconfig wlan0
. iwlist wlan0 scan (search APs)
. iwconfig wlan0 essid XXX (associate with AP, XXX is the AP name)
. ifconfig wlan0 192.168.1. xx

  or get IP address dynamicly:
  dhclient wlan0

. Ping 192.168.1.1
. scp root@192.168.1.1:/xx/xx .

| Expected Result |
Ping and SCP pass

|====================================================================

<<<
FSL-UT-WIFI-001-Suspend Resume
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[cols=">s,6a",frame="topbot",options="header"]
|====================================================================
|Name | Description

| Summary |
WIFI Suspend Resume

| Automated |
No

| Kernel Config Option |

| Software Dependency |
N/A

| Non-default Hardware Configuration |

| Test Procedure |

.Steps
. Ensure WIFI can enter suspend

  echo mem > /sys/power/state

. Press one key to resume
. retest WIFI function

| Expected Result |
WIFI can work normally after resume

|====================================================================

<<<