Re: Synth NAND Flash

Simon Kallweit wrote:
> Hi there
> 
> I merged the NAND code from Rutger into my repo and tried to figure out 
> how to write synthetic target support, which in my opinion would be a 
> great addition so we can test future filesystems (UFFS) without a 
> target, do wear-leveling analysis and stuff like that.
> 
> First, I noticed a few things I would like to clear up in front. 
> Currently, the NAND subsystem sits in io/flash_nand which I think is 
> fine. But the devices sit under devs/flash, which is the same location 
> as for NOR flash. I think we should rename this to devs/flash_nand. I 
> already did this in my merge. This would make the distinction between 
> NOR and NAND flash more clearer. I also thought about renaming the whole 
> framework from flash_nand to simply nand. This would also match the API 
> names cyg_nand_xxx better. Are there any objections?

In fact, this is how I started out originally. But Andrew Lunn convinced 
me to do otherwise:

http://ecos.sourceware.org/ml/ecos-discuss/2008-09/msg00172.html

> I started out with eCos in it's default template. I was getting some 
> errors because of the missing ssize_t type. Either we should get rid of 
> it or add something like this to the CDL:
> 
> require CYGBLD_ISO_SSIZE_T_HEADER

My Ubuntu man page says that ssize_t should be defined by sys/types.h; 
requiring CYGPKG_ISOINFRA ought to be good enough.

> Other than that there is a little bit of cleaning up to do, but I think 
> that's all minor stuff.

I'm open for recommendations.

> Next I copied the GPIO nand flash controller to make a synth version and 
> also copied a st-micro NAND chip driver to make a synth version. For 
> now, they are pretty empty skeletons. But I was able to build the NAND 
> subsystems with those dummy drivers. Of course, the test cases don't 
> work. It also occurred to me that the "shell.c" test has quite a few 
> dependencies. I just removed this test for the moment.

Yes, sure, "shell.c" allows a number of operations to be done 
interactively. It is not so much in the vein of automated stress 
testing. It was in fact my testing vehicle for a raw terminal program. 
I'm fine with removing it from the standard test build, but I would be 
sorry to see it go.

> 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.

I never heard of an actual ONFI chip yet. Current chips are usually of 
the regular large-page kind. It might be most practical to make a 
generic regular large-page chip emulator that can be parameterized with 
the Device IDs as enumerated in cyg_nand_chip_id[] in file 
flash_nand/src/chip/io_nand_chip.c .

> I think the basics can be implemented rather quickly. I guess we don't 
> need to simulate multiple concurrent LUNs, or does the framework already 
> support these?

Multiple LUNs is the same as multiple chips, as far as the NAND package 
(or ONFI) is concerned. It should be supported, but it is untested 
because I lacked hardware.

> Well that's about it. I'll try to implement a simple simulator tomorrow 
> and see where I get. I post back some results as soon as I have something.
> 
> Simon

Rutger