All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.