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/%27s 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 :)
- 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!