Hi,
I'm working with UBI these days. Thanks to the wiki page of TI, can make UBI images now.
But there are some questions about relationship between partitions,block devices, volumes:
I know NAND flash can be divide to several partitions by the kernel, and each of them
have a device name in the /dev directory, such as mtdblock0, mtdblock1...
But it seems that UBI doesn't depend on block device. What the usage of the
partitions defined by the kernel in this situation? Should we flash the UBI images
according to the partitions? We specify the volume name in the ubinize process,
and every time we mount the file system, we should provide volume name of the
image in mount command line. But after several days, we might forget the volume
names of the images, How can we get the volume name then? Is there any
handy tool? or we need to recreate a image?
Thank you.
Zhu,
1. Your understanding is partially correct. UBI doesn't depend on the block device doesn't mean that it doesn't use partitions. Instead of mtdblock0 it uses mtd0 which is a character interface to the same NAND partition. When you are creating a UBI volume you are creating it for the NAND partition and not for the entire NAND device.
2. There are two options here, you can use the volume name in bootargs so that it will get mounted during boot. Another option is to give a generic name like "rootfs" which you'll not forget.
-Renjith | www.pathpartnertech.com | Verify the answer if you think your query is resolved
Hi Thomas,
Thank you very much for your reply. Now I created a ubi image, but after I flash it to Nand, the following message is given. I'm using a samsung mlc2 nand, K9GAG08UOE.
Creating 3 MTD partitions on "NAND 2GiB 3,3V 8-bit":0x000000000000-0x000000400000 : "Bootloader"0x000000400000-0x000000c00000 : "Kernel"0x000000c00000-0x000080000000 : "File System"UBI: attaching mtd2 to ubi0UBI: physical eraseblock size: 1048576 bytes (1024 KiB)UBI: logical eraseblock size: 1032192 bytesUBI: smallest flash I/O unit: 8192UBI: VID header offset: 8192 (aligned 8192)UBI: data offset: 16384UBI warning: process_eb: valid VID header but corrupted EC header at PEB 0UBI warning: process_eb: valid VID header but corrupted EC header at PEB 1UBI warning: process_eb: valid VID header but corrupted EC header at PEB 2UBI error: check_corruption: PEB 13 contains corrupted VID header, and the data does not contain all 0xFF, nUBI error: check_what_we_have: 1 PEBs are corrupted and preservedCorrupted PEBs are: 13UBI: max. sequence number: 0UBI error: vtbl_check: volume table check failed: record 0, error 9UBI error: ubi_init: cannot attach mtd2
Blow is how I create the image:
mkfs.ubifs -r rootfs -m 8KiB -e 1008KiB -F -c 2012 -o rootfs.ubifs
ubinize -o rootfs.ubi -m 8KiB -p 1024KiB -O 8192 ubinize.cfg
And the ubinize.cfg:
[ubifs]mode=ubiimage=rootfs.ubifsvol_id=0vol_size=2036MiBvol_type=dynamicvol_name=rootfsvol_flags=autoresize
I don't know where I went wrong. Could you help me out?
Thank you very much!
Lihua:
Have got any solution for your issue?
regards,
santosh vastrad
Hi Zhu,
I don't think AM335x support 8KB NAND page with hardware ecc supported. Check the register GPMC_ECC_CONFIG. Are you able to boot up the device from NAND with BCH8 algorithm?
I made it on 335xEVK last week without any problem following the guidance. Now I do the same on a FriendlyArm 6410 board. it use a 8KB page nand. I can make a correct UBI image with the tool provided by FriendlyArm, but failed by manually make UBI image. the board will display the errors when kernel startup if I flash my own image to nand.
I think it is a UBI making problem. So I asked here.
Thanks.
sorry, I have not got a solution.
I read the help by run "mkfs.ubifs -h" and "ubinize -h", does it need other options than I used if using a mlc2 nand?
I also find another item in ubinize.cfg when searching internet. vol_alignment, I noticed a ubinize.cfg of a nor flash is using it. What does it mean? I didn't find any explaination in the internet.
thank you.
I am not familiar with S3C6410 architecture. Could you please check first whether the NAND controller in 6410 support 8KB page size or not. Can you follow the steps below, which will create the UBI image from kernel itself. This will help you getting the right parameters for creating the UBI image from a PC. Change the commands according to your system.
1. First you should have your rootfs as a tar ball in your SD card or NFS from where you mount the filesystem.2. Boot up the device and the filesystem from NFS or SD card according your preference.3. Boot it up and login. Hope you have all the required command binaries like "flash_erase" etc in your filesystem. 4. Follow the steps below
$ flash_erase /dev/mtd4 0 0 $ ubiattach /dev/ubi_ctrl -m 4 $ ubimkvol /dev/ubi0 -N rootfs -m
$ mkdir /mnt/nand $ mount -t ubifs ubi0:rootfs /mnt/nand $ tar xvf rootfs.tar.gz -C /mnt/nand
5. Change the bootargs like below for booting from UBIFS. 'ubi.mtd=4 rootfstype=ubifs root=ubi0:rootfs rw'
HI Thomas,
Sorry for the late reply, I was in my vacation last week.
Thank you for your guidance. I made it according your steps. The rootfs is working now. But why it doesn't work when flashing a ubinized image to nand? Does this mean there is something wrong with the parameters of mkfs.ubifs and/or ubinize? How to check the parameters?
Thank you very much.
Hi Lihua,
There are couple of issues in flashing from u-boot. Are you really looking forward to flash from u-boot?
Hi Renjith,
We have a tool which can flash u-boot, kernel and rootfs in one step. It's very convenience for the line workers to produce products. So I prefer to make an image.
could you please tell me what are the issue in flashing from u-boot., or could you please provide some links for that? I'm new to UBI. Thank you.
One major issue with u-boot and UBI combination is that, assume that the given data for a page is 0xFF, which looks like an erased page. But when you write the same page from u-boot, it will calculate valid ECC values and write.
Since the ubi.img will have pages which are erased(filled with 0xFF), and during bootup it will write these pages without erasing as it assumes these pages are already erased. So what happens here is, the kernel will overwrite the data area as well as spare area. Since the spare area already contains valid values, this write will overwrite it and corrupt it.
So when it reads the page again, the ECC will mismatch even though the data is proper. It will try to correct (in turn corrupt) the data and if correction algorithm reaches its limit, the page read will fail with ECC errors.
To avoid this problem you've to add support for a command in u-boot for flashing UBI images. Or else you can hack the u-boot NAND driver to ignore writes to the pages where data is completely 0xFF.
Hope the issue with u-boot is clear. Have you also explored the option of using NAND bulk programmer?
You might be able to work around this using UBIFS "free space fixup":
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_free_space_fixup
Thank you for the detailed explanation. Now I understand.
For the K9GAG08uom, the datasheet claims that it need 24 bit ECC per 1KB data. But 6410 can provide only 16 bit ECC per 1KB data. I think it is not very safe to use that CPU with this nand flash. So I quit.
We have decided to use AM3352 with a SLC nand. Many thanks to all you guys.