From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Mon, 6 Jul 2009 10:47:41 +0200 Subject: [U-Boot] [PATCH] flread: new command for reading indirect mapped flashes In-Reply-To: <200907060437.11544.vapier@gentoo.org> References: <1246387465-13156-1-git-send-email-vapier@gentoo.org> <200907060925.43846.sr@denx.de> <200907060437.11544.vapier@gentoo.org> Message-ID: <200907061047.41621.sr@denx.de> List-Id: 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 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 [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 =====================================================================