headers
harsh poshtiwala | 1 Apr 2007 21:59
Picon

MTD partition on ARM

I am novice to this stuff.

I need to make MTD partition followed by JFFS2 file system on
NOR flash of one of the ARM926ejs based board.

I didn't get much information about

1,How can i create MTD partition ? strps to create those.
2,Do i need to have MTD utilities ?
3,If yes what are the steps to integrate it ?
4,How can i implement JFFS2 on MTD partition?

I would appreciate your guidence /documentation that shows me
entire procedure  to get me going on this stuff.

--

-- 
Thanks & Regards
Harsh

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 1 comment |
headers
John Williams | 2 Apr 2007 03:09
Picon
Picon
Favicon

ENOENT creating /dev/root on MTD RAM partition

Hello,

I'm working on the 2.6 kernel for MicroBlaze (embedded, NOMMU) arch. 
Like some other nommu archs, we typically mount root on an MTD RAM 
partition (either CRAMFS or ROMFS).

All of this is working fine on 2.6.19 plus SnapGear 2.6.19-uc0-bigpatch 
NOMMU patchset.

However, since coming forward to 2.6.20 (plus equiv. SnapGear patchset) 
mount_root is failing.

Details follow, but basically create_dev(/dev/root, ROOT_DEV) is 
returning -ENOENT.  ROOT_DEV points to a valid MTD RAM partition, with a 
valid ROMFS (or CRAMFS, doesn't matter which) image. I've dumped the 
memory, the image is good.

Googling the various archives finds one or two past references to 
create_dev or do_mount_root returning -ENOENT on MTD RAM partitions, but 
I found no followups or solutions posted.

 From my bootlog:

uclinux[mtd]: RAM probe address=0x22182cc8 size=0x21d000
Creating 1 MTD partitions on "RAM":
0x00000000-0x0021d000 : "ROMfs"
mtd: Giving out device 5 to ROMfs
uclinux[mtd]: set ROMfs to be root filesystem index=5

...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joakim Tjernlund | 2 Apr 2007 12:00
Picon

[Resend: [PATCH] Speed up mount for cfi_cmdset_0001 users]

Resending.

 Jocke 
-------- Forwarded Message --------
From: Joakim Tjernlund <joakim.tjernlund <at> transmode.se>
Reply-To: joakim.tjernlund <at> transmode.se
To: linux-mtd <at> lists.infradead.org
Subject: [PATCH] Speed up mount for cfi_cmdset_0001 users
Date: Tue, 27 Mar 2007 13:44:01 +0200

This will speed up mount greatly for users of point/unpoint method
like cfi_cmdset_0001. Please Apply.

 Jocke

>From bcd1aa987ab786c526e225269775a557a1bcbe1f Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund <at> transmode.se>
Date: Tue, 27 Mar 2007 13:32:09 +0200
Subject: [PATCH] Speed up mount for cfi_cmdset_0001 users
Remove excessive scanning of empty flash after a clean
marker for users of the point/unpoint method. cfi_cmdset_0001
uses point/unpoint by default iff flash mapping is linear.
The speedup is several orders of magnitude if FS is less than
half full.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund <at> transmode.se>
---
 fs/jffs2/scan.c |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)
(Continue reading)

Permalink | Reply | 501 comments |
headers
Artem Bityutskiy | 2 Apr 2007 12:53
Favicon

Re: [RFC] [PATCH] UBI: refine wear leveling logic

On Fri, 2007-03-30 at 16:40 +0200, Alexander Schmidt wrote:
> In the current code, wl_get_peb() calls produce_free_peb() if the
> free tree is empty and thereby performs a synchronous work (even if the
> bgt is enabled). This is what I meant with "mixing" sync/async.

OK, what's wring with this? We do not have eraseblocks, we produce them
synchronously.

We cannot rely on the thread - what if it was killed or its priority is
too low, but the requesting task needs eraseblocks ASAP.

> So I think making the user thread wait for the wl thread to free a peb
> (e.g. by sleeping while waiting for a semaphore) could lead to a better
> performance as the wl thread will likely finish its work before the user
> thread has performed a whole work.

Not necessarily. The current approach is safer.

--

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Iyer | 2 Apr 2007 18:05
Picon
Favicon

Magic bitmask 0x1985 messages, while attempting to mount a JFFS2 filesystem on dataflash

Hi Folks,

I seem to be getting the "Magic bitmask 0x1985" errors
on attempting to mount a JFFS2 filesystem on a
dataflash (AT45DB321). This is the very first FAQ in
the JFFS2 FAQ. It may be likely that the data on the
flash is not a valid JFFS2 image.

Here are the steps I did, please let me know if I have
done anything wrong. The same JFFS2 image was mounting
well on the NAND flash (with the corresponding
mkfs.jffs2 -e and --pad options set for the NAND
flash), but not on the data flash.

The kernel was compiled with the MTD relevant options
for having the kernel, RFS and bootloader on the
dataflash, for the board AT91SAM9261-EK:

CONFIG_MTD =y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_DATAFLASH=y

The JFFS2 image was created with the options -e 528 -n
--pad= 777744 (a multiple of 528) for mkfs.jffs2
(erase size:528 for the AT45DB321)

The following bootargs to partition the MTD dataflash
(Continue reading)

Permalink | Reply | 1 comment |
headers
MikeW | 2 Apr 2007 19:18
Picon
Favicon

Re: MTD partition on ARM

harsh poshtiwala <hiharsh <at> gmail.com> writes:

> 
> I am novice to this stuff.
> 
> I need to make MTD partition followed by JFFS2 file system on
> NOR flash of one of the ARM926ejs based board.
> 
> I didn't get much information about
> 
> 1,How can i create MTD partition ? strps to create those.
> 2,Do i need to have MTD utilities ?
> 3,If yes what are the steps to integrate it ?
> 4,How can i implement JFFS2 on MTD partition?
> 
> I would appreciate your guidence /documentation that shows me
> entire procedure  to get me going on this stuff.
> 
I agree - there is no from-the-ground-up explanation and HowTo
for MTD. Unfortunately I am not yet expert enough myself to
write am authoritative guide.

Keep Googling (with a few well-chosen keywords as well as 'MTD') !!

Regards,
MikeW

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Williams | 3 Apr 2007 06:39
Picon
Picon
Favicon

Re: [uClinux-dev] ENOENT creating /dev/root on MTD RAM partition

I wrote:

> I'm working on the 2.6 kernel for MicroBlaze (embedded, NOMMU) arch. 
> Like some other nommu archs, we typically mount root on an MTD RAM 
> partition (either CRAMFS or ROMFS).
> 
> All of this is working fine on 2.6.19 plus SnapGear 2.6.19-uc0-bigpatch 
> NOMMU patchset.
> 
> However, since coming forward to 2.6.20 (plus equiv. SnapGear patchset) 
> mount_root is failing.

Problem solved.  An error in the arch link script resulted in the 
initcall_rootfs initcalls to not be invoked - thus the stub init_ramfs 
wasn't mounted, and /dev didn't exist.

John

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Jitendra Jain | 4 Apr 2007 08:38

MEMGETREGIONCOUNT ioctl


Hi All,
 
I am trying to get some information regarding my NAND device on board
through the MEMGETREGIONCOUNT and the MEMGETREGIONINFO ioctls. What
troubles me is that the mtd/util application "flash_info" also doesnt
come to my rescue.
 
As per the driver, the MEMGETREGIONCOUNT returns the parameter
numeraseregions, which is meant to signify if the flash erase size is
same throughout or whether it has variable sized sectors (which is found
on NOR flash devices). Why does the util denote that number as number of
erase regions ??
 
Next, the MEMGETREGIONINFO seems to copy arguments from User to the
kernel which I dont understand. This is meant to give the User
information so, it ought to be copy_to_user.
 
Please excuse me if I am wrong on both the above accounts, but i would
be glad if anybody would let me know about that...
 
Thanx,

Regards
Jitendra Jain,

 

eInfochips Business Disclaimer:
This message may contain confidential, proprietary or legally Privileged information. In case you are
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gavin Lambert | 4 Apr 2007 09:11

RE: MEMGETREGIONCOUNT ioctl

I'm a bit of an MTD newbie myself, so I could be wrong about some of
this, but:

Quoth Jitendra Jain [jitendra.jain <at> einfochips.com]:
> As per the driver, the MEMGETREGIONCOUNT returns the
> parameter numeraseregions, which is meant to signify if the
> flash erase size is same throughout or whether it has
> variable sized sectors (which is found on NOR flash devices).
> Why does the util denote that number as number of erase regions ??

Because that's sort of what it is.  If your driver doesn't support the
ioctl at all then callers assume the erase size is constant as given in
the erasesize field of MEMGETINFO.  If it does support the ioctl, then
callers expect it to return the number of erase block size-change
thresholds (since a region can cover multiple erase blocks, provided
they're contiguous and of the same size).

> Next, the MEMGETREGIONINFO seems to copy arguments from User
> to the kernel which I dont understand. This is meant to give
> the User information so, it ought to be copy_to_user.

It's bidirectional.  It has to first copy to the kernel so that the
kernel can read the regionindex field and find out which region the user
wants to know about.  Then once it's filled in the rest of the
kernel-side structure it needs to copy that back to userspace.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
(Continue reading)

Permalink | Reply | 1 comment |
headers
MikeW | 4 Apr 2007 09:49
Picon
Favicon

Re: MEMGETREGIONCOUNT ioctl

Gavin Lambert <gavinl <at> compacsort.com> writes:

> 
> I'm a bit of an MTD newbie myself, so I could be wrong about some of
> this, but:
> 
> Quoth Jitendra Jain [jitendra.jain <at> einfochips.com]:
> > As per the driver, the MEMGETREGIONCOUNT returns the
> > parameter numeraseregions, which is meant to signify if the
> > flash erase size is same throughout or whether it has
> > variable sized sectors (which is found on NOR flash devices).
> > Why does the util denote that number as number of erase regions ??
> 
> Because that's sort of what it is.  If your driver doesn't support the
> ioctl at all then callers assume the erase size is constant as given in
> the erasesize field of MEMGETINFO.  If it does support the ioctl, then
> callers expect it to return the number of erase block size-change
> thresholds (since a region can cover multiple erase blocks, provided
> they're contiguous and of the same size).

Perhaps this suggests that the ioctl documentation could be made
clearer or more explicit in this area ...

Regards,
MikeW

=gmane-pad==gmane-pad==gmane-pad==gmane-pad==gmane-pad==gmane-pad=

______________________________________________________
Linux MTD discussion mailing list
(Continue reading)

Permalink | Reply | 0 comments |

Gmane