Chapter 20: Card Services
`
`Note that the AcknowledgeInterrupt function is called by the status change in-
`terrupt service routine. Interrupts must not be re-enabled while processing a
`status change interrupt. This could cause nesting of status change interrupts
`while processing the socket service's Acknowledgelnterrupt, a situation that
`socket services is unprepared to manage (because the routine is non-
`reentrant).
`
`The Client Call-Back
`
`Numerous events can occur that require a call-back to client drivers. These
`events are listed in table 20-11. The events in the shaded boxes were added
`with the PC Card 95 release.
`
`Table 20-11. Call-Back Events Defined by Card Services
`
`
`
`
`
`
`
`
`
`
`Registered By
`Client(s}
`Source
`7r9-
`Hardware
`Hardware
`
`Socket
`
`:38’_.a
`
`Z
`
`'I'Ds
`DeregisterMTD
`_
`Requester
`RegisterClient
`WeleaseExclusive
`——
`
`——
`
`Code
`01 h
`02h
`40h
`
`40h
`gs.C) 3"
`
`4011
`
`
`
`
`
`RequestSock
`RequestSoc
`
`em
`
`ask
`ask
`
`A“
`
`R R
`
`-
`
`equestExcluswe
`RequestSocketMask
`RequestSocketMask
`RequestSocketMask
`RegisterChent
`
`Socket
`
`__
`
`
`
`
`
`
`
`RequestSockewask
`
`293
`
`Toshiba_Apricorn 1006-0303
`Toshiba_Apricorn 1006-0303
`IPR2018-01067
`|PR2018—01067
`
`40h
`
`05h
`
`0511
`
`06h
`
`07h
`
`Hardware
`
`81h
`
`Queued Erase
`
`91‘:
`
`Card Services
`
`
`' CardSemces
`
`
`
`Event
`BATTE RY_DEAD
`BATTERY_LOW
`CARDJNSERTION
`
`CARD_]NSERTION [A1
`CARD_INSERTION [Al
`CARDJNSER’I‘ION [A]
`cmmsmow w
`mewsmomm
`camm
`mama
`mmmm
`mamas 1m
`mama/aw
`meme
`cmmocx
`ammo
`EJECTIONWCOMPLETE
`EJECTIONJEQUEST
`ERASE_COMPLETE
`EXCLUSIVE_COMPLETE
`EXCLUSWE_REQUEST
`
`INSERTION_COMPLETE
`INSERTIONuREQUEST
`MTD_REQUEST
`
`
`
`RequestExclusive
`Q.t:E.
`
`D [TI 5"
`
`OAh
`
`8D r9 mm?HeEM:339
`
`
`

`

`PCMCIA System Architecture
`
`Table 20-11. Cali-Back Events Defined by Card Services
`
`RegisterClient
`
`Configuring PC Cards During POST
`
`The previous discussions of PC Card configuration have presumed that the
`cards will be installed when the operating system loads or when the PC Card
`is inserted sometime after the operating system has loaded and the system is
`running. If however, the need to load the operating system from the PC Card
`exists, the previously discussed approaches for configuring the cards don't
`work.
`
`To perform initial program load (IPL) from a PC Card, ROM-based PCMCIA
`initialization code must be included with the system. This code must be able
`to program the HBA and parse the CIS to determine if a given card should be
`configured during POST (Power-On Self Test). Once the HBA has been pro—
`grammed, memory cards containing a boot sector can be recognized as
`bootable since they will contain a BIOS Parameter Block (BPB) that permits the
`booting from the PC Card in the same fashion as a floppy drive.
`
`Similarly, ATA drives can be recognized by ROM code by reading the initiali—
`zation byte within the Function Identification tuple. The initialization byte
`specifies that the device should be configured during POST. Once the ATA
`drive is configured, IPL can occur from the PCMCIA ATA drive like any other
`ATA drive.
`
`Note that this initialization process occurs prior to card services being in-
`stalled. As a result, the a client driver will not have registered to receive status
`change events from the PC Card. When the operating system boots, a driver
`for the PC Card that is performing IPL can register with card services.
`
`294
`
`Toshiba_Apricorn 1006-0304
`Toshiba_Apricorn 1006-0304
`IPR2018-01067
`|PR2018—01067
`
`

`

`
`Chapter 21: Client Drivers
`
`Chapter 21
`
`The Previous Chapter
`
`The previous chapter focused on the role of card services in the PCMCIA en-
`vironment. It also reviewed each of the functions defined by the PC Card
`specification that apply to 16-bit PC Cards, and defined the related return
`codes. The call back mechanism was also described and the event and call
`back codes were defined.
`
`This Chapter
`
`This chapter discusses the three basic types of enablers: point enablers, device-
`specific enablers, and super enablers. The chapter also discusses the jobs per-
`formed by generic memory enablers (and MTDs) and [/0 device enablers.
`
`The Next Chapter
`
`The next chapter discusses the problems associated with loading the operating
`system from a PC Card.
`It also defines mechanisms used to determine
`whether a given PC Card is a bootable device, and the firmware support re-
`quired to support PC Card booting.
`
`Overview
`
`This chapter discusses PC Card enablers. The chapter focuses primarily on cli-
`ent driver enablers, but also includes a brief discussion of point enablers at the
`end of the chapter. Note that the terms PC Card enabler, client, client driver,
`and device driver are all used to describe the software that is responsible for
`configuring a PC Card. This chapter uses the terms enabler and client driver.
`
`
`
`295
`
`Toshiba_Apricorn 1006-0305
`Toshiba_Apricorn 1006-0305
`IPR2018-01067
`|PR2018—01067
`
`

`

`PCMCIA System Architecture
`
`Specific types of client drivers (enablers) discussed in this chapter include:
`
`I»
`
`SRAM client drivers
`
`Flash client drivers and Memory Technology Drivers (MTUs)
`I
`0 Generic I/ 0 client drivers
`
`In order to configure a PC Card, enablers must first register with card serv—
`ices. The primary tunction of an enabler is to detect and configure PC Cards
`that it supports. As such, the enabler must be prepared to configure its card
`no matter when it is installed. In order to configure cards installed after power
`up, the enabler registers with card services to receive a call back (i.e., a card
`insertion call-back) each time card services detects that a PC Cards has been
`
`installed. During registration, the enabler can also request that card services
`generate a call-back for each PC Card already installed, thereby calling the en»
`abler’s configuration routine.
`
`
`
`The Card Insertion Call-Back
`
`When card services makes a card insertion call-back it Specifies the type of
`call-back initiated, along with the logical socket that the card was inserted
`into. The call-back routine then attempts to configure the card. Figure 21-1 il-
`lustrates the typical process used by an enabler to configure a card. The CIS
`may have to be accessed several
`times to obtain a combination of card-
`required resources that can be successfully allocated to the card (i.e., resources
`that are not already assigned to other devices).
`
`The configuration process begins when card services makes the card insertion
`call—back to the enabler. The enabler detects which event caused the call-back
`
`and obtains information supplied by card services (e.g., which logical socket
`the card was inserted into).
`
`The method of configuring a card varies depending of the type of card to be
`configured. The next section discusses generic memory enablers, and the fol-
`lowing section describes the operation of a generic I/ O enabler.
`
`As discussed in the previous chapter, a variety of services are available for the
`PC Card enablers (i.e., card services client drivers) to configure a PC Card.
`
`296
`
`Toshiba_Apricorn 1006-0306
`Toshiba_Apricorn 1006-0306
`IPR2018-01067
`|PR2018—01067
`
`

`

`Chapter 21: Client Drivers
`
`Card configured
`or does not belong
`to enabler
`
` End
`(card not configured)
`
`Start Configuration
`
`
`
`Cali
`
`GetConfiglnfo
`
`
`
`Card not configured
`and beloan to
`enabler
`
`
` Process
`
`Not available.
`
`
`try next options
`
`
` Request
`
`
`allocation
`Not available.
`
`of resources
`End
`no more otions
`
`
`{card not configured)
`
`C IS
`
`
`
`
`Flesources
`granted to
`enabler
`
`
`Call
`
`
`RequestConfig
`
`
`End
`(card configured)
`
`Figure 21-1. A Sample Configuration Process Used By a Card Services Client
`
`
`
`Memory Drivers and Memory Technology Drivers
`
`Memory client drivers provide virual disk drive support. In short, these driv-
`ers are responsible for storing and retrieving files within the memory card.
`The method required to access the memory card varies depending 0n the type
`of memory devices (i.e., memory technology] implemented in the card. Since
`memory devices (such as flash) require various programming algorithms,
`each memory type must have an associated memory technology driver
`(MTD).
`
`E
`
`Toshiba_Apricorn 1006-0307
`Toshiba_Apricorn 1006-0307
`IPR2018-01067
`lPR2018—01067
`
`

`

`PCMCIA System Architecture
`
`Figure 21-2 illustrates the overall software architecture specified for accessing
`memory cards as virtual disk drives. Notice that memory client drivers re—
`ceive file access requests from the file system and must access the memory
`card to fullfill each request. The file system might be the standard file system
`used by the opertating system (e.g., the DOS FAT system) or an installable
`system required when accessing flash memory. Card services provides bulk
`memory services that simplifies the memory client driver’s job of accessing a
`specific block of memory within the memory card.
`
`SRAM memory client drivers typically interface directly to the operating sys
`tem’s file manager, since there are no restrictions related to writing and
`reading data to or from SRAM. These client drivers are designed to access
`memory via the bulk memory services provided by card services. Since ac-
`cessing SRAM is uniform and quite simple (byte read / write capability), the
`memory technology driver is incorporated into card services.
`
`Flash memory client drivers interface directly to a flash file system. A special
`file system is required for flash devices due to the special requirements asso-
`ciated with writing to flash memory. Two major factors are:
`
`O Write operations require first erasing a specified block of memory fol-
`lowed by the block write, and may take several seconds to complete.
`Flash memory also has a limited write~cycle life. That is, repetitive era-
`sures and writes to the same memory block destroys the chips ability to
`retain data within that block. The maximum number of erasures and
`
`I
`
`writes are specified by the manufacturer (e.g., a flash device may specify
`as life of as few as 10,000 writes).
`
`Knowing the restrictions associated with accessing flash memory, the flash file
`system is designed specifically to provide compatible access to flash memory.
`For example,
`the flash file system distributes writes to flash memory to
`minimize the effects of repetitive write ware and accomodates the slow erase
`time.
`
`Memory enablers (client drivers) have a formidable task to perform since a
`wide variety of memory card implementations exist. The enabler must also
`acquire a drive letter from the operating system to allocate to each card slots
`that a memory card might be inserted into. The following sections describe the
`jobs performed by SRAM and flash client drivers.
`
`298
`
`Toshiba_Apricorn 1006-0308
`Toshiba_Apricorn 1006-0308
`IPR2018-01067
`|PR2018—01067
`
`

`

`Chapter 21: Client Drivers
`
`Applications
`
`Client Dr'rve
`
`
`_
`
`Bulk Memory Services—"
`
`MTD
`
`SHAM
`
`Flash
`Flle System
`
`Installabls
`
`File System
`
`Flash
`Client Driver
`
`Operating
`System
`
`Card Services
`
`Socket Services
`
`
`
`Figure 21-2. Memory Client Driver Software Environment
`
`SRAM Client Drivers
`
`SRAM client drivers typically load as installable device drivers via the con-
`figsys file or equivalent mechanism. One of the tasks performed by the device
`driver is to detect the presence of card services by calling the GetCSlnfo serv-
`ice. If the call returns the ASCII string ”CS,” then SRAM client driver
`recognizes that card services are installed. Note that if card services is not in-
`stalled, the SRAM driver typically reports the error condition and terminates
`
`299
`
`Toshiba_Apricorn 1006-0309
`Toshiba_Apricorn 1006-0309
`IPR2018-01067
`|PR2018—01067
`
`

`

`PCMCIA System Architecture
`
`without remaining resident in memory. When card services is detected, the
`driver then registers with card services.
`
`The driver must also obtain logical drive letters needed to perform the disk
`emulation. Note that the drive letter is acquired when the device driver in-
`stalls even though a memory card may not be installed in the system. In this
`case, an attempt to access files associated with the drive letter assigned to the
`socket will result in a drive not ready error.
`
`SRAM Client Driver Registers with Card Services
`
`The client driver performs the registration process by calling the RegisterCli-
`ent service. The SRAM client identifies itself as a memory client, registers to
`receive relevant call-back events, and passes a pointer to its call-back routine.
`The client may also request that card services generate a card insertion call-
`back for each PC Card already installed in the system. The memory client re-
`ceives a handle value from card services when it returns from the call. Once
`
`registered, the memory client awaits call—backs from card servcies, notifying it
`when a PC card is inserted or removed.
`
`The SRAM Client Driver Call-Back
`
`When card services generates the card insertion call-back, it also passes the
`logical socket number that the PC Card was inserted into. The memory client
`then attempts to configure the PC Card.
`
`The memory client must first determine if it should attempt to configure the
`PC Card by determining the card type. Memory clients can use the bulk
`memory services to access a specific region within the PC card. To access
`memory, the client first calls the OpenMemory service by specifying an offset
`Within the card’s attribute or common memory address space. Card services
`then returns a memory handle to the client that it can use when accessing
`memory relative to the offset specified in the OpenMemory service. Note that
`if card services does not support bulk memory services, the memory client
`must use the RequestWindow service to specify the host system address space
`that it wishes to use to access PC Card memory.
`
`Reading from or writing to PC Card memory is accomplished by calling the
`ReadMemory or WriteMemory services. The memory client passes the mem-
`ory handle it received from the OpenMemory service and specifies the
`memory offset and range of addresses it wishes to access. The call will likely
`
`
`
`300
`
`Toshiba_Apricorn 1006-0310
`Toshiba_Apricorn 1006-0310
`IPR2018-01067
`|PR2018—01067
`
`

`

`Chapter 21: Client Drivers
`
`Specify location zero within the attribute memory address space. When the
`data is returned to the memory client it evaluates the DEVICE tuple to de-
`termine if the card contains SRAM.
`
`Note that determining the card type can be a complicated process for memory
`clients. Some memory cards implement the CIS in attribute memory (required
`by the PC Card standard), some implement the C18 in common memory,
`while others do not implement a C15 at all. To complicate matters, some CIS
`implementations are invalid, requiring the enabler to attempt interpretation of
`the faulty CIS. If the card does not contain a C18, the enabler attempts to de-
`tect
`the presence of
`the BPB (BIOS parameter block), which contains
`information that specifies the logical size of the disk. The BPB if present
`should reside at either location 0 or 512 in common memory.
`
`If an SRAM card is detected, the call-back routine return to card services, in-
`dicating that the card was successfully configured. If the PC Card was not an
`SRAM card, the client returns to card services, indicating the card was not
`configured by the SRAM enabler.
`
`Flash Client Drivers
`
`Figure 21-3 illustrates the flash client driver software environment. Three
`types of flash client drivers are illustrated in figure 21-3. Two of the client
`drivers are shown interfacing to a flash file system and the other via a file
`translation layer. (Each file system is discussed later in this chapter.)
`
`The flash client drivers typically load as installable device drivers via the con-
`figsys file or equivalent mechanism. The first task performed by the device
`driver is to detect the presence of card services. If card services are not in-
`stalled, the flash driver typically reports the error condition and terminates
`without remaining resident in memory. When card services is detected, the
`driver then registers with card services.
`
`Flash client drivers differ from SRAM drivers in two important ways:
`
`Flash client drivers interface to the flash file system
`0
`0 MTD client drivers must be installed to handle calls made to bulk memory
`services
`
`The MTD must register prior to the flash client driver. This is necessary be-
`cause the flash client driver uses the MTD to access the flash card.
`
`301
`
`Toshiba_Apricorn 1006-0311
`Toshiba_Apricorn 1006-031 1
`IPR2018-01067
`|PR2018—01067
`
`

`

`PCMCIA System Architecture
`
`Operating
`System
`
`lnstallable
`File System
`
`Standard
`File System
`
`
`
`Flash
`File System
`
`Flash
`Translation
`
`La er
`
`Flash
`Client Driver
`
`Flash
`Client Driver
`
`Flash
`Client Driver
`
`Applications
`
`
`
`
`
`
`
`
`
`
`
` Memory
`Technolog
`
`Driver
`
`Card Services
`
`_
`Bulk Memory Services
`
`Socket Services
`
`Figure 21-3. Software Environment Required for Flash Card Support
`
`302
`
`Toshiba_Apricorn 1006-0312
`Toshiba_Apricorn 1006-0312
`IPR2018-01067
`|PR2018—01067
`
`

`

`Chapter 21: Client Drivers
`
`Like SRAM client drivers, flash client drivers must also obtain logical drive
`letters needed to perform the disk emulation. The drive letter is acquired
`when the device driver installs even thOugh a memory card may not be in-
`stalled in the system. In this case, an attempt to access files associated with the
`drive letter assigned to the socket will result in a drive not ready error.
`
`The Flash File System
`
`Two primary types of flash file system solution are provided by software
`vendors today. These systems are generally referred to as the flash file system
`(FPS) and flash translation layer (FTL) as illustrated in figure 21-3. The FPS
`provides file management based on variable size data blocks, while the FTL
`interfaces directly to the DOS file system which allocates data based on stan-
`dard block sizes. The FTL system is compatible with disk utility programs
`such as Norton and PC Tools, whereas, the FFS—based systems are not.
`
`MTD Registers with Card Services
`
`The MTD registers with card services by calling the Register-Client service.
`When registering the MTD specifies that it is a MTD client during , specifies
`relevant call-back events it want to be notified of, and passes a pointer to its
`call-back routine. The MTD client may also request that card services generate
`a card insertion call-back for each PC Card already installed in the system.
`The MTD client receives a handle value from card services when it returns
`
`from the call. Once registered, the MTD awaits call-backs from card servcies,
`notifying it when a PC card is inserted or removed.
`
`The MTD Call-Back
`
`When card services generates the card insertion call-back, it also passes the
`logical socket number that the PC Card was inserted into. The MTD client
`then determines if the PC Card contains any flash memory that it is designed
`to access. This can be accomplished by calling the GetFirstRegion and Get-
`NextRegion services. These services return information (obtained from the
`CIS) about the card type, size, location, access time, and block erase details of
`the regions. If the MTD recognizes a regions of memory that it knows how to
`access, it then registers with card services to control access to that specific re-
`gion of memory.
`
`303
`
`Toshiba_Apricorn 1006-0313
`Toshiba_Apricorn 1006-0313
`IPR2018-01067
`|PR2018—01067
`
`

`

`PCMCIA System Architecture
`
`MTD Registers Memory Regions
`
`To register a memory region with card services the MTD calls the Regis-
`terMTD service. This notifies card services that the MTD has agreed to handle
`access to the memory regions specified. When a flash client driver requests
`access to this region via bulk memory services, card services will make an
`MTDRequest call-back to the MTD. The information specified in the call-back
`packet specifies the operation be requested.
`
`Flash Client Driver Registers with Card Services
`
`The client driver performs the registration process by calling the RegisterCli—
`ent service. The flash client identifies itself as a memory client, during
`registration and specifies which callback events it wishes to be notified of,
`and passes a pointer to its cali-back routine. The client may also request that
`card services generate a card insertion call-back for each PC Card already in-
`stalled in the system. The memory client receives a handle value from card
`services when it returns from the call. Once registered, the memory client
`awaits call—backs from card services, notifying it when a PC card is inserted or
`removed.
`
`The Flash Client Driver Call-Back
`
`When card services generates the card insertion call-back, it also passes the
`logical socket number that the PC Card was inserted into. The memory client
`then attempts to configure the PC Card.
`
`The memory client must first determine if the card is the type that it is de-
`signed to enable. Memory clients can use the bulk memory services to access a
`specific region within the PC card. To access memory, the client first calls the
`OpenMemory service by specifying an offset within the card’s attribute or
`common memory address space. Card services then returns a memory handle
`to the client for use when accessing memory starting at the offset specified in
`the OpenMemory service. Also when the OpenMernory service is called, card
`services recognized the region being opened is registered by the MTD. Note
`that if card services does not support bulk memory services, the memory cli-
`ent must use the RequestWindow service to specify the host system address
`space that it wishes to use to access PC Card memory.
`
`
`
`304
`
`Toshiba_Apricorn 1006-0314
`Toshiba_Apricorn 1006-0314
`IPR2018-01067
`|PR2018—01067
`
`

`

`Chapter 21: Client Drivers
`
`Reading from or writing to PC Card memory is accomplished by calling the
`ReadMemory or WriteMemory services. In this instance, the memory client
`passes the memory handle it received from the OpenMemory service and
`specifies the memory offset and range of addresses it wishes to access. The
`call will likely specify location zero within the attribute memory address
`space. When the data is returned to the memory client it evaluates the DE-
`VICE tuple to determine if the card contains flash memory.
`
`If a flash card is detected the call-back routine returns to card services, indicat-
`ing that the card was successfully configured. If the PC Card was not a flash
`card, the client returns to card services, indicating the card was not enabled
`by the flash Client driver.
`
`Accessing Flash Memory
`
`Once the flash card has been enabled, access made to the flash card virtual
`
`drive will be fulfilled. The flash client driver receives the request from the
`flash file system and calls the appropriate bulk memory service. Card services
`recognizes that the call is to a region controlled by an MTD that previously
`register to access the specified memory region. Card services responds by
`making MTD call~bacl<s to specify the operation being requested.
`
`I/O Card Client Drivers
`
`Two basic types of [/0 client drivers are popular.
`
`0 Device-specific client drivers — drivers designed to detect and configure
`a specific PC Card. The client drivers are typically shipped by the manu»
`facturer of a PC Card and are designed to configure this specific PC Card.
`0 Generic (Super) client drivers — drivers designed to detect and configure
`a wide range of I/O cards based on generic types, regardless of manufac-
`turer.
`
`Each type of [/0 client driver instail as device drivers when the configsys file
`is executed during the system boot process. Figure 21-4 illustrates the primary
`actions taken by an generic I /0 client driver when it initializes, registers with
`card services and attempts to configure PC Cards.
`
`305
`
`Toshiba_Apricorn 1006-0315
`Toshiba_Apricorn 1006-0315
`IPR2018-01067
`|PR2018—01067
`
`

`

`PCMCIA System Architecture
`
`Start
`
`Call
`
`Cal] GeICSInIo
`FiequasllOi'
`
`
`RequestiHOi'
`Flequelen
`risque - IDMA
`
`
`
`
`
`Release
`
`Flesouoes
`Terminate
`
`For lncnmplale
`Initialization
`
` YES
`Re mercilenl
`
`
`
`
`Hesouces
`Duplicale
`
`Flesouces
`For Incomplete
`
`Enabter Waits
`EntlyI
`(if any]
`
`for Call-bad: from
`
`
`
`Card Services
` GetFilstTupla
`
`{Conllg Table Enty}
`
`
`
`
`
`
`- Cine-s
`
`I Call-back
`' ggmzliaatgm
`
`
`
`‘
`S [E On
`
`Call
`
`am ale
`GetNexlTupie
`Call-
`ok
`
`
`(nex‘l ouan
`
`entry]
`
`
`a"
`Fiequ estconilg
`
`
`
`Figure 21—4. 1/0 Enabler Registration and PC Card Configuration Process
`
`IIO Client Driver Registers with Card Services
`
`The registration process begins after the client driver detects that card services
`has initialized. This is accomplished with the GetCardServicesInfo cal]. Card
`services returns information about card services and verifies its presence by
`also returning the ASCII string ”CS.” If card services is not initialized, the I/O
`client driver reports the error condition and terminates without remaining
`resident in memory. If card services are present the client driver calls the
`RegisterClient service. When the I / 0 client driver makes the call it:
`
`0
`
`0
`0
`
`0
`
`identifies itself as an I/O client,
`
`specifies which events it wants to be notified of,
`requests a card insertion cali~back for each PC Card currently installed in
`sockets, and
`
`passes the entry point of it call-back routine when making the call.
`
`306
`
`Toshiba_Apricorn 1006-0316
`Toshiba_Apricorn 1006-0316
`IPR2018-01067
`|PR2018—01067
`
`

`

`Chapter 21: Client Drivers
`
`Card services returns a client handle to the [/0 client driver upon return from
`the RegisterClient service. The client driver then awaits card insertion cali-
`backs. Card services generates a CardInsertion call-back for each PC Card al-
`ready installed in a card socket (as requested by the client driver during
`registration). If all sockets are empty, card services generates a Configura-
`tionComplete call-back to signal the end of the configuration process. This
`example presumes that an 1/0 PC Card was installed when the system was
`powered on.
`
`The IIO Client Driver Call-Back
`
`Card services generates a Cardlnsertion call-back to the I/O client driver. The
`driver detects the call-back and evaluates the call-back packet to determine
`the socket into which the PC Card was inserted.
`
`Identifying the PC Card
`
`Next the GetConfigurationlnfo service is called to determine if the PC Card
`has already been configured by another enabler. If already configured, the cli-
`ent driver returns to card services without configuring the PC Card. If the PC
`Card has not been configured, the client driver evaluates other data returned
`by the GetConfigurationInfo service to determine the type of function that is
`associated with the PC Card. If the function is one that the generic I /O enabler
`is designed to handle, the configuration process continues.
`
`Determining Resources Requirements
`
`Next, the client driver checks the first entry within the configuration table to
`determine the resources required by the card. This can be accomplished by
`and calling the GetFirstTuple service and specifying a tuple code of 1311 (the
`configuration table entry tuple code). Card services scans the CIS until if finds
`the first instance of tuple lBh and returns to the client driver. The [/0 driver
`checks the completion status and detects that card services has located the
`first configuration table entry. Next, the client driver calls GetTupleData and
`card services returns the contents of the first configuration table entry. The
`tuple data is evaluated to determine the resources required by the PC Card.
`
`307
`
`Toshiba_Apricorn 1006-0317
`Toshiba_Apricorn 1006-0317
`IPR2018-01067
`|PR2018—01067
`
`

`

`PCMCIA System Architecture
`
`Requesting the Resources
`
`As the client driver detects a configurable resource within the configuration
`table entry (e.g., a range of I / 0 address locations), it checks with card services
`to determine if the resource is available for the I/O card to use. The client re-
`
`quests a resource by calling the respective resource request service (e.g.,
`RequestIO). When RequestIO is called Card services receives the base I/O
`address and range of address locations requested. It uses these values to per-
`forms a look-up within the resource management table to determine if the
`resource is available. Card services indicates whether or not the resource was
`available in the return code.
`
`The client driver rnakes requests for all resources listed within the configura-
`tion table entry and determines their availability. The configurable resources
`that can be acquired from the system include:
`
`I...
`
`Memory address locations — via the RequestWindow service
`I / 0 address locations — via the RequestIO service
`Interrupt request lines — via the RequestIRQ service
`DMA channels - via the RequestDMA service
`
`The specific actions taken when a resource is not available depends of whether
`the entry is a default entry of not, as discussed in the following paragraph.
`
`If the client driver detects that the entry is tagged as'a default entry, it knoWs
`that it should attempt to acquire all resources that are specified within this en-
`try. It should retain all resource acquired from card services even if one or
`more of the resources requested are not available. If the entry is not a default
`entry, the client driver knows that the entire set of resources specified within
`entry must be obtained to satisfy the configuration. If any one resource is not
`available, then the client driver should release any individual resources that
`were acquired from card services by calling the respective release resource
`service {e.g., ReleaseIO).
`
`If a given entry fails to satisfy the PC Card’s configuration, the client driver
`then proceeds to the next entry by calling the GetNextTuple service. Card
`services finds the next configuration table entry (tuple 13) and the client
`driver calls GetTupleData and starts the resource acquisition process again.
`
`308
`
`Toshiba_Apricorn 1006-0318
`Toshiba_Apricorn 1006-0318
`IPR2018-01067
`|PR2018—01067
`
`

`

`Chapter 21: Client Drivers
`
`Configuring the PC Card
`
`When all resources needed for the PC Cards configuration have been ac-
`quired from the system, the client driver configures the HBA and PC Card by
`calling the RequestConfiguration service. In response, card services configures
`the I-IBA and PC Card. The HBA is configured by loading the appropriate
`HBA registers (via socket services) that satisfy the configuration being re-
`quested. This includes reconfiguring the socket interface to memory or 1/0,
`programming the 1/0 window registers, and programming the IREQ# steer—
`ing logic to direct the IRQ to the appropriate system IRQ line. The PC Card is
`configured by writing the index number of the configuration table entry (the
`entry that satisfied the configuration) into the configuration option register
`(COR) within the card’s attribute memory address space.
`
`Point Enablers
`
`Point enablers are dedicated enablers that bypass card and socket services.
`These enablers are popular in environments such as DOS where limited mem-
`ory address space is available for application programs. Card and socket
`services take a considerable amount of memory when they install. Added to
`this is the space required by the enabler(s) and any TSR (terminate and stay
`resident programs) that might be used. As a result, too little memory is left for
`many application programs to run.
`
`One solution used to relieve this memory shortage, is to remove card and
`socket services from the system, thereby freeing up memory that is needed to
`run the application program. Eliminating the card and socket services pre-
`vents PC Card client drivers from performing their functions, thus ._PC Card
`are never enabled and cannot be used. In order to use PC Cards point enablers
`are needed to configure the PC Cards.
`
`In the absence of card and socket services, point enablers must communicate
`directly with the HBA to load the appropriate registers necessary to gain ac-
`cess to the PC Card. The card’s CIS must be read and interpreted to identify
`the PC Card. If the point enabler recognizes the PC Card, it attempts to con-
`figure the card by loading the appropriate registers within the HBA to satisfy
`the configuration, and by writing to the configuration registers to configure
`the PC Card. Note that the resources used to configure the PC Card must be
`specified manually by the user (typically via software switches).
`
`309
`
`Toshiba_Apricorn 1006-0319
`Toshiba_Apricorn 1006-0319
`IPR2018-01067
`|PR2018—01067
`
`

`

`Chapter 22: Booting from PC Cards
`
`Chapter 22
`
`The Previous Chapter
`
`The previous chapter discussed the three basic types of enablers: point en—
`ablers, device-specific enablers, and generic (super) enablers. The chapter also
`discussed the jobs performed by generic memory enablers (and MTDs) and
`[/0 device enablers.
`
`This Chapter
`
`This chapter discusses the problems associated with loading the operating
`system from a PC Card. It also defines mechanisms used to determine
`whether a given PC Card is a bootable device, and the fi