UBI also proactively implements fixes: whenever a block is read and the eraseblock is weak-that is, it reads with errors but the error is corrected by an error correction code, UBI will try to remap the data to another physical eraseblock before it goes bad, in an attempt to preserve the data. No matter how many times we use our device, logical eraseblock #1 will always function properly, as long as it has spare blocks to cover for physical failures. UBI, on the other hand, would trap this error and select a different block for writing. The block is bad and should not be used, but it's up to the upper level to deal with it. With MTD, an attempt to write to physical eraseblock #1 would end in an error. Let's suppose that physical eraseblock #1 has turned bad due to overuse. This is used to mask errors in the device. This protects the device, by preventing a single block from being overworn.įurthermore, UBI also reserves some blocks as spares. Additionally, if we were to repeatedly erase and program logical eraseblock #1, UBI would select a different physical block and write the new data to it. Whenever we request logical eraseblock #1, UBI will find the proper physical block and hand the data back to us, wherever it was stored. Instead, UBI would select the least worn out physical eraseblock, note in the header that this block is logical eraseblock #1 and then write the data to it. If we did the same thing to UBI's logical eraseblock #1, the erase/program operation would not necessarily go to the initial physical eraseblock. If we keep writing and erasing this eraseblock, we will concentrate our operations on this single part of the flash and eventually wear it out. With MTD, this would be mapped straight to the first physical eraseblock of the flash device. As an example, let's assume that we're writing to eraseblock #1 of our device. This data enables UBI to remap any sector at will. Each logical eraseblock contains a block number and volume ID in its header. With respect to wear leveling, we have the remapped logical eraseblocks. Here we can see the improved capabilities we discussed above. In NOR flash, the second header would immediately follow the first instead. Each header takes one physical block as we're using NAND flash. This spacing of 2048 bytes is not a coincidence. Finally, the file system data appears at offset 0x221000, or 4096 bytes after the start of the block. This header can be recognized by the UBI! string and describes which logical volume (which will be addressed later in this guide)this header belongs to. Next, you can see the volume header (here at offset 0x220800, 2048 bytes into the eraseblock). This header describes how worn the eraseblock is, adds an error detection code, and points to the next header. At the beginning of the block we can see the UBI erasecounter header (indicated by UBI#) which contains the logical eraseblock information. The block starts at offset 0x220000 of the flash memory, which is physical eraseblock 17. Below we show a hex dump of the first blocks of a logical eraseblock. Additionally, a few logical eraseblocks are reserved for volume data and as spares. A second header is added once the eraseblock is assigned to a volume, describing the volume related data. These headers take space, so each logical eraseblock is slightly smaller (usually by two r/w blocks of 1KB each). This header describes, among other things, how many times it has been erased, which is essentially how badly worn it is, and what it is being used for. UBI takes the eraseblocks presented by an MTD and adds at least one UBI header on each. Additionally, UBI provides a way of defining volumes inside the same MTD partition, not unlike what LVM does for block devices.įirst, let’s define logical eraseblocks. While MTD directly shows all physical characteristics of the underlying device (eraseblock size, bad blocks, etc), UBI does two important things: it shows logical blocks that are mapped in an arbitrary and not necessarily constant way and hides bad blocks from upper layers. UBI (unsorted block images) is an abstraction layer that rides on top of MTD. These two are actually two layers in a stack. It is important to keep in mind that UBI is not the same as UBIfs. The latest and greatest in Linux-MTD is UBI and UBIfs.
0 kommentar(er)
