Difference between revisions of "Board validation and diagnostic tools"
From IGEP - ISEE Wiki
(→How to find the Silicon Revision of your OMAP35x) |
|||
Line 26: | Line 26: | ||
|} | |} | ||
− | Use the memory dump capability of u-boot | + | Use the memory dump capability of u-boot |
U-Boot # md 0x4830A204 1 | U-Boot # md 0x4830A204 1 | ||
4830a204: 2b7ae02f /.z+ | 4830a204: 2b7ae02f /.z+ | ||
− | + | from the read back value: 2b7ae02f, you can see the revision of this OMAP35x corresponds to ES2.1 | |
+ | |||
+ | or linux userspace utility devmem2 (http://www.lartmaker.nl/lartware/port/devmem2.c) | ||
+ | # devmem2 0x4830A204 | ||
+ | /dev/mem opened. | ||
+ | Memory mapped at address 0x402cc000. | ||
+ | Value at address 0x4830A204 (0x402cc204): 0x4B7AE02F | ||
+ | |||
+ | from the read back value: 0x4B7AE02F, you can see the revision of this OMAP35x corresponds to ES3.1 | ||
= Power consumption = | = Power consumption = |
Revision as of 20:04, 21 October 2010
( WIP )
Contents
How to find the Silicon Revision of your OMAP35x
Read back a 32 bit word from the CONTROL_IDCODE Register at address: 0x4830 A204
Silicon Revision | 32-bit readback value |
---|---|
ES1.0 | 0x0B6D 602F |
ES2.0 | 0x1B7A E02F |
ES2.1 | 0x2B7A E02F |
ES3.0 | 0x3B7A E02F |
ES3.1 | 0x4B7A E02F |
Use the memory dump capability of u-boot
U-Boot # md 0x4830A204 1 4830a204: 2b7ae02f /.z+
from the read back value: 2b7ae02f, you can see the revision of this OMAP35x corresponds to ES2.1
or linux userspace utility devmem2 (http://www.lartmaker.nl/lartware/port/devmem2.c)
# devmem2 0x4830A204 /dev/mem opened. Memory mapped at address 0x402cc000. Value at address 0x4830A204 (0x402cc204): 0x4B7AE02F
from the read back value: 0x4B7AE02F, you can see the revision of this OMAP35x corresponds to ES3.1
Power consumption
Power measurements taken over the operating conditions specified.
Platform reference | Power-up (1) | 2.6.28.y | 2.6.33.y | 2.6.34.y |
---|---|---|---|---|
IGEP v2 RC1 | 240mA | 550mA | |
|
IGEP v2 RC2 | 240mA | 460mA | |
|
IGEP v2 RC3 | 240mA | 550mA | |
|
IGEP SOC 3530 4G | 80mA | NA | 310mA | |
IGEP SOC 3503 1G | 80mA | NA | 260mA | |
Power measurements conditions:
- 1: Typical value when power-up with empty flash
MMC
I/O operations
#001 : Basic read/write operation
Category: performance
Description:
How to test:
The read tests were performed by running the following command:
$ time dd if=/dev/mmcblk0 of=/dev/null
The write tests were performed by running the following command:
$ time dd if=/dev/zero of=/dev/mmcblk0
The time used for the calculations was the time reported by dd.
Results:
Test (SD 2GB) | 2.6.28.y | 2.6.33.y |
---|---|---|
read | |
2m 33s |
write | |
10m 13s |
OneNAND
MTD Test Suite
We assume that the mtd4 is available for test.
#001 : Simple read/write test
Category: functional
Description:
How to test:
Run the nandtest command
nandtest -l 4194304 -k -p 5 /dev/mtd4
Result should be like this:
ECC corrections: 0 ECC failures : 0 Bad blocks : 0 BBT blocks : 0 003c0000: checking... Finished pass 1 successfully 003c0000: checking... Finished pass 2 successfully 003c0000: checking... Finished pass 3 successfully 003c0000: checking... Finished pass 4 successfully 003c0000: checking... Finished pass 5 successfully
#002 : MTD page test
Category: functional
Description: The MTD subsystem includes a set of tests which you may run to verify your flash hardware and drivers.
How to test:
Run this script
#!/bin/sh # # mtd-test-suite # # The MTD subsystem includes a set of tests which you may run to verify your # flash hardware and drivers. The tests are available in the drivers/mtd/tests # directory of the linux kernel source codes. You may compile the tests as # kernel modules by enabling them in the kernel configuration menu by marking: # "Memory Technology Device (MTD) support" -> "MTD tests support" # (or the MTD_TESTS symbol in the .config file). # # The MTD test-suite contains the following tests: # * mtd_speedtest: measures and reports read/write/erase speed of the MTD # device. # * mtd_stresstest: performs random read/write/erase operations and validates # the MTD device I/O capabilities. # * mtd_readtest: this tests reads whole MTD device, one NAND page at a time # including OOB (or 512 bytes at a time in case of flashes like NOR) and # checks that reading works properly. # * mtd_pagetest: relevant only for NAND flashes, tests NAND page writing and # reading in different sizes and order; this test was originally # developed for testing the OneNAND driver, so it might be a little # OneNAND-oriented, but must work on any NAND flash. # * mtd_oobtest: relevant only for NAND flashes, tests that the OOB area I/O # works properly by writing data to different offsets and verifying it. # * mtd_subpagetest: relevant only for NAND flashes, tests sub-page I/O. # * mtd_torturetest: this test is designed to wear out flash eraseblocks. It # repeatedly writes and erases the same group of eraseblocks until an # I/O error happens, so be careful! The test supports a number of # options (see modinfo mtd_torturetest) which allow you to set the # amount of eraseblocks to torture and how the torturing is done. You # may limit the amount of torturing cycles using the cycles_count module # parameter. It may be very god idea to run this test for some time and # validate your flash driver and HW, providing you have a spare device. # For example, we caught rather rare and nasty DMA issues on an OMAP2 # board with OneNAND flash, just by running this tests for few hours. # * mtd_nandecctest: a simple test that checks correctess of the built-in # software ECC for 256 and 512-byte buffers; this test is not # driver-specific but tests general NAND support code. (NOT APPLICABLE) # # We assume that the mtd4 is available for test. MTD=4 MTD_TESTS="mtd_oobtest mtd_pagetest mtd_readtest mtd_speedtest mtd_stresstest mtd_subpagetest mtd_torturetest" # Assure all mtd test modules are removed modprobe -r ${MTD_TESTS} # Run test suite for test in ${MTD_TESTS}; do case "$test" in "mtd_torturetest" ) # clean the kernel ring buffer dmesg -c > /dev/null echo "MTD subsystem $test ..." modprobe ${test} dev=${MTD} cycles_count=1 # print out the messages dmesg ;; * ) # clean the kernel ring buffer dmesg -c > /dev/null echo "MTD subsystem $test ..." modprobe ${test} dev=${MTD} # print out the messages dmesg ;; esac done # Remove all mtd test modules modprobe -r ${MTD_TESTS} exit 0