[ECOS] Re: Simple flash filesystem?

[ECOS] Re: Simple flash filesystem?

[Kristian Otnes]

Hi Grant,
the reason for emulating a disk in a flash based filesystem
is probably twofold:

- It fits in with the normal disk approach usage
- It breaks the larger blocks (typically 64KB or 128KB) into
  virtual smaller blocks, so that other software is not
  bothered by the problem of handling the large flash blocks
  efficiently. In other words, it is a relatively simple
  way of managing some of the harder parts of flash usage.

As Lewin indicated, there are easy ways out depending on
the needs. But if you

- need some sort of efficient use of the flash
- intend to use the disk to some extent for repeated
  write operations
- want to be sure that the flash survives power failures etc.
  without corrupting the logics of the data within it

then I believe you need some sort of controller.

I have seen one implementer doing it with variable block sizes
for increased efficiency, others with fixed 512 bytes blocks and
some with user defined sizes. From my experience, all the
suggested solutions that seem usable for a broader audience,
boils down to variations of the block controller/disk emulator
concept.

I think the main problem with emulating a disk, is that
memory is needed for a mapping table between logical and
physical blocks. One could maybe avoid this by some rather slow
search mechanism. I guess it depends a bit on the needs,
but again the emulating disk concept seems as a good allround
solution.

Ok, so you got a flash disk controller. Then, the next problem
is the file system. It would be nice to have something

- that doesn't do any unnecessary updates to the disk (this
  will waste virtual blocks, since changing just one bit on
  a disk will invalidate a virtual block). E.g. use the flash
  remembering that: 1. writing is slow, 2. erasing is sometimes
  even slower

- that is somewhat secure so that it can doesn't leave
  you with an unreadable flash disk after a power failure
  or uncontrolled restart.

- that is not too big (big being a relative term though...)

Thus the following "stack" seems a practical approach:

    ------------
    Application
    ------------
    File System
    ------------
    Flash Disk Controller
    ------------
    Flash Driver
    ------------

The flash disk controller can be reused with different flash file
systems, since the file functionality holds the more or less
advanced file system features required. One could start off
with something very simple, and then grow... 

All in all, it is probably not made in a day, but once mastered,
it will be easier to use for new products, 
especially as one gets used to having a flash disk...

Alas, it is hard to find any free and good system on the
net... I couldn't when I needed it. The Journalling flash file system
( http://www.developer.axis.com/software/jffs/ ) is possibly one
candidate, but it is for Linux (maybe portable). I don't know
the situation of its overall performance and recovery mechanisms...

Kris.
  
******************************************************************
Tevero AS               Kristian Otnes
P.O.Box 96              Tel:    +47 67 56 29 95
N-1317 BAERUMS VERK     Mobile: +47 93 05 48 58
NORWAY                  E-mail: kristian.otnes@tevero.no
                        Web: www.tevero.no/products
******************************************************************


> Subject: Simple flash filesystem?
> Date: Mon, 05 Feb 2001 22:10:12 GMT
> From: "Grant Edwards" <grante@visi.com>
> To: ecos-discuss@sources.redhat.com
> 
> I've been looking for info on flash filesystems, and have found pretty
> much nothing.
> 
> What I have found are flash device-drivers that emulate 512-byte
> block devices so that you can use them in place of disk drives
> underneath file systems designed for disk drives.  These filesystems
> are designed with (and optimized for) the following assumptions:
> 
>  1) The physical media has 512 blocks that are independently
>     erasable/writable.
> 
>  2) Read and write operations are both an order of magnitude slower
>     than RAM.
> 
>  3) Read and write times for a sector depend on the sector number (i.e.
>     there is a seek-time).
> 
>  4) There is zero cost associated with an erase (either elapsed time
>     or media lifetime).
> 
> For flash, none of these assumptions are true.  Blocks can only be erased
> in large chunks (typically 64k).  Read operations are the same speed
> (roughly) as RAM.  Write operations are an order of magnitude slower.
> Erase operations are _another_ order of magnitude slower and have an
> associated media life cost.  Read/write speeds are independant of address.
> 
> Though it may be the most expedient thing to do in the short-term,
> It seems like a bad idea to take a complex filesystem designed for disk
> and use it for a flash.  For example, it seems like a waste of effort
> to impliment 512 byte blocks when the filesystem uses them in 4K clusters.
> 
> Rather than try to make a flash act like a disk drive (and using a
> disk-drive filesystem), has anybody seen any information on a simple
> filesystem designed for flash?
> 
> --
> Grant Edwards
> grante@visi.com
> 
>   
-- 
******************************************************************
Tevero AS               Kristian Otnes
P.O.Box 96              Tel:    +47 67 56 29 95
N-1317 BAERUMS VERK     Mobile: +47 93 05 48 58
NORWAY                  E-mail: kristian.otnes@tevero.no
******************************************************************

[ECOS] Re: Simple flash filesystem?

[Grant Edwards]

Kristian Otnes writes:

[excellent analsys of problem]

> Alas, it is hard to find any free and good system on the
> net... I couldn't when I needed it. The Journalling flash file system
> ( http://www.developer.axis.com/software/jffs/ ) is possibly one
> candidate, but it is for Linux (maybe portable). I don't know
> the situation of its overall performance and recovery mechanisms...

I found jffs and a couple other journalling approaches to implimenting
a block device underneath a Unix or DOS filesystem, but they all seemed
way too big/complex when my filesystem isn't going to be more than a few
hundred KBytes and will be rarely written to.  For now, I'm going to try
to use a ROM filesystem and have users download the whole directory
tree when a file changes.

\x18It could be worse, I could ask them to link the files as data with the
application code and eCos.

Maybe in phase II (AKA: the list of things that will never get done)
I'll come up with a simple flash filesystem for my situation: writes
are rare and are allowed to block reads for a long time (several seconds).

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Re: Simple flash filesystem?

[Lewin A.R.W. Edwards]

>way too big/complex when my filesystem isn't going to be more than a few
>hundred KBytes and will be rarely written to.  For now, I'm going to try

Aha!! Do you have a "few hundred KBytes" of free RAM?

You could get the best of all possible worlds by loading the FS into RAM, 
and allowing random R/W as convenient, then committing the entire thing 
back to flash when your device is idle.


=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

[ECOS] Re: Simple flash filesystem?

[Grant Edwards]

Lewin A.R.W. Edwards writes:

> >way too big/complex when my filesystem isn't going to be more than a few
> >hundred KBytes and will be rarely written to.  For now, I'm going to try
> 
> Aha!! Do you have a "few hundred KBytes" of free RAM?

I should.

> You could get the best of all possible worlds by loading the FS into RAM, 
> and allowing random R/W as convenient, then committing the entire thing 
> back to flash when your device is idle.

Yup.

That's probably the simplest solution for a small filesystem.  Burns can
happen in the background without interrupting read access to the RAM
version of the files.

Of course once marketing gets hold of the web pages, I may end up with
several megabytes of real-audio and dancing GIFs.  Then half of my
assumptions go out the window.  :)

-- 
Grant Edwards
grante@visi.com

[ECOS] Touch screen on EP7211

[Wilson Kwan]

Has anyone had any success getting the touch screen working on a cirrus
EP7211 dev board? Where can I get some sample code. The code in the eCos
distribution doesn't seem to work. I looked in the archives but could not
find any relevent information.

Thanks in advance,
Wilson

Re: [ECOS] Touch screen on EP7211

[Lewin A.R.W. Edwards]

Hello Wilson,

>Has anyone had any success getting the touch screen working on a cirrus
>EP7211 dev board? Where can I get some sample code. The code in the eCos

There is some sample code included on the CD-ROM (Cirrus's). I haven't 
tested it myself.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] Touch screen on EP7211

[Wilson Kwan]

> Hello Wilson,
>
> >Has anyone had any success getting the touch screen working on a cirrus
> >EP7211 dev board? Where can I get some sample code. The code in the eCos
>
> There is some sample code included on the CD-ROM (Cirrus's). I haven't
> tested it myself.

Thanks Lewin but I tried the sample code on the CD and it doesn't seem to
work either. The documentation seems to be sparse for my board. The sample
eCos sample code seems to be for the 7212 board.

Wilson