* [ECOS] Re: Simple flash filesystem? [not found] <981465384.28425.ezmlm@sources.redhat.com> @ 2001-02-06 12:30 ` Kristian Otnes 2001-02-06 12:50 ` Grant Edwards 0 siblings, 1 reply; 7+ messages in thread From: Kristian Otnes @ 2001-02-06 12:30 UTC (permalink / raw) To: ecos-discuss 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 ****************************************************************** ^ permalink raw reply [flat|nested] 7+ messages in thread
* [ECOS] Re: Simple flash filesystem? 2001-02-06 12:30 ` [ECOS] Re: Simple flash filesystem? Kristian Otnes @ 2001-02-06 12:50 ` Grant Edwards 2001-02-06 12:54 ` Lewin A.R.W. Edwards 0 siblings, 1 reply; 7+ messages in thread From: Grant Edwards @ 2001-02-06 12:50 UTC (permalink / raw) To: Kristian Otnes; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Re: Simple flash filesystem? 2001-02-06 12:50 ` Grant Edwards @ 2001-02-06 12:54 ` Lewin A.R.W. Edwards 2001-02-06 13:03 ` Grant Edwards 2001-02-06 13:13 ` [ECOS] Touch screen on EP7211 Wilson Kwan 0 siblings, 2 replies; 7+ messages in thread From: Lewin A.R.W. Edwards @ 2001-02-06 12:54 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss >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." ^ permalink raw reply [flat|nested] 7+ messages in thread
* [ECOS] Re: Simple flash filesystem? 2001-02-06 12:54 ` Lewin A.R.W. Edwards @ 2001-02-06 13:03 ` Grant Edwards 2001-02-06 13:13 ` [ECOS] Touch screen on EP7211 Wilson Kwan 1 sibling, 0 replies; 7+ messages in thread From: Grant Edwards @ 2001-02-06 13:03 UTC (permalink / raw) To: Lewin A.R.W. Edwards; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [ECOS] Touch screen on EP7211 2001-02-06 12:54 ` Lewin A.R.W. Edwards 2001-02-06 13:03 ` Grant Edwards @ 2001-02-06 13:13 ` Wilson Kwan 2001-02-07 5:07 ` Lewin A.R.W. Edwards 1 sibling, 1 reply; 7+ messages in thread From: Wilson Kwan @ 2001-02-06 13:13 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Touch screen on EP7211 2001-02-06 13:13 ` [ECOS] Touch screen on EP7211 Wilson Kwan @ 2001-02-07 5:07 ` Lewin A.R.W. Edwards 2001-02-07 8:12 ` Wilson Kwan 0 siblings, 1 reply; 7+ messages in thread From: Lewin A.R.W. Edwards @ 2001-02-07 5:07 UTC (permalink / raw) To: Wilson Kwan, ecos-discuss 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." ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Touch screen on EP7211 2001-02-07 5:07 ` Lewin A.R.W. Edwards @ 2001-02-07 8:12 ` Wilson Kwan 0 siblings, 0 replies; 7+ messages in thread From: Wilson Kwan @ 2001-02-07 8:12 UTC (permalink / raw) To: ecos-discuss, 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. 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2001-02-07 8:12 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <981465384.28425.ezmlm@sources.redhat.com> 2001-02-06 12:30 ` [ECOS] Re: Simple flash filesystem? Kristian Otnes 2001-02-06 12:50 ` Grant Edwards 2001-02-06 12:54 ` Lewin A.R.W. Edwards 2001-02-06 13:03 ` Grant Edwards 2001-02-06 13:13 ` [ECOS] Touch screen on EP7211 Wilson Kwan 2001-02-07 5:07 ` Lewin A.R.W. Edwards 2001-02-07 8:12 ` Wilson Kwan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).