[U-Boot] [PATCH v5 4/5] mtdparts: add new sub-command "spread"
Ben Gardiner
bengardiner at nanometrics.ca
Tue Aug 31 15:51:35 CEST 2010
On Mon, Aug 30, 2010 at 5:01 PM, Scott Wood <scottwood at freescale.com> wrote:
> On Mon, 30 Aug 2010 13:38:59 -0400
> Ben Gardiner <bengardiner at 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
<laforge at 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 <scottwood at freescale.com> wrote:
> On Mon, 30 Aug 2010 16:01:05 -0500
> Scott Wood <scottwood at 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
More information about the U-Boot
mailing list