This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: Synth NAND Flash
- From: Simon Kallweit <simon dot kallweit at intefo dot ch>
- To: Rutger Hofman <rutger at cs dot vu dot nl>
- Cc: "ecos-devel at ecos dot sourceware dot org" <ecos-devel at ecos dot sourceware dot org>
- Date: Tue, 12 May 2009 18:00:54 +0200
- Subject: Re: Synth NAND Flash
- References: <4A0855FB.1030908@intefo.ch> <4A0968BF.3050204@cs.vu.nl>
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