Hi again, I could hardly believe it myself, but I actually got it working now, finally the patch from the Puppy linux forum did it!
It took me a while to figure out how to use it; because of my limited shell scripting capabilities I had to remove the smart automagic that checks for all available pcmcia sockets (I only have socket 0 anyway), and there seems to be a syntax incompatibility that prevents it from working with /bin/sh here on my squeeze system, but it works with /bin/bash (and I had always thought these were the same, but now I've learned that /bin/sh actually points to /bin/dash ;) and it works with the /bin/sh in the initrd, too. I then did some experimenting and found that a more elegant solution than putting the code into the initrd's init is to put it in a separate file /etc/initramfs-tools/scripts/init-premount/pcmcia-socket-startup.sh which now looks like: ################ #!/bin/sh print_irq_mask() { local digits="0123456789abcdef" i=$1 s="" while [ ${#s} -lt 4 ]; do s=`expr substr $digits $(($i%16+1)) 1`$s let i=$i/16 done echo -n 0x$s } pcmcia_socket_startup() { local i j path mask i=`expr "$1" : '\([0-9]*\)'` if [ "$i" ]; then let j=i else let i=0 j=9 fi while [ $i -le $j ]; do path=/sys/class/pcmcia_socket/pcmcia_socket$i if [ -f $path/available_resources_setup_done ]; then echo -n "0x00000100 - 0x000003af" >$path/available_resources_io echo -n "0x000003e0 - 0x000004ff" >$path/available_resources_io echo -n "0x00000820 - 0x000008ff" >$path/available_resources_io echo -n "0x00000a00 - 0x00000aff" >$path/available_resources_io echo -n "0x00000c00 - 0x00000cff" >$path/available_resources_io echo -n "0x000c0000 - 0x000fffff" >$path/available_resources_mem echo -n "0x60000000 - 0x60ffffff" >$path/available_resources_mem echo -n "0xa0000000 - 0xa0ffffff" >$path/available_resources_mem mask=`cat $path/card_irq_mask` # read old irq mask mask=$(( mask & ~( (1<<4) | (1<<7) ) )) # exclude irq 4,7 print_irq_mask $mask >$path/card_irq_mask # write new irq mask echo -n 42 >$path/available_resources_setup_done fi let i++ done } pcmcia_socket_startup 0 ############### This and the necessary modules added to /etc/initramfs-tools/modules (I added ide_cs, ide_gd_mod, pcmcia, pcmcia_core and yenta_socket, maybe not all were actually necessary, but they don't cost much ;) was all I had to do in the end, then run update-initramfs and the resulting initrd is able to recognize and mount the CF card partition as root file system (update-initramfs again outputs an error message because of the file's syntax, but it seems that this can be safely ignored). Debian apparently does more or less the same as the above script with a utility "pcmcia_socket_startup" that comes with udev and is run by udev after / has been mounted; I had already tried before to run this utility from within the initrd, but it just failed silently without telling me why, and I could not find any usage information on it, so maybe it requires something it does not find in the initrd or it needs a special cli syntax that only udev knows ;) > > I suspect you are correct - I'm beginning to suspect you have a 16-bit > PCMCIA bus which would complicate things (and I don't know much about > them, or self-mutilation) I think you are right pccardctl status says 3.3V 16-bit PC Card Maybe this explains why, as I now found, the CF card is slow as hell, it actually seems to be much slower now than running the system from an USB flash drive, and I/O operations seem to cause a considerable CPU load :( Anyway, in cases when I want to use it, speed is not much of an issue, so I will give it a try anyway, and if I later find that the USB drive wins, then at least I have learned something ;) > > > I still believe that it might have to do with the CF card being > > marked as "removable" and the way udev handles these devices, however > > I don't have a "fixed" card at hand to verify this. In fact I am not > > even sure that it is "removable"; thunar shows it as removable > > device, however udevadm info says ATTR{removable}=="0" . Hmmm... > > Perhaps, I wouldn't put too much stock in udev (it's like Wikipedia). Anyway, now it seems that apparently the problem had nothing to do with the card being "removable" or not. Thanks for all your help, and best regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. Madness has no purpose. Or reason. But it may have a goal. -- Spock, "The Alternative Factor", stardate 3088.7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120123123713.e646fef5.klappn...@freenet.de