From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefan Roese <sr@denx.de>
Date: Mon, 6 Jul 2009 09:25:43 +0200
Subject: [U-Boot] [PATCH] flread: new command for reading indirect
	mapped flashes
In-Reply-To: <200907060304.46176.vapier@gentoo.org>
References: <1246387465-13156-1-git-send-email-vapier@gentoo.org>
	<200907060710.58602.sr@denx.de>
	<200907060304.46176.vapier@gentoo.org>
Message-ID: <200907060925.43846.sr@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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