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

Testing U-Boot

Purpose

The purpose of testing U-Boot is to ensure the release is stable and robust, which can be used to initialize the target board and boot it into the uClinux kernel.

Overview

To test the Das U-boot, a host system and Blackfin target are required. The host system is where the U-Boot source code is downloaded and built. The Blackfin target enables tests to be run on the processor ensuring that the U-Boot binary can initialize the board properly before the uClinux kernel has been booted up. For now, there are the following types of target boards available: Blackfin 533 STAMP board, Blackfin 537 STAMP board, Blackfin 533 EZKIT board, Blackfin 561 EZKIT board, Blackfin 548 EZKIT board, Blackfin 527 EZKIT board, Blackfin 518 EZBRD board, Blackfin 526 EZBRD board, and Blackfin 609 EZKIT board. These boards are covered in this test. Since there is some difference between them, the way to test the u-boot also differs accordingly. And since Blackfin 534 is only one ethernet port less than the Blackfin 537 chip, the test for BF534 can be emulated by running on BF537 board.

The u-boot test is taken at various system clock and core clock to ensue U-Boot support the boards at all the working frequencies well. The working range for the boards is 30~120Mhz System Clock and 50~600Mhz Core Clock. For each board, four combinations of CSLK and SCLK are selected(except BF609 with ddr clock).

  • stamp BF533 board: 497 Mhz 124 Mhz, 497Mhz 33 Mhz, 398 Mhz 79 Mhz, 99Mhz 49Mhz.
  • stamp BF537 board: 500 Mhz 100 Mhz, 500Mhz 50 Mhz, 200 Mhz 100 Mhz, 100Mhz 50Mhz.
  • ezkit BF561 board: 600 Mhz 120 Mhz, 600Mhz 50 Mhz, 195 Mhz 97 Mhz, 97Mhz 48Mhz.
  • ezkit BF533 board: 594 Mhz 118 Mhz, 594Mhz 49 Mhz, 202 Mhz 101 Mhz, 101Mhz 50Mhz.
  • ezkit BF548 board: 525 Mhz 131 Mhz, 525Mhz 43 Mhz, 93 Mhz 46 Mhz, 187Mhz 93Mhz.
  • ezkit BF527 board: 525 Mhz 131 Mhz, 600Mhz 50 Mhz, 100 Mhz 50 Mhz, 200Mhz 100Mhz.
  • ezkit BF609 board: 500 Mhz 100 Mhz(250Mhz),500Mhz 100Mhz(250Mhz),400 Mhz 100Mhz(200Mhz),400Mhz 100Mhz(133Mhz).

After download the U-Boot source code, change the CSLK and SCLK value in the bf533-stamp.h/bf537-stamp.h/bf561-ezkit.h/bf533-ezkit.h/bf548-ezkit.h/bf609-ezkit.h head file by redefine CONFIG_VCO_MULT, CONFIG_CCLK_DIV, and CONFIG_SCLK_DIV,(CONFIG_DCLK_DIV on bf609). Then build a u-boot.bin and/or u-boot.ldr, flash it onto the board and do all the test cases to see if they can pass. When finished, it comes to the next combination of CSLK and SCLK, and go through the whole process all over again. The same apply to the left points.

And while running the test cases, to ensure that cache settings (either data cache or instruction cache) does not negatively effect any of the tests, all the tests will be executed 4 times with:

  • instruction cache off, data cache off
  • instruction cache on, data cache off
  • instruction cache off, data cache on
  • instruction cache on, data cache on

Since the U-Boot tests will load an elf uClinux image and uImage,etc, it is necessary to have the needed files under /tftpboot on the host system.

Basic Command Tests

U-Boot provides a set of commands to operate the resources, such as RAM, FLASH, serial port, and ethernet, on the board before the kernel is executed. The below tests attempt to ensure that all the features of U-Boot are working.

  1. test countdown time period
    • It calculates the intermediate time between the 3rd and 2nd second when countdown in rebooting. Then the result is compared with 1 second. If the difference is less than 0.1, the case passes, otherwise it fails.
  2. version command
    • Input the version command at the U-Boot prompt. If it can display the U-Boot version, it passes, otherwise it fails.
  3. echo
    • Input echo command followed by one sentence. If the output is the same as the sentence entered, the case passes, otherwise it fails.
  4. help date
    • Input this command to see if the help information is shown correctly. If the output is like “[MMDDhhmm]”, the case passes, otherwise it fails.
  5. date
    • Set one specific date using this command, and see if U-Boot accepts it correctly. If the print date is the intended date, the test passes, otherwise it fails.
  6. date set and time set after U-Boot reset
    • Sleep 60 seconds, reset U-Boot and print the date and time information again to see if the previous setting is still effective and is displayed properly . If true, the case pass, otherwise it fails.
  7. help
    • To see if the help information is right by issuing the help command. If the usage message for each command is displayed, then the case passes, else it fails.
  8. flinfo
    • To check the flash bank and sector information. If what it prints goes with the value in the U-Boot config file which is, bank 1 and sector 67, the case passes, otherwise it fails.
  9. mw
    • Memory write test. Use the mw.l command to write a long value to one memory address, and check it with md.w (memory display) command to see if the mw command writes as expected.
  10. nm
    • Memory modify at constant address. First, write a value to one address by mw.b, then issue nm.w command to change the value 80 times. When finished, interrupt the command and check the value using md. If the result is expected the case passes, otherwise it fails.
  11. mm
    • Memory modify by auto-incrementing. Input the mm.w command with one address, change that value, and hit enter to change the next value in the following address. It is cycled by 32 times. In the end, check with the md command to see if the result is right.
  12. reset
    • Reset U-Boot 200 times to see if U-Boot can continuously reset the board successfully. If it resets properly every time, the test passes, otherwise it fails.
  13. saveenv and printenv
    • First set the U-Boot environment variables with set command, then execute the command of saveenv, reset and printenv in sequence for 10 times. If it correctly saves and prints the environment variables, the test passes, otherwise it fails.
  14. ping
    • Ping the host machine 10 times to see if this command functions properly. If all 10 pings are successful, the case passes, otherwise it fails.
  15. autoscr
    • Tftp download one test image file, run autoscr to see if it can execute and print the right message. If so, the case passes, otherwise it fails.
  16. base
    • Use this command to check if the base address is set as it is in the U-Boot config file. If they are the same, the case passes, otherwise it fails.
  17. bdinfo
    • Use this command to check if the board memory start address and its size, flash start and size, Ethernet address, ipaddr, and baudrate in U-Boot matches the config file. If it is the same, the case passes, otherwise it fails.
  18. iminfo
    • Use this command to check if the information of the kernel gunzip-compressed image can be recognized correctly in U-Boot. It includes the image name, the created date, its type, the size, its address and entry point, and checksum. If all information is right, the case passes, otherwise it fails.
  19. bootelf (this case is disabled now)
    • Tftp download one dxe kernel image, use this command to see if it can be booted up successfully. If so, the case passes, otherwise it fails.
  20. cmp
    • Firstly tftp download one test file, copy it to one random SDRAM address, then use this command to compare if the destination file is the same as the source file. Secondly use mm.b to change the last byte of the file, compare again to see if the printed message says there is a difference and one less bytes are still the same. If so, cmp case passes, otherwise it fails.
  21. run
    • Input this command to see if it can make a U-Boot command execute. Try an invalid U-Boot command to see if it reports an error message. If so, the case passes, else it fails.
  22. mtest
    • Simple RAM test. To issue this command at a random RAM address to see if it quickly repeats writing and reading information. If so, it passes.
  23. protect on and protect off
    • First, use this command to protect on the whole flash bank, then try cp.b command to see if it still can be written to. If not, protect on works. Secondly, protect off the whole bank, erase one random flash address area, copy a file to that address, and use cmp.b command to compare if the destination file is the same as the source file. If true, protect off case passes.
  24. cp RAM-to-RAM, aligned
    • First, use mw.b to write to two aligned RAM addresses with 0xFF 4 times respectively. Secondly tftp one test file to an aligned RAM address, and copy this file to the address that is 4 bytes behind the first aligned address. Compare the two files to see if they are the same. Finally check again the two aligned addresses if the old value still remains. If so, the case passes, else fails.
  25. cp RAM-to-RAM,unaligned
    • First, use mw.b to write to two unaligned RAM addresses with 0xFF 4 times respectively. Secondly tftp one test file to an unaligned RAM address, and copy this file to the address that is 4 bytes behind the first unaligned address. Compare the two files to see if they are the same. Finally check again the two unaligned addresses if the old value still remains. If so, the case passes, else fails.
  26. cp RAM-to-flash, aligned
    • First, erase one flash area that is started from an aligned address, cp.b one testfile from the tftp_boot RAM aligned address to one segment of the erased flash that is started from an aligned address. Then compare the two areas to see if they are the same. Finally check two aligned flash address that is before and after this segment to see if these addresses are not modified. If so, the case passes, otherwise it fails.
  27. cp RAM-to-flash, unaligned
    • First, erase one flash area that is started from an aligned address, cp.b one testfile from the tftp_boot RAM unaligned address to one segment of the erased flash that is started from an unaligned address. Then compare the two areas to see if they are the same. Finally check two unaligned flash address that is before and after this segment to see if their addresses are not modified. If so, the case passes, otherwise it fails.
  28. cp flash-to-flash, aligned
    • First, erase one flash area that is started from an aligned address, and select one segment that is started from an aligned address to cp.b one testfile from RAM. Then erase another flash area with aligned start address, copy from the previous area to it. When finished, compare the two areas to see if they are the same. Finally check two aligned flash addresses that is before and after the latter flash address to see if their values are not been modified by the copy. If that is the case, the test passes, otherwise it fails.
  29. cp flash-to-flash, unaligned
    • First, erase one flash area, from which select one segment that is started from an unaligned address to cp.b one testfile from RAM . And then erase another flash area, copy from the previous area to the second flash area that is also started with an unaligned address. When finished, compare the two areas to see if they are the same. Finally check two unaligned flash addresses that is before and after the latter flash address to see if their values are not been modified by the copy. If that is the case, the test passes, otherwise it fails.
  30. cp flash-to-RAM,aligned
    • First, erase one flash area that is started from an aligned address, cp.b one testfile to it from RAM. And then mw.b write to two aligned RAM addresses with 0xff 4 times respectively which is before and after the intended to copy RAM address. Secondly Copy from the previous flash area started with aligned address to the selected RAM address. When finished, compare the two areas to see if they are same. Finally check again the two RAM aligned addresses to see if their values are unchanged. If that is the case, the test passes, otherwise it fails.
  31. cp flash-to-RAM, unaligned
    • First, erase one flash area, from which select one segment that is started from an unaligned address to cp.b one testfile to from RAM address. And then mw.b write to two unaligned RAM addresses with 0xFF 4 times respectively which is before and after the intended to copy RAM address. Secondly Copy from the previous flash area to the selected RAM address that is also started with an unaligned address. When finished, compare the two areas to see if they are same. Finally check again the two RAM unaligned addresses to see if their values are not changed. If that is the case, the test passes, otherwise it fails.
  32. tftp and tftp check for error
    • Tftp download uImage file 20 times, and check if for an error, such as invalid RARP, tftp timeout etc,during this process. If all download successfully, the tftp test passes, otherwise tftp fails. And If no tftp error is detected, the check for error case is also passed.
  33. boot known-good uImage from flash
    • Download a uImage via tftp, and copy it to flash. Set the bootcmd parameter to make it boot from the flash address. Reset the board to see if the kernel really boots from the flash area and boots successfully. If so, the case passes, otherwise it fails.
  34. Big-size linux image boot test with caches on
    • Having icache and dcache on, tftp download big-size(for BF533 about 35M,for BF537 about 15M) linux DXE image to see if it can boot up successfully.
  35. go
    • Tftp download a small binary file add.bin to one SDRAM address 0x1000000, run this file at U-Boot prompt by issuing go command. It does an add operation and store the result value to another address. Read it out by md.b command to see if it is the expected value. If true, it proves the add.bin has been correctly executed,and the case passes. Otherwise it fails.
  36. bootm
    • Tftp download one uImage kernel to a SDRAM address, use this command to see if it can be booted up successfully. If so, the case passes, otherwise it fails.
  37. tftp download at speed 10 duplex half when ping flood
    • Tftp download a big linux kernel (>=20M) with the ethernet card configured at speed 10 duplex half when ping flood to see if the tftp process can still pass. The configuration is done by ethtool tool on host in the commandline: ethtool -s ethX speed 10 duplex half.
  38. tftp download at speed 10 duplex full when ping flood
    • Tftp download a big linux kernel (>=20M) with the ethernet card configured at speed 10 duplex full when ping flood to see if the tftp process can still pass. The configuration is done by ethtool tool on host in the commandline: ethtool -s ethX speed 10 duplex full.
  39. tftp download at speed 100 duplex half when ping flood
    • Tftp download a big linux kernel (>=20M) with the ethernet card configured at speed 100 duplex half when ping flood to see if the tftp process can still pass. The configuration is done by ethtool tool on host in the commandline: ethtool -s ethX speed 100 duplex half.
  40. tftp download at speed 100 duplex full when ping flood
    • Tftp download a big linux kernel (>=20M) with the ethernet card configured at speed 100 duplex full when ping flood to see if the tftp process can still pass. The configuration is done by ethtool tool on host in the commandline: ethtool -s ethX speed 100 duplex full.
  41. watchdog
    • Run an illegal command or disallowed instruction, like writing to a reserved address to see if it can panic u-boot and reset.
  42. spi compare
    • Read date from the address of spi flash to two different addresses and then compare if they are samely copied. Set up a loop to run this operation by increasing the spi address each time.
Note: date/time related command doesn't supported on BF561 and BF609, since they have no RTC.

Added Feature Tests

  1. jffs2
    • By adding jffs2 filesystem to U-Boot, it is able to use flash file system under U-Boot, display and operate files just like in uClinux operating system, thus highly extending the usefulness of U-Boot.
    • When testing, firstly tftp download the jffs2.image made by mkfs.jffs2 tool, erase one segment of flash, and copy the image to this area. When done, issue ls command to scan the content of the jffs2 filesystem to see if it prints correctly. And input fsinfo, fsload command to check if the image is made right. The commands are: 
      stamp> tftpboot 0x1000000 jffs2.image
stamp> protect off 0x20080000 0x203fffff
stamp> erase 0x20080000 0x203fffff
stamp> cp.b 0x1000000 0x20080000 0x320000
stamp> ls
stamp> fsinfo
stamp> fsload /uImage
  2. DMA
    • By doing DMA in U-Boot, L1 Memory can be put into usage before the kernel is booted up. Because in the Blackfin processor, L1 Memory can only be extracted instructions from, and these instructions need to be stored into L1 memory through DMA operation.
    • The DMA test case firstly tftp download a small binary file add.bin to 0xffa0b000, one Instruction SRAM address( it belongs to L1 Memory ), run this file at U-Boot prompt. It does an add operation and store the result value to one memory address. Read it out by md.b command to see if it is the expected value. If true, it proves the Blackfin processor can read and execute the data in the Instruction SRAM correctly, and DMA sends the file in the right way. The commands are:
      stamp> tftpboot 0xffa0b000 add.bin
stamp> go 0xffa0b000
stamp> md.b 0x1000090
  3. Passing parameters from U-Boot to kernel
    • Passing parameters, such as root filesystem, ip address, from U-Boot to kernel make it possible to dynamically switch the root file system when boot the kernel without reconfiguration and rebuilding the linux image.
    • Set the environment param bootargs of U-Boot to a new value. Boot up to the linux kernel, and then execute cat /proc/cmdline to see if it is the value previously set. If so, it means the param has been passed by U-Boot to kernel. Otherwise the case fails. The commands are (at U-Boot Prompt):
       stamp> set bootargs root=/dev/mtdblock0 rw ip=10.100.4.60

      At kernel prompt: 

       root> cat /proc/cmdline
  4. Boot kernel uImage from serial port(for BF537 board only)
    • To have kernel uImage downloaded from serial port /dev/ttyS0, which supports BF534 board to boot up kernel.
    • Start kermit, connect to target board, input loadb at U-boot prompt, and then get back to kermit prompt by entering Ctrl-\ followed by C. Type send command with the linux uImage name. The serial transfer begins. It normally lasts 4 minutes or so for 1.5M kernel uImage. The commands are(at shell prompt): 
      root:~> kermit

      There is kermit prompt now. At this kermit prompt: 

      kermit> connect

      Then it comes to target board u-boot prompt: 

      stamp> loadb

      Get back kermit by Ctrl-\ and C and enter 

      kermit> send /tftpboot/uImage-beta
  5. Early Printk
    • Enable macro: #define CONFIG_DEBUG_EARLY_SERIAL.
    • It would show some early info before uboot start which is very useful to see uboot info instead of debugging.

Manual test

  1. Splash test(for BF527 and BF58 ezkit boards)
    • To show a picture of penguin when u-boot is starting on, which is included from u-boot source tree by default in the building process. Since bf527 and bf548 ezkit boards both have lcd screen equipped, so it is quite simple to set up this testing.
  2. SPI flash
    • Boot u-boot from SPI flash.
      • Edit include/configs/bf5xx-stamp(ezkit).h, define BFIN_BOOT_MODE to BFIN_BOOT_SPI_MASTER. For details of building u-boot, refer to compiling.
      • The built u-boot image is u-boot.bin, the binary LDR format file is u-boot.ldr. Do the following to load u-boot to the SPI flash:
        • Connect SPI flash to STAMP board. Note that for BF533, SPISEL2(PF2) is used as SPI chip select line; for BF537, SPISEL1(PF10) is used as SPI chip select line. Make sure your SPI flash has the correct SPI Chip Select line.
        • If there is no u-boot in the STAMP board, please program the file u-boot.hex to the SPI flash(M25P64) by VDSP, using the released VDSP SPI flash driver M25P64.dxe.
        • If you have u-boot in your flash on the STAMP board, you also can put the file u-boot.ldr into your host TFTP root directory and implement the command run update on the u-boot prompt.
          stamp>tftp 0x1000000 u-boot.bin
stamp>go 0x1000000

          Note: this u-boot.bin is the one built for spi flash. And before go 0x1000000, set switch for booting directly from SPI flash. Now the new u-boot is loaded. We can write the u-boot.ldr to SPI flash: 

          serial_stamp>printenv
... ...
update=tftp $(loadaddr) $(ubootfile);sf probe 1;sf erase 0 0x40000;sf write $(loadaddr) 0 $(filesize)
... ...
serial_stamp>run update
        • Make sure on BF533 board the S1 switch is set to 11(both switch are off) and on BF537 board SW16 is set to 3 when booting directly from SPI flash.
    • To read from and write to SPI flash and make it possible to boot up the uClinux kernel from the SPI flash.
      • SPI flash operation commands: sf. SPI flash can be used in following way. Firstly tftp download a file to one memory address, input sf erase/sf write command to copy the file to the SPI flash address(For example, 0x100000). When done, use sf read command to copy it out to another memory address. Then use cmp.b command to compare if the data at these two addresses are identical. Finally bootm the kernel that is copied from SPI flash. The commands are: 
        bfin> tftpboot 0x1000000 uImage
Using bfin_mac device
TFTP from server 10.100.4.174; our IP address is 10.100.4.50
Filename 'uImage'.
Load address: 0x1000000
Loading: #################################################################
         ################################
done
Bytes transferred = 1413493 (159175 hex)
bfin> sf erase 0x40000 0x190000
bfin> sf write 0x1000000 0x40000 $(filesize)
bfin>  sf read 0x2000000 0x40000 $(filesize)
bfin> cmp.b 0x1000000 0x2000000 $(filesize)
Total of 1413493 bytes were the same
bfin> bootm 0x2000000
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   bf527-0.2-3.0.8-ADI-2011R1-svn10
   Created:      2011-11-10   8:08:51 UTC
   Image Type:   Blackfin Linux Kernel Image (gzip compressed)
   Data Size:    1413429 Bytes = 1.3 MiB
   Load Address: 00001000
   Entry Point:  001caca8
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Starting Kernel at = 001caca8
...
      • If your u-boot has no sf command built in. Please follow the steps in compiling to add this command to u-boot.
  3. LDR tool test for serial boot
    • Supported platforms are: BF537-STAMP/BF527-EZKIT/BF548-EZKIT.
    • To boot up a stamp board without u-boot on it under Windows environment, which greatly saves the trouble to flash u-boot through hardware method.
    • The test procedure can be found at:Initially Loading U-Boot.
  4. Hardware test(for BF537 board)
    • To test if the chips and connectors are OK when the board is equipped at the beginning.
    • The test covers flash and memory chips, ethernet connector and buttons. As to the board setting, the SW5 and SW6 should all on, and the ethernet net port is set in a loop.
    • As to the building process, it is needed to delete the line of #undef CONFIG_POST_TEST in the file u-boot-1.1.6/include/configs/bf537-stamp.h and rebuild a new u-boot.bin. Flash this u-boot binary to the stamp board and reset, the hardware test starts.
  5. Nand flash support test(for BF537 board only)
  6. CF card support test(for BF537 board only)
  7. USB support test(for BF548,BF527,BF609)
  8. SDIO MMC startup(for BF609)
    • To see if the board can start up from u-boot image in SDIO MMC.
    • Edit boot mode to BFIN_BOOT_RSI_MASTER, and switch the jumper to 2.
    • Start kernel and cat u-boot.ldr > /dev/mmcblk0. This is the uboot image which would be loaded from SDIO MMC.
  9. ATAPI(for BF548)
    • Load uImage from sata devices.
    • Use command: 
      sata init
fatls sata 0
fatload sata 0 0x1000000 uimage
bootm 0x1000000
  10. MMC(SPI MMC for BF537, rest is SDIO MMC)
  11. JTAG console(for BF537,BF561)

Test coverage

All the test cases above, including basic command test, added feature test and manual test, are listed in the sheet u-boot test coverage

Environment

The requirements of a host system are those necessary to build the U-Boot. The general information about U-Boot installation can be found by checking out u-boot. 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;
  • Hard disk: 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 uClinux
  • 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 cvs machine (such as cvs.blackfin.uclinux.org)

Uboot test steps

For STAMP BF533

There are a few scripts needed to test the U-Boot, which is in the u-boot svn or git directory test_script. In this package you will find:

  • change_clk.exp changes CSLK and SCLK, which needs to pass in BOARD_TYPE(for example BF533-STAMP) and selected clock config(like 0,1,2,3) as parameters.
  • uboot-test: check out U-Boot source code from cvs, call change_clk.exp to change SCLK and CCLK value, rebuild U-Boot, reflash it on to stamp board by running uboot_erase.exp, and then call test_uboot.exp to do the comprehensive test, which includes all the command test cases and that of jffs2, cache, DMA, pass parameters and SPI flash features. Uboot-test repeats the process of reconfiguring the head file,rebuilding, reflashing and testing U-Boot for every combination of SCLK and CCLK. And the test_uboot.exp script generates a log file which will be reported to http://blackfin.uclinux.org.
  • boot_config.exp: select the boot up method,BYPASS,PARA,SPI_MASTER,SPI_SLAVE.
  • uboot_erase.exp.
  • test-uboot.exp.
  • uboot-config.exp: the pre-defined parameters needed in test-uboot.exp.
  • uboot-test-check: uboot souce code checkout script.
  • uboot_rectangle_test: a simple test script to connect the testing cycles on different clocks and keep it running in a loop.
  • uboot_misc_test.exp: change to different configs in include/configs to build specific uboot file and run gdb console test.
  • kernel_serial_transit.exp: test case to transit uImage through serial port and boot it up.
  • ide_test.exp: ide testing script.
  • spi_flash_test.exp: spi flash test script.

The files needed during the testing is included in uboot-file.tar.gz, which includes:(it could be check into the svn later.)

  • uboot-autoscr-test.img
  • testfile.bin
  • jffs2.image
  • add.bin

Here are the steps to test the u-boot:

  • On host: Check out u-boot and test scripts.
    cd /home/test/checkouts/u-boot
svn checkout --username anonymous https://blackfin.uclinux.org/svn/u-boot/trunk/u-boot_test_script u-boot_test_script
or:
git clone ssh://anonymous@firewall-sources.blackfin.uclinux.org:443/git/u-boot
  • On host: Change to this directory, and run the test script files. 
    cd /home/test/checkouts/u-boot/test_script/
./uboot_rectangle_test

    If the path is different from above, it is acquired to make a change to the related parameters, like CHECKOUT,UBOOT_SCRIPTS,SVN_SERVER,uboot_path in uboot-config.exp, uboot-test, and change_clock.exp. And also specify your ip_subnet and host_ipaddr in the config file.

  • On host: Edit /home/test/uboot_loop_test file, to make sure the board parameter passed to uboot-test is the right one. The default is BF561-EZKIT, it also could be BF533-STAMP, BF537-STAMP, BF533-EZKIT.
  • On host: Change to /tftpboot directory, and exact the uboot-file.tar.gz file, which includes the necessary files used by the test scripts.
    cd /tftpboot
tar zxvf  uboot-file.tar.gz
  • On host: Download the released uClinux source code(the version number is 2.6.x) to ~/checkouts/kernel/. 
    cd  ~/checkouts/kernel/
svn checkout --username anonymous https://blackfin.uclinux.org/svn/uclinux-dist/trunk .
or:
git clone ssh://anonymous@firewall-sources.blackfin.uclinux.org:443/git/buildroot kernel
git submodule update --init
  • On host: Install a latest released toolchain, e.g. blackfin-toolchain-xxrx-x.i386.rpm. Export this path so that when building the kernel next step, it can use this installed toolchain. 
    export PATH=/opt/uClinux/bfin-uclinux/bin:/opt/uClinux/bfin-elf/bin:$PATH
  • On host: Build a stable kernel with the minimum configuration. When finished, copy the linux image to /tftpboot directory. 
    cd  ~/checkouts/kernel/
make menuconfig
make
cp images/linux /tftpboot
cp images/uImage /tftpboot/uImage-beta

    It will print the kernel configuration and building information.

  • On Host: Configure as root the IP address of the ethernet card that is connecting with the target board. 
    sudo ifconfig eth0 10.100.4.174

Make sure the target board connected with the host through the serial port and the Ethernet port.

  • On host: Start the minicom at shell console to have a connection with the target board through the serial port.
  • On target: Power on the board and stops it at U-Boot prompt to get ready for the testing.
  • On target: Set up the uboot environment variables at U-Boot prompt, such as serverip, ipaddress, bootcmd. 
    stamp> set ipaddr 10.100.4.50
stamp> set serverip 10.100.4.174
stamp> set bootcmd run tftp_boot
stamp> set tftp_boot 'tftpboot 0x1000000 linux;bootelf 0x1000000'
stamp> save
  • On host: Close the minicom by enter ctrl-A followed by Q to cut off the serial connection. Because in the next step, uboot-test will also need to establish a serial connection with the target board through the same serial port.
  • On host: Enter /home/test/, run test script ./uboot_rectangle_test.
    cd /home/test/ 
./uboot_rectangle_test

It will print out the SVN checking out, SCLK and CCLK readjusting, U-Boot building and testing messages in a loop. These information can be found at the Uboot_Head page of http://blackfin.uclinux.org.

For the rest of the boards

The test steps are the same with that of stamp bf533. Please follow the above procedure.

Criteria

Here is the summary file for testing U-Boot under 398Mhz CCLK and 79Mhz SCLK on BF533 STAMP board by auto test script. 

test started Apr-26-2012-11:48am

Test Results (cclk:162 Mhz,sclk:81 Mhz,icache:off,dcache:on)
=====================================
  Total Tests   :   51
  Passed Tests  :   50
  Failed Tests  :   0
  Tests Not Run :   1

Failed Tests
=====================================

Passed Tests
=====================================
  -  usb
  -  atapi
  -  mmc
  -  tftp_100_full
  -  tftp_100_half
  -  tftp_10_full
  -  tftp_10_half
  -  go
  -  boot big kernel img
  -  SPI_flash
  -  DMA
  -  pass param
  -  bootm
  -  jffs2
  -  autoboot countdown seconds
  -  cp flash-to-RAM, unaligned
  -  cp flash-to-RAM, aligned
  -  cp flash-to-flash, unaligned
  -  cp flash-to-flash, aligned
  -  cp RAM-to-flash, unaligned
  -  cp RAM-to-flash, aligned
  -  cp RAM-to-RAM, unaligned
  -  cp RAM-to-RAM, aligned
  -  boot known-good uImage from flash
  -  tftp check for errors
  -  tftp
  -  run
  -  cmp
  -  protect off
  -  protect on
  -  printenv
  -  iminfo
  -  bdinfo
  -  base
  -  source
  -  ping
  -  savenv
  -  reset
  -  mm
  -  nm
  -  mw
  -  flinfo
  -  help
  -  time set after power cycle
  -  date set after power cycle
  -  date set
  -  help date
  -  echo
  -  version
  -  mtest

Tests Not Run
=====================================
  -  bootelf

Measurement Tests
=====================================
  ave ping command time, in seconds = 3.5446528
  min ping command time, in seconds = 1.531421
  max ping command time, in seconds = 6.551701
  ave saveenv time, in seconds = 2.7140311
  min saveenv time, in seconds = 2.693147
  max saveenv time, in seconds = 2.727480
  one boot countdown second = .999886

Test Setup
=====================================
  board type    = BF548-EZKIT
  tty           = /dev/ttyS0
  VCO Clock     = 325 Mhz
  Core Clock    = 162 Mhz
  System Clock  = 81 Mhz
  icache_status = off
  dcache_status = on

The detailed log can be found at:http://blackfin.uclinux.org

For BF533 STAMP board,U-Boot should pass all these cases(except the hardware test and LDR tool test,NAND and CF card test) at the 4 combinations of CCLK and SCLK, with either icache and dcache on or off.

For BF537 STAMP board,U-Boot should pass all these cases(except the manual splash test) at the 4 combinations of CCLK and SCLK with either icache and dcache on or off.

For BF548 EZKIT board,U-Boot should pass all these cases at the 4 combinations of CCLK and SCLK with either icache and dcache on or off.

For BF527 EZKIT board,U-Boot should pass all these cases at the 4 combinations of CCLK and SCLK with either icache and dcache on or off.

For BF561 EZKIT board,U-Boot is lack of 'date' command,so it would fail at 4 related cases (date set, help date, date set after power cycle, time set after power cycle). But all the other autorun cases should pass at the 4 combinations of CCLK and SCLK, with either icache and dcache on or off.

For BF533 EZKIT board, U-BOOT doesn't support SPI flash and JFFS2 file system . All the other cases should all pass at the four points with no caches turned on.

For BF609 EZKIT board,U-Boot is lack of 'date' command,so it would fail at 4 related cases (date set, help date, date set after power cycle, time set after power cycle). But all the other autorun cases should pass at the 4 combinations of CCLK and SCLK, with either icache and dcache on or off.

Problem reporting and tracking

  • Automated tests will be complete with Cruisecontrol.
  • Report files will be posted at here
  • To post or examine bug status check the Blackfin toolchain project

Limitations

  • U-Boot does not currently support Booting VDSP++ elf files