2012/8/16 Shmulik Ladkani :
> Hi,
>
> One more thing...
>
> On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy
> wrote:
>> config MTD_UBI_BEB_LIMIT
>> - int "Percentage of maximum expected bad eraseblocks"
>> - default 2
>> - range 0 25
>> + int "Maximum expected bad eraseblock
On Thu, 2012-08-16 at 10:13 +0200, Richard Genoud wrote:
> > + To put it differently, if this value is 20, UBI will try
> to reserve
> > + about 1.9% of physical eraseblocks for bad blocks
> handling. And that
> > + will be 1.9% of eraseblocks on the entire NAND chip, not
>
On Thu, 2012-08-16 at 11:32 +0300, Shmulik Ladkani wrote:
> > - default 2
> > - range 0 25
> > + int "Maximum expected bad eraseblock count per 1024 eraseblocks"
> > + default 20
> > + range 2 256
>
> Those defconfigs that explicilty set an original LIMIT should be
> adjusted as well,
On Thu, 2012-08-16 at 12:35 +0200, Richard Genoud wrote:
> Ok, I'll change that, may be in a separate patch, as it's a bug fix.
Let me take care of this patch. I'll amend it myself, push to my tree
and re-send to the mailing list for your review. Please, provide an
updated version of the other
On Thu, 2012-08-16 at 11:25 +0300, Shmulik Ladkani wrote:
> I would remove this one sentence from the log, it is misleading; invalid
> blocks are not necessarily related to ECC.
Done.
> + if (mult_frac(limit, 1024, per1024) < device_pebs)
Done, thanks!
--
Best Regards,
2012/8/16 Shmulik Ladkani :
> Hi Artem, Richard,
>
> On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy
> wrote:
>> 1. Invalid blocks are block that contain one or more bad bits beyond
>> ECC.
>
> I would remove this one sentence from the log, it is misleading; invalid
> blocks are not
Hi,
One more thing...
On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy wrote:
> config MTD_UBI_BEB_LIMIT
> - int "Percentage of maximum expected bad eraseblocks"
> - default 2
> - range 0 25
> + int "Maximum expected bad eraseblock count per 1024 eraseblocks"
> + default
Hi Artem, Richard,
On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy wrote:
> 1. Invalid blocks are block that contain one or more bad bits beyond
> ECC.
I would remove this one sentence from the log, it is misleading; invalid
blocks are not necessarily related to ECC.
> if
2012/8/15 Artem Bityutskiy :
> On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote:
>> + /* we are using here the whole MTD device size and not
>> + * the MTD partition size because the maximum number of
>> + * bad blocks is a
2012/8/15 Artem Bityutskiy dedeki...@gmail.com:
On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote:
+ /* we are using here the whole MTD device size and not
+ * the MTD partition size because the maximum number of
+ * bad
Hi Artem, Richard,
On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy dedeki...@gmail.com wrote:
1. Invalid blocks are block that contain one or more bad bits beyond
ECC.
I would remove this one sentence from the log, it is misleading; invalid
blocks are not necessarily related to ECC.
Hi,
One more thing...
On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy dedeki...@gmail.com wrote:
config MTD_UBI_BEB_LIMIT
- int Percentage of maximum expected bad eraseblocks
- default 2
- range 0 25
+ int Maximum expected bad eraseblock count per 1024 eraseblocks
+
2012/8/16 Shmulik Ladkani shmulik.ladk...@gmail.com:
Hi Artem, Richard,
On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy dedeki...@gmail.com
wrote:
1. Invalid blocks are block that contain one or more bad bits beyond
ECC.
I would remove this one sentence from the log, it is misleading;
On Thu, 2012-08-16 at 11:25 +0300, Shmulik Ladkani wrote:
I would remove this one sentence from the log, it is misleading; invalid
blocks are not necessarily related to ECC.
Done.
+ if (mult_frac(limit, 1024, per1024) device_pebs)
Done, thanks!
--
Best Regards,
Artem
On Thu, 2012-08-16 at 12:35 +0200, Richard Genoud wrote:
Ok, I'll change that, may be in a separate patch, as it's a bug fix.
Let me take care of this patch. I'll amend it myself, push to my tree
and re-send to the mailing list for your review. Please, provide an
updated version of the other
On Thu, 2012-08-16 at 11:32 +0300, Shmulik Ladkani wrote:
- default 2
- range 0 25
+ int Maximum expected bad eraseblock count per 1024 eraseblocks
+ default 20
+ range 2 256
Those defconfigs that explicilty set an original LIMIT should be
adjusted as well, as the units
On Thu, 2012-08-16 at 10:13 +0200, Richard Genoud wrote:
+ To put it differently, if this value is 20, UBI will try
to reserve
+ about 1.9% of physical eraseblocks for bad blocks
handling. And that
+ will be 1.9% of eraseblocks on the entire NAND chip, not
just the
2012/8/16 Shmulik Ladkani shmulik.ladk...@gmail.com:
Hi,
One more thing...
On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy dedeki...@gmail.com
wrote:
config MTD_UBI_BEB_LIMIT
- int Percentage of maximum expected bad eraseblocks
- default 2
- range 0 25
+ int
On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote:
> + /* we are using here the whole MTD device size and not
> + * the MTD partition size because the maximum number of
> + * bad blocks is a percentage of the whole device and
> +
On Wed, 2012-07-18 at 10:30 +0200, Richard Genoud wrote:
> So the per1024 thing was really to stick to the device layout and to
> be easier for users (IMHO)
Convinced, thanks!
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
On Wed, 2012-07-18 at 10:30 +0200, Richard Genoud wrote:
So the per1024 thing was really to stick to the device layout and to
be easier for users (IMHO)
Convinced, thanks!
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote:
+ /* we are using here the whole MTD device size and not
+ * the MTD partition size because the maximum number of
+ * bad blocks is a percentage of the whole device and
+
2012/7/18 Artem Bityutskiy :
> On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote:
>>
>> The Kconfig option is in per1024 blocks, thus it can have a default
>> value of 20 which is *very* common for NAND devices.
>
> Why do you prefer per1024? I'd make it centi-percent instead, wouldn't
>
On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote:
>
> The Kconfig option is in per1024 blocks, thus it can have a default
> value of 20 which is *very* common for NAND devices.
Why do you prefer per1024? I'd make it centi-percent instead, wouldn't
that be more human-friendly. It is just
On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote:
The Kconfig option is in per1024 blocks, thus it can have a default
value of 20 which is *very* common for NAND devices.
Why do you prefer per1024? I'd make it centi-percent instead, wouldn't
that be more human-friendly. It is just
2012/7/18 Artem Bityutskiy dedeki...@gmail.com:
On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote:
The Kconfig option is in per1024 blocks, thus it can have a default
value of 20 which is *very* common for NAND devices.
Why do you prefer per1024? I'd make it centi-percent instead,
On NAND flash devices, UBI reserves some physical erase blocks (PEB) for
bad block handling.
Today, the number of reserved PEB can only be set as a percentage of the
total number of PEB in each MTD partition.
For example, for a NAND flash with 128KiB PEB, 2 MTD partition of 20MiB
(mtd0) and 100MiB
On NAND flash devices, UBI reserves some physical erase blocks (PEB) for
bad block handling.
Today, the number of reserved PEB can only be set as a percentage of the
total number of PEB in each MTD partition.
For example, for a NAND flash with 128KiB PEB, 2 MTD partition of 20MiB
(mtd0) and 100MiB
28 matches
Mail list logo
