Platform +Specific Layer Validation

There are three stages involved in testing a port of the MultiMediaCard +controller. The first stage tests the controller in isolation; subsequent +stages test an additional area of functionality.

All three stages involve text shell based test programs and test drivers, +and therefore these tests can be run by just building a text shell ROM. You +can also run tests on the Emulator.

Testing the +controller in isolation

MMCTEST.EXE tests +the MultiMediaCard controller in isolation, at the controller’s client interface +level. Since the controller’s client API is a kernel side interface, this +requires a test driver, D_MMCIF.LDD, as well as the test +program itself.

This is not a 'go/no-go' type test, but is a test +utility that can perform a small variety of operations. These are selected +a simple interactive way by pressing appropriate keys.

+ + + +

Building MMCTEST.EXE and D_MMCIF.LDD

The source and header files needed to build MMCTEST.EXE can +be found in ...\e32utils\pccd; the mmp file is ...\e32utils\group\mmctest.mmp.

The +source and header files needed to build the test driver D_MMCIF.LDD can +be found in ...\e32utils\pccd; the mmp file is ...\e32utils\group\d_mmcif.mmp.

You +need to build MMCTEST.EXE for the appropriate CPU target +architecture (e.g. ARMI,THUMB etc.); you need to build D_MMCIF.LDD for +the appropriate platform (e.g. MINT).

Include both of these components +in a ROM

+ + +

Running the tests

Run MMCTEST and perform the following suggested sequence:

Without a card inserted, +power up the stack by pressing P, and check that it +reports that no card is present.
Insert a card, power +it up, and check that it reports that a card is present.
Now that the card is +powered up, read the card info by pressing C, and check +the data returned about the card against the expected card data, by referring +to the datasheet for the card.
Read the first sector +of the card by pressing M.
Now read a few more +sectors by pressing the space bar.
Test writing to a sector: +while still viewing a sector, edit a part of this, by using the direction +keys and typing in a hex number. Now save the change by pressing ESC, +followed by Y. Now navigate to the same sector again +and check that it displays the new contents of the sector.
Quit the test by pressing Q.

+ + + +

Testing the +controller with the media driver and the local media sub-system

DRVTEST.EXE tests +the MultiMediaCard controller in conjunction with the media driver and the +local media sub-system, in effect accessing the card as a local drive. This +requires a kernel side test driver D_DRVIF.LDD as well +as the test program itself.

This is not a 'go/no-go' type test, but +is a test utility that can perform a small variety of operations. These are +selected a simple interactive way by pressing appropriate keys. It is used +to test that card initialization and single block read and write requests +are performed successfully.
T_ATADRV.EXE tests +that card initialization and simple read and write requests succeed. It also +tests multi-block read/write operations, format requests, accessing the device +following a media change event, and a machine power down event.

This +is a 'go/no-go' type test. If this test succeeds, you can have fairly high +confidence that the F32 test suite will run successfully.

+ + + +

Building DRVTEST.EXE, D_DRVIF.LDD, +and T_ATADRV.EXE

The source and header files needed to build DRVTEST.EXE can +be found in ...\e32utils\pccd; the mmp file is ...\e32utils\group\drvtest.mmp.

The +source and header files needed to build the test driver D_DRVIF.LDD can +be found in ...\e32utils\pccd; the mmp file is ...\e32utils\group\d_drvif.mmp.

The +source and header files needed to build T_ATADRV.EXE can +be found in ...\e32test\pccd; the mmp file is ...\e32test\group\t_atadrv.mmp.

You +need to build DRVTEST.EXE for the appropriate CPU target +architecture (e.g. ARMI,THUMB etc.)

You need to build D_DRVIF.LDD for +the appropriate platform (e.g. MINT)

You need to build T_ATADRV for +the appropriate CPU target architecture (e.g. ARMI,THUMB).

Include +these components in a ROM.

+ + +

Running the DRVTEST test

Run DRVTEST and perform the following suggested sequence:

Without a card inserted, +power up the stack by pressing P, and check that it +reports that no card is present.
Insert a card, power +it up, and check that it reports that a card is present.
Now that the card is +powered up, read the card info by pressing C, and check +the data returned about the card against the expected card data, by referring +to the datasheet for the card.
Read the first sector +of the card by pressing M.
Now read a few more +sectors by pressing the space bar.
Test writing to a sector: +while still viewing a sector, edit a part of this, by using the direction +keys and typing in a hex number. Now save the change by pressing ESC, +followed by Y. Now navigate to the same sector again +and check that it displays the new contents of the sector.
Quit the test by pressing Q.

+ + +

Running the T_ATADRV test

Run T_ATADRV and follow the on-screen instructions. Check that the +test runs to the end with no errors.

+ + + +

Testing using +the F32 test suite

The final test stage is to run the entire file +server test suite on a card drive.

To perform these tests:

build a text shell ROM +that contains the F32 test suite, i.e. build the ROM with the option:
-t=f32tests
boot the test machine +into the text shell.
launch the F32 automatic +tests and check that all of the tests run without error. Use the command option +"-d" to set the default drive, for example:
RUNTESTS F32TEST.AUTO.ARMI.BAT -d d

Emulator-based +tests

It is possible to emulate a user opening and closing the +MMC drive door, replacing and removing the MMC card, and assigning a password +to an emulated MMC card. This is important so that you can test:

how an application behaves +when the MMC card, from which the application is running, is removed and/or +swapped
how an application behaves +when it is reading and writing data to and from an MMC card
that data stored on +an MMC card is not lost or corrupted during MMC drive events
that MMC card locking +and password notification works correctly.

The platform independent layer of the MuiltiMediaCard controller, +as its name implies, is common to all platforms, including the emulator. However, +the emulator provides its own implementation of the platform specific layer.

The +emulator does not provide access to any kind of MultiMediaCard hardware. Instead, +the memory area of each emulated card is represented by a file, a .bin type +file in the Windows system temp directory, on the host +machine. The MultiMediaCard emulator emulates a single stack containing two +separate cards, the first in slot 0, and the second in slot 1. Each emulated +card has an associated .bin file on the host machine. +As the emulator only supports the swapping of cards in slot 0, there are two .bin files, +one for each of the two emulated MMC cards in slot 0. There is no support +for card swapping on slot 1, and therefore this has only one .bin file.

This +means that all the test programs described can be run on the emulator, and +they will exercise the platform independent layer code in the same way as +on real target hardware. It also means that call entries to, and exits from +platform specific layer code can be traced, and may be useful for debugging +problems on real hardware, and to help understand how the controller operates.

The +code for the emulator specific layer code can be found in ...\wins\specific\mmc.cpp.