On 08/27/2010 04:36 PM, Ben Gardiner wrote: > On Fri, Aug 27, 2010 at 9:51 AM, Ben Gardiner > <bengardi...@nanometrics.ca> wrote: > I have performed a refactoring but I have reached an impasse: the > 'mtdparts spread' command is written for mtd devices whereas the > get_len_incl_bad() function is for NAND devices. I extracted a > function, mtd_get_len_incl_bad(), to which both the spread_partition > and nand_utils.c:get_len_incl_bad() function then delegated.
I figured the NAND code could just call the MTD-ized get_len_incl_bad() directly. > But since a board may have NAND enabled but not MTD_DEVICE (i.e. guruplug) I > get > link errors sometimes. Grr... Eventually we ought to make NAND depend on MTD_DEVICE. It's 808 bytes currently in my build, but if we could get rid of/reduce specialized client code, it could more than make up for it. For now, I guess don't worry about sharing the code. > ATM I'm thinking of leaving the original > implementation of get_len_incl_bad in an #else. An alternative is to > move 'mtdparts spread' to 'nand mtdparts.spread' -- only OneNAND and > NAND devices (currently) have bad_block functions. There's too much duplication between NAND and OneNAND as is; I'd rather do it at the MTD layer. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
