drivers/mtd/nand/nand_mrvl_nfc.c

[Andrei Yakimov]

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 at pengutronix.de> writes:
> 
> > Hi Andrei,
> >
> > +Cc Robert Jarzmik <robert.jarzmik at 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.
>