This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Synth NAND Flash

Sergei Gavrikov wrote:
Thank you for your efforts! Can I ask you about UFFS itself? How did it
look for you, Is UFFS stable enough to use it? Thanks to your post about
UFFS I looked on its sources 2 days ago and just tried to know what its a
memory amount. I did stand up a small test sandbox here

Hmm, I don't have any experience with UFFS yet. But as I need something more economical than JFFS2 and public domain also UFFS seemed like a good option.

so, I knew that UFFS needs much less of .text, .bss than JFFS2 needs. As
I could understand UFFS has not GC like JFFS2 and, perhaps, it can be
more suitable for the small memory foot print systems. But, I do not
know, is UFFS stable, bug-less, etc.

UFFS does not use any GC. It's memory requirements are currently linear to the disk size, but should be very economical for smaller FS. It also should be, according to the author, stable to be used in real-world applications.

I see that you started from NAND flash driver for eCos to wire it with
UFFS core then. Fortunately or unfortunately I have no NAND flash parts
to play with it, and I looked in a side of a UFFS SIMRAM class which was
implemented by UFFS's author to debug and play with UFFS (I did import
uffs-1.3.0 sources). So, that my stub sandbox FS_UFFS does not seat on
FLASH_IO layer, instead, I thought to try to implement of a set of the
file system commands like uffs_mount, uffs_umount, uffs_open, etc. to
get the UFFS stuff like the eCos RAMFS file system for the test
purposed. It seemed for me that e.g. 512b x 512 or 256K UFFS partition
will be suitable for some targets and of course for synth Linux target.
What is your opinion about this way to test UFFS? Does it look wrong on
your view? If I miss understood something, please, enlighten me and I
will stop those my evening drops on bitbucket and will be wait a success
story from you.

This seems like a reasonable plan to me. I originally intended to do the same, but then decided to first focus on the NAND subsystem itself. Once we have synthetic NAND in place, implementing the NAND glue code for UFFS will be relatively easy and testable.

Of course it would be really great if you already write the glue code for the FS itself. This can be tested independently (with the SIMRAM class).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]