Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Free flash file system for vxworks?

391 views
Skip to first unread message

cecil

unread,
Mar 30, 2001, 6:10:55 PM3/30/01
to
Does anybody know of a freeware flash file system for vxworks or is our only
choice TrueFFS?
Thanks
Nigel


molochai

unread,
Mar 31, 2001, 6:00:21 AM3/31/01
to
In message <986026835.29461.0...@news.demon.co.uk>
"cecil" <ce...@hunmanby.demon.co.uk> wrote:

> Does anybody know of a freeware flash file system for vxworks or is our
> only choice TrueFFS?

Not as far as I know. There is one being developed for linux (JFFS) which I
had a peak at the other day but I don't think it would port terribly easily.

My major problem with TFFS is the cost - which is quite considerable, coming
in at about a third of the cose for an OEM licence *PER PROJECT* as well as
extra run-time costs.

Anyone intersted in writing/porting an open-source alternative?

Michael R. Kesti

unread,
Mar 31, 2001, 1:07:49 PM3/31/01
to
cecil wrote:

>Does anybody know of a freeware flash file system for vxworks or is our only
>choice TrueFFS?

It's not very difficult to homebrew an FFS with a limited feature set. Start
by writing a library for your flash memory. It needs to include functions to
erase the entire memory, erase specific sectors of the memory, and to write
arbitrary length arrays to specific locations in the memory. Once this is up
and working, modify the RAM disk driver supplied with vxWorks to become a
flash disk driver by changing the block write function to first erase the
sector that is about to be written and then to call the flash memory
library's write function rather than bcopy(). Also, rewrite the "format"
ioctl to use the library function that erases the entire memory. Install
this driver from your application as you would the RAM disk driver, using
the flash memory's sector size as the disk's sector size, etc.

This FFS provides no wear leveling, writes its FAT to the same sector every
time, and makes no attempt to distribute data sector usage. If, however,
your system only infrequently needs to write to this disk (Perhaps to store
application images or data that doesn't often need to be altered.), this
can be acceptable.

--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mke...@gv.net | - The Who, Bargain

molochai

unread,
Mar 31, 2001, 3:57:47 PM3/31/01
to
In message <3AC61CF5...@gv.net>

"Michael R. Kesti" <mke...@gv.net> wrote:

> cecil wrote:
>
> > Does anybody know of a freeware flash file system for vxworks or is our
> > only choice TrueFFS?
>
> It's not very difficult to homebrew an FFS with a limited feature set.
> Start by writing a library for your flash memory. It needs to include
> functions to erase the entire memory, erase specific sectors of the memory,
> and to write arbitrary length arrays to specific locations in the memory.
> Once this is up and working, modify the RAM disk driver supplied with
> vxWorks to become a flash disk driver by changing the block write function
> to first erase the sector that is about to be written and then to call the
> flash memory library's write function rather than bcopy(). Also, rewrite
> the "format" ioctl to use the library function that erases the entire
> memory. Install this driver from your application as you would the RAM
> disk driver, using the flash memory's sector size as the disk's sector
> size, etc.

Yes.. I had thought along these lines too, but I unfortuantely do need to
write the flash rather more often than this, and need guarentees of its
security. The other potential problem is that I'm using either 32MB or 64MB
Intel strataflash parts where the erase blocks are 64Kb each.

However, this is definately a good starting point. Presumably what you would
do next is to build a sector-map table to allow translation between logical
sectors (as seem by the filing system) and physical sectors on the flash, the
sectors almost certainly being smaller than the underlying erase units.

The sector-map table would probably have to be locatable anywhere on the
device(s) and some method of identify it at power-up would be required.

The difficult bit I suspect, is going to be the heuristics for allocation and
garbage collection to allow for wear-levelling, and designing data structures
to minimize copying.

Anyone got any comments? Anyone spun their own FFS along these lines?

Serge Wenger

unread,
Apr 2, 2001, 1:25:55 AM4/2/01
to
You can try to port Intel VFM (vitrtual small block file manager).

/Serge
"cecil" <ce...@hunmanby.demon.co.uk> a écrit dans le message news:
986026835.29461.0...@news.demon.co.uk...

B Luong

unread,
Apr 24, 2001, 8:20:01 PM4/24/01
to
Try looking at

ftp://ftp.atd.ucar.edu/pub/vxworks/vx/ flash.zip - Source for a flash
file system. FTP only.

Don't know if its any good. Could never get it to work on my board.

Dave Korn

unread,
Apr 25, 2001, 5:30:41 AM4/25/01
to
B Luong wrote in message <3AE61831...@student.cs.york.ac.uk>...

>Don't know if its any good. Could never get it to work on my board.

Well, that's enough information to be able to put an upper bound on how
good it is..

DaveK
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.

B Luong

unread,
Apr 25, 2001, 5:42:08 PM4/25/01
to
> Dave Korn wrote:
>
>>
>> >Don't know if its any good. Could never get it to work on my board.
>>
>> Well, that's enough information to be able to put an upper bound on how
>>
>> good it is..
>>
>
... or maybe an upper bound on my programming skills :-)

ggang1

unread,
Apr 28, 2001, 12:26:04 AM4/28/01
to
Hi...

I read the file(flash.zip)
I wonder that flashFsInit (NUM_FLASHFS_FILES) /* init flashFs filesystem */
The function don't exist ..
How make the function..?
What include the function ..?


0 new messages