UBI partitioning in embedded device?

UBI partitioning in embedded device?

[Ricard Wanderlof]

Are there any opinions here on the partitioning of a flash memory in an 
embedded device when using UBI?

Principially, one could let UBI manage the whole flash as one mtd 
partition, except possibly some boot area due to restriction in the boot 
ROM of the system in question. But is it wise to do so, assuming for 
instance there is data in part of the flash that you really want to avoid 
loosing, such as calibration data? Of course, theoretically, once the 
kernel has access to one part of the flash it could clobber anything, 
still, the mtd code has been proven for years whereas UBI is relatively 
young, so one idea would be to partition that flash into several mtd 
partitions (e.g. boot, running system, and calibration data), and let UBI 
handle these separately. That could minimize the risk of UBI clobbering 
the calibration data when operating on the running system, for instance.

Any thoughts?

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: UBI partitioning in embedded device?

[Artem Bityutskiy]

On Mon, 2011-04-18 at 08:44 +0200, Ricard Wanderlof wrote:
> Are there any opinions here on the partitioning of a flash memory in an 
> embedded device when using UBI?
> 
> Principially, one could let UBI manage the whole flash as one mtd 
> partition, except possibly some boot area due to restriction in the boot 
> ROM of the system in question.

FYI, IBM people were able to implement boot initial boot loader with the
limit of 4KiB for the whole initial boot loader, and it supported R/O
UBI (but not UBIFS of course).

>  But is it wise to do so, assuming for 
> instance there is data in part of the flash that you really want to avoid 
> loosing, such as calibration data?

The best way to not lose it is to have several copy of it, IMO.

>  Of course, theoretically, once the 
> kernel has access to one part of the flash it could clobber anything, 
> still, the mtd code has been proven for years whereas UBI is relatively 
> young, so one idea would be to partition that flash into several mtd 
> partitions (e.g. boot, running system, and calibration data), and let UBI 
> handle these separately. That could minimize the risk of UBI clobbering 
> the calibration data when operating on the running system, for instance.
> 
> Any thoughts?

You can let UBI manage your calibration data in a static UBI volume. But
additionally, you can have a separate calibration data back-up
partition, just in case.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

RE: UBI partitioning in embedded device?

[Atlant Schmidt]

Ricard:

One advantage of moving critical data (such as calibration
data) into its own partition is that because each partition
would absolutely positively *NOT* share its PEBs (Physical
Erase Blocks) with any other partition, data stored in
those partitions would then be better-insulated from
"disturb" effects (such as "program disturb" and "read
disturb") caused by the reading and writing of other data.

Generally, the "disturb" effects only take place within
Flash pages and from one Flash page to another.

                    Atlant

-----Original Message-----
From: linux-mtd-bounces@lists.infradead.org [mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of Ricard Wanderlof
Sent: Monday, April 18, 2011 02:44
To: Linux mtd
Subject: UBI partitioning in embedded device?


Are there any opinions here on the partitioning of a flash memory in an
embedded device when using UBI?

Principially, one could let UBI manage the whole flash as one mtd
partition, except possibly some boot area due to restriction in the boot
ROM of the system in question. But is it wise to do so, assuming for
instance there is data in part of the flash that you really want to avoid
loosing, such as calibration data? Of course, theoretically, once the
kernel has access to one part of the flash it could clobber anything,
still, the mtd code has been proven for years whereas UBI is relatively
young, so one idea would be to partition that flash into several mtd
partitions (e.g. boot, running system, and calibration data), and let UBI
handle these separately. That could minimize the risk of UBI clobbering
the calibration data when operating on the running system, for instance.

Any thoughts?

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

RE: UBI partitioning in embedded device?

[Ricard Wanderlof]

On Mon, 18 Apr 2011, Atlant Schmidt wrote:

> Ricard:
>
> One advantage of moving critical data (such as calibration
> data) into its own partition is that because each partition
> would absolutely positively *NOT* share its PEBs (Physical
> Erase Blocks) with any other partition, data stored in
> those partitions would then be better-insulated from
> "disturb" effects (such as "program disturb" and "read
> disturb") caused by the reading and writing of other data.
>
> Generally, the "disturb" effects only take place within Flash pages and 
> from one Flash page to another.

But is it even possible to have an UBI volume less than one eraseblock in 
size? Normally a UBI volume would be several eraseblocks, so there's no 
chance of any eraseblocks being shared at any one time between different 
UBI volumes.

I've always thought that because UBI volumes are measured in 
number-of-LEBs, that each volume in practice gets its own PEBs, even 
though of course UBI can move them around in the flash if it wants to.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

RE: UBI partitioning in embedded device?

[Artem Bityutskiy]

On Mon, 2011-04-18 at 14:53 +0200, Ricard Wanderlof wrote:
> On Mon, 18 Apr 2011, Atlant Schmidt wrote:
> 
> > Ricard:
> >
> > One advantage of moving critical data (such as calibration
> > data) into its own partition is that because each partition
> > would absolutely positively *NOT* share its PEBs (Physical
> > Erase Blocks) with any other partition, data stored in
> > those partitions would then be better-insulated from
> > "disturb" effects (such as "program disturb" and "read
> > disturb") caused by the reading and writing of other data.
> >
> > Generally, the "disturb" effects only take place within Flash pages and 
> > from one Flash page to another.
> 
> But is it even possible to have an UBI volume less than one eraseblock in 
> size? Normally a UBI volume would be several eraseblocks, so there's no 
> chance of any eraseblocks being shared at any one time between different 
> UBI volumes.
> 
> I've always thought that because UBI volumes are measured in 
> number-of-LEBs, that each volume in practice gets its own PEBs, even 
> though of course UBI can move them around in the flash if it wants to.

That's right, minimum size is one LEB. Probably Atlant meant that UBI
will move data around, so the same PEBs will be "shared", meaning that
today your critical calibration data is in PEB 1, tomorrow PEB 1
contains some random non-critical stuff.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

RE: UBI partitioning in embedded device?

[Ricard Wanderlof]

On Mon, 18 Apr 2011, Artem Bityutskiy wrote:

> On Mon, 2011-04-18 at 14:53 +0200, Ricard Wanderlof wrote:
>> On Mon, 18 Apr 2011, Atlant Schmidt wrote:
>>
>>> Ricard:
>>>
>>> One advantage of moving critical data (such as calibration
>>> data) into its own partition is that because each partition
>>> would absolutely positively *NOT* share its PEBs (Physical
>>> Erase Blocks) with any other partition, data stored in
>>> those partitions would then be better-insulated from
>>> "disturb" effects (such as "program disturb" and "read
>>> disturb") caused by the reading and writing of other data.
>>>
>>> Generally, the "disturb" effects only take place within Flash pages and
>>> from one Flash page to another.
>>
>> But is it even possible to have an UBI volume less than one eraseblock in
>> size? Normally a UBI volume would be several eraseblocks, so there's no
>> chance of any eraseblocks being shared at any one time between different
>> UBI volumes.
>>
>> I've always thought that because UBI volumes are measured in
>> number-of-LEBs, that each volume in practice gets its own PEBs, even
>> though of course UBI can move them around in the flash if it wants to.
>
> That's right, minimum size is one LEB. Probably Atlant meant that UBI
> will move data around, so the same PEBs will be "shared", meaning that
> today your critical calibration data is in PEB 1, tomorrow PEB 1
> contains some random non-critical stuff.

True, but then UBI will move the data to another PEB before that which 
should be ok. Of course, moving critical data could be seen as risky, but 
the way nand flash development is going, leaving it in place without 
potentially re-writing it is also risky.

I think what I'm most worried about is some bug in UBI causing the 
critical data to be lost at some point. And as you said, some form of 
backup would definitely help.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

RE: UBI partitioning in embedded device?

[Artem Bityutskiy]

On Mon, 2011-04-18 at 15:33 +0200, Ricard Wanderlof wrote:
> I think what I'm most worried about is some bug in UBI causing the 
> critical data to be lost at some point. And as you said, some form of 
> backup would definitely help.

Well, good testing and redundancy would be the answer...

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)