This is the mail archive of the ecos-patches@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: NAND Flash device driver


Ð ÐÑÑ, 18/12/2007 Ð 07:30 -0700, Gary Thomas ÐÐÑÐÑ:
> Alexey Shusharin wrote:
> > Ð ÐÑÑ, 18/12/2007 Ð 10:13 +0100, Andrew Lunn ÐÐÑÐÑ:
> >> On Tue, Dec 18, 2007 at 10:03:11AM +0600, Alexey Shusharin wrote:
> >>> ?? ??????, 10/12/2007 ?? 19:01 +0600, Alexey Shusharin ??????????:
> >>>> Hi,
> >>>>
> >>>> This patch adds a NAND Flash device driver to flash V1 branch.
> >>>>
> >>>> Currently it supports 8-bit NAND flash with 256/512 page size and has
> >>>> implemented software ECC and simple bad block management algorithms.
> >>>>
> >>>> I've tested it with SAMSUNG K9F5608U0D.
> >>>>
> >>>> Best regards
> >>>> Alexey Shusharin
> >>>>
> >>> Hi guys!
> >>>
> >>> What's wrong with this patch? Why you didn't answer?
> >> I've never worked with a NAND device, so i did not feel too happy to
> >> look at this patch. I hope one of the other maintainers has the
> >> necessary background.
> >>
> > Hi,
> > Thanks for answer.
> > 
> >> Having said that, i took a quick look at the code. I have some general
> >> questions about NAND devices and drivers.
> >>
> >> You have the ECC and bad block management code integrated with the
> >> package. Is this specific to the Samsung device? I'm wondering if this
> >> should be separated out, either into a new package, or made part of
> >> io/flash with some CDL to control it. It then makes it possible for
> >> other manufactures devices to use this code.
> > 
> > I didn't check all NAND devices, of course. But devices which i know
> > have identical memory arrangements and general access methods. They
> > differs only access times which is adjusted by platform code. Moreover,
> > Linux NAND driver doesn't distinguish between different manufacturers.
> > So i think this driver should work with different manufacturers devices.
> > 
> > If this statement is true the ECC and bad block management algorithms
> > depend of NAND page size only. This driver support only small page (256
> > or 512 bytes), but can be modified to support large page in the future
> > (device with large page has other command set).
> > 
> > Other issue is 16-bit bus width support. It's not difficult to add this
> > feature (add 3 small functions), but i cannot test it because have 8-bit
> > flash only.
> > 
> >> You say this is not compatible with Linux. How much effort is required
> >> to make it compatible? A lot of people use eCos for RedBoot, booting
> >> Linux. In this situation it is useful to be compatible with Linux.
> > 
> > Unfortunately Linux NAND driver has complex bad block management
> > algorithm and the best way to make driver compatible with Linux - get
> > code from it (this is that u-boot does). Therefore if i use other bbm
> > algorithm, it doesn't matter to use the same ECC algorithm, more so i
> > didn't find its description.
> > 
> > You can find more information about Linux NAND driver there:
> > http://www.linux-mtd.infradead.org/doc/nand.html
> > http://www.linux-mtd.infradead.org/tech/mtdnand/index.html
> > 
> > There are other reasons in using especial bbm algorithm.
> > eCos flash API doesn't have methods to works with NAND speciality (write
> > to spare area, check bad blocks and etc.) and RedBoot doesn't support
> > this features too. This driver hides NAND flash particularity and makes
> > it transparent for flash API and RedBoot FIS.
> > 
> > Maybe somebody has other opinion. You are welcome! ;-)
> 
> I've not had time to review this, but how different is it from
> the existing Toshiba NAND device driver?

In general:

 - It supports not only Toshiba chips.

 - It has own ECC code (not from Linux and so not GPL-infected).

 - It has page buffer in RAM so application can read any part of page
and doesn't worry about ECC (driver reads whole page and corrects data).
Buffer also allows to read data from one page several times without
access to chip.

 - It implements bad block management algorithm which reserves repair
area at the end of the flash and replace bad blocks in main area with
blocks from it. New bad blocks will be also replaced. Management
information resides in last not bad block.

Best regards
Alexey



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