All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörg Krause" <joerg.krause@embedded.rocks>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mxs_nand: Fix ECC strength for NAND flash with OOB size of 256
Date: Mon, 13 Apr 2015 13:38:56 +0200	[thread overview]
Message-ID: <1428925136.8695.17.camel@embedded.rocks> (raw)
In-Reply-To: <552B85DA.2090503@denx.de>

Hi Marek, Heiko,

On Mo, 2015-04-13 at 11:01 +0200, Heiko Schocher wrote:
> Hello Marek, Joerg,
> 
> Am 13.04.2015 10:42, schrieb Marek Vasut:
> > On Monday, April 13, 2015 at 10:39:46 AM, J?rg Krause wrote:
> > > Hi Heiko,
> > > 
> > > On So, 2015-04-12 at 10:17 +0200, Heiko Schocher wrote:
> > > > On the i.mx6 based aristainetos2 board a Toshiba 
> > > > TH58NYG3S0HBAI4
> > > > is used, which has 4096 pagesize and 256b oob. The ECC strength
> > > > was not correct detected by U-Boot
> > > > 
> > > > Signed-off-by: Heiko Schocher <hs@denx.de>
> > > > ---
> > > > 
> > > >   drivers/mtd/nand/mxs_nand.c | 3 +++
> > > >   1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/drivers/mtd/nand/mxs_nand.c
> > > > b/drivers/mtd/nand/mxs_nand.c
> > > > index 2d2b938..00bf036 100644
> > > > --- a/drivers/mtd/nand/mxs_nand.c
> > > > +++ b/drivers/mtd/nand/mxs_nand.c
> > > > @@ -163,6 +163,9 @@ static inline uint32_t
> > > > mxs_nand_get_ecc_strength(uint32_t page_data_size,
> > > > 
> > > >                if (page_oob_size == 224)
> > > > 
> > > >                        return 16;
> > > > 
> > > > +
> > > > +             if (page_oob_size == 256)
> > > > +                     return 18;
> > > > 
> > > >        }
> > > > 
> > > >        return 0;
> > > 
> > > How about calculation the ECC strength dynamically? Peng Fan from
> > > Freescale send a patch doing this in December 2014 which was 
> > > already
> > > reviewed by Marek:
> > > https://patchwork.ozlabs.org/patch/422756/
> > > 
> > > It is also necessary to change the calculation in mxsboot...
> > 
> > Would be nice if the patch got applied, but I think there were some
> > comments and the patch was never fixed/reposted. If Heiko wants to
> > do it, that'd be nice.
> 
> Hmm.. I feel, I have not much time left for fixing such things...

I can re-submit the patch from Peng Fan together with my fixes for 
mxsboot.

> Joerg: You wrote on Jan. 27, 2015, 11:14 p.m.:
> "I was able to fix mxsboot, but I had difficulties with round_down, 
> which
> is a macro definition in linux/kernel.h. I've copied the macro
> definition to mxsboot. I will submit the patch in a seperate mail."
> 
> Did you post such a patch? Was this the onyl problem of the patch
> from Peng Fan?

No, I didn't. I waited for some comment and then I just forgot about 
it. The main problem with the patch from Peng Fan was that it was not 
consistent with mxsboot, which still has the hardcoded oobsizes. I 
copied the calculation to mxsboot.c, but failed to include 
linux/kernel.h, because mxsboot is compiled with the host compiler and 
u-boot with the cross-compiler. So I just copied the macro definition 
for round_down from kernel.h to mxsboot.c.

> "I would like to see a comment or a macro for the magic number 13, 
> which
> is the value for the Galois Field, just for clarification"
> 
> I have no idea what 13 means ...

This is cited from the i.MX28 Reference Manual:
    BCH-codes are a type of block-code, which implies that all error-
    correction is performed over a block of N-symbols. The BCH 
    operation will be performed over GF (2^13 = 8192), which is the 
    Galois Field consisting of 8191 one-bit symbols.

> 
> > Nice domain name btw ;-)
> 
> Indeed.

Thanks :-)

> 
> bye,
> Heiko

  parent reply	other threads:[~2015-04-13 11:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-12  8:17 [U-Boot] [PATCH] mxs_nand: Fix ECC strength for NAND flash with OOB size of 256 Heiko Schocher
2015-04-13  8:39 ` Jörg Krause
2015-04-13  8:42   ` Marek Vasut
2015-04-13  9:01     ` Heiko Schocher
2015-04-13  9:12       ` Marek Vasut
2015-04-13 11:38       ` Jörg Krause [this message]
2015-04-13 13:25         ` Heiko Schocher

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=1428925136.8695.17.camel@embedded.rocks \
    --to=joerg.krause@embedded.rocks \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.