[LinuxBIOS] Epia MII, Compact Flash and device nodes

[Markus Tornqvist]

On Wed, Sep 19, 2007 at 10:47:41PM +0200, Peter Stuge wrote:
>On Wed, Sep 19, 2007 at 06:30:14PM +0300, Markus Törnqvist wrote:
>> 
>> pcmcia: request for exclusive IRQ could not be fulfilled.
>> pcmcia: the driver needs updating to supported shared IRQ lines.
[...]
>> 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.

Grim.

>> http://pcmcia-cs.sf.net/'s mail archives speak of irq problems at
>> least.
>> I will definitely look into this further later.
>http://www.kernel.org/pub/linux/utils/kernel/pcmcia/powerbugs.html
>pcmcia-cs is deprecated. Only useful for old 2.4 kernels.

Seems one of the most difficult things in this project of mine
is knowing what really is deprecated...

>> >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.

...like I could swear the alternative to CONFIG_IDE said it was the
old one...

>> 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
>> along?
>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.

Since I'm not on the CF yet, it's on the nfsroot I use to install
from, so I know it's available because I can use another tty to
read the scripture and so :)

>> Documentation/pcmcia/devicetable.txt isn't really clear either
>> on where I'm supposed to put those crc32 hashes...
>
>They go into the drivers.
>
>--8<-- drivers/ide/legacy/ide-cs.c
>        PCMCIA_DEVICE_PROD_ID12("IBM", "microdrive", 0xb569a6e5, 0xa6d76178),
>        PCMCIA_DEVICE_PROD_ID12("IO DATA", "PCIDE", 0x547e66dc, 0x5c5ab149),
>-->8-- etc..

That's the place I couldn't find. Thanks :)

>> >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.
>Not possible.

I got a different impression on IRC, but this is something to get back to.

>> 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...
>4Mbit == 512kb

harrumph, yes, in this modern day and age of extreme storage it's easy
to say du -sk and think "yay kilobits" :P

Do you know if the SST49LF160C (the 2MB one from the kdrive demo video)
works on an Epia though the specs say 2/4Mbit?

(I guess this is general theoretics, is there a single mbr-style entry
point on every flash chip that gets accessed so the size doesn't matter :)

>> 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.

I was actually thinking about using FAI to flash the BIOSes, but there
is no mutual exclusion here; I might as well use Etherboot to boot
into FAI and change the chip to something else and having then
flash.

Well, now's not the best moment to think about possibilities and
they are endless anyway. :)

>Then once everything is working, build a new LB and flash the final
>version.

Yes.

>> >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.

Well, yet more food for the todo list :>

>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

Then it's only a good thing I'm on 2.6.18 now and nothing stops
me from using a later one.

>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. :)

That's how it often goes :)

>> 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
>other things.

Indeed this is so, but there is also an old saying "if you beat your
head to the wall long enough, the wall will eventually give up." ;)

Anyway, it seems I haven't even really started beating my head to the
wall so there's a lot left to do :)

Thank you!

-- 
mjt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070920/7932f2f0/attachment.sig>