Board validation and diagnostic tools
From IGEP - ISEE Wiki
Contents
[hide]OMAP35x/DM37x
How to find the Silicon Revision
Read back a 32 bit word from the CONTROL_IDCODE Register at address: 0x4830 A204
| Processor | Silicon Revision | 32-bit readback value |
|---|---|---|
| OMAP35x | ES1.0 | 0x0B6D 602F |
| OMAP35x | ES2.0 | 0x1B7A E02F |
| OMAP35x | ES2.1 | 0x2B7A E02F |
| OMAP35x | ES3.0 | 0x3B7A E02F |
| OMAP35x | ES3.1 | 0x4B7A E02F |
| AM/DM37x | ES1.0 | 0x0B89 102F |
| AM/DM37x | ES1.1 | 0x1B89 102F |
| AM/DM37x | ES1.2 | 0x2B89 102F |
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
How to check system boot order
# devmem2 0x480022F0 b
How to find the SGX core revision
Perform the following commands on the target with an utility like devmem2.
# devmem2 0x48004B48 w 0x2 # devmem2 0x48004B10 w 0x1 # devmem2 0x48004B00 w 0x2 # devmem2 0x50000014
from the read back value you can see the revision of the SGX Core
| Processor | SGX Core Revision | 32-bit readback value |
|---|---|---|
| OMAP35x ES2.0 | 1.0.3 | 0x10003 |
| OMAP35x ES3.1 | 1.2.1 | 0x10201 |
| AM/DM37x | 1.2.5 | 0x10205 |
How to get the processor DIEID
#!/bin/sh
DIEID=""
for addr in '0x4830a224' '0x4830a220' '0x4830a21c' '0x4830a218'; do
DIEID=${DIEID}`devmem2 $addr | awk '/Read/ { printf "%08X", $6 }'`
done
echo ${DIEID}
Power consumption
Power measurements taken over the operating conditions specified.
| Platform reference | Power-up (1) | 2.6.28.y | 2.6.33.y |
|---|---|---|---|
| IGEP v2 RC1 | 240mA | 550mA | |
| IGEP v2 RC2 | 240mA | 460mA | |
| IGEP v2 RC3 | 240mA | 550mA | |
| IGEP COM MODULE 3530 4G | 80mA | NA | 310mA |
| IGEP COM ELECTRON 3503 1G | 80mA | NA | 260mA |
Power measurements conditions:
- 1: Typical value when power-up with empty flash
Decrease consumption
- Switch off leds:
echo 0 > /sys/devices/platform/leds-gpio/leds/d210\:green/brightness echo 0 > /sys/devices/platform/leds-gpio/leds/d210\:red/brightness echo 0 > /sys/devices/platform/leds-gpio/leds/d440\:green/brightness echo 0 > /sys/devices/platform/leds-gpio/leds/d440\:red/brightness
- Switch off WIFI i BT:
echo 0 > /sys/class/gpio/gpio139/value echo 0 > /sys/class/gpio/gpio137/value
- Slow down CPU frecuency (about 120mA):
cpufreq-set -f 300Mhz
- Hibernate (about 60mA):
echo mem > /sys/power/state
MMC
#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 rate transfer was reported by dd.
Results:
| Test | 2.6.32.25 (PC i5 CPU) | 2.6.35.9 (DM37x) | 2.6.37-5 (DM37x) | 2.6.37-6 (DM37x) |
|---|---|---|---|---|
| read | 9.7 MB/s (3m 24.43s) | 13.8 MB/s (2m 22.70s) | 5.5 MB/s (4.0 GB copied, 728.5s, SD Class 6) | 16.2 MB/s (4.0 GB copied, 249.29s, SD Class 6) |
| write | 2.0 MB/s (16m 3.68s ) | 3.4 MB/s (9m 44.78s) | 2.0 MB/s (4.0 GB copied, 2055.92s, SD Class 6) | 3.0 MB/s (4.0 GB copied, 1356.13s, SD Class 6) |
Notes:
src: http://jozz.no-ip.org/wiki/host/tips_and_trix
Says performance can be improved by letting more memory be used as buffers and delaying writeback doing
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs echo 50 > /proc/sys/vm/dirty_ratio echo 50 > /proc/sys/vm/dirty_background_ratio
The results are:
# time dd if=/dev/mmcblk0 of=/dev/null 3842048+0 records in 3842048+0 records out 1967128576 bytes (2.0 GB) copied, 148.344 seconds, 13.3 MB/s real 2m 28.35s user 0m 5.67s sys 0m 19.66s
# time dd if=/dev/zero of=/dev/mmcblk0 dd: writing to `/dev/mmcblk0': No space left on device 3842049+0 records in 3842048+0 records out 1967128576 bytes (2.0 GB) copied, 578.973 seconds, 3.4 MB/s Command exited with non-zero status 1 real 9m 39.00s user 0m 3.64s sys 0m 39.77s
Conclusion: No big difference with this test.
NAND/OneNAND
We assume that the mtd4 is available for test.
#000 : Basic read operation
Category: performance
Description:
Conditions: IGEP0020-RC6 + IGEP Firmware Yocto 1.2.1-2
How to test:
The read tests were performed by running the following command:
$ time dd if=/dev/mtd2 of=/dev/null
The results are:
root@igep00x0:~# time dd if=/dev/mtd2 of=/dev/null 1022976+0 records in 1022976+0 records out real 1m21.901s user 0m0.453s sys 1m21.406s
#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 subsystem tests
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
RAM
#001 : Simple memory test
Category: functional
Description: Userspace utility for testing the memory subsystem for faults.
How to test:
Run the memtest command
memtester 256M 1
Result should be like this:
memtester version 4.1.3 (32-bit) Copyright (C) 2010 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffff000 want 256MB (268435456 bytes) got 256MB (268435456 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok
