Synth NAND Flash
Simon Kallweit
simon.kallweit@intefo.ch
Tue May 12 16:00:00 GMT 2009
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
More information about the Ecos-devel
mailing list