UBI
UBI
Unsorted Block Images
- http://www.linux-mtd.infradead.org/doc/ubi.html
- Volume management system on top of MTD devices (similar to what LVM provides for block devices)
- Allows to create multiple logical volumes and spread writes across all physical blocks
- Takes care of managing the erase blocks and wear leveling. Makes filesystems easier to implement
- Wear leveling can operate on the whole storage, not only on individual partitions (strong advantage)
- Volumes can be dynamically resized or, on the opposite, can be read-only (static)
UBI: internals
UBI is storing its metadata in-band
- In each MTD erase block
- One page is reserved to count the number of erase cycles
- Another page is reserved to attach the erase block to a UBI volume
- The remaining pages are used to store payload data
If the device supports subpage write, the EC and VID headers can be stored on the same page
UBI is responsible for distributing writes all over the flash device: the more space you assign to a partition attached to the UBI layer the more efficient the wear leveling will be
- If you need partitioning, use UBI volumes not MTD partitions
- Some partitions will still have to be MTD partitions: e.g. the bootloaders and bootloader environments
- If you need extra MTD partitions, try to group them at the end or the beginning of the flash device
UBI layout: bad example
UBI layout: good example
Linux: UBI host tools
- ubinize is the only host tool for the UBI layer
- Creates a UBI image to be flashed on an MTD partition
- Takes the following arguments:
- -o
Path to the output image file - -p
The PEB size (MTD erase block size) - -m
The minimum write unit size (e.g. MTD write size) - -s
Subpage size, only needed if both your flash and your flashcontroller are supporting subpage writes - The last argument is a path to a UBI image description file (see next page for an example)
- -o
- Example: ubinize -o ubi.img -p 16KiB -m 512 -s 256 cfg.ini
ubinize configuration file
Can contain several sections
- Each section is describing a UBI volume
- Example:
[kernel-volume] mode=ubi image=zImage vol_id=1 vol_type=static vol_name=kernel
[rootfs-volume] mode=ubi image=rootfs.squashfs vol_id=2 vol_type=static vol_name=rootfs
[data-volume] mode=ubi image=data.ubifs vol_id=3 vol_size=30MiB vol_type=dynamic vol_name=data vol_flags=autoresize
U-Boot: UBI tools
Grouped under the ubi command
- ubi part
Attach an MTD partition to the UBI layer - ubi info [layout] Display UBI device information (or volume information if the layout string is passed
- ubi check
Check if a volume exists - ubi readvol
[ ] Read volume contents - U-Boot also provides tools to update the UBI device contents
- Using them is highly discouraged (the U-Boot UBI implementation is not entirely stable, and using commands that do not touch the UBI metadata is safer)
- ubi createvol
[ ] [ ] - ubi removevol
- ubi writevol
- ubi createvol
Linux: UBI target tools
Tools used on the target to dynamically create and modify UBI elements
- UBI device management:
- ubiformat
Format an MTD partition and preserve Erase Counter information if any - ubiattach -m
/dev/ubi_ctrl Attach an MTD partition/device to the UBI layer, and create a UBI device - ubidetach -m
/dev/ubi_ctrl Detach an MTD partition/device from the UBI layer, and remove the associated UBI device
- ubiformat
UBI volume management:
- ubimkvol /dev/ubi
-N -s Create a new volume. Use -m in place of -s if you want to assign all the remaining space to this volume. - ubirmvol /dev/ubi
-N Delete a UBI volume - ubiupdatevol /dev/ubi
_ [-s ] Update volume contents - ubirsvol /dev/ubi
-N -s Resize a UBI volume - ubirename /dev/ubi
_ Rename a UBI volume
Linux tools: BusyBox UBI limitations
Beware that the implementation of UBI commands in BusyBox is still incomplete. For example:
- ubirsvol doesn't support -N
. You have to use specify the volume to resize by its id (-n num): ubirsvol /dev/ubi0 -n 4 -s 64 MiB - Same constraint for ubirmvol: ubirmvol /dev/ubi0 -n 4