mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Andrei Yakimov <ayakimov@iptec-inc.com>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: barebox@lists.infradead.org
Subject: Re: drivers/mtd/nand/nand_mrvl_nfc.c
Date: Wed, 20 May 2015 17:30:36 -0700	[thread overview]
Message-ID: <1432168236.14341.228.camel@andreilinux> (raw)
In-Reply-To: <87twv7hz8x.fsf@belgarion.home>

I would like to provide a patch,
but I do not requesting any changes in baraebox
and not working with it.


I do not working with marvel chips,
do not have any controller description.

I found this problem in my 8313 u-boot elbc and
Scott Wood point me to same the problem in imx driver.

Checking linux drivers, found marvel driver which
looks like have same problem.

Geleral idea - linux nand detection flow, expect
PARAM command extra data will deliver as much data
as needed, each next read will trigger extra transfer
from nand chip. This is not true at least for 
elbc, imx and mrvl controllers ( just by looking
to the driver code).

Any controller with memory buffer and transferring
all data from chip at once and required another
nand commad to do next transfer will need to
be updated to read at least 1536 byte by param
commad.
Existing implementation for this type of controllers
will cause eventual failure on the field as soon 
as first ONFI/Jedec block will go bad unless other
other chip identification (by chip ID) pick it up.

Andrei


On Wed, 2015-05-20 at 20:37 +0200, Robert Jarzmik wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > Hi Andrei,
> >
> > +Cc Robert Jarzmik <robert.jarzmik@free.fr>
> >
> > On Tue, May 19, 2015 at 12:23:22PM -0700, Andrei Yakimov wrote:
> >> Please,
> >>  change 
> >>   case NAND_CMD_PARAM:
> >>         host->buf_count = 256;
> >> To:
> >>   host->buf_count = 768;
> >> 
> >> If first copy of parameter page corrupted you will not able
> >> to use ONFI flash.
> >
> > Thanks for noting. However, like many other opensource projects we
> > communicate changes and change requests with formalized patches. Please
> > generate one using git format-patch or similar and send it to the list.
> > I'll happily make that change then.
> 
> Same from me, I'll happily review a patch.
> May I add also that host->ndcb3 and host->data_size deserve the same change
> within the NAND_CMD_PARAM case statement.
> 
> Cheers.
> 



_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

      reply	other threads:[~2015-05-21  0:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-19 19:23 drivers/mtd/nand/nand_mrvl_nfc.c Andrei Yakimov
2015-05-20  6:19 ` drivers/mtd/nand/nand_mrvl_nfc.c Sascha Hauer
2015-05-20 18:37   ` drivers/mtd/nand/nand_mrvl_nfc.c Robert Jarzmik
2015-05-21  0:30     ` Andrei Yakimov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1432168236.14341.228.camel@andreilinux \
    --to=ayakimov@iptec-inc.com \
    --cc=barebox@lists.infradead.org \
    --cc=robert.jarzmik@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox