headers
Charles Manning | 1 Jun 2005 06:41
Picon

Re: Samsung RFS Filesystem

On Tuesday 31 May 2005 23:42, Ludovic Guilhamat wrote:
> Hi,
>
> I would maybe interested in testing the Samsung RFS File System...
>
> Does someone, here, already used it, and what are the conclusions ?

Please do do some testing. It would be good to see the results, positive or 
negative.

I have not used it, but from a description I can draw some immediate 
conclusions.

RFS = Robust FAT file system

>From the blurb at 
http://www.samsung.com/Products/Semiconductor/Flash/TechnicalInfo/rfs.htm

this looks a bit like FATFS running on top of DOC. It might have some 
transactioning which would make it look a bit more like Microsoft's TFAT.

Neither of these are a proven reliable system. DOC can still get FAT 
corruptions if you don't umount before power loss (== potentially a 
completely scrambled fs). TFAT is completely unprovedn and is slower and not 
always robust (not robust with typical mount options). Perhaps RFS gets the 
robustness right.

Running FAT on NAND costs some performance due to the FTL etc.  To make a 
journaling system on FAT, as RFS claims, costs even more performance.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ludovic Guilhamat | 1 Jun 2005 08:28
Picon

Re: Samsung RFS Filesystem

Charles Manning a écrit :

>On Tuesday 31 May 2005 23:42, Ludovic Guilhamat wrote:
>  
>
>>Hi,
>>
>>I would maybe interested in testing the Samsung RFS File System...
>>
>>Does someone, here, already used it, and what are the conclusions ?
>>    
>>
>
>
>Please do do some testing. It would be good to see the results, positive or 
>negative.
>
>I have not used it, but from a description I can draw some immediate 
>conclusions.
>
>RFS = Robust FAT file system
>
>>From the blurb at 
>http://www.samsung.com/Products/Semiconductor/Flash/TechnicalInfo/rfs.htm
>
>this looks a bit like FATFS running on top of DOC. It might have some 
>transactioning which would make it look a bit more like Microsoft's TFAT.
>
>Neither of these are a proven reliable system. DOC can still get FAT 
>corruptions if you don't umount before power loss (== potentially a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jörn Engel | 1 Jun 2005 10:51
Picon

Re: Oops on rmmod mtdblock module while in dev dir.

On Tue, 31 May 2005 16:57:49 +0100, David Woodhouse wrote:
> On Tue, 2005-05-31 at 10:55 -0500, Josh Boyer wrote:
> > It's even more complicated when working with partitions.  A MTD
> > partition is actually a whole new device to MTD, whereas a partition in
> > general block terms is just a subset of a particular device.  Things in
> > this area need some help.
> 
> That's just a terminology mismatch though, and shouldn't really be
> relevant.

Unless you add hotplug.  Treating partitions as independent devices
might have some interesting effects.

Jörn

--

-- 
Happiness isn't having what you want, it's wanting what you have.
-- unknown

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Konstantin Kletschke | 1 Jun 2005 15:41
Picon

Intel flash that powers up locked

Hi there!

I have intel K3 devices on my Board and the linux Kernel needs to unlock
them.
I found
http://lists.infradead.org/pipermail/linux-mtd/2005-April/012431.html
and incorporated the provided diff into a daily-mtd-cvs snapshot from
20050530 in 2.6.11.
However, this code Oopses in cfi_intelext_unlockall():

static void cfi_intelext_unlockall(struct mtd_info *mtd)
{
#if 1
        int i;
        for (i = 0; i <= mtd->numeraseregions; i++) {
                printk("mtd->numeraseregions %x\n", mtd->numeraseregions);
                int j;
                printk("rumms\n");
                printk("mtd->eraseregions[0].numblocks %x\n", 
                                mtd->eraseregions[i].numblocks);
                printk("bumms\n");
...

The printk("mtd->eraseregions[0].numblocks %x\n", 
				mtd->eraseregions[i].numblocks);

causes The Oops. How is that possible?
Also weird is that mtd->numeraseregions is 0.

Probing scb9328_flash at physical address 0x10000000 (16-bit buswidth)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Charles Manning | 2 Jun 2005 01:49
Picon

Re: Samsung RFS Filesystem


> Actually, the system I work on uses Jffs2 (Coldfire with uClinux). But,
> mount times are very long (the memory is a Flash Nand 16Mb). So, I
> planned to test Jffs2 patches (from the Jffs2 Improvement Project), then
> Yaffs. And as RFS is not freely distributed, and I don't know yet its
> cost, I wanted to know if someone had tested it.

Pick up a more recent JFFS2, I believe that there have been some speedups.

I get a lot of feedback that YAFFS is typically a few times faster than JFFS2

FAT is indeed "instant mounting" and uses less RAM because it is not log 
structured. FAT however does have a bad record as far as reliability and 
write speed on raw NAND devices.

In the end you need to look at pros and cons and fit them to your system 
needs.

-- Charles

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Ratan Panneerselvam | 2 Jun 2005 06:15

Re: Intel flash that powers up locked

Konstantin Kletschke wrote:

>Has anybody Intel K3 unlocking working and if yes, how is his or her map
>driver looking?
>  
>
I had the Intel K3 unlocked successfully in the map driver on a 2.4.20
kernel with this call:
nor_info->unlock( nor_info, 0, nor_info->size );

However on the 2.6.12 from cvs <at> ftp.linux-mips.org, the same map driver
gives an oops similar to yours.

regards,
ratan

map driver code snippet:
>>>>>
    simple_map_init(&nor_map);
    nor_info = do_map_probe("cfi_probe", &nor_map);
    if (!nor_info) {
        err("cfi_probe: NOR flash probe failed");
        iounmap(nor_map.virt);
        return -ENXIO;
    }

    nor_info->owner = THIS_MODULE;

    if (nor_info->unlock)
    {
(Continue reading)

Permalink | Reply | 3 comments |
headers
Konstantin Kletschke | 2 Jun 2005 12:19
Picon

Re: Intel flash that powers up locked

* Ratan Panneerselvam <ratan <at> thattiko.net> [Thu, Jun 02, 2005 at 12:15:17AM -0400]:

> However on the 2.6.12 from cvs <at> ftp.linux-mips.org, the same map driver
> gives an oops similar to yours.

He, weird...

at first, what I don't understand in my quoted code snippets is the
following:

Creating 5 MTD partitions on "scb9328_flash":             
0x00000000-0x00020000 : "U-boot"             
0x00020000-0x00040000 : "U-boot_env"
cfi_intelext_unlock: lock status before, ofs=0x00000000, len=0x00020000
cfi_intelext_unlock: lock status after, ret=-1070912512                
0x00040000-0x00240000 : "kernel"                       
cfi_intelext_unlock: lock status before, ofs=0x00000000, len=0x00200000
cfi_intelext_unlock: lock status after, ret=-1070913024                
0x00240000-0x00740000 : "root"                         
cfi_intelext_unlock: lock status before, ofs=0x00000000, len=0x00500000
cfi_intelext_unlock: lock status after, ret=-1070913536                
0x00740000-0x01000000 : "fs"                           
cfi_intelext_unlock: lock status before, ofs=0x00000000, len=0x008C0000
cfi_intelext_unlock: lock status after, ret=-1070914048

That comes from 
cfi_intelext_unlock(mtd, 0, mtd->size);
being called, the cfi_varsize_frob functions are all commented out,
only the DEBUG_LOCK_BITS are functional.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Gleixner | 2 Jun 2005 12:46
Picon

Re: Intel flash that powers up locked

On Thu, 2005-06-02 at 12:19 +0200, Konstantin Kletschke wrote:

> Why is cfi_intelext_unlock() called with ofs=0, is that correct?
> Shouldn't there be hardware addresses?

Maybe it helps if you read the code of the invoked function
(cfi_varsize_frob).

tglx

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 1 comment |
headers
Munira Ahmed | 2 Jun 2005 13:01

jffs2, intel flash and i.MX21

I am working with i.Mx21 and intel strata nor flash. I wish to use jffs2
and I have got a readymade jffs2 file sytem for nor flash from may be
freescale/motorola. I am told that this file system is supposed to be
mounted by the kernel when it boots up. However it does happen so and
system does not boot at all. Can anybody please tell me what's wrong.

I have enabled mtd, jffs2 and intel flash support with bus size of 32.
The intel flash driver cfi_cmdset_0001.c is also there.

Can anybody please give me a clue 

1)	how can I debug that 
2) 	which part of the kernel should I look into i.e where do I found the
code to mount the jffs2 in the kernel tree
3) what might be missing in the kernel config
4) any other idea?

--

-- 
Munira Ahmed

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 2 comments |
headers
Konstantin Kletschke | 2 Jun 2005 13:26
Picon

Re: jffs2, intel flash and i.MX21

Am 2005-06-02 19:01 +0800 schrieb Munira Ahmed:

> 1)	how can I debug that 

Tell us what you did, what is happening, what should happening, what
hardware you are using, which bootloader.

> 2) 	which part of the kernel should I look into i.e where do I found the
> code to mount the jffs2 in the kernel tree

Oh my... fs/jffs2 or drivers/mtd.

> 3) what might be missing in the kernel config

Many many things. A mapping driver, or partition support, wrong
commandline, wrong chip driver, modules instead of *'s.

> 4) any other idea?

Many, your provided information is very insufficient.

Regards, Konsti

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 1 comment |

Gmane