= 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.0 |1 | 0x1B7A 0x2B7A E02F
|-
| ES2OMAP35x| ES3.1 |0 | 0x2B7A 0x3B7A E02F
|-
| OMAP35x| ES3.0 |1 | 0x3B7A 0x4B7A E02F
|-
| ES3AM/DM37x| ES1.0| 0x0B89 102F|-| AM/DM37x| ES1.1 |0x1B89 102F|-| AM/DM37x| ES1.2| 0x4B7A E02F0x2B89 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. {| border="1"|-! Platform reference ! Power-up <sup>(1)</sup> ! 2.6.28.y ! 2.6.33.y |-| IGEP v2 RC1 | 240mA | 550mA | <br> |-| IGEP v2 RC2 | 240mA | 460mA | <br> |-| IGEP v2 RC3 | 240mA | 550mA | <br> |-| 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:<pre>echo 0 > /sys/devices/platform/leds-gpio/leds/d210\:green/brightnessecho 0 > /sys/devices/platform/leds-gpio/leds/d210\:red/brightnessecho 0 > /sys/devices/platform/leds-gpio/leds/d440\:green/brightnessecho 0 > /sys/devices/platform/leds-gpio/leds/d440\:red/brightness</pre> *Switch off WIFI i BT:<pre>echo 0 > /sys/class/gpio/gpio139/valueecho 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 : 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 ! 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: <pre>root@igep00x0:~# time dd if=/dev/mtd2 of=/dev/null1022976+0 records in1022976+0 records out real 1m21.901suser 0m0.453ssys 1m21.406s</pre> === #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 <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" -> "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=4MTD_TESTS="mtd_oobtest mtd_pagetest mtd_readtest mtd_speedtest mtd_stresstest mtd_subpagetest mtd_torturetest" # Assure all mtd test modules are removedmodprobe -r ${MTD_TESTS} # Run test suitefor 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 ;; esacdone # Remove all mtd test modulesmodprobe -r ${MTD_TESTS} exit 0</pre> == 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 [[Category:Hardware]]