protecting env partitions from bad blocks

protecting env partitions from bad blocks

[Boaz Ben-David]

Hi all,

I want to protect the env partition on my device from bad blocks 
(created during operation or already there out of the factory).
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?
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?

Thanks,

Boaz.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: protecting env partitions from bad blocks

[Juergen Beisert]

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

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | Phone: +49-5121-206917-5128 |
Vertretung Sued/Muenchen, Germany             | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686              | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: protecting env partitions from bad blocks

[Boaz Ben-David]

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

Re: protecting env partitions from bad blocks

[Sascha Hauer]

Hi Boaz,

Please do not top-post.

On Sun, Jun 05, 2011 at 03:38:40PM +0300, Boaz Ben-David wrote:
> 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?

barebox currently does not actively mark a block as bad. You can only
do it manually from the command line.
However, it correctly handles bad blocks once they are there, so
if barebox starts and can't read its environment, you can mark
a block bad on the command line. After a 'saveenv' the bad block
gets skipped during write (and also during reading next time).

This is a lack of features, so patches welcome.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox