This is the mail archive of the 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]

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:


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.


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