[solved] Re: Unable to boot into CompactFlash card - card not found by initrd

[Michael Lange <klappnase@freenet.de>]

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