RFS aka Robust File System
From Samsung documentation:
SAMSUNG RFS (Robust File System) is an embedded flash file system that uses SAMSUNG OneNAND flash memory as storage on any consumer electronic devices.
SAMSUNG RFS runs in the Linux kernel and is fully compatible with FAT file system standards (FAT16/32).
RFS is simply a FAT16 (maybe 32 too, in my movinand.bin is 16) with a transaction log for journaling (file $rfs_log.lo$) in root and a partition mark of 0x83 (linux)...
$rfs_log.lo$ is a 128kb file of all 0x00 (NULL).
RFS filesystems from /proc/mounts
... /dev/stl9 /mnt/rsv rfs rw,code page=utf8,vfat,fcache(blks)=128 0 0 /dev/mmca1 /mnt/ums rfs rw,code page=utf8,vfat,fcache(blks)=128 0 0 /dev/mmca2 /opt rfs rw,code page=utf8,vfat,fcache(blks)=128 0 0 /dev/mmca3 /mnt/csc rfs rw,code page=utf8,vfat,fcache(blks)=128 0 0
There are two interesting parameters: vfat and fcache(blks)=128.
- vfat mybe RFS can be used on top of other filesystem???
- fcache(blks)=128 $rfs_log.lo$ is 128kb long, mybe related???
XSR aka eXtended Sector Remapper
We can start from Samsung XSR documentation
XSR is a layer between filesystems and NAND devices that uses logical sector relocation to prevent too many overwrites of the same block and to relocate bad blocks.
- STL (Sector Translation Layer) are the logical devices on top of XSR
- BML (Block Management Layer) are the devices on bottom of XSR exatly on top on NAND low level drivers.
If one analyzes the content of an stl device wich contains an RFS (f.e. stl9), he will see a FAT as secribed upper in this page. On the other hand if someone analyzes the contet of the relative bml (f.e. bml9) he will see someting like this:
00000000 64 00 01 00 02 00 00 00 01 00 00 00 58 53 52 32 |d...........XSR2|
00000010 3e 00 00 00 0c 00 00 00 a5 a5 a5 a5 60 04 00 00 |>...........`...|
00000020 04 00 00 00 c1 ff ff ff f3 ff ff ff fb ff ff ff |................|
00000030 a7 ac ad cd 9f fb ff ff 5a 5a 5a 5a 01 ff ff ff |........ZZZZ....|
00000040 08 00 00 00 f7 ff ff ff ff ff ff ff ff ff ff ff |................|
00000050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000100 09 1c 09 1d 09 1e 09 1f 09 20 09 21 09 22 09 23 |......... .!.".#|
00000110 09 24 09 25 09 26 09 27 09 28 09 29 09 2a 09 2b |.$.%.&.'.(.).*.+|
00000120 09 44 09 45 09 46 09 47 09 60 09 61 09 62 09 63 |.D.E.F.G.`.a.b.c|
00000130 0a 02 0a 03 0a 04 0a 05 0a 26 0a 27 0a 28 0a 29 |.........&.'.(.)|
00000140 0a 42 0a 43 0a 44 0a 45 0a 66 0a 67 0a 68 0a 69 |.B.C.D.E.f.g.h.i|
00000150 0b 04 0b 05 0b 06 0b 07 0b 24 0b 25 0b 26 0b 27 |.........$.%.&.'|
00000160 0b 48 0b 49 0b 4a 0b 4b 0b 64 0b 65 0b 66 0b 67 |.H.I.J.K.d.e.f.g|
00000170 0b 7c 0b 7d 0b 7a 0b 7b 89 fe 89 fe 89 fe 89 fe |.|.}.z.{........|
00000180 89 fe 89 fe 89 fe 89 fe 89 fe 89 fe 89 fe 89 fe |................|
*
000001f0 89 fe 89 fe 89 fe 89 fe 89 fe 89 fe ff ff ff ff |................|
00000200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000800 63 6f 6e 64 69 74 69 6f 6e 20 3a 20 36 34 20 0a |condition : 64 .|
00000810 4a 61 6e 20 31 39 20 31 30 3a 34 31 3a 34 30 20 |Jan 19 10:41:40 |
...
".rfs" image files
The begining of my datafs.rfs is:
00000000 64 00 01 00 02 00 00 00 01 00 00 00 58 53 52 32 |d...........XSR2| 00000010 00 00 00 00 00 00 00 00 a5 a5 a5 a5 5a 00 00 00 |............Z...| 00000020 01 00 00 00 ff ff ff ff ff ff ff ff fe ff ff ff |................| 00000030 a7 ac ad cd a5 ff ff ff 5a 5a 5a 5a 01 ff ff ff |........ZZZZ....| 00000040 08 00 00 00 f7 ff ff ff ff ff ff ff ff ff ff ff |................| 00000050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000800 ff ff 01 00 00 ff ff ff aa aa 5a aa fe ff 00 ff |..........Z.....| 00000810 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000840 eb 3c 90 6c 69 62 46 41 54 20 20 00 10 01 01 00 |.<.libFAT .....| 00000850 02 00 02 48 1d f8 04 00 08 00 01 00 00 00 00 00 |...H............| ...
As we can see it is similar to the content of the BML on bottom of STL with RFS in it.
Unfortunately in my "datafs.rfs" at address 0x00000840 doesn't contain a coerent FAT, this means we need more investigation on the XSR translation table/blocks to be able to reconstruct an RFS.
Research notes
These are my raw research notes... ASAP I'll reorder them... I hope :-)
In bml9 image there are 240 of these:
01de0000 64 00 01 00 02 00 00 00 01 00 00 00 58 53 52 32 |d...........XSR2|
Digging a little into /proc we can find this:
# more /proc/rfs/bmlinfo XSR VERSION: 1.5.2-p4 minor position size blocks id 1: 0x00000000-0x00040000 0x00040000 2 0 2: 0x00040000-0x00640000 0x00600000 48 1 3: 0x00640000-0x00780000 0x00140000 10 2 4: 0x00780000-0x008c0000 0x00140000 10 3 5: 0x008c0000-0x00dc0000 0x00500000 40 4 6: 0x00dc0000-0x012c0000 0x00500000 40 5 7: 0x012c0000-0x02140000 0x00e80000 116 6 8: 0x02140000-0x0cb40000 0x0aa00000 1360 7 9: 0x0cb40000-0x0e940000 0x01e00000 240 8 10: 0x0e940000-0x0f940000 0x01000000 128 9 11: 0x0f940000-0x0fa40000 0x00100000 8 10 (0) bad mapping information No BadBlock RsvBlock
LOOK bml9 (minor 9) has 240 blocks.... I've already saw this value...
Let's see if there is a regularity in these blocks:
00000000 64 00 01 00 02 00 00 00 01 00 00 00 58 53 52 32 |d...........XSR2| ... 00020000 64 00 01 00 02 00 00 00 01 00 00 00 58 53 52 32 |d...........XSR2| ... 00040000 64 00 01 00 02 00 00 00 01 00 00 00 58 53 52 32 |d...........XSR2| ...
00020000 = 128Kb per block
Some interesting tools on the phone:
# ffdisk
+---------------------------------------------------------------------+
| ffdisk : RFS-level Partitioning Tool for Flash Block Devices |
+---------------------------------------------------------------------+
Usage : ffdisk [-a] <flash_block_dev>
-a option that automatically format without user interaction
-u user-region-percentage
Must be (100 >= percentage > 0)
The default is 100
-r reserved-area
Must be (10 >= area >= 2)
The default is 2
<flash_block_dev> : device file for an FTL block device
(ex) /dev/bml0/1 : 1st FTL block device
/dev/bml0/2 : 2nd FTL block device
/dev/bml0/3 : 3rd FTL block device
version 1.2.3
# fformat
Usage:
fformat [-s sectors-per-cluster] [-S logical-sector-size] [-F fat-size]
[-p page-size-to-align] [-v]
OUT_FILE/FLASH_BLK_DEV
-s sectors-per-cluster
Must be a power of 2, i.e. 1, 2, 4, ... 64.
The default is 2
-S logical-sector-size
Must be a power of 2, greater than or equal to 512,
i.e. 512, 1024, 2048, 4096
The default is 512
-F fat-size
The type of file allocation table used(16, 32 bit)
If nothing is specified, fat-size is automatically selected.
-p page-size-to-align
Each area is aligned to NAND page size
i.e. 0(no alignment), 2048, 4096
The default is 4096, zero means disable to the alignment
-l volume-label
Must be under 11 characters
-v verbose option
version 1.2.3
#
Let's analyze a tipical block:
001e0000 64 00 01 00 02 00 00 00 01 00 00 00 58 53 52 32 |d...........XSR2|
001e0010 4c 00 00 00 05 00 00 00 a5 a5 a5 a5 f4 03 00 00 |L...............|
001e0020 09 00 00 00 b3 ff ff ff fa ff ff ff f6 ff ff ff |................|
001e0030 a7 ac ad cd 0b fc ff ff 5a 5a 5a 5a 01 ff ff ff |........ZZZZ....|
001e0040 08 00 00 00 f7 ff ff ff ff ff ff ff ff ff ff ff |................|
001e0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
001e0100 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 |................|
001e0110 01 0a 01 0b 01 0c 01 0d 01 10 01 11 01 12 01 13 |................|
001e0120 01 2c 01 2d 01 2e 01 2f 01 50 01 51 01 52 01 53 |.,.-.../.P.Q.R.S|
001e0130 01 6c 01 6d 01 6e 01 6f 02 12 02 13 02 14 02 15 |.l.m.n.o........|
001e0140 02 2e 02 2f 02 30 02 31 02 52 02 53 02 54 02 55 |.../.0.1.R.S.T.U|
001e0150 02 6e 02 6f 02 70 02 71 04 4a 04 4b 04 4c 04 4d |.n.o.p.q.J.K.L.M|
001e0160 04 4e 04 4f 04 50 04 51 04 52 04 53 04 54 04 55 |.N.O.P.Q.R.S.T.U|
001e0170 04 56 04 57 04 58 04 59 04 12 04 13 04 14 04 15 |.V.W.X.Y........|
001e0180 04 32 04 33 04 34 04 35 04 5a 04 5b 04 5c 04 5d |.2.3.4.5.Z.[.\.]|
001e0190 04 76 04 77 04 78 04 79 04 7a 04 7b 04 7c 04 7d |.v.w.x.y.z.{.|.}|
001e01a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
001e0800 6f 20 64 65 76 6d 67 72 5f 6d 6f 6e 3a 20 72 65 |o devmgr_mon: re|
Data begins at + 0x800 (2048 byte) from starting of the block, this means 126kb of data per block.
-rw-r--r-- 1 root root 31457280 Mar 12 12:07 bml9.img -rw-r--r-- 1 root root 30707712 Mar 12 12:06 stl9.img
126K per block of data
30707712 (stl9 block size in byte) / 1024 / 126 (kb of data per block) = 238 blocks
240 - 238 = 2 spare block look at -r reserved-area of ffdisk
NOW remains to understand how to sort XSR blocks ;-)
OT IMPORTANT:
max facrotyfs.cramfs = 1360 blocks * 128 kb / 1024 = 170 Mb
