From: Artem Bityutskiy <dedekind@infradead.org>
To: John Smith <john.smith@arrows.demon.co.uk>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI and OneNAND
Date: Tue, 07 Nov 2006 13:39:38 +0200 [thread overview]
Message-ID: <1162899578.31636.19.camel@sauron> (raw)
In-Reply-To: <loom.20061107T110704-786@post.gmane.org>
Hi, few notes:
On Tue, 2006-11-07 at 10:20 +0000, John Smith wrote:
> UBI: data offset: 2048
> UBI: max. allowed volumes: 128
> UBI: wear-levelling threshold: 4096
> UBI: number of internal volumes: 2
> UBI: number of user volumes: 1
> UBI: available PEBs: 49
> UBI: total number of reserved PEBs: 126
> UBI: number of PEBs reserved for bad PEB handling: 1
Hmm, only one PEB is reserved, may be it makes sense to reserve more -
there is a corresponding option.
>
>
> ##
> ## Then with the busybox shell I can list the MTD partitions
> ##
>
> / # cat /proc/mtd
> dev: size erasesize name
> mtd0: 00c00000 00020000 "BootLoader" <<< Nor Flash
> mtd1: 00400000 00020000 "OldCFE" <<< Nor Flash
> mtd2: 00100000 00010000 "CFE" <<< OneNAND Flash
> mtd3: 00400000 00010000 "Kernel" <<< OneNAND Flash
> mtd4: 00af0000 00010000 "rootfs" <<< OneNAND Flash
> mtd5: 00010000 00010000 "CFE-NVM" <<< OneNAND Flash
> mtd6: 00753800 0000f800 "Kernel" <<< UBI Partition on mtd4:
I would recommend you to use unique names for MTD partitions. You have
two "kernel" partitions.
> ##
> ## Look at existing devices
> ##
> / # ls -l /dev/mtdblock?
> brw-r----- 1 0 0 31, 0 Jan 1 00:00 /dev/mtdblock0
> brw-r----- 1 0 0 31, 1 Jan 1 00:00 /dev/mtdblock1
> brw-r----- 1 0 0 31, 2 Jan 1 00:00 /dev/mtdblock2
> brw-r----- 1 0 0 31, 3 Jan 1 00:00 /dev/mtdblock3
Yo do not need mtdblock devices to mount JFFS2 at all. JFFS2 anyway
works with MTD devices directly and this is just an old way to mount
JFFS2. /dev/mtdX are character devices and you cannot feed the mount
utility by character devices, so this is why fake block devices were
used. Nowadays there is device-less mount support and you may use:
mount mtd7 /mnt/nvm
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2006-11-07 11:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-07 2:35 UBI and OneNAND 박경민
2006-11-07 8:50 ` Frank Haverkamp
2006-11-07 10:20 ` John Smith
2006-11-07 11:39 ` Artem Bityutskiy [this message]
2006-11-07 11:47 ` Josh Boyer
2006-11-07 14:10 ` Artem Bityutskiy
2006-11-07 14:24 ` Josh Boyer
2006-11-07 14:39 ` Artem Bityutskiy
2006-11-07 9:16 ` Artem Bityutskiy
2006-11-08 16:03 ` Artem Bityutskiy
-- strict thread matches above, loose matches on Subject: below --
2006-11-07 12:52 Kyungmin Park
2006-11-08 16:09 ` Artem Bityutskiy
2006-11-04 8:22 UBI and OneNand John
2006-11-06 9:46 ` Frank Haverkamp
2006-11-06 13:18 ` Artem Bityutskiy
2006-11-06 20:16 ` John Smith
2006-11-06 20:54 ` Josh Boyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1162899578.31636.19.camel@sauron \
--to=dedekind@infradead.org \
--cc=john.smith@arrows.demon.co.uk \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.