There is one caveat on the Raspberry Pi : the USB support is still somewhat buggy perfectible, and we will need to configure it to make it work reliably. The problem is, the RasPi will occasionally drop USB packets for "full-speed" peripherals (such as keyboard, mouse, modems, as well as some audio devices) when working in standard "high-speed" mode. The problem is less acute with the most recent firmware, but it is not completely solved. The only reliable workaround for now is to force all peripherals to run in "full-speed" mode. This will have the negative side effect of limiting all peripherals (including the on-board network adapter) to 1.5 MBytes/s, but anyway, the Raspberry Pi is not designed to be a race horse...

To force USB to run in "full-speed" mode, simply add dwc_otg.speed=1 to the /boot/cmdline.txt file, as follows:

These mechanisms of the dwMechanical parameter have been included for completeness; however, these functions of motorized CCIDs are not covered by this release of the specification. A future release may attempt to standardize the interface to these mechanical functions.

dwMechanical

#

%

0x00000000

246

96.85 %

0x00000001

7

2.76 %

0x03000000

1

0.39 %

The normal value should be 0x00000000: "No special characteristics" since this field is not covered by the CCID specification.

RRRR –Upper Word- is RFU = 0000h
PPPP –Lower Word- Encodes the supported protocol types. A ‘1’ in a given bit position indicates support for the associated ISO protocol.
0001h = Protocol T=0
0002h = Protocol T=1
All other bits are reserved and must be set to zero. The field is intended to correspond to the PCSC specification definitions. See PCSC Part3. Table 3-1 Tag 0x0120.
Example: 00000003h indicates support for T = 0 and T = 1.

dwProtocols

#

%

0x0000 0x0003

207

81.50 %

0x0000 0x0002

27

10.63 %

0x0000 0x0001

19

7.48 %

0x0000 0x0300

1

0.39 %

The value 0x0300 is bogus and is used by the reader:

MYSMART MySMART PAD V2.0

Some readers (7.48%) only supports the T=0 protocol. They are:

ATMEL AT91SC192192CT-USB ICCD reader

ATMEL AT98SC032CT-USB

ATMEL VaultIC420 Smart Object

ATMEL VaultIC440

ATMEL VaultIC460

BIFIT iBank2Key

Gemalto Hybrid Smartcard Reader

Gemalto SA .NET Dual

Gemalto Smart Enterprise Guardian Secure USB Device

Gemalto Smart Enterprise Guardian Secure USB Device

IID AT90S064 CCID READER

INSIDE Secure VaultIC 405 Smart Object

INSIDE Secure VaultIC 441 Smart Object

Inside Secure VaultIC 420 Smart Object

Inside Secure VaultIC 440 Smart Object

Inside Secure VaultIC 460 Smart Object

KEBTechnology KONA USB SmartCard

Kingtrust Multi-Reader

RSA RSA SecurID (R) Authenticator

SchlumbergerSema SchlumbergerSema Cyberflex Access

SecuTech SecuTech Token

Softforum Co., Ltd XecureHSM

TianYu CCID Key TianYu CCID SmartKey

Some readers (10.63%) only supports T=1 protocol. They are:

ACS ACR122U PICC Interface

ASK-RFID CPL108

Aktiv Co., ProgramPark Rutoken Magistra

Aktiv PINPad Ex

Aktiv PINPad In

Aktiv Rutoken ECP

Aktiv Rutoken lite

BIFIT USB-Token iBank2key

CCB eSafeLD

Crypto Stick Crypto Stick v1.4

Feitian ePass2003

Free Software Initiative of Japan Gnuk

Gemalto PDT

German Privacy Foundation Crypto Stick v1.2

Giesecke & Devrient GmbH Star Sign Card Token 350 (ICCD)

Giesecke & Devrient GmbH Star Sign Card Token 550 (ICCD)

GoldKey Security PIV Token

IIT E.Key Almaz-1C

Macally NFC CCID eNetPad

OCS ID-One Cosmo Card USB Smart Chip Device

Philips Semiconductors JCOP41V221

Philips Semiconductors SmartMX Sample

REINER SCT cyberJack RFID basis

Watchdata W5181

Yubico Yubikey NEO CCID

Yubico Yubikey NEO OTP+CCID

id3 Semiconductors CL1356A_HID

id3 Semiconductors CL1356T5

id3 Semiconductors CL1356T

ubisys 13.56MHz RFID (CCID)

Many of the readers with support of only 1 protocol are tokens with an integrated smart card. Since you can't change the card only the protocol used by the card is declared. So it is not really a limitation of the reader.

The dwSynchProtocols field is a number value from the CCID USB descriptor:

• RRRR-UpperWord- is RFU=0000h
• PPPP-Lower Word- encodes thes upported protocol types. A ‘1’ in a given bit position indicates support for the associated protocol.
0001h indicates support for the 2-wire protocol
0002h indicates support for the 3-wire protocol
0004h indicates support for the I2C protocol
All other values are outside of this specification, and must be handled by vendor-supplied drivers.

A footnote in the specification also indicates:

This release of the specification does not support devices with the 2-wire, 3-wire, and I2C protocol so PPPP = 0000h. This field is intended to be forward compatible with the PCSC specification.

I imagine this value is for synchronous cards only.

dwSynchProtocols

#

%

0x00000000

218

85.83 %

0x00000007

35

13.78 %

0x00000001

1

0.39 %

The normal value should be PPPP = 0000h. Most of the readers provide this value.