From: Boaz Ben-David <boaz.bd@wellsense-tech.com>
To: Juergen Beisert <jbe@pengutronix.de>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: protecting env partitions from bad blocks
Date: Sun, 5 Jun 2011 15:38:40 +0300 [thread overview]
Message-ID: <4DEB78D0.6070408@wellsense-tech.com> (raw)
In-Reply-To: <201106051411.55383.jbe@pengutronix.de>
Hi Juergen,
Thanks for your reply.
Please correct me if I'm wrong here, but from what you are saying, if my
flash has a block
size of 512KB (thats the erase size also) and I define the env partition
to have say 5 blocks with one that is bad
I'm covered if I do my read/write operations using a bb device.
Also, say a block gets wear out after extended use, will it be marked
bad after a failed write operation for example?
I think the quiestion above is actually if Barebox can handle a block
going bad in it's environment?
Thanks,
Boaz.
On 06/05/11 15:11, Juergen Beisert wrote:
> Hi,
>
> Boaz Ben-David wrote:
>> I want to protect the env partition on my device from bad blocks
>> (created during operation or already there out of the factory).
> Maybe you mean the same, but you cannot really _protect_ them from bad blocks.
>
>> Couldn't find any good documentation regarding this issue, so I have
>> some questions:
>>
>> 1. Exactly what capabilities the bb devices in Barebox give me?
> Handling a flash based memory in a linear manner, even if there are "holes" in
> the memory.
>
> non-bb |---------------------|BB|------------------------------|
> |---ESU--|
> bb |-----------------------------------------------|
>
> Reading the "non-bb" will give you an error message, when you try to read from
> the offset the BadBlock is located. Reading the "bb" silently skips the
> BadBlock for you. By the price the usable size is smaller.
> ESU is a "erase size unit" you always will lose if it contains a bad block.
>
>> 2. I was thinking of somehow assigning the env partition larger than
>> required in order to later
>> handle bad blocks by moving the block currenly being used to be the
>> first good block.
>> Is this a good approach or maybe there is something already ready and I
>> shouldn't bother because I am totally missing the point?
> You should increase the partitions in "erase block size units". Recent NAND
> flashes are using 128 kiB erase size units. So, increasing by 256 kiB will
> give you two spare "erase block size units".
>
> jbe
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2011-06-05 12:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-05 11:50 protecting env partitions from bad blocks Boaz Ben-David
2011-06-05 12:11 ` Juergen Beisert
2011-06-05 12:38 ` Boaz Ben-David [this message]
2011-06-06 7:25 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DEB78D0.6070408@wellsense-tech.com \
--to=boaz.bd@wellsense-tech.com \
--cc=barebox@lists.infradead.org \
--cc=jbe@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.