[LinuxBIOS] Epia MII, Compact Flash and device nodes

Peter Stuge peter at stuge.se
Mon Sep 17 19:03:29 CEST 2007


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




More information about the coreboot mailing list