Re: Synth NAND Flash

Rutger Hofman wrote:
>> 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

OK, then I have to rename my stuff again :)

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

Seems like there is a bug in eCos as the option is called 
CYGBLD_ISO_SSIZE_T_HEADER but used as CYGBLD_ISO_SSIZET_HEADER. I submit 
a patch for it.

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

I'll post patches when ready.

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

Ok, then we should make the building of this 'test' configurable and add 
a list of requirements for building. Anyone disagrees?

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

Seems like a good idea. Although it might be nice to also simulate the 
more esoteric types. Configuration could be done by just specifying the 
ID bytes. I didn't yet figure out the content of bytes 3-4 though. Are 
they standardized? We could also provide a configuration interface for 
custom chips, so pretty much every configuration could be done, but this 
might well be overkill.

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

I see. I think it's a good idea to first test behaviour with real 
hardware and then see how the simulator needs to be adapted.

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

I have the basics running. But I still ended up using a bit of code from 
the MTD NAND simulator code. I hope we can get an agreement with the 
original author to use bits of his code. Anyone thinks this is a problem?

Simon