tips and tricks, on using compact flash under linux

[Kilrah]

Kilrah, the terminology is a bit confusing but what you've linked to is what we'd commonly call "CardBus", not "PCMCIA".
So that adapter will only work on laptops with a 32-bit CardBus slot, not ones with a "PCMCIA" port.

Sure, but precisely the reason the whole thing is confusing is that everybody uses "PCMCIA" for anything in that form factor and Cardbus is never really mentioned... and since CardBus is already 20 years old you can be pretty sure that close to 100% of what's referred to as PCMCIA today is actually CardBus. Specifically I doubt that OP is using a 20+ year old machine...

[ade]

Specifically I doubt that OP is using a 20+ year old machine...

True... the laptop itself should support CardBus.

[isometrik]

I am not sure if that is the case for all drive types, but generally speaking, Linux (and other flavours of *nix) offers two types of block devices: buffered (slower) and raw (faster).

For example, the buffered (slower) block device "/dev/disk0" will have a raw (faster) equivalent block device under "/dev/rdisk0". The raw (faster) block device name is prepended with a "r".

Have a try, it should make the "dd" transfer much faster.

[Rasz]

Specifically I doubt that OP is using a 20+ year old machine...

thats because you dont know the author 13 year old kernel should be a good hint
not to mention pcmcia cf converters are common, there is no electronics inside, just two sockets, cardbus ones are full PCI ide controllers.

[legacy]

PCMCIA stands for "People Can't Memorize Computer Industry Acronyms".   

 

[legacy]

Specifically I doubt that OP is using a 20+ year old machine...

True... the laptop itself should support CardBus.

yes, I enabled the support, 16 and 32bit
my hardware is supported by (kernel module name) "yenta_cardbus"

[legacy]

Code: [Select]

x61s ~ # lspcmcia -v
Socket 0 Bridge:    [yenta_cardbus] (bus ID: 0000:05:00.0)
Configuration: state: on ready: yes

Voltage: 3.3V
 Vcc: 3.3V
 Vpp: 0.0V

Socket 0 Device 0: [ide-cs] (bus ID: 0.0)
Configuration: state: on
[io  0x4100-0x410f flags 0x110]
[io  0x0000 flags 0x100]
[mem 0x00000000 flags 0x200]
[mem 0x00000000 flags 0x200]
[mem 0x00000000 flags 0x200]
[mem 0x00000000 flags 0x200]

Product Name:   SANDISK
 SDCFXS-064G
 
Identification: manf_id: 0x00f1 card_id: 0x0101
function: 4 (fixed disk)
prod_id(1): "SANDISK
" (0xda4ae7f3)
prod_id(2): "SDCFXS-064G
" (0xd2534b65)
prod_id(3): --- (---)
prod_id(4): --- (---)



Code: [Select]

x61s ~ # pccardctl info
PRODID_1="SANDISK
"
PRODID_2="SDCFXS-064G
"
PRODID_3=""
PRODID_4=""
MANFID=00f1,0101
FUNCID=4
x61s ~ #


interesting, the linux kernel module in S/ATA PCMCI support does not recognized MANFID=00f1,0101

drivers/ata/pata_pcmcia.c

Code: [Select]

...
static struct pcmcia_device_id pcmcia_devices[] =
{
        PCMCIA_DEVICE_FUNC_ID(4),
        PCMCIA_DEVICE_MANF_CARD(0x0000, 0x0000),        /* Corsair */
        PCMCIA_DEVICE_MANF_CARD(0x0007, 0x0000),        /* Hitachi */
        PCMCIA_DEVICE_MANF_CARD(0x000a, 0x0000),        /* I-O Data CFA */
        PCMCIA_DEVICE_MANF_CARD(0x001c, 0x0001),        /* Mitsubishi CFA */
        PCMCIA_DEVICE_MANF_CARD(0x0032, 0x0704),
        PCMCIA_DEVICE_MANF_CARD(0x0032, 0x2904),
        PCMCIA_DEVICE_MANF_CARD(0x0045, 0x0401),        /* SanDisk CFA */


[legacy]

Bus options (PCI etc.)  --->  PCCard (PCMCIA/CardBus) support  --->

Code: [Select]

--- PCCard (PCMCIA/CardBus) support                                                             ? ? 
  ? ?                         <*>   16-bit PCMCIA support                                                                     ? ? 
  ? ?                         [*]     Load CIS updates from userspace (EXPERIMENTAL)                                          ? ? 
  ? ?                         -*-   32-bit CardBus support                                                                    ? ? 
  ? ?                               *** PC-card bridges ***                                                                   ? ? 
  ? ?                         <M>   CardBus yenta-compatible bridge support


[legacy]

&& this link seems interesting while this is LoL

[legacy]

interesting, a lot of problems with 2.6.24
CF detected as PIO0 is performing 1.6 MByte/sec 
oh my goodness

Linus' tree is also broken.

I tried a Linus 2.6.24-rc4 and it acts the same way, with a very slow
transfer rate. 

I also tried 2.6.24-rc4 with the older not-libata PATA drivers and it is
broken.  dmesg had a line about the CF card detected as hda,
but /sys/block did not have hda and /dev/hda did not function.

I will try the patches you mentioned, but I think I may also have to
work backward through kernel versions until I find the last one where
the PCMCIA hd{a,b,c,d,e} drivers worked.

( 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash )

[legacy]

also it looks like pata_pcmcia is always PIO mode 0

Code: [Select]

/*
  * pcmcia_init_one - attach a PCMCIA interface
  * @pdev: pcmcia device
  *
  * Register a PCMCIA IDE interface. Such interfaces are PIO 0 and
  * shared IRQ.
  */

jesus 

[legacy]

>>>>> I normally use a USB-2 memory card reader but I also have a PCMCIA
>>>>> CompactFlash adapter that I use occasionally.  During the MM series
>>>>> kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all.  I
>>>>> don't know about vanilla since I don't run that.
>>>>>
>>>>> Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I
>>>>> only get read rates of 1.6 MB/s.  When it used to work in 2.6.20 I got
>>>>> at least 16 MB/s.  The card itself is capable of 30+ in the USB-2
>>>>> reader.

need to check an old kernel 2.6.20

[legacy]

anyone using CF with CardBus over linux 4.* or 3.* ?

going to apply this setup for my laptop
kernel 3.17.7 (even if … I can't upgrade 2.6.39, I am considering a dual boot with grub)

[Monkeh]

You can play with your kernel all you like, it won't change the fact that you need an IDE adapter.

[legacy]

usb-CF adaptor

[legacy]

anyway, I can't understand why, if cardbus is pci-like, then plugging a microdrive on a cardbus-CF adaptor gives more performances than a compact flash

10Mbyte/sec (a few models give 20Mbyte/sec) vs 1.6Mbyte/sec

it's 1:10..1:20, so what is wrong with compact flash? (oh, declared to be "true IDE")

[legacy]

The speed is limited by your CardBus controller, whether it supports UDMAx or not.

according with hdparm there is no UDMAx flags with micro drive, and I get 10-20Mbyte/sec
while with a compact flash in "True-IDE" I get 1.6Mbyte/sec

physically

Code: [Select]

05:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)


Code: [Select]

05:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
Subsystem: Lenovo Device 20c6
Flags: bus master, medium devsel, latency 168, IRQ 16
Memory at d7eff000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=05, secondary=06, subordinate=07, sec-latency=176
Memory window 0: d8000000-dbffffff (prefetchable)
Memory window 1: 80000000-83ffffff
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
16-bit legacy interface ports at 0001
Kernel driver in use: yenta_cardbus



thus, which is the difference between a micro drive interface and a compact flash interface?
(none of them use UDMA, according to the flags I see)

[Monkeh]

CardBus is a multi-purpose bus that can be configured to be IDE, that is to say, there is not a single chip in a CardBus to CF converter. The speed is limited by your CardBus controller, whether it supports UDMAx or not.

Uh.. no, CardBus is effectively PCI. You need a host controller attached to do DMA, or you're stuck with PIO on a 16-bit bus (PCMCIA mode).

[legacy]

You need a host controller attached to do DMA, or you're stuck with PIO on a 16-bit bus (PCMCIA mode).

may be the problem is related to the Yenta_CardBus kernel drive, more specifically there is no specific driver for the host controller
it my case it's "Ricoh", and it seems they probably just re-branded some other generic components.

I typed  "lspci -v" and looked for the device numbers after "Subsystem: Device" for those device.
Then googled for those device numbers to figure out who actually made the chipsets for the devices.

Unfortunately I have found no good information 


anyway, I can explain why the micro drive achieves better performances within the same configuration

[Monkeh]

You need a host controller attached to do DMA, or you're stuck with PIO on a 16-bit bus (PCMCIA mode).

may be the problem is related to the Yenta_CardBus kernel drive, more specifically there is no specific driver for the host controller
it my case it's "Ricoh", and it seems they probably just re-branded some other generic components.

I typed  "lspci -v" and looked for the device numbers after "Subsystem: Device" for those device.
Then googled for those device numbers to figure out who actually made the chipsets for the devices.

Unfortunately I have found no good information 

You have the driver for the cardbus interface, it is not an IDE host controller.

[legacy]

it is not an IDE host controller

you are in my ignore list

[Monkeh]

Uh.. no, CardBus is effectively PCI. You need a host controller attached to do DMA, or you're stuck with PIO on a 16-bit bus (PCMCIA mode).

From Wikipedia,

CompactFlash is a smaller dimensioned 50 pin subset of the 68 pin PC Card interface. It requires a setting for the interface mode of either "memory" or "ATA storage".

Probably that means PCMCIA has a "memory" or "ATA storage" mode or both.

And PCMCIA is not CardBus..

E: Or more correctly, PCMCIA <v5 is not CardBus.

Yes, you can have a 16-bit PIO ATA interface with PCMCIA. Or you can have an IDE controller attached via CardBus and get UDMA.

it is not an IDE host controller

you are in my ignore list

You can lead a horse to water..

[legacy]

mmm from the documentation I also see that "CFA extensions" can allow to use pio5 or pio6 (>20Mbyte/sec)
while from linux sources (2.6.39) I see that the ide-cs can support only pio0 (~1Mbyte/sec)

and again it's not clear why the micro drive achieves 10Mbyte/sec in the same bus, plugged to the same interface, and handled by the same kernel

going to buy a second usb-cd adapter, but … it's a workaround 
(probably I'd better to say to my boss that … his solution is defective)

[legacy]

p.s.
the SSD-miniPCIe was a good tips, faster, cheaper, very good tips
unfortunately I can't open the laptop (it's not mine)

[Monkeh]

Congratulations, you finally bothered to look for an IDE controller!

Sadly, it seems performance on those ones is substandard due to lack of documentation, but it's at least faster than PIO.