summaryrefslogtreecommitdiffstats
path: root/include/asm-xtensa/mman.h
diff options
context:
space:
mode:
authorArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2008-01-16 15:44:24 +0200
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2008-01-25 16:41:24 +0200
commit4ccf8cffa963c7b5bdc6d455ea9417084ee49aa8 (patch)
treea7281874dc9298b3d7eca2d1e4cb22c326625382 /include/asm-xtensa/mman.h
parent896c0c06aa30147630e9a75949b6ae2014c841fc (diff)
downloadop-kernel-dev-4ccf8cffa963c7b5bdc6d455ea9417084ee49aa8.zip
op-kernel-dev-4ccf8cffa963c7b5bdc6d455ea9417084ee49aa8.tar.gz
UBI: add auto-resize feature
The problem: NAND flashes have different amount of initial bad physical eraseblocks (marked as bad by the manufacturer). For example, for 256MiB Samsung OneNAND flash there might be from 0 to 40 bad initial eraseblocks, which is about 2%. When UBI is used as the base system, one needs to know the exact amount of good physical eraseblocks, because this number is needed to create the UBI image which is put to the devices during production. But this number is not know, which forces us to use the minimum number of good physical eraseblocks. And UBI additionally reserves some percentage of physical eraseblocks for bad block handling (default is 1%), so we have 1-3% of PEBs reserved at the end, depending on the amount of initial bad PEBs. But it is desired to always have 1% (or more, depending on the configuration). Solution: this patch adds an "auto-resize" flag to the volume table. The volume which has the "auto-resize" flag will automatically be re-sized (enlarged) on the first UBI initialization. UBI clears the flag when the volume is re-sized. Only one volume may have the "auto-resize" flag. So, the production UBI image may have one volume with "auto-resize" flag set, and its size is automatically adjusted on the first boot of the device. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Diffstat (limited to 'include/asm-xtensa/mman.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud