how little do i have to do to define flash layout on my system?

how little do i have to do to define flash layout on my system?

[Robert P. J. Day]

  currently, my 8xx 2.4 kernel-based system defines its flash layout
with a proprietary driver file we installed into the "maps" directory,
but i'd like to simplify that approach.

  certainly, i can use command-line partitioning to define all of the
partitions, making the driver file *way* simpler.  can i somehow avoid
even the creation of that driver file (so i don't have to mess with
the kernel source tree at all)?

  i just read that there is a generic driver for accessing CFI flash
chips on systems that have no specific mapping driver.  does this mean
what i think it means?  that i can somehow take advantage of that
generic driver to avoid having to write my own?

  i need to be able to concatenate 2 16M chips into a single 32M
address space, then partition into 5 or 6 partitions.  am i being too
optimistic about not needing my own driver map program if i can use
the "generic" one?

rday

Re: how little do i have to do to define flash layout on my system?

[Cliff Brake]

On Apr 10, 2005 4:41 PM, Robert P. J. Day <rpjday@mindspring.com> wrote:
> 
>   currently, my 8xx 2.4 kernel-based system defines its flash layout
> with a proprietary driver file we installed into the "maps" directory,
> but i'd like to simplify that approach.
> 
>   certainly, i can use command-line partitioning to define all of the
> partitions, making the driver file *way* simpler.  can i somehow avoid
> even the creation of that driver file (so i don't have to mess with
> the kernel source tree at all)?
> 
>   i just read that there is a generic driver for accessing CFI flash
> chips on systems that have no specific mapping driver.  does this mean
> what i think it means?  that i can somehow take advantage of that
> generic driver to avoid having to write my own?

I am using the MTD mechanism for defining the physical area where the
flash lives on several PXA systems:

CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0x0
CONFIG_MTD_PHYSMAP_LEN=0x4000000
CONFIG_MTD_PHYSMAP_BANKWIDTH=4

You can then use the kernel command line to define the partitions:

mtdparts=phys_mapped_flash:256k(boot)ro,0x1C0000(kernel),-(root)

The only tricky part was figuring out the above name
(phys_mapped_flash).  From reading the documentation, I thought I
could leave the name blank, but did not work for me.
 
>   i need to be able to concatenate 2 16M chips into a single 32M
> address space, then partition into 5 or 6 partitions.  am i being too
> optimistic about not needing my own driver map program if i can use
> the "generic" one?

I have not used the above with multiple chips.  MTD layer does have a 
CONFIG_MTD_CONCAT config parameter ...

Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com

Re: how little do i have to do to define flash layout on my system?

[Robert P. J. Day]

On Mon, 11 Apr 2005, Cliff Brake wrote:

> I am using the MTD mechanism for defining the physical area where the
> flash lives on several PXA systems:
>
> CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP_START=0x0
> CONFIG_MTD_PHYSMAP_LEN=0x4000000
> CONFIG_MTD_PHYSMAP_BANKWIDTH=4
>
> You can then use the kernel command line to define the partitions:
>
> mtdparts=phys_mapped_flash:256k(boot)ro,0x1C0000(kernel),-(root)

that's exactly what i was looking at to see if it could do what i
want, but for more than one chip.

> The only tricky part was figuring out the above name
> (phys_mapped_flash).  From reading the documentation, I thought I
> could leave the name blank, but did not work for me.

based on what i've read, i'm pretty sure you need a non-empty mtd-id,
even if you have only one chip.  certainly, a quick glance at
cmdlinepart.c seems to suggest it has to have some value (see the
mtdpart_setup_real() routine).

> >   i need to be able to concatenate 2 16M chips into a single 32M
> > address space, then partition into 5 or 6 partitions.  am i being too
> > optimistic about not needing my own driver map program if i can use
> > the "generic" one?
>
> I have not used the above with multiple chips.  MTD layer does have a
> CONFIG_MTD_CONCAT config parameter ...

i did a bit more reading last night and concluded that the PHYSMAP
stuff would let me define a single flash chip but no more.  so if i
want multiple chips, it *appears* that i have to write a maps file.

rday

Re: how little do i have to do to define flash layout on my system?

[Michael]

> i did a bit more reading last night and concluded that the
> PHYSMAP stuff would let me define a single flash chip but no
more.
> so if i want multiple chips, it *appears* that i have to write a
> maps file.
> 
> rday

Could an alternative be to extend the physmap stuff to handle
multiple chips?  If situations like yours are more common, this
solution will make it simpler for all.

Mike

Re: how little do i have to do to define flash layout on my system?

[Josh Boyer]

On Mon, 2005-04-11 at 07:32 -0400, Robert P. J. Day wrote:
> On Mon, 11 Apr 2005, Cliff Brake wrote:
> 
> > I am using the MTD mechanism for defining the physical area where the
> > flash lives on several PXA systems:
> >
> > CONFIG_MTD_PHYSMAP=y
> > CONFIG_MTD_PHYSMAP_START=0x0
> > CONFIG_MTD_PHYSMAP_LEN=0x4000000
> > CONFIG_MTD_PHYSMAP_BANKWIDTH=4
> >
> > You can then use the kernel command line to define the partitions:
> >
> > mtdparts=phys_mapped_flash:256k(boot)ro,0x1C0000(kernel),-(root)
> 
> that's exactly what i was looking at to see if it could do what i
> want, but for more than one chip.
> 
> > The only tricky part was figuring out the above name
> > (phys_mapped_flash).  From reading the documentation, I thought I
> > could leave the name blank, but did not work for me.
> 
> based on what i've read, i'm pretty sure you need a non-empty mtd-id,
> even if you have only one chip.  certainly, a quick glance at
> cmdlinepart.c seems to suggest it has to have some value (see the
> mtdpart_setup_real() routine).
> 
> > >   i need to be able to concatenate 2 16M chips into a single 32M
> > > address space, then partition into 5 or 6 partitions.  am i being too
> > > optimistic about not needing my own driver map program if i can use
> > > the "generic" one?
> >
> > I have not used the above with multiple chips.  MTD layer does have a
> > CONFIG_MTD_CONCAT config parameter ...
> 
> i did a bit more reading last night and concluded that the PHYSMAP
> stuff would let me define a single flash chip but no more.  so if i
> want multiple chips, it *appears* that i have to write a maps file.

See drivers/mtd/maps/mphysmap.c

josh

Re: how little do i have to do to define flash layout on my system?

[Ralph Siemsen]

Robert P. J. Day wrote:

> i did a bit more reading last night and concluded that the PHYSMAP
> stuff would let me define a single flash chip but no more.  so if i
> want multiple chips, it *appears* that i have to write a maps file.

If the chips are of the same type, physmap.c will do what you want - 
just give it the total size of flash space.  Eg. if you have two 32M 
chips then give the size as 64M.  The MTD code is will probe and 
discover the two chips automatically.  Be sure you specify the 
interleave correctly too.

If the chips are of different types, then the more recent mphysmap.c is 
probably what you need.  (I haven't tried this one).

-R

Re: how little do i have to do to define flash layout on my system?

[Robert P. J. Day]

On Mon, 11 Apr 2005, Michael wrote:

>
> > i did a bit more reading last night and concluded that the
> > PHYSMAP stuff would let me define a single flash chip but no
> more.
> > so if i want multiple chips, it *appears* that i have to write a
> > maps file.
> >
> > rday
>
> Could an alternative be to extend the physmap stuff to handle
> multiple chips?  If situations like yours are more common, this
> solution will make it simpler for all.

i'd thought of that and was already looking at the code.  i think
that, as a start, it wouldn't be hard to add support for multiple,
*identical* chips, each with an arbitrary starting address.

this is what we have here.  is this scenario common enough to warrant
adding that kind of support to physmap?  i can't imagine it would be
that hard.

rday

Re: how little do i have to do to define flash layout on my system?

[Robert P. J. Day]

On Mon, 11 Apr 2005, Josh Boyer wrote:

> See drivers/mtd/maps/mphysmap.c

ah, there is no such map file in my kernel source tree 2.6.11.7, so
that's obviously new.  CVS?

rday

Re: how little do i have to do to define flash layout on my system?

[Robert P. J. Day]

On Mon, 11 Apr 2005, Ralph Siemsen wrote:

> Robert P. J. Day wrote:
>
> > i did a bit more reading last night and concluded that the PHYSMAP
> > stuff would let me define a single flash chip but no more.  so if i
> > want multiple chips, it *appears* that i have to write a maps file.
>
> If the chips are of the same type, physmap.c will do what you want - just give
> it the total size of flash space.  Eg. if you have two 32M chips then give the
> size as 64M.  The MTD code is will probe and discover the two chips
> automatically.  Be sure you specify the interleave correctly too.

and this would work regardless of the addresses of the two chips?
i'll have to look at the code more carefully.

> If the chips are of different types, then the more recent mphysmap.c
> is probably what you need.  (I haven't tried this one).

just got josh's post, i'll be looking into that shortly once i figure
out the best place to get it.

rday

Re: how little do i have to do to define flash layout on my system?

[Josh Boyer]

On Mon, 2005-04-11 at 15:09 -0400, Robert P. J. Day wrote:
> On Mon, 11 Apr 2005, Josh Boyer wrote:
> 
> > See drivers/mtd/maps/mphysmap.c
> 
> ah, there is no such map file in my kernel source tree 2.6.11.7, so
> that's obviously new.  CVS?

Yep.  IIRC, it should be in the latest -mm too.

josh

Re: how little do i have to do to define flash layout on my system?

[Robert P. J. Day]

On Mon, 11 Apr 2005, Josh Boyer wrote:

> On Mon, 2005-04-11 at 15:09 -0400, Robert P. J. Day wrote:
> > On Mon, 11 Apr 2005, Josh Boyer wrote:
> >
> > > See drivers/mtd/maps/mphysmap.c
> >
> > ah, there is no such map file in my kernel source tree 2.6.11.7, so
> > that's obviously new.  CVS?
>
> Yep.  IIRC, it should be in the latest -mm too.

excellent.  so that CVS update should drop in nicely into a 2.6.11.x
source tree, i'm assuming.

and just one more clarification -- what is the current "physmap.c"
capable of in terms of multiple chips and auto-detection?  just
curious.

rday