[U-Boot] Fix fsl_elbc_nand driver

[Andrei Yakimov]

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
> 
> > 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.

> 
> > 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 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.

there is only 4 places for PARAM:
drivers/mtd/nand/mxs_nand_spl.c	  chip->cmdfunc(mtd, NAND_CMD_PARAM, 0,
-1);
drivers/mtd/nand/nand_base.c: chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
drivers/mtd/nand/nand_base.c: chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
drivers/mtd/nand/nand_base.c: chip->cmdfunc(mtd, NAND_CMD_PARAM, 0x40,
-1);

latest kernel read it like this:
      chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
        for (i = 0; i < 3; i++) {
                for (j = 0; j < sizeof(*p); j++)
                        ((uint8_t *)p)[j] = chip->read_byte(mtd);
                if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
                                le16_to_cpu(p->crc)) {
                        break;
                }
        }

> 
> Yes, that's how the hardware works, but controllers like eLBC don't
> directly expose that interface.  We need to get all of the command's
> output at once.
> 
> >  This kind of implementation better, but I did not see how it could
> > be done for this controller.
> 
> I wouldn't say it's "better" so much as a closer fit to what the Linux
> NAND code is expecting.
> 
> > I am not sure how is small page (512 byte) flash should operate
> > also.
> 
> Is there any small-page ONFI flash?
I do not know.
ONFI parameter page will tell you page size:
80-83  M  Number of data bytes per page
84-85  M  Number of spare bytes per page
if we drop it, lets set to 2k and forget.
> 
> Why did you take this e-mail off-list?
Sorry just forgot.
> 
> -Scott
> 
>