Board validation and diagnostic tools

Revision as of 13:19, 15 April 2014 by Eballetbo (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Revision as of 13:19, 15 April 2014 by Eballetbo (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Contents

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