Re: [Gumstix-users] Moving from JFFS2 to UBIFS

[cybaslt <cy...@ho...>]

It works!

Small tutorial of how to do it using Bitbake to generate UBI image (you can
do it manually):
(a) Edit machine configuration:
~/overo-oe/org.openembedded.dev/conf/machine/overo.conf by updating this
line: IMAGE_FSTYPES += "tar.bz2 ubi". Now you gonna get old good tar.bz2 and
additionally ubi image. uImage and u-boot are not affected by this.

(b) You have to follow steps in NAND flashing bash script for mtd1, mtd2,
and mtd3.

(c) For mtd4 you have to change steps:
ubiformat /dev/mtd4 -s 512 -f <your_image>.ubi

(d) If you wanna mount it:
mkdir -p /media/mynand
ubiattch /dev/ubi_ctrl -m 4
mount -t ubifs ubi0[:vol_name] /mnt/root # :vol_name is optional. It is
taken from ubinize.cfg (same location as ubi image generated). Mostly it
will be "overo-rootfs".

(e) During boot change execute these two lines:
setenv nandroot 'ubi0:overo-rootfs ubi.mtd=4'
setenv nandrootfstype ubifs

No more file system warning, df -h returns nice numbers, SQLite3 WAL mode
works! Simply put much more stable, I would suggest every one moving from
JFFS2. It is just making problems.

-david




cybaslt wrote:
> 
> So, Bitbake generates .ubi and .ubifs files. I was using .ubi file, don't
> know if that is bad or not.
> 
> All u-boot and uImage as before was generated as .bin.
> 
> So I tried doing manual flashing following these steps:
> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html
> 
> So u-boot and uImage steps where unchanged, but for the rootfs I did:
> ubiformat /dev/mtd4 -f my_image.ubi
> 
> I change u-boot environment as was given.
> 
> The result was:
> twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC
> (946684800)
> Root-NFS: No NFS server available, giving up.
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "(null)" or unknown-block(2,0)
> Please append a correct "root=" boot option; here are the available
> partitions:
> 1f00             512 mtdblock0 (driver?)
> 1f01            1792 mtdblock1 (driver?)
> 1f02             256 mtdblock2 (driver?)
> 1f03            4096 mtdblock3 (driver?)
> 1f04          255488 mtdblock4 (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
> 
> I was trying to mount it with:
> 
> mkdir -p /media/mtdblock4
> mount -t ubifs /dev/mtd4 /media/mtdblock4
> 
> result:
> root@overo:~/images# mount -t ubifs /dev/mtd4 /media/mtdblock4     
> UBIFS error (pid 1660): ubifs_get_sb: cannot open "/dev/mtd4", error -22
> mount: wrong fs type, bad option, bad superblock on /dev/mtd4,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> 
> Tried:
> root@overo:~/images# mount -t ubifs /dev/mtdblock4 /media/mtdblock4
> UBIFS error (pid 1661): ubifs_get_sb: cannot open "/dev/mtdblock4", error
> -22
> mount: wrong fs type, bad option, bad superblock on /dev/mtdblock4,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> 
> I tried fdisk:
> root@overo:~/images# fdisk /dev/mtdblock4
> Device contains neither a valid DOS partition table, nor Sun, SGI or OSF
> disklabel
> Building a new DOS disklabel with disk identifier 0xf67d5bbf.
> Changes will remain in memory only, until you decide to write them.
> After that, of course, the previous content won't be recoverable.
> 
> So, what I have missed?
> 
> 
> 
> Jeff DeFouw-2 wrote:
>> 
>> On 12/6/2010 8:45 PM, Chris Whittenburg wrote:
>>> If you set the OE options and build a ubifs, then next you should
>>> change the uboot variables--
>>>
>>> setenv nandroot 'ubi0:overo-rootfs ubi.mtd=4'
>>> setenv nandrootfstype ubifs
>>> setenv nandargs 'setenv bootargs console=${console} mpurate=${mpurate}
>>> vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y
>>> omapfb.vram=${fbvram} omapdss.def_disp=${defaultdisplay} ${mem}
>>> root=${nandroot} rootfstype=${nandrootfstype}'
>>>
>>> then boot from an mmc card and write your ubifs to nand with something
>>> like
>>>
>>> # flash_eraseall /dev/mtd4
>>> # nandwrite -p /dev/mtd4 fs.ubi
>>>
>>> Then I think you can reboot without the mmc and it should boot with
>>> your ubifs...
>> 
>> UBI has its own format tool to prepare the NAND properly, so you would
>> replace 
>> the flash_eraseall and nandwrite with something like this:
>> 
>> ubiformat /dev/mtd4 -f fs.ubi
>> 
>> It scans the flash first and asks you for confirmation if something is
>> wrong, 
>> including if something other than UBI is already on it.  There are other 
>> options you might need to match up.
>> 
>> -- 
>> Jeff DeFouw <je...@gr...>
>> Programmer
>> Grand Rapids Technologies
>> 
>> ------------------------------------------------------------------------------
>> What happens now with your Lotus Notes apps - do you make another costly 
>> upgrade, or settle for being marooned without product support? Time to
>> move
>> off Lotus Notes and onto the cloud with Force.com, apps are easier to
>> build,
>> use, and manage than apps on traditional platforms. Sign up for the Lotus 
>> Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
>> _______________________________________________
>> gumstix-users mailing list
>> gum...@li...
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>> 
>> 
> 
> 

-- 
View this message in context: http://old.nabble.com/Moving-from-JFFS2-to-UBIFS-tp30372267p30399763.html
Sent from the Gumstix mailing list archive at Nabble.com.