ubi_vid_hdr Struct Reference

#include <ubi-media.h>

Data Fields
__be32	magic
__u8	version
__u8	vol_type
__u8	copy_flag
__u8	compat
__be32	vol_id
__be32	lnum
__u8	padding1 [4]
__be32	data_size
__be32	used_ebs
__be32	data_pad
__be32	data_crc
__u8	padding2 [4]
__be64	sqnum
__u8	padding3 [12]
__be32	hdr_crc

Detailed Description

struct ubi_vid_hdr - on-flash UBI volume identifier header. : volume identifier header magic number (UBI_VID_HDR_MAGIC)

Version

: UBI implementation version which is supposed to accept this UBI image (UBI_VERSION) : volume type (UBI_VID_DYNAMIC or UBI_VID_STATIC) : if this logical eraseblock was copied from another physical eraseblock (for wear-leveling reasons) : compatibility of this volume (%0, UBI_COMPAT_DELETE, UBI_COMPAT_IGNORE, UBI_COMPAT_PRESERVE, or UBI_COMPAT_REJECT) : ID of this volume : logical eraseblock number : reserved for future, zeroes : how many bytes of data this logical eraseblock contains : total number of used logical eraseblocks in this volume : how many bytes at the end of this physical eraseblock are not used : CRC checksum of the data stored in this logical eraseblock : reserved for future, zeroes : sequence number : reserved for future, zeroes : volume identifier header CRC checksum

The is the value of the global sequence counter at the time when this VID header was created. The global sequence counter is incremented each time UBI writes a new VID header to the flash, i.e. when it maps a logical eraseblock to a new physical eraseblock. The global sequence counter is an unsigned 64-bit integer and we assume it never overflows. The (sequence number) is used to distinguish between older and newer versions of logical eraseblocks.

There are 2 situations when there may be more than one physical eraseblock corresponding to the same logical eraseblock, i.e., having the same and values in the volume identifier header. Suppose we have a logical eraseblock L and it is mapped to the physical eraseblock P.

1. Because UBI may erase physical eraseblocks asynchronously, the following situation is possible: L is asynchronously erased, so P is scheduled for erasure, then L is written to,i.e. mapped to another physical eraseblock P1, so P1 is written to, then an unclean reboot happens. Result - there are 2 physical eraseblocks P and P1 corresponding to the same logical eraseblock L. But P1 has greater sequence number, so UBI picks P1 when it attaches the flash.

1. From time to time UBI moves logical eraseblocks to other physical eraseblocks for wear-leveling reasons. If, for example, UBI moves L from P to P1, and an unclean reboot happens before P is physically erased, there are two physical eraseblocks P and P1 corresponding to L and UBI has to select one of them when the flash is attached. The field says which PEB is the original (obviously P will have lower ) and the copy. But it is not enough to select the physical eraseblock with the higher sequence number, because the unclean reboot could have happen in the middle of the copying process, so the data in P is corrupted. It is also not enough to just select the physical eraseblock with lower sequence number, because the data there may be old (consider a case if more data was added to P1 after the copying). Moreover, the unclean reboot may happen when the erasure of P was just started, so it result in unstable P, which is "mostly" OK, but still has unstable bits.

UBI uses the field to indicate that this logical eraseblock is a copy. UBI also calculates data CRC when the data is moved and stores it at the field of the copy (P1). So when UBI needs to pick one physical eraseblock of two (P or P1), the of the newer one (P1) is examined. If it is cleared, the situation* is simple and the newer one is picked. If it is set, the data CRC of the copy (P1) is examined. If the CRC checksum is correct, this physical eraseblock is selected (P1). Otherwise the older one (P) is selected.

There are 2 sorts of volumes in UBI: user volumes and internal volumes. Internal volumes are not seen from outside and are used for various internal UBI purposes. In this implementation there is only one internal volume - the layout volume. Internal volumes are the main mechanism of UBI extensions. For example, in future one may introduce a journal internal volume. Internal volumes have their own reserved range of IDs.

The field is only used for internal volumes and contains the "degree of their compatibility". It is always zero for user volumes. This field provides a mechanism to introduce UBI extensions and to be still compatible with older UBI binaries. For example, if someone introduced a journal in future, he would probably use UBI_COMPAT_DELETE compatibility for the journal volume. And in this case, older UBI binaries, which know nothing about the journal volume, would just delete this volume and work perfectly fine. This is similar to what Ext2fs does when it is fed by an Ext3fs image

• it just ignores the Ext3fs journal.

The field contains the CRC checksum of the contents of the logical eraseblock if this is a static volume. In case of dynamic volumes, it does not contain the CRC checksum as a rule. The only exception is when the data of the physical eraseblock was moved by the wear-leveling sub-system, then the wear-leveling sub-system calculates the data CRC and stores it in the field. And of course, the is in this case.

The field is used only for static volumes because UBI has to know how many bytes of data are stored in this eraseblock. For dynamic volumes, this field usually contains zero. The only exception is when the data of the physical eraseblock was moved to another physical eraseblock for wear-leveling reasons. In this case, UBI calculates CRC checksum of the contents and uses both and fields. In this case, the field contains data size.

The field is used only for static volumes and indicates how many eraseblocks the data of the volume takes. For dynamic volumes this field is not used and always contains zero.

The is calculated when volumes are created using the alignment parameter. So, effectively, the field reduces the size of logical eraseblocks of this volume. This is very handy when one uses block-oriented software (say, cramfs) on top of the UBI volume.

Definition at line 278 of file ubi-media.h.

Field Documentation

__u8 compat

Definition at line 283 of file ubi-media.h.

__u8 copy_flag

Definition at line 282 of file ubi-media.h.

__be32 data_crc

Definition at line 290 of file ubi-media.h.

__be32 data_pad

Definition at line 289 of file ubi-media.h.

__be32 data_size

Definition at line 287 of file ubi-media.h.

__be32 hdr_crc

Definition at line 294 of file ubi-media.h.

__be32 lnum

Definition at line 285 of file ubi-media.h.

__be32 magic

Definition at line 279 of file ubi-media.h.

__u8 padding1[4]

Definition at line 286 of file ubi-media.h.

__u8 padding2[4]

Definition at line 291 of file ubi-media.h.

__u8 padding3[12]

Definition at line 293 of file ubi-media.h.

__be64 sqnum

Definition at line 292 of file ubi-media.h.

__be32 used_ebs

Definition at line 288 of file ubi-media.h.

__u8 version

Definition at line 280 of file ubi-media.h.

__be32 vol_id

Definition at line 284 of file ubi-media.h.

__u8 vol_type

Definition at line 281 of file ubi-media.h.

---

The documentation for this struct was generated from the following file:

• drivers/mtd/ubi/ubi-media.h