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


Ð ÐÑÐ, 20/12/2007 Ð 05:10 -0700, Gary Thomas ÐÐÑÐÑ:
> Alexey Shusharin wrote:
> > Ð ÐÑÑ, 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.
> 
> Good.  Does it support the newer chips which have 4KB pages?

Not yet. But there are no barriers to add it in the future.

> >  - It has own ECC code (not from Linux and so not GPL-infected).
> 
> As Andrew has said, to really be useful, the ECC management must be
> compatible (if not borrowed from) Linux.

It doesn't have sense if driver doesn't use the same bad block
management algorithm.

> >  - 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.
> 
> We already have a FLASH driver function for this (flash_read_buffer())
> Why have two implementations?

I don't completely understand what you mean. My driver implements just
this function (if you mean flash_read_buf()), but it uses RAM buffer for
reading page, because ECC can be calculated for whole page only.

E.g. Toshiba NAND driver doesn't calculate ECC if application reads part
of page and therefore can read with error.

> >  - 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.
> 
> Again, is this compatible with how Linux does it?

No. There are many reasons why not.

Linux bad block management algorithm cannot be convenient with current
eCos flash API. RedBoot and eCos application don't know anything about
bad blocks and other NAND characteristics.

The one opportunity to use Linux compatible driver in eCos is using
JFFS2 (it knows about bad blocks). But JFFS2 cannot use eCos flash API,
because it must have access to NAND special functions (for example, it
writes to spare area).

> Virtually all "complex" platforms may end up running Linux at
> one time or another, so we should strive to be as supportive
> (compatible) as possible.  If your driver can be seen as an
> upgrade to the existing driver(s), then this would be best
> as having multiple solutions only causes grief...

I think there are two NAND driver development directions. The first is
using eCos flash API and not Linux compatible driver, which hides NAND
particularity. The second is to create flash_V3 branch, finish JFFS2 and
write compatible with Linux driver. And these directions don't prohibit
each other.

I use first direction because i don't need Linux compatibility. If
anybody wants, he can choose other way.

Best regards
Alexey Shusharin



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