mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* barebox 2019.07 ubiformat
@ 2019-09-25 17:44 Barbier, Renaud
  2019-09-26  6:41 ` Sascha Hauer
  0 siblings, 1 reply; 8+ messages in thread
From: Barbier, Renaud @ 2019-09-25 17:44 UTC (permalink / raw)
  To: barebox

We recently jumped from barebox 2016.07 to 2019.07. 
Everything went well till the NAND got ubiformated.

Using the version from2016.07, the NOR boot partition can be formatted (FIT image) and NAND (file system) and the system boots.
When using the barebox 2019-07, both storage can be formatted but when booting (Linux 4.16 or 5.2) I get:

nand: device found, Manufacturer ID: 0x01, Chip ID: 0xdc
nand: AMD/Spansion S34ML04G1
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
1 fixed-partitions partitions found on MTD device ff800000.flash
Creating 1 MTD partitions on "ff800000.flash":
0x000000000000-0x000020000000 : "nand"
fsl,ifc-nand ff800000.nand: IFC NAND device at 0xff800000, bank 1
...
...
ubi0: default fastmap pool size: 200
ubi0: default fastmap WL pool size: 100
ubi0: attaching mtd5
ubi0: fixable bit-flip detected at PEB 2
ubi0: fixable bit-flip detected at PEB 3
ubi0: fixable bit-flip detected at PEB 4
...
ubi0: fixable bit-flip detected at PEB 3270
random: crng init done
ubi0: scanning is finished
__nand_correct_data: uncorrectable ECC error
__nand_correct_data: uncorrectable ECC error
__nand_correct_data: uncorrectable ECC error
...
__nand_correct_data: uncorrectable ECC error
ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 22528 bytes from PEB 0:4096, read only 22528 bytes, retry
__nand_correct_data: uncorrectable ECC error
...
ubi0 error: ubi_io_read: error -74 (ECC error) while reading 22528 bytes from PE
B 0:4096, read 22528 bytes
CPU: 0 PID: 1 Comm: swapper Not tainted 5.2.0-owc-g39fb4f3.tethys-dx1014 #1
Call Trace:
[cf825d18] [c02e7d0c] ubi_io_read+0x1b4/0x37c (unreliable)
[cf825d68] [c02dd9a0] ubi_read_volume_table+0x128/0xb8c
[cf825dc8] [c02ef46c] ubi_attach+0xbc/0x3a0
[cf825df8] [c02e1710] ubi_attach_mtd_dev+0x654/0xcf8
[cf825e58] [c0575ec0] ubi_init+0x198/0x224
[cf825e98] [c0003194] do_one_initcall+0x3c/0x1a8
[cf825ef8] [c055fba8] kernel_init_freeable+0x12c/0x1dc
[cf825f28] [c00033b0] kernel_init+0x14/0x114
[cf825f38] [c000f268] ret_from_kernel_thread+0x14/0x1c

So far I have been looking at the commit in barebox regarding MTD/UBI/UBIFS to v2019.09 and cannot see anything obvious.
I could rebase forward if necessary. Is that something that is been observed by anybody?

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: barebox 2019.07 ubiformat
  2019-09-25 17:44 barebox 2019.07 ubiformat Barbier, Renaud
@ 2019-09-26  6:41 ` Sascha Hauer
  2019-09-26 14:15   ` Barbier, Renaud
  0 siblings, 1 reply; 8+ messages in thread
From: Sascha Hauer @ 2019-09-26  6:41 UTC (permalink / raw)
  To: Barbier, Renaud; +Cc: barebox

Hi Renaud,

On Wed, Sep 25, 2019 at 05:44:16PM +0000, Barbier, Renaud wrote:
> We recently jumped from barebox 2016.07 to 2019.07. 
> Everything went well till the NAND got ubiformated.
> 
> Using the version from2016.07, the NOR boot partition can be formatted (FIT image) and NAND (file system) and the system boots.
> When using the barebox 2019-07, both storage can be formatted but when booting (Linux 4.16 or 5.2) I get:

There is no driver for this NAND controller upstream, I assume you have
it in your tree, right? Can barebox itself read what it has written,
i.e. ubiattach / mount it?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: barebox 2019.07 ubiformat
  2019-09-26  6:41 ` Sascha Hauer
@ 2019-09-26 14:15   ` Barbier, Renaud
  2019-09-27  6:44     ` Sascha Hauer
  0 siblings, 1 reply; 8+ messages in thread
From: Barbier, Renaud @ 2019-09-26 14:15 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox

My apology, I used a model (DX1014) that we have not upstream to your repository.
It is based on the Freescale P1014 unlike the DA923RC (MPC8544). More answer below
Including both the DA923RC and DX1014.



> >
> > Using the version from2016.07, the NOR boot partition can be formatted (FIT
> image) and NAND (file system) and the system boots.
> > When using the barebox 2019-07, both storage can be formatted but when
> booting (Linux 4.16 or 5.2) I get:
> 
> There is no driver for this NAND controller upstream, I assume you have
> it in your tree, right? 
[Barbier, Renaud] 
Correct. The NAND driver has not been upstream for the DA923RC.
I have now used the DA923RC to do the same test.

With barebox from 2016.07, ubiformat gives me:
OWBOOT> / addpart -n /dev/ram0 77070336@0x10000(image)
OWBOOT> / ls /dev/nand0
/dev/nand0
OWBOOT> / ubiformat -q -y /dev/nand0 -f /dev/image
OWBOOT> /

With 2019.07, ubiformat gives:
OWBOOT> / ubiformat -y -q /dev/nand0 -f /dev/image
ubi1: detaching mtd0 from ubi1
ubi1: removing nand0.ubi
ubi1: mtd0 is detached
nand0: error -74 (ECC error) while reading 64 bytes from PEB 14:0
nand0: error -74 (ECC error) while reading 64 bytes from PEB 15:0
nand0: error -74 (ECC error) while reading 64 bytes from PEB 21:0
nand0: error -74 (ECC error) while reading 64 bytes from PEB 21:512
nand0: error -74 (ECC error) while reading 64 bytes from PEB 24:0
nand0: error -74 (ECC error) while reading 64 bytes from PEB 24:512
nand0: error -74 (ECC error) while reading 64 bytes from PEB 30:0
nand0: error -74 (ECC error) while reading 64 bytes from PEB 30:512
nand0: error -74 (ECC error) while reading 64 bytes from PEB 37:0
nand0: error -74 (ECC error) while reading 64 bytes from PEB 37:512
nand0: error -74 (ECC error) while reading 64 bytes from PEB 47:0
nand0: error -74 (ECC error) while reading 64 bytes from PEB 47:512
nand0: error -74 (ECC error) while reading 64 bytes from PEB 470:0
nand0: error -74 (ECC error) while reading 64 bytes from PEB 470:512
nand0: error -74 (ECC error) while reading 64 bytes from PEB 473:0
nand0: error -74 (ECC error) while reading 64 bytes from PEB 473:512
ubi1: scanning is finished
ubi1 error: ubi_update_fastmap: could not find any anchor PEB
ubi1 warning: ubi_update_fastmap: Unable to write new fastmap, err=-28
nand0: error -74 (ECC error) while reading 64 bytes from PEB 30:512
ubi1: scrubbed PEB 30 (LEB 0:28), data moved to PEB 2702
nand0: error -74 (ECC error) while reading 64 bytes from PEB 37:512
ubi1: scrubbed PEB 37 (LEB 0:35), data moved to PEB 2104
nand0: error -74 (ECC error) while reading 64 bytes from PEB 47:512
ubi1: scrubbed PEB 47 (LEB 0:45), data moved to PEB 2103
ubi1: scrubbed PEB 328 (LEB 1:33), data moved to PEB 2101
nand0: error -74 (ECC error) while reading 64 bytes from PEB 21:512
ubi1: scrubbed PEB 21 (LEB 0:19), data moved to PEB 2100
nand0: error -74 (ECC error) while reading 64 bytes from PEB 24:512
ubi1: scrubbed PEB 24 (LEB 0:22), data moved to PEB 2099
ubi1: scrubbed PEB 26 (LEB 0:24), data moved to PEB 1925
ubi1: scrubbed PEB 448 (LEB 1:153), data moved to PEB 1922
nand0: error -74 (ECC error) while reading 64 bytes from PEB 470:512
ubi1: scrubbed PEB 470 (LEB 1:175), data moved to PEB 1921
nand0: error -74 (ECC error) while reading 64 bytes from PEB 473:512
ubi1: scrubbed PEB 473 (LEB 1:178), data moved to PEB 1920
nand0: error -74 (ECC error) while reading 64 bytes from PEB 13:512

On the DX1014, ubiformat never reported an ECC errors on both 2016 and 2019

Can barebox itself read what it has written,
> i.e. ubiattach / mount it?
[Barbier, Renaud] 

DA923RC:
Barebox can attach and mount, do ls and copy a file to memory and boot.

DX1014:
Barebox can attach and mount, do ls but not copy a file to memory.
OWBOOT> / cp /bin/busybox.nosuid /
could not open /bin/busybox.nosuid: No such file or directory


I could upstream the DA923RC nand driver if you like but I think it may be easier for me to do a dichotomy between 2016 and 2019 and find when it  went wrong. 
If you have any idea, let me know.

Cheers,
Renaud



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: barebox 2019.07 ubiformat
  2019-09-26 14:15   ` Barbier, Renaud
@ 2019-09-27  6:44     ` Sascha Hauer
  2019-09-27  8:43       ` Barbier, Renaud
  0 siblings, 1 reply; 8+ messages in thread
From: Sascha Hauer @ 2019-09-27  6:44 UTC (permalink / raw)
  To: Barbier, Renaud; +Cc: barebox

On Thu, Sep 26, 2019 at 02:15:57PM +0000, Barbier, Renaud wrote:
> My apology, I used a model (DX1014) that we have not upstream to your repository.
> It is based on the Freescale P1014 unlike the DA923RC (MPC8544). More answer below
> Including both the DA923RC and DX1014.
> 
> 
> 
> > >
> > > Using the version from2016.07, the NOR boot partition can be formatted (FIT
> > image) and NAND (file system) and the system boots.
> > > When using the barebox 2019-07, both storage can be formatted but when
> > booting (Linux 4.16 or 5.2) I get:
> > 
> > There is no driver for this NAND controller upstream, I assume you have
> > it in your tree, right? 
> [Barbier, Renaud] 
> Correct. The NAND driver has not been upstream for the DA923RC.
> I have now used the DA923RC to do the same test.
> 
> With barebox from 2016.07, ubiformat gives me:
> OWBOOT> / addpart -n /dev/ram0 77070336@0x10000(image)
> OWBOOT> / ls /dev/nand0
> /dev/nand0
> OWBOOT> / ubiformat -q -y /dev/nand0 -f /dev/image
> OWBOOT> /
> 
> With 2019.07, ubiformat gives:
> OWBOOT> / ubiformat -y -q /dev/nand0 -f /dev/image
> ubi1: detaching mtd0 from ubi1
> ubi1: removing nand0.ubi
> ubi1: mtd0 is detached
> nand0: error -74 (ECC error) while reading 64 bytes from PEB 14:0
> nand0: error -74 (ECC error) while reading 64 bytes from PEB 15:0
> nand0: error -74 (ECC error) while reading 64 bytes from PEB 21:0
> nand0: error -74 (ECC error) while reading 64 bytes from PEB 21:512

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?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: barebox 2019.07 ubiformat
  2019-09-27  6:44     ` Sascha Hauer
@ 2019-09-27  8:43       ` Barbier, Renaud
  2019-10-18 14:36         ` Barbier, Renaud
  0 siblings, 1 reply; 8+ messages in thread
From: Barbier, Renaud @ 2019-09-27  8:43 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox


> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: barebox 2019.07 ubiformat
  2019-09-27  8:43       ` Barbier, Renaud
@ 2019-10-18 14:36         ` Barbier, Renaud
  2019-10-18 15:09           ` Barbier, Renaud
  0 siblings, 1 reply; 8+ messages in thread
From: Barbier, Renaud @ 2019-10-18 14:36 UTC (permalink / raw)
  To: Barbier, Renaud, Sascha Hauer; +Cc: barebox

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: barebox 2019.07 ubiformat
  2019-10-18 14:36         ` Barbier, Renaud
@ 2019-10-18 15:09           ` Barbier, Renaud
  2019-10-21  7:52             ` Sascha Hauer
  0 siblings, 1 reply; 8+ messages in thread
From: Barbier, Renaud @ 2019-10-18 15:09 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: barebox 2019.07 ubiformat
  2019-10-18 15:09           ` Barbier, Renaud
@ 2019-10-21  7:52             ` Sascha Hauer
  0 siblings, 0 replies; 8+ messages in thread
From: Sascha Hauer @ 2019-10-21  7:52 UTC (permalink / raw)
  To: Barbier, Renaud; +Cc: barebox

Hi Renaud,

On Fri, Oct 18, 2019 at 03:09:00PM +0000, Barbier, Renaud wrote:
> 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.

What we have in barebox currently seems to be the nand_ecc.c version of
Linux-2.6.25. A git log of that file from v2.6.25 to master has:

260dc003e9fd mtd: nand: fix 512 byte software ecc support

So yes, we do not seem to have 512 byte software ecc support.

I'd say just update nand_ecc.c to a recent Kernel version.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-10-21  7:52 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-25 17:44 barebox 2019.07 ubiformat 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
2019-10-21  7:52             ` Sascha Hauer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox