Back to all discussions

  •   about 14 years ago

First Plug in on Linux

After first plugging in my MintChip USB stick, this is what I found:

burton@newton:~/mintchip$ dmesg
[681887.200019] usb 2-1: new high speed USB device number 3 using ehci_hcd
[681887.334832] scsi10 : usb-storage 2-1:1.0
[681888.332865] scsi 10:0:0:0: Direct-Access SD/MMC Card Reader 1.00 PQ: 0 ANSI: 0
[681888.436605] sd 10:0:0:0: Attached scsi generic sg8 type 0
[681888.439846] sd 10:0:0:0: [sdh] Attached SCSI removable disk
burton@newton:~/mintchip$ sudo mount /dev/sdh mnt
mount: no medium found on /dev/sdh

No distinct USB device name and no actual flash on the USB. Plugging in one of the SD Cards into my reader produces no information from the system and it not recognized as a flash card at all.

This leads me to believe that these are only smart chips. I was under the impression that they were storage with a smart chip. The idea of putting this into the single phone slot and losing all your extra media storage seems a bit of an odd decision.

  • 8 comments

  •   •   about 14 years ago

    burton@newton:~/mintchip/linux$ sudo lsusb -v

    Bus 002 Device 003: ID 058f:6335 Alcor Micro Corp. SD/MMC Card Reader
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 2.00
    bDeviceClass 0 (Defined at Interface level)
    bDeviceSubClass 0
    bDeviceProtocol 0
    bMaxPacketSize0 64
    idVendor 0x058f Alcor Micro Corp.
    idProduct 0x6335 SD/MMC Card Reader
    bcdDevice 1.03
    iManufacturer 1 Generic
    iProduct 2 Mass Storage Device
    iSerial 3
    bNumConfigurations 1
    Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 32
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0x80
    (Bus Powered)
    MaxPower 100mA
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 0
    bAlternateSetting 0
    bNumEndpoints 2
    bInterfaceClass 8 Mass Storage
    bInterfaceSubClass 6 SCSI
    bInterfaceProtocol 80 Bulk (Zip)
    iInterface 0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x01 EP 1 OUT
    bmAttributes 2
    Transfer Type Bulk
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0200 1x 512 bytes
    bInterval 0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x82 EP 2 IN
    bmAttributes 2
    Transfer Type Bulk
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0200 1x 512 bytes
    bInterval 0
    Device Qualifier (for other device speed):
    bLength 10
    bDescriptorType 6
    bcdUSB 2.00
    bDeviceClass 0 (Defined at Interface level)
    bDeviceSubClass 0
    bDeviceProtocol 0
    bMaxPacketSize0 64
    bNumConfigurations 1
    Device Status: 0x0000
    (Bus Powered)

    So bulk IN/OUT and that's it. Any chance the USB chip bulk protocol specs can be published?

  •   •   about 14 years ago

    It might be worthwhile trying to look at how the android version is built. I imagine it has some android specific items, but it does have two library objects that you might be able to use.

    Based on looking at the .net version, all the heavy work is done in the c library, everything actually in .net is just wrapper and helper functions. I'd expect it's the same thing on android/linux.

  •   •   about 14 years ago

    I have looked at the android project and there are 2 .so libraries. I have posted in other dicussions asking for headers to use these libraries. The only way to use the Android libraries is to port Dalvik to ARM Linux since the .jar has DEX bytecodes and would thus not be usable on any other VM.

    Of course I'm going to say again that they should be open sourcing these libraries, both for security reasons and portability. If I can't get this to work on LInux I can't enter anything in the competition; I don't use Windows and my Android phone doesn't have an SD card slot (Nexus S).

  •   •   about 14 years ago

    There's something flaky about the SD card. I managed to get it recognized by using a different external flash reader, but it would only be recognized if I plugged the card into the reader and then plugged in the USB port. After that I managed to mount the card and found nothing bt SMART_IO.CRD.

    I copied SMART_IO_CRD but the file came back full of NULLs so there's something blocking it.

    I tried again with the USB stick thinking I might have tried to mount the whole device rather than a partition, but no, there's only a single device and sill 'no medium found' when trying to mount it.

  •   •   about 14 years ago

    I'm starting to think that my inboard card reader doesn't support MicroSD; is that possible? Are the MicroSD cards adapters not completely compatible with standard SD?

  •   •   about 14 years ago

    No idea about the MicroSD card.

    Sorry, I hadn't really thought about what was involved using the android version. I was just thinking that it's effectively linux based, so that could atleast be a starting point.

    I did a bit of digging through the windows GTSDUpi.dll file. Haven't looked at it to closely, but based on some of the flow and windows system calls, it looks to me what it's doing is basically:

    1. List the drives
    2. List the removable drives (look for mass storage only)
    3. Open a file handle for read or write (presumably to SMART_IO.CRD)
    4. Memory map the file
    5. Run transactions against the file
    6. Close everything off

    Most of the exposed functions are protected by a mutex.

    Presumably to avoid requiring special system drivers, the MicroSD is designed in a way that it uses the filesystem for communication and the standard mass storage drivers. Read's and Write's to the special SMART_IO.CRD file are used for communication.

    I would imagine almost everything would be translateable into posix calls if you know enough about how to do this. One piece I'm really not sure about though is almost all the operations seem to query a windows performance counter.

    Looking at the .net DLL's (way easier to read). Most of the heavy lifting appears to be in the ApduProcessor.executeCommand/SDSCTransmitEx. These functions take a build APDU, and basically create a byte array, and expect a byte response. It could be that they're just using the UnmanagedDll just as a common message passer for the higher level languages.

    When I receive my device, I'll have to see if I can figure out how to snoop the calls to see what data actually get's passed to the device and see if it's the same as what the higher level language sends it. This may make it able to re-create the API in managed only code, and I also think to support multiple devices hooked up to the same computer. It's in there, just not exposed.

  •   •   about 14 years ago

    Is the SD card an SDIO card?

  •   •   about 14 years ago

    I stand corrected on the USB dongle; I didn't realize it was an adapter and not another chip. Putting the chip in caused it to be recognized by the system. I must have been a bit too excited when I got my package yesterday.

Comments are closed.