Synth NAND Flash

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?

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

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

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.

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

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