On Mon, Aug 30, 2010 at 5:01 PM, Scott Wood <scottw...@freescale.com> wrote: > On Mon, 30 Aug 2010 13:38:59 -0400 > Ben Gardiner <bengardi...@nanometrics.ca> wrote: > >> +static void spread_partition(struct mtd_info *mtd, struct part_info *part, >> + uint64_t *next_offset) >> +{ >> + uint64_t net_size, padding_size = 0; >> + int truncated; >> + >> + mtd_get_len_incl_bad(mtd, part->offset, part->size, &net_size, >> + &truncated); >> + >> + /* >> + * Absorb bad blocks immediately following this >> + * partition also into the partition, such that >> + * the next partition starts with a good block. >> + */ > > Why is the first block of a partition special?
This (arbitrary) decision to re-assign the bad-blocks that would normally be at the start of the next partition to the end of this partition is carried forward from the design of Harald Welte <lafo...@gnumonks.org> from the openmoko u-boot feature [1]. Since the behaviour of the read and write commands (as you well know) is to skip bad blocks, the same end result of any read or write would be obtained regardless of whether the bad-blocks were assigned to the end of this partition or the start of the the next partition -- I think this is what you are getting at with your question: there is nothing special about the first block of a partition. One particular advantage to assigning these bad blocks to the end of the partitions is that reads and writes on any partitions occurring later during the execution of u-boot (and of Linux if the same mtdparts are passed as a boot variable) will not have to skip immediately past the bad block(s) at the beginning of the partition. I can easily reverse the behaviour here to keep the bad blocks at the beginning of the current partition if that is what you would prefer. But unless you say so I will keep it as-is to preserve the design from openmoko. >> + if (!truncated) { >> + mtd_get_len_incl_bad(mtd, part->offset + net_size, >> + mtd->erasesize, &padding_size, >> &truncated); >> + padding_size -= mtd->erasesize; > > What if this is the last partition? You're relying on an > implementation quick (bug?) that mtd_get_len_incl_bad() will let you > exceed the device size by a block if you start there. If it returned > the more expected zero in such a case, you'll end up subtracting a > block from net_size. On Mon, Aug 30, 2010 at 5:05 PM, Scott Wood <scottw...@freescale.com> wrote: > On Mon, 30 Aug 2010 16:01:05 -0500 > Scott Wood <scottw...@freescale.com> wrote: > Grr, s/quick/quirk/ Got it. You're absolutely right I will add an additional check of the truncated return value. Best Regards, Ben Gardiner [1] http://git.openmoko.org/?p=u-boot.git;a=commitdiff;h=e05835df019027391f58f9d8ce5e1257d6924798 --- Nanometrics Inc. http://www.nanometrics.ca _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot