All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] flread: new command for reading indirect mapped flashes
Date: Mon, 6 Jul 2009 09:25:43 +0200	[thread overview]
Message-ID: <200907060925.43846.sr@denx.de> (raw)
In-Reply-To: <200907060304.46176.vapier@gentoo.org>

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.

> 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).

> 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.

BTW: Adding the MTD layer to those other FLASH types like SF has the 
advantage, that things like UBI/UBIFS could be used on those devices as well.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

  reply	other threads:[~2009-07-06  7:25 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 [this message]
2009-07-06  8:37                     ` Mike Frysinger
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=200907060925.43846.sr@denx.de \
    --to=sr@denx.de \
    --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.