Changing the ECC method for a running system (UBI seems to use OOB?)

Changing the ECC method for a running system (UBI seems to use OOB?)

[Steffen Kühn]

Hello everyone,

the problem which I have to solve is to change the type of the used ECC
procedure for a linux system with UBIFS >>after<< the installation. For
this purpose I have modified the first-stage bootloader so, that it
reads all blocks with the old ECC method (software ECC 1-bit) and
re-writes these with the new one (on-die hardware ECC, Micron flash).

The reason for that effort is, that the old method has to be proven as
to bad (to much bit errors). Unfortunately it is not possible to install
the system new with activated on-die ECC, because the hardware is
scattered over the world.

The update procedure works in principle fine, that means, it is possible
to update the blocks for kernel, u-boot, first-stage bootloader and
environment variables. But the rootfs makes problems. Can it be, that
UBIFS uses some bytes of the OOB structures, perhaps indirect?

Have someone any hints for me?

Best regards,
Steffen

Re: Changing the ECC method for a running system (UBI seems to use OOB?)

[David Mosberger-Tang]

Steffen,

We had exactly the same issue with our embedded systems (I'm really mad at
Micron that they released the 4-bit ECC chips without as much as putting a
warning message in the Linux kernel, but that's a separate topic...).

Anyhow, we modified the AT91bootstrap loader to convert the entire NAND
from 1-bit sw-ecc to on-die 4-bit ECC.  I'd be happy to send a patch to
this mailing list if you think this would be useful.

UBI fortunately does not use OOB at all, so there should be no issue from
there.

The subpage size has to match though.  In our case, UBI was built for 512B
subpage, but when turning on the on-die ECC support, it'd by default only
support 2048B pages.  The patch I sent earlier to this mailing list enables
512B subpage writes with on-die ECC.

  --david

On Thu, Apr 11, 2013 at 10:29 AM, Steffen Kühn <sk@ammonit.com> wrote:
> Hello everyone,
>
> the problem which I have to solve is to change the type of the used ECC
> procedure for a linux system with UBIFS >>after<< the installation. For
> this purpose I have modified the first-stage bootloader so, that it
> reads all blocks with the old ECC method (software ECC 1-bit) and
> re-writes these with the new one (on-die hardware ECC, Micron flash).
>
> The reason for that effort is, that the old method has to be proven as
> to bad (to much bit errors). Unfortunately it is not possible to install
> the system new with activated on-die ECC, because the hardware is
> scattered over the world.
>
> The update procedure works in principle fine, that means, it is possible
> to update the blocks for kernel, u-boot, first-stage bootloader and
> environment variables. But the rootfs makes problems. Can it be, that
> UBIFS uses some bytes of the OOB structures, perhaps indirect?
>
> Have someone any hints for me?
>
> Best regards,
> Steffen
>
>
>
>
>
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Changing the ECC method for a running system (UBI seems to use OOB?)

[Steffen Kühn]

Hello David,

> We had exactly the same issue with our embedded systems (I'm really mad at
> Micron that they released the 4-bit ECC chips without as much as putting a
> warning message in the Linux kernel, but that's a separate topic...).
> 
> Anyhow, we modified the AT91bootstrap loader to convert the entire NAND
> from 1-bit sw-ecc to on-die 4-bit ECC.  I'd be happy to send a patch to
> this mailing list if you think this would be useful.

Yes, this would be great! The patch is certainly also helpful for the
next with the same problem ...

> 
> UBI fortunately does not use OOB at all, so there should be no issue from
> there.
I have read this too. I'm happy that I have not to deal with YAFFS2.

> 
> The subpage size has to match though.  In our case, UBI was built for 512B
> subpage, but when turning on the on-die ECC support, it'd by default only
> support 2048B pages.  The patch I sent earlier to this mailing list enables
> 512B subpage writes with on-die ECC.

That could be my problem. I have not considered this point. Thanks!

Best regards,
Steffen

Re: Changing the ECC method for a running system (UBI seems to use OOB?)

[Angus CLARK]

Just to add one other point, you may need to skip programming "empty" pages when
transcoding the data to the new ECC format.  This will ensure the "empty" pages
can be programmed correctly, when UBIFS attempts to use them.

Cheers,

Angus

On 04/12/2013 10:12 AM, Steffen Kühn wrote:
> Hello David,
> 
>> We had exactly the same issue with our embedded systems (I'm really mad at
>> Micron that they released the 4-bit ECC chips without as much as putting a
>> warning message in the Linux kernel, but that's a separate topic...).
>>
>> Anyhow, we modified the AT91bootstrap loader to convert the entire NAND
>> from 1-bit sw-ecc to on-die 4-bit ECC.  I'd be happy to send a patch to
>> this mailing list if you think this would be useful.
> 
> Yes, this would be great! The patch is certainly also helpful for the
> next with the same problem ...
> 
>>
>> UBI fortunately does not use OOB at all, so there should be no issue from
>> there.
> I have read this too. I'm happy that I have not to deal with YAFFS2.
> 
>>
>> The subpage size has to match though.  In our case, UBI was built for 512B
>> subpage, but when turning on the on-die ECC support, it'd by default only
>> support 2048B pages.  The patch I sent earlier to this mailing list enables
>> 512B subpage writes with on-die ECC.
> 
> That could be my problem. I have not considered this point. Thanks!
> 
> Best regards,
> Steffen
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

-- 
-------------------------------------
Angus Clark
ST Microelectronics (R&D) Ltd.
1000 Aztec West, Bristol, BS32 4SQ
email: angus.clark@st.com
tel: +44 (0) 1454 462389
st-tina: 065 2389
-------------------------------------