This is the mail archive of the ecos-devel@sourceware.org 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


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



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