|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-180973A1-5C0A-5A85-82CC-E6B739A7F207" xml:lang="en"><title>Platform |
|
13 Specific Layer Validation</title><shortdesc>Describes the test code to validate a port of the MMC Controller.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
14 <p>There are three stages involved in testing a port of the MultiMediaCard |
|
15 controller. The first stage tests the controller in isolation; subsequent |
|
16 stages test an additional area of functionality. </p> |
|
17 <p>All three stages involve text shell based test programs and test drivers, |
|
18 and therefore these tests can be run by just building a text shell ROM. You |
|
19 can also run tests on the Emulator. </p> |
|
20 <section id="GUID-AB3EBD9F-49E9-5C9C-ACFB-377997C2A838"><title>Testing the |
|
21 controller in isolation</title> <p> <filepath>MMCTEST.EXE</filepath> tests |
|
22 the MultiMediaCard controller in isolation, at the controller’s client interface |
|
23 level. Since the controller’s client API is a kernel side interface, this |
|
24 requires a test driver, <filepath>D_MMCIF.LDD</filepath>, as well as the test |
|
25 program itself. </p> <p>This is not a 'go/no-go' type test, but is a test |
|
26 utility that can perform a small variety of operations. These are selected |
|
27 a simple interactive way by pressing appropriate keys. </p> <table id="GUID-A5C02651-82A2-57DB-8BCF-D1EF5F72902A"> |
|
28 <tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/> |
|
29 <tbody> |
|
30 <row> |
|
31 <entry><p>Building <filepath>MMCTEST.EXE</filepath> and <filepath>D_MMCIF.LDD</filepath> </p> </entry> |
|
32 <entry><p>The source and header files needed to build <filepath>MMCTEST.EXE</filepath> can |
|
33 be found in <filepath>...\e32utils\pccd</filepath>; the mmp file is <filepath>...\e32utils\group\mmctest.mmp</filepath>. </p> <p>The |
|
34 source and header files needed to build the test driver <filepath>D_MMCIF.LDD</filepath> can |
|
35 be found in <filepath>...\e32utils\pccd</filepath>; the mmp file is <filepath>...\e32utils\group\d_mmcif.mmp</filepath>. </p> <p>You |
|
36 need to build <filepath>MMCTEST.EXE</filepath> for the appropriate CPU target |
|
37 architecture (e.g. ARMI,THUMB etc.); you need to build <filepath>D_MMCIF.LDD</filepath> for |
|
38 the appropriate platform (e.g. MINT). </p> <p>Include both of these components |
|
39 in a ROM </p> </entry> |
|
40 </row> |
|
41 <row> |
|
42 <entry><p>Running the tests </p> </entry> |
|
43 <entry><p>Run MMCTEST and perform the following suggested sequence: </p> <ul> |
|
44 <li id="GUID-3685E0AA-B3D5-5A30-B6FF-04DE7A53EBCF"><p>Without a card inserted, |
|
45 power up the stack by pressing <userinput>P</userinput>, and check that it |
|
46 reports that no card is present. </p> </li> |
|
47 <li id="GUID-BA816CD0-3FA1-54C3-8480-7F82BA338119"><p>Insert a card, power |
|
48 it up, and check that it reports that a card is present. </p> </li> |
|
49 <li id="GUID-29403BEA-814F-5F54-85B1-8E598E67BB72"><p>Now that the card is |
|
50 powered up, read the card info by pressing <userinput>C</userinput>, and check |
|
51 the data returned about the card against the expected card data, by referring |
|
52 to the datasheet for the card. </p> </li> |
|
53 <li id="GUID-7C7542B2-F46A-5183-8256-1E962094A9B7"><p>Read the first sector |
|
54 of the card by pressing <userinput>M</userinput>. </p> </li> |
|
55 <li id="GUID-B6F5D3F1-2CF9-55B3-8EAF-4672EBE9B1A9"><p>Now read a few more |
|
56 sectors by pressing the space bar. </p> </li> |
|
57 <li id="GUID-15FBBB20-8914-566B-A786-BB470312A7D0"><p>Test writing to a sector: |
|
58 while still viewing a sector, edit a part of this, by using the direction |
|
59 keys and typing in a hex number. Now save the change by pressing <userinput>ESC</userinput>, |
|
60 followed by <userinput>Y</userinput>. Now navigate to the same sector again |
|
61 and check that it displays the new contents of the sector. </p> </li> |
|
62 <li id="GUID-23809955-30D3-5B53-85B6-890C75E63957"><p>Quit the test by pressing <userinput>Q</userinput>. </p> </li> |
|
63 </ul> </entry> |
|
64 </row> |
|
65 </tbody> |
|
66 </tgroup> |
|
67 </table> </section> |
|
68 <section id="GUID-9A353066-CE24-5969-B0FD-3F1164ECF3F5"><title>Testing the |
|
69 controller with the media driver and the local media sub-system</title> <ol id="GUID-323C60B8-36B4-5975-AECC-659F68AB560D"> |
|
70 <li id="GUID-97E060B0-8355-54E3-AA35-7FF9B9D59119"><p> <filepath>DRVTEST.EXE</filepath> tests |
|
71 the MultiMediaCard controller in conjunction with the media driver and the |
|
72 local media sub-system, in effect accessing the card as a local drive. This |
|
73 requires a kernel side test driver <filepath>D_DRVIF.LDD</filepath> as well |
|
74 as the test program itself. </p> <p>This is not a 'go/no-go' type test, but |
|
75 is a test utility that can perform a small variety of operations. These are |
|
76 selected a simple interactive way by pressing appropriate keys. It is used |
|
77 to test that card initialization and single block read and write requests |
|
78 are performed successfully. </p> </li> |
|
79 <li id="GUID-BCCDA1BB-7205-5C0D-A0CC-607E44196624"><p> <filepath>T_ATADRV.EXE</filepath> tests |
|
80 that card initialization and simple read and write requests succeed. It also |
|
81 tests multi-block read/write operations, format requests, accessing the device |
|
82 following a media change event, and a machine power down event. </p> <p>This |
|
83 is a 'go/no-go' type test. If this test succeeds, you can have fairly high |
|
84 confidence that the F32 test suite will run successfully. </p> </li> |
|
85 </ol> <table id="GUID-D29E7820-6241-5B6E-B242-4B7037BA7344"> |
|
86 <tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/> |
|
87 <tbody> |
|
88 <row> |
|
89 <entry><p>Building <filepath>DRVTEST.EXE</filepath>, <filepath>D_DRVIF.LDD</filepath>, |
|
90 and <filepath>T_ATADRV.EXE</filepath> </p> </entry> |
|
91 <entry><p>The source and header files needed to build <filepath>DRVTEST.EXE</filepath> can |
|
92 be found in <filepath>...\e32utils\pccd</filepath>; the mmp file is <filepath>...\e32utils\group\drvtest.mmp</filepath>. </p> <p>The |
|
93 source and header files needed to build the test driver <filepath>D_DRVIF.LDD</filepath> can |
|
94 be found in <filepath>...\e32utils\pccd</filepath>; the mmp file is <filepath>...\e32utils\group\d_drvif.mmp</filepath>. </p> <p>The |
|
95 source and header files needed to build <filepath>T_ATADRV.EXE</filepath> can |
|
96 be found in <filepath>...\e32test\pccd</filepath>; the mmp file is <filepath>...\e32test\group\t_atadrv.mmp</filepath>. </p> <p>You |
|
97 need to build <filepath>DRVTEST.EXE</filepath> for the appropriate CPU target |
|
98 architecture (e.g. ARMI,THUMB etc.) </p> <p>You need to build <filepath>D_DRVIF.LDD</filepath> for |
|
99 the appropriate platform (e.g. MINT) </p> <p>You need to build <filepath>T_ATADRV</filepath> for |
|
100 the appropriate CPU target architecture (e.g. ARMI,THUMB). </p> <p>Include |
|
101 these components in a ROM. </p> </entry> |
|
102 </row> |
|
103 <row> |
|
104 <entry><p>Running the DRVTEST test </p> </entry> |
|
105 <entry><p>Run DRVTEST and perform the following suggested sequence: </p> <ul> |
|
106 <li id="GUID-22D82528-84D3-58C8-83F1-63B9D63976D0"><p>Without a card inserted, |
|
107 power up the stack by pressing <userinput>P</userinput>, and check that it |
|
108 reports that no card is present. </p> </li> |
|
109 <li id="GUID-646F1CE2-6F6E-58D1-A097-2675CC0285D6"><p>Insert a card, power |
|
110 it up, and check that it reports that a card is present. </p> </li> |
|
111 <li id="GUID-76B81B73-0F7E-57DE-AEE2-67E03E9422A2"><p>Now that the card is |
|
112 powered up, read the card info by pressing <userinput>C</userinput>, and check |
|
113 the data returned about the card against the expected card data, by referring |
|
114 to the datasheet for the card. </p> </li> |
|
115 <li id="GUID-FD9CC21C-5818-5405-B0BA-B5E5344D715F"><p>Read the first sector |
|
116 of the card by pressing <userinput>M</userinput>. </p> </li> |
|
117 <li id="GUID-B7EF88BE-D2CB-5E8F-844B-47F1A461CC82"><p>Now read a few more |
|
118 sectors by pressing the <userinput>space bar</userinput>. </p> </li> |
|
119 <li id="GUID-96527F35-52E7-5400-AEB1-E7D05D4420C5"><p>Test writing to a sector: |
|
120 while still viewing a sector, edit a part of this, by using the direction |
|
121 keys and typing in a hex number. Now save the change by pressing <userinput>ESC</userinput>, |
|
122 followed by <userinput>Y</userinput>. Now navigate to the same sector again |
|
123 and check that it displays the new contents of the sector. </p> </li> |
|
124 <li id="GUID-D91CFC9A-C544-5E32-BCAE-3B2BA558AF63"><p>Quit the test by pressing <userinput>Q</userinput>. </p> </li> |
|
125 </ul> </entry> |
|
126 </row> |
|
127 <row> |
|
128 <entry><p>Running the T_ATADRV test </p> </entry> |
|
129 <entry><p>Run T_ATADRV and follow the on-screen instructions. Check that the |
|
130 test runs to the end with no errors. </p> </entry> |
|
131 </row> |
|
132 </tbody> |
|
133 </tgroup> |
|
134 </table> </section> |
|
135 <section id="GUID-9AD20A90-0E4D-56BC-A681-833EBD632DF6"><title> Testing using |
|
136 the F32 test suite</title> <p>The final test stage is to run the entire file |
|
137 server test suite on a card drive. </p> <p>To perform these tests: </p> <ul> |
|
138 <li id="GUID-1C50C6E5-E811-5DFE-8814-F4B18648E389"><p>build a text shell ROM |
|
139 that contains the F32 test suite, i.e. build the ROM with the option: </p> <codeblock id="GUID-892CC775-89C7-5B48-AE44-5D63E7A030FD" xml:space="preserve">-t=f32tests</codeblock> </li> |
|
140 <li id="GUID-2A5BE4AA-9762-525F-9391-D839153C41F5"><p>boot the test machine |
|
141 into the text shell. </p> </li> |
|
142 <li id="GUID-C9A22A2C-58F6-59A4-BB85-6D69703520F9"><p>launch the F32 automatic |
|
143 tests and check that all of the tests run without error. Use the command option |
|
144 "-d" to set the default drive, for example: </p> <codeblock id="GUID-08A2E18B-7CA8-5124-B46E-88311D468C4E" xml:space="preserve">RUNTESTS F32TEST.AUTO.ARMI.BAT -d d</codeblock> </li> |
|
145 </ul> </section> |
|
146 <section id="GUID-57378A6B-B5FB-5EFF-9FD4-6F948B5F20D1"><title>Emulator-based |
|
147 tests</title> <p>It is possible to emulate a user opening and closing the |
|
148 MMC drive door, replacing and removing the MMC card, and assigning a password |
|
149 to an emulated MMC card. This is important so that you can test: </p> <ul> |
|
150 <li id="GUID-2B8F603F-FC12-57E2-B4A7-E86653DAD5C5"><p>how an application behaves |
|
151 when the MMC card, from which the application is running, is removed and/or |
|
152 swapped </p> </li> |
|
153 <li id="GUID-D110DBEA-7070-557E-982A-8A34FACC7256"><p>how an application behaves |
|
154 when it is reading and writing data to and from an MMC card </p> </li> |
|
155 <li id="GUID-E714BBF6-A97F-5D4A-9D45-A7B8C12238F4"><p>that data stored on |
|
156 an MMC card is not lost or corrupted during MMC drive events </p> </li> |
|
157 <li id="GUID-EC779E31-2A94-51D4-B93D-4C9C2811726A"><p>that MMC card locking |
|
158 and password notification works correctly. </p> </li> |
|
159 </ul> <p>The platform independent layer of the MuiltiMediaCard controller, |
|
160 as its name implies, is common to all platforms, including the emulator. However, |
|
161 the emulator provides its own implementation of the platform specific layer. </p> <p>The |
|
162 emulator does not provide access to any kind of MultiMediaCard hardware. Instead, |
|
163 the memory area of each emulated card is represented by a file, a <filepath>.bin</filepath> type |
|
164 file in the Windows system <filepath>temp</filepath> directory, on the host |
|
165 machine. The MultiMediaCard emulator emulates a single stack containing two |
|
166 separate cards, the first in slot 0, and the second in slot 1. Each emulated |
|
167 card has an associated <filepath>.bin</filepath> file on the host machine. |
|
168 As the emulator only supports the swapping of cards in slot 0, there are two <filepath>.bin</filepath> files, |
|
169 one for each of the two emulated MMC cards in slot 0. There is no support |
|
170 for card swapping on slot 1, and therefore this has only one <filepath>.bin</filepath> file. </p> <p>This |
|
171 means that all the test programs described can be run on the emulator, and |
|
172 they will exercise the platform independent layer code in the same way as |
|
173 on real target hardware. It also means that call entries to, and exits from |
|
174 platform specific layer code can be traced, and may be useful for debugging |
|
175 problems on real hardware, and to help understand how the controller operates. </p> <p>The |
|
176 code for the emulator specific layer code can be found in <filepath>...\wins\specific\mmc.cpp</filepath>. </p> </section> |
|
177 </conbody></concept> |