Determining geometry of Compact Flash

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
We are using an IDE compact flash reader, which the system sees as
/dev/sda.  We need to programmatically determine the actual geometry of
the flash chip for lilo purposes, and we have chips of all different
sizes.  (Surprise!  Your 16MB flash can have anywhere from 15M to 24M with
all kinds of geometries even when they're exactly the same size.)

The BIOS of the unit correctly determines the geometry, but all of linux's
measurements are way off.  Isn't there *some* way to find out the *TRUTH*?
This is keeping us from automating production.  Thanks in advance.

If you require some kind of reward for the answer, please let me know in
advance; it's possible we can work something out for a real solution.


--
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
We've slightly trimmed the long signature. Click to see the full one.
Re: Determining geometry of Compact Flash

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

--
Grant Edwards                   grante             Yow!  I'd like TRAINED
                                  at               SEALS and a CONVERTIBLE on
We've slightly trimmed the long signature. Click to see the full one.
Re: Determining geometry of Compact Flash

Quoted text here. Click to load it

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



Quoted text here. Click to load it

Except for when it isn't.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quoted text here. Click to load it

You're not reading what I wrote.


Quoted text here. Click to load it

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.

--
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
We've slightly trimmed the long signature. Click to see the full one.
Re: Determining geometry of Compact Flash
Quoted text here. Click to load it

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

-Michael

Re: Determining geometry of Compact Flash
If the BIOS allows it, try enabling LBA32. I've lilo with LBA32 and did not
have to
specify the CF CHS settings.

Simon Paradis

Quoted text here. Click to load it



Re: Determining geometry of Compact Flash
On Mon, 24 Jan 2005 02:24:54 GMT, "Simon Paradis"


Quoted text here. Click to load it

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.


--
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
We've slightly trimmed the long signature. Click to see the full one.
Re: Determining geometry of Compact Flash
download this document

http://www.sandisk.com/pdf/oem/cf-manual-10.7.pdf

It explains all about CF

Kevin D. Quitt wrote:
Quoted text here. Click to load it

Re: Determining geometry of Compact Flash
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
04 04 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


Re: Determining geometry of Compact Flash

Quoted text here. Click to load it

From your description, you seem to.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.

--
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline