[hawkboard.org] JFFS2 mtd-> read returned ECC error in NAND

[Harishkumar V]

Hi,

I am trying the boot the kernel and rootfs from NAND.

For rootfs, i am using jffs2.

I did the following things, but it does not work.

1) created jffs2 image using mkfs.jffs2.

in bootloader,

1) setenv serverip <server ipaddress>
2) setenv ipaddr <board ipaddress>
3) tftp 0xc0700000 uImage
4) nand erase 0x200000 0x200000;nand write.e 0xc0700000 0x200000 0x200000
5) tftp 0xc1180000 rootfs.jffs2
6) nand erase 0x400000 0x7c00000                        (0x7c00000 - from /proc/mtd)
7) nand write.jffs2 0xc1180000 0x400000 ${filesize}

rebooted the board, then

8) setenv bootargs 'mem=128M console=ttyS2,115200n8 root=/dev/mtdblock4 rw rootfstype=jffs2 noinitrd rootdelay=1'
9) nboot.e 0xc0700000 0 0x200000; bootm

The kernel boots fine, but when mounting /dev/mtdblock4 , it fails and throws the following errors and kernel panic comes.

mtd->read returned ECC error.
mtd->read returned ECC error.
mtd->read returned ECC error.
mtd->read returned ECC error.
mtd->read returned ECC error.
mtd->read returned ECC error.

Also, i tried flash_eraseall from NFS, it shows,

#flash_eraseall -j /dev/mtd4

error : unable to get NAND oobinfo

I am struck and i have series of questions,
1) is it a NAND problem wrt JFFS2
2) If JFFS2 is not, which one is preferred?
3) Is this can be solved, (ie) can make JFFS2 to work?


--
Thanks and Regards,
Harish Kumar. V

[Caglar Akyuz]

> *error : unable to get NAND* oobinfo
>

I faced the same error when playing my NAND for the first time. What I did is to use 'nand scrub' under u-boot(Yes it is scary). Then I flashed filesystem from userspace, I couldn't make it work under u-boot.

> I am struck and i have series of questions,
> 1) is it a NAND problem wrt JFFS2
> 2) If JFFS2 is not, which one is preferred?
> 3) Is this can be solved, (ie) can make JFFS2 to work?
>

I don't know for JFFS2 but if you are interested in UBI here are my steps:

1) There is problem with sub page write on L-138. You can see the details and my dirty fixup at [1].

2) After patching kernel, I need to change my ubinize commands. This makes
Narcissus possibly useless for this case. So You should be able to creating ubi with your own commands. For OpenEmbedded/Angstrom you can change hawkboard.conf like the following:
________________________________________________________
# do ubiattach /dev/ubi_ctrl -m 4
# From dmesg:
# UBI: smallest flash I/O unit: 2048
# UBI: logical eraseblock size: 126976 bytes
# from ubiattach stdout:
# UBI device number 0, total 960 LEBs
MKUBIFS_ARGS = "-m 2048 -e 126976 -c 960"

# do ubiattach /dev/ubi_ctrl -m 4
# from dmesg:
# UBI: smallest flash I/O unit: 2048
# UBI: physical eraseblock size: 131072 bytes (128 KiB)
# UBI: sub-page size: 512
UBINIZE_ARGS = "-m 2048 -p 128KiB -s 2048"
________________________________________________________

3) Then all you need to do is boot Linux from somewhere other than NAND and type:

$ubiformat /dev/mtd4 -f rootfs.ubi

Relevant boot options for this file system is something like:

ubi.mtd=filesystem root=ubi0:hawkboard-rootfs rootfstype=ubifs ...

Best Regards,
Caglar

[1] http://patchwork.ozlabs.org/patch/50601/

[Harishkumar V]

Caglar,

Thanks, it sounds good.

My requirement needs write support. will UBI supports writing back the data to the flash.

Also, I will apply the patch and check it.

[Caglar Akyuz]

On Friday 07 May 2010 12:32:29 pm Harishkumar V wrote:
> Caglar,
>
> Thanks, it sounds good.
>
> My requirement needs write support. will UBI supports writing back the data
> to the flash.
>

Yes. UBIFS is the successor of JFFS2 with many enhancements. [1] has nice
comparison of various filesystems including JFFS2 and UBIFS.

> Also, I will apply the patch and check it.
>

BTW, your current OOB problem still can hunt you down.

Regards,
Caglar

[1] http://freeelectrons.com/pub/conferences/2008/elce/flashfilesystems.pdf

[Harishkumar V]

Caglar,

I am unable to open http://freeelectrons.com/pub/conferences/2008/elce/flashfilesystems.pdf

cool. Will the data will be saved on reboots, like JFFS2.

I cannot understand,

BTW, your current OOB problem still can hunt you down.

Does it mean, still OOB errors will appear, if i use UBI.

[Caglar Akyuz]

On Friday 07 May 2010 12:48:31 pm Harishkumar V wrote:
> Caglar,
>

> I am unable to open
> http://freeelectrons.com/pub/conferences/2008/elce/flashfilesystems.pdf
>

It should be :
http://free-electrons.com/pub/conferences/2008/elce/flash-filesystems.pdf

> cool. Will the data will be saved on reboots, like JFFS2.
>

Yes.

> I cannot understand,
> BTW, your current OOB problem still can hunt you down.
>
> Does it mean, still OOB errors will appear, if i use UBI.
>

Yes, that's what I meant. Erasing whole flash from u-boot may fix that.

Regards,
Caglar

[Harishkumar V]

Caglar,

Thanks, the flashfilesystems.pdf was really good.

[Harishkumar V]

Caglar,

for UBI,

In kernel configuration ,i have the following things set,

Enable UBI
UBI wear levelling threashold - 4096
percentage of reserved eraseblocks  - 1
UBI debugging
UBI debugging messages
Extra self-checks.

My concern is about "Do not enable the UBI background thread", as far as i know abt this, the thread is taking care of write-buffer.

By default, it is disabled, do i need to enable or disable.

[Caglar Akyuz]

On Friday 07 May 2010 03:19:47 pm Harishkumar V wrote:
> Caglar,
>

> for UBI,
>
> In kernel configuration ,i have the following things set,
>
> Enable UBI
> UBI wear levelling threashold - 4096
> percentage of reserved eraseblocks - 1
> UBI debugging
> UBI debugging messages
> Extra self-checks.
>
> My concern is about "Do not enable the UBI background thread", as far as i
> know abt this, the thread is taking care of write-buffer.
>

In my current config, UBI debugging is not set, so nothing to do about
background thread. Here is my relevant kernel config:

# UBI - Unsorted block images
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
CONFIG_MTD_UBI_GLUEBI=m
# UBI debugging options
# CONFIG_MTD_UBI_DEBUG is not set
# CONFIG_JFFS2_RUBIN is not set
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_XATTR=y
CONFIG_UBIFS_FS_ADVANCED_COMPR=y
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_UBIFS_FS_DEBUG is not set

Regards,
Caglar

[Harishkumar V]

Caglar,

Sorry, to disturb u, once again,

Can u send the commands that worked for you after applying the patch.

[Caglar Akyuz]

On Saturday 08 May 2010 10:37:14 am Harishkumar V wrote:
> Caglar,
>
> Sorry, to disturb u, once again,
>
> Can u send the commands that worked for you after applying the patch.
>

First you can check if subpage reads are disabled with:

$cat /sys/class/mtd/mtd4/subpagesize

You should see 2048 here. Then you can try if ubi is workable on the board:

$ubiformat /dev/mtd4
$ubiattach /dev/ubi_ctrl -m 4
$ubimkvol /dev/ubi0 -N filesytem -s 100MiB
$mount -t ubifs /dev/ubi0_0 /mnt/cf

At this point you can write some things to /mnt/cf, umount it, restart your
board and mount it with 4 commands above again. You should see your changes.

Last step is to create your own UBI image, I use OE always for this step but
I'm fairly sure that relevant ubifs arguments are:

MKUBIFS_ARGS = "-m 2048 -e 126976 -c 960"

and ubinize arguments are:

UBINIZE_ARGS = "-m 2048 -p 128KiB -s 2048"

When you have a something to burn to flash, you can write it with following
command from Linux:

$ubiformat /dev/mtd4 -f rootfs.ubi

Regards,
Caglar

[Harishkumar V]

Caglar,

After analysing and fighting with the nand and ubi, I completely agree with ,

"My conclusion is that nand driver cannot work reliably with 512 byte writes to
a page so it should be disabled for the time being."

I faced problems mentioned in the following link,

http://e2e.ti.com/support/embedded/f/354/p/42731/149058.aspx

After applying ur patch and did the steps given by you, all problems gone....

its a happy ending for me.... now, able to boot from bootargs also, did the test for 5 times, reliablely working.

Thanks very much for help and sorry for disturbing.

On Sat, May 8, 2010 at 2:45 PM, Harishkumar V <harish...@gmail.com> wrote:

Caglar,

ubiformat /dev/mtd5 -s 512 -f ubi.img

this works.

On Sat, May 8, 2010 at 1:51 PM, Caglar Akyuz <cagla...@gmail.com> wrote:

On Saturday 08 May 2010 11:07:00 am Harishkumar V wrote:
> Caglar,
>

> for me,
>
> cat /sys/class/mtd/mtd4/subpagesize is 512.
>

Since patch is not applied, this is expected.

> i am using two filesystems, one is squashfs (readonly) and other is ubifs
> for rw.
>

It's fine having more than one partition.

I followed the instructions you gave, I see that you are able to mount UBI
partitions. But, I guess you will get error 22 when you try to write your UBI
image with ubiformat utility. At least that was what I got.

My conclusion is that nand driver cannot work reliably with 512 byte writes to
a page so it should be disabled for the time being.

Regards,
Caglar

> On Sat, May 8, 2010 at 1:34 PM, Harishkumar V
<harish...@gmail.com>wrote:
> > Hi,
> >
> > without the patch being applied, it works , these are the steps, i tried,
> > i have spilt the filesystem into equal 2 partitions, so, for me, its
> > /dev/mtd4 and /dev/mtd5.
> >
> > 1) ubinize.cfg
> >
> > [ubifs]
> > mode=ubi
> > image=ubifs.img
> > vol_id=0
> > vol_size=55MiB
> > vol_type=dynamic
> > vol_name=rootfs
> > vol_flags=autoresize
> >
> > 2) ./mkfs.ubifs -e 129024 -c 489 -m 2048 -r filesys -o ubifs.img
> >
> > 3) ./ubinize -o ubi.img -p 128KiB -m 2048 -s 512 ./ubinize.cfg
> >
> > 4) flash_eraseall /dev/mtd5
> >
> > 5) ubiformat /dev/mtd5 -s 512
> >
> > 6) ubiformat /dev/mtd5 -s 512 -f ubi.img
> >
> > 7) ubiattach /dev/ubi_ctrl -m 5
> >
> > o/p :
> >
> > UBI: attaching mtd5 to ubi0^M
> > UBI: physical eraseblock size:   131072 bytes (128 KiB)^M
> > UBI: logical eraseblock size:    129024 bytes^M
> > UBI: smallest flash I/O unit:    2048^M
> > UBI: sub-page size:              512^M
> > UBI: VID header offset:          512 (aligned 512)^M
> > UBI: data offset:                2048^M
> > UBI: volume 0 ("rootfs") re-sized from 447 to 481 LEBs^M
> > UBI: attached mtd5 to ubi0^M
> > UBI: MTD device name:            "filesystem_2"^M
> > UBI: MTD device size:            62 MiB^M
> > UBI: number of good PEBs:        489^M
> > UBI: number of bad PEBs:         7^M
> > UBI: max. allowed volumes:       128^M
> > UBI: wear-leveling threshold:    4096^M
> > UBI: number of internal volumes: 1^M
> > UBI: number of user volumes:     1^M
> > UBI: available PEBs:             0^M
> > UBI: total number of reserved PEBs: 489^M
> > UBI: number of PEBs reserved for bad PEB handling: 4^M
> > UBI: max/mean erase counter: 3/3^M
> > UBI: image sequence number: -1^M
> > UBI: background thread "ubi_bgt0d" started, PID 391^M
> > UBI device number 0, total 489 LEBs (63092736 bytes, 60.2 MiB), available
> > 0 LEBs (0 bytes), LEB size 129024 bytes (126.0
> > KiB)
> >
> >
> > 8) mount -t ubifs ubi0:rootfs /mnt/test
> >
> > o/p:
> >
> > UBIFS: mounted UBI device 0, volume 0, name "rootfs"^M
> > UBIFS: file system size:   60770304 bytes (59346 KiB, 57 MiB, 471 LEBs)^M
> > UBIFS: journal size:       8257536 bytes (8064 KiB, 7 MiB, 64 LEBs)^M
> > UBIFS: media format:       w4/r0 (latest is w4/r0)^M
> > UBIFS: default compressor: lzo^M
> > UBIFS: reserved for root:  0 bytes (0 KiB)^M
> >
> > 9) mount
> >
> > o/p:
> >
> > ubi0:rootfs on /mnt/test type ubifs (rw,relatime)^M

> > --
> > Thanks and Regards,
> > Harish Kumar. V
>

--

Thanks and Regards,
Harish Kumar. V

--

Thanks and Regards,
Harish Kumar. V