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: [email protected] ===================================================================== _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
