world leader in high performance signal processing
  |   Forum
Analog Devices Inc. Wiki : [[linux-kernel:testing]]
print this page   Text Export   ODT Export   PDF Export
Recent changes | Old revisions | Show pagesource
Trace: » testing
Table of Contents

Testing the Linux Kernel

Purpose

The purpose of testing the Linux kernel is to ensure each part of the released image, such as the system calls, IPC mechanism, file system, network, device drivers, memory management is stable and robust, so that it can support various applications running well.

Overview

To test the Linux kernel, a host system and Blackfin target are required. The host system is where the Linux source code is downloaded and built. The Blackfin target enables tests to be run on the real processor platform ensuring that the Linux kernel image can take control from uboot, initialize the processor and peripherals, and operate the whole system properly. For now, the following types of target boards covered in this test: BF533-STAMP, BF537-STAMP, BF533-EZKIT, BF561-EZKIT, BF548-EZKIT, BF527-EZKIT, BF538-EZKIT,BF526-EZBRD, BF518-EZBRD, BF609-EZKIT. For the detailed coverage info, see Linux_test_coverage.

Besides, in current release there are two versions of toolchain released, and each of it support compiling both elf and flat format applications. As a result, four kinds of kernel image could be generated in the host environment of Suse linux, flat format image by 4.1 toolchain, flat format image by 4.3 toolchain, elf format image by 4.1 toolchain, elf format image by 4.3 toolchain. Also it needs to test the linux image built in the host environment of COLINUX.

The tests below would been carried out on kernel built by either 4.1 or 4.3 toolchain with various kernel configuration(flat format application). As to the elf toolchain, since the format just referrs to applications, only application related testcases would be executed. And there is also some difference for certain cases to run on different boards, the following part would describe in detailed ways.

In order to secure the kernel performance at all the working frequencies, the Linux kernel testing is needed to take at various system clock and core clock. The working range for the boards is about 30~120Mhz System Clock and 30~600Mhz Core Clock.

LTP test(WT,WB)

The Linux Test Project(LTP) is a collection of tools for testing the Linux kernel and related features with a goal to deliver test suites to the open source community that validate the reliability, robustness, and stability of Linux. It helps to improve the Linux kernel by bringing test automation to the kernel testing effort. And its test covers almost all the parts of Linux, such as system calls, file system, device driver, IPC, memory managent, and timer, etc. For detailed information on LTP project, refer to the LTP page.

Since the LTP project is intented for desktop linux system, which has some difference from the Linux system here. It is required to port this project to make it run. So far, the system call, pthread and file system test cases are adopted in this test, approximately about 600 cases. The LTP testing is carried out on the RAM system of the target board, while the testcases are stored on host machine and transferred to the target by rcp in the process of testing. In this way, we can possible to test on the target that has no big SDRAM, for the whole size of the test cases can total to about 40M. In the end, there is a summary log tells the number and the names of passed cases, failed cases, the warning, broken, crashing ones and which is not run.

You can get LTP source code from LTP website or get from our Linux svn. There are several versions of ltp source code in svn. Please checkout out the latested one. 

svn ls svn://firewall-sources.blackfin.uclinux.org:80/svn/ltp/trunk

svn co svn://firewall-sources.blackfin.uclinux.org:80/svn/ltp/trunk/ltp-full-20071031 ltp-full-20071031

Enter the folder named ltp, there is a prog directory which is ported for our blackfin testing. 

cd ltp-full-20071031/
make uclinux
make uclinux_install

All these steps to run the cases are automated into an expect script, ltp_auto_test.exp which can keep the ltp test cases always running. For certain cases would sometimes crash the kernel and put the target board out of order, there is a wire connection to restart from the host parallel port 2.

By default, we run LTP test cases under /home/test/work/cruise/checkouts/uclinux-dist/testsuites/ltp folder. You need to specify your test running directories before execution the script and make sure a usable toolchain path is exported to environment variable $PATH. Run the following script to go through all the ltp testcases: 

echo $PATH
/opt/uClinux/bfin-elf/bin:/opt/uClinux/bfin-uclinux/bin:/opt/uClinux/bfin-linux-uclibc/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/jvm/jre/bin

cd /home/test/work/cruise/checkouts/uclinux-dist/testsuites/ltp
./ltp_auto_test.exp /dev/ttyS0 2

The log and summary file are produced and given out at the end.

As to the Linux kernel that ltp cases is running on, there are two policies for the board cache configuration,write through(WT) and write back(WB). With the kernel built in each case, ltp cases will all be run through to see if there is some difference and issues involved. For kernel with SMP support, only WT is supported. Except for above WB/WT polices, we also enable another round of LTP test with high resolution timer and preempt support.

Device driver test

  1. Audio driver test over SPORT(AD1836)
    • One script is to test if the sound device can play with different combination of 16, 8 bit rate and 44100,22000,11000,8000 record speeds. It also includes extra cases to test if recording and playing at the same time functions well. It needs listening to the earphone which is connected to the board to decide whether the case goes right. If you can hear the voice periodically, then the case passes, otherwise it fails.
    • Another script is to test the Multichannel Audio player to see if it support two channels to play at the same time and one channel play, the other channel play while doing records at various bit rate and record speeds.
    • AD1836 supports three audio outputs at the same time. We can here from three RCA jacks with priority from high to low: green, black and yellow.
    • Spectrum analysis is applied to sine wave files recorded on PC and target board, which can check the quality of sound process. The frequency of these sine waves are:100/250/440/1K/10K Hz. The tool to transform audio file to power spectrum is snd2dft. Details of this tool is at:snd2fftw. Spectrum analysis is applied to all other audio card drivers we supported.
    • Build the Linux kernel with audio driver support and audio applications.
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select Sound ==
  == Select Sound card support ==
    == Select Advanced Linux Sound Architecture==
      Enable Sequencer support      
      Enable Advanced Linux Sound Architecture  
      Enable OSS Mixer API
      Enable OSS PCM (digital audio) API
      == Select ALSA blackfin devices==
         Enable 1836  Audio support for BF53x        
         == Select 5.1 Channels or 3 seperate Stereos == 
              Enable 3 stereos 
      == System on Chip audio support ==
              Disable ALSA for SoC audio support

under Customize Vendor/User Settings
== Select Miscellaneous Applications == 
      Enable vplay
      Enable vrec
== Select Blackfin build Options == 
      Select FDPIC Binaryformat
  2. Audio driver test over SPORT(AD73311)
    • Build the Linux kernel with AD73311 audio driver support.
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select Sound ==
  == Select Sound card support ==
    == Select Advanced Linux Sound Architecture==
      Enable Sequencer support      
      Enable Advanced Linux Sound Architecture  
      Enable OSS Mixer API
      Enable OSS PCM (digital audio) API
      == Select ALSA blackfin devices==
         Disable 1836  Audio support for BF53x 
         Enable AD73311L Audio support for BF53x
      == System on Chip audio support ==
              Disable ALSA for SoC audio support

      The application selection is the same as that for ad1836 testing above.

  3. Audio driver test(AD73322) (for BF537-STAMP)
    • Build the Linux kernel with AD73322 audio driver support.
      under Customize Kernel Settings
== Select Blackfin processor Options ==
 == Select Enable DMA Support ==
      select Uncached SDRAM region (Enable 2M DMA region) -> Enable 2M DMA region 
== Select Device Drivers ==
 == Select Sound ==
  == Select Sound card support ==
    == Select Advanced Linux Sound Architecture==
      Enable Sequencer support      
      Enable Advanced Linux Sound Architecture  
      Enable OSS Mixer API
      Enable OSS PCM (digital audio) API
      == Select ALSA blackfin devices==
         Disable 1836  Audio support for BF53x 
         Disable AD73311L Audio support for BF53x
         Select Cascaded AD73322 Audio support for BF53x
         (2)Blackfin Audio SPORT port(0 for sport0, 1 for sport1 ,2 for both ports)
      == System on Chip audio support ==
              Disable ALSA for SoC audio support

      The application selection is the same as that for ad1836 testing above.

  4. Audio driver test(AD1980)
    • Test the audio driver on BF548-EZKIT board. Obsolete now.
  5. Audio driver test(AD1981b)
    • Test the audio card AD1981b. Obsolete now.
  6. Audio driver test(ssm2603)
    • Test the audio driver on BF537-STAMP board. For detail please refer to:ssm2602_setup.
  7. Audio driver test(ad1938)
    • Test the audio driver on BF537-STAMP board.
    • AOUT1 and AIN1 are used for audio output and input. Red RCA connector is right channel and white RCA connector is left channel.
  8. Audio driver test(adau1761)
    • Test the audio driver adau1761 on BF609-EZKIT board. Connect Audio EI3 Extender Board to P1A port on BF609-EZKIT.
    • On Audio EI3 Extender Board, J4 is Line-in and J2 is headphone.
  9. Audio multi-channel test
    • This is a 5.1 multi-channel test and bellow audio cards support it.
    • AD1980 on BF548-EZKITz
      J9: Top - Center / LFE; Down - Front Left / Right
J10: Rear Left / Right
    • AD1836
      Green: Front Left / Right
Yellow: Center / LFE
Black: Rear Left / Right
  10. SPORT driver test(AD73311)
    • To test if the AD73311 daughter card can play sound through sport driver.It needs jump on the 1 or 8 pin for bf537 stamp and 1 pin for bf533 stamp board.
    • The sport driver support is enabled by defalt.
    • The test case description is at:sport driver.
  11. Ethernet driver test(Netperf)
    • A benchmark that can be used to measure the performance of TCP/IP network.
    • It is expected to test the connectivity of the Ethernet card and its rate of flow.If the throughput is more than 30 Mb/s, it is passed, otherwise it fails.
    • In the kernel configuration, it needs to select:
      under Customize Vendor/User Settings
== Select Blackfin test programs == 
   Enable  netperf test tool

      Build the kernel,there would be netperf in the romfs/bin folder. Extract the netperf.tgz under testscripts/ethernet. Copy netperf_script to romfs, then rebuild kernel and copy the newly-built image to /tftpboot directory. After that run the netserver_x86 in background on host and run netperf_script on target system. It will generate two log files netperf_tcp_rr and netperf_tcp_stream to tell the result.

  12. Ethernet driver test with 256 DMA buffer size(Netperf)
    • This case is to test the connectivity of the Ethernet card with larger transmit and receive buffer packets.
    • In the kernel configuration, it needs to change the config like following:
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select Network device support ==
    Select  Ethernet (10 or 100 Mbit)                                   
      Disable Use L1 memory for rx/tx packets
      set Number of transmit buffer packets 100
      set Number of receive buffer packets 500
under Customize Vendor/User Settings
== Select Blackfin test programs == 
   Enable  netperf test tool
  13. Video driver test - ADV7393
    • For detailed information of ADV7393 video driver, please refer to the doc:ADV7393.
    • In ADV7393 extender board, pin 2 & 3 of JP1 are connected. For more hardware introduction of ADV7393, please refer to :ADV7393 Video Encoder Card.
    • Test method: connect Composite output to TV Composite input, run video_test, a round bow tie pattern can be seen on TV with white background.
  14. TFT LCD driver(LQ035,LQ043)
    • Please look into the doc:tft-lcd.
    • On BF527-EZKIT board version 2.2 with SHARP LQ035Q1DH02 TFT LCD, set sw26 [off on x x x x].
    • BF526-EZBRD supports to add an adapter board Blackfin Landscape LCD EZ-Extender. Blackfin Landscape LCD EZ-Extender has a Sharp LQ035Q1DH02 3.5 inch LCD with resistive touch and a AD7879 Touch Screen Controller. Connect extender to BF526-EZBRD according to following rule: J1 to P3, J2 to P2. A detailed doc about how to config hardware setting is at Hardware Configuration BF526-EZBRD ( Rev 0.2 )
  15. Serial driver test over UART port0(WT,WB)
    • To see if the serial port can receive the string and command sequencially and exactly, which will be shown on the screen through kermit. If the strings printed and commands executed are as expected, the case passes, otherwise it fails.
    • In order to check if different policies for the board cache configuration would effect its performance, it would run on the two Linux kernel image built either with write through(WT) or write back(WB) policy.
  16. Serial driver test over UART port1
    • For the board that has the second UART port,it is also needed to see if it works right.
    • The test method is pretty much like the way to test the first UART port.
  17. DPMC driver test
    • Dynamic power managent controller test aims to see if this driver can change the VCO frequency, SCLK, CCLK, switch between different Modes, and change the Voltage successfully. Three points are selected: VCO 500M,SCLK 100M,CCLK 500M; VCO 300M,SCLK 100M,CCLK 300M; VCO 200M,SCLK 80M,CCLK 200M. The transition includes from Fullon to Active Mode and back, Fullon to Sleep Mode, back to Fullon, and then to Active Mode.
    • Select the test case for dpmc : 
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select Character devices ==
    Enable  Blackfin Power Management Support                                   

under Customize Vendor/User Settings
== Select Blackfin test programs == 
   Enable  DPMC test program
  18. Frame Capture driver test(Net camera)
    • The PPIFCD Frame Capture Driver test application aims to see if the digital image sensor can take pictures effectively which is connected through the PPI port to the target board. It records the row_time, total_frame_time, total_frame_capture_time, and the taken picture. If the printed data is as expected, the case passes, otherwise it fails.
    • we test one Micron camera based on:ppifcd driver.
  19. Generic gpio test
    • Generic gpio test verifies the registers by writing different values to them to see if they can toggle the BUTTON and LED status on target boards as expected.
    • For board BF537-STAMP,BF548-EZKIT,and BF527-EZKIT, 1 means on, 0 means off. For board BF533-STAMP, on the opposite, 0 means on, 1 means off. If the action goes right, the case passes, otherwise it fails.
    • Make the kernel configuraion like this:
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select GPIO Support ==
    Enable  /sys/class/gpio/...(sysfs interface)
    • For this test to run on bf537 stamp board or bf548 ezkit board, SW5 needs to be [on on on on]. For bf527 ezkit board, SW13 needs to be [on x off off off off].
    • The steps to operate with /sys/class/gpio can be seen at: gpio-sysfs interface
  20. Pfbutton driver test
    • Press SW10,SW11,SW12,SW13 button to see if the input subsystem can receive the status change on buttons correctly. If the test case print on and off info as the buttons are hit one by one, the case passes, otherwise it fails. Make sure sw5 all on.
    • Make the kernel configuraion like this:
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select Input device support  ==
    Enable  Generic input layer (needed for keyboard, mouse, ...)
    Enable  Event interface 
    Enable  Keyboards 
       Disable AT keyboard 
       Enable GPIO Buttons
    ==Select Hardware I/O ports ==
       Disable Serial I/O support  
under Customize Vendor/User Settings
== Select Blackfin test programs == 
   Enable  Input event device test program
  21. RTC test
    • Real time conntroller tests to see if this device can be correctly read time for 6 times, set new RTC time, alarm time, and wait for the alarm ring. Then also a stop watch test and epoch reading. If all the cases run right, this test passes, otherwise it fails.
    • Select the RTC test case when build the kernel:
      under Customize Vendor/User Settings
== Select Blackfin test programs == 
   Enable  RTC test program
  22. Timer tick test
    • To check if the timer interrupt take place as required.
    • There are three timer frequencies:100HZ, 250 HZ and 1000 HZ that can be selected. Selecting 100Hz means the timer would tick about 100 times every second. For 250HZ, 250 timer interrupts would happen. For 1000hz, about 1000 timer interrupts occur in each second.
    • Select the following item when build the kernel:
      under Customize kernel Settings
== Select Blackfin Proccessor Options ==
 == Select Clock Settings == 
   == Select Timer frequency 100 HZ( 250 HZ or 1000 HZ)==
  23. I2C Keypad and LCD driver over TWI port or GPIO
    • Implement Keypad and LCD solution through I2C port on boards:
      BF533-STAMP: JP1 set 15-16
    • Implement Keypad and LCD solution through TWI port on boards:
      BF537-STAMP: JP1 set 15-16
BF609-EZKIT: JP1 set 15-16
BF548-EZKIT: JP1 set 9-10
BF527-EZKIT: JP1 set 9-10

      For BF527 board jumper “STAMP_ENABLE” must be shorted to turn on the TWI signal. It's JP7 on 2.x board and JP3 on 1.x board.

    • Detailed info about keypad is at I2C Keypad doc.
    • Detailed info about LCD is at I2C LCD doc.
  24. I2C TWI driver
    • To test I2C/TWI port through an i2c controller in tftlcd add-on card to see if it can receive the right data at the right address and/or recognize the data from the wrong address without breaking the whole system. If so, the test passes, otherwise fails.
  25. Capacitance Touch
    • There are two capacitance touch sensor boards AD7142/7147 now supported in our kernel. We connected the AD7142 demo board to the TWI/I2C connector and AD7147 demo board to the SPI connector on the BF537 STAMP board. BF537 STAMP board SW5.3 needs to be off, and AD7147 S4.2 on and other positions off.
    • The config options is as follows:
      under Customize kernel Settings
== Select Device Drivers ==
  == Select I2C support ==
    Enable I2C support
    Enable I2C device interface
    == Select I2C Hardware Bus support ==
      Enable Blackfin TWI I2C support
  == Select Input device support ==
    Enable Generic input layer (needed for keyboard,mouse,...)
    Disable Mouse interface
    Enable Joystick interface
    Enable Event interface
    Disable Keyboards
    Disable Mice
    Enable Miscellaneous devices  
    Enable Analog Devices AD714x Capacitance Touch Sensor
       Enable  support I2C bus connection
       Enable  support SPI bus connection

under Customize Vendor/User Settings
== Select Blackfin test programs == 
   Enable input event device test
    • More info can be found at:capacitance_touch_sensors
  26. NOR Flash MTD driver test(JFFS2)
    • To check if the kernel supports the mtd device driver.
    • Firstly erase the /dev/mtdx device which labels for the rootfs on mtd device, copy the jffs2 image made from /rootfs to it, then mount the content of this device to another inode of the ram file system, e.g. /mnt. Finally compare the test file under /rootfs with that under /mnt. If they are the same, the case passes, otherwise it fails.
    • When doing configuration, the kernel setting is the same as the way to enable the jffs2 filesystem. Details are in:enable_jffs2. As to the user settings, need more selection:
      == Flash Tools ==
    Select mtd-utils
       Enable eraseall
       Enable mkfs.jffs2

      These tools will be used in the test case.

  27. Serial NOR Flash MTD driver test(SPI flash,JFFS2)
    • To test if it can boot the kernel uImage with the jffs2.img on SPI flash mounted as the root file system, which is useful when there are no flash chips on the target board.
    • To use micro SPI chip, on BF537 stamp, jump the 2nd pin, on BF533 stamp jump the third pin.
    • Change the boot mode of S1 swith on stamp board to 11, the board will start from the uboot in SPI flash.
    • Have the same setting to kernel configuration except that:
      == Select Device Drivers ==
 == Select Memory Technology Devices (MTD) ==
     Select - Self-contained MTD device drivers
          Enable – Support for M25 SPI Flash
    • More mtd related configs see :jffs.
  28. NAND Flash MTD driver test(UBIFS)
    • Build the uclinux kernel to support ubifs file system on nand flash, see :ubifs
    • For blackfin 527/526, nand is conflicting with on-chip mac support.
      On BF527-EZKIT board, switch SW1: [off off on off], SW11: [x x x on]. On BF526-EZBRD board, SW12: [off off on off], SW13: [x x x on].
  29. IDE device test - CD ROM,harddisk
    • Support ide interfaced CD ROM and harddisk running on STAMP board.
    • Please refer to the page for details the IDE card doc.
  30. Libata ATAPI driver test - CD ROM, DVD, CD-RW, harddisk
  31. CF Memory card test
    • Support CF Memory card in true IDE mode to be read/written by STAMP board.
    • Please refer to the page for details the CF card doc.
  32. 802.11 wireless CF card test
  33. 802.11 wifi card through sdio
    • Support wifi card on BF548-EZKIT and BF518F-EZBRD, which have sdio mmc port.
    • The SDIO WIFI card is not reset properly if you hit the reset button referring to bug 7493. Please re-plug power before test.
    • Please refer to the page for details Wifi over SDIO.
  34. adf7021 - High Performance Narrowband ISM Transceiver
    • The ADF7021 is a low power, highly integrated 2FSK/3FSK/4FSK transceiver. It is designed to operate in the narrow-band, license-free ISM bands and licensed bands in the 80 MHz to 650 MHz and 862 MHz to 940 MHz frequency ranges, which is not wifi.
    • Prepare two ADF7021. Connect ADF7021 to BF537-STAMP using an adaptor card with the STAMP SPORT socket. On BF537-STAMP, it's better to disconnect all SW5 Switch buttons. STAMP SPORT has following hardware settings:
      JP1: open
JP2: set 1-2
JP3: set 1-2, set 3-4
JP4: open
JP5: open
    • Enable SPI driver support and then load the ADF7021 kernel module. Use ifconfig to configure eth0, which is the ethernet interface for ADF7021 device. Then do some simple ping between the two boards.
    • exmple to test ADF7021
  35. USB host devices - memory stick(isp1362+sl811,isp176x)
  36. USB client device (network)
  37. USB host device - usb video camera test
  38. SPI MMC driver
    • Test the MMC/SD SPI addon card driver.
    • Pay attention to Switch setting in spi mmc add-on card. Default CS is 4 so switch 5 is on. In current regression CS is changed from 4 to 1, so switch 2 is on. Details at: Blackfin MMC Driver.
  39. Bluetooth (usb)
    • To use bluetooth protocal on stamp board via usb port. Details at: Bluetooth on USB.
    • Make sure bluetooth signal is strong enough during test, otherwise l2ping may fail.
    • Make sure bluetooth service is OK after long time running on host machine and better not to use use usb hub. Please refer to buildroot bug [#7061].
  40. Bluetooth ALSA
  41. Bluetooth UART
  42. IRDA driver
    • Communicate through IRDA to IRDA devices.
    • Driver modules of bfin_sir and irtty-sir need to be tested.
    • Driver bfin_sir is tested between two blackfin boards. We don't test it at present as we don't have enough good irda boards to test.
    • Driver irtty-sir is tested between blackfin board and a linux PC with irda device. To test irtty-sir, we should use bellow serial port: 
      Board Type     Serial Port    irtty-sir
BF537-STAMP       UART0         UART1    
BF533-STAMP       UART0*        UART0    
BF548-EZKIT       UART1         UART3    
BF527-EZKIT       UART1         UART0
* only a UART0. Serial Port needs to be disabled before using irtty-sir on UART0.
    • Test methods: Use irdaping to ping IRDA device; Use ircp to send/receive files.
    • Details at: irda_framework.
  43. hardware flow controll RTS/CTS test
    • On bf537 stamp, test with UART0. Should configure SW4 to be [on on on off].
    • On bf548 ezkit, test with UART1. The default connection between CTS/RTS PINs of UART1 and T2/R2 PINs of ADM3202ARNZ on bf548 ezkit board are incorrect. CTS is input signal and should be connected to R2, while RTS as an output signal should be routed to T2. Please configure SW7 to be [off on off off] and jump 2 cables to cross PIN SW7.1 and SW7.3.
    • Enable in the Linux kernel like following:
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select Character devices ==
   == Select Serial drivers ==
    Enable  UART0             // For bf537
    Enable  UART0 hareware flow control 
    Enable  UART1             // For bf548
    Enable  UART1 hareware flow control 
 
under Customize Vendor/User Settings
== Select Blackfin test programs== 
   Enable  RTS/CTS test program
    • Before testing, the serial port setup parameter need to be reset: 
      minicom -s
Serial port setup
F - Hardware Flow Control: Yes
    • Power off and restarting the board, you would find the uboot doesn't accept the activities from keyboard. Instead it automatically boot up kernel by predefined uboot parameter. After entering kernel, it receive keyboard hitting at this moment.
      • Case 1: run rts-cts test case
        rtscts_test ttyBF0 -t

        it would prevent any input from outside to be output at shell prompt for 5 seconds. Then print all at once at the end of the test programe.

      • Case 2 is to cat /proc/kallsyms.
        On bf537-stamp, in the middle of the printing, switch the SW4.3 to off, it would withhold the message from outputing. Switch back to on, printing resumes.
        On bf548-ezkit, after kernel boots up, start a telnet connection to the target board(ie, telnet 10.100.4.50), and run the following in it:
        rtscts_test ttyBF0 -d   // disable RTS on /dev/ttyBF0 
cat /proc/kallsyms > /dev/ttyBF0

        Connect the CTS pin to 3V, it can withhold the output message from being print on serial console(don't look at the telnet console, it is through ethernet); disconnect CTS from 3V , it continues to output.
        If the two cases go like this, it counts as passed, otherwise fails.

  44. watch dog test
    • To implement software restart if the boards have system error and can't recover.
    • The kernel configuration is: 
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select Character devices ==
    == Select Watchdog Cards ==                                  
      Enable Watchdog Timer Support
      Enable Blackfin Watchdog Timer 
under Customize Vendor/User Settings
== Select Blackfin test programs== 
   Enable  Kernel Panic (test Watchdog)
== Select Blackfin app programs== 
   Enable  watchdog simple deamon
  45. CAN bus test
    • To transmit the data between two target boards through can bus. On bf537 board SW2 should all on. On bf548 ezkit board can0 works with sw6 [off off on on].
    • After starting the kernel, do “modprobe bfin_can”, it would say bain_can.ko is used and inserted. Receive data on one machine and send on the other one.
    • For detail doc, it locates at: bfin_can.
  46. early printk
    • Add a panic before initiallize console in linux-2.6.x/init/main.c. When kernel boot up, the panic message should be seen.
    • For detailed information about early printk, please refer to:Linux Kernel Early Printk Debugging.
  47. Keypad
    • For BF54x-EZKIT boards, there is an attached keypad which accept key input. The document that decribe the feature and testing is at: keypad.
  48. Touchscreen
    • There are two kinds of ports for touchscreen connection: SPI port for BF537-STAMP/BF527-EZKIT/BF609-EZKIT; PPI port for BF548-EZKIT.
    • On BF537-STAMP/BF527-EZKIT/BF609-EZKIT, touchscreen daughter board is AD7877.
    • Chip select for BF537-STAMP and BF527-EZKIT is CS1, interrupt is 4. There are some hardware settings required for BF527-EZKIT board(1.4): populate JP3 and disable SW11.2, SW18.1. Settings for BF527-EZKIT board(2.2): populate JP7 and disable SW11.2, enable SW28 to both on.
    • For BF609-EZKIT, CS7 and interrupt 6 on AD7877 board should be set. AD7877 board has poor connection between touchscreen and AD7877 board. PENIRQ will light when touch event has been received. The touchscreen extension is not directly connected to BF609-EZKIT, and a BF609 expansion adaptor board is needed. Detailed info is at BF609 adaptor.
    • BF526-EZBRD also supports touchscreen function with adapter board Blackfin Landscape LCD EZ-Extender. Blackfin Landscape LCD EZ-Extender has a Sharp LQ035Q1DH02 3.5 inch LCD with resistive touch and a AD7879 Touch Screen Controller. Connect extender to BF526-EZBRD according to following rule: J1 to P3, J2 to P2. A detailed doc about how to config hardware setting is at Hardware Configuration BF526-EZBRD ( Rev 0.2 )
    • A detailed doc that can be referred to touch_screen
  49. Power
    • Test power management. Make sure kernel can enter “Standby” or “Suspend-to-RAM” states, then it is waken up by rtc interrupt in bf5xx board. In BF609-EZKIT, it is waken up by pushing button SW10.
    • This test should be done in several drivers: ethernet, ad1836, ssm2603, adv7393 and tftlcd.
    • According to bug 5370, a pull down resistor is needed when Suspend-to-RAM. For 537-stamp/533-stamp/533-ezkit/527-ezkit/538-ezkit, add a 6.8k Ohm resistor between SCKE (J2-81) and GND (J2-87); and for 518f-ezbrd/526-ezbrd, add resistor between P5-B12 and P5-B13. 548-ezkit uses DDR SDRAM, and it's not affected by this bug. BF609-EZKIT is also not affected by this bug.
    • Detail of power management is at :Power Management Support
  50. Power test with usb gadget driver
    • After kernel wake up from “Standby” states, usb gadget driver should work. Test method is similar to above test “Power”.
    • Test case is in folder power_usbdev. For detail of power management test, please refer to Power Management Support.
  51. Power management test over uart(uart_wakeup)
    • Test power management with power saving mode of sleep. Make sure kernel can enter “Standby” states, then wake up by uart interrupt. “mem” is not supported.
    • For detail of power management test, please refer to Power Management Support.
  52. Power management test over ethernet(ethernet_wakeup)
    • Test power management with power saving mode of sleep. Make sure kernel can enter “Standby” states, then wake up by ethernet interrupt. “mem” is not supported.
    • For detail of power management test, please refer to Power Management Support.
  53. Power management test over usb(usb_wakeup)
    • Test power management with power saving mode of sleep. Make sure kernel can enter “mem” states, then wake up by usb interrupt. “Standby” is not supported.
    • For detail of power management test, please refer to Power Management Support.
  54. V4L2 Video Capture Driver - Camera
    • VS6624: connect STAMP_PPI port in the CMOS Camera card(VS6624) to PPI port in BF537-STAMP. For BF609-EZKIT, it needs an adapter board from P1A slot to PPI port. Hardware of CMOS Camera card is at CMOS Camera Add-On-Card
    • ADV7842: connect ADV7842 adapter board directly to BF609-EZKIT P1A connector. Bellow formats need to be tested: 720p60(HD), NTSC and PAL. When test 720p60, connect HDMI wire from source to HDMIA port. When test NTSC and PAL, connect source to composite port. For details please refer to ADV7842 Example
    • Aptina MT9M114: connect Aptina MT9M114 board(P9 connector) to BF609-EZKIT P1A connector via Aptina camera adapter board(J2 connector).
    • For details please refer to Blackfin v4l Video Capture Driver
  55. ADV7183 video decoder
    • The ADV7183 is an integrated video decoder that automatically recognizes and converts a standard analog baseband television signal into 4:2:2 component video data.
    • According to task 2808, both BF561-EZKIT and BF533-EZKIT should support this driver.
    • Test method: send video signal(eg: video output from digital camera) to BF561-EZKIT AVIN5 port and video signal will be decoded by BF561-EZKIT; use ffmpeg to encode and send encoded stream via UDP; play video stream on a host PC, using tools such as VLC.
    • For details please refer to adv7183 example
  56. V4L2 Video Display Driver
    • ADV7511: connect ADV7511 adapter board to BF609-EZKIT P3A connector. Only HD format is support for ADV7511, so connect HDMI wire card to TV to display captured HD yuv file (720p).
    • For details please refer to Blackfin v4l2 Video Display Driver
  57. MPU
  58. ADP5588 QWERTY I2C KEYBOARD
    • To test the ADP5588 which is an I/O port expander and keypad matrix designed for QWERTY type devices that require a large keypad matrix and expanded I/O lines. Details are at:adp5588.
  59. ADP5520
    • The ADP5520 is a versatile single-chip, white LED backlight driver with a user configurable keypad and I/O expander. adp5520.
  60. ADP8860
    • The ADP8860 combines a programmable backlight LED charge pump driver with automatic phototransistor control. It changes the current intensity in office and dark ambient light conditions. By performing this function automatically, it eliminates the need for a processor to monitor the phototransistor.
    • Connect J30 to TWI interface on BF537-STAMP: VBAT → P10.2, SDA → P10.6, SCL → P10.5, GND → P10.20
    • Three major tests need to be done: cover the photosensor D2 in ADP8860 daughter card, LED D6-D14 will dim; change brightness of D6-D14 through /sys/class/backlight/adp8860_bl/brightness; other LEDs will blink when /sys/class/leds/adp8860-led7/brightness is nonzero.
    • Detailed info is at adp8860.
  61. SPI net enc28j60
    • Enc28j60 demo board is an extended ethernet card through STAMP SPI port. Now it is only test on BF537-STAMP board.
    • Configure the kernel as following:
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select Network device support ==
    Select  Ethernet (10 or 100 Mbit)                                   
      Enable ENC28J60 support
under Customize Vendor/User Settings
== Select Blackfin test programs == 
   Enable  netperf test tool

      The device is registered as eth1 and we test it with netperf. Once the connection through eth1 is ok and produce the data, the case is passed, otherwise fails.

  62. Rotary input device
  63. SPORT emulated UART port
    • This demo board expands an serial UART port through SPORT0 for STAMP boards.
    • The test way is the same as normal serial uart port. Detailed information is at SPORT UART
    • Configure the kernel as following:
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select character devices ==
    Select  Serial drivers                                   
      Enable Blackfin SPORT emulate UART
      Enable Console on Blackfin sport emulated uart
  64. SPORT emulated SPI bus
    • This add-on board expands a 8/16 bit SPI bus through SPORT0.
    • To test 8bit bus performance, we use SPI NOR flash read and write functions.
    • In order to test spi flash, file stamp.c must be changed to:
      Index: /home/bob/uclinux-dist2/linux-2.6.x/arch/blackfin/mach-bf537/boards/stamp.c
===================================================================
--- /home/bob/uclinux-dist2/linux-2.6.x/arch/blackfin/mach-bf537/boards/stamp.c	(revision 9424)
+++ /home/bob/uclinux-dist2/linux-2.6.x/arch/blackfin/mach-bf537/boards/stamp.c	(working copy)
@@ -1037,8 +1037,8 @@
 		/* the modalias must be the same as spi device driver name */
 		.modalias = "m25p80", /* Name of spi_driver for this device */
 		.max_speed_hz = 25000000,     /* max spi clock (SCK) speed in HZ */
-		.bus_num = 0, /* Framework bus number */
-		.chip_select = 1, /* Framework chip select. On STAMP537 it is SPISSEL1*/
+		.bus_num = 1, /* Framework bus number */
+		.chip_select = GPIO_PF14, /* Framework chip select. On STAMP537 it is SPISSEL1*/
 		.platform_data = &bfin_spi_flash_data,
 		.controller_data = &spi_flash_chip_info,
 		.mode = SPI_MODE_3,
@@ -1579,7 +1579,7 @@
 
 /* SPORT SPI controller data */
 static struct bfin5xx_spi_master bfin_sport_spi0_info = {
-	.num_chipselect = 1, /* master only supports one device */
+	.num_chipselect = MAX_CTRL_CS + MAX_BLACKFIN_GPIOS, /* master only supports one device */
 	.enable_dma = 0,  /* master don't support DMA */
 	.pin_req = {P_SPORT0_DTPRI, P_SPORT0_TSCLK, P_SPORT0_DRPRI,
 		P_SPORT0_RSCLK, P_SPORT0_TFS, P_SPORT0_RFS, 0},
    • NOTE:These changes only apply to sport0, similar changes must be made in order to support sport1.
    • Configure the kernel as following:
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select SPI support ==
      Enable emulate SPI bus with Blackfin SPORT

      After that, proceed with specific spi flash test steps.

  65. AD SPORT test(Net Scope,Net Awg)
    • NDSO is a manual test to see if the ADC SPI card(ad7476) can acquire anolog signal from the environment and convert it to digital signal correctly through netscope. The sampled data then is formed into a picture and sent to the web browser through TCP/IP network. From the output of the web browser, we can tell if the ADC works right.
    • NDSO card has a spi interface but this test now only works with sport interface, so attach NDSO card to BF537-STAMP through SPI-to-SPORT convertor. STAMP SPI socket pin 19 in NDSO card must be connected to the standard SPI pin 19(V_UNREG) on BF537-STAMP.
    • AWG is a manual test to see if the DAC SPI card(ad5443) can generate waveform and convert it to analog signal correctly. Check DAC card output with oscilloscope. SPORT PIN1 should connect to SPI PIN1 on the SPORT-SPI conversion board for AWG test and NDSO test won't be effected by this hardware change.
    • Build the Linux kernel with BFIN SPORT driver support and ndso/awg applications.
      under Customize Kernel Settings
== Select Device Drivers ==
 == Select Character devices ==
    Blackfin SPORT driver for direct raw access
 
under Customize Vendor/User Settings
== Select Library Configuration  == 
   Enable  Build libZ
   Enable  Build libpng
== Select Miscellaneous Applications ==
   Enable  gnuplot
== Select Blackfin canned demos==
   Networked Software Defined Storage Oscilloscope /dev/sport
or Enable  Networked Arbitrary Waveform Genertor
(Don't use NDSO_IIO. Please select AWG or NDSO and disable the other, as kernel image may be too big.)

      Build this kernel and use it to boot the target board, configure the Ethernet card at kernel prompt: 

      #ifconfig eth0 10.100.4.50

      Then start test application: 

       #ndso &     (for ndso test)
 #awg &     (for awg test)

      Open the web browser on host system, such as Mozilla, Firefox, IE. Enter in the URL target ip address: 

       http://10.100.4.50

      For ndso test, hit Acquire button on the left, the picture sampled by the ADC converter can now be seen on website. For awg test, choose any waveform on website and it should be seen on oscilloscope.

  66. Generic PPI Driver (BFIN_PPI)
    • It's a manual case in bfinppi folder and only test it with bf537. We don't test it on bf527 and bf548 platform as the following reasons:
      • Testing the PPI Driver on the BF527-EZKIT is very complicated, since the LCD is hard wired to PPI0..7 and the upper PPI strobes PPI8..15 are used for various other things such as UART etc. So there is no need to test it on the BF527, since the PPI is 100% identical to the one on BF537.
      • For the BF548, there needs to be a special test application, since ppi_test isn’t prepared for EPPI specific IOCTLS.
    • As an external clk is needed to PPI CLK and we don't have it on bf537-stamp, so place a wire on BF537-EZKIT from U4 (output of the 12MHz oscillator) to PPI CLK. And this test should be done between bf537-ezkit and bf537-stamp. Set SW4.3 OFF, so PG7 can work. Also you can refer to bug [#4997] for some information.
    • Run application ppitest to test it.
  67. BFIN DMA
    • Configure the kernel as following:
      Character devices --->
        <*> Blackfin Userspace DMA Interface
Blackfin test programs  --->
        [*] bfin-dma test
    • Then run application bfin-dma in kernel. All platforms support this test.
  68. BFIN CRC
    • Only BF609-EZKIT support this test.
    • Configure the kernel and user app as following:
      Character devices --->
        <*> Blackfin hardware CRC driver
Miscellaneous  --->
        [*] bfin CRC test
    • Detailed information is at: bfin_crc.
  69. PTP
    • The Precision Time Protocol (PTP) is a high precision time synchronization protocol for networked measurement and control systems. ADSP-BF518 processors include the module that supports hardware assistance for the implementation of PTP in the IEEE 1588 standard.
    • In testing, it needs at least two BF518F-EZBRD boards connected in the same network. Here we wire the boards to the company router with ip address 10.99.29.xxx which is got by dhcpcd in kernel (or dhcp at u-boot prompt).
    • For more details, please refer to PTP
  70. ADXL34x
    • The ADXL34x is a small, thin, ultra low power, 3-axis accelerometer with high resolution measurement, which measures the static acceleration of gravity in tilt-sensing applications, as well as dynamic acceleration resulting from motion or shock.
    • There are two tyes of demo-boards, one is connected to TWI/I2C port, the other is connected to SPI. We move either of the add-on boards after kernel boots up and detects it on the target to see if the event_test can notice the position and speed changes that happens.
    • For detail doc, it locates at: adxl34x.
  71. DSA
    • DSA is “Distributed Switch Architecture”. It can be test on BF518-EZBRD board with two Ethernet ports and a switch chip Micrel Ksz8893m.
    • Detailed information is at: dsa_for_ksz8893m.
  72. GPtimer
    • Caculate the timer interrupts generated on timer_in and re-direct its to timer_out to see if the out interrupts number is slightly less or equal to the in number. There should be a jumper to connect the in and out pin of gptimer.
      simple_timer_test -m 5 -b 537(or -b 609)
cat /proc/bfin_simple_timer
  73. Linkport
    • To see if it can transit data through linkport device of BF609 EZKIT board.
    • It needs to use uboot with macro : #define CONFIG_BFIN_LINKPORT enabled.
    • There is a connecting blue linking line to join the two LINKPORTs.
    • For detail doc, it locates at: bfin_linkport.

Kernel Function test

  1. Kgdb test
    • To test if the kgdb commands can work ok in SRAM, L1 and L2 when using them to debug the kernel under single CPU or SMP condition through serial cable or ethernet port. The tested commands are list, c, break, bt, d, info break, step, print len, detach, and quit.
    • kgdb
  2. Loadable module test
    • To see if kernel supports module operation well, which includes insmod,lsmod,rmmod commands.Here we use the ethernet module to validate this feature. If all operation works ok,the case passes, otherwise fails.
    • Build the Linux kernel with module support:
      under Customize Kernel Settings
== Select Loadable module support ==
    Enable  Enable loadable module support
    Enable  Module unloading
    Enable  Automatic kernel module loading  

== Select Device Drivers ==
 == Select Network device support ==
   == Select Ethernet (10 or 100Mbit) ==
      Select M SMC 91C9x/91C1xxx support (BF533-STAMP,BF533-EZKIT,BF561-EZKIT)          
      Select M Blackfin 527/536/537 on-chip mac support (BF537-STAMP,BF527-EZKIT)       
      Select M SMSC LAN911x/LAN921x families embedded ethernet support (BF548-EZKIT)
    • test the ethernet module as followed on the target:
      insmod /lib/modules/2.6.12.1/kernel/drivers/net/smc91x.ko
lsmod
ifconfig eth0 10.100.4.50
ping 10.100.4.174
rmmod
  3. Kernel module in L1
  4. Application in L1
  5. L1 scrachpad with user app stack
  6. L1 memory alloc/free system call
  7. malloc performance
    • To test the malloc operation performance by recording the time before and after the malloc function to see if the cost time would increase twice as much as the first time after repeating 38 times. If so, fail, otherwise pass.
    • Test case is under source tree: user/blkfin-test/malloc-perf
  8. Memory issues to allocate continuous memory region
    • Test method: allocate continuous memory region.
    • Case is in folder mem_fragment.
  9. Memory protection test with invalid memory access
    • Test method: call a system call with an invalid pointer in one process and check if it is killed correctly. Refer to track 5251 for more information.
    • This case only test on MPU kernel and case is in folder mem_access.
  10. mmap
    • Test memory mapping in kernel. For details please refer to: mmap
  11. Pthread test
    • To test the pthread function of the kernel. There are 8 cases about mutexes and conditions,semaphones usage,multi-thread searching,static variables thread-safe,etc.
    • Select pthread test:
      under Customize Vendor/User Settings
== Select Blackfin test programs== 
   Enable  Pthread lib test
  12. Strace
    • To trace the system calls that are used when execute a command which helps to illustrate how the command actually works.
    • It is recorded the output of executing three commands, pwd, date and dmesg.
    • Select strace test:
      under Customize Vendor/User Settings
== Select Blackfin app programs== 
   Enable  strace
  13. Oprofile test
    • Oprofile is capable of profiling all running code at low overhead on hardware and software interrupt handlers, kernel modules, the kernel, shared libraries, and applications.
    • To add oprofile function, make the following selection:
      under Customize Kernel Settings
== Select Profiling support ==
    Enable  Profiling support 
    Enable  OProfile system Profiling      

under Customize Vendor/User Settings
== Select Blackfin app programs ==
   == Select oprofile ==
    • The oprofile kernel image is quite big, so it is needed to enlarge the default image size EXT2_BLOCKS in vender/Analogdevices/BF533-STAMP/Makefile:
      EXT2_BLOCKS = 18432
  14. Java Virtual Machine
  15. XIP
    • Load a romfs root filesystem in system ram, by using the prebuilt linux.romfs image.
    • Normal flat binaries do not support XIP; test with both FD-PIC and shared flat.
    • For details, please refer to the doc xip
  16. Load elf binary and dynamic object
    • To test if the kernel built with flat toolchain could load elf binary and dynamic object.
    • The test commands are: 
      bfin-uclinux-gcc -o libhelloworld.so helloworld.c -shared -mfdpic
bfin-uclinux-gcc -o test_dll test_dll.c -mfdpic -ldl
rcp libhelloworld.so root@10.100.4.50:/lib
rcp test_dll root@10.100.4.50:/

      The test_dll.c is as following: 

      #include <dlfcn.h>

int main(int argc, char* argv[])
{
	void *handle;
	char *error;

	int (*helloworld)(char *str);
	int r;
	
	handle = dlopen("libhelloworld.so", RTLD_NOW);
	if (!handle) {
		fprintf (stderr, "%s\n", dlerror());
		exit(1);
	}
	

	dlerror();    /* Clear any existing error */
	helloworld = dlsym(handle, "helloworld");
	if ((error = dlerror()) != NULL)  {
		fprintf (stderr, "%s\n", error);
		exit(1);
	}

	r = helloworld("hello\n");
	printf("get %d\n", r);
	dlclose(handle);
	
	return 0;
}
  17. Core B code loader
  18. Intercore communication protocol on bf561 test
    • Use the utility icc_loader to load the binary to core B, and run app on coreA to communication with coreB via ICC
    • For details, please refer to the doc:test_icc_on_bf561
  19. MCAPI on bf561 test
  20. Configurable kernel boot address
    • Give an option to set the user defined boot address in case there is different sram settings.
      under Customize Kernel Settings
== Select Board customizations ==
     Kernel load address for booting 
       --> Change from 0x1000 to user-defined address(for example 0x2000)
  21. dma copy system call
    • Test the system call of dma copy, including: dma_memcpy from SDRAM to SRAM and SRAM to SDRAM; dma_memcpy from SDRAM to SDRAM.
    • Bellow is the test program:

      file: trunk/testsuites/dmacopy/src/dmacopy.c

      #include <bfin_sram.h>
#include <signal.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
 
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof(*arr))
 
static inline void show_diff(int first, int last)
{
	printf(" %i", first);
	if (first != last)
		printf("...%i", last);
}
static void dump_diff(char *ptr_a, char *ptr_b, int len)
{
	int i, first = -1, last;
	printf("\toffsets differ:");
	for (i = 0; i < len; ++i) {
		if (ptr_a[i] != ptr_b[i]) {
			if (first == -1)
				first = i;
			last = i;
		} else if (first != -1) {
			show_diff(first, last);
			first = last = -1;
		}
	}
	if (first != -1)
		show_diff(first, last);
	printf("\n");
}
 
/* Make sure dma_memcpy() does not over/under flow the buffers given to it.
 * We do this by padding each buffer with a canary at the start and end.  So
 * the actual allocation looks like:
 * [size][canary][ ... buffer ... ][canary]
 * The canary used is the pointer returned by malloc so we know we have a
 * unique value at all times.  If dma_memcpy() does anything bad, the canaries
 * will get killed in the process.
 */
#define canary_size sizeof(char *)
static void *xmalloc(size_t size)
{
	char *ret = malloc(size + (canary_size * 2) + sizeof(size));
	char *canary, *canary1, *canary2;
	if (!ret) {
		printf("FAIL: malloc(%zu) failed\n", size);
		exit(10);
	}
	canary = (void *)&ret;
	canary1 = ret + canary_size;
	canary2 = canary1 + canary_size + size;
	memcpy(ret, &size, sizeof(size));
	memcpy(canary1, canary, canary_size);
	memcpy(canary2, canary, canary_size);
	return ret + sizeof(size) + canary_size;
}
static void xfree(void *ptr)
{
	char *ret;
	char *canary, *canary1, *canary2;
	size_t size;
	ret = (char *)ptr - sizeof(size) - canary_size;
	canary = (void *)&ret;
	memcpy(&size, ret, sizeof(size));
	canary1 = ret + canary_size;
	canary2 = canary1 + canary_size + size;
	if (memcmp(canary, canary1, canary_size))
		printf("FAIL: leading canary was killed {%i,%i,%i,%i} vs {%i,%i,%i,%i}!\n",
			canary1[0], canary1[1], canary1[2], canary1[3], canary[0], canary[1], canary[2], canary[3]);
	if (memcmp(canary, canary2, canary_size))
		printf("FAIL: trailing canary was killed {%i,%i,%i,%i} vs {%i,%i,%i,%i}!\n",
			canary2[0], canary2[1], canary2[2], canary2[3], canary[0], canary[1], canary[2], canary[3]);
	free(ret);
}
 
int is_l1_inst(void *paddr)
{
	unsigned long addr = (unsigned long)paddr & 0xfff00000;
	if (addr == 0xffa00000 || addr == 0xff600000)
		return 1;
	else
		return 0;
}
 
/* Do the actual test:
 *  - set buffers to values known to be different
 *  - copy src to chk
 *  - copy chk to dst
 *  - compare src and dst
 */
int _do_test(char *src_desc, char *dst_desc, char *src, char *dst, char *chk, int size)
{
	static int test_num = 1;
	int ret = 0, i;
	void *ptr;
 
	memset(src, 's', size);
	memset(dst, 'd', size);
	__builtin_bfin_ssync();
	if (!is_l1_inst(chk))
		memset(chk, 'c', size);
 
	ptr = dma_memcpy(chk, src, size);
	if (ptr)
		printf("PASS: dma_memcpy %s[s] to %s[c]\n", src_desc, dst_desc);
	else
		printf("FAIL: dma_memcpy %s[s] to %s[c]\n", src_desc, dst_desc), ++ret;
 
	if (!is_l1_inst(chk)) {
		i = memcmp(chk, src, size);
		if (!i)
			printf("PASS: dma_memcpy(chk, src) test case %i, memcmp result is %d\n", test_num, i);
		else {
			printf("FAIL: dma_memcpy(chk, src) test case %i, memcmp result is %d\n", test_num, i), ++ret;
			dump_diff(chk, src, size);
		}
	}
 
	ptr = dma_memcpy(dst, chk, size);
	if (ptr)
		printf("PASS: dma_memcpy %s[c] to %s[d]\n", dst_desc, src_desc);
	else
		printf("FAIL: dma_memcpy %s[c] to %s[d]\n", dst_desc, src_desc), ++ret;
 
	if (!is_l1_inst(chk)) {
		i = memcmp(dst, chk, size);
		if (!i)
			printf("PASS: dma_memcpy(dst, chk) test case %i, memcmp result is %d\n", test_num, i);
		else {
			printf("FAIL: dma_memcpy(dst, chk) test case %i, memcmp result is %d\n", test_num, i), ++ret;
			dump_diff(dst, chk, size);
		}
	}
 
	i = memcmp(dst, src, size);
	if (!i)
		printf("PASS: dma_memcpy(dst, src) test case %i, memcmp result is %d\n", test_num, i);
	else {
		printf("FAIL: dma_memcpy(dst, src) test case %i, memcmp result is %d\n", test_num, i), ++ret;
		dump_diff(dst, src, size);
	}
 
	++test_num;
 
	return ret;
}
 
/*
 * test case 1 - dma_memcpy from src(SDRAM) to sram(SRAM) and sram(SRAM) to dst(SDRAM), then compare
 *               src(SDRAM) and dst(SDRAM) to make sure that copy into or from SRAM is ok.
 *               also check that 8/16/32 bit transfers work by mucking with alignment.
 */
int sram_test(int size, char *sram_desc, int flags)
{
	int ret = 0;
	char *src = xmalloc(size);
	char *dst = xmalloc(size);
	char *sram = sram_alloc(size, flags);
 
	printf("TEST:  --- SRAM (%s) <-> SDRAM w/%i bytes ---\n", sram_desc, size);
 
	if (!sram) {
		printf("FAIL: sram_alloc(%i) failed\n", size);
		return 1;
	}
 
	if ((ulong)src % 4 != 0 || (ulong)dst % 4 != 0 ||
	    (ulong)sram % 4 != 0 || size % 4 != 0)
	{
		printf("FAIL: SRAM src/dst/size are not 32bit aligned to start:\n"
			"\t%p / %p / %p / %i\n",
			src, dst, sram, size);
		return 1;
	}
 
	ret += _do_test("SDRAMx32", "SRAMx32", src, dst, sram, size);
	ret += _do_test("SDRAMx16", "SRAMx16", src+2, dst+2, sram+2, size-2);
	ret += _do_test("SDRAMx8", "SRAMx8", src+1, dst+1, sram+1, size-1);
 
	xfree(src);
	xfree(dst);
	sram_free(sram);
 
	return ret;
}
 
/*
 * test case 2 - dma_memcpy from src(SDRAM) to dst(SDRAM), memcmp of src and dst,
 *               make sure that dma_memcpy in SDRAM is ok
 *               also check that 8/16/32 bit transfers work by mucking with alignment.
 */
int sdram_test(int size)
{
	int ret = 0;
	char *src = xmalloc(size);
	char *dst = xmalloc(size);
	char *chk = xmalloc(size);
 
	printf("TEST:  --- SDRAM <-> SDRAM w/%i bytes ---\n", size);
 
	if ((ulong)src % 4 != 0 || (ulong)dst % 4 != 0 ||
	    (ulong)chk % 4 != 0 || size % 4 != 0)
	{
		printf("FAIL: SDRAM src/dst/size are not 32bit aligned to start\n"
			"\t%p / %p / %p / %i\n",
			src, dst, chk, size);
		return 1;
	}
 
	ret += _do_test("SDRAMx32", "SDRAMx32", src, dst, chk, size);
	ret += _do_test("SDRAMx16", "SDRAMx16", src+2, dst+2, chk+2, size-2);
	ret += _do_test("SDRAMx8", "SDRAMx8", src+1, dst+1, chk+1, size-1);
 
	xfree(src);
	xfree(dst);
	xfree(chk);
 
	return ret;
}
 
int has_l2(void)
{
	/* if the part does not have L2, then don't try to use it */
	return WEXITSTATUS(system("grep -qs '^L2 SRAM[[:space:]]*:[[:space:]]*[1-9]' /proc/cpuinfo")) == 0;
}
 
/*
 * Setup some "background noise" and really stress the hell out of the DMA
 * memcpy code.  We do this by forking off a bunch of children and each child
 * continuously does small random memcpy's over and over.  If the kernel
 * locking is safe, then there should be no problem processing all these
 * small children as well as the large buffers the main test does.
 */
pid_t children[20];
void maybe_run_child(int argc, char *argv[])
{
	if (argc != 2 || strcmp(argv[1], "child"))
		return;
 
	srandom(time(0));
	while (1) {
		char src[256], dst[256];
		dma_memcpy(src, dst, random() % 256);
	}
}
bool spawn_children(int argc, char *argv[])
{
	size_t i;
 
	maybe_run_child(argc, argv);
 
	for (i = 0; i < ARRAY_SIZE(children); ++i) {
		children[i] = vfork();
		if (children[i] < 0) {
			perror("vfork() failed");
			return false;
		} else if (!children[i]) {
			execlp(argv[0], argv[0], "child", NULL);
			perror("execlp() failed");
			return false;
		}
	}
	return true;
}
void kill_children(void)
{
	size_t i;
	for (i = 0; i < ARRAY_SIZE(children); ++i)
		kill(children[i], SIGKILL);
}
 
#define TEST_RANGE(range, func, args...) \
	for (i = 0; i < ARRAY_SIZE(range##_range); ++i) \
		ret += func(range##_range[i], ## args)
 
int main(int argc, char *argv[])
{
	int ret = 0, i;
	int sml_range[] = { 4, 0x10, 0x1000 };
	int mid_range[] = { 4, 0x10, 0x1000, 0x10000, 0x12340 };
	int lrg_range[] = { 4, 0x10, 0x1000, 0x10000, 0x12340, 0x22340, 0x32340, 0x42340, 0x54320, 0x323450 };
 
	if (!spawn_children(argc, argv))
		return -1;
 
	TEST_RANGE(sml, sram_test, "L1 INST", L1_INST_SRAM);
	TEST_RANGE(sml, sram_test, "L1 DATA", L1_DATA_SRAM);
	if (has_l2())
		TEST_RANGE(mid, sram_test, "L2", L2_SRAM);
	TEST_RANGE(lrg, sdram_test);
 
	if (ret)
		printf("SUMMARY: %i tests failed\n", ret);
	else
		printf("SUMMARY: all tests passed\n");
 
	kill_children();
 
	return ret;
}
  22. erestart
    • Test case is under: user/blkfin-test/erestart_test.
  23. null point check
    • Test the NULL pointer reads/writes can be caught.
    • Make sure the following config is set in kernel.
      Kernel hacking  --->
       [*] Catch NULL pointer reads/writes
    • Run a program that will read the NULL point.
      #include <stdio.h>
int main ()
{
        int * p = NULL; 
        printf("No null point check: *p is %d\n", *p);
        return 0;
}
  24. reserve memory for customer app by boot command
    • Provide a way to reserve memory space for exclusively customer use when kernel boots up, which is set in u-boot bootargs so that it take effect at the start of kernel beginnning. Set like: 
      set bootargs root=/dev/mtdblock0 rw mem=32M max_mem=64M

      It would reserve 32M memory from the whole 64M memory space for user applications.

  25. string opertations in kernel space
    • To test the string related functions in kernel, like strcmp,strncmp,strcpy,strncpy,memcpy,memchr,memcmp,memset,memmove. They are run as a module to be inserted into the kernel.
    • The test case is under: user/blkfin-test/string_test.
  26. Change CPU frequency and voltage scaling
    • This feature enables to change CPU frequency dynamically and thus save the voltage usage:cpufreq .
  27. Reprogram Clock
    • In this testing,we change the kernel clocks while kernel boots.
      under Customize Kernel Settings
== Select Blackfin Processor Options ==
  ==Select Board customization==
    Enable  Re-program Clocks while kernel boots 
    Set VCO Multiplier 16
    Set Core Clock Divider 1
    Set System Clock Divider 5

System test

  1. Reboot test on RAMDISK
    • Reboot the system continuously for 30 times both to see if the linux kernel as an elf file can reboot successfully everytime.
  2. Reboot on JFFS2 file system
    • Programme the uboot, kernel uImage and file system all on flash, each in one MTD patition. per the instructions at :enable_jffs2
  3. Boot a kernel-only uImage
    • Boot the uImage made from vmlinux or disable when doing kernel configuration like following:
      == Blackfin Processor Options ==
  Disable   Enable RAM RootFS attached to the Kernel image(linux)
== Select Device Drivers ==
 == Memory Technology Devices(MTD) ==
  == Mapping drivers for chip access
    Disable   Generic Linux RAM/ROM filesystem support

      Then we can get a kernel-only linux. Use this image to boot the STAMP board from SDRAM using jffs2 file system.

  4. Mount NFS file system test
    • To see if the target machine can mount to host file system, which will be very useful for exchanging files between them and smooth the develop and test process.
    • There are two kinds of nfs mount operation. It is allowed to mount the file system when kernel is booting up at the beginning as well as after that at any moment when is needed. Either method needs the host system has the nfs server set ready.
    • To use the first method, configure the kernel like following:
      under Customize Kernel Settings
== Select Kernel hacking ==
    Disable Compiled-in Kernel Boot Parameter
== Select Networking  ==
    Enable  Networking Support
    == Select Networking options ==
       Enable IP: kernel level autoconfiguration
== Select File systems ==
    == Select Network File System ==
      Enable  NFS file system support
      Enable  Root file system on NFS

      Set uboot environment variable rootpath to the nfs access directory that is set in the host machine. 

      stamp> set rootpath=/home/test/checkouts/uclinus-dist/romfs

      Make a console device in this romfs under /dev folder. 

      root:~> mknod console c 5 1

      Then boot the previously built kernel, you can see it mount the nfs export directory of the host machine.

    • The second method can look this document:enabling_nfs
  5. Mount SMB file system test
    • To see if the uclinux can samba mount onto the host system and share its files.
    • SMB server need be started on host by:
       /etc/init.d/smb start
    • Next add a user test. 
      smbpasswd -a test
  6. JFFS2 file system test
    • To see if jffs2 file system can work right as to various file operations.
    • There is a shell script to recursively establish folder and files and then delete; execute the general file operation provided in standard C library, including file open, close, read, write, putc, getc etc functions; also cases to test the file stream operations.
    • Use the kernel built supporting JFFS2 file system, details are in the this document:enable_jffs2. Enlarge the size of the file system to include these cases in the jffs2 image. Edit the value of EXT2_BLOCKS in the file vendors/AnalogDevices/BF533-STAMP/Makefile to be EXT2_BLOCKS = 8192. Flash the new jffs2.img, and use it as the root file system. Run the fs-test.sh script can start the test.
  7. Stress test(WT,WB)
    • Run the ftp client program, telnet proram, and ping to the host machine at the same time for a day to see if the target board can sustainable receive and deal with ftp and telnet request with ping goes on. If at the end of the time period, the ping process is still alive and kill the two ongoing ftp and telnet process normally, the test passes, otherwise it fails.
  8. Network audio player
    • To test if the network audio player can play the music that is stored on a host machine by smb mount.
    • More details can be found at:network audio player
  9. Linphone
  10. Sqlite
    • Config the kernel to select the sqlite application and it test case.
      under Customize Vendor/User Settings
== Select Library Configuration programs ==
   == Select Build sqlite ==   
== Select Blackfin test programs ==
   == Select Sqlite test program ==
    • At the target board prompt,run:
      cd /usr
sqlite3 wishlist.db < wishlist.sql
sqlite3 wishlist.db ".dump"
sqlite_test "foo"

      It should print out one record from the database.

  11. Pound - https server
  12. Qt (mouse)
    • There is an auto test case for QT and usb mouse is not used. A manual case should be done with a usb mouse connected, and we use usb host ISP1362.
    • Before QT kernel is built, make sure that there is a pre-built QT source in host PC.
    • Please refer to the docQT Embedded Library
  13. Konqueror
    • This manual test case comes together with QT test case, as the kerenel can only be built after qt kernel is built.
    • Please refer to the doc:Konqueror3 Embedded
  14. MicroWin
  15. Mplayer
  16. DirectFB
    • Run the benchmark application “df_dok” in regression. There are still other examples in /usr/bin. df_input can be used to test with usb keyboard and mouse inputs. This can only be run manually.
    • Choose Blackfin App - DirectFB Examples, DirectFB lib and examples will be built. Framebuffer Console should also be enabled.
    • Please refer to the DirectFB doc:DirectFB, and the Framebuffer Console doc:The Framebuffer Console.
  17. g729
    • The detailed description of G729ab Blackfin uClinux codec is in the README.txt in folder uclinux-dist/lib/libbfgdots/g729. There is a “check test” option in the Makefile in that folder. You can run a quick test to just type “make check test”.
    • In auto test case, alltests.sh is used instead of quick.sh to run all the test vectors.
  18. debug_mmrs
    • Read access on the debugfs may crash, use command to catch crashes:
      find /sys/kernel/debug/blackfin/ -type f -print -exec cat '{}' \;
    • For the detail to test debug-mmrs.c, please refer to:[#4778] debug-mmrs.c causes crashes.
  19. colinux
    • CoLinux is a system where you can run a complete Linux system while in Windows. This is a brief introduction to colinux.
    • Get the latest Blackfin colinux release and start to install colinux.
    • Run coLinux, then check out toolchain and kernel resource and build a image. Run this image in target board.
    • When a new colinux is released, upgrade an existing install with colinux base installer.

Performance test

  1. lmbench test
  2. nbench test
  3. dhrystone test
  4. whetstone
  5. edn test
    • Configure uclinux-dist to build edn.
      Blackfin app programs  --->
     [*] EDN's DSP benchmark
    • Run edn 
      root:/> edn

Environment

The requirements of a host system are those necessary to build the Linux kernel. The general information about installation of the Linux kernel and uClinux diststribution can be found by checking out at FIXME. For example purposes, the host system described in this document is composed as follows:

  • Dell x86 machine
  • Intel® Pentium® 4 CPU 3.00Ghz;
  • 512 M RAM;
  • Harddisk: 78 G;
  • Two Ethernet cards (one connection to the internet)
  • serial port
  • SuSE Linux 9.2 Pro, with these optional packages installed:
    • subversion-cvs2svn-1.0.8-2
    • expect-5.41-2
    • tftpd
    • kermit or minicom

The Blackfin target system must have the following features:

  • Blackfin processor, supported by the uClinux distribution
  • 10/100 Ethernet
  • SDRAM (about 32M for normal size kernel test)
  • Flash (128k bytes to Boot U-Boot)
  • Serial Port for console communications

For example purposes, the ADDS-BF533-STAMP and ADDS-BF537-STAMP board will be used for these tests. This board includes:

  • an Ethernet interface with an RJ45 (female) jack,
  • a serial port interface with a DB9 (female) connector,
  • a power supply jack and voltage regulator, as well as several interfaces to various Blackfin peripherals.
  • It is connected with the host machine using crossover network cable and the serial cable. Its IP address is also fixed, e.g.10.100.4.50.

Target Configuration

The target must be connected to the host with:

  • 10/100 Ethernet cross over cable
  • Serial Cable
  • Power must be applied to the target

Host Configuration

The following needs to be pre-configured on the machine, which is out of the scope of this document:

  • serial communication on /dev/ttyS0, set to 57,600 8-N-1 (8 data bits, No parity, one stop bit), which can be accessed by the user running the tests
  • A tftp server needs to be enabled, and its working directory set to /tftpboot
  • The IP address of Ethernet device is set to a fixed address, such as 10.100.4.174
  • A connection to the internet, with access to the svn machine (such as firewakk-sources.blackfin.uclinux.org)

Linux Kernel test steps

The test scripts to run the above cases are placed in /testsuites folder under uClinux-dist kernel source tree which can be downloaded from our svn server. Each case has an unique subfolder which includes the script to build the function kernel and the steps to test it. There is a script named kernel_test which knows what cases to run on each board and takes turns to run them. To use it, you just need pass the right board name, etc, as parameter into the script to run the right set of cases.
These test cases fall into two parts, automated ones and manual cases.

  1. Automated tests
  2. Manual tests

Here are the steps to follow to test the Linux kernel:

  • On Host: Download the released uClinux-dist source code and the test scripts with the tagname(the version number is 2.6.x) from svn to ~/checkouts/kernel/. 
    cd  ~/checkouts/kernel/
svn checkout svn://firewall-sources.blackfin.uclinux.org:80/svn/uclinux-dist/trunk .
  • On Host: Install a released stable toolchain and export its path, so that when building the kernel, it can use this installed toolchain. 
    export PATH=/opt/uClinux/bfin-uclinux/bin:/opt/uClinux/bfin-linux-uclibc/bin:/opt/uClinux/bfin-elf/bin:$PATH
  • On Host: Configure as root the IP address of the ethernet card that is connecting with the target board. 
       sudo ifconfig eth1 10.100.4.174
  • Make sure the stamp board is connected with the host through the serial port(/dev/ttyS0,if not change the ttydev value to Kermit setting) and the Ethernet port.
  • On Host: Start minicom at shell console to have a connection with the target board through the serial port. 
        minicom
  • On Target: Power on the board, stop it at uboot prompt and set the uboot environment, such as serverip, ipaddress, bootcmd. 
        set ipaddr 10.100.4.50
    set serverip 10.100.4.174
    set bootfile linux
    set bootcmd run tftp_boot
    set tftp_boot 'tftpboot 0x2000000 linux;bootelf 0x2000000'
    save
  • On Target: Let the board boot into kernel to get ready for testing on hardware. 
        run tftp_boot
  • On Host: Close minicom by entering ctrl-A followed by Q to cut off the serial port connection. Because most of the test scripts will also need establish a serial connection with the target board through the same serial port.
  • On Host: Copy run_kernel_test from testsuites.test_scripts/ to ~/test_suites/uclinux-dist(a user-defined folder for test suites), enter the directory, edit the parameters in this file like BOARD_CONFIG,CPU KERNEL_PATH etc,and then run ./run_kernel_test script to do the testing. 
        cd ~/test_suites/uclinux-dist
    ./run_kernel_test

    It will print out removing and checking out cvs infomation, and the messages from building and testing the kernel. The test result files can be found at the same directory as the scripts, and would be collected to the folder test-scripts/uclinux-dist/logs/2008_xxx_xx_xx_xx of the host machine.

Criteria

  1. LTP 
    	       Total	Pass	Fail	Broken	 Warning  Crash	Skipped  NA
============================================================================
* gcc 4.1, FLT							
bf533-stamp-wt	702	554	6	3	0        1	13      125
bf533-stamp-wb	702	554	6	3	0	 1	13      125
bf533-ezkit-wt	702	552	7	3	0	 2	13      125
bf533-ezkit-wb	702	552	7	3	0	 2	13      125
bf537-stamp-wt	702	554	6	3	0        1	13      125
bf537-stamp-wb	702	554	6	3	0        1	13      125
bf561-ezkit-wt	702	554	5	3	0        1	14      125
bf561-ezkit-wb	702	555	5	3	0        1	13      125

    For details, please refer to blackfin website here

  2. The driver tests and system test cases listed in this test plan for the kernel built should all pass the testing .The test results log can be found at website here

Problem reporting and tracking

Limitations

The kernel testing at various system clock and core clock is not carried out at the moment.

Others