All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] flread: new command for reading indirect mapped flashes
Date: Mon, 6 Jul 2009 04:37:10 -0400	[thread overview]
Message-ID: <200907060437.11544.vapier@gentoo.org> (raw)
In-Reply-To: <200907060925.43846.sr@denx.de>

On Monday 06 July 2009 03:25:43 Stefan Roese wrote:
> On Monday 06 July 2009 09:04:44 Mike Frysinger wrote:
> > > I kind of like the idea to create a new set of commands for accessing
> > > such board specific NOR FLASH (can be used on "normal" NOR FLASH as
> > > well). Perhaps we could make it "generic" in a way that it can be used
> > > for all kind of "MTD devices". How about this "mtd" commandset:
> > >
> > > Select MTD NOR device #1 (2nd NOR device):
> > > => mtd device nor 1
> > >
> > > Or via mtdparts/mtdids:
> > > => mtd device nor0
> >
> > so both syntaxes would be available when mtdparts support is enabled, or
> > would it be one or the other ?
>
> I didn't make my mind up until now. I was just throwing out an idea.
>
> > we would want to avoid ambiguity -- is
> > "nor" referring to the nor flashes or is it referring to a partition
> > named "nor".
>
> The first version would refer "nor" as flash type and the 2nd one "nor0" as
> a device name from mtdparts/mtdids.

so people wouldnt be able to name a mtdpart "nor"

> > what flash devices does mtdparts support now ?  i'm not really familiar
> > with it and the README and doc/ files doesnt seem to cover it.
>
> Right now it supports NAND, OneNAND and NOR (if CONFIG_FLASH_CFI_MTD is
> enabled). Others can be easily added (see drivers/mtd/cfi_mtd.c for NOR).

so FLASH_CFI_MTD is merely glue between the existing CFI flash driver and the 
MTD layers ?

> > i guess each flash type would parse the additional commands however it
> > liked and so the mtd command would just act as a multiplexer at this
> > point. the current spi flash "sf" command is pretty flexible -- you
> > specify the spi chip select to select the device and you can specify
> > other parameters dynamically (like frequency).  so when folding it in,
> > we'd have: => mtd device sf <cs> [speed] [mode]
> >
> > common/cmd_mtd.c
> > common/cmd_mtd_sf.c
> > common/cmd_mtd_nor.c
>
> I was more thinking about adding the MTD layer to all FLASH types supported
> by this new commandset. Then accessing the device is done via the MTD
> functions pointers (mtd->erase, mtd->read, etc). Special FLASH type
> specific stuff still needs to be handled in some additional drivers (like
> OOB handling for NAND/OneNAND, or SF specific stuff) though.

ok, this seems like it should be doable in a gradual progression.  i.e. today 
i am only concerned with nor flash, so getting a base framework with that as 
the only supported flash should be fine.  once we know it can replace the 
existing cmd_flash.c functions, we can look at folding in other flash types.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090706/f667c052/attachment.pgp 

  reply	other threads:[~2009-07-06  8:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-30 18:44 [U-Boot] [PATCH] flread: new command for reading indirect mapped flashes Mike Frysinger
2009-06-30 19:01 ` Mike Frysinger
2009-07-04 23:39 ` Wolfgang Denk
2009-07-05  3:07   ` Mike Frysinger
2009-07-05 15:15     ` Wolfgang Denk
2009-07-05 17:12       ` Mike Frysinger
2009-07-05 17:55         ` Wolfgang Denk
2009-07-05 19:03           ` Mike Frysinger
2009-07-05 20:34             ` Wolfgang Denk
2009-07-06  5:10               ` Stefan Roese
2009-07-06  5:59                 ` Mike Frysinger
2009-07-06  6:24                   ` Stefan Roese
2009-07-06  7:04                 ` Mike Frysinger
2009-07-06  7:25                   ` Stefan Roese
2009-07-06  8:37                     ` Mike Frysinger [this message]
2009-07-06  8:47                       ` Stefan Roese
2009-07-10 14:27                         ` Stefan Roese
2009-07-10 14:31                         ` Mike Frysinger
2009-07-06  6:42               ` Mike Frysinger
2009-07-06  8:03                 ` Wolfgang Denk

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=200907060437.11544.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=u-boot@lists.denx.de \
    /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.