Re: FFS2 and MTDs (flash)

Re: FFS2 and MTDs (flash)

[David Woodhouse]

jgg@ualberta.ca said:
>  Yes, there is lots of benifit to being able to mount a FFS filesystem
> over a loop device or on a RAM disk or something else. There is also
> lots of benifit to being able to create the FFS off the flash and then
> write the whole thing in one go. For my purposes that is a crucial
> feature. Also since the MTD's are presented as block devices you can
> mount other FS's like romfs in read-only mode.  

OK - that sounds reasonable.

jgg@ualberta.ca said:
>  Things will also run a bit faster if the buffer cache is used to hang
> onto some often used filesystem meta data in main memory.

Think of CFI-compliant flash mapped into the host's address space. Why cache 
it in RAM when you can just point a page table at the original?

> XIP is not directly possible with FFS2 as it places no constraints on
> alignment (like romfs).

So what they say on their web site about XIP is all crap? Of course, I suppose 
that shouldn't surprise me :)

Is it possible to run Linux on FFS2 without some kind on UMSDOS-like 
translation layer? Are we going to want to write our own version which is 
POSIX-compliant?

>  You're welcome to my code so far if you are interested, I have
> support for an Octagon 5066, a V-Max 301 and untested support for
> something called a MixCom card. 

Yes please - that'd be useful.

> BTW, I thought Disk on a chip used an ATA interface, and wasn't really
> a MTD? 

No, it maps into the host's memory map between 0xD0000 and 0xE0000 and has a 
custom ASIC to interface to the flash. The old versions behaved very similarly 
to EMS, paging in different blocks of flash - but the new version is very 
different, and very strange. 

It's CompactFlash that uses an ATA interface, either PCMCIA-ATA or raw IDE. So
you don't even need PCMCIA support to use it, I believe.


----                                 ----                                 ----
David Woodhouse        David.Woodhouse@mvhi.com       Office: (+44) 1223 810302
 Project Leader,     Process Information Systems      Mobile: (+44) 976 658355
    Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
             finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.




To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

Re: FFS2 and MTDs (flash)

[Jason Gunthorpe]

On Mon, 5 Jul 1999, David Woodhouse wrote:

> jgg@ualberta.ca said:
> >  Things will also run a bit faster if the buffer cache is used to hang
> > onto some often used filesystem meta data in main memory.
> 
> Think of CFI-compliant flash mapped into the host's address space. Why cache 
> it in RAM when you can just point a page table at the original?

CFI? The point here is that flash is not nearly as fast as system memory.
My boards have the flash configured with an 8bit memory bus and the
latency isn't exactly amazing either. It is not a huge deal, but if you
are accessing the same memory again and again to do lookups like FFS2 does
then a caching in system ram does speed things, and you get it for free ;>
 
> > XIP is not directly possible with FFS2 as it places no constraints on
> > alignment (like romfs).
> 
> So what they say on their web site about XIP is all crap? Of course, I suppose 
> that shouldn't surprise me :)

For WinCE? I donno. I -could- be done, but you'd need to page align the
datablocks explicity, some sort of special flag when you create the file I
guess. I only have one board that has un-paged flash (16 bits wide too)
but the flash is small and I'm thinking of using compression, so I am
not very concerned. (and again there is that issue with flash being slower
than system memory)

> Is it possible to run Linux on FFS2 without some kind on UMSDOS-like 
> translation layer? Are we going to want to write our own version which is 
> POSIX-compliant?

The FFS2 spec has room for some extension structures. I'm going to see
what QNX uses for their implementation and follow the same pattern. I need
to have at least devices to be supported..

Unfortunately the QNX folks have decided to create a new FFS for Neutrino
2, and they are not willing to give out any information about it's format
:<

> Yes please - that'd be useful.

http://www.deltatee.com/~jgg/mtd-19990629-jgg.tar.gz

Startup looks something like:

# insmod mtd; insmod octagon-5066
Octagon 5066 SSD IO:0x208 MEM:0xe8000-0xf0000
mtd0: 5066 Socket ROM 512KB (RO)
mtd1: 5066 Internal Flash (AMD Am29F016) 2048KB (RW)

The flash chip type is autoprobed and my board has support for two
distinct 'sockets' The VMax board starts with

mtd1: VMax 301 Internal Flash (3*[AMD Am29F080]) 6144KB (RW)

Indicating three chips were found. It doesn't yet support interleved flash
(flash that address based on the lowest adress bit) And I haven't ported
over the PCMICA driver, I'm not sure what to make of it.. The autoprober
also needs some work to detect ROM/RAM sizes (looking for wrap around)

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

Re: FFS2 and MTDs (flash)

[Rogier Wolff]

David Woodhouse wrote:
> 
> Think of CFI-compliant flash mapped into the host's address space. Why cache 
> it in RAM when you can just point a page table at the original?

One of the things is that the ROMs and flash devices that you're
talking about are usually only 8 or 16 bits wide. That means that you
get worse access times than 32- or 64-bit wide RAM. If you just copy
the page from the device into main memory the only thing that YOU'll
notice is that it is a whole lot faster than a disk. Once you start
executing code out of it, the first thing you'll notice is that it's
slower than RAM.... ;-)

XIP is useful though for very cramped machines. Say one with 4M RAM
and 16M flash. You might even want the kernel to stay put in the
flash. Possibly have the choice of running the one important
application (e.g. the mp3 decompressor in the empeg-car) get copied
over to RAM before execution....

			Roger.

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

Re: FFS2 and MTDs (flash)

[David Woodhouse]

jgg@ualberta.ca said:
>  It is not a huge deal, but if you are accessing the same memory again
> and again to do lookups like FFS2 does then a caching in system ram
> does speed things, and you get it for free ;>
>  

I was thinking that the CPU L1/L2 cache will have much the same effect, but 
I suppose on the type of systems we're talking about, there's not going to be 
a usefully large CPU cache. Shame; it seemed like quite a nice idea. 

It'd be nice to retain the option of doing it for those systems where it makes
sense - and I think the way you're doing it should allow that. So we can look 
into it later if we want to.



----                                 ----                                 ----
David Woodhouse        David.Woodhouse@mvhi.com       Office: (+44) 1223 810302
 Project Leader,     Process Information Systems      Mobile: (+44) 976 658355
    Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
             finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.




To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

Re: Loop Devices over NFS don't work?

[David Woodhouse]

jgg@ualberta.ca said:
>  How interesting (It looks simple to me, but is there something I'm
> not aware of?) It beats rebooting my desktop every time I screw up on
> this filesystem driver (MS Flash Filesystem 2 if anyone cares)! 

I use the MTD subsystem itself for testing - my workstation has 128Mb RAM, so I
boot it with 'mem=96M', load the 'physmem' driver to handle the extra 32Mb, 
and play with the filesystem on that. Course, I have these Disks-On-Chip too, 
but I haven't got a MTD system driver for them yet :)

Using FFS2 directly on the MTD layer rather than through an 'intermediate' 
block device should allow us to do clever things like execute-in-place (XIP) 
without too much trouble. Is there any need for FFS2 directly on a block 
device? If there is, I may have to rethink the arrangements to allow it.


----                                 ----                                 ----
David Woodhouse        David.Woodhouse@mvhi.com       Office: (+44) 1223 810302
 Project Leader,     Process Information Systems      Mobile: (+44) 976 658355
    Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
             finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.




To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

FFS2 and MTDs (flash)

[Jason Gunthorpe]

On Mon, 5 Jul 1999, David Woodhouse wrote:

> Using FFS2 directly on the MTD layer rather than through an 'intermediate' 
> block device should allow us to do clever things like execute-in-place (XIP) 
> without too much trouble. Is there any need for FFS2 directly on a block 
> device? If there is, I may have to rethink the arrangements to allow it.

Yes, there is lots of benifit to being able to mount a FFS filesystem over
a loop device or on a RAM disk or something else. There is also lots of
benifit to being able to create the FFS off the flash and then write the
whole thing in one go. For my purposes that is a crucial feature. Also
since the MTD's are presented as block devices you can mount other FS's
like romfs in read-only mode. 

Things will also run a bit faster if the buffer cache is used to hang onto
some often used filesystem meta data in main memory.

XIP is not directly possible with FFS2 as it places no constraints on
alignment (like romfs). It is concievable that you could carefully layout
a FFS2 filesystem to allow XIP, but IMHO it isn't worth it - if you are
running linux then you have ram to spare. Even QNX is largely moving away
from that except in the most tiny systems. 

My intent is to have the File System detect that it was mounted on a MTD
and then directly access that system where necessary. I've also re-done
the MTD stuff that was taken from the PCMCIA modules to act as a block
device drive and to provide a library of functions for dealing with raw
flash (which is what all my SBCs have on them). I haven't had any interest
in porting the FTL layer or providing backwards compatibilty with the
original character devices. Ultimately using FFS instead of something like
minix over FTL is a much better solution for embedded systems.

You're welcome to my code so far if you are interested, I have support for
an Octagon 5066, a V-Max 301 and untested support for something called a
MixCom card. 

BTW, I thought Disk on a chip used an ATA interface, and wasn't really a
MTD?

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk