Hi,
On Mon, Sep 17, 2007 at 10:43:35AM +0300, Markus Tornqvist wrote:
The problem: I'm not seeing the cflash /dev/hde. It's found a-ok by lspcmcia and pccardctl, as well as cating /sys (which is apparently pretty much what udevinfo does as well)
udev can be a bit tricky. You might check to see if the cflash is showing up as /dev/sda
try: dmesg | more
I've been reading dmesg and tested sda, I should have mentioned that, but that didn't help...
Please send us your dmesg output.
The yenta_socket is found tho.
It appears to be abstracted behind a cardbus whatever interface and therefore it would probably need something extra to work, right?
The CF slot is PCMCIA slot #1 in the Ricoh RL5c476 controller, which by the way appears to be quite a crappy piece of hardware. (There are known, unfixed, hard-to-fix bugs with it specifically mentioned on the Linux PCMCIA page.)
There's still other mojo to try out, if I want to get creative, like this devfs reimplementation
Don't waste your time.
Needless to say, stuff like that is fetching from pretty far and I'd much rather get it working any standard way :)
It would anyway seem that pcmcia ide stuff should Just Work,
Yes.
But I couldn't get it running..
First of all, make sure you build your own kernel so you have control of things.
Then; are you using new PATA or old ATAPI/IDE drivers? Make sure you have PCMCIA PATA support or PCMCIA IDE support enabled, respectively.
Either way, the particular flash card you are using needs to be recognized by the kernel driver in order for things to work automagically. Run pccardctl info with the card inserted to get the PRODID_* strings you need - then calculate the CRC32 hash that needs to go into the kernel - see /usr/src/linux/Documentation/pcmcia/crc32hash.c and add the hashes to both drivers. Please send a patch to the linux-pcmcia mailing list with them as well.
When using LB there are at least two tricky problems with what you (and I) want to accomplish:
1. If FILO is to load the kernel from the Ricoh slot #1, the Ricoh chip seems to need to be configured in a way which later causes Linux to not be able to pick it up as a PCMCIA controller. This is surely a problem with how LB initializes the Ricoh, combined with, ehm, "design decisions" in the FILO IDE driver.
2. Pluggable device events are handled in a separate kernel thread, which means that the root device may not be available by the time Linux wants to mount root even though the card is physically plugged in - because the coldplug event has not been processed and the device has not yet been added to the kernel-internal device tree.
1 needs further investigation. I gave up on it because I did not understand 2 completely when I first looked at this. If you search the LB archives for September 2006 you'll find some posts by me babbling about the CF situation on the EPIA-MII.
Others have encountered 2 when wanting to boot e.g. from 1394 disks. IBM has an article on this from early 2.4 kernel times. The suggested workaround was to add a few seconds delay to the kernel before it tries to mount root, so that the coldplug event is handled first. That's crazy ugly of course, but it works. Unfortunately the patch for the ancient kernels is no longer available so it will have to be re-invented. :(
It's also possible to configure the Ricoh slot #1 as a static IDE device - ie. not hot-pluggable and using the plain PATA/IDE drivers, not the PCMCIA ones. Then it works fine in FILO, and it almost worked with 2.6.18. A lot has happened in the kernel since so I think chances are good for it to work perfectly now. The problem with this is that the slot IS hot-pluggable so I do not want to be dumbing it down with a non-hotplug-aware driver. You may be fine with that.
Finally, if you haven't gotten to booting with LB yet and are still working with the factory BIOS you are just having some silly driver issue in your kernel. Get that fixed (possibly you need to add your card CRC32 hashes to the drivers) and you'll be on your way.
//Peter