http://www.embedded.com/design/debug-and-optimization/4398519/Mastering-stack-and-heap-for-system-reliability--Part-3--Avoiding-heap-errors
Friday, February 21, 2014
Wednesday, February 12, 2014
Wednesday, November 6, 2013
Android 4.3 wfd command line(Wi-fi Display/ Miracast )
Below are steps the steps to run wfd source and sink from android 4.3 command line.
PATH of wi-fi display on android is "frameworks/av/media/libstagefright/wifi-display" after build it creates libstagefright_wfd.so library and wfd binary
1) Android 4.3 wfd contains only source, sink code is available on MR2 merge the sink code from MR2 to MR3.
2) In Sink code replace ISurfaceTexture to IGraphicBufferProducer to fix compilation issue.
3)Merge wfd.cpp to for sink changes.
3)Merge wfd.cpp to for sink changes.
4)OnDisplayConnected of wfd.cpp make the width and height according to the device resolution.
void RemoteDisplayClient::onDisplayConnected{
.......
SurfaceComposerClient::openGlobalTransaction();
mComposerClient->setDisplaySurface(mDisplayBinder, mSurfaceTexture);
mComposerClient->setDisplayLayerStack(mDisplayBinder, 0) ;
Rect layerStackRect(width, height);
Rect displayRect(2560,1600);// make the resolution change according to the display this is manta resolution
mComposerClient->setDisplayProjection(
mDisplayBinder, 0 /* 0 degree rotation */,
displayRect,
layerStackRect);
mComposerClient->setDisplaySurface(mDisplayBinder, mSurfaceTexture);
mComposerClient->setDisplayLayerStack(mDisplayBinder, 0) ;
Rect layerStackRect(width, height);
Rect displayRect(2560,1600);// make the resolution change according to the display this is manta resolution
mComposerClient->setDisplayProjection(
mDisplayBinder, 0 /* 0 degree rotation */,
displayRect,
layerStackRect);
......
}
1. Connect two Android >= 4.3 devices to Wi-Fi network.
2. Execute Source
Connect your device to PC via usb(adb).$ adb shell netcfg
wlan0 UP 192.168.1.2/24 0x00001043 12:34:56:78:90:ab <-- your device IP address.
$ adb shell wfd -l 192.168.1.2:20000
3. Execute Sink
Connect another device to PC via usb(adb).$ adb shell netcfg
wlan0 UP 192.168.1.3/24 0x00001043 ab:90:78:56:34:12 <-- your device IP address.
$ adb shell wfd -c 192.168.1.2:20000 <-- Source device IP Address != your device IP address
Tuesday, September 17, 2013
andrioid app crash debug
How to read crash dump of Android
When porting Android system, sometimes boot fails animating Android logo forever. At the case some critical part failed by some reason. Look at log from logcat. There is crash dump.
The debuggerd generated this crash dump.
I/DEBUG ( 3037): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 3037): Build fingerprint: 'emxx/kmc_kzm9d/kzm9d/:2.2/FRF91/eng.koba.20110221.133144:eng/test-keys' I/DEBUG ( 3037): pid: 3233, tid: 3234 >>> /system/bin/netd <<< I/DEBUG ( 3037): signal 11 (SIGSEGV), fault addr deadbaad I/DEBUG ( 3037): r0 00001728 r1 100ffd7c r2 00000027 r3 00000000 I/DEBUG ( 3037): r4 afd42328 r5 00000000 r6 00000000 r7 00011000 I/DEBUG ( 3037): r8 00100000 r9 aef01cad 10 10000000 fp 40008008 I/DEBUG ( 3037): ip ffffffff sp 100ffd68 lr deadbaad pc afd11ca4 cpsr 40000030 I/DEBUG ( 3037): d0 3d454d414e564544 d1 6164732f7665642f I/DEBUG ( 3037): d2 65766972642d693d d3 3a302d6273752d64 I/DEBUG ( 3037): d4 652d6d726f667461 d5 696368652d78786d I/DEBUG ( 3037): d6 2d7265766972642d d7 2e313a302d627375 I/DEBUG ( 3037): d8 0000000000000000 d9 0000000000000000 I/DEBUG ( 3037): d10 0000000000000000 d11 0000000000000000 I/DEBUG ( 3037): d12 0000000000000000 d13 0000000000000000 I/DEBUG ( 3037): d14 0000000000000000 d15 0000000000000000 I/DEBUG ( 3037): d16 0000000000000000 d17 0000000000000000 I/DEBUG ( 3037): d18 0000000000000000 d19 0000000000000000 I/DEBUG ( 3037): d20 0000000000000000 d21 0000000000000000 I/DEBUG ( 3037): d22 0000000000000000 d23 0000000000000000 I/DEBUG ( 3037): d24 0000000000000000 d25 0000000000000000 I/DEBUG ( 3037): d26 0000000000000000 d27 0000000000000000 I/DEBUG ( 3037): d28 0000000000000000 d29 0000000000000000 I/DEBUG ( 3037): d30 0000000000000000 d31 0000000000000000 I/DEBUG ( 3037): scr 00000000 I/DEBUG ( 3037): I/DEBUG ( 3037): #00 pc 00011ca4 /system/lib/libc.so I/DEBUG ( 3037): #01 pc 0000bdf2 /system/lib/libc.so I/DEBUG ( 3037): #02 pc 0000cd52 /system/lib/libc.so I/DEBUG ( 3037): #03 pc 00002770 /system/lib/libsysutils.so I/DEBUG ( 3037): #04 pc 0000279c /system/lib/libsysutils.so I/DEBUG ( 3037): #05 pc 0000253a /system/lib/libsysutils.so I/DEBUG ( 3037): #06 pc 00001b16 /system/lib/libsysutils.so I/DEBUG ( 3037): #07 pc 00001cae /system/lib/libsysutils.so I/DEBUG ( 3037): #08 pc 00010ee0 /system/lib/libc.so I/DEBUG ( 3037): #09 pc 000109d0 /system/lib/libc.so I/DEBUG ( 3037): I/DEBUG ( 3037): code around pc: I/DEBUG ( 3037): afd11c84 2d00682d e029d1fb b12b68db c05cf8df I/DEBUG ( 3037): afd11c94 f8442001 4798000c e054f8df 26002227 I/DEBUG ( 3037): afd11ca4 2000f88e eecaf7fb f7fc2106 f04feff8 I/DEBUG ( 3037): afd11cb4 91035180 460aa901 96012006 f7fc9602 I/DEBUG ( 3037): afd11cc4 a905eb6e 20024632 eb78f7fc eeb6f7fb I/DEBUG ( 3037): I/DEBUG ( 3037): code around lr: I/DEBUG ( 3037): deadba8c ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 3037): deadba9c ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 3037): deadbaac ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 3037): deadbabc ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 3037): deadbacc ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 3037): I/DEBUG ( 3037): stack: I/DEBUG ( 3037): 100ffd28 00000000 I/DEBUG ( 3037): 100ffd2c 00000000 I/DEBUG ( 3037): 100ffd30 00000000 I/DEBUG ( 3037): 100ffd34 00000000 I/DEBUG ( 3037): 100ffd38 00000000 I/DEBUG ( 3037): 100ffd3c afd10290 /system/lib/libc.so I/DEBUG ( 3037): 100ffd40 afd43724 /system/lib/libc.so I/DEBUG ( 3037): 100ffd44 0000001b I/DEBUG ( 3037): 100ffd48 00012850 [heap] I/DEBUG ( 3037): 100ffd4c 4000805e I/DEBUG ( 3037): 100ffd50 100ffd7c I/DEBUG ( 3037): 100ffd54 afd42328 /system/lib/libc.so I/DEBUG ( 3037): 100ffd58 00000000 I/DEBUG ( 3037): 100ffd5c 100ffd7c I/DEBUG ( 3037): 100ffd60 df002777 I/DEBUG ( 3037): 100ffd64 e3a070ad I/DEBUG ( 3037): #00 100ffd68 afd438dc /system/lib/libc.so I/DEBUG ( 3037): 100ffd6c afd103ac /system/lib/libc.so I/DEBUG ( 3037): 100ffd70 afd42328 /system/lib/libc.so I/DEBUG ( 3037): 100ffd74 aef04178 /system/lib/libsysutils.so I/DEBUG ( 3037): 100ffd78 000123e0 [heap] I/DEBUG ( 3037): 100ffd7c fffffbdf I/DEBUG ( 3037): 100ffd80 afd42328 /system/lib/libc.so I/DEBUG ( 3037): 100ffd84 afd43724 /system/lib/libc.so I/DEBUG ( 3037): 100ffd88 000123e0 [heap] I/DEBUG ( 3037): 100ffd8c afd0bdf7 /system/lib/libc.so I/DEBUG ( 3037): #01 100ffd90 00012850 [heap] I/DEBUG ( 3037): 100ffd94 afd1d595 /system/lib/libc.so I/DEBUG ( 3037): 100ffd98 000013fc I/DEBUG ( 3037): 100ffd9c aef04178 /system/lib/libsysutils.so I/DEBUG ( 3037): 100ffda0 00012348 [heap] I/DEBUG ( 3037): 100ffda4 00012348 [heap] I/DEBUG ( 3037): 100ffda8 aef04178 /system/lib/libsysutils.so I/DEBUG ( 3037): 100ffdac 40008008 I/DEBUG ( 3037): 100ffdb0 00000360 I/DEBUG ( 3037): 100ffdb4 afd0cd55 /system/lib/libc.so/system/bin/netd caused SEGV(egmentation fault). The address was 0xdeadbaad.
This is immediate analysis. Next, you want to know which route the problem come through, don’t you?
It is in the stacktrace. Look at this.
I/DEBUG ( 3037): #00 pc 00011ca4 /system/lib/libc.so I/DEBUG ( 3037): #01 pc 0000bdf2 /system/lib/libc.so I/DEBUG ( 3037): #02 pc 0000cd52 /system/lib/libc.so I/DEBUG ( 3037): #03 pc 00002770 /system/lib/libsysutils.so ...This means that SEGV occuerd at the instruction offseted 0x00011ca4 in /system/lib/libc.so and that is called from one offseted 0x000bdf2 in the same libc.so.
Then, called from offseted 0x0000cd52 in libc.so, called from offset 0×00002770 in /system/lib/libsysutils.so.
Next step, Let’s find where are these instructions in the source code. objdump command show us.
At first, move to the directory where object file with debug information are. In the case of KZM-A9-Dual,
$ cd $(ANDROID_TOP)/out/target/product/kmz9d/symbols/system/libThe object files here have information which maps addresses and source code lines.
$ arm-eabi-objdump -S libc.so |lessPut -S option to objdump command to show disasemble with source code.
Then search string “11ca4″, and investigate what was doing there.
/* temporary, for bug hunting */
/* seg fault seems to produce better debuggerd results than SIGABRT */
*((char*)0xdeadbaad) = 39;
11ca4: f88e 2000 strb.w r2, [lr]
/* -- */
Oh, this code intentionaly write immediate value 39 to address
0xdeadbaad to cause SEGV. And you find this is in
bionic/libc/unistd/abort.cIn the same manner, search string “bdf2″ in libc.so.
bdec: 2300 movs r3, #0
bdee: 6183 str r3, [r0, #24]
bdf0: e001 b.n bdf6 <dlfree+0x532>
check_free_chunk(fm, p);
goto postaction;
}
}
erroraction:
USAGE_ERROR_ACTION(fm, p);
bdf2: f005 ff25 bl 11c40 <abort>
postaction:
POSTACTION(fm);
bdf6: 4907 ldr r1, [pc, #28] (be14 )
bdf8: 1864 adds r4, r4, r1
Surely it calls abort. This is in the function dlfree.Then search string “cd52″.
0000cd3c <free>:
void free(void* mem) {
__libc_malloc_dispatch->free(mem);
cd3c: 4b06 ldr r3, [pc, #24] (cd58 <free+0x1c>)
cd3e: bf00 nop
cd40: a100 add r1, pc, #0 (adr r1, cd44
)
cd42: 4a06 ldr r2, [pc, #24] (cd5c <free+0x20>)
cd44: 185b adds r3, r3, r1
cd46: b510 push {r4, lr}
cd48: f853 c002 ldr.w ip, [r3, r2]
cd4c: f8dc 1000 ldr.w r1, [ip]
cd50: 684b ldr r3, [r1, #4]
cd52: 4798 blx r3
}
cd54: bd10 pop {r4, pc}
cd56: bf00 nop
cd58: 000355e4 .word 0x000355e4
cd5c: 00000054 .word 0x00000054
The fuction dlfree is called from free.Let’s sail up the river more. Do objdump libsysutils.so. This library is written in C++, put -C option to objdump to demangle C++ symboles.
$ arm-eabi-objdump -S -C libsysutils.so |less“2770″ is not found. But found near address.
(Offset 0c00002770 is middle of instruction. I think this is bug of stack trace. 4byte instruction of Thumb2 seems to be not considered.)
NetlinkEvent::~NetlinkEvent() {
276a: 6022 str r2, [r4, #0]
int i;
if (mPath)
276c: b108 cbz r0, 2772 <NetlinkEvent::~NetlinkEvent()+0x1e>
free(mPath);
276e: f7ff e848 blx 1800 <SocketListener::sendBroadcast(char const*)-0xc>
if (mSubsystem)
2772: 6920 ldr r0, [r4, #16]
2774: b108 cbz r0, 277a <NetlinkEvent::~NetlinkEvent()+0x26>
free(mSubsystem);
2776: f7ff e844 blx 1800 <SocketListener::sendBroadcast(char const*)-0xc>
277a: 2500 movs r5, #0
free(mPath) is used in the deconstractor of NetlinkEvent. Probabley mPath has illegal value.So then, using these information you can find what triggered this problem.
Let’s summarize.
NetlinkEvent::~NetlinkEvent() :free(mPath);
free
dlfree
abort
(SEGV here.)
Took from
http://kobablog.wordpress.com/2011/05/14/how-to-read-crash-dump-of-android/
Wednesday, April 17, 2013
Starting and Stopping Executable from Android Framework.
1)Add the service in the ini.rc of android source and build it.
The Path of init.rc in the JB source it will be
android_src/device/...
service testservice /system/bin/testservice
class main
disabled
oneshot
2) Starting Service:
Framework to Native code communication is done in JNI, in JNI method add this
code to start service:
char testservice_status[PROPERTY_VALUE_MAX] = {'\0'};
property_set("ctl.start", "testservice');
sched_yield();
usleep(100000);
if (property_get( "init.svc.testservice", testservice_status, NULL)) {
if (strcmp(testservice_status, "running") == 0)
return 0;
}
usleep(100000);
3)Stopping Service:
/* Check whether service already stopped */
if (property_get(init.svc.testservice, testservice_status, NULL)
&& strcmp(testservice_status, "stopped") == 0) {
return status;
}
property_set("ctl.stop", "testservice");
sched_yield();
while (count-- > 0) {
if (property_get("init.svc.testservice", testservice_status, NULL)) {
if (strcmp(testservice_status, "stopped") == 0)
return status;
}
usleep(100000);
}
Without compiling the code Start and Stop service can be verfied by setprop and getprop functionality through adb shell.
1)Add the service in the ini.rc of android source and build it.
The Path of init.rc in the JB source it will be
android_src/device/...
service testservice /system/bin/testservice
class main
disabled
oneshot
2) Starting Service:
Framework to Native code communication is done in JNI, in JNI method add this
code to start service:
char testservice_status[PROPERTY_VALUE_MAX] = {'\0'};
property_set("ctl.start", "testservice');
sched_yield();
usleep(100000);
if (property_get( "init.svc.testservice", testservice_status, NULL)) {
if (strcmp(testservice_status, "running") == 0)
return 0;
}
usleep(100000);
3)Stopping Service:
/* Check whether service already stopped */
if (property_get(init.svc.testservice, testservice_status, NULL)
&& strcmp(testservice_status, "stopped") == 0) {
return status;
}
property_set("ctl.stop", "testservice");
sched_yield();
while (count-- > 0) {
if (property_get("init.svc.testservice", testservice_status, NULL)) {
if (strcmp(testservice_status, "stopped") == 0)
return status;
}
usleep(100000);
}
Without compiling the code Start and Stop service can be verfied by setprop and getprop functionality through adb shell.
Tuesday, March 26, 2013
Thursday, January 24, 2013
SD Host vs. SPI Comparison
Page 1
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
SD Host vs. SPI Comparison
This report is intended to provide a comparison between a utilizing a generic SPI Host and a fullfeatured
SD/SDIO/MMC Host for integrating SD Card / device functionality into an Altera NIOS‐based
platform using uClinux as an OS. Engineers and system integrators can benefit from learning of some of
the advantages and drawbacks with the various approaches available in integrating an SD Host into their
platform.
SD Protocol Overview
The SD/SDIO Protocol (current spec 2.0) is a high‐speed serial protocol used primarily for interfacing
with SD (SecureDigital) Flash memory cards. SDIO, a specification based on SD, can be used to interface
with devices such as Wireless ICs. This paper will mainly focus on the SD protocol and interfacing with
flash memory. It should also be noted that the SD Protocol is largely based on the MultiMediaCard
(MMC) format, although some mechanical differences exist. For the purpose of this report, they can be
treated equally.
The first revision of the SD Protocol supported only up to 4GB of data in a flash memory card. With
the advent of SDHC (2.0), capacities of up to 32 GB (2TB theoretical) can be supported. On a physical
level, SDHC is equivalent to SD 1.0. The changes mostly exist in the block/MAC‐level of the protocol.
The table below outlines the various signals used when interfacing with an SD device. Different
operating modes utilize the signals in different ways.
SD Mode (1 and 4‐bit) SPI Mode
Name Type Description Name Type Description
CMD Bidir. Command/Response DI Input Data In
CLK Input Clock SCLK Input Clock
DAT[0] Bidir. Data Line 0 DO Output Data Out
DAT[1] Bidir. Data Line 1 RSV ‐ ‐
DAT[2] Bidir. Data Line 2 RSV ‐ ‐
DAT[3] Bidir. Data Line 3 CS Input Chip‐select
There are 3 fundamental modes that the SD Physical layer can operate in:
1. 4‐bit SD DAT Mode
2. 1‐bit SD DAT Mode
3. SPI‐Mode
All modes of transport only dictate the physical layer operation; the block layer of the interface
remains the same regardless of transport mode used. All modes of operation can be clocked up to
25MHz in standard‐speed mode, or 50 MHz in high‐speed mode.
Page 2
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
1 and 4‐bit SD DAT Mode
The 1 and 4‐bit SD DAT Modes differ only by the number of data lines used. The 4‐bit mode allows
the host to utilize all four of the SD Data lines, thereby increasing throughput significantly. In SD Mode,
all command/response tokens are sent over the CMD line. The DAT lines are reserved for data blocks. All
command/response tokens are required to be protected with a 7‐bit CRC, and the Data blocks with a 16‐
bit CRC (both based on CCITT polynomials).
In SD Mode, the DAT signals are also used for three additional functions. 1) To implement wait
states from the device to the host, 2) To indicate successful reception of data blocks on write
operations, and 2) To signal interrupts from the device to the host. Wait states are useful when writing
large data blocks to an SD Device for example. In the event that the write‐buffers on the card are full,
the device can indicate it is busy through special signaling on the DAT line. This eliminates the need for
un‐necessary polling. On reception of data blocks that are being written to the device, the device will
calculate and verify the CRC of the data in real‐time, and report the status on the DAT lines as well. This
allows the host to terminate or re‐issue a write block transaction if the device reports a CRC error.
SPI Mode
SPI Mode utilizes the popular Serial Peripheral Interface Bus (SPI). This bus contains clock, chipselect,
data‐in and data‐out signals. Most microcontrollers/processors come with a host SPI port, or a
variant, allowing for easy interfacing. In addition, several low‐end microcontrollers also support a SPI
port due to its low resource requirements.
With SPI Mode, all command/response tokens are transmitted over the Data‐in / Data‐out pins.
There is no separate line for command/response. Once command/response tokens have been
transmitted, data blocks are also transmitted on the same lines. CRC protection is also specified using
SPI, however, it is disabled by default and uses a weak CRC protection scheme since most SPI Hosts do
not have built in CRC generation.
Test Setup
Hardware
The Nios II Evaluation Kit from Altera (aka: NEEK) is the platform used for evaluating performance of
an SD Host versus SPI Host. The kit features 32 MB DDR RAM, a Cyclone III FPGA, and SD Slot.
Unfortunately, the NEEK only supports 1‐bit SD DAT Mode since all 4 Data signals are not connected to
the FPGA.
The FPGA Projects used were:
• FPS‐Tech SD Host Evaluation project; used for testing the FPS‐Tech SD Host controller.
Datasheet can be found here.
• neek_ocm_spi test project located on the NIOS Wiki; used for testing the performance in SPI
Mode. Project uses Altera SPI Host controller. Datasheet can be found here.
SD Host Overview
A brief description of the SD Hosts used will be outlined in this section. The FPS‐Tech SD Host
controller is a high‐performance SD Host designed specifically for Altera NIOS‐based platforms. The host
has a number of features that dramatically improve performance in uClinux environments. Due to the
Page 3
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
relatively low clock speeds that the NIOS can run at, the SD Host tries to offload as much work as
possible to free up the processor for other tasks. Some of the features of the host include:
• Full support for 1 and 4‐bit DAT Modes
• Integrated card‐detect and write‐protect pins with filters
• Open‐source uClinux driver, available on public upstream repository
• Powerful integrated DMA engine backpressure and pre‐fetching support to tackle highlatency
memory sub‐systems (such as DDR)
• Support for SDHC flash cards
• Deep read and write FIFOs to ensure maximal physical‐layer transfer rate
• DMA engine designed specifically to maximize Altera Avalon’s interconnect architecture
features
• Integrated 7‐bit and 16‐bit CCITT CRC generation
• Detailed profiling registers included to identify any potential bottlenecks in system
• External busy signal output for busy indication
The SPI host controller used was a standard Altera SPI Host. The host allows for different data byte
sizes, but does not have any DMA or CRC capabilities since it is a standard SPI Host. The Altera SPI host is
also supported by the upstream uClinux distribution through an open‐source driver.
Software
uClinux 2.6.26 and 2.6.27 were used as the kernel revisions for benchmarking the test setups. A
modified version of the disk IO benchmarking utility ‘bonnie’ (information located here) was used to
measure read and write throughput. The utility was modified to remove character based read/write
tests since they are more a measure of the processor performance. The test was run on various file
sizes, although performance maintained relatively constant across different test cases.
In addition to measuring read/write performance, interrupt statistics and profiling registers were
also monitored to obtain additional information about the tests. This test is as much of a software driver
test as it is a SD Host test since driver interaction with the kernel can heavily influence the results. Since
most system integrators will be considering uClinux to interface with SD memory, the system consisting
of the driver and SD Host will be treated as one.
Page 4
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
Test Setup Summary
The test‐setup for the SPI‐based host is given in the table below:
Test Setup
Date 9/14/2008
Hardware Platform NEEK
CPU / MEM Configuration 100 MHz CPU / 66.5 MHz, 32 MB DDR
FPGA Project neek_ocm_spi
SD Controller
Type Altera Standard SPI Controller
Version Quartus 8.0
PHY Interface Mode / Speed 1‐bit SPI Mode / 15.0 MHz
Linux Kernel / Driver
Kernel Version 2.6.27‐rc6
Driver Configuration No bounce buffer
SD Card
Brand Ultra SecureDigital Card
Size 1 GB
The test setup for the FPS‐Tech SD Host is given in the table below:
Test Setup
Date 7/9/2008
Hardware Platform NEEK
CPU / MEM Configuration 87.5MHz, 32 MB DDR
FPGA Project uclinux_sdio_test
SD Controller
Type FPS‐Tech SD/SDIO/MMC Host
Version 1.1
PHY Interface Mode / Speed 21MHz / 1‐bit
Linux Kernel / Driver
Kernel Version 2.6.26‐rc9
Driver Configuration No bounce buffer, max_blk_count = 8,
max_seg_size = max_req_size = 4096
SD Card
Brand Ultra Secure Digital Card
Size 1 GB
Page 5
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
Benchmark Results
SPI Host Results
Test Configuration
File Size 50 MB
Write Stats
Block Output 75 KB/s, 3.2% CPU
Driver Interrupts <Independent Read/write interrupts not available>
XFER_LEN / BUSY_LEN / BUS_LEN <Stats not available for SPI Core>
Read Stats
Block Input 69 KB/s, 1.1% CPU
Driver Interrupts 110,591,051 (read+write)
XFER_LEN / BUSY_LEN / BUS_LEN 24 minutes for read+write
Test Configuration
File Size 250 MB
Write Stats
Block Output 74 KB/s, 3.3% CPU
Driver Interrupts <Independent Read/write interrupts not available>
XFER_LEN / BUSY_LEN / BUS_LEN <Stats not available for SPI Core>
Read Stats
Block Input 69 KB/s, 1.1% CPU
Driver Interrupts 553,209,715 (read+write)
XFER_LEN / BUSY_LEN / BUS_LEN 1h 58m for read+write
Page 6
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
FPS‐Tech SD Host Results
Test Configuration
File Size 50 MB
Write Stats
Block Output 1464 KB/s, 39% CPU
Driver Interrupts 53,157
XFER_LEN / BUSY_LEN / BUS_LEN 22 /3/0
Read Stats
Block Input 1737 KB/s, 18.4% CPU
Driver Interrupts 26,031
XFER_LEN / BUSY_LEN / BUS_LEN 21 /2/0
Test Configuration
File Size 250 MB
Write Stats
Block Output 1410 KB/s, 39% CPU
Driver Interrupts 271,021
XFER_LEN / BUSY_LEN / BUS_LEN 120/19/2
Read Stats
Block Input 1739 KB/s, 18.5% CPU
Driver Interrupts 130,188
XFER_LEN / BUSY_LEN / BUS_LEN 109/12/0
Note: The XFER_LEN/BUSY_LEN/BUS_LEN numbers are all given in ‘seconds’ units. For details on these
parameters, please refer to the FPS‐Tech SD Host datasheet.
Page 7
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
Summary and Conclusions
Using the results available in the benchmarking and protocol information sections, one should be
able to determine which SD Host (SPI or full‐featured SD‐host) suits their application best. While it is
clear that the FPS‐Tech SD‐host provides a very large increase in throughput, this may or may not be the
sole requirement of the application at hand.
The table below summarizes the advantages/disadvantages of both approaches is given below.
Item SPI Host FPS‐Tech SD Host
Logic Footprint Very small logic footprint inside the
FPGA (<200 LEs) due to simple logic.
Larger footprint; around 2,000 LEs are
required to implement the full 4‐bit SD
Host
Memory Footprint Requires no on‐chip memory inside
FPGA
Required 1 M9K of on‐chip memory
for read/write FIFO
Throughput Very low performance due to bytelevel
interaction between driver and
host
Highest throughput possible due to
integrated DMA engine, block prefetching
schemes and full 4‐bit DAT
interface
Driver Size Slightly more complicated driver due
to byte‐level interaction between
driver and host
Simple driver since most functionality
is offloaded onto SD Host IP.
Cost SPI Host and driver are free from
Altera
Driver is free open‐source, but SD Host
IP requires a one‐time fee (no royalty)
Protocol Usage SPI Host utilizes the simpler SPI
mode of the SD protocol
Full 4‐bit DAT in SD Mode utilized,
with optional 1‐bit mode if desired
Processor/OS
Overhead
Significant processor overhead
incurred due to large number of
interrupts (byte‐level processing)
Very‐low processor overhead since
transactions are handled on a multi
block‐basis by the Host IP
Driver Availability Driver is integrated into upstream
distribution, open‐source, supported
by NIOS Community
Driver is integrated into upstream
distribution, open‐source, supported
by FPS‐Tech
Device‐side interrupts SPI Mode does not support Deviceside
interrupts
Full support for generation of
interrupts from device side
Busy Indication SPI Mode does not support wait
state signaling from device side
Full support for wait states from
device, eliminating need for polling
CRC
Generation/Verification
SPI Mode supports CRC, but is
disabled by default. The Altera SPI
Host does not support hardware
generation of CRCs
Generation and verification of both 7
and 16‐ bit CCITT CRCs are performed
automatically
In conclusion, both host options offers their own distinct advantages that system integrators need
to consider when choosing the right host. The SPI Mode host is a free, simple and effective way to
implement SD functionality into a system if performance is not a requirement. In the event that
throughput and processor overhead are of concern, going with the full‐featured SD Host by FPS‐Tech
will offer numerous advantages. If the target application requires as many CPU cycles as possible to be
dedicated for other applications, the FPS‐Tech SD Host will allow this since the bulk of the SD Host
interfacing is offloaded into hardware.
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
SD Host vs. SPI Comparison
This report is intended to provide a comparison between a utilizing a generic SPI Host and a fullfeatured
SD/SDIO/MMC Host for integrating SD Card / device functionality into an Altera NIOS‐based
platform using uClinux as an OS. Engineers and system integrators can benefit from learning of some of
the advantages and drawbacks with the various approaches available in integrating an SD Host into their
platform.
SD Protocol Overview
The SD/SDIO Protocol (current spec 2.0) is a high‐speed serial protocol used primarily for interfacing
with SD (SecureDigital) Flash memory cards. SDIO, a specification based on SD, can be used to interface
with devices such as Wireless ICs. This paper will mainly focus on the SD protocol and interfacing with
flash memory. It should also be noted that the SD Protocol is largely based on the MultiMediaCard
(MMC) format, although some mechanical differences exist. For the purpose of this report, they can be
treated equally.
The first revision of the SD Protocol supported only up to 4GB of data in a flash memory card. With
the advent of SDHC (2.0), capacities of up to 32 GB (2TB theoretical) can be supported. On a physical
level, SDHC is equivalent to SD 1.0. The changes mostly exist in the block/MAC‐level of the protocol.
The table below outlines the various signals used when interfacing with an SD device. Different
operating modes utilize the signals in different ways.
SD Mode (1 and 4‐bit) SPI Mode
Name Type Description Name Type Description
CMD Bidir. Command/Response DI Input Data In
CLK Input Clock SCLK Input Clock
DAT[0] Bidir. Data Line 0 DO Output Data Out
DAT[1] Bidir. Data Line 1 RSV ‐ ‐
DAT[2] Bidir. Data Line 2 RSV ‐ ‐
DAT[3] Bidir. Data Line 3 CS Input Chip‐select
There are 3 fundamental modes that the SD Physical layer can operate in:
1. 4‐bit SD DAT Mode
2. 1‐bit SD DAT Mode
3. SPI‐Mode
All modes of transport only dictate the physical layer operation; the block layer of the interface
remains the same regardless of transport mode used. All modes of operation can be clocked up to
25MHz in standard‐speed mode, or 50 MHz in high‐speed mode.
Page 2
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
1 and 4‐bit SD DAT Mode
The 1 and 4‐bit SD DAT Modes differ only by the number of data lines used. The 4‐bit mode allows
the host to utilize all four of the SD Data lines, thereby increasing throughput significantly. In SD Mode,
all command/response tokens are sent over the CMD line. The DAT lines are reserved for data blocks. All
command/response tokens are required to be protected with a 7‐bit CRC, and the Data blocks with a 16‐
bit CRC (both based on CCITT polynomials).
In SD Mode, the DAT signals are also used for three additional functions. 1) To implement wait
states from the device to the host, 2) To indicate successful reception of data blocks on write
operations, and 2) To signal interrupts from the device to the host. Wait states are useful when writing
large data blocks to an SD Device for example. In the event that the write‐buffers on the card are full,
the device can indicate it is busy through special signaling on the DAT line. This eliminates the need for
un‐necessary polling. On reception of data blocks that are being written to the device, the device will
calculate and verify the CRC of the data in real‐time, and report the status on the DAT lines as well. This
allows the host to terminate or re‐issue a write block transaction if the device reports a CRC error.
SPI Mode
SPI Mode utilizes the popular Serial Peripheral Interface Bus (SPI). This bus contains clock, chipselect,
data‐in and data‐out signals. Most microcontrollers/processors come with a host SPI port, or a
variant, allowing for easy interfacing. In addition, several low‐end microcontrollers also support a SPI
port due to its low resource requirements.
With SPI Mode, all command/response tokens are transmitted over the Data‐in / Data‐out pins.
There is no separate line for command/response. Once command/response tokens have been
transmitted, data blocks are also transmitted on the same lines. CRC protection is also specified using
SPI, however, it is disabled by default and uses a weak CRC protection scheme since most SPI Hosts do
not have built in CRC generation.
Test Setup
Hardware
The Nios II Evaluation Kit from Altera (aka: NEEK) is the platform used for evaluating performance of
an SD Host versus SPI Host. The kit features 32 MB DDR RAM, a Cyclone III FPGA, and SD Slot.
Unfortunately, the NEEK only supports 1‐bit SD DAT Mode since all 4 Data signals are not connected to
the FPGA.
The FPGA Projects used were:
• FPS‐Tech SD Host Evaluation project; used for testing the FPS‐Tech SD Host controller.
Datasheet can be found here.
• neek_ocm_spi test project located on the NIOS Wiki; used for testing the performance in SPI
Mode. Project uses Altera SPI Host controller. Datasheet can be found here.
SD Host Overview
A brief description of the SD Hosts used will be outlined in this section. The FPS‐Tech SD Host
controller is a high‐performance SD Host designed specifically for Altera NIOS‐based platforms. The host
has a number of features that dramatically improve performance in uClinux environments. Due to the
Page 3
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
relatively low clock speeds that the NIOS can run at, the SD Host tries to offload as much work as
possible to free up the processor for other tasks. Some of the features of the host include:
• Full support for 1 and 4‐bit DAT Modes
• Integrated card‐detect and write‐protect pins with filters
• Open‐source uClinux driver, available on public upstream repository
• Powerful integrated DMA engine backpressure and pre‐fetching support to tackle highlatency
memory sub‐systems (such as DDR)
• Support for SDHC flash cards
• Deep read and write FIFOs to ensure maximal physical‐layer transfer rate
• DMA engine designed specifically to maximize Altera Avalon’s interconnect architecture
features
• Integrated 7‐bit and 16‐bit CCITT CRC generation
• Detailed profiling registers included to identify any potential bottlenecks in system
• External busy signal output for busy indication
The SPI host controller used was a standard Altera SPI Host. The host allows for different data byte
sizes, but does not have any DMA or CRC capabilities since it is a standard SPI Host. The Altera SPI host is
also supported by the upstream uClinux distribution through an open‐source driver.
Software
uClinux 2.6.26 and 2.6.27 were used as the kernel revisions for benchmarking the test setups. A
modified version of the disk IO benchmarking utility ‘bonnie’ (information located here) was used to
measure read and write throughput. The utility was modified to remove character based read/write
tests since they are more a measure of the processor performance. The test was run on various file
sizes, although performance maintained relatively constant across different test cases.
In addition to measuring read/write performance, interrupt statistics and profiling registers were
also monitored to obtain additional information about the tests. This test is as much of a software driver
test as it is a SD Host test since driver interaction with the kernel can heavily influence the results. Since
most system integrators will be considering uClinux to interface with SD memory, the system consisting
of the driver and SD Host will be treated as one.
Page 4
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
Test Setup Summary
The test‐setup for the SPI‐based host is given in the table below:
Test Setup
Date 9/14/2008
Hardware Platform NEEK
CPU / MEM Configuration 100 MHz CPU / 66.5 MHz, 32 MB DDR
FPGA Project neek_ocm_spi
SD Controller
Type Altera Standard SPI Controller
Version Quartus 8.0
PHY Interface Mode / Speed 1‐bit SPI Mode / 15.0 MHz
Linux Kernel / Driver
Kernel Version 2.6.27‐rc6
Driver Configuration No bounce buffer
SD Card
Brand Ultra SecureDigital Card
Size 1 GB
The test setup for the FPS‐Tech SD Host is given in the table below:
Test Setup
Date 7/9/2008
Hardware Platform NEEK
CPU / MEM Configuration 87.5MHz, 32 MB DDR
FPGA Project uclinux_sdio_test
SD Controller
Type FPS‐Tech SD/SDIO/MMC Host
Version 1.1
PHY Interface Mode / Speed 21MHz / 1‐bit
Linux Kernel / Driver
Kernel Version 2.6.26‐rc9
Driver Configuration No bounce buffer, max_blk_count = 8,
max_seg_size = max_req_size = 4096
SD Card
Brand Ultra Secure Digital Card
Size 1 GB
Page 5
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
Benchmark Results
SPI Host Results
Test Configuration
File Size 50 MB
Write Stats
Block Output 75 KB/s, 3.2% CPU
Driver Interrupts <Independent Read/write interrupts not available>
XFER_LEN / BUSY_LEN / BUS_LEN <Stats not available for SPI Core>
Read Stats
Block Input 69 KB/s, 1.1% CPU
Driver Interrupts 110,591,051 (read+write)
XFER_LEN / BUSY_LEN / BUS_LEN 24 minutes for read+write
Test Configuration
File Size 250 MB
Write Stats
Block Output 74 KB/s, 3.3% CPU
Driver Interrupts <Independent Read/write interrupts not available>
XFER_LEN / BUSY_LEN / BUS_LEN <Stats not available for SPI Core>
Read Stats
Block Input 69 KB/s, 1.1% CPU
Driver Interrupts 553,209,715 (read+write)
XFER_LEN / BUSY_LEN / BUS_LEN 1h 58m for read+write
Page 6
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
FPS‐Tech SD Host Results
Test Configuration
File Size 50 MB
Write Stats
Block Output 1464 KB/s, 39% CPU
Driver Interrupts 53,157
XFER_LEN / BUSY_LEN / BUS_LEN 22 /3/0
Read Stats
Block Input 1737 KB/s, 18.4% CPU
Driver Interrupts 26,031
XFER_LEN / BUSY_LEN / BUS_LEN 21 /2/0
Test Configuration
File Size 250 MB
Write Stats
Block Output 1410 KB/s, 39% CPU
Driver Interrupts 271,021
XFER_LEN / BUSY_LEN / BUS_LEN 120/19/2
Read Stats
Block Input 1739 KB/s, 18.5% CPU
Driver Interrupts 130,188
XFER_LEN / BUSY_LEN / BUS_LEN 109/12/0
Note: The XFER_LEN/BUSY_LEN/BUS_LEN numbers are all given in ‘seconds’ units. For details on these
parameters, please refer to the FPS‐Tech SD Host datasheet.
Page 7
SD Host vs. SPI Comparison
FPS‐Tech
Sep. 2008
Summary and Conclusions
Using the results available in the benchmarking and protocol information sections, one should be
able to determine which SD Host (SPI or full‐featured SD‐host) suits their application best. While it is
clear that the FPS‐Tech SD‐host provides a very large increase in throughput, this may or may not be the
sole requirement of the application at hand.
The table below summarizes the advantages/disadvantages of both approaches is given below.
Item SPI Host FPS‐Tech SD Host
Logic Footprint Very small logic footprint inside the
FPGA (<200 LEs) due to simple logic.
Larger footprint; around 2,000 LEs are
required to implement the full 4‐bit SD
Host
Memory Footprint Requires no on‐chip memory inside
FPGA
Required 1 M9K of on‐chip memory
for read/write FIFO
Throughput Very low performance due to bytelevel
interaction between driver and
host
Highest throughput possible due to
integrated DMA engine, block prefetching
schemes and full 4‐bit DAT
interface
Driver Size Slightly more complicated driver due
to byte‐level interaction between
driver and host
Simple driver since most functionality
is offloaded onto SD Host IP.
Cost SPI Host and driver are free from
Altera
Driver is free open‐source, but SD Host
IP requires a one‐time fee (no royalty)
Protocol Usage SPI Host utilizes the simpler SPI
mode of the SD protocol
Full 4‐bit DAT in SD Mode utilized,
with optional 1‐bit mode if desired
Processor/OS
Overhead
Significant processor overhead
incurred due to large number of
interrupts (byte‐level processing)
Very‐low processor overhead since
transactions are handled on a multi
block‐basis by the Host IP
Driver Availability Driver is integrated into upstream
distribution, open‐source, supported
by NIOS Community
Driver is integrated into upstream
distribution, open‐source, supported
by FPS‐Tech
Device‐side interrupts SPI Mode does not support Deviceside
interrupts
Full support for generation of
interrupts from device side
Busy Indication SPI Mode does not support wait
state signaling from device side
Full support for wait states from
device, eliminating need for polling
CRC
Generation/Verification
SPI Mode supports CRC, but is
disabled by default. The Altera SPI
Host does not support hardware
generation of CRCs
Generation and verification of both 7
and 16‐ bit CCITT CRCs are performed
automatically
In conclusion, both host options offers their own distinct advantages that system integrators need
to consider when choosing the right host. The SPI Mode host is a free, simple and effective way to
implement SD functionality into a system if performance is not a requirement. In the event that
throughput and processor overhead are of concern, going with the full‐featured SD Host by FPS‐Tech
will offer numerous advantages. If the target application requires as many CPU cycles as possible to be
dedicated for other applications, the FPS‐Tech SD Host will allow this since the bulk of the SD Host
interfacing is offloaded into hardware.
Subscribe to:
Posts (Atom)