Changes

Board validation and diagnostic tools

9,195 bytes added, 13:19, 15 April 2014
no edit summary
( WIP )= OMAP35x/DM37x =
== How to find the Silicon Revision of your OMAP35x ==
Read back a 32 bit word from the CONTROL_IDCODE Register at address: 0x4830 A204
{| border="1"
|-
! 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 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 {| border="1"|-! 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 <sup>(1)</sup>
! 2.6.28.y! 2.6.33.y! 2.6.34.y
|-
| IGEP v2 RC1
| 240mA
| 550mA||<br>
|-
| IGEP v2 RC2
| 240mA
| 460mA||<br>
|-
| IGEP v2 RC3
| 240mA
| 550mA||<br>
|-
| IGEP SOC COM MODULE 3530 4G
| 80mA
| NA| 310mA|
|-
| IGEP SOC COM ELECTRON 3503 1G
| 80mA
| NA| 260mA|
|}
*1: Typical value when power-up with empty flash
 
'''Decrease consumption'''
*Switch off leds:
<pre>
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
</pre>
 
*Switch off WIFI i BT:
<pre>
echo 0 > /sys/class/gpio/gpio139/value
echo 0 > /sys/class/gpio/gpio137/value
</pre>
 
* Slow down CPU frecuency (about 120mA):
<pre>
cpufreq-set -f 300Mhz
</pre>
 
* Hibernate (about 60mA):
<pre>
echo mem > /sys/power/state
</pre>
 
== MMC ==
 
=== #001&nbsp;: 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:
 
{| border="1"
|-
! Test
! &nbsp;2.6.32.25 (PC i5 CPU)&nbsp;
! &nbsp;2.6.35.9 (DM37x)&nbsp;
! &nbsp;2.6.37-5 (DM37x)&nbsp;
! &nbsp;2.6.37-6 (DM37x)&nbsp;
|-
| read
| &nbsp;9.7 MB/s (3m 24.43s)&nbsp;
| &nbsp;13.8 MB/s (2m 22.70s)&nbsp;
| &nbsp;5.5 MB/s (4.0 GB copied, 728.5s, SD Class 6)&nbsp;
| &nbsp;16.2 MB/s (4.0 GB copied, 249.29s, SD Class 6)&nbsp;
|-
| write
| &nbsp;2.0 MB/s (16m 3.68s )&nbsp;
| &nbsp;3.4 MB/s (9m 44.78s)&nbsp;
| &nbsp;2.0 MB/s (4.0 GB copied, 2055.92s, SD Class 6)&nbsp;
| &nbsp;3.0 MB/s (4.0 GB copied, 1356.13s, SD Class 6)&nbsp;
|}
 
'''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&nbsp;: 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:
 
<pre>
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
</pre>
 
=== #001&nbsp;: 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&nbsp;: 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
<pre>#!/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" -&gt; "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 &gt; /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 &gt; /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
</pre>
 
== RAM ==
 
=== #001&nbsp;: 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
 
 
[[Category:Hardware]]
0
edits