Determining geometry of Compact Flash

What do you mean by "geometry"? The number of 512-byte blocks is the only geometry I'm aware of. The actual geometry of the flash chip(s) is hidden behind the IDE interface logic. There's all sorts of stuff going on (remapping bad blocks, etc.). Even if you did know the geometry of the flash chip(s) you couldn't do anything with that information.

They're _not_ all the same size. That's the problem. What you have to do is standardize on a partition size that will fit on all the parts from all the vendors. If you're spec'ing 16MB CF cards, you can't depend on more than 16,000,000 bytes, and you probably ought to back off from that number by a couple percent.

How are you doing the "measurements" and why do you think they're "off".

The only thing I ever figured out to do was to generate a master "disk" image that was smaller than the smallest of the CF cards of the size in question.

Kevin,

I'm not sure I understand your exact problem, however it sounds familliar to some of the problem I have encountered (if I am wrong accept my apologies).

When you prepare you cf-disk from /dev/sda it comes to be invalid when you try to boot with weird messages such as L 01 01 01 01 ... or L 04

I faced the same issue and finally opted to use grub as boot-loader rather than lilo. I have to admit my lazyness not to spend more time and figure out what the exact problem was nor the reason of such ... let say behavior. The moment I switched to grub it has run like a charm. I suspected at that time as you said that the geometry lilo use when installing is quite different that the one that will be reported and used at boot time.

If that is not a big problem in you scenario and if that solve the issue, you might consider using grub which does not require a re-install each time you rebuild a kernel a tremendous advantage IMHO for embedded systems.

Hope this helps Regards JM

CF presents itself as having cylinders, tracks and sectors. lilo will not work correctly unless it is given the correct values for those.

Except for when it isn't.

I can find out the geometry of the chip from the BIOS by booting to the BIOS instead of linux. This is how I do it *now*. I then provide this information to lilo, so that it can create a boot block that allows me to boot from the CF into linux.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You're not reading what I wrote.

Completely wrong. The partition size doesn't matter for booting; the geometry does because lilo requires to know that geometry.

I do thank you for bothering to answer.

From your description, you seem to.

I have no problem with the idea, I just don't know how to go about using grub instead of lilo. My experiments with it failed; my excuse is that they were done in my copious free time amidst tremendous pressure to ship.

It's not because of kernel changes I need to do this, it's because the CF chips coming from a single manufacturer, with identical part numbers, do not necessarily have the same geometry as far as lilo is concerned.

It can do this but it's not necessary. I think the _usual_ way to handle a CF is doing the LBA mode.

-Michael

If the BIOS allows it, try enabling LBA32. I've lilo with LBA32 and did not have to specify the CF CHS settings.

Sim>

Thanks - I'll look into it. Unfortunately, while this is a custom BIOS, we don't have access to it; we'll have to get the company that made it for us to fix it.

download this document

It expla> >