[LinuxBIOS] Epia MII, Compact Flash and device nodes
peter at stuge.se
Wed Sep 19 22:47:41 CEST 2007
On Wed, Sep 19, 2007 at 06:30:14PM +0300, Markus Törnqvist wrote:
> Thank you for your excellent reply!
Glad you managed to read it all! :)
> >> I've been reading dmesg and tested sda, I should have mentioned
> >> that, but that didn't help...
> >Please send us your dmesg output.
> I actually have a mount now!! :)
> I will explain details further below, but here's what I hope is
> pcmcia: request for exclusive IRQ could not be fulfilled.
> pcmcia: the driver needs updating to supported shared IRQ lines.
> Probing IDE interface ide2...
> hde: ELITE PRO CF CARD 1GB, CFA DISK drive
> usbcore: registered new driver hiddev
> input: USB Multimedia Keyboard as /class/input/input0
> input: USB HID v1.00 Keyboard [ USB Multimedia Keyboard ] on
> ide2 at 0x100-0x107,0x10e on irq 5
> hde: max request size: 128KiB
> hde: 2031120 sectors (1039 MB) w/1KiB Cache, CHS=2015/16/63
> hde: hde1
> ide-cs: hde: Vpp = 0.0
> The entirety is attached.
> So the driver is broken wrt irq handling?
Yeah. It doesn't matter if the Ricoh controller has it's own
interrupt and/or if you only ever have either CF or PCMCIA but not
both. I don't remember if there's a shared IRQ on the MII.
> >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.)
> http://pcmcia-cs.sf.net/'s mail archives speak of irq problems at
> I will definitely look into this further later.
pcmcia-cs is deprecated. Only useful for old 2.4 kernels.
> >Then; are you using new PATA or old ATAPI/IDE drivers? Make sure you
> I'm on the new one, CONFIG_IDE
No, that's the old one. Try moving over to pata_pcmcia instead,
ide-cs is sort-of deprecated too. pata_pcmcia does shared IRQs.
> >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.
> I'm not sure I understand this part, at least completely, sorry.
> This is not handleable by udev, to have the rules there for
> creating nodes? Or do I need to patch the drivers to have udev play
Where is your udev stored? If the answer is "on the CF" think about
how it gets loaded. The kernel driver has to like the CF.
> Documentation/pcmcia/devicetable.txt isn't really clear either
> on where I'm supposed to put those crc32 hashes...
They go into the drivers.
PCMCIA_DEVICE_PROD_ID12("IBM", "microdrive", 0xb569a6e5, 0xa6d76178),
PCMCIA_DEVICE_PROD_ID12("IO DATA", "PCIDE", 0x547e66dc, 0x5c5ab149),
> >1. If FILO is to load the kernel from the Ricoh slot #1, the Ricoh
> I'm actually thinking about skipping FILO if possible, so I have
> the kernel and and a small-enough initrd as the payload.
> Have to admit I haven't really checked sizes yet, but the via
> spec said the bios is 2/4Mbit, so 4Mbit should fit pretty much...
> Any thoughts on this?
4Mbit == 512kb
> >2. Pluggable device events are handled in a separate kernel
> This may turn out to be a severe problem.
> Anyway, my roadmap is pretty much that next up I'll set up a local
> debian repository so I can install a kernel.
> .. And then there will be linuxbios, finally :)
I like LB with Etherboot because it's so simple to throw different
payloads at the system. Just change the dhcpd config and reset the
board to try different payload.
Then once everything is working, build a new LB and flash the final
> >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
> Even if it were available I doubt it would patch in very cleanly,
No, certainly not. But it would at least show where exactly in the
boot process the delay goes.
> so something needs to be figured out.
I should ask linux-kernel about this some day.
> >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
> What is "almost worked", please? :)
I don't remember so I tried to get away with being vague. :p
I think I posted all relevant dmesg logs to the list last September
but I may have left the last experiments out - not sure.
There were issues when using ide-cs. pata_pcmcia wasn't ready yet.
MANY changes especially for ATA/IDE went into 2.6.18 and it took some
time to stabilize. I needed to get the board running and went for the
IDE->CF adapter as a workaround. Since then my MII board caps blew so
the board doesn't run anymore. If I can get hold of replacement caps
of high quality it would be nice to get it working again. (Though I
bought it really cheap and I also have a -CN board that I'd like to
play with instead. :)
> >I do not want to be dumbing it down with a non-hotplug-aware
> >driver. You may be fine with that.
> That's almost the same type of defeat-admission as using a separate
> cf-ide adapter, which I'd rather pass up on.
These are the cards we are dealt as cutting edge early adopters and
developers. We will always get screwed out of something. But we gain
More information about the coreboot