On Tue, May 12, 2009 at 10:36:34AM +0200, Simon Kallweit wrote: > Simon Kallweit wrote: >> Now for the actual design of the synth driver. I think the best way >> would be to implement a NAND simulator based on the ONFI >> specification. Something similar has been done for the MTD >> framework, but I guess other than for inspiration we're not allowed >> to use that code. So basically we would simulate the interface to the >> chip. I guess we don't have to simulate the signal lines. We just >> need some mechanism for chipselect and reset I guess. The interface >> will more be along the lines of writing commands, addresses, reading >> back etc. This means that the simulator will be implemented as a >> state machine. There is even one described in the ONFI specification >> for reference. > > Well after some more thought it's probably a better idea to keep the > interface to the NAND chip simulator very close to the hardware. That > means, a function for setting signal lines (CE, CLE, ALE, WP) as well > as two functions for read and write access. > > I don't intend to support multiple LUNs for the moment, just to keep > it simple. > > I have already done the interface to the NAND chip simulator. This > seems to work fine. I'll keep you updated.
Hello Simon 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 http://bitbucket.org/tickling/uffs4ecos/ 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. 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. Thank you. Sergei > Simon
