[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Stefan Roese <sr@denx.de>]

On Monday 06 July 2009 10:37:10 Mike Frysinger wrote:
> 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"

Yes, this doesn't make much sense. It's probably better to only use the 2nd 
approach via the mtdparts/mtdids name.

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

Correct. And such glue layers could be added for other FLASH technologies like 
SF as well.

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

I think this is a doable approach. But we first need a general consent on 
this. Other opinions on this are welcome...

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