mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: "Barbier, Renaud" <renaud.barbier@abaco.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: RE: barebox 2019.07 ubiformat
Date: Fri, 18 Oct 2019 15:09:00 +0000	[thread overview]
Message-ID: <MN2PR16MB311709C5A0F09CA7B9F69A24916C0@MN2PR16MB3117.namprd16.prod.outlook.com> (raw)
In-Reply-To: <MN2PR16MB311759D0859AB61BC1977E99916C0@MN2PR16MB3117.namprd16.prod.outlook.com>

Looking at the Linux nand_ecc, there is something specific for512 bytes size ecc:

if (eccsize_mult == 2 && (i & 0x4) == 0)
                        rp16 ^= tmppar;

code[2] =
+                   (invparity[par & 0xf0] << 7) |
+                   (invparity[par & 0x0f] << 6) |
+                   (invparity[par & 0xcc] << 5) |
+                   (invparity[par & 0x33] << 4) |
+                   (invparity[par & 0xaa] << 3) |
+                   (invparity[par & 0x55] << 2) |
+                   (invparity[rp17] << 1) |
+                   (invparity[rp16] << 0);

In barebox we have:
ecc_code[2] = ((~reg1) << 2) | 0x03;

So I guess there is a small change to do to support 512 bytes.
> -----Original Message-----
> From: Barbier, Renaud
> Sent: 18 October 2019 15:37
> To: Barbier, Renaud <renaud.barbier@abaco.com>; Sascha Hauer
> <s.hauer@pengutronix.de>
> Cc: barebox@lists.infradead.org
> Subject: RE: barebox 2019.07 ubiformat
> 
> Back from holidays
> 
> I have not been able to repeat the issue on the upstream DA923RC. It  is now
> booting after  ubiformatting using v2019.07.
> 
> Looking back in my commit history I found that in 2016.03 I replaced the
> barebox nand_ecc by the Linux nand_ecc file to work around this issue on
> ourP1014 platforms.
> 
> While debugging using the barebox nand_ecc, I  applied patched found in U-
> boot. This did not solve the problem.
> Our NAND uses 512 bytes for ecc size. The barebox eccsize is hard-coded to
> 256. Even setting to 512 did not help.
> 
> Should the nand_calculate_ecc algorithm be different for a 512 bytes size?
> 
> > -----Original Message-----
> > From: barebox [mailto:barebox-bounces@lists.infradead.org] On Behalf Of
> > Barbier, Renaud
> > Sent: 27 September 2019 09:44
> > To: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: barebox@lists.infradead.org
> > Subject: RE: barebox 2019.07 ubiformat
> >
> >
> >
> > [**EXTERNAL SOURCE**]:Please verify the source before clicking link or
> > opening attachment.
> >
> > > Not all blocks seem to be unreadable. Have you looked into subpage
> > > reads? subpage reads have been enabled in 18ea738 ("mtd: nand: Enable
> > > subpage reads"), but on the other hand that commit is already included
> > > in 2016.07. Anyway, maybe the old barebox doesn't do subpage reads for
> > > some reason.
> > > What ECC are you using, software or hardware? Is it still the same in
> > > the new barebox or are you maybe ending up with some other ECC
> scheme?
> > [Barbier, Renaud]
> > The PPC platforms uses software ECC. I will compare with our ARM platforms
> > that uses hardware ECC.
> > Thanks for the information. Answer hopefully in two weeks as I am going in
> > holidays
> >
> > Cheers,
> > Renaud
> >
> > _______________________________________________
> > barebox mailing list
> > barebox@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/barebox

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2019-10-18 15:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 17:44 Barbier, Renaud
2019-09-26  6:41 ` Sascha Hauer
2019-09-26 14:15   ` Barbier, Renaud
2019-09-27  6:44     ` Sascha Hauer
2019-09-27  8:43       ` Barbier, Renaud
2019-10-18 14:36         ` Barbier, Renaud
2019-10-18 15:09           ` Barbier, Renaud [this message]
2019-10-21  7:52             ` Sascha Hauer

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=MN2PR16MB311709C5A0F09CA7B9F69A24916C0@MN2PR16MB3117.namprd16.prod.outlook.com \
    --to=renaud.barbier@abaco.com \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox