[U-Boot] Fix fsl_elbc_nand driver

[Scott Wood]

On Tue, 2015-05-19 at 16:42 -0700, Andrei Yakimov wrote:
> On Tue, 2015-05-19 at 17:38 -0500, Scott Wood wrote:
> > On Tue, 2015-05-19 at 15:29 -0700, Andrei Yakimov wrote:
> > > I did not compiling latest, I still in 2011.9 and 2.6.38.
> > > I have go over latest kernel and can see they using 
> > > NAND_CMD_PARAM with sub command  0x40 - to get JEDEC
> > > information, it is 3 mandatory copy by 512 bytes.
> > 
> > 3x512 or 3x256?
> ONFI - 3x256 sub command 0x0
> JEDEC - 3x512 sub command 0x40

So then we want 1536 bytes, not 768 (or 786) if we go with the simple
fix?

> > > Going over kernel divers, figure out some read whole
> > > page some 256 bytes.
> > > Reading whole page (set fcbr = 0) have some sense - you do not need
> > > to know anything about flash, but what to put in to read_bytes ?
> > 
> > You don't want fbcr = 0 here because that will enable ECC which isn't
> > there.
>  Is it correcting or just generating syndrome? It is working on
>  my board, I would say it only generate or ignored for this command
> (8313). It should corrupt data if it correcting but it does not.

Correcting.  Perhaps it's working because it's reporting an
uncorrectable error (thus not correcting anything) and you're ignoring
it?
 
> > > It looks like for universal patch 2K should be read.
> > 
> > Again, if we're going to do anything beyond s/256/768/ it should be a
> > higher level function where the caller says how much it wants.
> It is not normal nand  flow:  READ_ID and PARAM assuming it know the
> size.

I'm not sure what you're trying to say here.

> > > I have also check other vendor controllers like tegra,
> > > there continuous data read trigger additional data transfer from
> > > chip.
> Can we do  (NOP CWO UA RWB RS RS RS RS) 
> wait ltesr (cc) and after that 
> next  read_buffer ( RB or RS)
> all command have to start with NOP,
> this will effectively terminate previous command.
> And we do not care about locks in u-boot. kernel will be different
> store, but again this code executed only during start up - so who care
> holding CS to long.

You won't be holding CS that long.  It will drop as soon as the current
operation completes.  And I'm not interested in a solution that only
works in U-Boot's single-tasking environment, given that this code is
more or less shared with Linux.

I don't see what the objection is to adding a replaceable read_param()
method that is not so hostile to high-level controllers.

-Scott