UBIFS Question

Fri Jul 10 14:43:05 EDT 2009

Hi Artem,

I am currently working on an embedded Linux project which has an ARM9 chip (NXP’s 180MHz LPC3131) with a NAND Flash controller which supports 5bits or 8bits HW ECC.
I have a 256MB SLC NAND and run Linux 2.6.28.2

It is important to know the way my product is used, the user will always brutally power it off. It’s not like I can nicely do this, do a sync etc etc…
I would have a few questions, hopefully you can answer them.

1) The LPC3131 supports a USB DFU mode which basically allows an end-user to upload a binary file into the chip's internal RAM and execute it.

I have coded a small USB application that I upload via DFU which allows me to completely control the NAND flash from the PC.
My goal was to create an application used in the factory that programs a blank NAND Flash.

It works :
with respect of bad blocks, I burn the LPC313x boot-block, my own small uimage bootloader, the nand-bbt located at the end of the flash, the linux uimage, and a ubi image that I generated doing

mkfs.ubifs -x none -r lolo -m 2048 -e 129024 -c 2047 -o ubifs.img

ubinize.cfg is:

[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=200MiB
vol_type=dynamic
vol_name=rootfs
vol_alignment=1
vol_flags=autoresize

ubinize -o ubi.img -m 2048 -p 128KiB -s 512 ubinize.cfg

I am not using LZO compression because I have seen that mount time is faster without, and since my file system contents are already compressed file, this does not buy me must room.
But maybe I am missing something and LZO compression is really advised ?

2) I boot my embedded system ( I use OpenWrt )

root at OpenWrt:/# ubiattach /dev/ubi_ctrl -m 5

UBI: attaching mtd5 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: volume 0 ("rootfs") re-sized from 1626 to 1854 LEBs
UBI: attached mtd5 to ubi0
UBI: MTD device name:            "lpc313x-rootfs"
UBI: MTD device size:            235 MiB
UBI: number of good PEBs:        1876
UBI: number of bad PEBs:         6
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             0
UBI: total number of reserved PEBs: 1876
UBI: number of PEBs reserved for bad PEB handling: 18
UBI: max/mean erase counter: 1/0
UBI: background thread "ubi_bgt0d" started, PID 2059
UBI device number 0, total 1876 LEBs (242049024 bytes, 230.8 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)

root at OpenWrt:/# mount -t ubifs ubi0 /mnt

UBIFS: mounted UBI device 0, volume 0, name "rootfs"
UBIFS: file system size:   237791232 bytes (232218 KiB, 226 MiB, 1843 LEBs)
UBIFS: journal size:       9033728 bytes (8822 KiB, 8 MiB, 71 LEBs)
UBIFS: media format:       4 (latest is 4)
UBIFS: default compressor: no compression
UBIFS: reserved for root:  0 bytes (0 KiB)

root at OpenWrt:/# find /mnt

/mnt
/mnt/img
/mnt/img/00783_hongkongbynight_1920x1200.jpg
/mnt/img/00678_vancouverdusk_1920x1200.jpg
/mnt/img/00698_snowmountains_1920x1200.jpg
/mnt/music
/mnt/music/10 F Cuitad & Y Hayat - The Force.mp3
/mnt/music/07 Sakamoto - Forbidden Colours.mp3
/mnt/alphaflight
/mnt/alphaflight/indexOnline.html
/mnt/alphaflight/Lover_Charlie.zsid
/mnt/alphaflight/sid.java
/mnt/alphaflight/retroguard.jar
/mnt/alphaflight/retroguard.log
/mnt/alphaflight/obfuscAFL.bat
/mnt/alphaflight/aflClean.jar
/mnt/alphaflight/index.html
/mnt/alphaflight/sid.class
/mnt/alphaflight/afl.gif
/mnt/alphaflight/afl.jar
/mnt/alphaflight/afl.java
/mnt/alphaflight/afl.class
/mnt/alphaflight/AFL-06.prg
/mnt/alphaflight/indexObuscLocal.html
/mnt/alphaflight/sid_applet.java
/mnt/alphaflight/sid$sidVoice.class
/mnt/alphaflight/aflold.java

In /mnt/alphaflight I generate a small new.txt file with vi, which contains a few lines of characters.
After saving, I immediately power-off brutally.
I power-on again, mount, and the new.txt file is not there...

I recreate the file, I wait 20 seconds or so and power-off brutally.

I power-on again, mount and now I have:

-rw-r--r--    1 1000     1000          397 Dec 31  2002 indexOnline.html
-rw-r--r--    1 root     root            0 Jan  1 00:00 new.txt
-rw-r--r--    1 1000     1000          104 Dec 31  2002 obfuscAFL.bat

Size 0 ... I can understand that since I did not have time to sync.

It’s funny though that the file is present in the directory but the contents are not there ?

If I do this programmatically, I presume I can force a sync after I close the file ?
Is it safe to do so ? Would you know the C API to use to do a sync programmatically ?

I generate a new2.txt wait one minute...  Reboot, the file new2.txt is still 0
I generate a new3.txt wait two minutes... Reboot, now the file new3.txt has correct size !

So, I am wondering, is this background thread "ubi_bgt0d" responsible for automatically synching periodically ? Is this interval adjustable  ? Do you recommend it ? Like every 10 seconds, isn’t it too much ?

Thank you,
Laurent

_________________________________________________________________
Insert movie times and more without leaving Hotmail®. 
http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009