On Sat, Nov 03, 2012 at 05:21:46PM +0100, Ilya Yanok wrote:
> Hi Tom,
> 
> On Wed, Oct 31, 2012 at 1:03 AM, Tom Rini <tr...@ti.com> wrote:
> >
> > > +     for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
> > > +             this->ecc.hwctl(&mtd, NAND_ECC_READ); +
> > nand_command(block,
> > > page, data_pos, NAND_CMD_RNDOUT); + +         this->read_buf(&mtd, p,
> > > eccsize); + +         nand_command(block, page, oob_pos,
> > > NAND_CMD_RNDOUT); + +         this->read_buf(&mtd, oob, eccbytes); +
> > > this->ecc.calculate(&mtd, p, &ecc_calc[i]); + +               data_pos +=
> > > eccsize; +            oob_pos += eccbytes; +          oob += eccbytes; +
> >      }
> >
> > This is where the function differs.  If we can't merge things
> > together, I'd like to see about putting just this function into
> > nand_spl_simple.c under CONFIG_SYS_NAND_HW_BCH8 since if I follow
> > what's going on, and I need to play with the code to confirm I do,
> > it's a generic change related to how much more we're reading back out
> 
> Not exactly. This change is rather GPMC-specific: we have to read data
> block then it's ecc code to get the syndrome. And even with GPMC in another
> configuration we will need another reading order...
> I'm not sure if we can do this in some generic way...

OK, lets just leave that part alone for now.  Maybe we need to allow for
some abstraction or __weak in the SPL read case, but we can revisit this
a little later on once we're able to see how say BCH16 behaves too.

-- 
Tom

Attachment: signature.asc
Description: Digital signature

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to