public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Cliff Brake <cliff.brake@gmail.com>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: MTD mailing list <linux-mtd@lists.infradead.org>
Subject: Re: how little do i have to do to define flash layout on my system?
Date: Mon, 11 Apr 2005 05:55:01 -0500	[thread overview]
Message-ID: <f96d234e050411035522064e02@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain>

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

  reply	other threads:[~2005-04-11 10:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-10 21:41 how little do i have to do to define flash layout on my system? Robert P. J. Day
2005-04-11 10:55 ` Cliff Brake [this message]
2005-04-11 11:32   ` Robert P. J. Day
2005-04-11 17:01     ` Josh Boyer
2005-04-11 19:09       ` Robert P. J. Day
2005-04-11 19:15         ` Josh Boyer
2005-04-11 19:30           ` Robert P. J. Day
2005-04-11 17:08     ` Ralph Siemsen
2005-04-11 19:11       ` Robert P. J. Day
  -- strict thread matches above, loose matches on Subject: below --
2005-04-11 16:47 Michael
2005-04-11 19:08 ` Robert P. J. Day

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f96d234e050411035522064e02@mail.gmail.com \
    --to=cliff.brake@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=rpjday@mindspring.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox