Hello!
I hope I'm not too far off the mark, and this is semi-offtopic, but what I'm wondering about is udev and compact flash.
What I'm doing is installing Debian with FAI[1] and afterwards would be flashing the bios with LinuxBios. The FAI installation works on a regular hard drive just perfectly.
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)
I searched the archives and they seem to point me towards etherboot like http://www.mail-archive.com/linuxbios@clustermatic.org/msg03583.html but especially stages 4-6 in that list seem to be something I'm not planing on doing at the moment.
My idea is to do whatever it takes to get FAI to install on the cflash and use that to make an initrd payload to the make a root of the card.
What do I need to get this thing going?
Thanks!
[1] http://www.informatik.uni-koeln.de/fai/
PS. Unfortunately a lot of the other mail traffic is about using an adapter; imo that sort of defeats the purpose of having an integrated bridge...
On Mon, 17 Sep 2007, Markus Tornqvist wrote:
Hello!
I hope I'm not too far off the mark, and this is semi-offtopic, but what I'm wondering about is udev and compact flash.
What I'm doing is installing Debian with FAI[1] and afterwards would be flashing the bios with LinuxBios. The FAI installation works on a regular hard drive just perfectly.
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
Russ
On Mon, Sep 17, 2007 at 12:28:42AM -0700, Russell Whitaker 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...
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?
There's still other mojo to try out, if I want to get creative, like this devfs reimplementation I heard of (afaik a one-day hack probably unsupported) if it needs to be in the kernel and whatever.
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, http://reactivated.net/writing_udev_rules.html#example-usbcardreader like with minor modifications.
But I couldn't get it running..
Cheers!
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
On Mon, Sep 17, 2007 at 07:03:29PM +0200, Peter Stuge wrote:
Hi,
Thank you for your excellent reply!
On Mon, Sep 17, 2007 at 10:43:35AM +0300, Markus Tornqvist wrote:
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 relevant:
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 usb-0000:00:10.0-2 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?
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.)
http://pcmcia-cs.sf.net/%27s mail archives speak of irq problems at least.
I will definitely look into this further later.
But I couldn't get it running..
First of all, make sure you build your own kernel so you have control of things.
This I am doing, fortunately.
Then; are you using new PATA or old ATAPI/IDE drivers? Make sure you
I'm on the new one, CONFIG_IDE
have PCMCIA PATA support or PCMCIA IDE support enabled, respectively.
Here I made a stupid mistake, didn't notice it under the pcmcia menus so I searched for PCMCIA, so I missed it, as it's under the IDE menu with the name CONFIG_BLK_DEV_IDECS so my bad there :(
I recompiled my FAI installer kernel with that on and it Just Worked :)
So that was the faulty point.
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 along?
Documentation/pcmcia/devicetable.txt isn't really clear either on where I'm supposed to put those crc32 hashes...
Anyway, seems my card is supported anyway but it would be interesting to know this stuff :>
When using LB there are at least two tricky problems with what you (and I) want to accomplish:
- 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.
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?
It is still always sad when hardware doesn't really work or is very hard to fix :/
- 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.
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.
Then I'll have FAI install on the cf.
After that (because seems it's now supported) I'll test boot with the factory bios and grub.
.. And then there will be linuxbios, finally :)
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.
After I get this message out.
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. :(
Even if it were available I doubt it would patch in very cleanly, so something needs to be figured out.
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? :)
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.
That's almost the same type of defeat-admission as using a separate cf-ide adapter, which I'd rather pass up on.
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.
Would seem to be limited to whatever bad mojo's still coming wrt the ricoh.
Thank you once again!
Hey!
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!! :)
Good.
I will explain details further below, but here's what I hope is relevant:
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 usb-0000:00:10.0-2 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/%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.
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 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.
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..
- 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.
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
- Pluggable device events are handled in a separate kernel
thread,
This may turn out to be a severe problem.
Right.
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 version.
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 other things.
//Peter
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!
On Thu, Sep 20, 2007 at 09:44:42AM +0300, Markus Tornqvist wrote:
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.
The ide-cs is bitrotting since there's a new shiny pata_pcmcia.
The new sata/pata code is presumably much better than old ide anyway.
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...
Going into embedded means knowing many things. :)
- If FILO is to load the kernel from the Ricoh slot #1, the
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
And this is why I say not possible. Kernel+initramfs doesn't fit in 512kb. (Or has someone managed this now? That would be sweet!)
Do you know if the SST49LF160C (the 2MB one from the kdrive demo video) works on an Epia though the specs say 2/4Mbit?
It does not.
(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 :)
Not so unfortunately. There is the matter of the bus that the flash chip is connected to. The MII uses parallel flash which is basically connected to an ISA bus. There's only room for 19 address lines on the 32-pin flash chips so 512kb is the ceiling.
Newer systems connect the boot flash through LPC or SPI, which are both basically serial buses, and then the limit becomes a matter of what the serial protocol supports and what the chip on the other side of the bus supports.
The largest common NOR flash for LPC is currently 16Mbit and the chipsets already support 16, 32 or 64 Mbit so there's still some room to grow.
Until LB or EFI really takes off I don't think there will be any larger flash parts readily available.
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.
Get the latest possible. 2.6.18 is a year old and not so hot. Grab 2.6.22.6.
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." ;)
Unless time runs out or the head breaks first. :(
//Peter
-
Markus Tornqvist -
mjt＠nysv.org
-
Peter Stuge -
Russell Whitaker